I’d love to look thru it.
The docs say that it is hard coded so I guess we cant overwrite it?
I’ve done some bare metal programming on riscv mcus like the Sparkfun Red-V board and I am curious about doing this on this board.
Thanks for any help
2 Likes
In my mind all the really interesting things happen in the SPL. I do not think that the ZSBL is all that interesting (configure the minimal number of clocks, enable/power-up the minimal number of devices required and load the SPL into the only accessible SRAM to the CPU at that stage in the boot process and transfer execution over to the newly loaded SPL). Even if the source code is not available for the JH7110, it would be amazingly similar to previous ZSBL’s for previous ROM chips in its ancestry.
e.g.
https://github.com/sifive/freedom/tree/master/bootrom
https://github.com/sifive/freedom-u540-c000-bootloader
1 Like
While it cannot be modified (because internal ROM), it’d still be interesting to see.
There’s value in knowing what code runs in a SoC’s startup, from the very first instruction.
Source code would be ideal, but I understand the boot rom is right there in the memory map, so it could be dumped and reverse-engineered. E.g. producing a commented disassembly.
1 Like
Do you know the address of the boot rom?
Thanks for any help
I saw the memory address here: http://doc-en.rvspace.org/VisionFive2/Developer_Guide/JH7110_Boot_UG.pdf
And the JH7110 TRM confirms it:
https://doc-en.rvspace.org/JH7110/TRM/JH7110_TRM/system_memory_map.html
Start Address End Address Size Attribute Device/Description
0x00_2A00_0000 0x00_2A00_81FF 32.5KB RX Boot ROM
Since it is too large to fit in the L1 cache (32 KiB), I guess it executes directly from the ROM.
1 Like
modifying the boot rom might make it possible to boot direct from nvme ssd.
You can not modify a ROM (Read Only Memory).
1 Like
Rom goes to switch selected SPL
It’s in flash or uart
1 Like
This thread is about the ZSBL (zero stage boot loader) which can not be modified without creating a new silicon device. Look at page 13 of the JH7110_Boot_UG.pdf file linked to above. That shows how you will eventually boot from NVMe (using QSPI to load the SPL, which loads the OpenSBI_U-boot which will load linux from …).
1 Like
What I’m looking for is how the AXP15060 power management is setup.
I assume it has to be setup early
in rom ?
or in SPL/U-BOOT ?
From sifive fu740-c000 manual:
On power-on, all cores jump to 0x1004
Also:
The Zeroth Stage Boot Loader (ZSBL) is contained in a mask ROM at 0x1_0000. It is responsi- ble for downloading the more complicated U-Boot SPL
Also:
the U- Boot SPL, are downloaded into the L2 LIM at address 0x0800_0000
Spl does stuff and then “ Jump to DDR memory (0x8000_0000)”
Also:
OpenSBI is executed from DDR, located at 0x8000_0000 and remains resident in memory at this location. It is responsible for providing the Supervisor Binary Interface
Then:
U-Boot manages the hardware that is used to load the Linux kernel. At the board level, U-Boot exposes a command line interface on the console serial port
Whew! Lots of moving parts to try to understand!
1 Like
After a quick speed read through u-boot, it looks to me like SPL configures pins underneath the JH7110 to be able to talk to I2C5 which is the bus where the AXP15060 PMIC(U22) and a 512 byte GT24C02A EEPROM(U30) are located. In my mind nothing would be talking to the PMIC before pins to be able to access it were configured.
1 Like
I think this is just a typo that occurred when creating the table.
The following line should be right.
0x00_2A00_0000 0x00_2A00_7FFF 32 KB RX Boot ROM
see JH7100 Datasheet - page 15 - 2.2. Memory and Storage
and see StarFive JH7110 Technical Reference Manual - Boot Process, notes
2 Likes
modifying the boot rom might make it possible to boot direct from nvme ssd.
Boot ROM is inside the SoC and is an actual ROM: It cannot be modified.
Booting directly from nvme is not possible; the nvme’s contents are not present the physical memory space. You would need to initialize PCI-e first, then the nvme, then send I/O read requests… which would load code/data into RAM, for which you need to also initialize the RAM.
Initializing the RAM is done by the SPL, which is loaded into the SoC’s SRAM by this boot ROM. By default SPL resides in the on-board QSPI flash, but as selected by the onboard switches, it can be loaded from emmc, sd and the uart.
AIUI, current SPL is not able to load opensbi/u-boot from emmc, sd or uart, so you’re stuck with the SPI. A special rescue image exists for the uart mode, which can flash the SPI in case it became unbootable.
Loading the kernel from the network/uart/disk is done by u-boot, which also resides in the on-board SPI.
There is ongoing work to get pci-e working on u-boot, which otherwise already has nvme support. I suspect this effort is what interests you.
4 Likes
so far happy to boot microsd with / on nvme
I’m used to Armbian on an arm board booting emmc with / on nvme.
after getting the nvme up and running I’m more concerned with the heat.
my application is headless which cuts heat substantially.
1 Like