From patchwork Tue Jul 26 06:30:13 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Xu Ziyuan X-Patchwork-Id: 652615 X-Patchwork-Delegate: trini@ti.com Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from theia.denx.de (theia.denx.de [85.214.87.163]) by ozlabs.org (Postfix) with ESMTP id 3rz7Y86NGHz9ssM for ; Tue, 26 Jul 2016 16:30:52 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 72215A78DA; Tue, 26 Jul 2016 08:30:51 +0200 (CEST) Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kl4-I2H2p7BJ; Tue, 26 Jul 2016 08:30:51 +0200 (CEST) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id DCD95A7537; Tue, 26 Jul 2016 08:30:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 0A18EA7537 for ; Tue, 26 Jul 2016 08:30:48 +0200 (CEST) Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFdTjN0Bjj14 for ; Tue, 26 Jul 2016 08:30:47 +0200 (CEST) X-policyd-weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 (only DNSBL check requested) Received: from regular1.263xmail.com (regular1.263xmail.com [211.150.99.135]) by theia.denx.de (Postfix) with ESMTPS id 2D545A7531 for ; Tue, 26 Jul 2016 08:30:43 +0200 (CEST) Received: from xzy.xu?rock-chips.com (unknown [192.168.167.232]) by regular1.263xmail.com (Postfix) with SMTP id F1B911E28C; Tue, 26 Jul 2016 14:30:37 +0800 (CST) X-263anti-spam: KSV:0; X-MAIL-GRAY: 0 X-MAIL-DELIVERY: 1 X-KSVirus-check: 0 X-ABS-CHECKED: 4 X-ADDR-CHECKED: 0 Received: from [172.16.22.217] (localhost.localdomain [127.0.0.1]) by smtp.263.net (Postfix) with ESMTP id 0DD174080; Tue, 26 Jul 2016 14:30:15 +0800 (CST) X-RL-SENDER: xzy.xu@rock-chips.com X-FST-TO: huangtao@rock-chips.com X-SENDER-IP: 103.29.142.67 X-LOGIN-NAME: xzy.xu@rock-chips.com X-UNIQUE-TAG: <06e3a0b2df9a1305a72edc09461c82a3> X-ATTACHMENT-NUM: 0 X-SENDER: xzy.xu@rock-chips.com X-DNS-TYPE: 0 Received: from [172.16.22.217] (unknown [103.29.142.67]) by smtp.263.net (Postfix) whith ESMTP id 4270OFU6N0; Tue, 26 Jul 2016 14:30:27 +0800 (CST) Message-ID: <57970375.2000300@rock-chips.com> Date: Tue, 26 Jul 2016 14:30:13 +0800 From: Ziyuan Xu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Sandy Patterson References: <57961E42.6010506@rock-chips.com> <5796292D.3010908@rock-chips.com> In-Reply-To: Cc: "Huang, Tao" , Tom Rini , U-Boot Mailing List , Kever Yang , Eddie Cai Subject: Re: [U-Boot] [issue report] mainline u-boot was stuck before booting kernel X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.15 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" Dear All, I add the ISB operation after dcache_disable(), and I can jump to linux kernel entry.:-) there may Sounds crazy. In fact, there is already an 'ISB' operation in set_cr() which to disable dcache and MMU. But it just tell processor that memory had change, not real ISB for armv7. dcache_disable ==>flush_dcache_all() ==>set_cr() disable dcache and MMU. #define isb() __asm__ __volatile__ ("" : : : "memory") static inline void set_cr(unsigned int val) { if (is_hyp()) asm volatile("mcr p15, 4, %0, c1, c0, 0 @ set CR" : : "r" (val) : "cc"); else asm volatile("mcr p15, 0, %0, c1, c0, 0 @ set CR" : : "r" (val) : "cc"); isb(); } I also find something in ARM cortex-A17 TRM. ==>"Disable the MMU from the each processor followed by an ISB to ensure the MMU disable operation is complete, then followed by a DSB to drain previous memory transactions." In my humble opinion, maybe instructions tlb had alter, and cause running away??? I'm not sure about it. @Sandy, could you have a try with my update? @Simon, did you hit this glitch? I hope you can help ...:-) On 2016年07月25日 23:00, Sandy Patterson wrote: > 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 > 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@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > > > > > > > diff --git a/arch/arm/cpu/armv7/cpu.c b/arch/arm/cpu/armv7/cpu.c index 6eac5ef..5cc09ba 100644 --- a/arch/arm/cpu/armv7/cpu.c +++ b/arch/arm/cpu/armv7/cpu.c @@ -43,6 +43,7 @@ int cleanup_before_linux_select(int flags) */ dcache_disable(); v7_outer_cache_disable(); + ISB; /* * After D-cache is flushed and before it is disabled