On Fri, 4 Feb 2022 17:33:47 -0800 (PST) Peter Watkins <[email protected]> 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 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. 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 [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/20220207113051.132bf63c%40donnerap.cambridge.arm.com.
