Re: [U-Boot] u-boot: x86: interrupt mapping
Hi Christian, On 20.07.2016 10:22, Christian Gmeiner wrote: Hi Jian, I took some time to recall what I did by patching FSP: - search in every PE32 and TE image section for binary sequence 81c900018908c6460e01 and change to 81c9000102008908c6460e00 In the meantime I started by patching out every access to the uart bar, with the same result as I get with your patching strategy. - then replace them in-place So here is the next interesting problem. During fsp_init it looks like fsp copies itself to ram (IP 0xFFFD1C6C vs 0x3F5F64E1) and here it does a busy loop :( I don't think it's a busy loop. This Bug?: https://patchwork.ozlabs.org/patch/446555/ At what place do you do the in-place patching? I hoped to do it at init_board setup. I mean in UEFITool select the "PE32 image section", right click "Extract body", do binary patching using your favorite hex editor, right click "Replace body". The difference can be better understand if disassemblies are compared, eg: Disassembly of section .data: @@ -3367,9 +3367,9 @@ 25fc:05 00 05 00 00 add$0x500,%eax 2601:8b 08mov(%eax),%ecx 2603:81 e1 ff ff f8 ffand$0xfff8,%ecx -2609:81 c9 00 01 00 00or $0x100,%ecx +2609:81 c9 00 01 02 00or $0x20100,%ecx What I did here is setting BAUDSEL to SYS_25MHz. 260f:89 08mov%ecx,(%eax) -2611:c6 46 0e 01 movb $0x1,0xe(%esi) +2611:c6 46 0e 00 movb $0x0,0xe(%esi) Can't recall why I did this, maybe bypassing PLL altogether? 2615:c6 46 0f 00 movb $0x0,0xf(%esi) 2619:c6 46 03 83 movb $0x83,0x3(%esi) 261d:c6 46 01 00 movb $0x0,0x1(%esi) Since I don't rely on Topcliff UART for output, the baud rate recalculation is all skipped. The same here... I am using a pci fpga based uart. Maybe you can try the fsp.bin I sent, to see if it runs Since it's a bit off-topic, should we exchange information w/o ccing the list? Best regards, *Jian Luo DC-IA/EAH2* Tel. +49(9352)18-4266 *Be**QIK * ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot: x86: interrupt mapping
Hi Christian, I took some time to recall what I did by patching FSP: - search in every PE32 and TE image section for binary sequence 81c900018908c6460e01 and change to 81c9000102008908c6460e00 - then replace them in-place The difference can be better understand if disassemblies are compared, eg: Disassembly of section .data: @@ -3367,9 +3367,9 @@ 25fc:05 00 05 00 00 add$0x500,%eax 2601:8b 08mov(%eax),%ecx 2603:81 e1 ff ff f8 ffand$0xfff8,%ecx -2609:81 c9 00 01 00 00or $0x100,%ecx +2609:81 c9 00 01 02 00or $0x20100,%ecx What I did here is setting BAUDSEL to SYS_25MHz. 260f:89 08mov%ecx,(%eax) -2611:c6 46 0e 01 movb $0x1,0xe(%esi) +2611:c6 46 0e 00 movb $0x0,0xe(%esi) Can't recall why I did this, maybe bypassing PLL altogether? 2615:c6 46 0f 00 movb $0x0,0xf(%esi) 2619:c6 46 03 83 movb $0x83,0x3(%esi) 261d:c6 46 01 00 movb $0x0,0x1(%esi) Since I don't rely on Topcliff UART for output, the baud rate recalculation is all skipped. Best regards, *Jian Luo DC-IA/EAH2* Tel. +49(9352)18-4266 *Be**QIK * On 19.07.2016 17:21, Christian Gmeiner wrote: Hi Jian, For the moment I have no answer to this question. I need to dive into the vxworks code, which is not what I like to do now (but needs to be done)- Yes, please do track it down. The interrupt line register configured by U-Boot should be enough for VxWorks to function under PIC mode. I have an other (wired) question you may could help out. http://www.mouser.com/pdfdocs/Intel_Platform_Controller_Hub_EG20T_datasheet.pdf (page 124) On my development board the uart_clk is connected to a oscillator and everything works as expected. But on the production devices the uart_clk is not connected and fsp hangs with post code 0x2e. I am not sure about the meaning of post code 0x2e. Jian has some working experience on Atom E6xx with U-Boot. Adding him. 0x2e == POST_PRE_MRC (arch/x86/include/asm/post.h) Now I would like to change the initial mux settings to use usb_48mhz but I am quite sure that I need to have the pci bus and its devices initialised already in order to change the CLKCFG register. Do you think there is an other way of accessing this register like fixed memory address etc? Which register do you want to program for this uart_clk? If it's on the PCI configuration space, you can use PCI config APIs to program. There a handful of registers I would need to program but all of them are accessible via pic config space. E.g CLKCFG: Size: 32-bit Default: 2C00 Power Well: Core Access PCI Configuration B:D:F D0:F0 Offset Start: Offset End: 500h 503h Memory Mapped I/O BAR: PKTHubCTLBASE Offset: 500h As I need to program those registers before fsp_init I must setup the pci bus by myself, change the register values and call fsb_init routine. Correct? My board had this problem too. I however toke a different approach by patching the original FSP. The waiting for Topcliff UART ready is completely bypassed in all UEFI blobs. You can use UEFITool [1] to extract blobs in the attached FSP for comparison. Sooo... I did use the UEFITool to compare your fsp with mine and yeah... some files are different. File_Raw_06A70056_3D0F_4A94_A743_5491CC9391D3_body.bin Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_body.bin Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_header.bin Section_PE32_image_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_body.bin Section_PE32_image_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_body.bin Section_TE_image_1BA0062E_C779_4582_8566_336AE8F78F09_Volume_Top_File_body.bin Section_TE_image_52C05B14_0B98_496C_BC3B_04B50211D680_PeiCore_body.bin Section_TE_image_86D70125_BAA3_4296_A62F_602BEBBB9081_DxeIpl_body.bin Section_TE_image_9618C0DC_50A4_496C_994F_7241F282ED01_PlatformEarlyInit_body.bin Section_TE_image_9B3ADA4F_AE56_4C24_8DEA_F03B7558AE50_PcdPeim_body.bin Section_TE_image_D2C69B26_82E1_4A1B_AD35_ED0261B9F347_MemoryInitPei_body.bin File_PEI_module_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt File_PEI_module_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_info.txt File_PEI_module_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_info.txt Section_Compressed_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt Section_Compressed_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_info.txt Section_Compressed_74D3B506_EE9C_47ED_B749_41261401DA78_TCInitDxe_info.txt Section_PE32_image_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt Section_PEI_dependency_47EA2673_2533_4C07_AABA_69CE5A7C5D35_PlatformLateInit_info.txt Section_PEI_dependency_4D1F48D8_0498_4C09_8EDE_72F30B58B1F2_MpInit_info.txt Any hint at what to look for? Sadly I am not an UEFI guy. gree
Re: [U-Boot] u-boot: x86: interrupt mapping
Hi Bin, On 19.07.2016 10:10, Bin Meng wrote: Hi Jian, On Tue, Jul 19, 2016 at 4:03 PM, Jian Luo wrote: Hallo Christian, On 19.07.2016 08:02, Christian Gmeiner wrote: Hi Bin For the moment I have no answer to this question. I need to dive into the vxworks code, which is not what I like to do now (but needs to be done)- Yes, please do track it down. The interrupt line register configured by U-Boot should be enough for VxWorks to function under PIC mode. I have an other (wired) question you may could help out. http://www.mouser.com/pdfdocs/Intel_Platform_Controller_Hub_EG20T_datasheet.pdf (page 124) On my development board the uart_clk is connected to a oscillator and everything works as expected. But on the production devices the uart_clk is not connected and fsp hangs with post code 0x2e. I am not sure about the meaning of post code 0x2e. Jian has some working experience on Atom E6xx with U-Boot. Adding him. 0x2e == POST_PRE_MRC (arch/x86/include/asm/post.h) Now I would like to change the initial mux settings to use usb_48mhz but I am quite sure that I need to have the pci bus and its devices initialised already in order to change the CLKCFG register. Do you think there is an other way of accessing this register like fixed memory address etc? Which register do you want to program for this uart_clk? If it's on the PCI configuration space, you can use PCI config APIs to program. There a handful of registers I would need to program but all of them are accessible via pic config space. E.g CLKCFG: Size: 32-bit Default: 2C00 Power Well: Core Access PCI Configuration B:D:F D0:F0 Offset Start: Offset End: 500h 503h Memory Mapped I/O BAR: PKTHubCTLBASE Offset: 500h As I need to program those registers before fsp_init I must setup the pci bus by myself, change the register values and call fsb_init routine. Correct? My board had this problem too. I however toke a different approach Great, I got you :) by patching the original FSP. The waiting for Topcliff UART ready is How did you patch the original FSP? Did you reverse engineering the FSP? Only at where it hangs. With the help of an ECM-XDP3 Debugger. Then I made a wild guess that in all compressed PE32 sections have the same problem. Yepp, dirty hack. completely bypassed in all UEFI blobs. You can use UEFITool [1] to extract blobs in the attached FSP for comparison. greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner [1] https://github.com/LongSoft/UEFITool Regards, Bin Best regards, *Jian Luo DC-IA/EAH2* Tel. +49(9352)18-4266 *Be**QIK * ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/8] Better support of booting VxWorks via 'bootvx'
Hi, please add Tested-by: Jian Luo on crownbay Best regards, Jian Luo On 24.09.2015 11:21, Bin Meng wrote: > This series adds better support of booting VxWorks using 'bootvx'. > > Tested by booting a VxWorks 6.9.4 kernel on Intel Crown Bay, and > a VxWorks 7 kernel on Intel Galileo. > > > Bin Meng (8): > x86: Initialize GDT entry 1 to be the 32-bit CS as well > cmd: Convert CONFIG_CMD_ELF to Kconfig > cmd: Clean up cmd_elf a little bit > cmd: elf: Reorder load_elf_image_phdr() and load_elf_image_shdr() > cmd: bootvx: Pass netmask and gatewayip to VxWorks bootline > cmd: bootvx: Always get VxWorks bootline from env > cmd: bootvx: Pass E820 information to an x86 VxWorks kernel > doc: Complement document about booting VxWorks > > README | 12 +- > arch/x86/cpu/cpu.c | 7 +- > common/Kconfig | 6 + > common/cmd_elf.c| 404 +--- > configs/A10-OLinuXino-Lime_defconfig| 2 +- > configs/Bananapi_defconfig | 2 +- > configs/Bananapro_defconfig | 2 +- > configs/Chuwi_V7_CW0825_defconfig | 2 +- > configs/M5208EVBE_defconfig | 2 +- > configs/M52277EVB_defconfig | 2 +- > configs/M5235EVB_defconfig | 2 +- > configs/M5272C3_defconfig | 2 +- > configs/M5275EVB_defconfig | 2 +- > configs/M5282EVB_defconfig | 2 +- > configs/M53017EVB_defconfig | 2 +- > configs/M5329AFEE_defconfig | 2 +- > configs/M5329BFEE_defconfig | 2 +- > configs/M5373EVB_defconfig | 2 +- > configs/M54418TWR_defconfig | 2 +- > configs/M54418TWR_nand_mii_defconfig| 2 +- > configs/M54418TWR_nand_rmii_defconfig | 2 +- > configs/M54418TWR_nand_rmii_lowfreq_defconfig | 2 +- > configs/M54418TWR_serial_mii_defconfig | 2 +- > configs/M54418TWR_serial_rmii_defconfig | 2 +- > configs/M54451EVB_defconfig | 2 +- > configs/M54455EVB_defconfig | 2 +- > configs/M5475AFE_defconfig | 2 +- > configs/M5475BFE_defconfig | 2 +- > configs/M5475CFE_defconfig | 2 +- > configs/M5475DFE_defconfig | 2 +- > configs/M5475EFE_defconfig | 2 +- > configs/M5475FFE_defconfig | 2 +- > configs/M5475GFE_defconfig | 2 +- > configs/M5485AFE_defconfig | 2 +- > configs/M5485BFE_defconfig | 2 +- > configs/M5485CFE_defconfig | 2 +- > configs/M5485DFE_defconfig | 2 +- > configs/M5485EFE_defconfig | 2 +- > configs/M5485FFE_defconfig | 2 +- > configs/M5485GFE_defconfig | 2 +- > configs/M5485HFE_defconfig | 2 +- > configs/MPC8349ITXGP_defconfig | 2 +- > configs/MPC8349ITX_LOWBOOT_defconfig| 2 +- > configs/MPC8349ITX_defconfig| 2 +- > configs/MSI_Primo81_defconfig | 2 +- > configs/Mini-X_defconfig| 2 +- > configs/PATI_defconfig | 2 +- > configs/UCP1020_defconfig | 2 +- > configs/VCMA9_defconfig | 2 +- > configs/Wexler_TAB7200_defconfig| 2 +- > configs/ac14xx_defconfig| 2 +- > configs/alt_defconfig | 2 +- > configs/am335x_boneblack_defconfig | 2 +- > configs/am335x_gp_evm_defconfig | 1 - > configs/am335x_sl50_defconfig | 1 - > configs/am3517_crane_defconfig | 2 +- > configs/am3517_evm_defconfig| 2 +- > configs/amcore_defconfig| 2 +- > configs/apalis_t30_defconfig| 4 +- > configs/apf27_defconfig | 2 +- > configs/arcangel4-be_defconfig | 2 +- > configs/arcangel4_defconfig | 4 +- > configs/arndale_defconfig | 4 +- > configs/astro_mcf5373l_defconfig| 2 +- > configs/at91rm9200ek_defconfig | 2 +- > configs/at91rm9200ek_ram_defconfig |
Re: [U-Boot] [PATCH] arm: socfpga: dm: Fix DM initialization failure after warm reset
Hi Dinh, Hi Marek, any updates on this issue? Best regards, Jian Luo On 04.09.2015 16:32, Marek Vasut wrote: > On Friday, September 04, 2015 at 04:26:46 PM, Simon Glass wrote: >> On 4 September 2015 at 08:25, Marek Vasut wrote: >>> On Friday, September 04, 2015 at 04:16:21 PM, Simon Glass wrote: >>>> Hi, >>>> >>>> On 4 September 2015 at 01:36, Jian Luo wrote: >>>>> Hi Simon, >>>>> >>>>> On 04.09.2015 02:23, Simon Glass wrote: >>>>>> Hi, >>>>>> >>>>>> On 3 September 2015 at 05:14, Marek Vasut wrote: >>>>>>> On Thursday, September 03, 2015 at 01:12:03 PM, Jian Luo wrote: >>>>>>>> On 03.09.2015 12:46, Marek Vasut wrote: >>>>>>>> > On Thursday, September 03, 2015 at 12:17:13 PM, Jian Luo wrote: >>>>>>>> > >>>>>>>> > Hi! >>>>>>>> > >>>>>>>> > [...] >>>>>>>> > >>>>>>>> >> >> Yes, I can. But U-Boot can still have problem with other >>>>>>>> >> >> Image which disables ECC. >>>>>>>> >> >> I found another post related to this problem >>>>>>>> >> >> https://lkml.org/lkml/2015/2/6/685 . >>>>>>>> >> >> >>>>>>>> >> >> Quote: To initialize ECC, the OCRAM needs to enable >>>>>>>> >> >> ECC >>>>>>>> >>>>>>>> then clear >>>>>>>> >>>>>>>> >> >> the entire >>>>>>>> >> >> >>>>>>>> >> >> memory to zero before using it. >>>>>>>> >> >>>>>>>> >> Hi! >>>>>>>> >> >>>>>>>> >> > Oh, but that is a problem, since we're running from the >>>>>>>> >> > OCRAM >>>>>>>> >>>>>>>> ourselves, >>>>>>>> >>>>>>>> >> > thus we cannot clear the OCRAM. Maybe we should >>>>>>>> >> > force-disable the ECC instead? But can we be sure that the >>>>>>>> >> > corruption does not >>>>>>>> >>>>>>>> happen >>>>>>>> >>>>>>>> >> > when you disable ECC ? >>>>>>>> >> >>>>>>>> >> Yes, that will be a problem. It's also why I let the >>>>>>>> >> SYSMGR_ECC_OCRAM_EN bit intact in the patch. >>>>>>>> > >>>>>>>> > OK, but what about turning the ECC off in the SPL, will that >>>>>>>> > also >>>>>>>> >>>>>>>> introduce >>>>>>>> >>>>>>>> > corruption or not ? That might be the right fix, no ? >>>>>>>> >>>>>>>> Hi Marek, >>>>>>>> >>>>>>>> Sorry, I don't know the detail of ECC implementation in socfpga. >>>>>>>> Dinh might have the answer to that. >>>>>>>> >>>>>>>> Anyhow I still think let the setting untouched is the safest fix. >>>>>>>> SPL should use the same ECC setting which BROM loads SPL with. >>>>>>> >>>>>>> That's right, but I'd also like to have this bit in some defined >>>>>>> state from the boot instead of having this in some random setting. >>>>>>> Dinh, can you comment on this corruption please ? >>>>>> >>>>>> Also I'm still a bit confused. >>>>>> >>>>>> The code in crt0.S zeroes global_data so how can it be non-zero a >>>>>> little later in board_init_f()? >>>>> >>>>> board_init_f() enables the ECC of the SRAM regardless its previous >>>>> state. If ECC is disabled beborehand, re-enabling it can cause SRAM >>>>> misreading. >>>> >>>> OK thanks. It might be possible to do this earlier, say in >>>> cpu_init_crit(). >>> >>> You cannot enable the bit, because it'd corrupt your OCRAM and your code >>> is running from the OCRAM, thus you'd be susceptible to corrupting the >>> code you're running itself :( >> >> Oh joy. Well anyway I think this is a chip-specific problem and there >> is nothing wrong in general with the current init process. > > That's absolutelly correct. > > I'd like to hear Dinh's opinion on this, because this seems quite important. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: dm: Fix DM initialization failure after warm reset
Hi Simon, On 04.09.2015 02:23, Simon Glass wrote: > Hi, > > On 3 September 2015 at 05:14, Marek Vasut wrote: >> On Thursday, September 03, 2015 at 01:12:03 PM, Jian Luo wrote: >>> On 03.09.2015 12:46, Marek Vasut wrote: >>> > On Thursday, September 03, 2015 at 12:17:13 PM, Jian Luo wrote: >>> > >>> > Hi! >>> > >>> > [...] >>> > >>> >> >> Yes, I can. But U-Boot can still have problem with other Image >>> >> >> which disables ECC. >>> >> >> I found another post related to this problem >>> >> >> https://lkml.org/lkml/2015/2/6/685 . >>> >> >> >>> >> >> Quote: To initialize ECC, the OCRAM needs to enable ECC >>> >>> then clear >>> >>> >> >> the entire >>> >> >> >>> >> >> memory to zero before using it. >>> >> >>> >> Hi! >>> >> >>> >> > Oh, but that is a problem, since we're running from the OCRAM >>> >>> ourselves, >>> >>> >> > thus we cannot clear the OCRAM. Maybe we should force-disable the >>> >> > ECC instead? But can we be sure that the corruption does not happen >>> >> > when you disable ECC ? >>> >> >>> >> Yes, that will be a problem. It's also why I let the >>> >> SYSMGR_ECC_OCRAM_EN bit intact in the patch. >>> > >>> > OK, but what about turning the ECC off in the SPL, will that also >>> >>> introduce >>> >>> > corruption or not ? That might be the right fix, no ? >>> >>> Hi Marek, >>> >>> Sorry, I don't know the detail of ECC implementation in socfpga. >>> Dinh might have the answer to that. >>> >>> Anyhow I still think let the setting untouched is the safest fix. >>> SPL should use the same ECC setting which BROM loads SPL with. >> >> That's right, but I'd also like to have this bit in some defined >> state from the boot instead of having this in some random setting. >> Dinh, can you comment on this corruption please ? > > Also I'm still a bit confused. > > The code in crt0.S zeroes global_data so how can it be non-zero a > little later in board_init_f()? > board_init_f() enables the ECC of the SRAM regardless its previous state. If ECC is disabled beborehand, re-enabling it can cause SRAM misreading. Best regards, Jian Luo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: dm: Fix DM initialization failure after warm reset
On 03.09.2015 12:46, Marek Vasut wrote: > On Thursday, September 03, 2015 at 12:17:13 PM, Jian Luo wrote: > > Hi! > > [...] > >> >> Yes, I can. But U-Boot can still have problem with other Image which >> >> disables ECC. >> >> I found another post related to this problem >> >> https://lkml.org/lkml/2015/2/6/685 . >> >> >> >> Quote: To initialize ECC, the OCRAM needs to enable ECC then clear >> >> >> >> the entire >> >> >> >> memory to zero before using it. >> >> Hi! >> >> > Oh, but that is a problem, since we're running from the OCRAM ourselves, >> > thus we cannot clear the OCRAM. Maybe we should force-disable the ECC >> > instead? But can we be sure that the corruption does not happen when >> > you disable ECC ? >> >> Yes, that will be a problem. It's also why I let the SYSMGR_ECC_OCRAM_EN >> bit intact in the patch. > > OK, but what about turning the ECC off in the SPL, will that also introduce > corruption or not ? That might be the right fix, no ? Hi Marek, Sorry, I don't know the detail of ECC implementation in socfpga. Dinh might have the answer to that. Anyhow I still think let the setting untouched is the safest fix. SPL should use the same ECC setting which BROM loads SPL with. > > Best regards, > Marek Vasut Best regards, Jian Luo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: dm: Fix DM initialization failure after warm reset
On 03.09.2015 12:09, Marek Vasut wrote:
> On Thursday, September 03, 2015 at 12:03:44 PM, Jian Luo wrote:
>> Hi!
>
> Hi!
>
>> On 03.09.2015 11:41, Marek Vasut wrote:
>> > On Wednesday, September 02, 2015 at 06:27:41 PM, Jian Luo wrote:
>> >> Hi!
>> >>
>> >> this error comes again. It isn't a compiler error after all. :(
>> >>
>> >> JTAG inspection shows that the problem is located in
>> >> arch/arm/mach-socfpga/spl.c line94.
>> >> It seems that re-enable ECC on OCRAM can cause some strange value
>> >> changes in SRAM.
>> >> Disabling ECC might also cause value changes, which I didn't test.
>> >>
>> >> On a cold (re)boot sysmgr_regs->eccgrp_ocram is 0x19
(derr|serr|en). So
>> >> gd keeps intact.
>> >>
>> >> In our VxWorks Image ECC on OCRAM happens to be disabled.
>> >> After a warm reset sysmgr_regs->eccgrp_ocram is 0x18 (derr|serr).
>> >> Thus after re-enable ECC, gd->dm_root turns to 0x80 every time.
>> >
>> > Ew, Dinh, can you check this please ? This is scary.
>>
>> You can also reproduce the problem directly in U-Boot with 2 steps:
>>=> mw.l 0xFFD08144 0
>>=> reset
>>
>> On my ade0-nano-soc it hangs even before serial output,
>> which means it did corrupt the SPL. I guess I just got (un)lucky with
>> socdk.
>
> Oh, nice testcase, thanks!
>
>> >> My solution is keeping SYSMGR_ECC_OCRAM_EN bit untouched. And it
works
>> >> for me.
>> >>
>> >> diff --git a/arch/arm/mach-socfpga/spl.c
b/arch/arm/mach-socfpga/spl.c
>> >> index 775a827..c858406 100644
>> >> --- a/arch/arm/mach-socfpga/spl.c
>> >> +++ b/arch/arm/mach-socfpga/spl.c
>> >> @@ -90,12 +90,14 @@ void board_init_f(ulong dummy)
>> >>
>> >> * and DBE might triggered during power on
>> >> */
>> >>
>> >> reg = readl(&sysmgr_regs->eccgrp_ocram);
>> >>
>> >> - if (reg & SYSMGR_ECC_OCRAM_SERR)
>> >> - writel(SYSMGR_ECC_OCRAM_SERR | SYSMGR_ECC_OCRAM_EN,
>> >> - &sysmgr_regs->eccgrp_ocram);
>> >> - if (reg & SYSMGR_ECC_OCRAM_DERR)
>> >> - writel(SYSMGR_ECC_OCRAM_DERR | SYSMGR_ECC_OCRAM_EN,
>> >> - &sysmgr_regs->eccgrp_ocram);
>> >> + if (reg & SYSMGR_ECC_OCRAM_SERR) {
>> >> + reg &= ~SYSMGR_ECC_OCRAM_SERR;
>> >> + writel(reg, &sysmgr_regs->eccgrp_ocram);
>> >> + }
>> >> + if (reg & SYSMGR_ECC_OCRAM_DERR) {
>> >> + reg &= ~SYSMGR_ECC_OCRAM_DERR;
>> >> + writel(reg, &sysmgr_regs->eccgrp_ocram);
>> >> + }
>> >>
>> >> memset(__bss_start, 0, __bss_end - __bss_start);
>> >>
>> >> Other solution:
>> >> 1. Moving OCRAM ECC setting to earlier stage: requires change in
>> >> generic code.
>> >> 2. Clear gd afterwards: requires replication of every early stage gd
>> >> setting.
>> >
>> > What I would be worried is that if this really happens, it likely
>>
>> also corrupts
>>
>> > the SPL code which is loaded in OCRAM.
>> >
>> > Can't you tune the VxWorks to keep the ECC enabled ?
>>
>> Yes, I can. But U-Boot can still have problem with other Image which
>> disables ECC.
>> I found another post related to this problem
>> https://lkml.org/lkml/2015/2/6/685 .
>> Quote: To initialize ECC, the OCRAM needs to enable ECC then clear
>> the entire
>> memory to zero before using it.
Hi!
>
> Oh, but that is a problem, since we're running from the OCRAM ourselves,
> thus we cannot clear the OCRAM. Maybe we should force-disable the ECC
> instead? But can we be sure that the corruption does not happen when
> you disable ECC ?
Yes, that will be a problem. It's also why I let the SYSMGR_ECC_OCRAM_EN
bit intact in the patch.
Best regards,
Jian Luo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: dm: Fix DM initialization failure after warm reset
Hi!
On 03.09.2015 11:41, Marek Vasut wrote:
> On Wednesday, September 02, 2015 at 06:27:41 PM, Jian Luo wrote:
>> Hi!
>>
>> this error comes again. It isn't a compiler error after all. :(
>>
>> JTAG inspection shows that the problem is located in
>> arch/arm/mach-socfpga/spl.c line94.
>> It seems that re-enable ECC on OCRAM can cause some strange value
>> changes in SRAM.
>> Disabling ECC might also cause value changes, which I didn't test.
>>
>> On a cold (re)boot sysmgr_regs->eccgrp_ocram is 0x19 (derr|serr|en). So
>> gd keeps intact.
>>
>> In our VxWorks Image ECC on OCRAM happens to be disabled.
>> After a warm reset sysmgr_regs->eccgrp_ocram is 0x18 (derr|serr).
>> Thus after re-enable ECC, gd->dm_root turns to 0x80 every time.
>
> Ew, Dinh, can you check this please ? This is scary.
You can also reproduce the problem directly in U-Boot with 2 steps:
=> mw.l 0xFFD08144 0
=> reset
On my ade0-nano-soc it hangs even before serial output,
which means it did corrupt the SPL. I guess I just got (un)lucky with socdk.
>
>> My solution is keeping SYSMGR_ECC_OCRAM_EN bit untouched. And it works
>> for me.
>>
>> diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c
>> index 775a827..c858406 100644
>> --- a/arch/arm/mach-socfpga/spl.c
>> +++ b/arch/arm/mach-socfpga/spl.c
>> @@ -90,12 +90,14 @@ void board_init_f(ulong dummy)
>> * and DBE might triggered during power on
>> */
>> reg = readl(&sysmgr_regs->eccgrp_ocram);
>> - if (reg & SYSMGR_ECC_OCRAM_SERR)
>> - writel(SYSMGR_ECC_OCRAM_SERR | SYSMGR_ECC_OCRAM_EN,
>> - &sysmgr_regs->eccgrp_ocram);
>> - if (reg & SYSMGR_ECC_OCRAM_DERR)
>> - writel(SYSMGR_ECC_OCRAM_DERR | SYSMGR_ECC_OCRAM_EN,
>> - &sysmgr_regs->eccgrp_ocram);
>> + if (reg & SYSMGR_ECC_OCRAM_SERR) {
>> + reg &= ~SYSMGR_ECC_OCRAM_SERR;
>> + writel(reg, &sysmgr_regs->eccgrp_ocram);
>> + }
>> + if (reg & SYSMGR_ECC_OCRAM_DERR) {
>> + reg &= ~SYSMGR_ECC_OCRAM_DERR;
>> + writel(reg, &sysmgr_regs->eccgrp_ocram);
>> + }
>>
>> memset(__bss_start, 0, __bss_end - __bss_start);
>>
>> Other solution:
>> 1. Moving OCRAM ECC setting to earlier stage: requires change in generic
>> code.
>> 2. Clear gd afterwards: requires replication of every early stage gd
>> setting.
>
> What I would be worried is that if this really happens, it likely
also corrupts
> the SPL code which is loaded in OCRAM.
>
> Can't you tune the VxWorks to keep the ECC enabled ?
Yes, I can. But U-Boot can still have problem with other Image which
disables ECC.
I found another post related to this problem
https://lkml.org/lkml/2015/2/6/685 .
Quote: To initialize ECC, the OCRAM needs to enable ECC then clear
the entire
memory to zero before using it.
Best regards,
Jian Luo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] arm: socfpga: Fix memory error caused by re-enabling OCRAM ECC
Re-enabling OCRAM ECC can cause some value changes in SRAM. Just
clear fake interrupt status and keep other bits intact.
Signed-off-by: Jian Luo
---
Changes for v2:
- add CC to custodian
arch/arm/mach-socfpga/spl.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c
index 775a827..c858406 100644
--- a/arch/arm/mach-socfpga/spl.c
+++ b/arch/arm/mach-socfpga/spl.c
@@ -90,12 +90,14 @@ void board_init_f(ulong dummy)
* and DBE might triggered during power on
*/
reg = readl(&sysmgr_regs->eccgrp_ocram);
- if (reg & SYSMGR_ECC_OCRAM_SERR)
- writel(SYSMGR_ECC_OCRAM_SERR | SYSMGR_ECC_OCRAM_EN,
- &sysmgr_regs->eccgrp_ocram);
- if (reg & SYSMGR_ECC_OCRAM_DERR)
- writel(SYSMGR_ECC_OCRAM_DERR | SYSMGR_ECC_OCRAM_EN,
- &sysmgr_regs->eccgrp_ocram);
+ if (reg & SYSMGR_ECC_OCRAM_SERR) {
+ reg &= ~SYSMGR_ECC_OCRAM_SERR;
+ writel(reg, &sysmgr_regs->eccgrp_ocram);
+ }
+ if (reg & SYSMGR_ECC_OCRAM_DERR) {
+ reg &= ~SYSMGR_ECC_OCRAM_DERR;
+ writel(reg, &sysmgr_regs->eccgrp_ocram);
+ }
memset(__bss_start, 0, __bss_end - __bss_start);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: socfpga: Fix memory error caused by re-enabling OCRAM ECC
Re-enabling OCRAM ECC can cause some value changes in SRAM. Just
clear fake interrupt status and keep other bits intact.
Signed-off-by: Jian Luo
---
arch/arm/mach-socfpga/spl.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c
index 775a827..c858406 100644
--- a/arch/arm/mach-socfpga/spl.c
+++ b/arch/arm/mach-socfpga/spl.c
@@ -90,12 +90,14 @@ void board_init_f(ulong dummy)
* and DBE might triggered during power on
*/
reg = readl(&sysmgr_regs->eccgrp_ocram);
- if (reg & SYSMGR_ECC_OCRAM_SERR)
- writel(SYSMGR_ECC_OCRAM_SERR | SYSMGR_ECC_OCRAM_EN,
- &sysmgr_regs->eccgrp_ocram);
- if (reg & SYSMGR_ECC_OCRAM_DERR)
- writel(SYSMGR_ECC_OCRAM_DERR | SYSMGR_ECC_OCRAM_EN,
- &sysmgr_regs->eccgrp_ocram);
+ if (reg & SYSMGR_ECC_OCRAM_SERR) {
+ reg &= ~SYSMGR_ECC_OCRAM_SERR;
+ writel(reg, &sysmgr_regs->eccgrp_ocram);
+ }
+ if (reg & SYSMGR_ECC_OCRAM_DERR) {
+ reg &= ~SYSMGR_ECC_OCRAM_DERR;
+ writel(reg, &sysmgr_regs->eccgrp_ocram);
+ }
memset(__bss_start, 0, __bss_end - __bss_start);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: dm: Fix DM initialization failure after warm reset
Hi!
this error comes again. It isn't a compiler error after all. :(
JTAG inspection shows that the problem is located in
arch/arm/mach-socfpga/spl.c line94.
It seems that re-enable ECC on OCRAM can cause some strange value
changes in SRAM.
Disabling ECC might also cause value changes, which I didn't test.
On a cold (re)boot sysmgr_regs->eccgrp_ocram is 0x19 (derr|serr|en). So
gd keeps intact.
In our VxWorks Image ECC on OCRAM happens to be disabled.
After a warm reset sysmgr_regs->eccgrp_ocram is 0x18 (derr|serr).
Thus after re-enable ECC, gd->dm_root turns to 0x80 every time.
My solution is keeping SYSMGR_ECC_OCRAM_EN bit untouched. And it works
for me.
diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c
index 775a827..c858406 100644
--- a/arch/arm/mach-socfpga/spl.c
+++ b/arch/arm/mach-socfpga/spl.c
@@ -90,12 +90,14 @@ void board_init_f(ulong dummy)
* and DBE might triggered during power on
*/
reg = readl(&sysmgr_regs->eccgrp_ocram);
- if (reg & SYSMGR_ECC_OCRAM_SERR)
- writel(SYSMGR_ECC_OCRAM_SERR | SYSMGR_ECC_OCRAM_EN,
- &sysmgr_regs->eccgrp_ocram);
- if (reg & SYSMGR_ECC_OCRAM_DERR)
- writel(SYSMGR_ECC_OCRAM_DERR | SYSMGR_ECC_OCRAM_EN,
- &sysmgr_regs->eccgrp_ocram);
+ if (reg & SYSMGR_ECC_OCRAM_SERR) {
+ reg &= ~SYSMGR_ECC_OCRAM_SERR;
+ writel(reg, &sysmgr_regs->eccgrp_ocram);
+ }
+ if (reg & SYSMGR_ECC_OCRAM_DERR) {
+ reg &= ~SYSMGR_ECC_OCRAM_DERR;
+ writel(reg, &sysmgr_regs->eccgrp_ocram);
+ }
memset(__bss_start, 0, __bss_end - __bss_start);
Other solution:
1. Moving OCRAM ECC setting to earlier stage: requires change in generic
code.
2. Clear gd afterwards: requires replication of every early stage gd
setting.
Best regards,
Jian Luo
DC-IA/EAH2
Tel. +49(9352)18-4266
BeQIK
On 31.08.2015 15:28, Marek Vasut wrote:
> On Monday, August 31, 2015 at 03:00:22 PM, Jian Luo wrote:
>> Hi,
>
> Hi!
>
>> On 28.08.2015 23:48, Marek Vasut wrote:
>>> On Friday, August 28, 2015 at 02:09:15 PM, Jian Luo wrote:
>>>> Hi Marek,
>>>
>>> Hi,
>>>
>>>> On 28.08.2015 14:01, Marek Vasut wrote:
>>>> > On Friday, August 28, 2015 at 01:40:08 PM, Jian Luo wrote:
>>>> snip
>>>>
>>>> >> "Security policy". :(
>>>> >
>>>> > But thunderbird works ? Can't you just copy the SMTP settings from
>>>>
>>>> thunderbird
>>>>
>>>> > into gitconfig ? :)
>>>>
>>>> I tried w/o success. Might try again another time.
>>>
>>> Try using msmtp and configure your git send-email to send through it
>>> (and all your other MUAs too), it's really convenient :)
>>
>> It works. Thanks. :)
>
> Cool!
>
>>> btw is this a custom board you're porting here ?
>>
>> Yes, but this particular error can also be reproduced on Altera SoCDK.
>>
>> It seems to be a compiler and/or configuration error of gcc 4.8
>> generated by yocto dizzy.
>
> Let me guess -- gcc 4.8.2 ?
>
>> After I switched to gcc 4.9 shiped with Altera Soc EDS 15.0, there is no
>> warm reset error anymore.
>
> Nice, thanks for the update :)
>
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: socfpga: Question about FPGA/HPS SDRAM Bridge
Hi Marek, On 02.09.2015 12:27, Marek Vasut wrote: > On Tuesday, September 01, 2015 at 02:32:26 PM, Jian Luo wrote: >> Hi Marek, > > Hi! > >> On 01.09.2015 14:03, Marek Vasut wrote: >> > On Tuesday, September 01, 2015 at 01:49:43 PM, Jian Luo wrote: >> snip >> >> >> What about calling socfpga_sdram_apply_static_cfg() direct in >> >> socfpga_load() in drivers/fpga/socfpga.c to make it generic? >> > >> > Which code exactly do you refer to ? >> >> I mean something like this. >> >> diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c >> index 4448250..d0f67f6 100644 >> --- a/drivers/fpga/socfpga.c >> +++ b/drivers/fpga/socfpga.c >> @@ -300,5 +300,12 @@ int socfpga_load(Altera_desc *desc, const void >> *rbf_data, size_t rbf_size) >> return status; >> >> /* Ensure the FPGA entering user mode */ >> - return fpgamgr_program_poll_usermode(); >> + status = fpgamgr_program_poll_usermode(); >> + if (status) >> + return status; >> + >> + /* Latch FPGA2SDRAM bridge configuration */ >> + socfpga_sdram_apply_static_cfg(); >> + >> + return 0; >> } >> >> >> socfpga_load() already did step 1 and 2. >> >> Is there any side effect when fpga2sdram bridge is not used? >> > >> > The idea is to keep the FPGA programming code and the code which >> > controls the bridges separate. The reason for that is that you can have >> > content in the FPGA which is running completely independent of the HPS >> > software. You don't always need to enable the bridges. >> >> No, it's the other way around here. >> socfpga_load() runs eventually when command "fpga load" is called. >> So when I explicitly use "fpga load" command, the old FPGA program is >> expected to stop running, right? > > Right > >> And I don't want to enable the bridge here, just to latch the SDRAM >> configuration. > > So what you want to do is "bridge disable ; fpga load ... ; bridge enable", > isn't that the correct sequence ? I might be missing something though, sorry. No, you are right. Sorry, I didn't think it through. My original thought was, that "fpga load" should not depend on "bridge e/d" regardless of how fpga2sdram is configured. Now I think the dependency is a bad idea. Sorry for the confusion. > >> > The FPGA2SDRAM bridge (or, more like fpga2hps bridge) is used for stuff >> > like framebuffers implemented in the FPGA, so that the FPGA can fetch >> > data from the SDRAM. >> > >> > Best regards, >> > Marek Vasut >> >> Best regards, >> >> Jian Luo > > Best regards, > Marek Vasut Best regards, Jian Luo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: socfpga: Question about FPGA/HPS SDRAM Bridge
Hi Marek, On 01.09.2015 14:03, Marek Vasut wrote: > On Tuesday, September 01, 2015 at 01:49:43 PM, Jian Luo wrote: snip >> What about calling socfpga_sdram_apply_static_cfg() direct in >> socfpga_load() in drivers/fpga/socfpga.c to make it generic? > > Which code exactly do you refer to ? I mean something like this. diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c index 4448250..d0f67f6 100644 --- a/drivers/fpga/socfpga.c +++ b/drivers/fpga/socfpga.c @@ -300,5 +300,12 @@ int socfpga_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size) return status; /* Ensure the FPGA entering user mode */ - return fpgamgr_program_poll_usermode(); + status = fpgamgr_program_poll_usermode(); + if (status) + return status; + + /* Latch FPGA2SDRAM bridge configuration */ + socfpga_sdram_apply_static_cfg(); + + return 0; } > >> socfpga_load() already did step 1 and 2. >> Is there any side effect when fpga2sdram bridge is not used? > > The idea is to keep the FPGA programming code and the code which controls > the bridges separate. The reason for that is that you can have content in > the FPGA which is running completely independent of the HPS software. You > don't always need to enable the bridges. No, it's the other way around here. socfpga_load() runs eventually when command "fpga load" is called. So when I explicitly use "fpga load" command, the old FPGA program is expected to stop running, right? And I don't want to enable the bridge here, just to latch the SDRAM configuration. > > The FPGA2SDRAM bridge (or, more like fpga2hps bridge) is used for stuff > like framebuffers implemented in the FPGA, so that the FPGA can fetch > data from the SDRAM. > > Best regards, > Marek Vasut Best regards, Jian Luo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: socfpga: Question about FPGA/HPS SDRAM Bridge
** Hi Marek, On 01.09.2015 11:03, Marek Vasut wrote: On Tuesday, September 01, 2015 at 10:41:31 AM, Jian Luo wrote: Hi! Hi, I've read about an implementation requirement regarding the usage of FPGA/HPS SDRAM bridge. (Link and Text attached at the end.) The 3. step involves writing the APPLYCFG bit in the STATICCFG register while the SDRAM interface is completely IDLE. IMHO, it's only possible in SPL stage where everything runs in SRAM. FPGA however can not be configured until U-Boot is ready (step 2). So warm reset should be performed after FPGA configuration. My idea is to patch sdram.c to dynamically write FPGAPORTRST and APPLYCFG based on information in sysmgr_regs->romcodegrp_bootromswstate. Is any one working on this? We do this sort of stuff by running code from cache, see socfpga_sdram_apply_static_cfg() in arch/arm/mach-socfpga/misc.c . Thanks. It's way better than run bootloader twice! You want to use the "bridge enable" and "bridge disable" commands to enable/disable the bridges between FPGA and HPS in U-Boot. What about calling socfpga_sdram_apply_static_cfg() direct in socfpga_load() in drivers/fpga/socfpga.c to make it generic? socfpga_load() already did step 1 and 2. Is there any side effect when fpga2sdram bridge is not used? Hope that helps ;-) Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] arm: socfpga: Question about FPGA/HPS SDRAM Bridge
Hi! I've read about an implementation requirement regarding the usage of FPGA/HPS SDRAM bridge. (Link and Text attached at the end.) The 3. step involves writing the APPLYCFG bit in the STATICCFG register while the SDRAM interface is completely IDLE. IMHO, it's only possible in SPL stage where everything runs in SRAM. FPGA however can not be configured until U-Boot is ready (step 2). So warm reset should be performed after FPGA configuration. My idea is to patch sdram.c to dynamically write FPGAPORTRST and APPLYCFG based on information in sysmgr_regs->romcodegrp_bootromswstate. Is any one working on this? Thanks! -- Best regards, Jian Luo Link and Text of the note: https://support.criticallink.com/redmine/projects/mityarm-5cs/wiki/Important_Note_about_FPGAHPS_SDRAM_Bridge Important Note about FPGA/HPS SDRAM Bridge (2013-12-13) Altera has recently disclosed an implementation requirement related to the use of the FPGA to HPS SDRAM bridges. Until more formal technical notes are published at Altera, this page will be maintained to outline the understood issue for the benefits of MitySOM-5CSX customers. Configuration of the FPGA to HPS SDRAM (fpga2sdram) AXI bridges involves the following major steps: 1. First, the FPGA ports on the fpga2sdram peripheral must be placed in reset. This is accomplished by writing a zero to the FPGAPORTRST register in the SDRAM Controller control group. 2. Second, the FPGA must be configured with an image that includes the configuration of the fpga2sdram ports. The FPGA fabric asserts configuration input ports at the input to the fpga2sdram bridges. The configuration ports affect such things as the width of the port as well as the direction, etc. When the FPGA is not configured, these configuration inputs are not defined. 3. Third, once the configuration inputs are set, the configuration must be then latched / applied to the fpga2sdram bridge peripheral. This is accomplished by writing a one to the APPLYCFG bit in the STATICCFG register in the SDRAM Controller control group. This bit can only be written to while the SDRAM DDR interface is guaranteed to be completely IDLE (including transfers from the ARM cores, DMAs, etc.). 4. Finally, the FPGA ports on the fpga2sdram peripheral can be taken out of reset based on your configuration. This is accomplished by writing ones to the appropriate bits in the FPGAPORTRST register in the SDRAM Controller control group. If these steps are not followed, attempting to use an FPGA port on the HPS SDRAM bridge controller may result in critical failure -- the HPS subsystem may freeze and effectively lock up the processor. As a consequence to the note bolded in step 3, the fpga2sdram controller cannot be practically configured while most high level operating systems are running (linux, windows, android, etc.). Altera has provided the capability to set the configuration bit in step three with a macro command in their (and Critical Link's) u-Boot port. This is accomplished by copying a small routine to on-chip RAM that disables caches and asserts the APPLYCFG bit and then returns operation to the typical DDR space. Therefor, if you have an FPGA design that utilizes the fpga2sdram controller, you must program the FPGA in u-Boot following an FPGA / power on reset situation. Once the SDRAM controller is properly configured, the FPGA ports may be reset and enabled (steps 1 and 4) as often as necessary in order to facilitate reloading of the FPGA -- as long as the new fpga2sdram port configuration matches the original configuration. This will allow for reconfiguration of an FPGA while running linux, if necessary. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: dm: Fix DM initialization failure after warm reset
Hi, On 28.08.2015 23:48, Marek Vasut wrote: On Friday, August 28, 2015 at 02:09:15 PM, Jian Luo wrote: Hi Marek, Hi, On 28.08.2015 14:01, Marek Vasut wrote: > On Friday, August 28, 2015 at 01:40:08 PM, Jian Luo wrote: snip >> "Security policy". :( > > But thunderbird works ? Can't you just copy the SMTP settings from thunderbird > into gitconfig ? :) I tried w/o success. Might try again another time. Try using msmtp and configure your git send-email to send through it (and all your other MUAs too), it's really convenient :) It works. Thanks. :) btw is this a custom board you're porting here ? Yes, but this particular error can also be reproduced on Altera SoCDK. It seems to be a compiler and/or configuration error of gcc 4.8 generated by yocto dizzy. After I switched to gcc 4.9 shiped with Altera Soc EDS 15.0, there is no warm reset error anymore. Best regards, Marek Vasut Best regards, Jian Luo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: dm: Fix DM initialization failure after warm reset
Hi Marek, On 28.08.2015 14:01, Marek Vasut wrote: > On Friday, August 28, 2015 at 01:40:08 PM, Jian Luo wrote: snip >> "Security policy". :( > > But thunderbird works ? Can't you just copy the SMTP settings from thunderbird > into gitconfig ? :) I tried w/o success. Might try again another time. Best regards, Jian Luo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: dm: Fix DM initialization failure after warm reset
On 28.08.2015 12:30, Marek Vasut wrote: On Friday, August 28, 2015 at 12:27:18 PM, Jian Luo wrote: Hi Marek, On 28.08.2015 11:24, Marek Vasut wrote: On Friday, August 28, 2015 at 10:41:50 AM, Jian Luo wrote: gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure. Signed-off-by: Jian Luo Hi! --- arch/arm/mach-socfpga/spl.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c index 13ec24b..59fe1f2 100644 --- a/arch/arm/mach-socfpga/spl.c +++ b/arch/arm/mach-socfpga/spl.c @@ -181,5 +181,11 @@ void board_init_f(ulong dummy) /* Configure simple malloc base pointer into RAM. */ gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024); + /* +* gd->dm_root might contain non-zero value after warm reset. +* Clear it to avoid dm_init error +*/ + gd->dm_root = NULL; Nit: The indent should be done with tabs, not spaces. I think the email got messed up somewhere along the way. Yes, sorry. I can't setup git send-email in our company network. Thunderbird messed the indent up. Why not ? "Security policy". :( The bigger concern I have is that if you look into arch/arm/lib/crt0.S , you will see that the entire global data are cleared there (_main, label clr_gd: ) and this code is executed before the board_init_f() . This was my first assumption, it should be cleared in crt0.S. I was using U-Boot to load a VxWorks image. And wrote 1 to rstmgr ctrl in VxWorks to do a warm reset. Afterwards the SPL hangs. Hangs in which way ? Can you share the output please ? Sorry, should attached the output in the first place. With CONFIG_DM_WARN defined: * * VxWorks is up * * -> reboot U-Boot SPL 2015.10-rc2-00192-ge122af6-dirty (Aug 28 2015 - 11:35:27) drivers/ddr/altera/sequencer.c: Preparing to start memory calibration drivers/ddr/altera/sequencer.c: CALIBRATION PASSED drivers/ddr/altera/sequencer.c: Calibration complete Virtual root driver already exists! ### ERROR ### Please RESET the board ### It did not happen if I do reset direct in U-Boot. I'll attach a JTAG Debug to dig deeper. Neat, that'd be really awesome, thanks for looking into this ! Can you try tracking it down a bit more? I suspect that you might see dm_init_and_scan() returned error -22 , is that what you observe please? Yes, in dm_init() where gd->dm_root will be checked. But if you get -ENOMEM, that means somehow the malloc is broken here. I wonder if this explicit setting of gd->malloc_area is screwing something up ? Isn't 22 EINVAL? It's in the drivers/core/root.c line 105 Best regards, Marek Vasut Best regards, Jian Luo * * ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: dm: Fix DM initialization failure after warm reset
Hi Marek, On 28.08.2015 11:24, Marek Vasut wrote: On Friday, August 28, 2015 at 10:41:50 AM, Jian Luo wrote: gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure. Signed-off-by: Jian Luo Hi! --- arch/arm/mach-socfpga/spl.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c index 13ec24b..59fe1f2 100644 --- a/arch/arm/mach-socfpga/spl.c +++ b/arch/arm/mach-socfpga/spl.c @@ -181,5 +181,11 @@ void board_init_f(ulong dummy) /* Configure simple malloc base pointer into RAM. */ gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024); + /* +* gd->dm_root might contain non-zero value after warm reset. +* Clear it to avoid dm_init error +*/ + gd->dm_root = NULL; Nit: The indent should be done with tabs, not spaces. I think the email got messed up somewhere along the way. Yes, sorry. I can't setup git send-email in our company network. Thunderbird messed the indent up. The bigger concern I have is that if you look into arch/arm/lib/crt0.S , you will see that the entire global data are cleared there (_main, label clr_gd: ) and this code is executed before the board_init_f() . This was my first assumption, it should be cleared in crt0.S. I was using U-Boot to load a VxWorks image. And wrote 1 to rstmgr ctrl in VxWorks to do a warm reset. Afterwards the SPL hangs. It did not happen if I do reset direct in U-Boot. I'll attach a JTAG Debug to dig deeper. Can you try tracking it down a bit more? I suspect that you might see dm_init_and_scan() returned error -22 , is that what you observe please? Yes, in dm_init() where gd->dm_root will be checked. board_init_r(NULL, 0); } Best regards, Marek Vasut Best regards, Jian Luo ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: socfpga: dm: Fix DM initialization failure after warm reset
gd->dm_root is not cleared in SPL after warm reset. This might cause DM initilazation failure. Signed-off-by: Jian Luo --- arch/arm/mach-socfpga/spl.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/mach-socfpga/spl.c b/arch/arm/mach-socfpga/spl.c index 13ec24b..59fe1f2 100644 --- a/arch/arm/mach-socfpga/spl.c +++ b/arch/arm/mach-socfpga/spl.c @@ -181,5 +181,11 @@ void board_init_f(ulong dummy) /* Configure simple malloc base pointer into RAM. */ gd->malloc_base = CONFIG_SYS_TEXT_BASE + (1024 * 1024); + /* +* gd->dm_root might contain non-zero value after warm reset. +* Clear it to avoid dm_init error +*/ + gd->dm_root = NULL; + board_init_r(NULL, 0); } -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
