[U-Boot] [issue report] mainline u-boot was stuck before booting kernel

[Sandy Patterson]

Ah, thanks. Your debugging looks the same as what I've seen from printf
debugging. I'll try to verify though.

On Mon, Jul 25, 2016 at 10:58 AM, Ziyuan Xu <xzy.xu at rock-chips.com> wrote:

> hi Stany,
>
> The difference is that you print out assertion log.
>
> Reset not supported on this platform
> ### ERROR ### Please RESET the board ###
>
> You can add show_boot_progress() function in your bsp file to find out
> something.
> #define CONFIG_SHOW_BOOT_PROGRESS
> void show_boot_progress(int progress)
> {
>     printf("Boot reached stage %d\n", progress);
>
> }
>
>
> On 2016年07月25日 22:12, Ziyuan Xu wrote:
>
>> Hi All,
>>
>> I'm sorry to tell you that I failed to boot linux kernel with the
>> mainline u-boot on rk3288 board(both evb-rk3288 & fennec-rk3288). It was
>> stuck in cleanup_before_linux() before jumping to linux, and the
>> boot_stage_flag is BOOTSTAGE_ID_BOOTM_HANDOFF.
>>
>> ## Current stack ends at 0x7df638b0 *  kernel: cmdline image address =
>> 0x02000000
>> ## No init Ramdisk
>>    ramdisk start = 0x00000000, ramdisk end = 0x00000000
>> ## No Flattened Device Tree
>> Continuing to boot without FDT
>> Initial value for argc=3
>> Final value for argc=3
>> using: ATAGS
>> ## Transferring control to Linux (at address 02000000)...
>>
>> Starting kernel ...
>>
>> With the further investigation, it never returnned back from
>> invalidate_dcache_all(). I mean that I can't reach stage 4 as below.
>>
>> cleanup_before_linux
>>     ==>cleanup_before_linux_select
>>         ==>1.disable_interrupts
>>         ==>2.dcache_disable
>>         ==>3.invalidate_dcache_all
>>         ==>4.icache_disable
>>
>> Debug further, invalidate_dcache_all  invalidate all cache one-by-one
>> which cache type is DATA_ONLY, INSTRUCTION_DATA or UNIFIED. And invalidate
>> way from one set to another set in order. The problem is that the PC ran
>> away in invalidate way loop  [cache level L1!!!].
>>
>> I add some serial output code in __v7_flush_dcache_all to figure out the
>> bog.
>> I expect:
>> Print the value of r9 in sequence, e.g 0x7f, 0x7e, 0x7d..... 0x01, 0x00
>> (hex)
>> In fact, print the value of r9 in sequence at first, but print unexpected
>> value afterwards.   e.g 0x7f, 0x7e, 0x7d, ..,0x73, 0x40, 0x85,....
>>
>> ENTRY(__v7_flush_dcache_all)
>> [snip]
>> loop1:
>>     mov    r9, r7                @ create working copy of max index
>> loop2:
>> +      stmfd    sp!, {r0}
>> +      ldr     r0, =0xff690000
>> +      str     r9, [r0]
>> +      ldmfd    sp!, {r0}
>>  ARM(    orr    r11, r10, r4, lsl r5    )    @ factor way and cache
>> number into r11
>>  THUMB(    lsl    r6, r4, r5        )
>>  THUMB(    orr    r11, r10, r6        )    @ factor way and cache number
>> into r11
>>  ARM(    orr    r11, r11, r9, lsl r2    )    @ factor index number into
>> r11
>>  THUMB(    lsl    r6, r9, r2        )
>>  THUMB(    orr    r11, r11, r6        )    @ factor index number into r11
>>     mcr    p15, 0, r11, c7, c14, 2        @ clean & invalidate by set/way
>>     subs    r9, r9, #1            @ decrement the index
>>     bge    loop2
>>     subs    r4, r4, #1            @ decrement the way
>>     bge    loop1
>> skip:
>> ENDPROC(__v7_flush_dcache_all)
>>
>> I don't have the jtag, hence I can't address the current pc. I have no
>> doubt that if any glitches in __v7_flush_dcache_all, I reviewed several
>> times, also copy kernel's implement to here. :-( No effect.
>> A more interesting thing is that Sandy had report it.  He and I have
>> similar problem. Everything work fine after I applied his patches, or
>> disable dcache(active CONFIG_SYS_DCACHE_OFF).
>> @Stany, I'm sorry that I disable dcache during hack.. That was a
>> mistake:-(
>>
>> @Simon & hieko,
>> Can you boot linux with the mainline u-boot? have a try?
>>
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>>
>>
>>
>
>
>