Android no NW - i.MX53 QSB
stefan.kalkowski at ...1...
Mon May 9 14:38:50 CEST 2016
On 05/09/2016 11:40 AM, Tiago Brito wrote:
> Hi, I'm trying to boot Android in the Normal World of an i.MX53 QSB using
> U-boot in the Secure World as the bootloader.
> I've adapted U-boot in order to switch to Normal World upon a SMC call.
> The Android version I'm using is Adeneo BSP for Android Gingerbread v4.3.
> Android boots fine when I disable the world switch in U-boot, but when I
> try to boot it in the Normal World it freezes in a Kernel Panic before
> running the Init.
> I followed the patch made by Stefan Kalkowski (as suggested in
> https://community.freescale.com/thread/308152 ) because I was experiencing
> a similar problem (FAILED TO RELEASE IRAM PARTITION). Unlike Miao Yu in
> that post my execution didn't stop there.
> I thought this would be enough to run Android in the Secure World (because
> this is what Stefan did) but apparently it didn't work.
> The problem remains the same.
> What happens is the kernel boots successfully and then the following flow
> (1) init_post() at kernel/init/main.c:826
> (2) run_init_process() at kernel/init/main.c:817
> (3) kernel_execve() at kernel/arch/arm/kernel/sys_arm.c:81
> Inside kernel_execve() when we return to user space by manipulating the
> kernel stack (asm code below) it lauches a Kernel Panic and init is never
> ASM CODE:
> "b ret_to_user"
> : "r" (current_thread_info()),
> "Ir" (THREAD_START_SP - sizeof(regs)),
> "r" (®s),
> "Ir" (sizeof(regs))
> : "r0", "r1", "r2", "r3", "ip", "lr", "memory");
> In addition we noticed that the execution jumps to do_undefinstr at
> b do_undefinstr
> Besides this we confirmed that init is never executed by adding a print to
> init's main function (src/system/core/init/init.c:713).
I do not see any relation to the Genode OS framework following your
setup. Would you be so kind to respect the topic of this mailing list?
Just a short remark: not seeing any "printf" results from init does not
mean that no init code is executed at all, it could be one the
instructions in the call-trace of "printf", which caused the undefined
instruction. If you notice that the undefined instruction handler of
Linux is called, maybe you can get the values of SPSR_UND (saved program
status register of undefined mode) and LR_UND (link register of
undefined mode). Those values hint you what instruction (LR == former
instrcution pointer; SPSR gives you former execution mode) caused the
> Thanks, Tiago Brito
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> genode-main mailing list
> genode-main at lists.sourceforge.net
http://www.genode-labs.com/ · http://genode.org/
More information about the users