Help understanding SPL and booting
441 views
Skip to first unread message
Peter Watkins
Feb 4, 2022, 9:36:55 PM2/4/22
to linux-sunxi
I'm using a Lindenis v536 SBC. I've built an image, loaded it on an SD 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 0x00000004
[107]the chip id is 0x00000004
[110]the chip id is 0x00000004
[113]the chip id is 0x00000004
[116]the chip id is 0x00000004
[119]chip id check OK
[121]DRAM_VCC set to 1500 mv
[156]Training result is = 000000ff
[159]DRAM training fail !
[195]Training result is = 00000007
[198][AUTO DEBUG]32bit,1 ranks training success!
[236]Training result is = 00000007
[274]Training result is = 00000007
[277]DRAM CLK =792 MHZ
[280]DRAM Type =3 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4)
[318]Training result is = 00000007
[322]Actual DRAM SIZE =1024 M
[325]DRAM SIZE =1024 MBytes, para1 = 000030fa, para2 = 04000000, 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 00000000
[368][mmc]: Wrong media type 0x00000000
[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.
[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 0x00000004
[107]the chip id is 0x00000004
[110]the chip id is 0x00000004
[113]the chip id is 0x00000004
[116]the chip id is 0x00000004
[119]chip id check OK
[121]DRAM_VCC set to 1500 mv
[156]Training result is = 000000ff
[159]DRAM training fail !
[195]Training result is = 00000007
[198][AUTO DEBUG]32bit,1 ranks training success!
[236]Training result is = 00000007
[274]Training result is = 00000007
[277]DRAM CLK =792 MHZ
[280]DRAM Type =3 (3:DDR3,4:DDR4,7:LPDDR3,8:LPDDR4)
[318]Training result is = 00000007
[322]Actual DRAM SIZE =1024 M
[325]DRAM SIZE =1024 MBytes, para1 = 000030fa, para2 = 04000000, 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 00000000
[368][mmc]: Wrong media type 0x00000000
[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.
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?
Andre Przywara
Feb 7, 2022, 6:31:08 AM2/7/22
to Peter Watkins, linux-sunxi
On Fri, 4 Feb 2022 17:33:47 -0800 (PST)
Peter Watkins <watk...@gmail.com> 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?
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
Peter Watkins <watk...@gmail.com> wrote:
Hi Peter,
> I'm using a Lindenis v536 SBC. I've built an image, loaded it on an SD
Shouldn't those contain the magic binary blobs then?
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?
image? Or at least compare the output of such a build to see what you are
missing.
Cheers,
Andre
Peter Watkins
Feb 7, 2022, 12:20:33 PM2/7/22
to Andre Przywara, linux-sunxi
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:
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:
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?
I guess part of what you said is mentioned in the note at the bottom of this wiki page:
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:
…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:
Thanks for all the info and clarification!
-Peter
Andre Przywara
Feb 7, 2022, 1:33:26 PM2/7/22
to Peter Watkins, linux-sunxi
On Mon, 7 Feb 2022 09:20:25 -0800
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 <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 <https://linux-sunxi.org/Boot_Process>
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 <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 <https://github.com/lindenis-org/lindenis-v536-device/blob/master/config/chips/v536/bin/boot0_sdcard_sun8iw16p1_ddr3.bin>?
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 SoC it's probably not too hard, but we still might need to tweak the
mainline code a bit to work with boot0.
The advantage is that for practical purpose you get a recent U-Boot, and
have no issues with mainline kernels. The main problem is that this build
would be not distributable, since you would pair GPL code with a
proprietary blob.
> > 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”.
You might get things working, for some definition of working, but it's
mostly a dead end, and the number of people able and willing to help you
with this mess are limited.
> > 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.
That's quite typical. Most board vendors just take the dirty code
from Allwinner, and add more hacks on top to just get it to work (TM).
> > 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?
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.
> > 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 <https://nstarke.github.io/ghidra/binary/address-offset/2021/06/06/bruteforcing-ghidra-file-offsets.html>
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: ea0000cc b 0x338
and then continues down there:
338: eaffffff b 0x33c
33c: e10f0000 mrs r0, CPSR
340: e3c0001f bic 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 ;-)
Cheers,
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 <http://wiki.lindeni.org/index.php/Lindenis_V536#Downloading>
>
> Yes. I used the code Lindenis supplies for that specific board:
>
> > 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 <https://github.com/lindenis-org/lindenis-v536-device/blob/master/config/chips/v536/bin/boot0_sdcard_sun8iw16p1_ddr3.bin>
> > 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:
>
> 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"
> 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.
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?
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:
>
> 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
> 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.
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:
>
> …for register addresses and values which match what’s in sun8iw16p1_ddr3.bin <https://github.com/lindenis-org/lindenis-v536-device/blob/master/config/chips/v536/bin/boot0_sdcard_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 SoC it's probably not too hard, but we still might need to tweak the
mainline code a bit to work with boot0.
The advantage is that for practical purpose you get a recent U-Boot, and
have no issues with mainline kernels. The main problem is that this build
would be not distributable, since you would pair GPL code with a
proprietary blob.
> > 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”.
mostly a dead end, and the number of people able and willing to help you
with this mess are limited.
> > 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.
from Allwinner, and add more hacks on top to just get it to work (TM).
> > 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?
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.
> > 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:
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: ea0000cc b 0x338
and then continues down there:
338: eaffffff b 0x33c
33c: e10f0000 mrs r0, CPSR
340: e3c0001f bic 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 ;-)
Cheers,
Andre
Peter Watkins
Feb 7, 2022, 6:10:50 PM2/7/22
to Andre Przywara, linux-sunxi
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)
[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)
[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: ea0000cc b 0x338
and then continues down there:
338: eaffffff b 0x33c
33c: e10f0000 mrs r0, CPSR
340: e3c0001f bic 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_00000338 XREF[1]: 00000000(j)
00000338 ff ff ff ea b LAB_0000033c
LAB_0000033c XREF[1]: 00000338(j)
0000033c 00 00 0f e1 mrs r0,cpsr
00000340 1f 00 c0 e3 bic r0,r0,#ARMV7_MODE_MASK
00000344 13 00 80 e3 orr r0,r0,#ARMV7_SVC_MODE
00000348 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.
0000034c 02 0c c0 e3 bic r0,r0,#ARMV7_CC_E_BIT // set little-endian
00000350 00 f0 21 e1 msr cpsr_c,r0
;// configure memory system : disable MMU,cache and write buf
00000354 10 0f 11 ee mrc p15,0x0,r0,cr1,cr0,0x0
00000358 02 0a c0 e3 bic r0,r0,#0x2000
0000035c 07 00 c0 e3 bic r0,r0,#( ARMV7_C1_M_BIT | ARMV7_C1_A_BIT | ARM
00000360 02 0b 80 e3 orr r0,r0,#0x800
00000364 01 0a c0 e3 bic r0,r0,#0x1000
00000368 10 0f 01 ee mcr p15,0x0,r0,cr1,cr0,0x0
// set SP for C language
0000036c 24 d0 9f e5 ldr sp,[BOOT0_STACK_BOTTOM] = 00058800h
00000370 01 00 00 eb bl FUN_0000037c undefined FUN_0000037c()
00000374 bf 0d 00 fa blx FUN_00003a78 undefined FUN_00003a78()
00000378 f7 0d 00 fa blx FUN_00003b5c undefined FUN_00003b5c()
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
Andre Przywara
Feb 8, 2022, 7:51:28 PM2/8/22
to Peter Watkins, linux-sunxi
On Mon, 7 Feb 2022 15:10:45 -0800
> From an earlier email:
> > See https://lists.denx.de/pipermail/u-boot/2022-January/473568.html <https://lists.denx.de/pipermail/u-boot/2022-January/473568.html> for a
should clean that up. However this is one of the bad examples, since it
needs to move code around to accommodate a new ARM architecture
revision. Support for a new 32-bit v7 SoC should be much easier.
> > 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.
This is actually a good argument for mainline: we use the very same
image for all boot media: SD card, eMMC, SPI flash, FEL.
> 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.
I see. And this is the part were I reckon reverse engineering this is
not worth the time: You will decode some weird image format that
Allwinner came up with (and they like to change that!), and which is
totally irrelevant for mainline operation. There is nothing in the
hardware that would dictate this format, it's a pure invention from the
slightly misguided software troops in AW.
> > 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: ea0000cc b 0x338
> > and then continues down there:
> > 338: eaffffff b 0x33c
> > 33c: e10f0000 mrs r0, CPSR
> > 340: e3c0001f bic 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.
Really? I didn't see any post, also nothing in the logs. You are
watkipet, I guess? Please note that OFTC and the channel setup requires
you to be authenticated to post something.
> Your disassembly helped. So far I have this in Ghidra:
>
> LAB_00000338 XREF[1]: 00000000(j)
> 00000338 ff ff ff ea b LAB_0000033c
> LAB_0000033c XREF[1]: 00000338(j)
> 0000033c 00 00 0f e1 mrs r0,cpsr
> 00000340 1f 00 c0 e3 bic r0,r0,#ARMV7_MODE_MASK
> 00000344 13 00 80 e3 orr r0,r0,#ARMV7_SVC_MODE
> 00000348 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.
> 0000034c 02 0c c0 e3 bic r0,r0,#ARMV7_CC_E_BIT // set little-endian
> 00000350 00 f0 21 e1 msr cpsr_c,r0
> ;// configure memory system : disable MMU,cache and write buf
> 00000354 10 0f 11 ee mrc p15,0x0,r0,cr1,cr0,0x0
> 00000358 02 0a c0 e3 bic r0,r0,#0x2000
> 0000035c 07 00 c0 e3 bic r0,r0,#( ARMV7_C1_M_BIT | ARMV7_C1_A_BIT | ARM
> 00000360 02 0b 80 e3 orr r0,r0,#0x800
> 00000364 01 0a c0 e3 bic r0,r0,#0x1000
> 00000368 10 0f 01 ee mcr p15,0x0,r0,cr1,cr0,0x0
> // set SP for C language
> 0000036c 24 d0 9f e5 ldr sp,[BOOT0_STACK_BOTTOM] = 00058800h
> 00000370 01 00 00 eb bl FUN_0000037c undefined FUN_0000037c()
> 00000374 bf 0d 00 fa blx FUN_00003a78 undefined FUN_00003a78()
> 00000378 f7 0d 00 fa blx FUN_00003b5c undefined FUN_00003b5c()
>
>
> 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.
See above, you are mostly wasting your time deciphering a non-trivial
image format. Actually the BSP should at least produce some working
image, albeit with their old and somewhat broken code base.
To be honest, looking at disassembly for this task will mostly give you
headaches. I'd would rather try to look at a working image, and stare at
the hexdump to make sense of the image format. At offset 0x10 you will
see the boot0 size, if you fast forward behind that (0xe000), you might
see some data structures with IDs, offsets, sizes. Then check to see
what's different in your image. Looking out for "boot-pkg" might help.
Cheers,
Andre
> From an earlier email:
> > See https://lists.denx.de/pipermail/u-boot/2022-January/473568.html <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.
Yeah, support for new SoCs *can* be a bit daunting, I always feel we
> > 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.
should clean that up. However this is one of the bad examples, since it
needs to move code around to accommodate a new ARM architecture
revision. Support for a new 32-bit v7 SoC should be much easier.
> > 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.
image for all boot media: SD card, eMMC, SPI flash, FEL.
> 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.
not worth the time: You will decode some weird image format that
Allwinner came up with (and they like to change that!), and which is
totally irrelevant for mainline operation. There is nothing in the
hardware that would dictate this format, it's a pure invention from the
slightly misguided software troops in AW.
> > 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: ea0000cc b 0x338
> > and then continues down there:
> > 338: eaffffff b 0x33c
> > 33c: e10f0000 mrs r0, CPSR
> > 340: e3c0001f bic 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.
watkipet, I guess? Please note that OFTC and the channel setup requires
you to be authenticated to post something.
> Your disassembly helped. So far I have this in Ghidra:
>
> LAB_00000338 XREF[1]: 00000000(j)
> 00000338 ff ff ff ea b LAB_0000033c
> LAB_0000033c XREF[1]: 00000338(j)
> 0000033c 00 00 0f e1 mrs r0,cpsr
> 00000340 1f 00 c0 e3 bic r0,r0,#ARMV7_MODE_MASK
> 00000344 13 00 80 e3 orr r0,r0,#ARMV7_SVC_MODE
> 00000348 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.
> 0000034c 02 0c c0 e3 bic r0,r0,#ARMV7_CC_E_BIT // set little-endian
> 00000350 00 f0 21 e1 msr cpsr_c,r0
> ;// configure memory system : disable MMU,cache and write buf
> 00000354 10 0f 11 ee mrc p15,0x0,r0,cr1,cr0,0x0
> 00000358 02 0a c0 e3 bic r0,r0,#0x2000
> 0000035c 07 00 c0 e3 bic r0,r0,#( ARMV7_C1_M_BIT | ARMV7_C1_A_BIT | ARM
> 00000360 02 0b 80 e3 orr r0,r0,#0x800
> 00000364 01 0a c0 e3 bic r0,r0,#0x1000
> 00000368 10 0f 01 ee mcr p15,0x0,r0,cr1,cr0,0x0
> // set SP for C language
> 0000036c 24 d0 9f e5 ldr sp,[BOOT0_STACK_BOTTOM] = 00058800h
> 00000370 01 00 00 eb bl FUN_0000037c undefined FUN_0000037c()
> 00000374 bf 0d 00 fa blx FUN_00003a78 undefined FUN_00003a78()
> 00000378 f7 0d 00 fa blx FUN_00003b5c undefined FUN_00003b5c()
>
>
> 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.
image format. Actually the BSP should at least produce some working
image, albeit with their old and somewhat broken code base.
To be honest, looking at disassembly for this task will mostly give you
headaches. I'd would rather try to look at a working image, and stare at
the hexdump to make sense of the image format. At offset 0x10 you will
see the boot0 size, if you fast forward behind that (0xe000), you might
see some data structures with IDs, offsets, sizes. Then check to see
what's different in your image. Looking out for "boot-pkg" might help.
Cheers,
Andre
Reply all
Reply to author
Forward
0 new messages