On Mon, 7 Feb 2022 15:10:45 -0800 Peter Watkins <watki...@gmail.com> wrote:
Hi Peter, > 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 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 -- 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/20220209005106.76f4a425%40slackpad.lan.
