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
3 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.
5 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
I wonder if a tftpserver was setup and running, could the ROM be uploaded to there from inside Das U-Boot.
e.g
StarFive # tftpput 0x2A000000 8200 192.168.1.100:ZSBLROM.bin
Or by the time that network is up and accessible, inside U-Boot, is that too late ? That JH7110 has left machine mode and entered into supervisor mode and the memory location where the Zero Stage BootLoader ROM resides is no longer accessible ? (Start address: 0x002A000000 ; End address : 0x002A0081FF ; size in bytes: 0x8200 )
1 Like
thanks for your pointing it out.
Yes, it doesn’t apply anymore (as of the firmware from the release in early March).
Current SPL can load the next stage from SD and presumably eMMC too.
1 Like
I would be glad if it got published. It’s even legal issue: the BootROM apparently includes GPL sources for qspi and sdio drivers (did strings -a on bootrom once extracted).
Most sources also come from VF1’s ddrinit GitHub - starfive-tech/JH7100_ddrinit
My claims maybe bold enough, and afaik GPL 2.0 does not require to publish parts of your own code, just code for GPLed part, right? Correct me if I’m wrong.
So far, considering nobody from StarFive gonna release the source, I probably will sit and in few nights reconstruct it back from what we have here, for own curiosity and abit RISC-V learning. But will it be legal to publish my results?