Re: [linux-sunxi] Help understanding SPL and booting

[Peter Watkins]

Hi Andre,

>From an earlier email:
> See https://lists.denx.de/pipermail/u-boot/2022-January/473568.html 
>  for a
> recent example, which is actually much bigger, since it also introduces
> ARMv5 support to the sunxi port.
Oh my. That’s a huge patch. We’ll I’ll just take it a step at a time and look 
at it a little bit at a time.

> That was referring to your original problem: to get your own build booted.
> So ideally there is some working image somewhere (could be Android, or
> whatever), provided by the board vendor. And yes, you compare the UART
> output of this one to your self-built image, and see what would come next.

Ah. OK. I can get a pre-built Linux image, but it’s for eMMC not an SD card. I 
have the eMMC hardware on order. From images on Lindenis’ site, I can see what 
should come next. I get the following:

[388][mmc]: ***SD/MMC %u init OK!!!***
[394]error:bad magic.
[398]error:bad magic.
[400]Loading boot-pkg fail(error=4)

I should get:

[321][mmc]: ***SD/MMC %u init OK!!!***
[449]Loading boot-pkg Succeed(index=0)


However, that doesn’t tell me what the magic number is or where its looking for 
the boot package.

> So that part is pretty easy: the BROM starts at the beginning of the
> image. This is a branch instruction to jump over the eGON header and
> probably some other data parts of boot0. In this case it's:
>  0:   eaccb   0x338
> and then continues down there:
> 338:   eaffb   0x33c
> 33c:   e10fmrs r0, CPSR
> 340:   e3c0001fbic r0, r0, #31
> 
> And yeah, having some software help you to unwind this is probably
> mandatory in understanding that. Still takes a lot of time, and asking in
> IRC is always faster ;-)

I have a question out on IRC but it’s pretty silent right now. Your disassembly 
helped. So far I have this in Ghidra:

 LAB_0338
XREF[1]: (j)  
0338 ff ff ff ea bLAB_033c
 LAB_033c
XREF[1]: 0338(j)  
033c 00 00 0f e1 mrs  r0,cpsr
0340 1f 00 c0 e3 bic  r0,r0,#ARMV7_MODE_MASK
0344 13 00 80 e3 orr  r0,r0,#ARMV7_SVC_MODE
0348 c0 00 80 e3 orr  r0,r0,#( ARMV7_IRQ_MASK | 
ARMV7_FIQ_MASK )   // After reset, ARM automaticly disables IRQ and FIQ, 
and runs in SVC mode.
034c 02 0c c0 e3 bic  r0,r0,#ARMV7_CC_E_BIT 
   // set little-endian
0350 00 f0 21 e1 msr  cpsr_c,r0
 ;// configure memory system : disable MMU,cache 
and write buf
0354 10 0f 11 ee mrc  p15,0x0,r0,cr1,cr0,0x0
0358 02 0a c0 e3 bic  r0,r0,#0x2000
035c 07 00 c0 e3 bic  r0,r0,#( ARMV7_C1_M_BIT | 
ARMV7_C1_A_BIT | ARM
0360 02 0b 80 e3 orr  r0,r0,#0x800
0364 01 0a c0 e3 bic  r0,r0,#0x1000
0368 10 0f 01 ee mcr  p15,0x0,r0,cr1,cr0,0x0
 // set SP for C language
036c 24 d0 9f e5 ldr  sp,[BOOT0_STACK_BOTTOM]   
   = 00058800h
0370 01 00 00 eb bl   FUN_037c  
   undefined FUN_037c()
0374 bf 0d 00 fa blx  FUN_3a78  
   undefined FUN_3a78()
0378 f7 0d 00 fa blx  FUN_3b5c  
   undefined FUN_3b5c()


I was hoping to use the msg() calls to navigate my way around the code. 
Unfortunately, Ghidra shows only one or two of the strings in the binary as 
being referenced anywhere in the code. Perhaps my analysis ran off the rails 
somewhere? It thinks it found 165 functions. Also, only a few of them have any 
parameters at all.

Thanks,

Peter

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/D685A1FE-B7AF-4E38-9883-753E49C7316C%40gmail.com.

Re: [linux-sunxi] Help understanding SPL and booting

[Andre Przywara]

On Mon, 7 Feb 2022 09:20:25 -0800
Peter Watkins  wrote:

Hi Peter,

