On Mon, 7 Feb 2022 09:20:25 -0800 Peter Watkins <watki...@gmail.com> 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 > <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 > > <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 > <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> > > 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 > <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>? > 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”. 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 -- 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/20220207183319.47680808%40donnerap.cambridge.arm.com.
