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