Re: [U-Boot] [PATCH 10/10] board/t104xrdb: Add support of NAND, SD, SPI boot for T1040RDB
Dear Prabhakar Kushwaha, Prabhakar Kushwaha freescale.com> writes: > > > On 4/1/2014 4:40 AM, Rommel G Custodio wrote: > > Dear Prabhakar Kushwaha, > > > > Prabhakar Kushwaha freescale.com> writes: > > 8>< snipped ><8 > >> +#Flush PBL data > >> +091380c0 000F > > That's a "Wait" command. > > Unless the "Flush" was command (that is in most PBI files I've read, > > Flush/Wait pait) was inadvertantly deleted. > > > > Flush command only work for CCSRBAR address space. It should not be used > for CPC-SRAM. > > This is the reason, it has been removed. Does this affect all mpc85xx cores? I've noticed this same weird behavior on a T1040QDS. A simple write to CPC-SRAM before a Flush command causes the LEDs to report an error. i.e 8900 4bfff004 09138000 091380c0 0001 After putting the CPC-SRAM write after the Flush the write was successful (as verified by a BDI-3000). i.e 09138000 091380c0 0001 8900 4bfff004 091380c0 0001 BUT it seems this does not occur on the P5040DS. The P5040DS_SPIFLASH creates a u-boot that has Flush commands and it boots correctly. [local]$ xxd -g4 obj-P5040DS_SPIFLASH/u-boot.pbl : 00cc0a0: 81c0 00cc0b0: 00cc0c0: 00cc0d0: 00cc0e0: 4bfff004 09138000 K... 00cc0f0: 091380c0 08138040 aa69eb89 ...@.i.. On another note, if this affects all mpc85xx cores then I guess tools/pblimage.c needs updating. The add_end_cmd() always adds a Flush command prior to a CRC check (CONT=0) command. > > Regards, > Prabhakar > All the best, Rommel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] dfu: add static alt num count in dfu_config_entities()
On Tuesday, April 01, 2014 at 08:47:05 AM, Przemyslaw Marczak wrote: > Hello, > This code was applied to u-boot-samsung few weeks ago. Please do NOT top-post. Why did it arrive in the ML yesterday ? > On 03/31/2014 11:15 AM, Lukasz Majewski wrote: > > Hi Marek, > > > >> On Monday, March 31, 2014 at 10:48:48 AM, Lukasz Majewski wrote: > >>> From: Przemyslaw Marczak > >>> > >>> Thanks to this multiple calls of function dfu_config_entities() give > >>> continuous dfu alt numbering until call dfu_free_entities(). > >>> > >>> This allows to store dfu entities in multiple env variables. > >>> > >>> Change-Id: Ibca7e785bfca9f53b64d3dff0490185b06841b54 > >>> Signed-off-by: Przemyslaw Marczak > >>> --- > >>> > >>> drivers/dfu/dfu.c |6 +- > >>> 1 file changed, 5 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c > >>> index f94c412..e15f959 100644 > >>> --- a/drivers/dfu/dfu.c > >>> +++ b/drivers/dfu/dfu.c > >>> @@ -19,6 +19,7 @@ > >>> > >>> static bool dfu_reset_request; > >>> static LIST_HEAD(dfu_list); > >>> static int dfu_alt_num; > >>> > >>> +static int alt_num_count; > >> > >> Can the variable name here be any less consistent with the > >> rest ... ? ;-) > > > > I think, that something like dfu_alt_num_cnt would fit better there. > > > >> [...] > >> > >> Best regards, > >> Marek Vasut > > Thanks Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] dfu: add static alt num count in dfu_config_entities()
Hello, This code was applied to u-boot-samsung few weeks ago. On 03/31/2014 11:15 AM, Lukasz Majewski wrote: Hi Marek, On Monday, March 31, 2014 at 10:48:48 AM, Lukasz Majewski wrote: From: Przemyslaw Marczak Thanks to this multiple calls of function dfu_config_entities() give continuous dfu alt numbering until call dfu_free_entities(). This allows to store dfu entities in multiple env variables. Change-Id: Ibca7e785bfca9f53b64d3dff0490185b06841b54 Signed-off-by: Przemyslaw Marczak --- drivers/dfu/dfu.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c index f94c412..e15f959 100644 --- a/drivers/dfu/dfu.c +++ b/drivers/dfu/dfu.c @@ -19,6 +19,7 @@ static bool dfu_reset_request; static LIST_HEAD(dfu_list); static int dfu_alt_num; +static int alt_num_count; Can the variable name here be any less consistent with the rest ... ? ;-) I think, that something like dfu_alt_num_cnt would fit better there. [...] Best regards, Marek Vasut Thanks -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marc...@samsung.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: mpc8xx: delete an unused source file
Dear Masahiro, In message <1396238924-12140-1-git-send-email-yamad...@jp.panasonic.com> you wrote: > Signed-off-by: Masahiro Yamada > Cc: Wolfgang Denk > --- > arch/powerpc/cpu/mpc8xx/wlkbd.c | 20 > 1 file changed, 20 deletions(-) > delete mode 100644 arch/powerpc/cpu/mpc8xx/wlkbd.c I just realized this patch should also remove references to the wireless keyboard driver from the documentation, i. e. something like diff --git a/doc/README.console b/doc/README.console index c9ef59e..e7970ed 100644 --- a/doc/README.console +++ b/doc/README.console @@ -25,7 +25,7 @@ stdout or stderr) to any device you see in that list simply by assigning its name to the corresponding environment variable. For example: -setenv stdin wl_kbd<- To use the wireless keyboard +setenv stdin serial<- To use the serial input setenv stdout video<- To use the video console Do a simple "saveenv" to save the console settings in the environment Can you please add this? Thanks. 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 "Here's a fish hangs in the net like a poor man's right in the law. 'Twill hardly come out." - Shakespeare, Pericles, Act II, Scene 1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANN] U-Boot v2014.04-rc3 released
Dear Tom, In message <20140331195316.GZ16360@bill-the-cat> you wrote: > > I've pushed v2014.04-rc3 out to the repository and tarballs should exist > soon. Tarball is out. Thanks! 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 is this place run - is it an anarchy?" "No, I wouldn't say so; it is not that well organised..." ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/9] i2c, davinci: convert driver to new mutlibus/mutliadapter framework
Hello Murali, Am 31.03.2014 22:23, schrieb Karicheri, Muralidharan: -Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Monday, March 31, 2014 1:24 AM To: Karicheri, Muralidharan Cc: Rini, Tom; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH v4 6/9] i2c, davinci: convert driver to new mutlibus/mutliadapter framework Hello Mruali, Heiko, Thanks for reviewing this. See below for my response. BTW, there is a Typo, it should have been Hello Murali, :) Oh, Sorry for that. Am 27.03.2014 16:59, schrieb Murali Karicheri: From: Vitaly Andrianov - add davinci driver to new multibus/multiadpater support - adapted all config files, which uses this driver Signed-off-by: Vitaly Andrianov Signed-off-by: Murali Karicheri --- arch/arm/cpu/arm926ejs/davinci/dm355.c |2 +- arch/arm/cpu/arm926ejs/davinci/dm365.c |2 +- arch/arm/cpu/arm926ejs/davinci/dm644x.c |2 +- arch/arm/cpu/arm926ejs/davinci/dm646x.c |2 +- drivers/i2c/Makefile|2 +- drivers/i2c/davinci_i2c.c | 401 ++- drivers/i2c/davinci_i2c.h | 27 ++- include/configs/cam_enc_4xx.h |8 +- include/configs/da830evm.h |8 +- include/configs/da850evm.h |8 +- include/configs/davinci_dm355evm.h |8 +- include/configs/davinci_dm355leopard.h |8 +- include/configs/davinci_dm365evm.h |8 +- include/configs/davinci_dm6467evm.h |8 +- include/configs/davinci_dvevm.h |8 +- include/configs/davinci_schmoogie.h |8 +- include/configs/davinci_sffsdr.h|8 +- include/configs/davinci_sonata.h|8 +- include/configs/ea20.h |6 +- include/configs/enbw_cmc.h |8 +- 20 files changed, 305 insertions(+), 235 deletions(-) This is your v4 post ... some sort of history, what has changed would be nice ... The history is maintained for the series that is part of the cover letter. I have reproduced it below for your convenience. Thanks, but it is not only for my convenience, see here for a help, how to send updated patches: http://www.denx.de/wiki/view/U-Boot/Patches#Sending_updated_patch_versions Change history: v4 - Added multibus support in i2c driver. Tested only on Keystone - Added comments to fdt patch v3 - Seperated network driver patches from the original series and and is now a different set as there are outstanding issues to be discussed and sorted out. Also the original series is ready for merge to upstream IMO. - Review comments incorporated. Following are the major comments addressed - Added KBUILD target for u-boot-spi.gph - Added bootup and flashing instructions in README - Cleaned up manually replacing #define with #define - Cleaned up k2hk_evm.h include file to remove unnecessary options v2 - Review comments incorporated. Following are major comments addressed - split network driver to navigator driver + ethernet driver - replaced register base + offset implemenation with struct based register access implementation - Added Readme for NAND no subpage write option - re-use code for davinci i2c driver on keystone2 with updates - clock-k2hk.c merged to clock.c - currently keeping board specific getclk() command. See the thread for the rational. - Added update to davinci spi driver to re-use on keystone v1 - added separate patch for sorting tools/Makefile entries - reworked gpimage patch to allow more re-use across omapimage/gpimage - dropped patch related to ubifs file size - added keystone SoC and K2HK EVM support v0 - preparatory patch for keystone [...] diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile index 36d5e5f..fd1cb11 100644 --- a/drivers/i2c/Makefile +++ b/drivers/i2c/Makefile @@ -6,7 +6,7 @@ # obj-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o -obj-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o +obj-$(CONFIG_SYS_I2C_DAVINCI) += davinci_i2c.o please keep lists sorted. Are you asking me to sort the entire Makefile based on file name? davinci_i2c.o is at No. the correct alphabetical position right now. Or are you expecting this to be sorted based on CONFIG_SYS_ ? Yes. If so, I could change as obj-$(CONFIG_SYS_I2C) += i2c_core.o obj-$(CONFIG_SYS_I2C_DAVINCI) += davinci_i2c.o obj-$(CONFIG_SYS_I2C_FSL) += fsl_i2c.o obj-$(CONFIG_SYS_I2C_FTI2C010) += fti2c010.o Please confirm. If sort by file name, then I am missing something. Yep, thats it! [...] Rest looks Ok for me ... i
Re: [U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus
Hello Lukasz, Am 31.03.2014 16:36, schrieb Lukasz Majewski: Hi Simon, Hi Lukasz, On 27 March 2014 11:33, Lukasz Majewski wrote: Hi Simon, Heiko From: Aaron Durbin The current pmic i2c code assumes the current i2c bus is the same as the pmic device's bus. There is nothing ensuring that to be true. Therefore, select the proper bus before performing a transaction. Signed-off-by: Aaron Durbin Signed-off-by: Simon Glass Reviewed-by: Simon Glass --- drivers/power/power_i2c.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c index ac76870..594cd11 100644 --- a/drivers/power/power_i2c.c +++ b/drivers/power/power_i2c.c @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val) if (check_reg(p, reg)) return -1; + I2C_SET_BUS(p->bus); + Hadn't we had a discussion about this explicit setting of I2C some time ago? I thought that this problem was solved within the I2C rework. Also I might be wrong, so please correct me if I'm wrong. Isn't the I2C_SET_BUS() macro regarded as a obsolete after the I2C rework? Agreed that would be ideal, but we would have to pass the bus number of the i2c_read/write() functions. I don't believe the i2c code has got that far yet. Unfortunately it doesn't work without this patch. If Heiko doesn't object, then I won't protest. It s okay for me, so to clarify: Acked-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus
Hello Lukasz, Am 31.03.2014 08:17, schrieb Lukasz Majewski: Hi Heiko, Hello Simon, Lukasz, Am 30.03.2014 01:17, schrieb Simon Glass: Hi Lukasz, On 27 March 2014 11:33, Lukasz Majewski wrote: Hi Simon, Heiko From: Aaron Durbin The current pmic i2c code assumes the current i2c bus is the same as the pmic device's bus. There is nothing ensuring that to be true. Therefore, select the proper bus before performing a transaction. Signed-off-by: Aaron Durbin Signed-off-by: Simon Glass Reviewed-by: Simon Glass --- drivers/power/power_i2c.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c index ac76870..594cd11 100644 --- a/drivers/power/power_i2c.c +++ b/drivers/power/power_i2c.c @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 val) if (check_reg(p, reg)) return -1; + I2C_SET_BUS(p->bus); + Hadn't we had a discussion about this explicit setting of I2C some time ago? I thought that this problem was solved within the I2C rework. Also I might be wrong, so please correct me if I'm wrong. Isn't the I2C_SET_BUS() macro regarded as a obsolete after the I2C rework? Agreed that would be ideal, but we would have to pass the bus number of the i2c_read/write() functions. I don't believe the i2c code has got that far yet. Yes, thats the plan, but first, all i2c driver must be converted to the new framework. After that we could start with such an approach (or device model is ready and we can switch to it ...) I know that there is a time line for introducing device model, but is there any for switching I2C to the new approach? I am not aware of a plan ... I think about deleting obsolete/unmaintained boards, which will not switch to new I2C approach. Hmm... this would be a long list, as there are the following driver which need a conversion: obj-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o obj-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o obj-$(CONFIG_DW_I2C) += designware_i2c.o obj-$(CONFIG_I2C_MVTWSI) += mvtwsi.o obj-$(CONFIG_I2C_MV) += mv_i2c.o obj-$(CONFIG_I2C_MXS) += mxs_i2c.o obj-$(CONFIG_PCA9564_I2C) += pca9564_i2c.o obj-$(CONFIG_TSI108_I2C) += tsi108_i2c.o obj-$(CONFIG_U8500_I2C) += u8500_i2c.o obj-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o Also some drivers in cpu dirs ... grep for HARD_I2C in u-boot source (one Goal is to get rid of HARD_I2C). ./arch/powerpc/cpu/mpc8xx/i2c.c ./arch/powerpc/cpu/mpc8260/commproc.c ./arch/powerpc/cpu/mpc8260/i2c.c ./arch/powerpc/cpu/mpc5xxx/i2c.c ./arch/powerpc/cpu/mpc824x/drivers/i2c/i2c.c ./arch/powerpc/cpu/mpc512x/i2c.c [...] bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] board/t104xrdb: Add support of NAND, SD, SPI boot for T1040RDB
On 4/1/2014 5:14 AM, Rommel G Custodio wrote: Rommel G Custodio gmail.com> writes: Dear Prabhakar Kushwaha, Prabhakar Kushwaha freescale.com> writes: Add support of 2 stage NAND, SD, SPI boot loader using SPL framework. here, PBL initialise the internal SRAM and copy SPL(160KB). This further initialise DDR using SPD and environment and copy u-boot(768 KB) from NAND to DDR. Finally SPL transer control to u-boot. This patch does not apply to HEAD. Arrggh ... guess I think I need this [U-BOOT] [PATCH v3] powerpc/t104xrdb: Unification ofT104xRDB header files You may also need below patches in sequence [U-Boot,U-BOOT,v3] powerpc/t104xrdb: Unification of T104xRDB header files [U-Boot] powerpc/mpc85xx:Add CONFIG_SYS_FSL_ERRATUM_ESDHC111 to Txx/Bxx [U-Boot,01/2] powerpc/mpc85xx:Avoid fix address of bootpg section [U-Boot,2/2] powerpc/mpc85xx:Update MONITOR_LEN [U-Boot] driver/mmc: fix compile warnings + 2 stage boot loader patch set Please let me know, if any other information is required. Regards, Prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] board/t104xrdb: Add support of NAND, SD, SPI boot for T1040RDB
On 4/1/2014 4:40 AM, Rommel G Custodio wrote: Dear Prabhakar Kushwaha, Prabhakar Kushwaha freescale.com> writes: Add support of 2 stage NAND, SD, SPI boot loader using SPL framework. here, PBL initialise the internal SRAM and copy SPL(160KB). This further initialise DDR using SPD and environment and copy u-boot(768 KB) from NAND to DDR. Finally SPL transer control to u-boot. This patch does not apply to HEAD. [u-boot (X_2stage $)]$ pw_u.sh 335250 2014-04-01 07:11:13 URL:http://patchwork.ozlabs.org/patch/335250/mbox/ [23256] -> "pw-am-335250.patch" [1] Applying: board/t104xrdb: Add support of NAND, SD, SPI boot for T1040RDB error: patch failed: boards.cfg:933 error: boards.cfg: patch does not apply error: include/configs/T104xRDB.h: does not exist in index More comments below. 8>< snipped ><8 diff --git a/board/freescale/t104xrdb/t1040_rcw.cfg b/board/freescale/t104xrdb/t1040_rcw.cfg new file mode 100644 index 000..3300c18 --- /dev/null +++ b/board/freescale/t104xrdb/t1040_rcw.cfg -0,0 +1,7 +#PBL preamble and RCW header +aa55aa55 010e0100 +# serdes protocol 0x66 +0c18000e 0e00 +6602 8002 e8106000 0100 e8106000 Don't you need a separate RCW setting for SPI? The previous patchset had a note about it. You can change. Generally switch has higher precedence over PBI_SRC in RCW. + 00032810 + 0342500f diff --git a/board/freescale/t104xrdb/t1042_rcw.cfg b/board/freescale/t104xrdb/t1042_rcw.cfg new file mode 100644 index 000..a3ea8ad --- /dev/null +++ b/board/freescale/t104xrdb/t1042_rcw.cfg -0,0 +1,7 +#PBL preamble and RCW header +aa55aa55 010e0100 +# serdes protocol 0x66 +0c18000e 0e00 +0602 0042 e8106000 0100 + 00030810 + 01fe0a06 diff --git a/board/freescale/t104xrdb/t104x_pbi.cfg b/board/freescale/t104xrdb/t104x_pbi.cfg new file mode 100644 index 000..7b9e9b0 --- /dev/null +++ b/board/freescale/t104xrdb/t104x_pbi.cfg -0,0 +1,26 +#PBI commands +#Initialize CPC1 +0901 00200400 +09138000 +091380c0 0100 +#Configure CPC1 as 256KB SRAM +09010100 +09010104 fffc0007 +09010f00 0800 +0901 8000 +#Configure LAW for CPC1 +09000cd0 +09000cd4 fffc +09000cd8 8111 +#Configure alternate space +0910 +0914 ff00 +0918 8100 +#Configure SPI controller +0911 8403 +09110020 2d170008 +09110024 0018 +09110028 0018 +0911002c 0018 +#Flush PBL data +091380c0 000F That's a "Wait" command. Unless the "Flush" was command (that is in most PBI files I've read, Flush/Wait pait) was inadvertantly deleted. Flush command only work for CCSRBAR address space. It should not be used for CPC-SRAM. This is the reason, it has been removed. Regards, Prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] tools: fix Makefile to clean-up fit_info and fit_check_sign
We should avoid the description in Makefile like this ifdef CONFIG_FIT_SIGNATURE hostprogs-y += fit_info$(SFX) fit_check_sign$(SFX) endif Otherwise, fit_info and fit_check_sign would never be cleaned by "make clean". Signed-off-by: Masahiro Yamada Cc: Heiko Schocher --- This patch is against u-boot/next Changes in v2: - Add Signed-off-by tools/Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index c5c378c..c34df4f 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -60,9 +60,7 @@ hostprogs-y += mkenvimage$(SFX) mkenvimage$(SFX)-objs := crc32.o mkenvimage.o os_support.o hostprogs-y += dumpimage$(SFX) mkimage$(SFX) -ifdef CONFIG_FIT_SIGNATURE -hostprogs-y += fit_info$(SFX) fit_check_sign$(SFX) -endif +hostprogs-$(CONFIG_FIT_SIGNATURE) += fit_info$(SFX) fit_check_sign$(SFX) FIT_SIG_OBJS-$(CONFIG_FIT_SIGNATURE) := image-sig.o # Flattened device tree objects -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] board/t104xrdb: Add support of NAND, SD, SPI boot for T1040RDB
Rommel G Custodio gmail.com> writes: > > Dear Prabhakar Kushwaha, > > Prabhakar Kushwaha freescale.com> writes: > > > > > Add support of 2 stage NAND, SD, SPI boot loader using SPL framework. > > here, PBL initialise the internal SRAM and copy SPL(160KB). This further > > initialise DDR using SPD and environment and copy u-boot(768 KB) from NAND > to DDR. > > Finally SPL transer control to u-boot. > > This patch does not apply to HEAD. Arrggh ... guess I think I need this [U-BOOT] [PATCH v3] powerpc/t104xrdb: Unification ofT104xRDB header files > > [u-boot (X_2stage $)]$ pw_u.sh 335250 > 2014-04-01 07:11:13 URL:http://patchwork.ozlabs.org/patch/335250/mbox/ > [23256] -> "pw-am-335250.patch" [1] > Applying: board/t104xrdb: Add support of NAND, SD, SPI boot for T1040RDB > error: patch failed: boards.cfg:933 > error: boards.cfg: patch does not apply > error: include/configs/T104xRDB.h: does not exist in index > > More comments below. > 8>< snipped ><8 All the best, Rommel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting
On Mon, 31 Mar 2014 14:05:17 -0400 Tom Rini wrote: > On Mon, Mar 31, 2014 at 10:48:49AM +0200, Lukasz Majewski wrote: > > > Up till now the CRC32 of received data was calculated > > unconditionally. The standard crc32 implementation causes long > > delays when large images were uploaded. > > > > The "dfu_checksum_method" environment variable gives the > > opportunity to enable on demand (when e.g. debugging) the crc32 > > calculation. It can be done without need to recompile the u-boot > > binary. > > > > By default the crc32 is not calculated. > > > > Tests results: > > 400 MiB ums.img file > > Withcrc32 calculation: 65 sec [avg 6.29 MB/s] > > Without crc32 calculation: 25 sec [avg 16.17 MB/s] > > > > Signed-off-by: Lukasz Majewski > > OK, so, protocol question. The DFU 1.1 standard in its appendinx B specifies the DFU suffix. It has the crc32 for the whole file, vendorID, device ID and other handy fields. Unfortunately, this part of the standard is not supported neither at dfu implementation in u-boot nor dfu-util (v.0.5 - debian). It would be handy for small files (like bootloaders, kernels) where we download all the data at once. For critical files it should be definitely implemented. From my glimpse observation the dfu-util would require some extension to support the DFU suffix (Tormod, please correct me if I'm wrong). For large files (400 MiB in this case) it is useless since we store data as it goes (with 32 MiB chunks). Also, as we send the large files we experience the biggest performance penalty from CRC32 calculation. It takes considerable time and in my opinion now serves only for debug purposes, to provide the final CRC for comparison with original one, even though the file is already on flash. When we use CRC in such a way, we should be able to decide which tool (algorithm) use for debug. SHA1, MD5, etc are widely available on each linux box. To have the same crc32 algorithm, which is in u-boot, implemented as linux command line tool you need to search a bit (libarchive-zip-perl package for debian). I think that we can improve the crc32 performance with calculating it for smaller chunks, which already fits L1 cache. Now they are calculated for 32 MiB. > What's going on in the background here > such that it's a good and safe idea to not do this checksum and we > won't end up in the case where data was corrupted and we just bricked > a board in update mode? Now we rely solely on testing. Downloading file, checking CRC and compare with original. I also have some automated tests, which utilize MD5. TO SUM UP: 1. Handling of the DFU suffix shall be implemented and utilized in both u-boot and dfu-util with critical files (bootloaders, kernel). 2. There should be freedom to use different checksum algorithms for providing debugging information. 3. The current CRC32 calculation at DFU should be optimized. > Best regards, Lukasz Majewski signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/10] board/t104xrdb: Add support of NAND, SD, SPI boot for T1040RDB
Dear Prabhakar Kushwaha, Prabhakar Kushwaha freescale.com> writes: > > Add support of 2 stage NAND, SD, SPI boot loader using SPL framework. > here, PBL initialise the internal SRAM and copy SPL(160KB). This further > initialise DDR using SPD and environment and copy u-boot(768 KB) from NAND to DDR. > Finally SPL transer control to u-boot. This patch does not apply to HEAD. [u-boot (X_2stage $)]$ pw_u.sh 335250 2014-04-01 07:11:13 URL:http://patchwork.ozlabs.org/patch/335250/mbox/ [23256] -> "pw-am-335250.patch" [1] Applying: board/t104xrdb: Add support of NAND, SD, SPI boot for T1040RDB error: patch failed: boards.cfg:933 error: boards.cfg: patch does not apply error: include/configs/T104xRDB.h: does not exist in index More comments below. 8>< snipped ><8 > diff --git a/board/freescale/t104xrdb/t1040_rcw.cfg b/board/freescale/t104xrdb/t1040_rcw.cfg > new file mode 100644 > index 000..3300c18 > --- /dev/null > +++ b/board/freescale/t104xrdb/t1040_rcw.cfg > -0,0 +1,7 > +#PBL preamble and RCW header > +aa55aa55 010e0100 > +# serdes protocol 0x66 > +0c18000e 0e00 > +6602 8002 e8106000 0100 e8106000 Don't you need a separate RCW setting for SPI? The previous patchset had a note about it. > + 00032810 > + 0342500f > diff --git a/board/freescale/t104xrdb/t1042_rcw.cfg b/board/freescale/t104xrdb/t1042_rcw.cfg > new file mode 100644 > index 000..a3ea8ad > --- /dev/null > +++ b/board/freescale/t104xrdb/t1042_rcw.cfg > -0,0 +1,7 > +#PBL preamble and RCW header > +aa55aa55 010e0100 > +# serdes protocol 0x66 > +0c18000e 0e00 > +0602 0042 e8106000 0100 > + 00030810 > + 01fe0a06 > diff --git a/board/freescale/t104xrdb/t104x_pbi.cfg b/board/freescale/t104xrdb/t104x_pbi.cfg > new file mode 100644 > index 000..7b9e9b0 > --- /dev/null > +++ b/board/freescale/t104xrdb/t104x_pbi.cfg > -0,0 +1,26 > +#PBI commands > +#Initialize CPC1 > +0901 00200400 > +09138000 > +091380c0 0100 > +#Configure CPC1 as 256KB SRAM > +09010100 > +09010104 fffc0007 > +09010f00 0800 > +0901 8000 > +#Configure LAW for CPC1 > +09000cd0 > +09000cd4 fffc > +09000cd8 8111 > +#Configure alternate space > +0910 > +0914 ff00 > +0918 8100 > +#Configure SPI controller > +0911 8403 > +09110020 2d170008 > +09110024 0018 > +09110028 0018 > +0911002c 0018 > +#Flush PBL data > +091380c0 000F That's a "Wait" command. Unless the "Flush" was command (that is in most PBI files I've read, Flush/Wait pait) was inadvertantly deleted. 8>< snipped ><8 All the best, Rommel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] armv8: Flush dcache before switching to EL2
For ARMv8, U-boot has been running at EL3 with cache and MMU enabled. Without proper setup for EL2, cache and MMU are both disabled (out of reset). Before switching, we need to flush the dcache to make sure the data is in the main memory. Signed-off-by: York Sun --- arch/arm/lib/bootm.c |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c index a8295bf..9782ddb 100644 --- a/arch/arm/lib/bootm.c +++ b/arch/arm/lib/bootm.c @@ -199,6 +199,7 @@ static void do_nonsec_virt_switch(void) #ifdef CONFIG_ARM64 smp_kick_all_cpus(); + flush_dcache_all(); /* flush cache before swtiching to EL2 */ armv8_switch_to_el2(); #ifdef CONFIG_ARMV8_SWITCH_TO_EL1 armv8_switch_to_el1(); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting
On Mon, Mar 31, 2014 at 10:44 PM, Lukasz Majewski wrote: > The DFU 1.1 standard in its appendinx B specifies the DFU suffix. It has > the crc32 for the whole file, vendorID, device ID and other handy > fields. > > Unfortunately, this part of the standard is not supported neither at > dfu implementation in u-boot nor dfu-util (v.0.5 - debian). > > It would be handy for small files (like bootloaders, kernels) where we > download all the data at once. For critical files it should be > definitely implemented. From my glimpse observation the dfu-util would > require some extension to support the DFU suffix (Tormod, please > correct me if I'm wrong). You are wrong :) Please don't use what's available in Debian (stable?) as a reference. I don't know what their maintainer is up to. dfu-util supports the DFU suffix according to the DFU standard. That means it checks the CRC after reading the file, and also checks that vendor/product values match, then sends the firmware to the device after stripping off the suffix. Are you wanting to do some CRC checking at the device side? That would be outside the DFU standard. But you can always put whatever you want in the "firmware", including proprietary headers or suffices. We already support some of those, please see the dfu-util (and dfu-suffx/dfu-prefix) code at dfu-util.gnumonks.org. Regards, Tormod ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.
Hi Simon, On Mon, 31 Mar 2014 11:27:11 -0600 Simon Glass wrote: > Hi Lukasz, > > On 31 March 2014 08:33, Lukasz Majewski > wrote: [snip] > > > > > > > > This can be easily added to be used at "pmic bat charge" command. > > > > > > Please look into the ./drivers/power/mfd/pmic_max77693.c > > > > > > Not easily. As mentioned above this is quite a bit of work. For a > > > later series I think. > > > > I'm looking forward for questions :-). > > > > Do you think you might submit a patch that adds comments to the header > files? That would help a lot. I will do my best. Up till then would you consider looking at the following link: http://u-boot.10912.n7.nabble.com/PATCH-v7-00-26-pmic-Redesign-PMIC-framework-to-support-multiple-instances-of-devices-tt140662.html#none It should shed some light on the PMIC design. > > Also now that driver model is merged, do you think we should try to > move PMICs to that, or would it be a later step? PMIC should be integrated with the device model. Also it shall support DT. When it will happen depends on the effort needed. Help more than welcome. > > Regards, > Simon Best regards, Lukasz Majewski signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] imx-common: cpu: add fdt_file environment variable
On 3/31/2014 12:47 PM, Marek Vasut wrote:
> On Monday, March 31, 2014 at 09:38:02 PM, Otavio Salvador wrote:
>> On Mon, Mar 31, 2014 at 4:22 PM, Marek Vasut wrote:
>>> On Monday, March 31, 2014 at 08:36:55 PM, Troy Kisky wrote:
On 3/29/2014 4:11 PM, Eric Nelson wrote:
> Hi Troy,
>
> On 03/29/2014 03:34 PM, Troy Kisky wrote:
>> This removes one block in the move toward 1 u-boot
>> for both a mx6q (quad) and mx6dl (duallite) processor.
>>
>> Now fdt_file hardcoded value can be removed.
>>
>> Signed-off-by: Troy Kisky
>> ---
>>
>> arch/arm/imx-common/cpu.c | 44
>> arch/arm/lib/board.c
>>
>>| 7 +++
>>
>> 2 files changed, 51 insertions(+)
>>
>> diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
>> index a77c4de..5d48011 100644
>> --- a/arch/arm/imx-common/cpu.c
>> +++ b/arch/arm/imx-common/cpu.c
>> @@ -180,3 +180,47 @@ void arch_preboot_os(void)
>>
>> ipuv3_fb_shutdown();
>>
>> }
>> #endif
>>
>> +
>> +const char *get_dtb_prefix(u32 imxtype)
>> +{
>> +switch (imxtype) {
>> +case MXC_CPU_MX6Q:
>> +case MXC_CPU_MX6D:
>> +return "imx6q";/* Quad/Dual-core version of the mx6
>> */ +case MXC_CPU_MX6DL:
>> +case MXC_CPU_MX6SOLO:
>> +return "imx6dl";/* Dual Lite/Solo version of the mx6 */
>> +case MXC_CPU_MX6SL:
>> +return "imx6sl";/* Solo-Lite version of the mx6 */
>> +case MXC_CPU_MX51:
>> +return "imx51";
>> +case MXC_CPU_MX53:
>> +return "imx53";
>> +}
>> +return "??";
>> +}
>> +
>
> I really dislike this implementation of naming policy in code.
It is not truly a policy. It is a convenience which can be ignored
if so desired. Though I do agree that cpu and board environment
variables would also be useful. Still, a cpu variable would still
require some scripting to combine the quad/dual, duallite/solo. So,
your way is not as convenient for dtb file names.
>>>
>>> You can make the CPU code set the CPU type into some variable.
>>> Afterwards, some scripts in the HUSH can assemble the DTB name based on
>>> those variables. This would be much more generic and re-usable than this
>>> ...
>>
>> The problem is this script will be mostly the same for most boards.
>
> This does by no means justify poluting code with non-reusable convoluted
> stuff.
> A script which is part of the environment can be tweaked on a running system
> as
> seen fit at any later date, updating bootloader on a running system is often
> not
> an option.
>
> Furthermore, having partial information which can be used for decisionmaking
> is
> much better than having a lengthy string which needs to be parsed first.
> Especially with the limited parsing options we have in some configurations of
> U-
> Boot.
>
I can agree to that, if I understand you correctly. So are you fine with having
a board and
cpu variable? If so, what should the cpu variable contain?
I propose cpu defaults to "IMX%s", get_imx_type(imxtype)
so cpu=IMX6Q, IMX6D, IMX6DL, IMX6SOLO, IMX6SL, IMX51, IMX53
and board defaults to plain CONFIG_SYS_BOARD. So, mx6sabresd
would need to set board=sabresd.
in mx6sabresd.h
setenv board=sabresd
and in some common file
setenv dtbpIMX6Q setenv dtbprefix imx6q
setenv dtbpIMX6D setenv dtbprefix imx6d
setenv dtbpIMX6DL setenv dtbprefix imx6dl
setenv dtbpIMX6SOLO setenv dtbprefix imx6dl
setenv dtbpIMX6SL setenv dtbprefix imx6sl
setenv find_dtb_file 'run dtbp${cpu} ; setenv fdt_file $dtbprefix-$board'
run find_dtb_file
echo $fdt_file
Or if you know a better way please speak up.
Thanks
Troy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/31/2014 04:44 PM, Lukasz Majewski wrote: > On Mon, 31 Mar 2014 14:05:17 -0400 > Tom Rini wrote: > >> On Mon, Mar 31, 2014 at 10:48:49AM +0200, Lukasz Majewski wrote: >> >>> Up till now the CRC32 of received data was calculated >>> unconditionally. The standard crc32 implementation causes long >>> delays when large images were uploaded. >>> >>> The "dfu_checksum_method" environment variable gives the >>> opportunity to enable on demand (when e.g. debugging) the crc32 >>> calculation. It can be done without need to recompile the u-boot >>> binary. >>> >>> By default the crc32 is not calculated. >>> >>> Tests results: >>> 400 MiB ums.img file >>> Withcrc32 calculation: 65 sec [avg 6.29 MB/s] >>> Without crc32 calculation: 25 sec [avg 16.17 MB/s] >>> >>> Signed-off-by: Lukasz Majewski >> >> OK, so, protocol question. > > The DFU 1.1 standard in its appendinx B specifies the DFU suffix. It has > the crc32 for the whole file, vendorID, device ID and other handy > fields. > > Unfortunately, this part of the standard is not supported neither at > dfu implementation in u-boot nor dfu-util (v.0.5 - debian). OK, so this is the important part. We're doing a crc32 on stuff that's not required by spec, just handy for verification, manually. [snip] > When we use CRC in such a way, we should be able to decide which tool > (algorithm) use for debug. SHA1, MD5, etc are widely available on each > linux box. To have the same crc32 algorithm, which is in u-boot, > implemented as linux command line tool you need to search a bit > (libarchive-zip-perl package for debian). I take your point, but I use rhash -C to get matching crc32 and it was the first thing I stumbled upon when going "oh right, what does crc32?". [snip] > TO SUM UP: > > 1. Handling of the DFU suffix shall be implemented and utilized in both > u-boot and dfu-util with critical files (bootloaders, kernel). > > 2. There should be freedom to use different checksum algorithms for > providing debugging information. > > 3. The current CRC32 calculation at DFU should be optimized. Well, is there work being done on the dfu-util side currently or planned in the near future to do #1 per the spec? But, with that, I'm happier to default to no crc32'ing the data for today. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTOdhmAAoJENk4IS6UOR1WDsYP/2eg3v+K5nCUZ22eYnrY4s14 f8KUan8My7Ifr/to9qbAIFsSuw5mlLPvYy5JNnrbmmipDH2bQIO20R1t94/Mm8Ut Hoj1nbGZ3JvMsoj86D+9pFz2AchVgbpvs+boiJGw2s1TZ3xKoNlJ1O4WJ8ttZRZS 1B3FC50PKYJK6lgWgfvds2AevLIAcF1QyePVsOLVKV2USilFiZ1LVb8qUFp5l6Ja LX3wfQjhPq4gQq8bX7LW6zNbDkXuZjxLlKT/kUxzl2qclpHj4+8rXVVRf1mLaLvU Dvx50V/JCncIivRBhfvK2BoQ/LOntmPwGfO95AY57naP9+nCzzE9vdKv/Ki5vpju /q/CjlXbkS4iwru+91neyMdfeCiiALV2yW0GBORgph7kCpUk343S753epl/MFmAW rOQ0xBjw4q5KeXijtQG5bdevynPkB09soKKhQX5XRe7i8olXe32+khQVwqpomjkG v0YbKvUTuCZ1NNZqEey/zO4gJPR2Tq4QiNFpfFPvcYOqlqoC/C84HfO+M8ocKiUh SUgdaUQI+uP7LSQ7Yv5N149ZD4aWAfsyU5YCtyC0gI9aXRF5YqwWU96eym8PUVM8 amo+srsp1uK5l6XRO0cqtM9cmLedPRNAEKhah4/GgZa3S6lTH3oD7JBEPNyazTsc FpOnIzGk5JJnVpeobQv2 =HfXm -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 6/9] i2c, davinci: convert driver to new mutlibus/mutliadapter framework
>-Original Message- >From: Heiko Schocher [mailto:h...@denx.de] >Sent: Monday, March 31, 2014 1:24 AM >To: Karicheri, Muralidharan >Cc: Rini, Tom; u-boot@lists.denx.de >Subject: Re: [U-Boot] [PATCH v4 6/9] i2c, davinci: convert driver to new >mutlibus/mutliadapter framework > >Hello Mruali, > Heiko, Thanks for reviewing this. See below for my response. BTW, there is a Typo, it should have been Hello Murali, :) >Am 27.03.2014 16:59, schrieb Murali Karicheri: >> From: Vitaly Andrianov >> >> - add davinci driver to new multibus/multiadpater support >> - adapted all config files, which uses this driver >> >> Signed-off-by: Vitaly Andrianov >> Signed-off-by: Murali Karicheri >> --- >> arch/arm/cpu/arm926ejs/davinci/dm355.c |2 +- >> arch/arm/cpu/arm926ejs/davinci/dm365.c |2 +- >> arch/arm/cpu/arm926ejs/davinci/dm644x.c |2 +- >> arch/arm/cpu/arm926ejs/davinci/dm646x.c |2 +- >> drivers/i2c/Makefile|2 +- >> drivers/i2c/davinci_i2c.c | 401 >> ++- >> drivers/i2c/davinci_i2c.h | 27 ++- >> include/configs/cam_enc_4xx.h |8 +- >> include/configs/da830evm.h |8 +- >> include/configs/da850evm.h |8 +- >> include/configs/davinci_dm355evm.h |8 +- >> include/configs/davinci_dm355leopard.h |8 +- >> include/configs/davinci_dm365evm.h |8 +- >> include/configs/davinci_dm6467evm.h |8 +- >> include/configs/davinci_dvevm.h |8 +- >> include/configs/davinci_schmoogie.h |8 +- >> include/configs/davinci_sffsdr.h|8 +- >> include/configs/davinci_sonata.h|8 +- >> include/configs/ea20.h |6 +- >> include/configs/enbw_cmc.h |8 +- >> 20 files changed, 305 insertions(+), 235 deletions(-) > >This is your v4 post ... some sort of history, what has changed would be nice >... > The history is maintained for the series that is part of the cover letter. I have reproduced it below for your convenience. Change history: v4 - Added multibus support in i2c driver. Tested only on Keystone - Added comments to fdt patch v3 - Seperated network driver patches from the original series and and is now a different set as there are outstanding issues to be discussed and sorted out. Also the original series is ready for merge to upstream IMO. - Review comments incorporated. Following are the major comments addressed - Added KBUILD target for u-boot-spi.gph - Added bootup and flashing instructions in README - Cleaned up manually replacing #define with #define - Cleaned up k2hk_evm.h include file to remove unnecessary options v2 - Review comments incorporated. Following are major comments addressed - split network driver to navigator driver + ethernet driver - replaced register base + offset implemenation with struct based register access implementation - Added Readme for NAND no subpage write option - re-use code for davinci i2c driver on keystone2 with updates - clock-k2hk.c merged to clock.c - currently keeping board specific getclk() command. See the thread for the rational. - Added update to davinci spi driver to re-use on keystone v1 - added separate patch for sorting tools/Makefile entries - reworked gpimage patch to allow more re-use across omapimage/gpimage - dropped patch related to ubifs file size - added keystone SoC and K2HK EVM support v0 - preparatory patch for keystone >[...] >> diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile index >> 36d5e5f..fd1cb11 100644 >> --- a/drivers/i2c/Makefile >> +++ b/drivers/i2c/Makefile >> @@ -6,7 +6,7 @@ >> # >> >> obj-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o >> -obj-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o >> +obj-$(CONFIG_SYS_I2C_DAVINCI) += davinci_i2c.o > >please keep lists sorted. Are you asking me to sort the entire Makefile based on file name? davinci_i2c.o is at the correct alphabetical position right now. Or are you expecting this to be sorted based on CONFIG_SYS_ ? If so, I could change as obj-$(CONFIG_SYS_I2C) += i2c_core.o obj-$(CONFIG_SYS_I2C_DAVINCI) += davinci_i2c.o obj-$(CONFIG_SYS_I2C_FSL) += fsl_i2c.o obj-$(CONFIG_SYS_I2C_FTI2C010) += fti2c010.o Please confirm. If sort by file name, then I am missing something. >[...] > >Rest looks Ok for me ... if checkpatch drops no errors and warnings and MAKEALL >compiles clean ;-) > Yes. I did it and no errors/warning. ./MAKEALL ran fine too. >bye, >Heiko >-- >DENX Software Engineering GmbH, MD: W
Re: [U-Boot] [PATCH v3 8/9] spi: davinci: add support for multiple bus and chip select
>-Original Message-
>From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>Sent: Thursday, March 27, 2014 1:47 PM
>To: Karicheri, Muralidharan
>Cc: Rini, Tom; u-boot@lists.denx.de; Chang, Rex
>Subject: Re: [U-Boot] [PATCH v3 8/9] spi: davinci: add support for multiple
>bus and chip
>select
>
>On Thu, Mar 27, 2014 at 1:19 AM, Karicheri, Muralidharan
>wrote:
>>>-Original Message-
>>>From: Jagan Teki [mailto:jagannadh.t...@gmail.com]
>>>Sent: Sunday, March 23, 2014 7:07 AM
>>>To: Karicheri, Muralidharan
>>>Cc: Rini, Tom; u-boot@lists.denx.de; Chang, Rex
>>>Subject: Re: [U-Boot] [PATCH v3 8/9] spi: davinci: add support for
>>>multiple bus and chip select
>>>
>>>Hi,
>>>
>>>On Sat, Mar 22, 2014 at 2:21 AM, Murali Karicheri
>>>wrote:
Currently davinci spi driver supports only bus 0 cs 0.
This patch allows driver to support bus 1 and bus 2 with
configurable number of chip selects. Also defaults are selected in a
way to avoid regression on other platforms that uses davinci spi
driver and has only one spi bus.
Signed-off-by: Rex Chang
Signed-off-by: Murali Karicheri
Acked-by: Tom Rini
---
drivers/spi/davinci_spi.c | 60
>>>++---
drivers/spi/davinci_spi.h | 33 +
2 files changed, 90 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index e3fb321..b682bc4 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -32,7 +32,27 @@ struct spi_slave *spi_setup_slave(unsigned int
bus, unsigned int
>>>cs,
if (!ds)
return NULL;
- ds->regs = (struct davinci_spi_regs *)CONFIG_SYS_SPI_BASE;
+ ds->slave.bus = bus;
+ ds->slave.cs = cs;
+
+ switch (bus) {
+ case SPI0_BUS:
+ ds->regs = (struct davinci_spi_regs *)SPI0_BASE;
+ break;
+#ifdef CONFIG_SYS_SPI1
+ case SPI1_BUS:
+ ds->regs = (struct davinci_spi_regs *)SPI0_BASE;
+ break;
+#endif
+#ifdef CONFIG_SYS_SPI2
+ case SPI2_BUS:
+ ds->regs = (struct davinci_spi_regs *)SPI2_BASE;
+ break;
+#endif
+ default: /* Invalid bus number */
+ return NULL;
+ }
+
ds->freq = max_hz;
return &ds->slave;
@@ -59,7 +79,7 @@ int spi_claim_bus(struct spi_slave *slave)
writel(SPIGCR1_MASTER_MASK | SPIGCR1_CLKMOD_MASK,
&ds->regs->gcr1);
/* CS, CLK, SIMO and SOMI are functional pins */
- writel((SPIPC0_EN0FUN_MASK | SPIPC0_CLKFUN_MASK |
+ writel(((1 << slave->cs) | SPIPC0_CLKFUN_MASK |
SPIPC0_DOFUN_MASK | SPIPC0_DIFUN_MASK),
&ds->regs->pc0);
/* setup format */
@@ -262,9 +282,43 @@ out:
return 0;
}
+#ifdef CONFIG_SYS_SPI1
+static int bus1_cs_valid(unsigned int bus, unsigned int cs) {
+ if ((bus == SPI1_BUS) && (cs < SPI1_NUM_CS))
+ return 1;
+ return 0;
+}
+#else
+static int bus1_cs_valid(unsigned int bus, unsigned int cs) {
+ return 0;
+}
+#endif
+
+#ifdef CONFIG_SYS_SPI2
+static int bus2_cs_valid(unsigned int bus, unsigned int cs) {
+ if ((bus == SPI2_BUS) && (cs < SPI2_NUM_CS))
+ return 1;
+ return 0;
+}
+#else
+static int bus2_cs_valid(unsigned int bus, unsigned int cs) {
+ return 0;
+}
+#endif
+
int spi_cs_is_valid(unsigned int bus, unsigned int cs) {
- return bus == 0 && cs == 0;
+ if ((bus == SPI0_BUS) && (cs < SPI0_NUM_CS))
+ return 1;
+ else if (bus1_cs_valid(bus, cs))
+ return 1;
+ else if (bus2_cs_valid(bus, cs))
+ return 1;
+ return 0;
}
void spi_cs_activate(struct spi_slave *slave) diff --git
a/drivers/spi/davinci_spi.h b/drivers/spi/davinci_spi.h index
33f69b5..d4612d3 100644
--- a/drivers/spi/davinci_spi.h
+++ b/drivers/spi/davinci_spi.h
@@ -74,6 +74,39 @@ struct davinci_spi_regs {
/* SPIDEF */
#define SPIDEF_CSDEF0_MASK BIT(0)
+#define SPI0_BUS 0
+#define SPI0_BASE CONFIG_SYS_SPI_BASE
+/*
+ * Define default SPI0_NUM_CS as 1 for existing platforms that uses
+this
+ * driver. Platform can configure number of CS using
+CONFIG_SYS_SPI0_NUM_CS
+ * if more than one CS is supported and by defining CONFIG_SYS_SPI0.
+ */
+#ifndef CONFIG_SYS_SPI0
+#define SPI0_NUM_CS1
+#else
+#define SPI0_NUM_CSCONFIG_SYS_SPI0_NUM_CS
>>
Re: [U-Boot] [PATCH v4 1/2] RiOTboard: add new board
Hi Stefano, Le Sun, 30 Mar 2014 18:20:49 +0200, Stefano Babic a écrit : > A general remark. I agree by reading the whole thread about checking at > runtime which is the running board (you do it getting the cpu type). > > However, you use also a compiler switch mechanism, adding RIOTBOARD or > MARSBOARD in the boards.cfg. You have implemented two ways to for the > same thing. This makes in principle your runtime detection useless, > because you can use #if CONFIG_MARSBOARD instead of "if board_type == > BOARD_IS_MARSBOARD)". Is it possible to use only the runtime detection ? > I think the main problem is CONFIG_ENV_IS_*, that is different for the > two boards. What do you think about it ? > I've tried and I don't see how to include functions to handle both MMC and SF environment in the same binary with the current env code. A workaround would be to use MMC to store env also on the MarSBoard but as it is using the SPI flash as the boot source I would prefer to keep the env in the SPI flash. Best regards, Eric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ANN] U-Boot v2014.04-rc3 released
Hey all, I've pushed v2014.04-rc3 out to the repository and tarballs should exist soon. Looking over the changelog it's mostly bugfixes and some improvements here and there. There's a few pull requests I'm looking for but I expect to release v2014.04 on time. As always, if anything is broken please speak up. Thanks all! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] imx-common: cpu: add fdt_file environment variable
On Monday, March 31, 2014 at 09:38:02 PM, Otavio Salvador wrote:
> On Mon, Mar 31, 2014 at 4:22 PM, Marek Vasut wrote:
> > On Monday, March 31, 2014 at 08:36:55 PM, Troy Kisky wrote:
> >> On 3/29/2014 4:11 PM, Eric Nelson wrote:
> >> > Hi Troy,
> >> >
> >> > On 03/29/2014 03:34 PM, Troy Kisky wrote:
> >> >> This removes one block in the move toward 1 u-boot
> >> >> for both a mx6q (quad) and mx6dl (duallite) processor.
> >> >>
> >> >> Now fdt_file hardcoded value can be removed.
> >> >>
> >> >> Signed-off-by: Troy Kisky
> >> >> ---
> >> >>
> >> >> arch/arm/imx-common/cpu.c | 44
> >> >> arch/arm/lib/board.c
> >> >>
> >> >>| 7 +++
> >> >>
> >> >> 2 files changed, 51 insertions(+)
> >> >>
> >> >> diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
> >> >> index a77c4de..5d48011 100644
> >> >> --- a/arch/arm/imx-common/cpu.c
> >> >> +++ b/arch/arm/imx-common/cpu.c
> >> >> @@ -180,3 +180,47 @@ void arch_preboot_os(void)
> >> >>
> >> >> ipuv3_fb_shutdown();
> >> >>
> >> >> }
> >> >> #endif
> >> >>
> >> >> +
> >> >> +const char *get_dtb_prefix(u32 imxtype)
> >> >> +{
> >> >> +switch (imxtype) {
> >> >> +case MXC_CPU_MX6Q:
> >> >> +case MXC_CPU_MX6D:
> >> >> +return "imx6q";/* Quad/Dual-core version of the mx6
> >> >> */ +case MXC_CPU_MX6DL:
> >> >> +case MXC_CPU_MX6SOLO:
> >> >> +return "imx6dl";/* Dual Lite/Solo version of the mx6 */
> >> >> +case MXC_CPU_MX6SL:
> >> >> +return "imx6sl";/* Solo-Lite version of the mx6 */
> >> >> +case MXC_CPU_MX51:
> >> >> +return "imx51";
> >> >> +case MXC_CPU_MX53:
> >> >> +return "imx53";
> >> >> +}
> >> >> +return "??";
> >> >> +}
> >> >> +
> >> >
> >> > I really dislike this implementation of naming policy in code.
> >>
> >> It is not truly a policy. It is a convenience which can be ignored
> >> if so desired. Though I do agree that cpu and board environment
> >> variables would also be useful. Still, a cpu variable would still
> >> require some scripting to combine the quad/dual, duallite/solo. So,
> >> your way is not as convenient for dtb file names.
> >
> > You can make the CPU code set the CPU type into some variable.
> > Afterwards, some scripts in the HUSH can assemble the DTB name based on
> > those variables. This would be much more generic and re-usable than this
> > ...
>
> The problem is this script will be mostly the same for most boards.
This does by no means justify poluting code with non-reusable convoluted stuff.
A script which is part of the environment can be tweaked on a running system as
seen fit at any later date, updating bootloader on a running system is often
not
an option.
Furthermore, having partial information which can be used for decisionmaking is
much better than having a lengthy string which needs to be parsed first.
Especially with the limited parsing options we have in some configurations of U-
Boot.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] imx-common: cpu: add fdt_file environment variable
On Mon, Mar 31, 2014 at 4:22 PM, Marek Vasut wrote:
> On Monday, March 31, 2014 at 08:36:55 PM, Troy Kisky wrote:
>> On 3/29/2014 4:11 PM, Eric Nelson wrote:
>> > Hi Troy,
>> >
>> > On 03/29/2014 03:34 PM, Troy Kisky wrote:
>> >> This removes one block in the move toward 1 u-boot
>> >> for both a mx6q (quad) and mx6dl (duallite) processor.
>> >>
>> >> Now fdt_file hardcoded value can be removed.
>> >>
>> >> Signed-off-by: Troy Kisky
>> >> ---
>> >>
>> >> arch/arm/imx-common/cpu.c | 44
>> >> arch/arm/lib/board.c
>> >>| 7 +++
>> >> 2 files changed, 51 insertions(+)
>> >>
>> >> diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
>> >> index a77c4de..5d48011 100644
>> >> --- a/arch/arm/imx-common/cpu.c
>> >> +++ b/arch/arm/imx-common/cpu.c
>> >> @@ -180,3 +180,47 @@ void arch_preboot_os(void)
>> >>
>> >> ipuv3_fb_shutdown();
>> >>
>> >> }
>> >> #endif
>> >>
>> >> +
>> >> +const char *get_dtb_prefix(u32 imxtype)
>> >> +{
>> >> +switch (imxtype) {
>> >> +case MXC_CPU_MX6Q:
>> >> +case MXC_CPU_MX6D:
>> >> +return "imx6q";/* Quad/Dual-core version of the mx6 */
>> >> +case MXC_CPU_MX6DL:
>> >> +case MXC_CPU_MX6SOLO:
>> >> +return "imx6dl";/* Dual Lite/Solo version of the mx6 */
>> >> +case MXC_CPU_MX6SL:
>> >> +return "imx6sl";/* Solo-Lite version of the mx6 */
>> >> +case MXC_CPU_MX51:
>> >> +return "imx51";
>> >> +case MXC_CPU_MX53:
>> >> +return "imx53";
>> >> +}
>> >> +return "??";
>> >> +}
>> >> +
>> >
>> > I really dislike this implementation of naming policy in code.
>>
>> It is not truly a policy. It is a convenience which can be ignored
>> if so desired. Though I do agree that cpu and board environment variables
>> would also be useful. Still, a cpu variable would still require
>> some scripting to combine the quad/dual, duallite/solo. So, your
>> way is not as convenient for dtb file names.
>
> You can make the CPU code set the CPU type into some variable. Afterwards,
> some
> scripts in the HUSH can assemble the DTB name based on those variables. This
> would be much more generic and re-usable than this ...
The problem is this script will be mostly the same for most boards.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] imx-common: cpu: add fdt_file environment variable
On Monday, March 31, 2014 at 08:36:55 PM, Troy Kisky wrote:
> On 3/29/2014 4:11 PM, Eric Nelson wrote:
> > Hi Troy,
> >
> > On 03/29/2014 03:34 PM, Troy Kisky wrote:
> >> This removes one block in the move toward 1 u-boot
> >> for both a mx6q (quad) and mx6dl (duallite) processor.
> >>
> >> Now fdt_file hardcoded value can be removed.
> >>
> >> Signed-off-by: Troy Kisky
> >> ---
> >>
> >> arch/arm/imx-common/cpu.c | 44
> >> arch/arm/lib/board.c
> >>| 7 +++
> >> 2 files changed, 51 insertions(+)
> >>
> >> diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
> >> index a77c4de..5d48011 100644
> >> --- a/arch/arm/imx-common/cpu.c
> >> +++ b/arch/arm/imx-common/cpu.c
> >> @@ -180,3 +180,47 @@ void arch_preboot_os(void)
> >>
> >> ipuv3_fb_shutdown();
> >>
> >> }
> >> #endif
> >>
> >> +
> >> +const char *get_dtb_prefix(u32 imxtype)
> >> +{
> >> +switch (imxtype) {
> >> +case MXC_CPU_MX6Q:
> >> +case MXC_CPU_MX6D:
> >> +return "imx6q";/* Quad/Dual-core version of the mx6 */
> >> +case MXC_CPU_MX6DL:
> >> +case MXC_CPU_MX6SOLO:
> >> +return "imx6dl";/* Dual Lite/Solo version of the mx6 */
> >> +case MXC_CPU_MX6SL:
> >> +return "imx6sl";/* Solo-Lite version of the mx6 */
> >> +case MXC_CPU_MX51:
> >> +return "imx51";
> >> +case MXC_CPU_MX53:
> >> +return "imx53";
> >> +}
> >> +return "??";
> >> +}
> >> +
> >
> > I really dislike this implementation of naming policy in code.
>
> It is not truly a policy. It is a convenience which can be ignored
> if so desired. Though I do agree that cpu and board environment variables
> would also be useful. Still, a cpu variable would still require
> some scripting to combine the quad/dual, duallite/solo. So, your
> way is not as convenient for dtb file names.
You can make the CPU code set the CPU type into some variable. Afterwards, some
scripts in the HUSH can assemble the DTB name based on those variables. This
would be much more generic and re-usable than this ...
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Adjust command macros to allow smaller U-Boot size
Hi Tom, On 31 March 2014 12:59, Tom Rini wrote: > On Mon, Mar 31, 2014 at 12:38:20PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On 31 March 2014 12:30, Tom Rini wrote: > > > > > On Mon, Mar 24, 2014 at 09:51:05AM -0600, Simon Glass wrote: > > > > > > > A large chunk of U-Boot's executable size is the code to process and > > > > execute commands. This is reasonable, since commands and scripts are > > > > an important part of U-Boot's feature set and provide much of its > > > > flexibility. > > > > > > > > However, for some applications only a very limited set of commands is > > > > required. Where image size is important, it is desirable to be able > to > > > > easily remove unwanted code. > > > > > > > > This series introduces a new board_run_command() function which can > > > > be used to run a small subset of commands as required by the board > > > > (typically load and bootm), thus allowing the rest of the commands > > > > to be automatically and reliably dropped from the image using > toolchain > > > > dead code elimination. > > > > > > This is an interesting concept certainly. Can you also provide a > > > non-trivial example here? > > > > > > > I have a very non-trivial example which is a lot of code, and calls > things > > like the SPI layer and do_bootm(). That might be more than you want. > > > > Would it help if I wrote a simple FDT-based boot to a kernel in a > function? > > How about both? > For the first case, here is a commit that adds a function https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/b9e8864294d8f2143ce17b4e0d4ba019b6348199 For example, this code set up and boots a kernel: https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/b9e8864294d8f2143ce17b4e0d4ba019b6348199/cros/lib/readwrite.c and this code deals with checking for a second-stage read-write U-Boot to run: https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/b9e8864294d8f2143ce17b4e0d4ba019b6348199/cros/lib/readonly.c Does that help? For the second case, I can write something. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] imx-common: cpu: add fdt_file environment variable
On 3/29/2014 4:11 PM, Eric Nelson wrote:
> Hi Troy,
>
> On 03/29/2014 03:34 PM, Troy Kisky wrote:
>> This removes one block in the move toward 1 u-boot
>> for both a mx6q (quad) and mx6dl (duallite) processor.
>>
>> Now fdt_file hardcoded value can be removed.
>>
>> Signed-off-by: Troy Kisky
>> ---
>> arch/arm/imx-common/cpu.c | 44
>> arch/arm/lib/board.c | 7 +++
>> 2 files changed, 51 insertions(+)
>>
>> diff --git a/arch/arm/imx-common/cpu.c b/arch/arm/imx-common/cpu.c
>> index a77c4de..5d48011 100644
>> --- a/arch/arm/imx-common/cpu.c
>> +++ b/arch/arm/imx-common/cpu.c
>> @@ -180,3 +180,47 @@ void arch_preboot_os(void)
>> ipuv3_fb_shutdown();
>> }
>> #endif
>> +
>> +const char *get_dtb_prefix(u32 imxtype)
>> +{
>> +switch (imxtype) {
>> +case MXC_CPU_MX6Q:
>> +case MXC_CPU_MX6D:
>> +return "imx6q";/* Quad/Dual-core version of the mx6 */
>> +case MXC_CPU_MX6DL:
>> +case MXC_CPU_MX6SOLO:
>> +return "imx6dl";/* Dual Lite/Solo version of the mx6 */
>> +case MXC_CPU_MX6SL:
>> +return "imx6sl";/* Solo-Lite version of the mx6 */
>> +case MXC_CPU_MX51:
>> +return "imx51";
>> +case MXC_CPU_MX53:
>> +return "imx53";
>> +}
>> +return "??";
>> +}
>> +
>
> I really dislike this implementation of naming policy in code.
It is not truly a policy. It is a convenience which can be ignored
if so desired. Though I do agree that cpu and board environment variables
would also be useful. Still, a cpu variable would still require
some scripting to combine the quad/dual, duallite/solo. So, your
way is not as convenient for dtb file names.
Troy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Adjust command macros to allow smaller U-Boot size
On Mon, Mar 31, 2014 at 12:38:20PM -0600, Simon Glass wrote: > Hi Tom, > > On 31 March 2014 12:30, Tom Rini wrote: > > > On Mon, Mar 24, 2014 at 09:51:05AM -0600, Simon Glass wrote: > > > > > A large chunk of U-Boot's executable size is the code to process and > > > execute commands. This is reasonable, since commands and scripts are > > > an important part of U-Boot's feature set and provide much of its > > > flexibility. > > > > > > However, for some applications only a very limited set of commands is > > > required. Where image size is important, it is desirable to be able to > > > easily remove unwanted code. > > > > > > This series introduces a new board_run_command() function which can > > > be used to run a small subset of commands as required by the board > > > (typically load and bootm), thus allowing the rest of the commands > > > to be automatically and reliably dropped from the image using toolchain > > > dead code elimination. > > > > This is an interesting concept certainly. Can you also provide a > > non-trivial example here? > > > > I have a very non-trivial example which is a lot of code, and calls things > like the SPI layer and do_bootm(). That might be more than you want. > > Would it help if I wrote a simple FDT-based boot to a kernel in a function? How about both? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] imx-common: cpu: add fdt_file environment variable
On 3/30/2014 9:30 AM, Stefano Babic wrote: > Hi Troy, > > On 29/03/2014 23:34, Troy Kisky wrote: >> This removes one block in the move toward 1 u-boot >> for both a mx6q (quad) and mx6dl (duallite) processor. >> >> Now fdt_file hardcoded value can be removed. >> >> Signed-off-by: Troy Kisky >> --- > > I have a general problem with this implementation. I am ok if, as you > proposed some times ago, there is a general rule for the "default" dtb > file in the CONFIG_EXTRA_ENV. > > However, you are binding in code naming conventions. In U-boot, it must > be allowed to set the environment as the user wants, and this must be > not overwritten by such an internal code. In the patch, the code returns without any changes if fdt_file is already defined. So, I don't know what you are referring to here. > > I mean: a board user, if he wants, should be allowed to do something as > > setenv fdt_file my_preferred_dtb_name.dtb > > and this must work when the file is loaded from storage - this is not > possible if the rule chosen from user is overwritten by code. I agree, but it does work. > > This makes the environment useless and generates headaches for a lot of > users. They will ask themselves why the wrong file is taken when they > tried in any way to set it differently... Still no disagreement. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Adjust command macros to allow smaller U-Boot size
Hi Tom, On 31 March 2014 12:30, Tom Rini wrote: > On Mon, Mar 24, 2014 at 09:51:05AM -0600, Simon Glass wrote: > > > A large chunk of U-Boot's executable size is the code to process and > > execute commands. This is reasonable, since commands and scripts are > > an important part of U-Boot's feature set and provide much of its > > flexibility. > > > > However, for some applications only a very limited set of commands is > > required. Where image size is important, it is desirable to be able to > > easily remove unwanted code. > > > > This series introduces a new board_run_command() function which can > > be used to run a small subset of commands as required by the board > > (typically load and bootm), thus allowing the rest of the commands > > to be automatically and reliably dropped from the image using toolchain > > dead code elimination. > > This is an interesting concept certainly. Can you also provide a > non-trivial example here? > I have a very non-trivial example which is a lot of code, and calls things like the SPI layer and do_bootm(). That might be more than you want. Would it help if I wrote a simple FDT-based boot to a kernel in a function? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] imx-common: cpu: add fdt_file environment variable
On 3/30/2014 7:52 AM, Marek Vasut wrote: > On Sunday, March 30, 2014 at 12:04:31 AM, Otavio Salvador wrote: >> On Sat, Mar 29, 2014 at 7:34 PM, Troy Kisky >> >> wrote: >>> This removes one block in the move toward 1 u-boot >>> for both a mx6q (quad) and mx6dl (duallite) processor. >>> >>> Now fdt_file hardcoded value can be removed. >>> >>> Signed-off-by: Troy Kisky >> >> Nice! I do think it is in the right direction. I will give it a try soon... > > Full NAK on this patch, I completely agree with Eric that this approach is > totally wrong. This adds stuff which should be pulled from DT into common > code, > this is just NAK. > > Best regards, > Marek Vasut > I am not sure what you are suggesting. Don't you have an chicken and egg problem? Troy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] TPM: STMicroelectronics u-boot driver I2C
Hi Jean-Luc, On 31 March 2014 02:44, Jean-Luc BLANC wrote: > Hi Simon, > > I rewrote the patch. A complete different version will be pushed soon. > Sounds good, thanks. Please cc me when you are ready. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Adjust command macros to allow smaller U-Boot size
On Mon, Mar 24, 2014 at 09:51:05AM -0600, Simon Glass wrote: > A large chunk of U-Boot's executable size is the code to process and > execute commands. This is reasonable, since commands and scripts are > an important part of U-Boot's feature set and provide much of its > flexibility. > > However, for some applications only a very limited set of commands is > required. Where image size is important, it is desirable to be able to > easily remove unwanted code. > > This series introduces a new board_run_command() function which can > be used to run a small subset of commands as required by the board > (typically load and bootm), thus allowing the rest of the commands > to be automatically and reliably dropped from the image using toolchain > dead code elimination. This is an interesting concept certainly. Can you also provide a non-trivial example here? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting
On Mon, Mar 31, 2014 at 08:15:41PM +0200, Marek Vasut wrote: > On Monday, March 31, 2014 at 08:05:17 PM, Tom Rini wrote: > > On Mon, Mar 31, 2014 at 10:48:49AM +0200, Lukasz Majewski wrote: > > > Up till now the CRC32 of received data was calculated unconditionally. > > > The standard crc32 implementation causes long delays when large images > > > were uploaded. > > > > > > The "dfu_checksum_method" environment variable gives the opportunity to > > > enable on demand (when e.g. debugging) the crc32 calculation. > > > It can be done without need to recompile the u-boot binary. > > > > > > By default the crc32 is not calculated. > > > > > > Tests results: > > > 400 MiB ums.img file > > > With crc32 calculation: 65 sec [avg 6.29 MB/s] > > > Without crc32 calculation: 25 sec [avg 16.17 MB/s] > > > > > > Signed-off-by: Lukasz Majewski > > > > OK, so, protocol question. What's going on in the background here such > > that it's a good and safe idea to not do this checksum and we won't end > > up in the case where data was corrupted and we just bricked a board in > > update mode? > > This is just a convenience measure for people who do a lot of updates > and thus the time matters, it's not a production-feature. That's what I figured. So we've got the default backwards. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot does not build when lensfun is installed on host system
Hello,
u-boot is not compilable when lensfun is isntalled on the host system. The
package manager descrption says "lensfun: A library for rectifying and
simulating photographic lens distortions".
It seems that this caused by using -idirafter instead of -I.
Any idea how to fix that?
Best regards,
Alexander
Here are my step:
{/tmp} % git clone git://git.denx.de/u-boot.git
Cloning into 'u-boot'...
remote: Counting objects: 252184, done.
remote: Compressing objects: 100% (48664/48664), done.
remote: Total 252184 (delta 202282), reused 248994 (delta 199296)
Receiving objects: 100% (252184/252184), 60.77 MiB | 665.00 KiB/s, done.
Resolving deltas: 100% (202282/202282), done.
Checking connectivity... done
git clone git://git.denx.de/u-boot.git 10.14s user 2.07s system 10% cpu
1:53.47 total
{/tmp} % cd u-boot
{master u-boot} % git describe
v2014.04-rc2-96-gb4722fe
{master u-boot} %
CROSS_COMPILE=/opt/OSELAS.Toolchain-2013.12.1/arm-v5te-linux-gnueabi/gcc-4.8.2-glibc-2.18-binutils-2.24-kernel-3.12-sanitized/bin/arm-v5te-linux-gnueabi-
make at91sam9263ek_norflash_config
Configuring for at91sam9263ek_norflash - Board: at91sam9263ek, Options:
AT91SAM9263,SYS_USE_NORFLASH
{master u-boot} %
CROSS_COMPILE=/opt/OSELAS.Toolchain-2013.12.1/arm-v5te-linux-gnueabi/gcc-4.8.2-glibc-2.18-binutils-2.24-kernel-3.12-sanitized/bin/arm-v5te-linux-gnueabi-
make
GEN include/autoconf.mk.dep
GEN include/autoconf.mk
CHK include/config/uboot.release
UPD include/config/uboot.release
CHK include/generated/version_autogenerated.h
UPD include/generated/version_autogenerated.h
CHK include/generated/timestamp_autogenerated.h
UPD include/generated/timestamp_autogenerated.h
HOSTCC scripts/basic/fixdep
CC lib/asm-offsets.s
GEN include/generated/generic-asm-offsets.h
CC arch/arm/lib/asm-offsets.s
GEN include/generated/asm-offsets.h
HOSTCC tools/bmp_logo
HOSTCC tools/aisimage.o
In file included from /usr/include/image.h:22:0,
from tools/aisimage.c:10:
/usr/include/rgbpixel.h:61:3: error: expected specifier-qualifier-list before
'RGBpixel'
In file included from tools/aisimage.c:10:0:
/usr/include/image.h:40:1: error: unknown type name 'class'
/usr/include/image.h:41:1: error: expected '=', ',', ';', 'asm' or
'__attribute__' before '{' token
tools/aisimage.c:22:1: error: unknown type name 'table_entry_t'
tools/aisimage.c:23:2: warning: braces around scalar initializer [enabled by
default]
tools/aisimage.c:23:2: warning: (near initialization for 'aisimage_cmds[0]')
[enabled by default]
tools/aisimage.c:23:2: warning: excess elements in scalar initializer [enabled
by default]
tools/aisimage.c:23:2: warning: (near initialization for 'aisimage_cmds[0]')
[enabled by default]
tools/aisimage.c:23:2: warning: excess elements in scalar initializer [enabled
by default]
tools/aisimage.c:23:2: warning: (near initialization for 'aisimage_cmds[0]')
[enabled by default]
tools/aisimage.c:24:2: warning: braces around scalar initializer [enabled by
default]
tools/aisimage.c:24:2: warning: (near initialization for 'aisimage_cmds[1]')
[enabled by default]
tools/aisimage.c:24:2: warning: excess elements in scalar initializer [enabled
by default]
tools/aisimage.c:24:2: warning: (near initialization for 'aisimage_cmds[1]')
[enabled by default]
tools/aisimage.c:24:2: warning: excess elements in scalar initializer [enabled
by default]
tools/aisimage.c:24:2: warning: (near initialization for 'aisimage_cmds[1]')
[enabled by default]
tools/aisimage.c:25:2: warning: braces around scalar initializer [enabled by
default]
tools/aisimage.c:25:2: warning: (near initialization for 'aisimage_cmds[2]')
[enabled by default]
tools/aisimage.c:25:2: warning: excess elements in scalar initializer [enabled
by default]
tools/aisimage.c:25:2: warning: (near initialization for 'aisimage_cmds[2]')
[enabled by default]
tools/aisimage.c:25:2: warning: excess elements in scalar initializer [enabled
by default]
tools/aisimage.c:25:2: warning: (near initialization for 'aisimage_cmds[2]')
[enabled by default]
tools/aisimage.c:26:2: warning: braces around scalar initializer [enabled by
default]
tools/aisimage.c:26:2: warning: (near initialization for 'aisimage_cmds[3]')
[enabled by default]
tools/aisimage.c:26:2: warning: excess elements in scalar initializer [enabled
by default]
tools/aisimage.c:26:2: warning: (near initialization for 'aisimage_cmds[3]')
[enabled by default]
tools/aisimage.c:26:2: warning: excess elements in scalar initializer [enabled
by default]
tools/aisimage.c:26:2: warning: (near initialization for 'aisimage_cmds[3]')
[enabled by default]
tools/aisimage.c:27:2: warning: braces around scalar initializer [enabled by
default]
tools/aisimage.c:27:2: warning: (near initialization for 'aisimage_cmds[4]')
[enabled by default]
tools/aisimage.c:27:2: warning: excess elements in scalar initializer [enabled
by default]
tools/aisimage.c:27:2: warning: (near
Re: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting
On Monday, March 31, 2014 at 08:05:17 PM, Tom Rini wrote: > On Mon, Mar 31, 2014 at 10:48:49AM +0200, Lukasz Majewski wrote: > > Up till now the CRC32 of received data was calculated unconditionally. > > The standard crc32 implementation causes long delays when large images > > were uploaded. > > > > The "dfu_checksum_method" environment variable gives the opportunity to > > enable on demand (when e.g. debugging) the crc32 calculation. > > It can be done without need to recompile the u-boot binary. > > > > By default the crc32 is not calculated. > > > > Tests results: > > 400 MiB ums.img file > > Withcrc32 calculation: 65 sec [avg 6.29 MB/s] > > Without crc32 calculation: 25 sec [avg 16.17 MB/s] > > > > Signed-off-by: Lukasz Majewski > > OK, so, protocol question. What's going on in the background here such > that it's a good and safe idea to not do this checksum and we won't end > up in the case where data was corrupted and we just bricked a board in > update mode? This is just a convenience measure for people who do a lot of updates and thus the time matters, it's not a production-feature. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting
On Mon, Mar 31, 2014 at 10:48:49AM +0200, Lukasz Majewski wrote: > Up till now the CRC32 of received data was calculated unconditionally. > The standard crc32 implementation causes long delays when large images > were uploaded. > > The "dfu_checksum_method" environment variable gives the opportunity to > enable on demand (when e.g. debugging) the crc32 calculation. > It can be done without need to recompile the u-boot binary. > > By default the crc32 is not calculated. > > Tests results: > 400 MiB ums.img file > With crc32 calculation: 65 sec [avg 6.29 MB/s] > Without crc32 calculation: 25 sec [avg 16.17 MB/s] > > Signed-off-by: Lukasz Majewski OK, so, protocol question. What's going on in the background here such that it's a good and safe idea to not do this checksum and we won't end up in the case where data was corrupted and we just bricked a board in update mode? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.
Hi Lukasz, On 31 March 2014 08:33, Lukasz Majewski wrote: [snip] > > > > This can be easily added to be used at "pmic bat charge" command. > > > > Please look into the ./drivers/power/mfd/pmic_max77693.c > > > > Not easily. As mentioned above this is quite a bit of work. For a > > later series I think. > > I'm looking forward for questions :-). > Do you think you might submit a patch that adds comments to the header files? That would help a lot. Also now that driver model is merged, do you think we should try to move PMICs to that, or would it be a later step? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pull request for u-boot-tegra/master info ARM/master
OK, will do. Albert - have you pull my latest PR into ARM master yet? Stephen was hoping to get it in before the next release. I'll send a new PR with the latest patches, but the first PR still needs to go in ASAP. Tom On Mon, Mar 31, 2014 at 9:25 AM, Stefan Agner wrote: > Am 2014-03-28 16:54, schrieb Tom Warren: > > > Have they all been ACKed? Sorry, been really busy with normal NVIDIA > stuff. > They have been ACKed, see > http://lists.denx.de/pipermail/u-boot/2014-March/175302.html > > and tested by Stephen, > http://lists.denx.de/pipermail/u-boot/2014-March/174662.html > > > > If they're ready, I can apply them with Stephen's pinmux changes and > send another PR to Albert. > That would be great yes. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pull request for u-boot-tegra/master info ARM/master
Am 2014-03-28 16:54, schrieb Tom Warren: > Have they all been ACKed? Sorry, been really busy with normal NVIDIA stuff. They have been ACKed, see http://lists.denx.de/pipermail/u-boot/2014-March/175302.html and tested by Stephen, http://lists.denx.de/pipermail/u-boot/2014-March/174662.html > If they're ready, I can apply them with Stephen's pinmux changes and send > another PR to Albert. That would be great yes. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 13/13] common: fixed linker-list example
On Monday, March 31, 2014 at 05:49:12 PM, Mateusz Zalega wrote:
> Change-Id: Id1bab29ec026d83f7e811ba82802aad33f77bea0
You samsung guys need to fix your mailers ... and you need to learn to write
commit messages.
> Signed-off-by: Mateusz Zalega
> Cc: Marek Vasut
> Cc: Tom Rini
Other than that, please add this for V2:
Acked-by: Marek Vasut
> ---
> include/linker_lists.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linker_lists.h b/include/linker_lists.h
> index 997d149..557e627 100644
> --- a/include/linker_lists.h
> +++ b/include/linker_lists.h
> @@ -228,7 +228,7 @@
> * and it's name.
> *
> * Example:
> - * ll_entry_declare(struct my_sub_cmd, my_sub_cmd, cmd_sub, cmd.sub) = {
> + * ll_entry_declare(struct my_sub_cmd, my_sub_cmd, cmd_sub) = {
> * .x = 3,
> * .y = 4,
> * };
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/13] USB: gadget: added a saner gadget downloader registration API
On Monday, March 31, 2014 at 05:49:05 PM, Mateusz Zalega wrote: > Preprocessor definitions and hardcoded implementation selection in > g_dnl core were replaced by a linker list made of (usb_function_name, > bind_callback) pairs. > > Signed-off-by: Mateusz Zalega > Cc: Lukasz Majewski > Cc: Marek Vasut Reviewed-by: Marek Vasut Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: mpc8xx: delete an unused source file
Dear Masahiro Yamada, In message <1396238924-12140-1-git-send-email-yamad...@jp.panasonic.com> you wrote: > Signed-off-by: Masahiro Yamada > Cc: Wolfgang Denk > --- > arch/powerpc/cpu/mpc8xx/wlkbd.c | 20 > 1 file changed, 20 deletions(-) > delete mode 100644 arch/powerpc/cpu/mpc8xx/wlkbd.c Acked-by: Wolfgang Denk Please apply as part of the patch series. I see no use in routing this through the 8xx repository. 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 Memories of you remind me of you. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 11/13] mmc: postponed needless timer initialization
mmc_init() doesn't call get_timer() anymore if MMC is already
initialized.
Change-Id: Ib4e0f5a04316c604e6a77a0679d42ff61d5641d2
Signed-off-by: Mateusz Zalega
---
drivers/mmc/mmc.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 8ab0bc9..9da31f5 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -1279,15 +1279,18 @@ static int mmc_complete_init(struct mmc *mmc)
int mmc_init(struct mmc *mmc)
{
int err = IN_PROGRESS;
- unsigned start = get_timer(0);
+ unsigned start;
if (mmc->has_init)
return 0;
+
+ start = get_timer(0);
+
if (!mmc->init_in_progress)
err = mmc_start_init(mmc);
-
if (!err || err == IN_PROGRESS)
err = mmc_complete_init(mmc);
+
debug("%s: %d, time %lu\n", __func__, err, get_timer(start));
return err;
}
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 04/13] dfu: fix boards wo USB cable detection
Former usb_cable_connected() patch broke compilation of boards which do
not support this feature.
Signed-off-by: Mateusz Zalega
Cc: Lukasz Majewski
---
common/cmd_usb_mass_storage.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c
index 5f557d5..5175bd5 100644
--- a/common/cmd_usb_mass_storage.c
+++ b/common/cmd_usb_mass_storage.c
@@ -45,6 +45,7 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
/* Timeout unit: seconds */
int cable_ready_timeout = UMS_CABLE_READY_TIMEOUT;
+#ifdef CONFIG_USB_CABLE_CHECK
if (!usb_cable_connected()) {
puts("Please connect USB cable.\n");
@@ -65,6 +66,7 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
}
puts("\r\n");
}
+#endif
while (1) {
usb_gadget_handle_interrupts();
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 08/13] arm:goni: enable GPT command
Signed-off-by: Mateusz Zalega Cc: Minkyu Kang --- include/configs/s5p_goni.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h index f97b52d..c52a00a 100644 --- a/include/configs/s5p_goni.h +++ b/include/configs/s5p_goni.h @@ -73,6 +73,7 @@ #define CONFIG_CMD_ONENAND #define CONFIG_CMD_MMC #define CONFIG_CMD_DFU +#define CONFIG_CMD_GPT /* USB Composite download gadget - g_dnl */ #define CONFIG_USBDOWNLOAD_GADGET @@ -237,6 +238,10 @@ #define CONFIG_FAT_WRITE #define CONFIG_EXT4_WRITE +/* GPT */ +#define CONFIG_EFI_PARTITION +#define CONFIG_PARTITION_UUIDS + #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_LOAD_ADDR - 0x100) #define CONFIG_SYS_CACHELINE_SIZE 64 -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 01/13] mmc: mmc header fix
Structure definition used type block_dev_desc_t, defined in part.h, which wasn't included in mmc.h. It worked only in circumstances when common.h, or another header using part.h was incuded in implementation files. Signed-off-by: Mateusz Zalega Cc: Minkyu Kang --- include/mmc.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/mmc.h b/include/mmc.h index b65ad9e..afc226a 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -12,6 +12,7 @@ #include #include +#include #define SD_VERSION_SD 0x2 #define SD_VERSION_3 (SD_VERSION_SD | 0x300) -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 07/13] arm:goni:dfu Add support for DFU to Goni target
Proper adjustment for supporting DFU at GONI target has been made.
The s5p_goni.h file has been updated. Moreover the code for low level
USB initialization has been added to GONI board code.
The malloc pool has been enlarged in order to support larger buffer
sizes needed by DFU implementation.
Signed-off-by: Arkadiusz Wlodarczyk
Signed-off-by: Kyungmin Park
Signed-off-by: Mateusz Zalega
Tested-by: Arkadiusz Wlodarczyk
Tested-by: Mateusz Zalega
Cc: Minkyu Kang
---
board/samsung/goni/goni.c | 8 +++
include/configs/s5p_goni.h | 54 --
2 files changed, 51 insertions(+), 11 deletions(-)
diff --git a/board/samsung/goni/goni.c b/board/samsung/goni/goni.c
index 61b9ece..273fa42 100644
--- a/board/samsung/goni/goni.c
+++ b/board/samsung/goni/goni.c
@@ -14,6 +14,8 @@
#include
#include
#include
+#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -179,6 +181,12 @@ struct s3c_plat_otg_data s5pc110_otg_data = {
.regs_otg = S5PC110_OTG_BASE,
.usb_phy_ctrl = S5PC110_USB_PHY_CONTROL,
};
+
+int board_usb_init(int index, enum usb_init_type init)
+{
+ debug("USB_udc_probe\n");
+ return s3c_udc_probe(&s5pc110_otg_data);
+}
#endif
#ifdef CONFIG_MISC_INIT_R
diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index b9b66c7..f97b52d 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -40,7 +40,7 @@
#define CONFIG_CMDLINE_EDITING
/* Size of malloc() pool.*/
-#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + SZ_1M)
+#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 80 * SZ_1M)
/*
* select serial console configuration
@@ -71,14 +71,18 @@
#define CONFIG_CMD_CACHE
#define CONFIG_CMD_REGINFO
#define CONFIG_CMD_ONENAND
-#define CONFIG_CMD_MTDPARTS
#define CONFIG_CMD_MMC
+#define CONFIG_CMD_DFU
-#define CONFIG_BOOTDELAY 1
-#define CONFIG_ZERO_BOOTDELAY_CHECK
+/* USB Composite download gadget - g_dnl */
+#define CONFIG_USBDOWNLOAD_GADGET
+#define CONFIG_DFU_FUNCTION
+#define CONFIG_DFU_MMC
-#define CONFIG_MTD_DEVICE
-#define CONFIG_MTD_PARTITIONS
+/* USB Samsung's IDs */
+#define CONFIG_G_DNL_VENDOR_NUM 0x04E8
+#define CONFIG_G_DNL_PRODUCT_NUM 0x6601
+#define CONFIG_G_DNL_MANUFACTURER "Samsung"
/* Actual modem binary size is 16MiB. Add 2MiB for bad block handling */
#define MTDIDS_DEFAULT "onenand0=samsung-onenand"
@@ -91,7 +95,34 @@
",12m(modem)"\
",60m(qboot)\0"
-#define NORMAL_MTDPARTS_DEFAULT MTDPARTS_DEFAULT
+#define CONFIG_BOOTDELAY 1
+#define CONFIG_ZERO_BOOTDELAY_CHECK
+
+/* partitions definitions */
+#define PARTS_CSA "csa-mmc"
+#define PARTS_BOOTLOADER "u-boot"
+#define PARTS_BOOT "boot"
+#define PARTS_ROOT "platform"
+#define PARTS_DATA "data"
+#define PARTS_CSC "csc"
+#define PARTS_UMS "ums"
+
+#define CONFIG_DFU_ALT \
+ "u-boot raw 0x80 0x400;" \
+ "uImage ext4 0 2;" \
+ "exynos3-goni.dtb ext4 0 2;" \
+ ""PARTS_ROOT" part 0 5\0"
+
+#define PARTS_DEFAULT \
+ "uuid_disk=${uuid_gpt_disk};" \
+ "name="PARTS_CSA",size=8MiB,uuid=${uuid_gpt_"PARTS_CSA"};" \
+ "name="PARTS_BOOTLOADER",size=60MiB," \
+ "uuid=${uuid_gpt_"PARTS_BOOTLOADER"};" \
+ "name="PARTS_BOOT",size=100MiB,uuid=${uuid_gpt_"PARTS_BOOT"};" \
+ "name="PARTS_ROOT",size=1GiB,uuid=${uuid_gpt_"PARTS_ROOT"};" \
+ "name="PARTS_DATA",size=3GiB,uuid=${uuid_gpt_"PARTS_DATA"};" \
+ "name="PARTS_CSC",size=150MiB,uuid=${uuid_gpt_"PARTS_CSC"};" \
+ "name="PARTS_UMS",size=-,uuid=${uuid_gpt_"PARTS_UMS"}\0" \
#define CONFIG_BOOTCOMMAND "run mmcboot"
@@ -150,18 +181,18 @@
"verify=n\0" \
"rootfstype=ext4\0" \
"console=" CONFIG_DEFAULT_CONSOLE \
- "mtdparts=" MTDPARTS_DEFAULT \
"meminfo=mem=80M mem=256M@0x4000 mem=128M@0x5000\0" \
- "loaduimage=fatload mmc ${mmcdev}:${mmcbootpart} 0x30007FC0 uImage\0" \
+ "loaduimage=ext4load mmc ${mmcdev}:${mmcbootpart} 0x30007FC0 uImage\0" \
"mmcdev=0\0" \
"mmcbootpart=2\0" \
"mmcrootpart=5\0" \
+ "partitions=" PARTS_DEFAULT \
"bootblock=9\0" \
"ubiblock=8\0" \
"ubi=enabled\0" \
- "opts=always_resume=1"
+ "opts=always_resume=1\0" \
+ "dfu_alt_info=" CONFIG_DFU_ALT "\0"
-/* Miscellaneous configurable options */
#define CONFIG_SYS_LONGHELP/* undef to save memory */
#define CONFIG_SYS_HUSH_PARSER /* use "hush" command parser*/
#define CONFIG_SYS_PROMPT "Goni # "
@@ -200,6 +231,7 @@
#define CONFIG_CMD_FAT
#define CONFIG_CMD_EXT4
+#define CONFIG_CMD_EXT4_WRITE
/* write support for filesystems */
#define CONFIG_FAT_WRITE
--
1.9.0
___
U-Boot mailing list
U-
[U-Boot] [PATCH v3 10/13] dfu:mmc: raw data write fix
When user attempted to perform a raw write using DFU (vide
dfu_fill_entity_mmc) with MMC interface not initialized before,
get_mmc_blk_size() reported invalid (zero) block size - it wasn't
possible to write ie. a new u-boot image.
This commit fixes that by initializing device in get_mmc_blk_size() when
needed.
Tested on Samsung Goni.
Signed-off-by: Mateusz Zalega
Signed-off-by: Kyungmin Park
Acked-by: Lukasz Majewski
Cc: Minkyu Kang
---
drivers/dfu/dfu_mmc.c| 106 ++-
include/configs/am335x_evm.h | 8 ++--
include/configs/trats.h | 2 +-
include/configs/trats2.h | 2 +-
include/dfu.h| 5 --
5 files changed, 70 insertions(+), 53 deletions(-)
diff --git a/drivers/dfu/dfu_mmc.c b/drivers/dfu/dfu_mmc.c
index 0816f46..75ff373 100644
--- a/drivers/dfu/dfu_mmc.c
+++ b/drivers/dfu/dfu_mmc.c
@@ -167,66 +167,88 @@ int dfu_read_medium_mmc(struct dfu_entity *dfu, u64
offset, void *buf,
return ret;
}
+/*
+ * @param s Parameter string containing space-separated arguments:
+ * 1st:
+ * raw (raw read/write)
+ * fat (files)
+ * ext4(^)
+ * part(partition image)
+ * 2nd and 3rd:
+ * lba_start and lba_size, for raw write
+ * mmc_dev and mmc_part, for filesystems and part
+ */
int dfu_fill_entity_mmc(struct dfu_entity *dfu, char *s)
{
- int dev, part;
- struct mmc *mmc;
- block_dev_desc_t *blk_dev;
- disk_partition_t partinfo;
- char *st;
-
- dfu->dev_type = DFU_DEV_MMC;
- st = strsep(&s, " ");
- if (!strcmp(st, "mmc")) {
- dfu->layout = DFU_RAW_ADDR;
- dfu->data.mmc.lba_start = simple_strtoul(s, &s, 16);
- dfu->data.mmc.lba_size = simple_strtoul(++s, &s, 16);
- dfu->data.mmc.lba_blk_size = get_mmc_blk_size(dfu->dev_num);
- } else if (!strcmp(st, "fat")) {
- dfu->layout = DFU_FS_FAT;
- } else if (!strcmp(st, "ext4")) {
- dfu->layout = DFU_FS_EXT4;
- } else if (!strcmp(st, "part")) {
+ const char *argv[3];
+ const char **parg = argv;
+ for (; parg < argv + sizeof(argv) / sizeof(*argv); ++parg) {
+ *parg = strsep(&s, " ");
+ if (*parg == NULL) {
+ error("Invalid number of arguments.\n");
+ return -ENODEV;
+ }
+ }
- dfu->layout = DFU_RAW_ADDR;
+ const char *entity_type = argv[0];
+ /*
+* Base 0 means we'll accept (prefixed with 0x or 0) base 16, 8,
+* with default 10.
+*/
+ size_t second_arg = simple_strtoul(argv[1], NULL, 0);
+ size_t third_arg = simple_strtoul(argv[2], NULL, 0);
- dev = simple_strtoul(s, &s, 10);
- s++;
- part = simple_strtoul(s, &s, 10);
+ struct mmc *mmc = find_mmc_device(dfu->dev_num);
+ if (mmc == NULL) {
+ error("Couldn't find MMC device no. %d.\n", dfu->dev_num);
+ return -ENODEV;
+ }
- mmc = find_mmc_device(dev);
- if (mmc == NULL || mmc_init(mmc)) {
- printf("%s: could not find mmc device #%d!\n",
- __func__, dev);
- return -ENODEV;
- }
+ if (mmc_init(mmc)) {
+ error("Couldn't init MMC device.\n");
+ return -ENODEV;
+ }
- blk_dev = &mmc->block_dev;
- if (get_partition_info(blk_dev, part, &partinfo) != 0) {
- printf("%s: could not find partition #%d on mmc device
#%d!\n",
- __func__, part, dev);
+ if (!strcmp(entity_type, "raw")) {
+ dfu->layout = DFU_RAW_ADDR;
+ dfu->data.mmc.lba_start = second_arg;
+ dfu->data.mmc.lba_size = third_arg;
+ dfu->data.mmc.lba_blk_size = mmc->read_bl_len;
+ } else if (!strcmp(entity_type, "part")) {
+ disk_partition_t partinfo;
+ block_dev_desc_t *blk_dev = &mmc->block_dev;
+ int mmcdev = second_arg;
+ int mmcpart = third_arg;
+
+ if (get_partition_info(blk_dev, mmcpart, &partinfo) != 0) {
+ error("Couldn't find part #%d on mmc device #%d\n",
+ mmcpart, mmcdev);
return -ENODEV;
}
- dfu->data.mmc.lba_start = partinfo.start;
- dfu->data.mmc.lba_size = partinfo.size;
- dfu->data.mmc.lba_blk_size = partinfo.blksz;
-
+ dfu->layout = DFU_RAW_ADDR;
+ dfu->data.mmc.lba_start = partinfo.start;
+ dfu->data.mmc.lba_size = partinfo.size;
+ dfu->data
[U-Boot] [PATCH v3 13/13] common: fixed linker-list example
Change-Id: Id1bab29ec026d83f7e811ba82802aad33f77bea0
Signed-off-by: Mateusz Zalega
Cc: Marek Vasut
Cc: Tom Rini
---
include/linker_lists.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linker_lists.h b/include/linker_lists.h
index 997d149..557e627 100644
--- a/include/linker_lists.h
+++ b/include/linker_lists.h
@@ -228,7 +228,7 @@
* and it's name.
*
* Example:
- * ll_entry_declare(struct my_sub_cmd, my_sub_cmd, cmd_sub, cmd.sub) = {
+ * ll_entry_declare(struct my_sub_cmd, my_sub_cmd, cmd_sub) = {
* .x = 3,
* .y = 4,
* };
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 06/13] USB: gadget: added a saner gadget downloader registration API
Preprocessor definitions and hardcoded implementation selection in
g_dnl core were replaced by a linker list made of (usb_function_name,
bind_callback) pairs.
Signed-off-by: Mateusz Zalega
Cc: Lukasz Majewski
Cc: Marek Vasut
---
common/cmd_dfu.c| 3 +-
common/cmd_thordown.c | 3 +-
common/cmd_usb_mass_storage.c | 2 +-
drivers/usb/gadget/f_dfu.c | 3 ++
drivers/usb/gadget/f_mass_storage.c | 3 ++
drivers/usb/gadget/f_thor.c | 2 ++
drivers/usb/gadget/g_dnl.c | 64 -
include/dfu.h | 7
include/g_dnl.h | 24 ++
include/thor.h | 8 -
include/usb_mass_storage.h | 8 -
11 files changed, 63 insertions(+), 64 deletions(-)
diff --git a/common/cmd_dfu.c b/common/cmd_dfu.c
index 5547678..a03538d 100644
--- a/common/cmd_dfu.c
+++ b/common/cmd_dfu.c
@@ -22,7 +22,6 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
char *interface = argv[2];
char *devstring = argv[3];
- char *s = "dfu";
int ret, i = 0;
ret = dfu_init_env_entities(interface, simple_strtoul(devstring,
@@ -38,7 +37,7 @@ static int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
int controller_index = simple_strtoul(usb_controller, NULL, 0);
board_usb_init(controller_index, USB_INIT_DEVICE);
- g_dnl_register(s);
+ g_dnl_register("usb_dnl_dfu");
while (1) {
if (dfu_reset())
/*
diff --git a/common/cmd_thordown.c b/common/cmd_thordown.c
index c4b3511..2dd7509 100644
--- a/common/cmd_thordown.c
+++ b/common/cmd_thordown.c
@@ -22,7 +22,6 @@ int do_thor_down(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
char *interface = argv[2];
char *devstring = argv[3];
- const char *s = "thor";
int ret;
puts("TIZEN \"THOR\" Downloader\n");
@@ -40,7 +39,7 @@ int do_thor_down(cmd_tbl_t *cmdtp, int flag, int argc, char *
const argv[])
goto exit;
}
- g_dnl_register(s);
+ g_dnl_register("usb_dnl_thor");
ret = thor_init();
if (ret) {
diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c
index 5175bd5..4c2de48 100644
--- a/common/cmd_usb_mass_storage.c
+++ b/common/cmd_usb_mass_storage.c
@@ -40,7 +40,7 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
return CMD_RET_FAILURE;
}
- g_dnl_register("ums");
+ g_dnl_register("usb_dnl_ums");
/* Timeout unit: seconds */
int cable_ready_timeout = UMS_CABLE_READY_TIMEOUT;
diff --git a/drivers/usb/gadget/f_dfu.c b/drivers/usb/gadget/f_dfu.c
index a045864..2f822c4 100644
--- a/drivers/usb/gadget/f_dfu.c
+++ b/drivers/usb/gadget/f_dfu.c
@@ -24,6 +24,7 @@
#include
#include
+#include
#include "f_dfu.h"
struct f_dfu {
@@ -781,3 +782,5 @@ int dfu_add(struct usb_configuration *c)
return dfu_bind_config(c);
}
+
+DECLARE_GADGET_BIND_CALLBACK(usb_dnl_dfu, dfu_add);
diff --git a/drivers/usb/gadget/f_mass_storage.c
b/drivers/usb/gadget/f_mass_storage.c
index f896169..f88bb12 100644
--- a/drivers/usb/gadget/f_mass_storage.c
+++ b/drivers/usb/gadget/f_mass_storage.c
@@ -255,6 +255,7 @@
#include
#include
#include
+#include
/**/
@@ -2778,3 +2779,5 @@ int fsg_init(struct ums *ums_dev)
return 0;
}
+
+DECLARE_GADGET_BIND_CALLBACK(usb_dnl_ums, fsg_add);
diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c
index f5c0224..59d246d 100644
--- a/drivers/usb/gadget/f_thor.c
+++ b/drivers/usb/gadget/f_thor.c
@@ -999,3 +999,5 @@ int thor_add(struct usb_configuration *c)
debug("%s:\n", __func__);
return thor_func_init(c);
}
+
+DECLARE_GADGET_BIND_CALLBACK(usb_dnl_thor, thor_add);
diff --git a/drivers/usb/gadget/g_dnl.c b/drivers/usb/gadget/g_dnl.c
index dd95afe..3575aca 100644
--- a/drivers/usb/gadget/g_dnl.c
+++ b/drivers/usb/gadget/g_dnl.c
@@ -41,7 +41,6 @@
#define DRIVER_VERSION "usb_dnl 2.0"
-static const char shortname[] = "usb_dnl_";
static const char product[] = "USB download gadget";
static char g_dnl_serial[MAX_STRING_SERIAL];
static const char manufacturer[] = CONFIG_G_DNL_MANUFACTURER;
@@ -96,29 +95,36 @@ static int g_dnl_unbind(struct usb_composite_dev *cdev)
free(cdev->config);
cdev->config = NULL;
debug("%s: calling usb_gadget_disconnect for "
- "controller '%s'\n", shortname, gadget->name);
+ "controller '%s'\n", __func__, gadget->name);
usb_gadget_disconnect(gadget);
return 0;
}
+static inline struct g_dnl_bind_callback * g_dnl_bind_callback_first(void)
+{
+ return ll_entry_start(struct g_dnl_bind_callback,
+
[U-Boot] [PATCH v3 12/13] ums: always initialize mmc before ums_disk_init()
In some cases MMC was still uninitialized while media capacity check,
leading to broken ums command.
Tested on Samsung Goni.
Change-Id: I4b86c2c59e430fb8b55272ea14f00316d8cb3dca
Signed-off-by: Mateusz Zalega
Tested-by: Mateusz Zalega
Cc: Lukasz Majewski
Cc: Minkyu Kang
---
board/samsung/common/ums.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/board/samsung/common/ums.c b/board/samsung/common/ums.c
index dc155ad..1375138 100644
--- a/board/samsung/common/ums.c
+++ b/board/samsung/common/ums.c
@@ -35,10 +35,10 @@ static struct ums ums_dev = {
.name = "UMS disk",
};
-static struct ums *ums_disk_init(struct mmc *mmc)
+static struct ums *ums_disk_init(const struct mmc *mmc)
{
- uint64_t mmc_end_sector = mmc->capacity / SECTOR_SIZE;
- uint64_t ums_end_sector = UMS_NUM_SECTORS + UMS_START_SECTOR;
+ const uint64_t mmc_end_sector = mmc->capacity / SECTOR_SIZE;
+ const uint64_t ums_end_sector = UMS_NUM_SECTORS + UMS_START_SECTOR;
if (!mmc_end_sector) {
error("MMC capacity is not valid");
@@ -66,11 +66,9 @@ static struct ums *ums_disk_init(struct mmc *mmc)
struct ums *ums_init(unsigned int dev_num)
{
- struct mmc *mmc = NULL;
+ struct mmc *mmc = find_mmc_device(dev_num);
- mmc = find_mmc_device(dev_num);
- if (!mmc)
+ if (!mmc || mmc_init(mmc))
return NULL;
-
return ums_disk_init(mmc);
}
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 03/13] arm:goni: Update configuration for goni target
Configuration file for GONI has been updated to support FAT file system,
new mmc partitioning scheme and read linux kernel from eMMC instead of
OneNAND.
Signed-off-by: Arkadiusz Wlodarczyk
Signed-off-by: Kyungmin Park
Signed-off-by: Mateusz Zalega
Tested-by: Arkadiusz Wlodarczyk
Tested-by: Mateusz Zalega
Cc: Minkyu Kang
---
include/configs/s5p_goni.h | 56 +-
1 file changed, 30 insertions(+), 26 deletions(-)
diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h
index 991c43e..b9b66c7 100644
--- a/include/configs/s5p_goni.h
+++ b/include/configs/s5p_goni.h
@@ -17,6 +17,7 @@
#define CONFIG_S5PC110 1 /* which is in a S5PC110 */
#define CONFIG_MACH_GONI 1 /* working with Goni */
+#include
#include /* get chip and board defs */
#define CONFIG_ARCH_CPU_INIT
@@ -38,11 +39,9 @@
#define CONFIG_INITRD_TAG
#define CONFIG_CMDLINE_EDITING
-/*
- * Size of malloc() pool
- * 1MB = 0x10, 0x10 = 1024 * 1024
- */
-#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + (1 << 20))
+/* Size of malloc() pool.*/
+#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + SZ_1M)
+
/*
* select serial console configuration
*/
@@ -90,30 +89,25 @@
",7m(kernel)"\
",1m(log)"\
",12m(modem)"\
- ",60m(qboot)"\
- ",-(UBI)\0"
+ ",60m(qboot)\0"
#define NORMAL_MTDPARTS_DEFAULT MTDPARTS_DEFAULT
-#define CONFIG_BOOTCOMMAND "run ubifsboot"
+#define CONFIG_BOOTCOMMAND "run mmcboot"
#define CONFIG_DEFAULT_CONSOLE "console=ttySAC2,115200n8\0"
-#define CONFIG_RAMDISK_BOOT"root=/dev/ram0 rw rootfstype=ext2" \
+#define CONFIG_RAMDISK_BOOT"root=/dev/ram0 rw rootfstype=ext4" \
" ${console} ${meminfo}"
#define CONFIG_COMMON_BOOT "${console} ${meminfo} ${mtdparts}"
-#define CONFIG_BOOTARGS"root=/dev/mtdblock8 ubi.mtd=8 ubi.mtd=3
ubi.mtd=6" \
- " rootfstype=cramfs " CONFIG_COMMON_BOOT
+#define CONFIG_BOOTARGS"root=/dev/mtdblock8 rootfstype=ext4 " \
+ CONFIG_COMMON_BOOT
#define CONFIG_UPDATEB "updateb=onenand erase 0x0 0x10;" \
" onenand write 0x32008000 0x0 0x10\0"
-#define CONFIG_UBI_MTD " ubi.mtd=${ubiblock} ubi.mtd=3 ubi.mtd=6"
-
-#define CONFIG_UBIFS_OPTION"rootflags=bulk_read,no_chk_data_crc"
-
#define CONFIG_MISC_COMMON
#define CONFIG_MISC_INIT_R
@@ -130,36 +124,38 @@
"onenand erase 0x0156 0x1eaa;" \
"onenand write 0x3200 0x126 0x8C\0" \
"bootk=" \
- "onenand read 0x30007FC0 0xc0 0x60;" \
+ "run loaduimage;" \
"bootm 0x30007FC0\0" \
"flashboot=" \
"set bootargs root=/dev/mtdblock${bootblock} " \
- "rootfstype=${rootfstype}" CONFIG_UBI_MTD " ${opts} " \
+ "rootfstype=${rootfstype} ${opts} " \
"${lcdinfo} " CONFIG_COMMON_BOOT "; run bootk\0" \
"ubifsboot=" \
"set bootargs root=ubi0!rootfs rootfstype=ubifs " \
- CONFIG_UBIFS_OPTION CONFIG_UBI_MTD " ${opts} ${lcdinfo} " \
+ "${opts} ${lcdinfo} " \
CONFIG_COMMON_BOOT "; run bootk\0" \
"tftpboot=" \
"set bootargs root=ubi0!rootfs rootfstype=ubifs " \
- CONFIG_UBIFS_OPTION CONFIG_UBI_MTD " ${opts} ${lcdinfo} " \
- CONFIG_COMMON_BOOT "; tftp 0x30007FC0 uImage; " \
- "bootm 0x30007FC0\0" \
+ "${opts} ${lcdinfo} " CONFIG_COMMON_BOOT \
+ "; tftp 0x30007FC0 uImage; bootm 0x30007FC0\0" \
"ramboot=" \
"set bootargs " CONFIG_RAMDISK_BOOT \
- " initrd=0x3300,8M ramdisk=8192\0" \
+ "initrd=0x3300,8M ramdisk=8192\0" \
"mmcboot=" \
- "set bootargs root=${mmcblk} rootfstype=${rootfstype}" \
- CONFIG_UBI_MTD " ${opts} ${lcdinfo} " \
+ "set bootargs root=/dev/mmcblk${mmcdev}p${mmcrootpart} " \
+ "rootfstype=${rootfstype} ${opts} ${lcdinfo} " \
CONFIG_COMMON_BOOT "; run bootk\0" \
"boottrace=setenv opts initcall_debug; run bootcmd\0" \
"bootchart=set opts init=/sbin/bootchartd; run bootcmd\0" \
"verify=n\0" \
- "rootfstype=cramfs\0" \
+ "rootfstype=ext4\0" \
"console=" CONFIG_DEFAULT_CONSOLE \
"mtdparts=" MTDPARTS_DEFAULT \
"meminfo=mem=80M mem=256M@0x4000 mem=128M@0x5000\0" \
- "mmcblk=/dev/mmcblk1p1\0" \
+ "loaduimage=fatload mmc ${mmcdev}:${mmcbootpart} 0x30007FC0 uImage\0" \
+ "mmcdev=0\0" \
+ "mmcbootpart=2\0" \
+ "mmcrootpart=5\0" \
"bootblock=9\0" \
"ubiblock=8\0" \
[U-Boot] [PATCH v3 09/13] arm:goni: enable USB Mass Storage
UMS-related defines were added to Samsung Goni config header. Signed-off-by: Mateusz Zalega Cc: Minkyu Kang --- include/configs/s5p_goni.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/s5p_goni.h b/include/configs/s5p_goni.h index c52a00a..f551c22 100644 --- a/include/configs/s5p_goni.h +++ b/include/configs/s5p_goni.h @@ -267,5 +267,7 @@ #define CONFIG_USB_GADGET_S3C_UDC_OTG #define CONFIG_USB_GADGET_DUALSPEED #define CONFIG_USB_GADGET_VBUS_DRAW 2 +#define CONFIG_CMD_USB_MASS_STORAGE +#define CONFIG_USB_GADGET_MASS_STORAGE #endif /* __CONFIG_H */ -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 00/13] DFU, MMC, Gadget, Goni, misc.
This is an updated version of patch series regarding DFU, MMC, USB Gadget and Samsung Goni board, originally sent on 10 January 2014. --- Changes since v1: - reordered "USB: gadget: added a saner gadget downloader registration API" - fixed a bug related to usb_cable_connected() which broke previous Goni configuration patches - disabled DFU in TI's am335x SPL build due to insufficient SRAM capacity v2: - fixed issues which came to [Marek Vasut]'s attention - rebased --- Mateusz Zalega (13): mmc: mmc header fix part: header fix arm:goni: Update configuration for goni target dfu: fix boards wo USB cable detection am335x: dfu: disable DFU in am335x_evm SPL build USB: gadget: added a saner gadget downloader registration API arm:goni:dfu Add support for DFU to Goni target arm:goni: enable GPT command arm:goni: enable USB Mass Storage dfu:mmc: raw data write fix mmc: postponed needless timer initialization ums: always initialize mmc before ums_disk_init() common: fixed linker-list example board/samsung/common/ums.c | 12 ++-- board/samsung/goni/goni.c | 8 +++ common/cmd_dfu.c| 3 +- common/cmd_thordown.c | 3 +- common/cmd_usb_mass_storage.c | 4 +- drivers/dfu/dfu_mmc.c | 106 +++-- drivers/mmc/mmc.c | 7 ++- drivers/usb/gadget/f_dfu.c | 3 + drivers/usb/gadget/f_mass_storage.c | 3 + drivers/usb/gadget/f_thor.c | 2 + drivers/usb/gadget/g_dnl.c | 64 +--- include/configs/am335x_evm.h| 10 ++-- include/configs/s5p_goni.h | 113 +--- include/configs/trats.h | 2 +- include/configs/trats2.h| 2 +- include/dfu.h | 12 include/g_dnl.h | 24 include/linker_lists.h | 2 +- include/mmc.h | 1 + include/part.h | 1 + include/thor.h | 8 --- include/usb_mass_storage.h | 8 --- 22 files changed, 236 insertions(+), 162 deletions(-) -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 05/13] am335x: dfu: disable DFU in am335x_evm SPL build
Future patches will make DFU too large to fit in this board's SPL build. Signed-off-by: Mateusz Zalega Cc: Tom Rini Cc: Lukasz Majewski --- include/configs/am335x_evm.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index fd6f52c..c1f2abf 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -315,6 +315,7 @@ #endif /* USB Device Firmware Update support */ +#ifndef CONFIG_SPL_BUILD #define CONFIG_DFU_FUNCTION #define CONFIG_DFU_MMC #define CONFIG_CMD_DFU @@ -357,6 +358,7 @@ DFU_ALT_INFO_MMC \ DFU_ALT_INFO_RAM \ DFU_ALT_INFO_NAND +#endif /* * Default to using SPI for environment, etc. -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 02/13] part: header fix
Implementation made use of types defined in common.h, even though it
wasn't #included. It worked in circumstances when .c files included
every needed header (all).
Signed-off-by: Mateusz Zalega
Cc: Minkyu Kang
---
include/part.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/part.h b/include/part.h
index 4beb6db..53532dc 100644
--- a/include/part.h
+++ b/include/part.h
@@ -8,6 +8,7 @@
#define _PART_H
#include
+#include
typedef struct block_dev_desc {
int if_type;/* type of the interface */
--
1.9.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kbuild: allow building tools without board configuration
On Mon, Mar 31, 2014 at 05:33:51PM +0900, Masahiro Yamada wrote: > Prior to Kbuild, U-Boot could build under tools/ directory > withour configuring for a specific board. > > That feature was lost when switching to Kbuild. > > This patch revives it again by adding a make target "tools-only". > > Usage: > $ make tools-only > > Neither board configuration nor cross compiler are required to > build host tools. > > Signed-off-by: Masahiro Yamada > Suggested-by: Alexey Brodkin > Cc: Alexey Brodkin > Cc: Simon Glass > Cc: Tom Rini > Acked-by: Alexey Brodkin Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kbuild: allow building tools without board configuration
On Mon, Mar 31, 2014 at 03:39:18PM +, Alexey Brodkin wrote: > On Mon, 2014-03-31 at 11:31 -0400, Tom Rini wrote: > > On Mon, Mar 31, 2014 at 03:24:19PM +, Alexey Brodkin wrote: > > > Hi Tom, > > > > > > On Mon, 2014-03-31 at 11:16 -0400, Tom Rini wrote: > > > > On Mon, Mar 31, 2014 at 05:33:51PM +0900, Masahiro Yamada wrote: > > > > > > > > > Prior to Kbuild, U-Boot could build under tools/ directory > > > > > withour configuring for a specific board. > > > > > > > > > > That feature was lost when switching to Kbuild. > > > > > > > > > > This patch revives it again by adding a make target "tools-only". > > > > > > > > > > Usage: > > > > > $ make tools-only > > > > > > > > > > Neither board configuration nor cross compiler are required to > > > > > build host tools. > > > > > > > > > > Signed-off-by: Masahiro Yamada > > > > > Suggested-by: Alexey Brodkin > > > > > Cc: Alexey Brodkin > > > > > Cc: Simon Glass > > > > > Cc: Tom Rini > > > > > > > > Problem is that we make enabling the signature code (which adds more > > > > deps on the host) based on the config, and this was intentional. So > > > > I'm not sure if we want to do this exactly, at least right now. > > > > > > Could you please add a bit more clarifications for your comment. > > > > > > I don't quite understand why do I need to have any info from a board > > > configuration when building "mkimage" utility. > > > > > > Maybe I'm missing something. > > > > > > And the problem is without proposed patch it's virtually impossible (or > > > I don't know how) to build "mkimage" without configuring the real board. > > > > > > For example what Linux distros will do to build generic "mkimage" tool? > > > > So, if you check out tools/mkimage.c you can see that if > > CONFIG_FIT_SIGNATURE is set we add options for doing rsa/etc signatures > > on parts of a FIT image (see doc/uImage.FIT/signature.txt). But then > > you need to have crypto libraries on the host available for linking. > > When not set we capture the relevant flags and print out a message to > > stderr. Since generic distros today hate FIT images even more than > > legacy images, I'm not overly concerned about that, today. > > So why don't we accept proposed patch so at least there will be a simple > way to build generic "mkimage" people usually need? > > If needed we may do more changes in the patch. For example we may add > warning message saying that FIT images won't be supported by this > "generic" "mkimage" etc. Yeah, OK, we are no different than before at least (just checked, a sandbox mkimage is still fine) so I can accept this, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kbuild: allow building tools without board configuration
On Mon, 2014-03-31 at 11:31 -0400, Tom Rini wrote: > On Mon, Mar 31, 2014 at 03:24:19PM +, Alexey Brodkin wrote: > > Hi Tom, > > > > On Mon, 2014-03-31 at 11:16 -0400, Tom Rini wrote: > > > On Mon, Mar 31, 2014 at 05:33:51PM +0900, Masahiro Yamada wrote: > > > > > > > Prior to Kbuild, U-Boot could build under tools/ directory > > > > withour configuring for a specific board. > > > > > > > > That feature was lost when switching to Kbuild. > > > > > > > > This patch revives it again by adding a make target "tools-only". > > > > > > > > Usage: > > > > $ make tools-only > > > > > > > > Neither board configuration nor cross compiler are required to > > > > build host tools. > > > > > > > > Signed-off-by: Masahiro Yamada > > > > Suggested-by: Alexey Brodkin > > > > Cc: Alexey Brodkin > > > > Cc: Simon Glass > > > > Cc: Tom Rini > > > > > > Problem is that we make enabling the signature code (which adds more > > > deps on the host) based on the config, and this was intentional. So > > > I'm not sure if we want to do this exactly, at least right now. > > > > Could you please add a bit more clarifications for your comment. > > > > I don't quite understand why do I need to have any info from a board > > configuration when building "mkimage" utility. > > > > Maybe I'm missing something. > > > > And the problem is without proposed patch it's virtually impossible (or > > I don't know how) to build "mkimage" without configuring the real board. > > > > For example what Linux distros will do to build generic "mkimage" tool? > > So, if you check out tools/mkimage.c you can see that if > CONFIG_FIT_SIGNATURE is set we add options for doing rsa/etc signatures > on parts of a FIT image (see doc/uImage.FIT/signature.txt). But then > you need to have crypto libraries on the host available for linking. > When not set we capture the relevant flags and print out a message to > stderr. Since generic distros today hate FIT images even more than > legacy images, I'm not overly concerned about that, today. So why don't we accept proposed patch so at least there will be a simple way to build generic "mkimage" people usually need? If needed we may do more changes in the patch. For example we may add warning message saying that FIT images won't be supported by this "generic" "mkimage" etc. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] tegra: fix Makefile to pass per-file CFLAGS
On Mon, Mar 31, 2014 at 02:23:15PM +0900, Masahiro Yamada wrote: > Since Kbuild was introduced, warmboot_avp.o has been compiled > without -march=armv4t. > > Makefile should be adjusted to pass a per-file option. > > Signed-off-by: Masahiro Yamada > Cc: Stephen Warren > Cc: Tom Warren Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kbuild: allow building tools without board configuration
On Mon, Mar 31, 2014 at 03:24:19PM +, Alexey Brodkin wrote: > Hi Tom, > > On Mon, 2014-03-31 at 11:16 -0400, Tom Rini wrote: > > On Mon, Mar 31, 2014 at 05:33:51PM +0900, Masahiro Yamada wrote: > > > > > Prior to Kbuild, U-Boot could build under tools/ directory > > > withour configuring for a specific board. > > > > > > That feature was lost when switching to Kbuild. > > > > > > This patch revives it again by adding a make target "tools-only". > > > > > > Usage: > > > $ make tools-only > > > > > > Neither board configuration nor cross compiler are required to > > > build host tools. > > > > > > Signed-off-by: Masahiro Yamada > > > Suggested-by: Alexey Brodkin > > > Cc: Alexey Brodkin > > > Cc: Simon Glass > > > Cc: Tom Rini > > > > Problem is that we make enabling the signature code (which adds more > > deps on the host) based on the config, and this was intentional. So > > I'm not sure if we want to do this exactly, at least right now. > > Could you please add a bit more clarifications for your comment. > > I don't quite understand why do I need to have any info from a board > configuration when building "mkimage" utility. > > Maybe I'm missing something. > > And the problem is without proposed patch it's virtually impossible (or > I don't know how) to build "mkimage" without configuring the real board. > > For example what Linux distros will do to build generic "mkimage" tool? So, if you check out tools/mkimage.c you can see that if CONFIG_FIT_SIGNATURE is set we add options for doing rsa/etc signatures on parts of a FIT image (see doc/uImage.FIT/signature.txt). But then you need to have crypto libraries on the host available for linking. When not set we capture the relevant flags and print out a message to stderr. Since generic distros today hate FIT images even more than legacy images, I'm not overly concerned about that, today. > > And I think it is very important to resolve before U-Boot v2014.04 gets > released. I agree, yes. > > -Alexey > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kbuild: allow building tools without board configuration
Hi Tom, On Mon, 2014-03-31 at 11:16 -0400, Tom Rini wrote: > On Mon, Mar 31, 2014 at 05:33:51PM +0900, Masahiro Yamada wrote: > > > Prior to Kbuild, U-Boot could build under tools/ directory > > withour configuring for a specific board. > > > > That feature was lost when switching to Kbuild. > > > > This patch revives it again by adding a make target "tools-only". > > > > Usage: > > $ make tools-only > > > > Neither board configuration nor cross compiler are required to > > build host tools. > > > > Signed-off-by: Masahiro Yamada > > Suggested-by: Alexey Brodkin > > Cc: Alexey Brodkin > > Cc: Simon Glass > > Cc: Tom Rini > > Problem is that we make enabling the signature code (which adds more > deps on the host) based on the config, and this was intentional. So > I'm not sure if we want to do this exactly, at least right now. Could you please add a bit more clarifications for your comment. I don't quite understand why do I need to have any info from a board configuration when building "mkimage" utility. Maybe I'm missing something. And the problem is without proposed patch it's virtually impossible (or I don't know how) to build "mkimage" without configuring the real board. For example what Linux distros will do to build generic "mkimage" tool? And I think it is very important to resolve before U-Boot v2014.04 gets released. -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ti/master
Hey, The following changes since commit ab6423cae0323e8db2c8fdd0a99138d93fde2137: Merge branch 'u-boot/master' into 'u-boot-arm/master' (2014-03-25 10:53:15 +0100) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to 96de041ed9d91f87e59a1bf55dfa35d5caec8b26: board: enable 32kHz RTC OSC at B&R boards (2014-03-31 11:19:41 -0400) Hannes Petermaier (1): board: enable 32kHz RTC OSC at B&R boards include/configs/bur_am335x_common.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] board: enable 32kHz RTC OSC at B&R boards
On Thu, Mar 27, 2014 at 10:37:36AM +0100, Hannes Petermaier wrote: > Since RTC-Clock is needed on all B&R boards, the OSC will be enabled > wihtin SPL-stage. > > Signed-off-by: Hannes Petermaier Applied to u-boot-ti/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kbuild: allow building tools without board configuration
On Mon, Mar 31, 2014 at 05:33:51PM +0900, Masahiro Yamada wrote: > Prior to Kbuild, U-Boot could build under tools/ directory > withour configuring for a specific board. > > That feature was lost when switching to Kbuild. > > This patch revives it again by adding a make target "tools-only". > > Usage: > $ make tools-only > > Neither board configuration nor cross compiler are required to > build host tools. > > Signed-off-by: Masahiro Yamada > Suggested-by: Alexey Brodkin > Cc: Alexey Brodkin > Cc: Simon Glass > Cc: Tom Rini Problem is that we make enabling the signature code (which adds more deps on the host) based on the config, and this was intentional. So I'm not sure if we want to do this exactly, at least right now. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 04/10] power: Explicitly select pmic device's bus
Hi Simon, > Hi Lukasz, > > On 27 March 2014 11:33, Lukasz Majewski > wrote: Hi Simon, Heiko > > > From: Aaron Durbin > > > > The current pmic i2c code assumes the current i2c bus is > > the same as the pmic device's bus. There is nothing ensuring > > that to be true. Therefore, select the proper bus before performing > > a transaction. > > > > Signed-off-by: Aaron Durbin > > Signed-off-by: Simon Glass > > Reviewed-by: Simon Glass > > --- > > > > drivers/power/power_i2c.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/drivers/power/power_i2c.c b/drivers/power/power_i2c.c > > index ac76870..594cd11 100644 > > --- a/drivers/power/power_i2c.c > > +++ b/drivers/power/power_i2c.c > > @@ -23,6 +23,8 @@ int pmic_reg_write(struct pmic *p, u32 reg, u32 > > val) if (check_reg(p, reg)) > > return -1; > > > > + I2C_SET_BUS(p->bus); > > + > > Hadn't we had a discussion about this explicit setting of I2C some > time ago? I thought that this problem was solved within the I2C > rework. > > Also I might be wrong, so please correct me if I'm wrong. Isn't the > I2C_SET_BUS() macro regarded as a obsolete after the I2C rework? > > Agreed that would be ideal, but we would have to pass the bus number > of the i2c_read/write() functions. I don't believe the i2c code has > got that far yet. > > Unfortunately it doesn't work without this patch. If Heiko doesn't object, then I won't protest. > > Regards, > Simon > -- Best regards, Lukasz Majewski Samsung R&D Institute Poland (SRPOL) | Linux Platform Group ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/10] power: Add support for TPS65090 PMU chip.
Hi Simon,
> Hi Lukasz,
>
> On 27 March 2014 11:59, Lukasz Majewski
> wrote: Hi Simon,
>
> > From: Tom Wai-Hong Tam
> >
> > This adds driver support for the TPS65090 PMU. Support includes
> > hooking into the pmic infrastructure so that the pmic commands
> > can be used on the console. The TPS65090 supports the following
> > functionality:
> >
> > - fet enable/disable/querying
> > - getting and setting of charge state
> >
> > Even though it is connected to the pmic infrastructure it does
> > not hook into the pmic charging charging infrastructure.
>
> Can I ask what was the problem with adding support for "pmic bat
> [state|charge]" command on this PMIC?
>
> Was the framework unfriendly or there was no need to do that?
>
> It's not great. I spent a bit of time trying again. It think the
> issues are:
>
> - no device tree support
> - no comments in the pmic.h file so it's hard do know what everything
> is for
You are right here - the lack of DT support is the main problem here.
As Tom Rini pointed out - it is problematic in this framework to
support more than one instance of the same PMIC device.
I must confess that I've overlooked this use case.
> - the battery charging command should really be common, not specific
> to each driver
I agree. We can try to discuss one solution suitable for Exynos4 and 5.
>
> I did actually create a battery system in the Chromium source tree a
> while back, but never sent it upstream, partly because the pmic stuff
> was there and I was not sure how to get it into that framework.
>
> I think maybe if someone can comment the pmic.h file then I could
> have another try. But it would be a separate series to this one,
> which is focussed on the LCD, not the battery.
For a quick reference please consider Trats and Trats2. If you need any
more help, then please write an e-mail to me.
>
> >
> > Signed-off-by: Tom Wai-Hong Tam
> > Signed-off-by: Simon Glass
> > Signed-off-by: Hatim Ali
> > Signed-off-by: Katie Roberts-Hoffman
> > Signed-off-by: Rong Chang
> > Signed-off-by: Sean Paul
> > Signed-off-by: Vincent Palatin
> > Signed-off-by: Aaron Durbin
> > ---
> >
> > doc/device-tree-bindings/power/tps65090.txt | 21 ++
> > drivers/power/pmic/Makefile | 1 +
> > drivers/power/pmic/pmic_tps65090.c | 296
> >
> > include/fdtdec.h | 1 +
> > include/power/tps65090_pmic.h | 83
> > lib/fdtdec.c | 1 + 6 files changed,
> > 403 insertions(+) create mode 100644
> > doc/device-tree-bindings/power/tps65090.txt create mode 100644
> > drivers/power/pmic/pmic_tps65090.c create mode 100644
> > include/power/tps65090_pmic.h
> >
> > diff --git a/doc/device-tree-bindings/power/tps65090.txt
> > b/doc/device-tree-bindings/power/tps65090.txt new file mode 100644
> > index 000..6a8a884
> > --- /dev/null
> > +++ b/doc/device-tree-bindings/power/tps65090.txt
> > @@ -0,0 +1,21 @@
> > +TPSchrome binding
> > +=
> > +
> > +The device tree node which describes the operation of the Texas
> > Instrument +TPS65090 power regulator chip is as follows:
> > +
> > +Required properties :
> > +- compatible : "ti,tps65090"
> > +- reg : slave address on the i2c bus
> > +
> > +The tps65090 node should appear as a subnode of the i2c bus that
> > connects it. +
> > +Example
> > +===
> > +
> > + i2c@12ca {
> > + power-regulator@48 {
> > + compatible = "ti,tps65090"
> > + reg = <0x48>;
> > + };
> > + };
>
> Those bindings look very different from the one at Linux kernel for
> this device. Therefore I assume that there was justification to not
> stick to the linux kernel DT format.
>
> Yes they pre-date the kernel. But now that the kernel has support I
> will pull those in. For the parts we use it is the same.
That would be great, thanks.
>
> > diff --git a/drivers/power/pmic/Makefile
> > b/drivers/power/pmic/Makefile index 0b45ffa..7ed55e6 100644
> > --- a/drivers/power/pmic/Makefile
> > +++ b/drivers/power/pmic/Makefile
> > @@ -9,5 +9,6 @@ obj-$(CONFIG_POWER_MAX8998) += pmic_max8998.o
> > obj-$(CONFIG_POWER_MAX8997) += pmic_max8997.o
> > obj-$(CONFIG_POWER_MUIC_MAX8997) += muic_max8997.o
> > obj-$(CONFIG_POWER_MAX77686) += pmic_max77686.o
> > +obj-$(CONFIG_POWER_TPS65090) += pmic_tps65090.o
> > obj-$(CONFIG_POWER_TPS65217) += pmic_tps65217.o
> > obj-$(CONFIG_POWER_TPS65910) += pmic_tps65910.o
> > diff --git a/drivers/power/pmic/pmic_tps65090.c
> > b/drivers/power/pmic/pmic_tps65090.c new file mode 100644
> > index 000..ef9f911
> > --- /dev/null
> > +++ b/drivers/power/pmic/pmic_tps65090.c
> > @@ -0,0 +1,296 @@
> > +/*
> > + * Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
> > + * Use of this source code is governed by a BSD-style license that
> > can be
> > + * found in the LICENSE file.
> > + *
> > + * Alternatively, thi
Re: [U-Boot] All Sparc boards are broken
Hello, I was recently informed about the problem by Tom. As I mentioned to him I'm very busy at the moment. I haven't looked into it yet, but my plan remains to do so in a few weeks time. Thanks, Daniel Hellstrom On 03/31/2014 04:27 AM, Masahiro Yamada wrote: Hi Daniel, All Sparc boards are broken because get_tbclk() func is missing. lib/built-in.o: In function `tick_to_time': u-boot/lib/time.c:56: undefined reference to `get_tbclk' lib/built-in.o: In function `usec_to_tick': u-boot/lib/time.c:80: undefined reference to `get_tbclk' Nothing has been done with that error since Rob Herring's common timer framework. Daniel, can you fix them? Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] tools: fix Makefile to clean-up fit_info and fit_check_sign
On Mon, Mar 31, 2014 at 10:58:33AM +0900, Masahiro Yamada wrote: > Hi Tom, > > > On Fri, 28 Mar 2014 15:12:25 -0400 > Tom Rini wrote: > > > On Fri, Mar 28, 2014 at 03:09:51PM +0900, Masahiro Yamada wrote: > > > > > We should avoid the description in Makefile like this > > > > > > ifdef CONFIG_FIT_SIGNATURE > > > hostprogs-y += fit_info$(SFX) fit_check_sign$(SFX) > > > endif > > > > > > Otherwise, fit_info and fit_check_sign would never be cleaned > > > by "make clean". > > > > > > Cc: Heiko Schocher > > > > > > --- > > > tools/Makefile | 4 +--- > > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > > > diff --git a/tools/Makefile b/tools/Makefile > > > index c5c378c..c34df4f 100644 > > > --- a/tools/Makefile > > > +++ b/tools/Makefile > > > @@ -60,9 +60,7 @@ hostprogs-y += mkenvimage$(SFX) > > > mkenvimage$(SFX)-objs := crc32.o mkenvimage.o os_support.o > > > > > > hostprogs-y += dumpimage$(SFX) mkimage$(SFX) > > > -ifdef CONFIG_FIT_SIGNATURE > > > -hostprogs-y += fit_info$(SFX) fit_check_sign$(SFX) > > > -endif > > > +hostprogs-$(CONFIG_FIT_SIGNATURE) += fit_info$(SFX) fit_check_sign$(SFX) > > > > > > FIT_SIG_OBJS-$(CONFIG_FIT_SIGNATURE) := image-sig.o > > > # Flattened device tree objects > > > > What tree is this against, exactly? > > It's against u-boot/next > because commit 6bf4ca076 and commit 29a23f9d went there. > > I forgot to add Signed-off-by. > If you need it, I will resend it. Ah, OK. Yeah, please do. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [i2c] Pull request
On Mon, Mar 31, 2014 at 07:35:51AM +0200, Heiko Schocher wrote: > Hello Tom, > > please pull from u-boot-i2c.git, thanks! > > The following changes since commit 0b2da7e209f4110b7c81d578336a10330e4a4404: > > blackfin: mmc: Correct mmc_host_is_spi and bfin_sdh.c (2014-03-28 16:55:29 > -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-i2c.git master > > for you to fetch changes up to 462d1883f78353c5ed9d09de45a9b5b2422793a3: > > drivers: i2c: delete an unused source file (2014-03-31 07:30:55 +0200) > > > Masahiro Yamada (1): > drivers: i2c: delete an unused source file > > drivers/i2c/adi_i2c.c | 387 > > 1 file changed, 387 deletions(-) > delete mode 100644 drivers/i2c/adi_i2c.c Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-sh/master
On Mon, Mar 31, 2014 at 10:52:33AM +0900, Nobuhiro Iwamatsu wrote: > Dear Tom Rini. > > Please pull u-boot-sh master branch. > > The following changes since commit 0b2da7e209f4110b7c81d578336a10330e4a4404: > > blackfin: mmc: Correct mmc_host_is_spi and bfin_sdh.c (2014-03-28 > 16:55:29 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-sh master > > for you to fetch changes up to 82778e92c2816036ed79cdfb47e6eb6f6487a3f9: > > board: ecovec: fix USB0 clock enable (2014-03-31 10:48:02 +0900) > > > Baruch Siach (2): > board: ecovec: fix debug LEDs pin direction > board: ecovec: fix USB0 clock enable > > board/renesas/ecovec/ecovec.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting
Hi Lukasz,
Hmm, looking at the code the crc is updated when draining the buffer.
That means that in essence you're working with cache-cold data.
Can you try performing the crc32 right in the dfu_write() function
just after the memcpy?
Regards
-- Pantelis
On Mar 31, 2014, at 3:04 PM, Lukasz Majewski wrote:
> Hi Pantelis,
>
>> Hi Lukasz,
>>
>> On Mar 31, 2014, at 11:48 AM, Lukasz Majewski wrote:
>>
>>> Up till now the CRC32 of received data was calculated
>>> unconditionally. The standard crc32 implementation causes long
>>> delays when large images were uploaded.
>>>
>>> The "dfu_checksum_method" environment variable gives the
>>> opportunity to enable on demand (when e.g. debugging) the crc32
>>> calculation. It can be done without need to recompile the u-boot
>>> binary.
>>>
>>> By default the crc32 is not calculated.
>>>
>>> Tests results:
>>> 400 MiB ums.img file
>>> Withcrc32 calculation: 65 sec [avg 6.29 MB/s]
>>> Without crc32 calculation: 25 sec [avg 16.17 MB/s]
>>>
>>
>> That's interesting; I'm surprised that there's so much difference.
>> Can we get some info about the environment? I.e. board, whether cache
>> is enabled etc.
>
>
> Board Exynos4412 - Trats2. Cache L1 enabled, cache L2 disabled.
>
> Crc32 is calculated for 32 MiB chunks of data in the received buffer.
> I'm using the standard software crc32 u-boot's implementation. It is
> the same as the one for perl-crc32 debian package.
>
>
>>
>> The crc table is per byte and I guess lookups maybe expensive.
>
> It seems so. Moreover the Exynos4412 has HW crypto engine which
> supports SHA1, MD5 and other algorithms. Unfortunately it doesn't
> provide speedup for crc32.
>
>
>>
>> Regards
>>
>> -- Pantelis
>>
>>
>>> Signed-off-by: Lukasz Majewski
>>> ---
>>> drivers/dfu/dfu.c | 34 ++
>>> include/dfu.h |5 +
>>> 2 files changed, 35 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
>>> index e15f959..5d50b47 100644
>>> --- a/drivers/dfu/dfu.c
>>> +++ b/drivers/dfu/dfu.c
>>> @@ -20,6 +20,7 @@ static bool dfu_reset_request;
>>> static LIST_HEAD(dfu_list);
>>> static int dfu_alt_num;
>>> static int alt_num_count;
>>> +static int dfu_checksum_method;
>>>
>>> bool dfu_reset(void)
>>> {
>>> @@ -99,6 +100,23 @@ unsigned char *dfu_get_buf(void)
>>> return dfu_buf;
>>> }
>>>
>>> +static int dfu_get_checksum_method(void)
>>> +{
>>> + char *s;
>>> +
>>> + s = getenv("dfu_checksum_method");
>>> + if (!s)
>>> + return DFU_NO_CHECKSUM;
>>> +
>>> + if (!strcmp(s, "crc32")) {
>>> + debug("%s: DFU checksum method: %s\n", __func__,
>>> s);
>>> + return DFU_CRC32;
>>> + } else {
>>> + error("DFU checksum method: %s not supported!\n",
>>> s);
>>> + return -EINVAL;
>>> + }
>>> +}
>>> +
>>> static int dfu_write_buffer_drain(struct dfu_entity *dfu)
>>> {
>>> long w_size;
>>> @@ -109,8 +127,8 @@ static int dfu_write_buffer_drain(struct
>>> dfu_entity *dfu) if (w_size == 0)
>>> return 0;
>>>
>>> - /* update CRC32 */
>>> - dfu->crc = crc32(dfu->crc, dfu->i_buf_start, w_size);
>>> + if (dfu_checksum_method == DFU_CRC32)
>>> + dfu->crc = crc32(dfu->crc, dfu->i_buf_start,
>>> w_size);
>>>
>>> ret = dfu->write_medium(dfu, dfu->offset, dfu->i_buf_start,
>>> &w_size); if (ret)
>>> @@ -234,7 +252,8 @@ static int dfu_read_buffer_fill(struct
>>> dfu_entity *dfu, void *buf, int size) /* consume */
>>> if (chunk > 0) {
>>> memcpy(buf, dfu->i_buf, chunk);
>>> - dfu->crc = crc32(dfu->crc, buf, chunk);
>>> + if (dfu_checksum_method == DFU_CRC32)
>>> + dfu->crc = crc32(dfu->crc, buf,
>>> chunk); dfu->i_buf += chunk;
>>> dfu->b_left -= chunk;
>>> dfu->r_left -= chunk;
>>> @@ -318,7 +337,9 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
>>> int size, int blk_seq_num) }
>>>
>>> if (ret < size) {
>>> - debug("%s: %s CRC32: 0x%x\n", __func__, dfu->name,
>>> dfu->crc);
>>> + if (dfu_checksum_method == DFU_CRC32)
>>> + debug("%s: %s CRC32: 0x%x\n", __func__,
>>> dfu->name,
>>> + dfu->crc);
>>> puts("\nUPLOAD ... done\nCtrl+C to exit ...\n");
>>>
>>> dfu_free_buf();
>>> @@ -393,6 +414,11 @@ int dfu_config_entities(char *env, char
>>> *interface, int num) dfu_alt_num = dfu_find_alt_num(env);
>>> debug("%s: dfu_alt_num=%d\n", __func__, dfu_alt_num);
>>>
>>> + ret = dfu_get_checksum_method();
>>> + if (ret < 0)
>>> + return ret;
>>> + dfu_checksum_method = ret;
>>> +
>>> dfu = calloc(sizeof(*dfu), dfu_alt_num);
>>> if (!dfu)
>>> return -1;
>>> diff --git a/include/dfu.h b/include/dfu.h
>>> index 751f0fd..855d6dc 100644
>>> --- a/include/dfu.h
>>> +++ b/include/dfu.h
>>> @@ -37,6 +37,11 @@ e
Re: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting
Hi Lukasz,
On Mar 31, 2014, at 3:04 PM, Lukasz Majewski wrote:
> Hi Pantelis,
>
>> Hi Lukasz,
>>
>> On Mar 31, 2014, at 11:48 AM, Lukasz Majewski wrote:
>>
>>> Up till now the CRC32 of received data was calculated
>>> unconditionally. The standard crc32 implementation causes long
>>> delays when large images were uploaded.
>>>
>>> The "dfu_checksum_method" environment variable gives the
>>> opportunity to enable on demand (when e.g. debugging) the crc32
>>> calculation. It can be done without need to recompile the u-boot
>>> binary.
>>>
>>> By default the crc32 is not calculated.
>>>
>>> Tests results:
>>> 400 MiB ums.img file
>>> Withcrc32 calculation: 65 sec [avg 6.29 MB/s]
>>> Without crc32 calculation: 25 sec [avg 16.17 MB/s]
>>>
>>
>> That's interesting; I'm surprised that there's so much difference.
>> Can we get some info about the environment? I.e. board, whether cache
>> is enabled etc.
>
>
> Board Exynos4412 - Trats2. Cache L1 enabled, cache L2 disabled.
>
> Crc32 is calculated for 32 MiB chunks of data in the received buffer.
> I'm using the standard software crc32 u-boot's implementation. It is
> the same as the one for perl-crc32 debian package.
>
Thanks for the report. Would it be too much to ask for the time it
takes to do a crc32 of the same image on user-space after boot?
I'm interested in the effect the disabling of L2 has.
>
>>
>> The crc table is per byte and I guess lookups maybe expensive.
>
> It seems so. Moreover the Exynos4412 has HW crypto engine which
> supports SHA1, MD5 and other algorithms. Unfortunately it doesn't
> provide speedup for crc32.
>
>
You could do a basic tradeoff of speed vs memory by creating larger tables
but it might not work if we're cache trashing.
Or even try using CRC with smaller tables (i.e. 4 bits) which would not affect
the cache much.
Regards
-- Pantelis
>>
>> Regards
>>
>> -- Pantelis
>>
>>
>>> Signed-off-by: Lukasz Majewski
>>> ---
>>> drivers/dfu/dfu.c | 34 ++
>>> include/dfu.h |5 +
>>> 2 files changed, 35 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
>>> index e15f959..5d50b47 100644
>>> --- a/drivers/dfu/dfu.c
>>> +++ b/drivers/dfu/dfu.c
>>> @@ -20,6 +20,7 @@ static bool dfu_reset_request;
>>> static LIST_HEAD(dfu_list);
>>> static int dfu_alt_num;
>>> static int alt_num_count;
>>> +static int dfu_checksum_method;
>>>
>>> bool dfu_reset(void)
>>> {
>>> @@ -99,6 +100,23 @@ unsigned char *dfu_get_buf(void)
>>> return dfu_buf;
>>> }
>>>
>>> +static int dfu_get_checksum_method(void)
>>> +{
>>> + char *s;
>>> +
>>> + s = getenv("dfu_checksum_method");
>>> + if (!s)
>>> + return DFU_NO_CHECKSUM;
>>> +
>>> + if (!strcmp(s, "crc32")) {
>>> + debug("%s: DFU checksum method: %s\n", __func__,
>>> s);
>>> + return DFU_CRC32;
>>> + } else {
>>> + error("DFU checksum method: %s not supported!\n",
>>> s);
>>> + return -EINVAL;
>>> + }
>>> +}
>>> +
>>> static int dfu_write_buffer_drain(struct dfu_entity *dfu)
>>> {
>>> long w_size;
>>> @@ -109,8 +127,8 @@ static int dfu_write_buffer_drain(struct
>>> dfu_entity *dfu) if (w_size == 0)
>>> return 0;
>>>
>>> - /* update CRC32 */
>>> - dfu->crc = crc32(dfu->crc, dfu->i_buf_start, w_size);
>>> + if (dfu_checksum_method == DFU_CRC32)
>>> + dfu->crc = crc32(dfu->crc, dfu->i_buf_start,
>>> w_size);
>>>
>>> ret = dfu->write_medium(dfu, dfu->offset, dfu->i_buf_start,
>>> &w_size); if (ret)
>>> @@ -234,7 +252,8 @@ static int dfu_read_buffer_fill(struct
>>> dfu_entity *dfu, void *buf, int size) /* consume */
>>> if (chunk > 0) {
>>> memcpy(buf, dfu->i_buf, chunk);
>>> - dfu->crc = crc32(dfu->crc, buf, chunk);
>>> + if (dfu_checksum_method == DFU_CRC32)
>>> + dfu->crc = crc32(dfu->crc, buf,
>>> chunk); dfu->i_buf += chunk;
>>> dfu->b_left -= chunk;
>>> dfu->r_left -= chunk;
>>> @@ -318,7 +337,9 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
>>> int size, int blk_seq_num) }
>>>
>>> if (ret < size) {
>>> - debug("%s: %s CRC32: 0x%x\n", __func__, dfu->name,
>>> dfu->crc);
>>> + if (dfu_checksum_method == DFU_CRC32)
>>> + debug("%s: %s CRC32: 0x%x\n", __func__,
>>> dfu->name,
>>> + dfu->crc);
>>> puts("\nUPLOAD ... done\nCtrl+C to exit ...\n");
>>>
>>> dfu_free_buf();
>>> @@ -393,6 +414,11 @@ int dfu_config_entities(char *env, char
>>> *interface, int num) dfu_alt_num = dfu_find_alt_num(env);
>>> debug("%s: dfu_alt_num=%d\n", __func__, dfu_alt_num);
>>>
>>> + ret = dfu_get_checksum_method();
>>> + if (ret < 0)
>>> + return ret;
>>> + dfu_checksum_method = ret;
>>> +
>>> dfu = calloc(sizeof(*dfu), dfu_alt_num);
>>> if (!dfu)
Re: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting
Hi Pantelis,
> Hi Lukasz,
>
> On Mar 31, 2014, at 11:48 AM, Lukasz Majewski wrote:
>
> > Up till now the CRC32 of received data was calculated
> > unconditionally. The standard crc32 implementation causes long
> > delays when large images were uploaded.
> >
> > The "dfu_checksum_method" environment variable gives the
> > opportunity to enable on demand (when e.g. debugging) the crc32
> > calculation. It can be done without need to recompile the u-boot
> > binary.
> >
> > By default the crc32 is not calculated.
> >
> > Tests results:
> > 400 MiB ums.img file
> > Withcrc32 calculation: 65 sec [avg 6.29 MB/s]
> > Without crc32 calculation: 25 sec [avg 16.17 MB/s]
> >
>
> That's interesting; I'm surprised that there's so much difference.
> Can we get some info about the environment? I.e. board, whether cache
> is enabled etc.
Board Exynos4412 - Trats2. Cache L1 enabled, cache L2 disabled.
Crc32 is calculated for 32 MiB chunks of data in the received buffer.
I'm using the standard software crc32 u-boot's implementation. It is
the same as the one for perl-crc32 debian package.
>
> The crc table is per byte and I guess lookups maybe expensive.
It seems so. Moreover the Exynos4412 has HW crypto engine which
supports SHA1, MD5 and other algorithms. Unfortunately it doesn't
provide speedup for crc32.
>
> Regards
>
> -- Pantelis
>
>
> > Signed-off-by: Lukasz Majewski
> > ---
> > drivers/dfu/dfu.c | 34 ++
> > include/dfu.h |5 +
> > 2 files changed, 35 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> > index e15f959..5d50b47 100644
> > --- a/drivers/dfu/dfu.c
> > +++ b/drivers/dfu/dfu.c
> > @@ -20,6 +20,7 @@ static bool dfu_reset_request;
> > static LIST_HEAD(dfu_list);
> > static int dfu_alt_num;
> > static int alt_num_count;
> > +static int dfu_checksum_method;
> >
> > bool dfu_reset(void)
> > {
> > @@ -99,6 +100,23 @@ unsigned char *dfu_get_buf(void)
> > return dfu_buf;
> > }
> >
> > +static int dfu_get_checksum_method(void)
> > +{
> > + char *s;
> > +
> > + s = getenv("dfu_checksum_method");
> > + if (!s)
> > + return DFU_NO_CHECKSUM;
> > +
> > + if (!strcmp(s, "crc32")) {
> > + debug("%s: DFU checksum method: %s\n", __func__,
> > s);
> > + return DFU_CRC32;
> > + } else {
> > + error("DFU checksum method: %s not supported!\n",
> > s);
> > + return -EINVAL;
> > + }
> > +}
> > +
> > static int dfu_write_buffer_drain(struct dfu_entity *dfu)
> > {
> > long w_size;
> > @@ -109,8 +127,8 @@ static int dfu_write_buffer_drain(struct
> > dfu_entity *dfu) if (w_size == 0)
> > return 0;
> >
> > - /* update CRC32 */
> > - dfu->crc = crc32(dfu->crc, dfu->i_buf_start, w_size);
> > + if (dfu_checksum_method == DFU_CRC32)
> > + dfu->crc = crc32(dfu->crc, dfu->i_buf_start,
> > w_size);
> >
> > ret = dfu->write_medium(dfu, dfu->offset, dfu->i_buf_start,
> > &w_size); if (ret)
> > @@ -234,7 +252,8 @@ static int dfu_read_buffer_fill(struct
> > dfu_entity *dfu, void *buf, int size) /* consume */
> > if (chunk > 0) {
> > memcpy(buf, dfu->i_buf, chunk);
> > - dfu->crc = crc32(dfu->crc, buf, chunk);
> > + if (dfu_checksum_method == DFU_CRC32)
> > + dfu->crc = crc32(dfu->crc, buf,
> > chunk); dfu->i_buf += chunk;
> > dfu->b_left -= chunk;
> > dfu->r_left -= chunk;
> > @@ -318,7 +337,9 @@ int dfu_read(struct dfu_entity *dfu, void *buf,
> > int size, int blk_seq_num) }
> >
> > if (ret < size) {
> > - debug("%s: %s CRC32: 0x%x\n", __func__, dfu->name,
> > dfu->crc);
> > + if (dfu_checksum_method == DFU_CRC32)
> > + debug("%s: %s CRC32: 0x%x\n", __func__,
> > dfu->name,
> > + dfu->crc);
> > puts("\nUPLOAD ... done\nCtrl+C to exit ...\n");
> >
> > dfu_free_buf();
> > @@ -393,6 +414,11 @@ int dfu_config_entities(char *env, char
> > *interface, int num) dfu_alt_num = dfu_find_alt_num(env);
> > debug("%s: dfu_alt_num=%d\n", __func__, dfu_alt_num);
> >
> > + ret = dfu_get_checksum_method();
> > + if (ret < 0)
> > + return ret;
> > + dfu_checksum_method = ret;
> > +
> > dfu = calloc(sizeof(*dfu), dfu_alt_num);
> > if (!dfu)
> > return -1;
> > diff --git a/include/dfu.h b/include/dfu.h
> > index 751f0fd..855d6dc 100644
> > --- a/include/dfu.h
> > +++ b/include/dfu.h
> > @@ -37,6 +37,11 @@ enum dfu_op {
> > DFU_OP_WRITE,
> > };
> >
> > +enum dfu_checksum {
> > + DFU_NO_CHECKSUM = 0,
> > + DFU_CRC32,
> > +};
> > +
> > #define DFU_NOT_SUPPORTED -1
> >
> > struct mmc_internal_data {
> > --
> > 1.7.10.4
> >
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
_
Re: [U-Boot] Chain loading an u-boot from an u-boot
On 02/13/2014 10:03 AM, Helmut Raiger wrote: But you just inspired me! There are probably interrupts running for some time when the second u-boot starts and the relocation might destroy part of the interrupt entry points Thx for asking the right questions. I'll have to check this. Helmut I'm finally able to start the second u-boot (other things in-between as always). If I do a cleanup_before_linux(), i.e. turn off interrupts and caches before the actual 'go' and it works just fine. For testing I patched the go command, but obviously this can't be contributed as such. Anyone having a suggestion on how to do this? 1) add option to 'go' command, which is hard as it has variable arguments 2) add another go command 3) use an environment variable to set the option for 'go' Theoretically I could use a u-boot image to encapsulate the second u-boot and use 'bootm', but I think I'll stumble over the same kind of questions. Helmut -- Scanned by MailScanner. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting
Hi Lukasz,
On Mar 31, 2014, at 11:48 AM, Lukasz Majewski wrote:
> Up till now the CRC32 of received data was calculated unconditionally.
> The standard crc32 implementation causes long delays when large images
> were uploaded.
>
> The "dfu_checksum_method" environment variable gives the opportunity to
> enable on demand (when e.g. debugging) the crc32 calculation.
> It can be done without need to recompile the u-boot binary.
>
> By default the crc32 is not calculated.
>
> Tests results:
> 400 MiB ums.img file
> With crc32 calculation: 65 sec [avg 6.29 MB/s]
> Without crc32 calculation: 25 sec [avg 16.17 MB/s]
>
That's interesting; I'm surprised that there's so much difference.
Can we get some info about the environment? I.e. board, whether cache
is enabled etc.
The crc table is per byte and I guess lookups maybe expensive.
Regards
-- Pantelis
> Signed-off-by: Lukasz Majewski
> ---
> drivers/dfu/dfu.c | 34 ++
> include/dfu.h |5 +
> 2 files changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/dfu/dfu.c b/drivers/dfu/dfu.c
> index e15f959..5d50b47 100644
> --- a/drivers/dfu/dfu.c
> +++ b/drivers/dfu/dfu.c
> @@ -20,6 +20,7 @@ static bool dfu_reset_request;
> static LIST_HEAD(dfu_list);
> static int dfu_alt_num;
> static int alt_num_count;
> +static int dfu_checksum_method;
>
> bool dfu_reset(void)
> {
> @@ -99,6 +100,23 @@ unsigned char *dfu_get_buf(void)
> return dfu_buf;
> }
>
> +static int dfu_get_checksum_method(void)
> +{
> + char *s;
> +
> + s = getenv("dfu_checksum_method");
> + if (!s)
> + return DFU_NO_CHECKSUM;
> +
> + if (!strcmp(s, "crc32")) {
> + debug("%s: DFU checksum method: %s\n", __func__, s);
> + return DFU_CRC32;
> + } else {
> + error("DFU checksum method: %s not supported!\n", s);
> + return -EINVAL;
> + }
> +}
> +
> static int dfu_write_buffer_drain(struct dfu_entity *dfu)
> {
> long w_size;
> @@ -109,8 +127,8 @@ static int dfu_write_buffer_drain(struct dfu_entity *dfu)
> if (w_size == 0)
> return 0;
>
> - /* update CRC32 */
> - dfu->crc = crc32(dfu->crc, dfu->i_buf_start, w_size);
> + if (dfu_checksum_method == DFU_CRC32)
> + dfu->crc = crc32(dfu->crc, dfu->i_buf_start, w_size);
>
> ret = dfu->write_medium(dfu, dfu->offset, dfu->i_buf_start, &w_size);
> if (ret)
> @@ -234,7 +252,8 @@ static int dfu_read_buffer_fill(struct dfu_entity *dfu,
> void *buf, int size)
> /* consume */
> if (chunk > 0) {
> memcpy(buf, dfu->i_buf, chunk);
> - dfu->crc = crc32(dfu->crc, buf, chunk);
> + if (dfu_checksum_method == DFU_CRC32)
> + dfu->crc = crc32(dfu->crc, buf, chunk);
> dfu->i_buf += chunk;
> dfu->b_left -= chunk;
> dfu->r_left -= chunk;
> @@ -318,7 +337,9 @@ int dfu_read(struct dfu_entity *dfu, void *buf, int size,
> int blk_seq_num)
> }
>
> if (ret < size) {
> - debug("%s: %s CRC32: 0x%x\n", __func__, dfu->name, dfu->crc);
> + if (dfu_checksum_method == DFU_CRC32)
> + debug("%s: %s CRC32: 0x%x\n", __func__, dfu->name,
> + dfu->crc);
> puts("\nUPLOAD ... done\nCtrl+C to exit ...\n");
>
> dfu_free_buf();
> @@ -393,6 +414,11 @@ int dfu_config_entities(char *env, char *interface, int
> num)
> dfu_alt_num = dfu_find_alt_num(env);
> debug("%s: dfu_alt_num=%d\n", __func__, dfu_alt_num);
>
> + ret = dfu_get_checksum_method();
> + if (ret < 0)
> + return ret;
> + dfu_checksum_method = ret;
> +
> dfu = calloc(sizeof(*dfu), dfu_alt_num);
> if (!dfu)
> return -1;
> diff --git a/include/dfu.h b/include/dfu.h
> index 751f0fd..855d6dc 100644
> --- a/include/dfu.h
> +++ b/include/dfu.h
> @@ -37,6 +37,11 @@ enum dfu_op {
> DFU_OP_WRITE,
> };
>
> +enum dfu_checksum {
> + DFU_NO_CHECKSUM = 0,
> + DFU_CRC32,
> +};
> +
> #define DFU_NOT_SUPPORTED -1
>
> struct mmc_internal_data {
> --
> 1.7.10.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Booting image from ARM for different architecture
Hi all, I want to check with you if someone tried this scenario. Load u-boot on main CPU (for me ARM cortex-a9) and boot different cpu(for me Microblaze) with FIT image or old u-boot image format. IRC I have seen any code regarding this but I am not able to find it out where. :-( My current usage is that I do that steps by hand by tftp 10 kernel.bin (microblaze kernel in bin format with rootfs and dtb in it) mwr 0xXX 0x1 (turn on microblaze via custom logic which jumps to 0x10) tftp 1000 image.ub (download arm kernel) bootm 0x1000 (boot arm kernel) I think that will be much better to have both kernels in one FIT image and and use two configurations. One for microblaze kernel and second for arm kernel and boot it with one bootm command. Simon: Is this configuration even supported by FIT image? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Kbuild: allow building tools without board configuration
On Mon, 2014-03-31 at 17:33 +0900, Masahiro Yamada wrote: > Prior to Kbuild, U-Boot could build under tools/ directory > withour configuring for a specific board. > > That feature was lost when switching to Kbuild. > > This patch revives it again by adding a make target "tools-only". > > Usage: > $ make tools-only > > Neither board configuration nor cross compiler are required to > build host tools. > > Signed-off-by: Masahiro Yamada > Suggested-by: Alexey Brodkin > Cc: Alexey Brodkin > Cc: Simon Glass > Cc: Tom Rini Works as expected for me. Acked-by: Alexey Brodkin -Alexey ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 10/10] board/t104xrdb: Add support of NAND, SD, SPI boot for T1040RDB
Add support of 2 stage NAND, SD, SPI boot loader using SPL framework. here, PBL initialise the internal SRAM and copy SPL(160KB). This further initialise DDR using SPD and environment and copy u-boot(768 KB) from NAND to DDR. Finally SPL transer control to u-boot. Initialise/create followings required for SPL framework - Add spl.c which defines board_init_f, board_init_r - update tlb and ddr accordingly Signed-off-by: Prabhakar Kushwaha --- This patch depends upon "[PATCH 3] powerpc/t104xrdb: Unification of T104xRDB header files" http://patchwork.ozlabs.org/patch/335207/ board/freescale/t104xrdb/Makefile |7 +- board/freescale/t104xrdb/README| 87 ++ board/freescale/t104xrdb/ddr.c |5 +- board/freescale/t104xrdb/spl.c | 118 + board/freescale/t104xrdb/t1040_rcw.cfg |7 ++ board/freescale/t104xrdb/t1042_rcw.cfg |7 ++ board/freescale/t104xrdb/t104x_pbi.cfg | 26 +++ board/freescale/t104xrdb/tlb.c | 12 +++ boards.cfg |6 ++ include/configs/T104xRDB.h | 128 10 files changed, 384 insertions(+), 19 deletions(-) create mode 100644 board/freescale/t104xrdb/spl.c create mode 100644 board/freescale/t104xrdb/t1040_rcw.cfg create mode 100644 board/freescale/t104xrdb/t1042_rcw.cfg create mode 100644 board/freescale/t104xrdb/t104x_pbi.cfg diff --git a/board/freescale/t104xrdb/Makefile b/board/freescale/t104xrdb/Makefile index e51fb7a..a68c951 100644 --- a/board/freescale/t104xrdb/Makefile +++ b/board/freescale/t104xrdb/Makefile @@ -4,10 +4,13 @@ # SPDX-License-Identifier: GPL-2.0+ # - +ifdef CONFIG_SPL_BUILD +obj-y += spl.o +else obj-y += t104xrdb.o -obj-y += ddr.o obj-y += eth.o obj-$(CONFIG_PCI) += pci.o +endif +obj-y += ddr.o obj-y += law.o obj-y += tlb.o diff --git a/board/freescale/t104xrdb/README b/board/freescale/t104xrdb/README index 1da52bb..4001ac8 100644 --- a/board/freescale/t104xrdb/README +++ b/board/freescale/t104xrdb/README @@ -198,3 +198,90 @@ The below commands apply to the board 2.To change from vbank4 to vbank0 => qixis reset (it will boot using vbank0) + +NAND boot with 2 Stage boot loader +-- +PBL initialise the internal SRAM and copy SPL(160KB) in SRAM. +SPL further initialise DDR using SPD and environment variables and copy +u-boot(768 KB) from flash to DDR. +Finally SPL transer control to u-boot for futher booting. + +SPL has following features: + - Executes within 256K + - No relocation required + + Run time view of SPL framework during NAND boot :- + --- + Area| Address | +--- + Reserve | 0xFFFC (32KB) | + --- + GD, BD | 0xFFFC8000 (4KB)| + --- + ENV | 0xFFFC9000 (6KB)| + --- + HEAP| 0xFFFCA800 (34KB) | + --- + STACK | 0xFFFD8000 (20KB) | + --- + U-boot SPL | 0xFFFD8000 (160KB) | + --- + + Run time view of SPL framework during SD, SPI boot :- + --- + Area| Address | +--- + Reserve | 0xFFFC (32KB) | + --- + GD, BD | 0xFFFC8000 (4KB)| + --- + HEAP| 0xFFFC9000 (40KB) | + --- + STACK | 0xFFFD8000 (20KB) | + --- + U-boot SPL | 0xFFFD8000 (160KB) | + --- + +NAND Flash memory Map on T104xRDB +-- + Start EndDefinition Size +0x00 0x0Fu-boot 1MB +0x18 0x19u-boot env 128KB +0x20 0x21FMAN Ucode 128KB +0x28 0x29QE Firmware 128KB + +SD Card memory Map on T104xRDB +-- + Block #blocks Definition Size +0x008 2048u-boot 1MB +0x800 0024u-boot env 8KB +0x820 0256FMAN Ucode 128KB +0x920 0256QE Firmware
[U-Boot] [PATCH 9/10] board/b4qds:Add support of 2 stage NAND boot-loader
Add support of 2 stage NAND boot loader using SPL framework.
here, PBL initialise the internal SRAM and copy SPL(160KB). This further
initialise DDR using SPD and environment and copy u-boot(768 KB) from NAND to
DDR.
Finally SPL transer control to u-boot.
Initialise/create followings required for SPL framework
- Add spl.c which defines board_init_f, board_init_r
- update tlb and ddr accordingly
Signed-off-by: Prabhakar Kushwaha
---
board/freescale/b4860qds/Makefile |9 ++-
board/freescale/b4860qds/ddr.c|5 +-
board/freescale/b4860qds/spl.c| 115 +
board/freescale/b4860qds/tlb.c| 10
boards.cfg|4 +-
doc/README.b4860qds | 35 +++
include/configs/B4860QDS.h| 64 ++---
7 files changed, 230 insertions(+), 12 deletions(-)
create mode 100644 board/freescale/b4860qds/spl.c
diff --git a/board/freescale/b4860qds/Makefile
b/board/freescale/b4860qds/Makefile
index e5cc054..0acd2a9 100644
--- a/board/freescale/b4860qds/Makefile
+++ b/board/freescale/b4860qds/Makefile
@@ -4,9 +4,14 @@
# SPDX-License-Identifier: GPL-2.0+
#
+ifdef CONFIG_SPL_BUILD
+obj-y += spl.o
+else
obj-y += b4860qds.o
-obj-y += ddr.o
obj-$(CONFIG_B4860QDS)+= eth_b4860qds.o
-obj-$(CONFIG_PCI) += pci.o
+obj-$(CONFIG_PCI) += pci.o
+endif
+
+obj-y += ddr.o
obj-y += law.o
obj-y += tlb.o
diff --git a/board/freescale/b4860qds/ddr.c b/board/freescale/b4860qds/ddr.c
index 187c3b3..2c17156 100644
--- a/board/freescale/b4860qds/ddr.c
+++ b/board/freescale/b4860qds/ddr.c
@@ -179,6 +179,7 @@ phys_size_t initdram(int board_type)
{
phys_size_t dram_size;
+#if defined(CONFIG_SPL_BUILD) || !defined(CONFIG_RAMBOOT_PBL)
puts("Initializingusing SPD\n");
dram_size = fsl_ddr_sdram();
@@ -186,7 +187,9 @@ phys_size_t initdram(int board_type)
dram_size = setup_ddr_tlbs(dram_size / 0x10);
dram_size *= 0x10;
- puts("DDR: ");
+#else
+ dram_size = fsl_ddr_sdram_size();
+#endif
return dram_size;
}
diff --git a/board/freescale/b4860qds/spl.c b/board/freescale/b4860qds/spl.c
new file mode 100644
index 000..d56cd30
--- /dev/null
+++ b/board/freescale/b4860qds/spl.c
@@ -0,0 +1,115 @@
+/* Copyright 2013 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include "../common/qixis.h"
+#include "b4860qds_qixis.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+phys_size_t get_effective_memsize(void)
+{
+ return CONFIG_SYS_L3_SIZE;
+}
+
+unsigned long get_board_sys_clk(void)
+{
+ u8 sysclk_conf = QIXIS_READ(brdcfg[1]);
+
+ switch ((sysclk_conf & 0x0C) >> 2) {
+ case QIXIS_CLK_100:
+ return 1;
+ case QIXIS_CLK_125:
+ return 12500;
+ case QIXIS_CLK_133:
+ return 1;
+ }
+ return ;
+}
+
+unsigned long get_board_ddr_clk(void)
+{
+ u8 ddrclk_conf = QIXIS_READ(brdcfg[1]);
+
+ switch (ddrclk_conf & 0x03) {
+ case QIXIS_CLK_100:
+ return 1;
+ case QIXIS_CLK_125:
+ return 12500;
+ case QIXIS_CLK_133:
+ return 1;
+ }
+ return ;
+}
+
+void board_init_f(ulong bootflag)
+{
+ u32 plat_ratio, sys_clk, uart_clk;
+ ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
+
+ /* Memcpy existing GD at CONFIG_SPL_GD_ADDR */
+ memcpy((void *)CONFIG_SPL_GD_ADDR, (void *)gd, sizeof(gd_t));
+
+ /* Update GD pointer */
+ gd = (gd_t *)(CONFIG_SPL_GD_ADDR);
+ __asm__ __volatile__("" : : : "memory");
+
+ console_init_f();
+
+ /* initialize selected port with appropriate baud rate */
+ sys_clk = get_board_sys_clk();
+ plat_ratio = (in_be32(&gur->rcwsr[0]) >> 25) & 0x1f;
+ uart_clk = sys_clk * plat_ratio / 2;
+
+ NS16550_init((NS16550_t)CONFIG_SYS_NS16550_COM1,
+uart_clk / 16 / CONFIG_BAUDRATE);
+
+ relocate_code(CONFIG_SPL_RELOC_STACK, (gd_t *)CONFIG_SPL_GD_ADDR, 0x0);
+}
+
+void board_init_r(gd_t *gd, ulong dest_addr)
+{
+ bd_t *bd;
+
+ bd = (bd_t *)(gd + sizeof(gd_t));
+ memset(bd, 0, sizeof(bd_t));
+ gd->bd = bd;
+ bd->bi_memstart = CONFIG_SYS_INIT_L3_ADDR;
+ bd->bi_memsize = CONFIG_SYS_L3_SIZE;
+
+ probecpu();
+ get_clocks();
+ mem_malloc_init(CONFIG_SPL_RELOC_MALLOC_ADDR,
+ CONFIG_SPL_RELOC_MALLOC_SIZE);
+
+#ifndef CONFIG_SPL_NAND_BOOT
+ env_init();
+#endif
+
+ /* relocate environment function pointers etc. */
+#ifdef CONFIG_SPL_NAND_BOOT
+ nand_spl_load_image(CONFIG_ENV_OFFSET, CONFIG_ENV_SIZE,
+ (uchar *)CONFIG_ENV_ADDR);
+ gd->env_addr = (ulong)(CONFIG_ENV_ADDR);
+ gd->env_valid = 1;
+#else
+ env_relo
[U-Boot] [PATCH 7/10] driver/mtd/spi:Read 8KB data chunk during u-boot load in SPL
SPI driver perform its operation(read/write) on 64KB buffer chunk for data
greater than 64KB. This buffer chunk is allocated from system heap.
During SPL boot, 768KB of data is read from SPI flash.
Here, heap size may not be sufficient enough to full-fill 64KB buffer
requirement of SPI driver. So break down u-boot read operation at 8KB of chunk.
Also, fix a warning i.e. "unused variable buf" during CONFIG_FSL_CORENET
Signed-off-by: Prabhakar Kushwaha
---
drivers/mtd/spi/fsl_espi_spl.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/spi/fsl_espi_spl.c b/drivers/mtd/spi/fsl_espi_spl.c
index e5ac79b..a55d741 100644
--- a/drivers/mtd/spi/fsl_espi_spl.c
+++ b/drivers/mtd/spi/fsl_espi_spl.c
@@ -20,8 +20,10 @@
void spi_boot(void)
{
void (*uboot)(void) __noreturn;
- u32 offset, code_len;
+ u32 offset, code_len, copy_len = 0;
+#ifndef CONFIG_FSL_CORENET
unsigned char *buf = NULL;
+#endif
struct spi_flash *flash;
flash = spi_flash_probe(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
@@ -56,8 +58,15 @@ void spi_boot(void)
code_len = code_len - CONFIG_SPL_MAX_SIZE;
#endif
/* copy code to DDR */
- spi_flash_read(flash, offset, code_len,
- (void *)CONFIG_SYS_SPI_FLASH_U_BOOT_DST);
+ printf("Loading second stage boot loader ");
+ while (copy_len <= code_len) {
+ spi_flash_read(flash, offset + copy_len, 0x2000,
+ (void *)(CONFIG_SYS_SPI_FLASH_U_BOOT_DST
+ + copy_len));
+ copy_len = copy_len + 0x2000;
+ putc('.');
+ }
+
/*
* Jump to U-Boot image
*/
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/10] Makefile: Add support of RAMBOOT_SPLPBL
Objective of this target to have concatenate binary having - SPL binary in PBL command format - U-boot binary Signed-off-by: Prabhakar Kushwaha --- Makefile | 19 +++ README |4 2 files changed, 23 insertions(+) diff --git a/Makefile b/Makefile index e5f5a8c..e7a0838 100644 --- a/Makefile +++ b/Makefile @@ -699,7 +699,11 @@ ALL-y += u-boot.srec u-boot.bin System.map ALL-$(CONFIG_NAND_U_BOOT) += u-boot-nand.bin ALL-$(CONFIG_ONENAND_U_BOOT) += u-boot-onenand.bin +ifeq ($(CONFIG_RAMBOOT_SPLPBL),y) +ALL-$(CONFIG_RAMBOOT_PBL) += u-boot-with-spl-pbl.bin +else ALL-$(CONFIG_RAMBOOT_PBL) += u-boot.pbl +endif ALL-$(CONFIG_SPL) += spl/u-boot-spl.bin ALL-$(CONFIG_SPL_FRAMEWORK) += u-boot.img ALL-$(CONFIG_TPL) += tpl/u-boot-tpl.bin @@ -882,6 +886,21 @@ endif u-boot-img.bin: spl/u-boot-spl.bin u-boot.img FORCE $(call if_changed,cat) +#Add a target to create boot binary having SPL binary in PBI format +#concatenated with u-boot binary. It is need by PowerPC SoC having +#internal SRAM <= 512KB. +MKIMAGEFLAGS_u-boot-spl.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:"%"=%) \ + -R $(srctree)/$(CONFIG_SYS_FSL_PBL_PBI:"%"=%) -T pblimage + +spl/u-boot-spl.pbl: spl/u-boot-spl.bin FORCE + $(call if_changed,mkimage) + +OBJCOPYFLAGS_u-boot-with-spl-pbl.bin = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) \ + --gap-fill=0xff + +u-boot-with-spl-pbl.bin: spl/u-boot-spl.pbl u-boot.bin FORCE + $(call if_changed,pad_cat) + # PPC4xx needs the SPL at the end of the image, since the reset vector # is located at 0xfffc. So we can't use the "u-boot-img.bin" target # and need to introduce a new build target with the full blown U-Boot diff --git a/README b/README index d8d5f60..7690fdb 100644 --- a/README +++ b/README @@ -486,6 +486,10 @@ The following options need to be configured: PBI commands can be used to configure SoC before it starts the execution. Please refer doc/README.pblimage for more details + CONFIG_RAMBOOT_SPLPBL + It adds a target to create boot binary having SPL binary in PBI format + concatenated with u-boot binary. + CONFIG_SYS_FSL_DDR_BE Defines the DDR controller register space as Big Endian -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/10] powerpc/mpc85xx: Avoid hardcoding in SPL linker script
SPL linker has fix location of bootpg and reset vector with respect to text
base.
It is not necessary to have fixed locations.
Avoid such hardcoding.
Signed-off-by: Prabhakar Kushwaha
---
arch/powerpc/cpu/mpc85xx/u-boot-spl.lds |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
index acaa093..4fad68b 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
@@ -66,11 +66,16 @@ SECTIONS
} :text = 0x
#else
#if defined(CONFIG_FSL_IFC) /* Restrict bootpg at 4K boundry for IFC */
- .bootpg ADDR(.text) + 0x1000 :
+#ifndef BOOT_PAGE_OFFSET
+#define BOOT_PAGE_OFFSET 0x1000
+#endif
+ .bootpg ADDR(.text) + BOOT_PAGE_OFFSET :
{
arch/powerpc/cpu/mpc85xx/start.o (.bootpg)
}
+#ifndef RESET_VECTOR_OFFSET
#define RESET_VECTOR_OFFSET 0x1ffc /* IFC has 8K sram */
+#endif
#elif defined(CONFIG_FSL_ELBC)
#define RESET_VECTOR_OFFSET 0xffc /* LBC has 4k sram */
#else
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/10] driver/ifc: define nand_spl_load_image() for SPL
nand_spl_load_image() can also be used for non TPL framework. Signed-off-by: Prabhakar Kushwaha --- drivers/mtd/nand/fsl_ifc_spl.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/fsl_ifc_spl.c b/drivers/mtd/nand/fsl_ifc_spl.c index 2f82f7c..8a7a3a3 100644 --- a/drivers/mtd/nand/fsl_ifc_spl.c +++ b/drivers/mtd/nand/fsl_ifc_spl.c @@ -88,7 +88,7 @@ static inline int bad_block(uchar *marker, int port_size) return __raw_readw((u16 *)marker) != 0x; } -#ifdef CONFIG_TPL_BUILD +#if defined(CONFIG_TPL_BUILD) || defined(CONFIG_SPL_BUILD) int nand_spl_load_image(uint32_t offs, unsigned int uboot_size, void *vdst) #else static int nand_load(uint32_t offs, unsigned int uboot_size, void *vdst) @@ -221,7 +221,7 @@ static int nand_load(uint32_t offs, unsigned int uboot_size, void *vdst) * Defines a static function nand_load_image() here, because non-static makes * the code too large for certain SPLs(minimal SPL, maximum size <= 4Kbytes) */ -#ifndef CONFIG_TPL_BUILD +#if !defined(CONFIG_TPL_BUILD) && !defined(CONFIG_SPL_BUILD) #define nand_spl_load_image(offs, uboot_size, vdst) \ nand_load(offs, uboot_size, vdst) #endif -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/10] powerpc/mpc85xx:Disable non DDR LAWs before init_law
Before parsing LAW table i.e. init_law, boot loader should disable all
previous LAWs except DDR LAWs which has been created by previous
pre boot loader during DDR initialization.
Signed-off-by: Prabhakar Kushwaha
---
arch/powerpc/cpu/mpc8xxx/law.c | 43 +++-
1 file changed, 34 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/law.c b/arch/powerpc/cpu/mpc8xxx/law.c
index a401083..0aa6ce1 100644
--- a/arch/powerpc/cpu/mpc8xxx/law.c
+++ b/arch/powerpc/cpu/mpc8xxx/law.c
@@ -221,6 +221,32 @@ int set_ddr_laws(u64 start, u64 sz, enum law_trgt_if id)
}
#endif /* not SPL */
+void disable_non_ddr_laws(void)
+{
+ int i;
+ int id;
+ for (i = 0; i < FSL_HW_NUM_LAWS; i++) {
+ u32 lawar = in_be32(LAWAR_ADDR(i));
+
+ if (lawar & LAW_EN) {
+ id = (lawar & ~LAW_EN) >> 20;
+ switch (id) {
+ case LAW_TRGT_IF_DDR_1:
+ case LAW_TRGT_IF_DDR_2:
+ case LAW_TRGT_IF_DDR_3:
+ case LAW_TRGT_IF_DDR_4:
+ case LAW_TRGT_IF_DDR_INTRLV:
+ case LAW_TRGT_IF_DDR_INTLV_34:
+ case LAW_TRGT_IF_DDR_INTLV_123:
+ case LAW_TRGT_IF_DDR_INTLV_1234:
+ continue;
+ default:
+ disable_law(i);
+ }
+ }
+ }
+}
+
void init_laws(void)
{
int i;
@@ -233,6 +259,14 @@ void init_laws(void)
#error FSL_HW_NUM_LAWS can not be greater than 32 w/o code changes
#endif
+#if !defined(CONFIG_SECURE_BOOT)
+ /*
+* if any non DDR LAWs has been created earlier, remove them before
+* LAW table is parsed.
+ */
+ disable_non_ddr_laws();
+#endif
+
/*
* Any LAWs that were set up before we booted assume they are meant to
* be around and mark them used.
@@ -244,15 +278,6 @@ void init_laws(void)
gd->arch.used_laws |= (1 << i);
}
-#if (defined(CONFIG_NAND_U_BOOT) && !defined(CONFIG_NAND_SPL)) || \
- (defined(CONFIG_SPL) && !defined(CONFIG_SPL_BUILD))
- /*
-* in SPL boot we've already parsed the law_table and setup those LAWs
-* so don't do it again.
-*/
- return;
-#endif
-
for (i = 0; i < num_law_entries; i++) {
if (law_table[i].index == -1)
set_next_law(law_table[i].addr, law_table[i].size,
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 03/10] powerpc:Add support of SPL non-relocation
Current SPL code base has BSS section placed after reset_vector. This means
they have to relocate to use the global variables. This put an implicit
requirement of having SPL size = Memory/2.
To avoid relocation:
- Move bss_section within SPL range
- Modify relocate_code()
Signed-off-by: Prabhakar Kushwaha
---
README |3 +++
arch/powerpc/cpu/mpc85xx/start.S|2 ++
arch/powerpc/cpu/mpc85xx/u-boot-spl.lds | 12
3 files changed, 17 insertions(+)
diff --git a/README b/README
index 7cb7c4f..d8d5f60 100644
--- a/README
+++ b/README
@@ -3310,6 +3310,9 @@ FIT uImage format:
continuing (the hardware starts execution after just
loading the first page rather than the full 4K).
+ CONFIG_SPL_SKIP_RELOCATE
+ Avoid SPL relocation
+
CONFIG_SPL_NAND_BASE
Include nand_base.c in the SPL. Requires
CONFIG_SPL_NAND_DRIVERS.
diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S
index 67e071b..c654363 100644
--- a/arch/powerpc/cpu/mpc85xx/start.S
+++ b/arch/powerpc/cpu/mpc85xx/start.S
@@ -1645,6 +1645,7 @@ relocate_code:
mr r10,r5 /* Save copy of Destination Address */
GET_GOT
+#ifndef CONFIG_SPL_SKIP_RELOCATE
mr r3,r5 /* Destination Address */
lis r4,CONFIG_SYS_MONITOR_BASE@h/* Source Address
*/
ori r4,r4,CONFIG_SYS_MONITOR_BASE@l
@@ -1735,6 +1736,7 @@ relocate_code:
mtlrr0
blr /* NEVER RETURNS! */
+#endif
.globl in_ram
in_ram:
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
index 4fad68b..8453f3a 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
@@ -57,6 +57,16 @@ SECTIONS
. = ALIGN(8);
__init_begin = .;
__init_end = .;
+#ifdef CONFIG_SPL_SKIP_RELOCATE
+ . = ALIGN(4);
+ __bss_start = .;
+ .bss : {
+ *(.sbss*)
+ *(.bss*)
+ }
+ . = ALIGN(4);
+ __bss_end = .;
+#endif
/* For ifc, elbc, esdhc, espi, all need the SPL without section .resetvec */
#ifdef CONFIG_SYS_MPC85XX_NO_RESETVEC
@@ -86,6 +96,7 @@ SECTIONS
} = 0x
#endif
+#ifndef CONFIG_SPL_SKIP_RELOCATE
/*
* Make sure that the bss segment isn't linked at 0x0, otherwise its
* address won't be updated during relocation fixups.
@@ -100,4 +111,5 @@ SECTIONS
}
. = ALIGN(4);
__bss_end = .;
+#endif
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/10] common/env: Point default environment for GD
GD(Global Data) structure has pointer to environment variable array.
but, it always point to default_environment assuming it is running from
final location.
So update GD pointer with env variable array during SPL boot.
Signed-off-by: Prabhakar Kushwaha
---
common/env_common.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/common/env_common.c b/common/env_common.c
index c0bfc2f..043150a 100644
--- a/common/env_common.c
+++ b/common/env_common.c
@@ -162,6 +162,9 @@ int env_import(const char *buf, int check)
if (himport_r(&env_htab, (char *)ep->data, ENV_SIZE, '\0', 0,
0, NULL)) {
gd->flags |= GD_FLG_ENV_READY;
+#ifdef CONFIG_SPL_BUILD
+ gd->env_addr = (unsigned long)ep->data;
+#endif
return 1;
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/0] powerpc: Add support 2 stage boot loader for corenet platform
Signed-off-by: Prabhakar Kushwaha --- Add support of 2 stage boot loader in cornet platforms using SPL framework. B4860QDS: NAND boot T1040RDB: NAND, SD, SPI boot T1042RDB_PI: NAND, SD, SPI boot In current secenrio size of u-boot can become >=512KB. So This patch set will be helpful for those SoC which has less internal SRAM(512KB). here, PBL initialise the internal SRAM and copy SPL(160KB) in SRAM. SPL further initialise DDR using SPD and environment variables and copy u-boot(768 KB) from flash to DDR. Finally SPL transer control to u-boot for futher booting. SPL has following features: - Executes within 256K - No relocation required Run time view of SPL framework :- Run time view of SPL framework during NAND boot :- --- Area| Address | --- Reserve | 0xFFFC (32KB) | --- GD, BD | 0xFFFC8000 (4KB)| --- ENV | 0xFFFC9000 (6KB)| --- HEAP| 0xFFFCA800 (34KB) | --- STACK | 0xFFFD8000 (20KB) | --- U-boot SPL | 0xFFFD8000 (160KB) | --- Run time view of SPL framework during SD, SPI boot :- --- Area| Address | --- Reserve | 0xFFFC (32KB) | --- GD, BD | 0xFFFC8000 (4KB)| --- HEAP| 0xFFFC9000 (40KB) | --- STACK | 0xFFFD8000 (20KB) | --- U-boot SPL | 0xFFFD8000 (160KB) | --- NAND Flash memory Map on T104xRDB -- Start EndDefinition Size 0x000x0Fu-boot 1MB 0x180x19u-boot env 128KB 0x200x21FMAN Ucode 128KB SD Card memory Map on T104xRDB -- Block #blocks Definition Size 0x008 2048u-boot 1MB 0x800 0024u-boot env 8KB 0x820 0256FMAN Ucode 128KB SPI Flash memory Map on T104xRDB -- Start EndDefinition Size 0x000x0Fu-boot 1MB 0x100x101FFFu-boot env 8KB 0x110x12FMAN Ucode 128KB --- This patch set contains:- [PATCH 1/10] powerpc/mpc85xx: Move LAW_EN define outside of config [PATCH 2/10] powerpc/mpc85xx: Avoid hardcoding in SPL linker script [PATCH 3/10] powerpc:Add support of SPL non-relocation [PATCH 4/10] powerpc/mpc85xx:Disable non DDR LAWs before init_law [PATCH 5/10] common/env: Point default environment for GD [PATCH 6/10] driver/ifc: define nand_spl_load_image() for SPL [PATCH 7/10] driver/mtd/spi:Read 8KB data chunk during u-boot load in SPL [PATCH 8/10] Makefile: Add support of RAMBOOT_SPLPBL [PATCH 9/10] board/b4qds:Add support of 2 stage NAND boot-loader [PATCH 10/10] board/t104xrdb: Add support of NAND, SD, SPI boot for T1040RDB -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/10] powerpc/mpc85xx: Move LAW_EN define outside of config
LAW_EN is only defined if CONFIG_SYS_CCSRBAR_DEFAULT is not equal to CONFIG_SYS_CCSRBAR_PHYS. in SPL framework CCSRBAR is not relocated hence both are same. This cause compilation error. So LAW_EN define outside of configs Signed-off-by: Prabhakar Kushwaha --- arch/powerpc/cpu/mpc85xx/start.S |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index dbbd8e5..67e071b 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -26,6 +26,8 @@ #undef MSR_KERNEL #define MSR_KERNEL ( MSR_ME ) /* Machine Check */ +#define LAW_EN 0x8000 + #if defined(CONFIG_NAND_SPL) || \ (defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_INIT_MINIMAL)) #define MINIMAL_SPL @@ -574,7 +576,6 @@ infinite_debug_loop: #ifdef CONFIG_FSL_CORENET #define CCSR_LAWBARH0 (CONFIG_SYS_CCSRBAR + 0x1000) -#define LAW_EN 0x8000 #define LAW_SIZE_4K0xb #define CCSRBAR_LAWAR (LAW_EN | (0x1e << 20) | LAW_SIZE_4K) #define CCSRAR_C 0x8000 /* Commit */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] driver/mmc: fix compile warnings
Fix following compile warnings
fsl_esdhc_spl.c: In function 'mmc_boot':
fsl_esdhc_spl.c:35:10: warning: unused variable 'byte_num' [-Wunused-variable]
fsl_esdhc_spl.c:35:7: warning: unused variable 'i' [-Wunused-variable]
fsl_esdhc_spl.c:34:8: warning: unused variable 'val' [-Wunused-variable]
fsl_esdhc_spl.c:33:6: warning: unused variable 'blklen' [-Wunused-variable]
fsl_esdhc_spl.c:105:7: warning: 'tmp_buf' may be used uninitialized in this
function [-Wuninitialized]
Signed-off-by: Prabhakar Kushwaha
---
drivers/mmc/fsl_esdhc_spl.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/fsl_esdhc_spl.c b/drivers/mmc/fsl_esdhc_spl.c
index 8fc263f..e0bbf21 100644
--- a/drivers/mmc/fsl_esdhc_spl.c
+++ b/drivers/mmc/fsl_esdhc_spl.c
@@ -29,10 +29,12 @@ void __noreturn mmc_boot(void)
{
__attribute__((noreturn)) void (*uboot)(void);
uint blk_start, blk_cnt, err;
- u32 blklen;
+#ifndef CONFIG_FSL_CORENET
uchar *tmp_buf;
+ u32 blklen;
uchar val;
uint i, byte_num;
+#endif
u32 offset, code_len;
struct mmc *mmc;
@@ -102,7 +104,9 @@ void __noreturn mmc_boot(void)
(uchar *)CONFIG_SYS_MMC_U_BOOT_DST);
if (err != blk_cnt) {
puts("spl: mmc read failed!!\n");
+#ifndef CONFIG_FSL_CORENET
free(tmp_buf);
+#endif
hang();
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] powerpc/mpc85xx:Update MONITOR_LEN for 768KB u-boot size
U-boot binary size has been increased from 512KB to 768KB. So update CONFIG_SYS_MONITOR_LEN to reflect the same. Signed-off-by: Prabhakar Kushwaha --- include/configs/B4860QDS.h |2 +- include/configs/BSC9131RDB.h |2 +- include/configs/BSC9132QDS.h |2 +- include/configs/C29XPCIE.h |2 +- include/configs/P1010RDB.h |2 +- include/configs/P1022DS.h |2 +- include/configs/P1023RDB.h |2 +- include/configs/P1023RDS.h |2 +- include/configs/P1_P2_RDB.h|2 +- include/configs/P2020DS.h |2 +- include/configs/P2041RDB.h |2 +- include/configs/T1040QDS.h |2 +- include/configs/T104xRDB.h |2 +- include/configs/T208xQDS.h |2 +- include/configs/T208xRDB.h |2 +- include/configs/corenet_ds.h |2 +- include/configs/p1_p2_rdb_pc.h |2 +- include/configs/p1_twr.h |2 +- include/configs/t4qds.h|2 +- 19 files changed, 19 insertions(+), 19 deletions(-) diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h index b248302..8fcd1de 100644 --- a/include/configs/B4860QDS.h +++ b/include/configs/B4860QDS.h @@ -414,7 +414,7 @@ unsigned long get_board_ddr_clk(void); GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_GBL_DATA_OFFSET -#define CONFIG_SYS_MONITOR_LEN (512 * 1024) +#define CONFIG_SYS_MONITOR_LEN (768 * 1024) #define CONFIG_SYS_MALLOC_LEN (4 * 1024 * 1024) /* Serial Port - controlled on board with jumper J8 diff --git a/include/configs/BSC9131RDB.h b/include/configs/BSC9131RDB.h index a163e3d..5a316c8 100644 --- a/include/configs/BSC9131RDB.h +++ b/include/configs/BSC9131RDB.h @@ -220,7 +220,7 @@ extern unsigned long get_sdram_size(void); - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_GBL_DATA_OFFSET -#define CONFIG_SYS_MONITOR_LEN (256 * 1024) /* Reserve 256 kB for Mon*/ +#define CONFIG_SYS_MONITOR_LEN (768 * 1024) #define CONFIG_SYS_MALLOC_LEN (1024 * 1024) /* Reserved for malloc*/ /* Serial Port */ diff --git a/include/configs/BSC9132QDS.h b/include/configs/BSC9132QDS.h index 052a0f1..c654277 100644 --- a/include/configs/BSC9132QDS.h +++ b/include/configs/BSC9132QDS.h @@ -396,7 +396,7 @@ combinations. this should be removed later - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_GBL_DATA_OFFSET -#define CONFIG_SYS_MONITOR_LEN (256 * 1024) /* Reserve 256 kB for Mon*/ +#define CONFIG_SYS_MONITOR_LEN (768 * 1024) #define CONFIG_SYS_MALLOC_LEN (1024 * 1024) /* Reserved for malloc*/ /* Serial Port */ diff --git a/include/configs/C29XPCIE.h b/include/configs/C29XPCIE.h index 92913c8..9e12fac 100644 --- a/include/configs/C29XPCIE.h +++ b/include/configs/C29XPCIE.h @@ -338,7 +338,7 @@ - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_GBL_DATA_OFFSET -#define CONFIG_SYS_MONITOR_LEN (512 * 1024) +#define CONFIG_SYS_MONITOR_LEN (768 * 1024) #define CONFIG_SYS_MALLOC_LEN (2 * 1024 * 1024) /* diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h index eabfc85..ff4c5c1 100644 --- a/include/configs/P1010RDB.h +++ b/include/configs/P1010RDB.h @@ -566,7 +566,7 @@ extern unsigned long get_sdram_size(void); - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_GBL_DATA_OFFSET -#define CONFIG_SYS_MONITOR_LEN (256 * 1024) /* Reserve 256 kB for Mon*/ +#define CONFIG_SYS_MONITOR_LEN (768 * 1024) #define CONFIG_SYS_MALLOC_LEN (1024 * 1024) /* Reserved for malloc*/ /* diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h index 139d4fe..959cdf6 100644 --- a/include/configs/P1022DS.h +++ b/include/configs/P1022DS.h @@ -352,7 +352,7 @@ (CONFIG_SYS_INIT_RAM_SIZE - GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_GBL_DATA_OFFSET -#define CONFIG_SYS_MONITOR_LEN (512 * 1024) +#define CONFIG_SYS_MONITOR_LEN (768 * 1024) #define CONFIG_SYS_MALLOC_LEN (10 * 1024 * 1024) /* diff --git a/include/configs/P1023RDB.h b/include/configs/P1023RDB.h index b41cb4a..b4d7023 100644 --- a/include/configs/P1023RDB.h +++ b/include/configs/P1023RDB.h @@ -125,7 +125,7 @@ extern unsigned long get_clock_freq(void); GENERATED_GBL_DATA_SIZE) #define CONFIG_SYS_INIT_SP_OFFSET CONFIG_SYS_GBL_DATA_OFFSET -#define CONFIG_SYS_MONITOR_LEN (512 * 1024) /* Reserve 512 kB for Mon */ +#define CONFIG_SYS_MONITOR_LEN (768 * 1024) /* Reserve 512 kB for Mon */ #define CONFIG_SYS_MALLOC_LEN (6 * 1024 * 1024) /* Reserved for malloc */ #define CON
[U-Boot] [PATCH] powerpc/mpc85xx:Add CONFIG_SYS_FSL_ERRATUM_ESDHC111 to Txx/Bxx
eSDHC host of T4x/B4x,T208x,T104x Soc has errata esdhc111. So add macro definition to enable its workaround. Signed-off-by: Haijun Zhang Signed-off-by: Prabhakar Kushwaha --- arch/powerpc/include/asm/config_mpc85xx.h |4 1 file changed, 4 insertions(+) diff --git a/arch/powerpc/include/asm/config_mpc85xx.h b/arch/powerpc/include/asm/config_mpc85xx.h index 9a20b97..fb73dce 100644 --- a/arch/powerpc/include/asm/config_mpc85xx.h +++ b/arch/powerpc/include/asm/config_mpc85xx.h @@ -641,6 +641,7 @@ #define CONFIG_SYS_FSL_ERRATUM_A006261 #define CONFIG_SYS_FSL_ERRATUM_A006379 #define CONFIG_SYS_FSL_ERRATUM_A006593 +#define CONFIG_SYS_FSL_ERRATUM_ESDHC111 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00 #define CONFIG_SYS_FSL_PCI_VER_3_X @@ -670,6 +671,7 @@ #define CONFIG_SYS_FSL_ERRATUM_A006593 #define CONFIG_SYS_FSL_ERRATUM_A006475 #define CONFIG_SYS_FSL_ERRATUM_A006384 +#define CONFIG_SYS_FSL_ERRATUM_ESDHC111 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00 #ifdef CONFIG_PPC_B4860 @@ -733,6 +735,7 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022) #define CONFIG_SYS_FSL_USB_DUAL_PHY_ENABLE #define CONFIG_SYS_FSL_USB_INTERNAL_UTMI_PHY #define CONFIG_SYS_FSL_ERRATUM_A006261 +#define CONFIG_SYS_FSL_ERRATUM_ESDHC111 #define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00 #elif defined(CONFIG_PPC_T2080) || defined(CONFIG_PPC_T2081) @@ -778,6 +781,7 @@ defined(CONFIG_PPC_T1020) || defined(CONFIG_PPC_T1022) #define CONFIG_SYS_CCSRBAR_DEFAULT 0xfe00 #define CONFIG_SYS_FSL_SFP_VER_3_0 #define CONFIG_SYS_FSL_ISBC_VER2 +#define CONFIG_SYS_FSL_ERRATUM_ESDHC111 #elif defined(CONFIG_PPC_C29X) #define CONFIG_MAX_CPUS1 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/2] powerpc/mpc85xx:Avoid fix address of bootpg section
It is not necessary for bootpg to be present at text + 512KB.
With increase of u-boot size (768KB), bootpg section's address
cannot be fixed.
Signed-off-by: Prabhakar Kushwaha
---
arch/powerpc/cpu/mpc85xx/u-boot-nand.lds |8 +++-
arch/powerpc/cpu/mpc85xx/u-boot.lds |6 +-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-nand.lds
b/arch/powerpc/cpu/mpc85xx/u-boot-nand.lds
index df3b0f9..d77a6dc 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-nand.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-nand.lds
@@ -4,6 +4,12 @@
* SPDX-License-Identifier:GPL-2.0+
*/
+#include "config.h"/* CONFIG_BOARDDIR */
+
+#ifndef CONFIG_SYS_MONITOR_LEN
+#define CONFIG_SYS_MONITOR_LEN 0x8
+#endif
+
OUTPUT_ARCH(powerpc)
/* Do we need any of these for elf?
__DYNAMIC = 0;*/
@@ -76,7 +82,7 @@ SECTIONS
KEEP(arch/powerpc/cpu/mpc85xx/start.o (.bootpg))
} :text = 0x
- . = ADDR(.text) + 0x8;
+ . = ADDR(.text) + CONFIG_SYS_MONITOR_LEN;
__bss_start = .;
.bss (NOLOAD) :
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot.lds
b/arch/powerpc/cpu/mpc85xx/u-boot.lds
index 2af4c80..99473dd 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot.lds
@@ -12,6 +12,10 @@
#define RESET_VECTOR_ADDRESS 0xfffc
#endif
+#ifndef CONFIG_SYS_MONITOR_LEN
+#define CONFIG_SYS_MONITOR_LEN 0x8
+#endif
+
OUTPUT_ARCH(powerpc)
PHDRS
@@ -84,7 +88,7 @@ SECTIONS
{
KEEP(arch/powerpc/cpu/mpc85xx/start.o (.bootpg))
} :text = 0x
- . = ADDR(.text) + 0x8;
+ . = ADDR(.text) + CONFIG_SYS_MONITOR_LEN;
#else
.bootpg RESET_VECTOR_ADDRESS - 0xffc :
{
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/4] arm: mx5: Fix memory slowness on MX53QSB
On Monday, March 31, 2014 at 11:47:14 AM, Stefano Babic wrote: > Hi Marek, > > On 31/03/2014 09:48, Marek Vasut wrote: > > Thanks :) > > > > There are a few more patches in your PW queue from me, please check them > > and apply as seen fit. Thanks again! > > All patches from you (or from others) that are ok for me and ready to be > merged are marked by me in PW as "under reviewed" - there is not a > "review passed " or "ready-to-be-merged" status. You can check yourself > if some of your patches are missing. Will do, but I think you got them all. Thanks! Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting
Hi Marek,
> On Monday, March 31, 2014 at 11:24:31 AM, Lukasz Majewski wrote:
> > Hi Marek,
> >
> > > On Monday, March 31, 2014 at 10:48:49 AM, Lukasz Majewski wrote:
> > > > Up till now the CRC32 of received data was calculated
> > > > unconditionally. The standard crc32 implementation causes long
> > > > delays when large images were uploaded.
> > >
> > > You might want to check common/cmd_hash.c and include/hash.h for
> > > the hash_command() call. It does the resolution of the hash
> > > algorithm from it's name and you can operate also SHA1 and SHA256
> > > with it. It would be nice if you could just extend it a bit and
> > > use that instead of adding another ad-hoc mechanism.
> > >
> > > Do you think it'd be possible to reuse it please ?
> >
> > I think, that crc32 shall be calculated when needed. That is why
> > I've added a dfu_ckecksum_method variable.
> >
> > With its help it is now possible to use different algorithms for
> > checking - not only crc32 (which in u-boot is the default and
> > painfully slow implementation).
> >
> > In the future the code:
> > if (dfu_checksum_method == DFU_CRC32)
> > crc32 calculation;
> >
> > will be changed to:
> >
> > switch (dfu_checksum_method) {
> > case CRC32:
> > crc32 calculation;
> > break;
> > case SHA1:
> > sha1 calculation;
> > break;
> > case MD5:
> > md5 calculation;
> > break;
> > }
> >
> > Moreover it is possible to dynamically change the checksum method
> > (between invoking dfu command) via adjusting "dfu_checksum_method"
> > variable.
> >
> > The default approach is to not calculate anything.
>
> I get it, but the direct calling of crc32() function can be
> abstracted already with the hash_command() now. You won't need to the
> above switch in such case. Also, you can implement a NULL hash algo,
> which would effectivelly model the case where you want to disable
> hashing.
I will look closer to the hash_command() - maybe it would be enough to
only call it with a proper parameter.
Thanks for tip.
>
> Best regards,
> Marek Vasut
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/4] arm: mx5: Fix memory slowness on MX53QSB
Hi Marek, On 31/03/2014 09:48, Marek Vasut wrote: > Thanks :) > > There are a few more patches in your PW queue from me, please check them and > apply as seen fit. Thanks again! All patches from you (or from others) that are ok for me and ready to be merged are marked by me in PW as "under reviewed" - there is not a "review passed " or "ready-to-be-merged" status. You can check yourself if some of your patches are missing. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting
On Monday, March 31, 2014 at 11:24:31 AM, Lukasz Majewski wrote:
> Hi Marek,
>
> > On Monday, March 31, 2014 at 10:48:49 AM, Lukasz Majewski wrote:
> > > Up till now the CRC32 of received data was calculated
> > > unconditionally. The standard crc32 implementation causes long
> > > delays when large images were uploaded.
> >
> > You might want to check common/cmd_hash.c and include/hash.h for the
> > hash_command() call. It does the resolution of the hash algorithm
> > from it's name and you can operate also SHA1 and SHA256 with it. It
> > would be nice if you could just extend it a bit and use that instead
> > of adding another ad-hoc mechanism.
> >
> > Do you think it'd be possible to reuse it please ?
>
> I think, that crc32 shall be calculated when needed. That is why I've
> added a dfu_ckecksum_method variable.
>
> With its help it is now possible to use different algorithms for
> checking - not only crc32 (which in u-boot is the default and painfully
> slow implementation).
>
> In the future the code:
> if (dfu_checksum_method == DFU_CRC32)
> crc32 calculation;
>
> will be changed to:
>
> switch (dfu_checksum_method) {
> case CRC32:
> crc32 calculation;
> break;
> case SHA1:
> sha1 calculation;
> break;
> case MD5:
> md5 calculation;
> break;
> }
>
> Moreover it is possible to dynamically change the checksum method
> (between invoking dfu command) via adjusting "dfu_checksum_method"
> variable.
>
> The default approach is to not calculate anything.
I get it, but the direct calling of crc32() function can be abstracted already
with the hash_command() now. You won't need to the above switch in such case.
Also, you can implement a NULL hash algo, which would effectivelly model the
case where you want to disable hashing.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] dfu: Introduction of the "dfu_checksum_method" env variable for checksum method setting
Hi Marek,
> On Monday, March 31, 2014 at 10:48:49 AM, Lukasz Majewski wrote:
> > Up till now the CRC32 of received data was calculated
> > unconditionally. The standard crc32 implementation causes long
> > delays when large images were uploaded.
>
> You might want to check common/cmd_hash.c and include/hash.h for the
> hash_command() call. It does the resolution of the hash algorithm
> from it's name and you can operate also SHA1 and SHA256 with it. It
> would be nice if you could just extend it a bit and use that instead
> of adding another ad-hoc mechanism.
>
> Do you think it'd be possible to reuse it please ?
I think, that crc32 shall be calculated when needed. That is why I've
added a dfu_ckecksum_method variable.
With its help it is now possible to use different algorithms for
checking - not only crc32 (which in u-boot is the default and painfully
slow implementation).
In the future the code:
if (dfu_checksum_method == DFU_CRC32)
crc32 calculation;
will be changed to:
switch (dfu_checksum_method) {
case CRC32:
crc32 calculation;
break;
case SHA1:
sha1 calculation;
break;
case MD5:
md5 calculation;
break;
}
Moreover it is possible to dynamically change the checksum method
(between invoking dfu command) via adjusting "dfu_checksum_method"
variable.
The default approach is to not calculate anything.
>
> Best regards,
> Marek Vasut
--
Best regards,
Lukasz Majewski
Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
