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

VisionFive 2 （English Forum)
1

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
3

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
4

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
5

Do you know the address of the boot rom?

Thanks for any help

6

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
7

modifying the boot rom might make it possible to boot direct from nvme ssd.

8

You can not modify a ROM (Read Only Memory).

1 Like
9

Rom goes to switch selected SPL
It’s in flash or uart

1 Like
10

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
11

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 ?

12

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
13

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
14

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

grafik
grafik710×163 4.51 KB

3 Likes
15

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
16

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
17

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
18

thanks for your pointing it out.

19

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
20

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?

2 Likes
22

I would expect the license of the BootROM to be either Apache 2.0 or possibly dual licensed Apache 2.0 or GPL 2.0 or later.since it would probably be forked and patched rather than written fully from scratch.

I thought of another way to dump the contents of the BootROM after reading this:
While booting hit the space bar to enter the U-Boot command prompt, And then type any of the following commands into the U-boot prompt and it will spew out a full hexdump+safe to print ASCII characters showing the contents at the memory addresses (b is 8 bit/ 1 byte, w is 16 bit/2 bytes words, l is 32 bit/4 bytes longs and q is 64-bit/8 bytes qwords, and the last hexadecimal number at the end is how many should be printed)…I was unable to copy and paste into my USB serial interface, so I just typed the command and it worked as expected.
I just logged the serial console output to file, for later manipulation to regenerate the binary ROM file.

Hit any key to stop autoboot:  0
StarFive # md.b 2A000000 8000
StarFive # md.w 2A000000 4000
StarFive # md.l 2A000000 2000
StarFive # md.q 2A000000 1000

e.g. the first 32 bytes only:

StarFive # md.b 2A000000 20
2a000000: 97 02 00 00 93 82 62 12 73 90 52 30 73 50 00 30  ......b.s.R0sP.0
2a000010: 73 50 40 30 81 40 01 41 81 41 01 42 81 42 01 43  sP@0.@.A.A.B.B.C
StarFive # md.w 2A000000 20
2a000000: 0297 0000 8293 1262 9073 3052 5073 3000  ......b.s.R0sP.0
2a000010: 5073 3040 4081 4101 4181 4201 4281 4301  sP@0.@.A.A.B.B.C
StarFive # md.l 2A000000 20
2a000000: 00000297 12628293 30529073 30005073  ......b.s.R0sP.0
2a000010: 30405073 41014081 42014181 43014281  sP@0.@.A.A.B.B.C
StarFive # md.q 2A000000 20
2a000000: 1262829300000297 3000507330529073  ......b.s.R0sP.0
2a000010: 4101408130405073 4301428142014181  sP@0.@.A.A.B.B.C

And there were some readable ASCII error messages towards the end of the dump, which makes me believe that the dump is valid and probably unencrypted.

1 Like