> > How did you build it? I guess using some vendor provided BSP sources?  
> 
> Yes. I used the code Lindenis supplies for that specific board:
> http://wiki.lindeni.org/index.php/Lindenis_V536#Downloading 
> 
> 
> > Shouldn't those contain the magic binary blobs then?  
> 
> The ones that contain the compiled boot0 code? Yes, the one the config file 
> picked for my compilation run is here:
> https://github.com/lindenis-org/lindenis-v536-device/blob/master/config/chips/v536/bin/boot0_sdcard_sun8iw16p1_ddr3.bin
>  
> 
> 
> The compilation process changes a few bytes in the header of that image 
> (inserts build timestamps, maybe?) but otherwise what I have on my SD card is 
> the same as what’s above.

So yeah, this is a bog standard boot0 image, with what we call an "eGON"
header (check the hexdump). The header format is documented in
include/sunxi_image.h in the (mainline) U-Boot tree. For instance you can
see the size (at 0x10: "00 e0 00 00") matching the file size.
The changes it does might be to the DRAM parameters (type, configuration,
timing, ...), we have seen those to be contained in this file in some data
structure somewhere, and the code reads them at runtime.
Then it needs to recalculate the checksum.

> > Well, not quite. boot0 is a proprietary piece of software that serves the
> > same purpose as the SPL part in U-Boot:
> > The on-chip BootROM loads some code from one of the various boot sources
> > (SD card, SPI flash, eMMC ...) into SRAM and executes this. This is
> > typically very limited in size (32KB), though later SoCs tend to support
> > larger images, but not by much. The purpose of this code is then to
> > initialise the DRAM controller, and load the actual U-Boot code.
> > The SPL is part of mainline U-Boot, however boot0 is not, not in mainline
> > and not in AW's BSP versions. In the distant past the boot0 source was
> > "available" for some SoCs/boards, but in general Allwinner tends to keep
> > that closed. I don't know how the situation is in your case, I am afraid
> > you have to dig through all those BSP code drops. Also the existence of
> > a "boot1" stage seemed to vary across the generations, I believe some SoC
> > do not use that, and jump straight into U-Boot.  
> 
> Ah! OK. This is starting to make sense now. The following is one of those 
> code drops, right?
> https://github.com/hno/allwinner-boot/tree/lichee-a20-dev/boot0 
> 

Yes, this is one of the better known examples. But the A20 is 10 years
old, and a lot has changed since then. And the A20 is pretty much reverse
engineered by now and fully support mainline, so we don't need any of this
anymore, it was just used as a source of information.

> I guess part of what you said is mentioned in the note at the bottom of this 
> wiki page:
> https://linux-sunxi.org/Boot_Process 
> 
> In my case, however, I don’t think boot0 loads boot1. Perhaps it goes 
> directly to U-Boot? I never found the string “eGON.BT1” in boot0 or anywhere 
> else in the SD card image.

Yeah, I think boot1 was only used for some older SoCs, which had even more
limited SRAM.

> > The critical part that boot0 does is to initialise the DRAM controller.
> > There is no public documentation about the IP used, and it tends to be
> > different between each SoC, sometimes only slightly so, sometimes
> > dramatically. For the mainline supported SoCs, this was reverse
> > engineered, see arch/arm/mach-sunxi/dram* in a mainline U-Boot source tree
> > near you.  
> OK. So look through here:
> https://github.com/u-boot/u-boot/tree/master/arch/arm/mach-sunxi 
> 
> 
> …for register addresses and values which match what’s in sun8iw16p1_ddr3.bin 
> ?
> Sounds challenging. I’ll give it a try though.

It is indeed challenging, and you won't probably understand much without
help. I am trying to wrap my head around this for 5 years, and have
barely scratched the surface. If you could join the #linux-sunxi IRC
channel on OFTC, there are the some of the people who wrote the DRAM
controller parts in mainline U-Boot in there. Chances are they know a bit
or two about the V536. If you are lucky, one of the existing driver works,
probably with some smaller changes. Just ask if anyone knows about the
V536 DRAM.

Having said that: to get things started, we did in the past use mainline
U-Boot (the non-SPL part: "U-Boot proper") along with some boot0 blob as an
SPL replacement, only as a temporary measure, to get things moving. For a
32-bit 

Re: [linux-sunxi] Help understanding SPL and booting

[Peter Watkins]

Hi Andre,


