Hi 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.
> 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)
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.
> 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
--
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/D685A1FE-B7AF-4E38-9883-753E49C7316C%40gmail.com.
