Is the source code for the boot rom for the VisionFive 2 available?

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
grafik
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