> How did you build it? I guess using some vendor provided BSP sources?

Yes. I used the code Lindenis supplies for that specific board:
http://wiki.lindeni.org/index.php/Lindenis_V536#Downloading 


> Shouldn't those contain the magic binary blobs then?

The ones that contain the compiled boot0 code? Yes, the one the config file 
picked for my compilation run is here:
https://github.com/lindenis-org/lindenis-v536-device/blob/master/config/chips/v536/bin/boot0_sdcard_sun8iw16p1_ddr3.bin
 


The compilation process changes a few bytes in the header of that image 
(inserts build timestamps, maybe?) but otherwise what I have on my SD card is 
the same as what’s above.

> Well, not quite. boot0 is a proprietary piece of software that serves the
> same purpose as the SPL part in U-Boot:
> The on-chip BootROM loads some code from one of the various boot sources
> (SD card, SPI flash, eMMC ...) into SRAM and executes this. This is
> typically very limited in size (32KB), though later SoCs tend to support
> larger images, but not by much. The purpose of this code is then to
> initialise the DRAM controller, and load the actual U-Boot code.
> The SPL is part of mainline U-Boot, however boot0 is not, not in mainline
> and not in AW's BSP versions. In the distant past the boot0 source was
> "available" for some SoCs/boards, but in general Allwinner tends to keep
> that closed. I don't know how the situation is in your case, I am afraid
> you have to dig through all those BSP code drops. Also the existence of
> a "boot1" stage seemed to vary across the generations, I believe some SoC
> do not use that, and jump straight into U-Boot.

Ah! OK. This is starting to make sense now. The following is one of those code 
drops, right?
https://github.com/hno/allwinner-boot/tree/lichee-a20-dev/boot0 


I guess part of what you said is mentioned in the note at the bottom of this 
wiki page:
https://linux-sunxi.org/Boot_Process 

In my case, however, I don’t think boot0 loads boot1. Perhaps it goes directly 
to U-Boot? I never found the string “eGON.BT1” in boot0 or anywhere else in the 
SD card image.


> The critical part that boot0 does is to initialise the DRAM controller.
> There is no public documentation about the IP used, and it tends to be
> different between each SoC, sometimes only slightly so, sometimes
> dramatically. For the mainline supported SoCs, this was reverse
> engineered, see arch/arm/mach-sunxi/dram* in a mainline U-Boot source tree
> near you.
OK. So look through here:
https://github.com/u-boot/u-boot/tree/master/arch/arm/mach-sunxi 


…for register addresses and values which match what’s in sun8iw16p1_ddr3.bin 
?
Sounds challenging. I’ll give it a try though.


