All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ziyuan Xu <xzy.xu@rock-chips.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [issue report] mainline u-boot was stuck before booting kernel
Date: Mon, 25 Jul 2016 22:58:53 +0800	[thread overview]
Message-ID: <5796292D.3010908@rock-chips.com> (raw)
In-Reply-To: <57961E42.6010506@rock-chips.com>

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
>
>
>

  reply	other threads:[~2016-07-25 14:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-25 14:12 [U-Boot] [issue report] mainline u-boot was stuck before booting kernel Ziyuan Xu
2016-07-25 14:58 ` Ziyuan Xu [this message]
2016-07-25 15:00   ` Sandy Patterson
2016-07-26  6:30     ` Ziyuan Xu
2016-07-26  6:32       ` Ziyuan Xu
2016-07-26 12:15       ` Ziyuan Xu
2016-07-26 13:16         ` Sandy Patterson
2016-07-26 13:47           ` Ziyuan Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5796292D.3010908@rock-chips.com \
    --to=xzy.xu@rock-chips.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.