Re: [U-Boot] [PATCH] powerpc/t1040qds: Add DDR Raw Timing support
On Oct 30, 2013, at 9:55 PM, Jain Priyanka-B32167 wrote: > >> -Original Message- >> From: sun york-R58495 >> Sent: Wednesday, October 30, 2013 10:14 PM >> To: Jain Priyanka-B32167; u-boot@lists.denx.de >> Cc: Aggrwal Poonam-B10812 >> Subject: Re: [PATCH] powerpc/t1040qds: Add DDR Raw Timing support >> >> On 10/25/2013 02:49 AM, Priyanka Jain wrote: >>> T1040QDS-D3 has dual-rank DDR: >>> Micron, MT18KSF51272AZ-1G6 (4GB, x72, CL=10). >>> Add Raw Timing structure for this DDR. >>> >>> Typically SPD method is used for getting DDR parameter and calculating >>> values for various DDR controller registers. >>> >>> But somentimes it may happen that SPD present on DDR may get >>> accidently erased or is not working properly during initial bring-up. >>> In that circumnstance, DDR raw timing structure can be use as fallback >>> option for getting DDR parameters. >>> >>> Signed-off-by: Poonam Aggrwal >>> Signed-off-by: Priyanka Jain >>> --- >> >> I don't think it is appropriate to use raw timing for this application. >> This board use DIMMs, not soldered DDR chips. In normal cases, this piece >> of code is not used. It is only useful if you have a DIMM without a valid >> SPD. You could get another DIMM. I am not saying this patch is wrong, it >> is just useless for general public. >> >> York > > [Jain Priyanka-B32167] You are right that in case of DIMM type of memories, > raw timing may not be required. > But there are certain scenarios in which keeping raw timing is useful like > 1)During initial bring-up, there is a possibility that I2C bus may be broken, > In that case boot-loader has to rely on the fallback option of raw timing. > 2)Also raw timings are used in emulator to test t1040. > So, we prefer to keep raw timing as fallback option. It is a debug technique, not an implementation. You can use fixed register setting as well for debugging. But it doesn't mean you have to keep it in the final code. After you cleaning up the code, all "fixed" code should be removed, including the raw timing parameters you are using. Emulator target also has I2C EEPROM modeled. You should use SPD as well. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] powerpc/esdhc: hack t4240 host capabilities register for VS33 bit
On Oct 24, 2013, at 6:54 PM, Haijun Zhang wrote: > T4240 eSDHC host capabilities reigster should have VS33 bit define. > hack the code to add the 3.3 voltage support Shall we call it quirk rather than hack? Native English speakers, please chime in. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] When to create a SoC directory for ARM
On Sep 25, 2013, at 10:23 PM, FengHua wrote: > > Date: Wed, 25 Sep 2013 20:10:13 -0500 > > From: Scott Wood > > Subject: Re: [U-Boot] When to create a SoC directory for ARM > > To: sun york-R58495 > > Cc: Rini , Wood Scott-B07421 , > > "u-boot@lists.denx.de" , Tom > > Message-ID: <1380157813.24959.237.ca...@snotra.buserror.net> > > Content-Type: text/plain; charset="UTF-8" > > > On Wed, 2013-09-25 at 20:04 -0500, sun york-R58495 wrote: > > > On Sep 25, 2013, at 4:52 PM, Scott Wood wrote: > > > > > > > On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote: > > > >> Dear Wolfgang, > > > >> > > > >> I failed to find the guideline, here is my question. Pardon me if this > > > >> is a dump question as I am still new to ARM. > > > >> > > > >> As David Feng post his patch set to add ARMv8 support, I am trying to > > > >> enable it for Freescale implementation. Let's name it as LS2 for this > > > >> discussion. I am thinking to reuse as much as possible for existing > > > >> codes, which include copying some header files from powerpc partially. > > > >> I > > > >> noticed the SoC field in boards.cfg file and I am wondering how to use > > > >> it effectively. I want to put LS2 specific headers to > > > >> arch/arm/include/asm/arch-ls2. Do I need to copy all files from > > > >> arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is > > > >> included in start.S. I have been searching case like this in ARMv7 but > > > >> didn't see shared header file (maybe I missed it). Please advise. > > > > > > > > LS2 is (or perhaps more accurately, contains) an implementation of > > > > ARMv8, so you should be using arch-armv8 rather than copying it. > > > > > > True. But I guess LS2 won't be the only "LS" Freescale is going to > > > make. Where is the best place to put the header file for chassis > > > related registers, like CCSR we have for mpc8xxx. > > > Anything that isn't deeply tied to the ARM architecture should probably > > just go in include/. > > > I am thinking the > > > best place is arch/arm/include/asm/ls2 (or a better name). Like other > > > ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/ as > > > well, to host LS-specific code. > > > Likewise, if it's specifically tied to armv8 it should go in > > arch/arm/include/asm/arch-armv8, but I'm not sure what would be tied to > > both armv8 and ls2. Most likely anything LS-specific that needs to go > > under arch/arm/ should go somewhere like arch/arm/include/asm/ls/ > > (similar to arch/arm/include/asm/imx-common). > > > -Scott > > all SOC specific include file should be in arch/arm/include/asm/arch-SOC/ or > some common directory(like include/asm/imx-common). Currently, u-boot only > link SOC specific(arch-SOC) include directory. > You could touch a mmu.h file in arch/arm/include/asm/arch-ls2/ and include > arch/arm/include/asm/arch-armv8/mmu.h. > or move arch-armv8/mmu.h to arch/arm/include/asm/ to make it as a generic > file. > Maybe we should distinguish architecture specific include directory and SOC > specific include directory. I was thinking to change the include in start.S to #include York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] When to create a SoC directory for ARM
On Sep 25, 2013, at 4:52 PM, Scott Wood wrote: > On Wed, 2013-09-25 at 16:30 -0700, York Sun wrote: >> Dear Wolfgang, >> >> I failed to find the guideline, here is my question. Pardon me if this >> is a dump question as I am still new to ARM. >> >> As David Feng post his patch set to add ARMv8 support, I am trying to >> enable it for Freescale implementation. Let's name it as LS2 for this >> discussion. I am thinking to reuse as much as possible for existing >> codes, which include copying some header files from powerpc partially. I >> noticed the SoC field in boards.cfg file and I am wondering how to use >> it effectively. I want to put LS2 specific headers to >> arch/arm/include/asm/arch-ls2. Do I need to copy all files from >> arch/arm/include/asm/arch-armv8/? There aren't many but I see mmu.h is >> included in start.S. I have been searching case like this in ARMv7 but >> didn't see shared header file (maybe I missed it). Please advise. > > LS2 is (or perhaps more accurately, contains) an implementation of > ARMv8, so you should be using arch-armv8 rather than copying it. True. But I guess LS2 won't be the only "LS" Freescale is going to make. Where is the best place to put the header file for chassis related registers, like CCSR we have for mpc8xxx. I am thinking the best place is arch/arm/include/asm/ls2 (or a better name). Like other ARMv7 variants, I am thinking to put ls2 under arch/arm/cpu/armv8/ as well, to host LS-specific code. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc8xxx: Fix CamelCase for DDR code
Aha! I was looking for it. I remember I saw it. Thanks for the link.
York
On Sep 10, 2013, at 9:12 PM, Jain Priyanka-B32167 wrote:
> Hello York,
>
> I have already send a similar patch:
> http://patchwork.ozlabs.org/patch/271670/
>
> Regards
> Priyanka
>
>
>
>> -Original Message-
>> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
>> On Behalf Of York Sun
>> Sent: Wednesday, September 11, 2013 1:56 AM
>> To: u-boot@lists.denx.de
>> Cc: sun york-R58495
>> Subject: [U-Boot] [PATCH] powerpc/mpc8xxx: Fix CamelCase for DDR code
>>
>> Clean up CamelCase in DDR code to comply with latest coding style.
>>
>> Signed-off-by: York Sun
>> ---
>> .../powerpc/cpu/mpc8xxx/ddr/common_timing_params.h |8 ++--
>> arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c | 46 ++
>> --
>> arch/powerpc/cpu/mpc8xxx/ddr/ddr.h |2 +-
>> arch/powerpc/cpu/mpc8xxx/ddr/interactive.c | 46 ++
>> --
>> .../cpu/mpc8xxx/ddr/lc_common_dimm_params.c| 14 +++---
>> arch/powerpc/cpu/mpc8xxx/ddr/main.c|6 +--
>> arch/powerpc/cpu/mpc8xxx/ddr/options.c | 34 +++---
>> -
>> arch/powerpc/include/asm/fsl_ddr_sdram.h | 28 ++--
>> board/exmeritus/hww1u1a/ddr.c |2 +-
>> board/freescale/b4860qds/ddr.c |4 +-
>> board/freescale/corenet_ds/ddr.c |4 +-
>> board/freescale/mpc8349emds/ddr.c |6 +--
>> board/freescale/mpc8540ads/ddr.c |2 +-
>> board/freescale/mpc8544ds/ddr.c|2 +-
>> board/freescale/mpc8560ads/ddr.c |2 +-
>> board/freescale/mpc8572ds/ddr.c|4 +-
>> board/freescale/mpc8610hpcd/ddr.c |2 +-
>> board/freescale/mpc8641hpcn/ddr.c |2 +-
>> board/freescale/p1022ds/ddr.c |4 +-
>> board/freescale/p2020ds/ddr.c |4 +-
>> board/freescale/p2041rdb/ddr.c |4 +-
>> board/freescale/t4qds/ddr.c|4 +-
>> board/stx/stxgp3/ddr.c |2 +-
>> board/stx/stxssa/ddr.c |2 +-
>> board/xes/xpedite550x/ddr.c|2 +-
>> doc/README.fsl-ddr |2 +-
>> 26 files changed, 119 insertions(+), 119 deletions(-)
>>
>> diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/common_timing_params.h
>> b/arch/powerpc/cpu/mpc8xxx/ddr/common_timing_params.h
>> index 06706ed..b392cd1 100644
>> --- a/arch/powerpc/cpu/mpc8xxx/ddr/common_timing_params.h
>> +++ b/arch/powerpc/cpu/mpc8xxx/ddr/common_timing_params.h
>> @@ -41,10 +41,10 @@ typedef struct {
>> unsigned int lowest_common_SPD_caslat;
>> unsigned int highest_common_derated_caslat;
>> unsigned int additive_latency;
>> -unsigned int all_DIMMs_burst_lengths_bitmask;
>> -unsigned int all_DIMMs_registered;
>> -unsigned int all_DIMMs_unbuffered;
>> -unsigned int all_DIMMs_ECC_capable;
>> +unsigned int all_dimms_burst_lengths_bitmask;
>> +unsigned int all_dimms_registered;
>> +unsigned int all_dimms_unbuffered;
>> +unsigned int all_dimms_ecc_capable;
>>
>> unsigned long long total_mem;
>> unsigned long long base_address;
>> diff --git a/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
>> b/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
>> index 242eb47..6c5dcb4 100644
>> --- a/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
>> +++ b/arch/powerpc/cpu/mpc8xxx/ddr/ctrl_regs.c
>> @@ -360,7 +360,7 @@ static void set_timing_cfg_3(fsl_ddr_cfg_regs_t *ddr,
>> ext_refrec = (picos_to_mclk(common_dimm->tRFC_ps) - 8) >> 4;
>> /* ext_wrrec only deals with 16 clock and above, or 14 with OTF */
>> ext_wrrec = (picos_to_mclk(common_dimm->tWR_ps) +
>> -(popts->OTF_burst_chop_en ? 2 : 0)) >> 4;
>> +(popts->otf_burst_chop_en ? 2 : 0)) >> 4;
>>
>> ddr->timing_cfg_3 = (0
>> | ((ext_pretoact & 0x1) << 28)
>> @@ -440,7 +440,7 @@ static void set_timing_cfg_1(fsl_ddr_cfg_regs_t *ddr,
>> printf("Error: WRREC doesn't support more than 16 clocks\n");
>> else
>> wrrec_mclk = wrrec_table[wrrec_mclk - 1];
>> -if (popts->OTF_burst_chop_en)
>> +if (popts->otf
Re: [U-Boot] P2041RDB fails to boot with master (and 2013.10-rc1)
Chris, Thanks for the debugging work. As I suspected, it's related to I2C change. It's probably a problem in the board header file. If you fix it, please submit a patch. Otherwise, I will look into it tomorrow. York Original Message From: Chris Packham Sent: Mon, 09/09/2013 22:49 To: sun york-R58495 CC: u-boot ; Xie Shaohui-B21989 ; h...@denx.de Subject: Re: P2041RDB fails to boot with master (and 2013.10-rc1) git bisect points to the following commit 00f792e0df9ae942427e44595a0f4379582accee is the first bad commit commit 00f792e0df9ae942427e44595a0f4379582accee Author: Heiko Schocher Date: Wed Oct 24 13:48:22 2012 +0200 i2c, fsl_i2c: switch to new multibus/multiadapter support - added to fsl_i2c driver new multibus/multiadpater support - adapted all config files, which uses this driver Signed-off-by: Heiko Schocher Cc: Simon Glass Cc: Stephen Warren On Tue, Sep 10, 2013 at 5:31 PM, sun york-R58495 wrote: > Chris, > > Thanks a lot to bring this to our attention. > > A brief look at the log shows the SPD wasn't found, probably due to recent > I2C change. We will address this issue as soon as possible. > > York > > > > Original Message > From: Chris Packham > Sent: Mon, 09/09/2013 22:26 > To: u-boot > CC: sun york-R58495 ; Xie Shaohui-B21989 ; aflem...@freescale.com > Subject: P2041RDB fails to boot with master (and 2013.10-rc1) > > Hi, > > I was just looking at something else and found that my P2041RDB no > longer boots from the master branch of u-boot.git (it hangs after DDR > initialisation). I checked 2013.10-rc1, same problem. 2013.07 works. > > I haven't bisected further than that. I just thought I'd fire this off > now since it appears to be a regression that might affect 2013.10. > > Thanks, > Chris > > -- > > Output from 2013.10-rc1 > > U-Boot 2013.10-rc1 (Sep 10 2013 - 17:08:26) > > CPU0: P2041E, Version: 1.0, (0x82180110) > Core: e500mc, Version: 2.2, (0x80230022) > Clock Configuration: >CPU0:1500 MHz, CPU1:1500 MHz, CPU2:1500 MHz, CPU3:1500 MHz, >CCB:750 MHz, >DDR:666.667 MHz (1333.333 MT/s data rate) (Asynchronous), LBC:93.750 > MHz >FMAN1: 583.333 MHz >QMAN: 375 MHz >PME: 375 MHz > L1:D-cache 32 kB enabled >I-cache 32 kB enabled > Reset Configuration Word (RCW): >: 1260 241c >0010: 249f40c0 c3c02000 fe80 4000 >0020: d0030f07 >0030: > Board: P2041RDB, CPLD version: 3.0 vBank: 0 > SERDES Reference Clocks: Bank1=100Mhz Bank2=125Mhz > I2C: ready > SPI: ready > DRAM: InitializingWARNING: Calling __hwconfig without a buffer > and before environment is ready > using SPD > DDR: failed to read SPD from address 82 > WARNING: Calling __hwconfig without a buffer and before environment is ready > WARNING: Calling __hwconfig without a buffer and before environment is ready > 16 MiB (DDR2, 64-bit, CL=0.5, ECC off) > Testing 0x - 0x00ff > Remap DDR > > Output from 2013.07 > > > U-Boot 2013.07 (Sep 10 2013 - 17:00:18) > > CPU0: P2041E, Version: 1.0, (0x82180110) > Core: e500mc, Version: 2.2, (0x80230022) > Clock Configuration: >CPU0:1500 MHz, CPU1:1500 MHz, CPU2:1500 MHz, CPU3:1500 MHz, >CCB:750 MHz, >DDR:666.667 MHz (1333.333 MT/s data rate) (Asynchronous), LBC:93.750 > MHz >FMAN1: 583.333 MHz >QMAN: 375 MHz >PME: 375 MHz > L1:D-cache 32 kB enabled >I-cache 32 kB enabled > Board: P2041RDB, CPLD version: 3.0 vBank: 0 > Reset Configuration Word (RCW): >: 1260 241c >0010: 249f40c0 c3c02000 fe80 4000 >0020: d0030f07 >0030: > SERDES Reference Clocks: Bank1=100Mhz Bank2=125Mhz > I2C: ready > SPI: ready > DRAM: Initializingusing SPD > Detected UDIMM UG51U6400N8SU-ACF > 2 GiB left unmapped > 4 GiB (DDR3, 64-bit, CL=9, ECC off) >DDR Chip-Select Interleaving Mode: CS0+CS1 > Testing 0x - 0x7fff > Testing 0x8000 - 0x > Remap DDR 2 GiB left unmapped > > POST memory PASSED > Flash: 128 MiB > L2:128 KB enabled > Corenet Platform Cache: 1024 KB enabled > SERDES: bank 3 disabled > SRIO1: disabled > SRIO2: disabled > NAND: 0 MiB > MMC: FSL_SDHC: 0 > EEPROM: Invalid ID (ff ff ff ff) > PCIe1: disabled > PCIe2: Root Complex, no link, regs @ 0xfe201000 > PCIe2: Bus 00 - 00 > PCIe3: disabled > I
Re: [U-Boot] P2041RDB fails to boot with master (and 2013.10-rc1)
Chris, Thanks a lot to bring this to our attention. A brief look at the log shows the SPD wasn't found, probably due to recent I2C change. We will address this issue as soon as possible. York Original Message From: Chris Packham Sent: Mon, 09/09/2013 22:26 To: u-boot CC: sun york-R58495 ; Xie Shaohui-B21989 ; aflem...@freescale.com Subject: P2041RDB fails to boot with master (and 2013.10-rc1) Hi, I was just looking at something else and found that my P2041RDB no longer boots from the master branch of u-boot.git (it hangs after DDR initialisation). I checked 2013.10-rc1, same problem. 2013.07 works. I haven't bisected further than that. I just thought I'd fire this off now since it appears to be a regression that might affect 2013.10. Thanks, Chris -- Output from 2013.10-rc1 U-Boot 2013.10-rc1 (Sep 10 2013 - 17:08:26) CPU0: P2041E, Version: 1.0, (0x82180110) Core: e500mc, Version: 2.2, (0x80230022) Clock Configuration: CPU0:1500 MHz, CPU1:1500 MHz, CPU2:1500 MHz, CPU3:1500 MHz, CCB:750 MHz, DDR:666.667 MHz (1333.333 MT/s data rate) (Asynchronous), LBC:93.750 MHz FMAN1: 583.333 MHz QMAN: 375 MHz PME: 375 MHz L1:D-cache 32 kB enabled I-cache 32 kB enabled Reset Configuration Word (RCW): : 1260 241c 0010: 249f40c0 c3c02000 fe80 4000 0020: d0030f07 0030: Board: P2041RDB, CPLD version: 3.0 vBank: 0 SERDES Reference Clocks: Bank1=100Mhz Bank2=125Mhz I2C: ready SPI: ready DRAM: InitializingWARNING: Calling __hwconfig without a buffer and before environment is ready using SPD DDR: failed to read SPD from address 82 WARNING: Calling __hwconfig without a buffer and before environment is ready WARNING: Calling __hwconfig without a buffer and before environment is ready 16 MiB (DDR2, 64-bit, CL=0.5, ECC off) Testing 0x - 0x00ff Remap DDR Output from 2013.07 U-Boot 2013.07 (Sep 10 2013 - 17:00:18) CPU0: P2041E, Version: 1.0, (0x82180110) Core: e500mc, Version: 2.2, (0x80230022) Clock Configuration: CPU0:1500 MHz, CPU1:1500 MHz, CPU2:1500 MHz, CPU3:1500 MHz, CCB:750 MHz, DDR:666.667 MHz (1333.333 MT/s data rate) (Asynchronous), LBC:93.750 MHz FMAN1: 583.333 MHz QMAN: 375 MHz PME: 375 MHz L1:D-cache 32 kB enabled I-cache 32 kB enabled Board: P2041RDB, CPLD version: 3.0 vBank: 0 Reset Configuration Word (RCW): : 1260 241c 0010: 249f40c0 c3c02000 fe80 4000 0020: d0030f07 0030: SERDES Reference Clocks: Bank1=100Mhz Bank2=125Mhz I2C: ready SPI: ready DRAM: Initializingusing SPD Detected UDIMM UG51U6400N8SU-ACF 2 GiB left unmapped 4 GiB (DDR3, 64-bit, CL=9, ECC off) DDR Chip-Select Interleaving Mode: CS0+CS1 Testing 0x - 0x7fff Testing 0x8000 - 0x Remap DDR 2 GiB left unmapped POST memory PASSED Flash: 128 MiB L2:128 KB enabled Corenet Platform Cache: 1024 KB enabled SERDES: bank 3 disabled SRIO1: disabled SRIO2: disabled NAND: 0 MiB MMC: FSL_SDHC: 0 EEPROM: Invalid ID (ff ff ff ff) PCIe1: disabled PCIe2: Root Complex, no link, regs @ 0xfe201000 PCIe2: Bus 00 - 00 PCIe3: disabled In:serial Out: serial Err: serial Net: Initializing Fman Fman1: DTSEC3 set to unknown interface 12 Fman1: Uploading microcode version 101.8.0 Phy not found PHY reset timed out FM1@DTSEC1, FM1@DTSEC2, FM1@DTSEC4, FM1@DTSEC5, FM1@TGEC1 => ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] common: Add CCACHE variable to allow use of ccache
On Aug 21, 2013, at 10:45 PM, sun york-R58495 wrote: > > On Aug 21, 2013, at 10:02 PM, Marek Vasut wrote: > >> Dear sun york-R58495, >> >>> On Aug 21, 2013, at 7:51 PM, Marek Vasut wrote: >>>> Dear York Sun, >>>> >>>>> On 05/20/2013 10:25 AM, Marek Vasut wrote: >>>>>> Prefix HOSTCC and CC with CCACHE variable to allow easy use of ccache. >>>>>> In case the user wants to use ccache, exporting CCACHE=ccache will do >>>>>> the trick. It is of course possible to either make the cross-compiler >>>>>> name into a shellscript which invokes the ccache and the compiler, but >>>>>> setting this variable makes use of ccache easier and more convenient. >>>>>> >>>>>> Using ccache becomes convenient when using MAKEALL for large build >>>>>> tests, where the speedup after building the cache for the first time >>>>>> is about 4-6 times. >>>>>> >>>>>> Signed-off-by: Marek Vasut >>>>>> Cc: Tom Rini >>>>>> >>>>>> --- >>>>>> config.mk |8 +--- >>>>>> >>>>>> 1 file changed, 5 insertions(+), 3 deletions(-) >>>>>> >>>>>> diff --git a/config.mk b/config.mk >>>>>> index 1fd109f..d59ded2 100644 >>>>>> --- a/config.mk >>>>>> +++ b/config.mk >>>>>> @@ -98,6 +98,8 @@ else >>>>>> >>>>>> HOSTCC = gcc >>>>>> endif >>>>>> >>>>>> +HOSTCC := $(CCACHE) $(HOSTCC) >>>>>> + >>>>>> >>>>>> ifeq ($(HOSTOS),cygwin) >>>>>> HOSTCFLAGS += -ansi >>>>>> endif >>>>>> >>>>>> @@ -140,13 +142,13 @@ binutils-version = $(shell $(SHELL) >>>>>> $(SRCTREE)/tools/binutils-version.sh $(AS)) >>>>>> >>>>>> # >>>>>> # Include the make variables (CC, etc...) >>>>>> # >>>>>> >>>>>> -AS = $(CROSS_COMPILE)as >>>>>> +AS = $(CCACHE) $(CROSS_COMPILE)as >>>>>> >>>>>> # Always use GNU ld >>>>>> LD = $(shell if $(CROSS_COMPILE)ld.bfd -v > /dev/null 2>&1; \ >>>>>> >>>>>> then echo "$(CROSS_COMPILE)ld.bfd"; else echo >>>> >>>> "$(CROSS_COMPILE)ld"; >>>> >>>>>> fi;) >>>>>> >>>>>> -CC = $(CROSS_COMPILE)gcc >>>>>> +CC = $(CCACHE) $(CROSS_COMPILE)gcc >>>>>> >>>>>> CPP = $(CC) -E >>>>>> AR = $(CROSS_COMPILE)ar >>>>>> NM = $(CROSS_COMPILE)nm >>>>>> >>>>>> @@ -320,7 +322,7 @@ endif >>>>>> >>>>>> ### >>>>>> # # >>>>>> >>>>>> -export HOSTCC HOSTCFLAGS HOSTLDFLAGS PEDCFLAGS HOSTSTRIP CROSS_COMPILE >>>> >>>> \ >>>> >>>>>> +export HOSTCC HOSTCFLAGS HOSTLDFLAGS PEDCFLAGS HOSTSTRIP CROSS_COMPILE >>>>>> CCACHE \ >>>>>> >>>>>> AS LD CC CPP AR NM STRIP OBJCOPY OBJDUMP MAKE >>>>>> >>>>>> export CONFIG_SYS_TEXT_BASE PLATFORM_CPPFLAGS PLATFORM_RELFLAGS >>>> >>>> CPPFLAGS >>>> >>>>>> CFLAGS AFLAGS >>>>> >>>>> Where did this patch go? I found it useful. >>>> >>>> It needs additional fixes, try running with MAKEALL and you will see the >>>> problem -- the problem is you would need separate ccache for each >>>> MAKEALL thread. >>> >>> I didn't use this patch but I modified config.mk as this patch did. MAKEALL >>> works fine for "-a powerpc". It cuts my compiling time more than half for >>> 660+ boards. >> >> That is still poor, it should be much faster. If you use separate ccache for >> each board, then it will be _much_ more performant. >> >> The problem is that when rebuilding all of those 680 configurations, the >> cached >> files get replaced by ones based on different board config all the time => >> you >> need to rebuild them => you loose performance. >> > > I kind of get it. I have to increase my ccache size a lot (more than 2GB) to > get consistent cache hit. I thought that was because I was using out-of-tree > build when setting BUILD_NBUILDS. For the first time I run MAKEALL with > ccache, it was completely miss. I mean zero hit. It would be nice to be able > hit the cache. I was read the ccache document to understand how the path is > involved when calculating the hash. How do you plan to make it work? > I forgot to mention, if the ccache size is at default (1GB), I don't see any performance improvement by using ccache. I think that's what you meant the cached files get replaced. I don't understand what you mean to use separated ccache for each board. Would it be equivalent to have a big cache? I was compiling with and without BUILD_NBUILDS, and my cache size is more than 3GB now. I could see the improvement by 2x~3x faster, but not more. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] common: Add CCACHE variable to allow use of ccache
On Aug 21, 2013, at 10:02 PM, Marek Vasut wrote: > Dear sun york-R58495, > >> On Aug 21, 2013, at 7:51 PM, Marek Vasut wrote: >>> Dear York Sun, >>> >>>> On 05/20/2013 10:25 AM, Marek Vasut wrote: >>>>> Prefix HOSTCC and CC with CCACHE variable to allow easy use of ccache. >>>>> In case the user wants to use ccache, exporting CCACHE=ccache will do >>>>> the trick. It is of course possible to either make the cross-compiler >>>>> name into a shellscript which invokes the ccache and the compiler, but >>>>> setting this variable makes use of ccache easier and more convenient. >>>>> >>>>> Using ccache becomes convenient when using MAKEALL for large build >>>>> tests, where the speedup after building the cache for the first time >>>>> is about 4-6 times. >>>>> >>>>> Signed-off-by: Marek Vasut >>>>> Cc: Tom Rini >>>>> >>>>> --- >>>>> config.mk |8 +--- >>>>> >>>>> 1 file changed, 5 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/config.mk b/config.mk >>>>> index 1fd109f..d59ded2 100644 >>>>> --- a/config.mk >>>>> +++ b/config.mk >>>>> @@ -98,6 +98,8 @@ else >>>>> >>>>> HOSTCC= gcc >>>>> endif >>>>> >>>>> +HOSTCC := $(CCACHE) $(HOSTCC) >>>>> + >>>>> >>>>> ifeq ($(HOSTOS),cygwin) >>>>> HOSTCFLAGS+= -ansi >>>>> endif >>>>> >>>>> @@ -140,13 +142,13 @@ binutils-version = $(shell $(SHELL) >>>>> $(SRCTREE)/tools/binutils-version.sh $(AS)) >>>>> >>>>> # >>>>> # Include the make variables (CC, etc...) >>>>> # >>>>> >>>>> -AS = $(CROSS_COMPILE)as >>>>> +AS = $(CCACHE) $(CROSS_COMPILE)as >>>>> >>>>> # Always use GNU ld >>>>> LD= $(shell if $(CROSS_COMPILE)ld.bfd -v > /dev/null 2>&1; \ >>>>> >>>>> then echo "$(CROSS_COMPILE)ld.bfd"; else echo >>> >>> "$(CROSS_COMPILE)ld"; >>> >>>>> fi;) >>>>> >>>>> -CC = $(CROSS_COMPILE)gcc >>>>> +CC = $(CCACHE) $(CROSS_COMPILE)gcc >>>>> >>>>> CPP = $(CC) -E >>>>> AR= $(CROSS_COMPILE)ar >>>>> NM= $(CROSS_COMPILE)nm >>>>> >>>>> @@ -320,7 +322,7 @@ endif >>>>> >>>>> ### >>>>> # # >>>>> >>>>> -export HOSTCC HOSTCFLAGS HOSTLDFLAGS PEDCFLAGS HOSTSTRIP CROSS_COMPILE >>> >>> \ >>> >>>>> +export HOSTCC HOSTCFLAGS HOSTLDFLAGS PEDCFLAGS HOSTSTRIP CROSS_COMPILE >>>>> CCACHE \ >>>>> >>>>> AS LD CC CPP AR NM STRIP OBJCOPY OBJDUMP MAKE >>>>> >>>>> exportCONFIG_SYS_TEXT_BASE PLATFORM_CPPFLAGS PLATFORM_RELFLAGS >>> >>> CPPFLAGS >>> >>>>> CFLAGS AFLAGS >>>> >>>> Where did this patch go? I found it useful. >>> >>> It needs additional fixes, try running with MAKEALL and you will see the >>> problem -- the problem is you would need separate ccache for each >>> MAKEALL thread. >> >> I didn't use this patch but I modified config.mk as this patch did. MAKEALL >> works fine for "-a powerpc". It cuts my compiling time more than half for >> 660+ boards. > > That is still poor, it should be much faster. If you use separate ccache for > each board, then it will be _much_ more performant. > > The problem is that when rebuilding all of those 680 configurations, the > cached > files get replaced by ones based on different board config all the time => > you > need to rebuild them => you loose performance. > I kind of get it. I have to increase my ccache size a lot (more than 2GB) to get consistent cache hit. I thought that was because I was using out-of-tree build when setting BUILD_NBUILDS. For the first time I run MAKEALL with ccache, it was completely miss. I mean zero hit. It would be nice to be able hit the cache. I was read the ccache document to understand how the path is involved when calculating the hash. How do you plan to make it work? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, 1/2] common: Add CCACHE variable to allow use of ccache
On Aug 21, 2013, at 7:51 PM, Marek Vasut wrote: > Dear York Sun, > >> On 05/20/2013 10:25 AM, Marek Vasut wrote: >>> Prefix HOSTCC and CC with CCACHE variable to allow easy use of ccache. >>> In case the user wants to use ccache, exporting CCACHE=ccache will do >>> the trick. It is of course possible to either make the cross-compiler >>> name into a shellscript which invokes the ccache and the compiler, but >>> setting this variable makes use of ccache easier and more convenient. >>> >>> Using ccache becomes convenient when using MAKEALL for large build >>> tests, where the speedup after building the cache for the first time >>> is about 4-6 times. >>> >>> Signed-off-by: Marek Vasut >>> Cc: Tom Rini >>> >>> --- >>> config.mk |8 +--- >>> >>> 1 file changed, 5 insertions(+), 3 deletions(-) >>> >>> diff --git a/config.mk b/config.mk >>> index 1fd109f..d59ded2 100644 >>> --- a/config.mk >>> +++ b/config.mk >>> @@ -98,6 +98,8 @@ else >>> >>> HOSTCC = gcc >>> endif >>> >>> +HOSTCC := $(CCACHE) $(HOSTCC) >>> + >>> >>> ifeq ($(HOSTOS),cygwin) >>> HOSTCFLAGS += -ansi >>> endif >>> >>> @@ -140,13 +142,13 @@ binutils-version = $(shell $(SHELL) >>> $(SRCTREE)/tools/binutils-version.sh $(AS)) >>> >>> # >>> # Include the make variables (CC, etc...) >>> # >>> >>> -AS = $(CROSS_COMPILE)as >>> +AS = $(CCACHE) $(CROSS_COMPILE)as >>> >>> # Always use GNU ld >>> LD = $(shell if $(CROSS_COMPILE)ld.bfd -v > /dev/null 2>&1; \ >>> >>> then echo "$(CROSS_COMPILE)ld.bfd"; else echo > "$(CROSS_COMPILE)ld"; >>> fi;) >>> >>> -CC = $(CROSS_COMPILE)gcc >>> +CC = $(CCACHE) $(CROSS_COMPILE)gcc >>> >>> CPP = $(CC) -E >>> AR = $(CROSS_COMPILE)ar >>> NM = $(CROSS_COMPILE)nm >>> >>> @@ -320,7 +322,7 @@ endif >>> >>> >>> # >>> >>> -export HOSTCC HOSTCFLAGS HOSTLDFLAGS PEDCFLAGS HOSTSTRIP CROSS_COMPILE > \ >>> +export HOSTCC HOSTCFLAGS HOSTLDFLAGS PEDCFLAGS HOSTSTRIP CROSS_COMPILE >>> CCACHE \ >>> >>> AS LD CC CPP AR NM STRIP OBJCOPY OBJDUMP MAKE >>> >>> export CONFIG_SYS_TEXT_BASE PLATFORM_CPPFLAGS PLATFORM_RELFLAGS > CPPFLAGS >>> CFLAGS AFLAGS >> >> Where did this patch go? I found it useful. > > It needs additional fixes, try running with MAKEALL and you will see the > problem > -- the problem is you would need separate ccache for each MAKEALL thread. I didn't use this patch but I modified config.mk as this patch did. MAKEALL works fine for "-a powerpc". It cuts my compiling time more than half for 660+ boards. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/10 v5] spl: env_common.c: make CONFIG_SPL_BUILD contain function env_import
On Aug 14, 2013, at 7:25 PM, Zhang Ying-B40530 wrote: > York, > I had checked all the patch and I am sure there is only this patch > almost forgotten. > I don't know how to do. Need I send the patch again or other way? > Thanks. > No need to resend. I can mark it. Just want to be sure there isn't a newer version hiding somewhere. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v3] command/cache: Add flush command
On Apr 7, 2013, at 1:29 AM, Wolfgang Denk wrote: > Dear sun york-R58495, > > In message > > you wrote: >> >>> Can we not split this into: >>> >>> dcache flush >>> icache invalidate >>> >>> ? This would make clear what's happening. >> >> >> The idea is to reuse existing code with minimum addition. For the applicati >> ons concerned, these two steps are both needed. Splitting them doesn't make >> things easier. > > Reusing code is a Good Thing, but not when it comes at the cost of > obfucating what the code actually does. > >> If I have to use existing command, I'd rather to put these two steps under >> icache invalide . > > No, this is not acceptable. The "icache" command deals with the IC > only, it must not meddle with the data cache (like flushing it). > I think it is best to keep this patch as it and stick with the original flush_cache name. It uses the existing function flush_cache() which is available for most (if not all) architectures. Splitting the dcache and icache not only adds more code, but architecture-dependent code. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v3] command/cache: Add flush command
On Apr 6, 2013, at 12:01 AM, Wolfgang Denk wrote: > Dear York Sun, > > In message <515f5812.8030...@freescale.com> you wrote: >> >>> adding new: >>> >>> dcache flush=> flush all >>> dcache flush=> flush range >>> >>> I think this makes more sense. Comments? >> >> It would if the command only deals with dcache. This command flushes >> dcache _and_ invalidates icache. > > Then the name "flush" is even more a bad choice. > >> If "flush_cache" is acceptable, we can use v2. If not, please suggest >> one. My candidates are "flushcache", "cacheflush". > > Can we not split this into: > > dcache flush > icache invalidate > > ? This would make clear what's happening. The idea is to reuse existing code with minimum addition. For the applications concerned, these two steps are both needed. Splitting them doesn't make things easier. If I have to use existing command, I'd rather to put these two steps under icache invalide . York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] powerpc/mpc8xxx: Enable entering DDR debugging by key press
On Jan 7, 2013, at 10:35 PM, Wolfgang Denk wrote: > Dear York Sun, > > In message <1357323245-12455-1-git-send-email-york...@freescale.com> you > wrote: >> ... >> CONFIG_FSL_DDR_INTERACTIVE needs to be defined in header file. To enter the >> debug mode by key press, press key 'd' shortly after reset, like one would >> do to abort auto booting. It is fixed to lower case 'd' at this moment. > ... >> --- a/doc/README.fsl-ddr >> +++ b/doc/README.fsl-ddr >> @@ -268,6 +268,13 @@ be activated by saving an environment variable >> "ddr_interactive". The value >> doesn't matter. Once activated, U-boot prompts "FSL DDR>" before enabling DDR >> controller. The available commands can be seen by typing "help". >> >> +Another way to enter debug mode without using environment variable is to >> send >> +a key press during boot, like one would do to abort auto boot. To save >> booting >> +time, no additioal delay is added so the window to send the key press is >> very >> +short. For example, user can send the key press using reset command >> followed by >> +hitting enter key twice. In case of power on reset, user can keep hitting >> any >> +key while applying the power. > > The documentation here does not mention the 'd' key at all. Guess it > should? > Guess I might have generated the patch from a wrong branch. Will update. Thanks, York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/i2c: Add i2c write command
Tom, It's like eeprom write but it writes to general devices, not specificly to system eeprom. I would have to use i2c mw command a lot without this. York Original Message From: Tom Rini Sent: Mon, Sep 17, 2012 05:16 PM To: sun york-R58495 CC: u-boot@lists.denx.de; u-boot-rele...@linux.freescale.net; Heiko Schocher Subject: Re: [U-Boot] [PATCH] common/i2c: Add i2c write command On Sun, Sep 16, 2012 at 01:02:30PM -0500, York Sun wrote: > Add i2c write command to write data from memory to i2c devices. > > Signed-off-by: York Sun This feels like eeprom write, to an i2c-connected eeprom. Is that what you have this for, or something else? -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl: board EEPROM has the CRC in the wrong location
On Jul 12, 2012, at 9:30 PM, Wolfgang Denk wrote: > Dear York, > > In message <9f5356fb-8ca2-44de-9089-64abd82ca...@freescale.com> you wrote: >> >> That patch itself is OK. But the comment is incorrect. We keep >> adding more mac addresses to this data structure. The CRC was at the >> end. The offset 0xCC was correct. > > This is a totally broken design then, when you have a growing data > structure where vital information fields get shifted. In such case, > the CRC should have been at the beginning, so it never changes > location. Or even better, you should not have used a binary data > structure at all (guess why the environment in U-Boot has been > implemented the way it is). I agree it was a broken design. Now we are using all available space and put CRC to the very end. It is not perfect but should work. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl: board EEPROM has the CRC in the wrong location
On Jul 12, 2012, at 3:37 PM, Scott Wood wrote: > On 07/12/2012 05:03 PM, sun york-R58495 wrote: >> Timur, >> >> That patch itself is OK. But the comment is incorrect. We keep adding more >> mac addresses to this data structure. The CRC was at the end. The offset >> 0xCC was correct. > > Is there anything in the data structure to indicate that this growth has > happened? > Discussed with Timur. The MAX_NUM_PORT was chosen as 23, probably because of a wrong math. There is no reason to use that number. Now changing to 31 will use up all the EEPROM space and push the CRC to the end, offset 0xFC. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl: board EEPROM has the CRC in the wrong location
Timur,
That patch itself is OK. But the comment is incorrect. We keep adding more mac
addresses to this data structure. The CRC was at the end. The offset 0xCC was
correct.
York
On Jul 12, 2012, at 2:46 PM, Timur Tabi wrote:
> The NXID v1 EEPROM format has the CRC at offset 0xFC, but for some reason it
> was placed at address 0xCC instead. To retain compatibility with existing
> boards, we check the CRC in the old location if necessary.
>
> Signed-off-by: Timur Tabi
> ---
> board/freescale/common/sys_eeprom.c | 28 ++--
> 1 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/board/freescale/common/sys_eeprom.c
> b/board/freescale/common/sys_eeprom.c
> index d2ed036..2541dd2 100644
> --- a/board/freescale/common/sys_eeprom.c
> +++ b/board/freescale/common/sys_eeprom.c
> @@ -34,8 +34,16 @@
> #endif
>
> #ifdef CONFIG_SYS_I2C_EEPROM_NXID
> -#define MAX_NUM_PORTS23
> +#define MAX_NUM_PORTS31
> #define NXID_VERSION 1
> +
> +/*
> + * Older versions of this code incorrectly placed the CRC at offset 0xCC,
> + * when it should have been at 0xFC. To maintain compatibility with boards
> + * that have the CRC at 0xCC, we check for the CRC at 0xCC if it's not in
> + * 0xFC.
> + */
> +#define BROKEN_CRC_OFFSET0xCC
> #endif
>
> /**
> @@ -71,7 +79,7 @@ static struct __attribute__ ((__packed__)) eeprom {
> u8 mac_count; /* 0x40Number of MAC addresses */
> u8 mac_flag; /* 0x41MAC table flags */
> u8 mac[MAX_NUM_PORTS][6]; /* 0x42 - x MAC addresses */
> - u32 crc; /* x+1 CRC32 checksum */
> + u32 crc; /* 0xFCCRC32 checksum */
> #endif
> } e;
>
> @@ -457,6 +465,22 @@ int mac_read_from_eeprom(void)
>
> crc = crc32(0, (void *)&e, crc_offset);
> crcp = (void *)&e + crc_offset;
> +#ifdef BROKEN_CRC_OFFSET
> + /*
> + * If the CRC is wrong, then check the old location. If it contains a
> + * valid CRC, then assume that this is an older EEPROM. We update the
> + * real CRC so that the EEPROM looks valid.
> + */
> + if ((e.version == NXID_VERSION) && (crc != be32_to_cpup(crcp))) {
> + u32 crc2 = crc32(0, (void *)&e, BROKEN_CRC_OFFSET);
> + void *crcp2 = (void *)&e + BROKEN_CRC_OFFSET;
> +
> + if (crc2 == be32_to_cpup(crcp2)) {
> + debug("Broken NXID v1 CRC found and corrected\n");
> + update_crc();
> + }
> + }
> +#endif
> if (crc != be32_to_cpu(*crcp)) {
> printf("CRC mismatch (%08x != %08x)\n", crc,
> be32_to_cpu(e.crc));
> return -1;
> --
> 1.7.3.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 2/3] mpc8xxx: assume unregistered DIMM for invalid SPD module_type
From: Ira W. Snyder [i...@ovro.caltech.edu] Sent: Monday, November 21, 2011 10:59 AM To: u-boot@lists.denx.de Cc: sun york-R58495 Subject: [PATCH v4 2/3] mpc8xxx: assume unregistered DIMM for invalid SPD module_type The generic Freescale DDR SDRAM SPD parsing code fails when the SPD's module_type field has an unknown value. In this case, we should assume that the memory module is an unregistered DIMM (the usual case). The DDR3 DIMM shipped with the Freescale COM Express P2020 Evaluation Kit has the module_type field set to 0x08. This is an unknown value in all documentation I can find online. Signed-off-by: Ira W. Snyder Cc: York Sun --- Isn't 0x08 72b-SO-UDIMM? York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/7] Expand POST memory test to support arch-depended implementation.
Wolfgang, Without progress indicator, slowe test on memory takes minutes and it looks like hanging. You probably don't want to run it every time the board boots up. York Sun - Original Message - From:"Wolfgang Denk" To:"York Sun" Cc:"u-boot@lists.denx.de" Sent:8/29/2010 3:56 AM Subject:Re: [U-Boot] [PATCH 2/7] Expand POST memory test to support arch-depended implementation. Dear York Sun, In message <1282944356-4020-2-git-send-email-york...@freescale.com> you wrote: > Add progress indicator for slow test. It is useful when the testing > takes too longer to finish. The indicator is reused from flash > programming. > > Hwconfig is used to turn on slow test when not enabled by flag. NAK. POST is supposed to be an automatic, unmonitored functionality. Results are suposed to be reported through a mechanism compatible to Linux' syslog system. There is no place for progress indicators here. Please note that your subject "support arch-depended implementation" and the commit message "Add progress indicator" are seriously out of sync as well. Another reason for a NAK. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] powerpc/85xx: Add memory test feature for mpc85xx.
Wolfgang, As Timur pointed out, the post framework doesn't work for us. After U-boot relocate itself to RAM, we have only 2GB memory to test. The best place is before relocation. Many other boards do that. Following your idea of reusing code, I can only reuse the test pattern generator. I am open to suggestions. York Sun - Original Message - From:"Wolfgang Denk" To:"York Sun" Cc:"Timur Tabi" , "Kumar Gala" , "u-boot@lists.denx.de" Sent:7/28/2010 4:50 PM Subject:Re: [U-Boot] [PATCH 8/8] powerpc/85xx: Add memory test feature for mpc85xx. Dear York Sun, In message <1280351179.8571.63.ca...@oslab-l1> you wrote: > > > We already have too many different implementations of a memory test in > > U-Boot, and I will not accept adding yet another one. > > > I can reuse your testing code but have to move the desired code out of > memory.c file to avoid the need for CONFIG_POST and > CONFIG_SYS_POST_MEMORY. I also add a progress indicator. My testing NAK, and NAK. Please integrate your code into the existing POST framework instead, as a number of other boards already did. A progress indicator may be a nice little toy, but how does it integrate into the POST framework? > target is 2GB at a time, up to physically memory size which is easily > over 8GB. Without progress indicator, it feels hung when it is actually > running. Yes, memory testing takes time. In the context of a power-on self test (and this is what you are doing, right?) we should take care to fit it into the existing framework, though. > Please take a look at the patch below. Instead of integrating your needs into an existing framework you invent yet another one. I don't want to have this, sorry. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de How can you tell when sour cream goes bad? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