> From my experience dealing with the BSP code is a complete waste of time.
Oh, don’t tell me that. :( I was kind of hoping to “just get this thing 
working”. 

> From briefly looking into the github, this release seems to be based on a
> 2014 U-Boot version, which is outdated beyond all hopes.
Yeah. That worries me a little. Lindenis doesn’t seem to be doing much in terms 
of ongoing support.


> Or at least compare the output of such a build to see what you are
> missing.
What do you mean by output? The UART output? And by build, do you mean a 
mainline U-boot build or the Lindenis binary boot0?


> Can you try to harvest those bits from an existing (pre-built) binary
> image?
I’ll try. I’m trying to learn Ghidra, so maybe this’ll be a good exercise. From 
the Wiki, the BROM should load boot0 code from the 8k offset on the SD card 
into address 0 in SRAM and execute it from there. I don’t know where the actual 
ARM instructions start in that binary image, but it looks like there’s a script 
that can help me:
https://nstarke.github.io/ghidra/binary/address-offset/2021/06/06/bruteforcing-ghidra-file-offsets.html
 


Thanks for all the info and clarification!

-Peter


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/D09200D0-DD14-4C1C-A0B7-8979E46F3F17%40gmail.com.

Re: [linux-sunxi] Help understanding SPL and booting

[Andre Przywara]

On Fri, 4 Feb 2022 17:33:47 -0800 (PST)
Peter Watkins  wrote:

Hi Peter,

> I'm using a Lindenis v536 SBC. I've built an image, loaded it on an SD 

How did you build it? I guess using some vendor provided BSP sources?
Shouldn't those contain the magic binary blobs then?

> card, and now I can observe these messages over a UART interface:
> 
> [70]HELLO! BOOT0 is starting!
> [72]boot0 commit : edb664ec9618b2388deb8d5658aa223a2f47d641
>  
> [90]rsb_send_initseq: rsb clk 400Khz -> 3Mhz
> [94]PMU: AXP2101
> [97]set pll start
> [99]set pll end
> [101]DRAM BOOT DRIVE INFO: V0.41
> [104]the chip id is 0x0004
> [107]the chip id is 0x0004
> [110]the chip id is 0x0004
> [113]the chip id is 0x0004
> [116]the chip id is 0x0004
> [119]chip id check OK
> [121]DRAM_VCC set to 1500 mv
> [156]Training result is = 00ff
> [159]DRAM training fail !
> [195]Training result is = 0007
> [198][AUTO DEBUG]32bit,1 ranks training success!
> [236]Training result is = 0007
> [274]Training result is = 0007
> [277]DRAM CLK =792 MHZ
> [280]DRAM Type =3 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4)
> [318]Training result is = 0007
> [322]Actual DRAM SIZE =1024 M
> [325]DRAM SIZE =1024 MBytes, para1 = 30fa, para2 = 0400, dram_tpr13 
> = 08006843
> [342]DRAM simple test OK.
> [344]dram size =1024
> [348]card no is 0
> [350]sdcard 0 line count 4
> [352][mmc]: mmc driver ver 2017-09-26 15:04
> [357][mmc]: sdc0 spd mode error, 2
> [360][mmc]: mmc 0 bias 
> [368][mmc]: Wrong media type 0x
> [372][mmc]: ***Try SD card %u***
> [382][mmc]: HSSDR52/SDR25 %u bit
> [385][mmc]: %u Hz
> [387][mmc]: %u MB
> [388][mmc]: ***SD/MMC %u init OK!!!***
> [394]error:bad magic.
> [398]error:bad magic.
> [400]Loading boot-pkg fail(error=4)
> [404]Ready to disable icache.
> 
> 
> My understanding is that I'm seeing the Boot0 portion of U-Boot executing. 
> This is called the SPL, right? This starts at the 8k address on the SD card.

Well, not quite. boot0 is a proprietary piece of software that serves the
same purpose as the SPL part in U-Boot:
The on-chip BootROM loads some code from one of the various boot sources
(SD card, SPI flash, eMMC ...) into SRAM and executes this. This is
typically very limited in size (32KB), though later SoCs tend to support
larger images, but not by much. The purpose of this code is then to
initialise the DRAM controller, and load the actual U-Boot code.
The SPL is part of mainline U-Boot, however boot0 is not, not in mainline
and not in AW's BSP versions. In the distant past the boot0 source was
"available" for some SoCs/boards, but in general Allwinner tends to keep
that closed. I don't know how the situation is in your case, I am afraid
you have to dig through all those BSP code drops. Also the existence of
a "boot1" stage seemed to vary across the generations, I believe some SoC
do not use that, and jump straight into U-Boot.

The critical part that boot0 does is to initialise the DRAM controller.
There is no public documentation about the IP used, and it tends to be
different between each SoC, sometimes only slightly so, sometimes
dramatically. For the mainline supported SoCs, this was reverse
engineered, see arch/arm/mach-sunxi/dram* in a mainline U-Boot source tree
near you.

>From my experience dealing with the BSP code is a complete waste of time.
>From briefly looking into the github, this release seems to be based on a
2014 U-Boot version, which is outdated beyond all hopes.
If we could find out if the DRAM controller is close to something
existing, we could attempt a mainline port. Apart from the DRAM parts this
is mostly a matter of diligence to sort out the address map and clock bits
and stuff them into the existing code.
See https://lists.denx.de/pipermail/u-boot/2022-January/473568.html for a
recent example, which is actually much bigger, since it also introduces
ARMv5 support to the sunxi port.

> I'm guessing it can't find Boot1 at the location it expects on the SD card. 
> However, I can't seem to find this code in the U-boot sources. When I look 
> through the sources in the Lindenis GitHub repo I only find these strings 
> in binary files. Is this something that Allwinner compiled and only 
> released as a binary?
> 
> Any pointers of where I could look next to troubleshoot this?

Can you try to harvest those bits from an existing (pre-built) binary
image? Or at least compare the output of such a build to see what you are
missing.

Cheers,
Andre

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20220207113051.132bf63c%40donnerap.cambridge.arm.com.