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
>
>
>
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox