Re: [U-Boot] [PATCH V2 2/2] eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command
Hello Wolfgang, Le 17/04/2014 21:56, Wolfgang Denk a écrit : Dear Pierre Aubert, In message <1397747435-24042-3-git-send-email-p.aub...@staubli.com> you wrote: This sub-command adds support for the RPMB partition of an eMMC: * mmc rpmb key Programs the authentication key in the eMMC This key can not be overwritten. * mmc rpmb read <#count> [address of key] Reads <#count> blocks of 256 bytes in the RPMB partition beginning at block number . If the optionnal address of the authentication key is provided, the Message Authentication Code (MAC) is verified on each block. * mmc rpmb write <#count> Writes <#count> blocks of 256 bytes in the RPMB partition beginning at block number . The datas are signed with the key provided. * mmc rpmb counter Returns the 'Write counter' of the RPMB partition. The sub-command is conditional on compilation flag CONFIG_SUPPORT_EMMC_RPMB Such new options must be documented in the README. I will add it in a V3 Signed-off-by: Pierre Aubert CC: Pantelis Antoniou --- common/cmd_mmc.c | 128 +- 1 files changed, 127 insertions(+), 1 deletions(-) diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c index c1916c9..3cf11e7 100644 --- a/common/cmd_mmc.c +++ b/common/cmd_mmc.c @@ -130,7 +130,123 @@ U_BOOT_CMD( "display MMC info", "- display info of the current MMC device" ); +#ifdef CONFIG_SUPPORT_EMMC_RPMB +static int confirm_key_prog(void) +{ + puts("Warning: Programming authentication key can be done only once !\n" +" Use this command only if you are sure of what you are doing,\n" +"Really perform the key programming ? "); + if (getc() == 'y') { Would it not makes sense to flush the input before reading the char, so that you don;t react on any type-ahead that might already be buffered? + int c; + + putc('y'); + c = getc(); + putc('\n'); + if (c == '\r') + return 1; + } Should we allow for 'Y"? And for "yes" / "Yes"? We have getenv_yesno() - maybe we should provide a similar function that can be used in other places where such interactive confirmation is needed? I have found such a confirmation in cmd_fuse, cmd_otp and cmd_mmc. It makes sense to provide a global function. I will try to submit a patch for that. + if (state != RPMB_INVALID) { Change this into if (state == RPMB_INVALID) return CMD_RET_USAGE; and avoid one level of indentation; this will make the code much easier to read. + if (IS_SD(mmc)) { Is IS_SD() a reliable test for eMMC devics, or would that also return true in other cases? You're right, the test must be more restrictive. The RPMB partition is available only since the release 4.41 of the Jedec standard. I will fix it in a V3. + if (confirm_key_prog()) { + if (mmc_rpmb_set_key(mmc, key_addr)) { + printf("ERROR - Key already programmed ?\n"); + ret = CMD_RET_FAILURE; + } + } else { + ret = CMD_RET_FAILURE; + } You should really avoid deep nesting and take early exits. You can write this as: if (!confirm_key_prog()) return CMD_RET_FAILURE; if (mmc_rpmb_set_key(mmc, key_addr)) { printf("ERROR - Key already programmed ?\n"); ret = CMD_RET_FAILURE; } Please fix globally. No problem, it will be fixed globally in V3 + } else if (state == RPMB_COUNTER) { + unsigned long counter; + if (mmc_rpmb_get_counter(mmc, &counter)) Please insert a blank line between declarations and code. Ok + printf("%d RPMB blocks %s: %s\n", + n, argv[2], (n == cnt) ? "OK" : "ERROR"); As the input is in hex, it is usually also a good idea to (also) print the count in hex. For coherency with the mmc read and mmc write, I kept the same output. But it can be changed, of course. #endif /* CONFIG_SUPPORT_EMMC_BOOT */ +#ifdef CONFIG_SUPPORT_EMMC_RPMB + } else if (strcmp(argv[1], "rpmb") == 0) { + return do_mmcrpmb(argc, argv); +#endif /* CONFIG_SUPPORT_EMMC_RPMB */ I think that now, with more subcommands being added, we should convert the mmc code to proper subcommand handling. [It might even make sense to do so for "mmc rpmb", too.] Do you think about the use of the macro U_BOOT_CMD_MKENT ? Best regards, Wolfgang Denk Best regards Pierre Aubert ___ U-Boot mailing list U-Boot@lists.denx.de http://l
[U-Boot] How to test vlan in u-boot
Hi , I am using an 8 port switch (MV88E6131) in our customized board with P2020 Processor. Following is the set up in our board, Port 6 -> CPU port Port0 / Port1 / Port2 connected to phy Port3 -> No connection Port 4 / Port 5 connected to DSP's Port 7 routed to back plane , SGMII connection. I tried grouping port0,port1,port2 as one LAN-A and Port 4,5,7 as LANB. Such that both LAN A and B cannot communicate with each other , but both can send frame to CPU PORT. After this i got stuck and dono how to proceed further and test it. Please guide me in this to solve. -- View this message in context: http://u-boot.10912.n7.nabble.com/How-to-test-vlan-in-u-boot-tp178161.html Sent from the U-Boot mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] MX6: add struct for sharing data between SPL and uboot
On Thu, Apr 17, 2014 at 4:44 AM, Stefano Babic wrote: > Hi Igor, hi Tim > > On 17/04/2014 13:22, Igor Grinberg wrote: > >> >> get_ram_size() works on cm-fx6 all DRAM configurations. > > As on most boards in mainline ;-) > It looks like I mis-interpreted the failure. This issue is that get_ram_size() only works with powers of 2 and maxes out at 2GB due to 32bit addressing. I was simply passing in a bogus value. I'm not sure how you would deal with detecting systems with 4GB but I don't need to support that for my boards currently. >> >>> > SPL is thought to generally load an image (of course, in most cases it > is u-boot). In Falcon mode, the kernel is started without running > u-boot, making this structure useless. Do we really need such a way (but > then, it must be generalized as SPL API), or can we get rid of it ? As we have an EEPROM on the board that tells us the physical ram size, I use that to avoid the lockup. >>> >>> It seems weird. There is several boards in mainline (I am sure about >>> Freescale's PowerPC) discovering the mounted RAM. Of course, this is >>> simpler if many parameters (row/columns/...) are the same, I am not sure >>> about this. >> >> Even if the parameters are different, this should not result in lockup... >> AFAICS, lockup of that type has nothing to do with the DRAM itself, but >> the controller configuration. > > Exactly, this is what I meant. Thanks for clarifying it better. > >> >>> Are we sure it is not possible here ? What does it happen >>> with an inconsistent value in EEprom ? >>> Eventually I would like to read and validate the entire EEPROM once in SPL and pass this to u-boot.img to avoid reading and validating it again. I think this is a good example of why sharing data between SPL and u-boot.img could be useful. >>> >>> I am not sure, and I doubt it is a good idea to use persistent data to >>> store that. It is potentially dangerous, and if some reasons the EEprom >>> is changed, the board could not boot at all. >> >> This is more a question of design and definition of what purpose the eeprom >> should serve, so I would let the vendor decide if he wants to depend on >> eeprom >> or not. > > Agree. Parsing and evaluating vendor specific information can be done > inside board specific part, as now in read_eeprom inside gw_ventana.c. > > Anyway, if there is a way to detect at runtime the hardware > configuration, it remains a better way as to store the size into the Eeprom. I agree and I definitely see the merits of completely de-coupling the SPL from u-boot.img so I will resort to reading the EEPROM in both places. Regards, Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 v2] usb: r8a66597: Fix initialization hub that using R8A66597_MAX_ROOT_HUB
This driver is processed as two USB hub despite one. The number of root hub is defined in R8A66597_MAX_ROOT_HUB. This fixes that register is accessed by using the definition of R8A66597_MAX_ROOT_HUB. Signed-off-by: Yasuhisa Umano --- v2 : No changes drivers/usb/host/r8a66597-hcd.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index dfe5423..c58d2a9 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -164,8 +164,8 @@ static int enable_controller(struct r8a66597 *r8a66597) r8a66597_bset(r8a66597, INTL, SOFCFG); r8a66597_write(r8a66597, 0, INTENB0); - r8a66597_write(r8a66597, 0, INTENB1); - r8a66597_write(r8a66597, 0, INTENB2); + for (port = 0; port < R8A66597_MAX_ROOT_HUB; port++) + r8a66597_write(r8a66597, 0, get_intenb_reg(port)); r8a66597_bset(r8a66597, CONFIG_R8A66597_ENDIAN & BIGEND, CFIFOSEL); r8a66597_bset(r8a66597, CONFIG_R8A66597_ENDIAN & BIGEND, D0FIFOSEL); -- 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 v2] usb: r8a66597: Fix initilization size of r8a66597 info structure
Initialization of r8a66597 info structure is not enough. Because initilization was used size of pointer. This fixes that use size of r8a6659 info structure. Signed-off-by: Yasuhisa Umano --- v2 : Change from sizeof(struct r8a66597) to sizeof(*r8a66597) drivers/usb/host/r8a66597-hcd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index c58d2a9..5114544 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -807,7 +807,7 @@ int usb_lowlevel_init(int index, enum usb_init_type init, void **controller) R8A66597_DPRINT("%s\n", __func__); - memset(r8a66597, 0, sizeof(r8a66597)); + memset(r8a66597, 0, sizeof(*r8a66597)); r8a66597->reg = CONFIG_R8A66597_BASE_ADDR; disable_controller(r8a66597); -- 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 2/2] usb: r8a66597: Fix initilization size of r8a66597 info, structure
Hi, Thanks for your comment. (2014/04/17 23:09), Marek Vasut wrote: On Thursday, April 17, 2014 at 10:20:29 AM, yasuhisa umano wrote: Initialization of r8a66597 info structure is not enough. Because initilization was used size of pointer. This fixes that use size of r8a6659 info structure. Signed-off-by: Yasuhisa Umano --- drivers/usb/host/r8a66597-hcd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index c58d2a9..8e82212 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -807,7 +807,7 @@ int usb_lowlevel_init(int index, enum usb_init_type init, void **controller) R8A66597_DPRINT("%s\n", __func__); - memset(r8a66597, 0, sizeof(r8a66597)); + memset(r8a66597, 0, sizeof(struct r8a66597)); Let's use sizeof(*r8a66597) instead . This is more scalable as you won't need to adjust this code when you change the data type of the *r8a66597 pointer, I will adjust that and apply with sizeof(*r8a66597); , does that work for you? Indeed. I will check your point and resend updated patch. Best regards, Marek Vasut Best regards, Yasuhisa ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] usb: r8a66597: Fix initialization hub that using, R8A66597_MAX_ROOT_HUB
Hi Sorry. I failed to send patchs to ML by setting of MUA. Best regards, Yasuhisa (2014/04/17 19:47), Marek Vasut wrote: On Thursday, April 17, 2014 at 09:48:32 AM, yasuhisa umano wrote: This driver is processed as two USB hub despite one. The number of root hub is defined in R8A66597_MAX_ROOT_HUB. This fixes that register is accessed by using the definition of R8A66597_MAX_ROOT_HUB. Signed-off-by: Yasuhisa Umano Is there any reason why those two patches were sent twice please ? They seem the same in both cases. Otherwise, I'm fine with those patches. 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/2] usb: r8a66597: Fix initialization hub that using, R8A66597_MAX_ROOT_HUB
Hi, Thanks for your comment. (2014/04/17 23:07), Marek Vasut wrote: On Thursday, April 17, 2014 at 09:48:32 AM, yasuhisa umano wrote: This driver is processed as two USB hub despite one. The number of root hub is defined in R8A66597_MAX_ROOT_HUB. This fixes that register is accessed by using the definition of R8A66597_MAX_ROOT_HUB. Signed-off-by: Yasuhisa Umano --- drivers/usb/host/r8a66597-hcd.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index dfe5423..c58d2a9 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -164,8 +164,8 @@ static int enable_controller(struct r8a66597 *r8a66597) r8a66597_bset(r8a66597, INTL, SOFCFG); r8a66597_write(r8a66597, 0, INTENB0); - r8a66597_write(r8a66597, 0, INTENB1); - r8a66597_write(r8a66597, 0, INTENB2); + for (port = 0; port < R8A66597_MAX_ROOT_HUB; port++) + r8a66597_write(r8a66597, 0, get_intenb_reg(port)); Hmm, looking at get_intenb_reg(), this is slightly dangerous, but I will trust you you know what you are doing . I am a bit worried someone might set R8A66597_MAX_ROOT_HUB to value >2 and will wonder why doesn't it work. I understood your point. Certainly, current device drivers support only the initialization of 1 or 2 interrupt for hub. If this driver has a hub of more future, I will send the patch. Anyway, I will apply this and if you feel my rant is valid, submit subsequent patch. Thank you. Best regards, Marek Vasut Best regards, Yasuhisa ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am43xx_evm: Drop SPI SPL
QSPI booting on this board does not use SPL, so drop SPI-SPL related options. Signed-off-by: Tom Rini --- include/configs/am43xx_evm.h |8 1 file changed, 8 deletions(-) diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h index 4e56ffc..d5e6c4b 100644 --- a/include/configs/am43xx_evm.h +++ b/include/configs/am43xx_evm.h @@ -98,14 +98,6 @@ #define CONFIG_SF_DEFAULT_SPEED4800 #define CONFIG_DEFAULT_SPI_MODESPI_MODE_3 -/* SPI SPL */ -#define CONFIG_SPL_SPI_SUPPORT -#define CONFIG_SPL_SPI_LOAD -#define CONFIG_SPL_SPI_FLASH_SUPPORT -#define CONFIG_SPL_SPI_BUS 0 -#define CONFIG_SPL_SPI_CS 0 -#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x2 - /* Enhance our eMMC support / experience. */ #define CONFIG_CMD_GPT #define CONFIG_EFI_PARTITION -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am335x_evm: Drop SPI SPL support from the default build
This is only useful with the _spiboot build target anyhow, so only include it then. Drop CONFIG_SPL_OS_BOOT support then as the flash is small and didn't include a spot for the device tree already. Signed-off-by: Tom Rini --- include/configs/am335x_evm.h | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index ebe2ab3..036c609 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -213,14 +213,6 @@ #define CONFIG_SPL_ENV_SUPPORT #define CONFIG_SPL_NET_VCI_STRING "AM335x U-Boot SPL" -/* SPI flash. */ -#define CONFIG_SPL_SPI_SUPPORT -#define CONFIG_SPL_SPI_FLASH_SUPPORT -#define CONFIG_SPL_SPI_LOAD -#define CONFIG_SPL_SPI_BUS 0 -#define CONFIG_SPL_SPI_CS 0 -#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x2 - #define CONFIG_SPL_LDSCRIPT"$(CPUDIR)/am33xx/u-boot-spl.lds" #ifdef CONFIG_NAND @@ -362,6 +354,15 @@ * 0x442000 - 0x80 : Userland */ #if defined(CONFIG_SPI_BOOT) +/* SPL related */ +#undef CONFIG_SPL_OS_BOOT /* Not supported by existing map */ +#define CONFIG_SPL_SPI_SUPPORT +#define CONFIG_SPL_SPI_FLASH_SUPPORT +#define CONFIG_SPL_SPI_LOAD +#define CONFIG_SPL_SPI_BUS 0 +#define CONFIG_SPL_SPI_CS 0 +#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x2 + #define CONFIG_ENV_IS_IN_SPI_FLASH #define CONFIG_SYS_REDUNDAND_ENVIRONMENT #define CONFIG_ENV_SPI_MAX_HZ CONFIG_SF_DEFAULT_SPEED @@ -437,7 +438,6 @@ #define CONFIG_SYS_FLASH_CFI_WIDTH FLASH_CFI_16BIT #define CONFIG_SYS_MONITOR_BASECONFIG_SYS_FLASH_BASE /* Reduce SPL size by removing unlikey targets */ -#undef CONFIG_SPL_SPI_SUPPORT #ifdef CONFIG_NOR_BOOT #define CONFIG_ENV_IS_IN_FLASH #define CONFIG_ENV_SECT_SIZE (128 << 10) /* 128 KiB */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] env_flash.c: Drop unused variables
With 7ce1526 we no longer need 'len' or 'res', so drop these variables. Signed-off-by: Tom Rini --- common/env_flash.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/common/env_flash.c b/common/env_flash.c index b3ad908..004e884 100644 --- a/common/env_flash.c +++ b/common/env_flash.c @@ -224,9 +224,8 @@ int env_init(void) int saveenv(void) { env_t env_new; - ssize_t len; int rc = 1; - char*res, *saved_data = NULL; + char*saved_data = NULL; #if CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE ulong up_data = 0; -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] support for maxim dallas rtcds1347
I am writing the support for rtc ds1347 my driver file resides in drivers/rtc/ds1347.c who is the custodian for the rtc subsystem of uboot or just i have to mail patch to u-boot@lists.denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Fwd: [PATCH v3 00/13] ARMv7: add PSCI support to u-boot
[ Drat. I meant to send this to the U-Boot list, not just Albert. --jdl] -- Forwarded message -- From: Jon Loeliger Date: Thu, Apr 17, 2014 at 11:36 AM Subject: Re: [U-Boot] [PATCH v3 00/13] ARMv7: add PSCI support to u-boot To: Albert ARIBAUD On Thu, Apr 17, 2014 at 3:34 AM, Albert ARIBAUD wrote: > Hi Marc, > > So yes, I am willing to review them -- and I suspect others are, as > well. Nobody commented the V3 series on the U-Boot list -- save for > Jon's comment about the series needing a rebase -- which could mean no > one here is unhappy with them... So, not *unhappy* with them, but definitely some review is needed. Also, there are aspects of the implementation that will need to be generalized a bit. For example, the sunxi code uses a magic register in its implementation that allows a core to come out of reset at a known (ie, given) non-0 address. My A9 core has CPUs coming out of reset at a fixed address of 0. That means my "secure text" must be at 0, and it must have a "secure vector" with a "secure reset" laid down at 0. Ultimately, this means that a small modification (adding a secure vector text section) to the LDS file will be needed to ensure that it is placed at 0 within the secure text section itself. No, I don't have all this working quite yet. :-) jdl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MAKEALL: remove hard-coded MIPS boards
iDo not initialize list_MIPS with hard-coded board names. Use targets_by_arch() instead. Signed-off-by: Daniel Schwierzeck --- MAKEALL | 40 +--- 1 file changed, 1 insertion(+), 39 deletions(-) diff --git a/MAKEALL b/MAKEALL index c54240c..020e65f 100755 --- a/MAKEALL +++ b/MAKEALL @@ -418,47 +418,9 @@ LIST_arm="$(targets_by_arch arm | \ ## MIPS Systems(default = big endian) # -LIST_mips4kc=" \ - qemu_mips \ - vct_platinum\ - vct_platinum_small \ - vct_platinum_onenand\ - vct_platinum_onenand_small \ - vct_platinumavc \ - vct_platinumavc_small \ - vct_platinumavc_onenand \ - vct_platinumavc_onenand_small \ - vct_premium \ - vct_premium_small \ - vct_premium_onenand \ - vct_premium_onenand_small \ -" - -LIST_au1xx0=" \ - dbau1000\ - dbau1100\ - dbau1500\ - dbau1550\ -" - -LIST_mips="\ - ${LIST_mips4kc} \ - ${LIST_mips5kc} \ - ${LIST_au1xx0} \ -" +LIST_mips="$(targets_by_arch mips)" # -## MIPS Systems(little endian) -# - -LIST_au1xx0_el=" \ - dbau1550_el \ - pb1000 \ -" -LIST_mips_el=" \ - ${LIST_au1xx0_el} \ -" -# ## OpenRISC Systems # -- 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 V2 2/2] eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command
Dear Pierre Aubert, In message <1397747435-24042-3-git-send-email-p.aub...@staubli.com> you wrote: > This sub-command adds support for the RPMB partition of an eMMC: > * mmc rpmb key > Programs the authentication key in the eMMC This key can not > be overwritten. > * mmc rpmb read <#count> [address of key] > Reads <#count> blocks of 256 bytes in the RPMB partition > beginning at block number . If the optionnal > address of the authentication key is provided, the > Message Authentication Code (MAC) is verified on each > block. > * mmc rpmb write <#count> > Writes <#count> blocks of 256 bytes in the RPMB partition > beginning at block number . The datas are signed > with the key provided. > * mmc rpmb counter > Returns the 'Write counter' of the RPMB partition. > > The sub-command is conditional on compilation flag CONFIG_SUPPORT_EMMC_RPMB Such new options must be documented in the README. > Signed-off-by: Pierre Aubert > CC: Pantelis Antoniou > --- > common/cmd_mmc.c | 128 > +- > 1 files changed, 127 insertions(+), 1 deletions(-) > > diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c > index c1916c9..3cf11e7 100644 > --- a/common/cmd_mmc.c > +++ b/common/cmd_mmc.c > @@ -130,7 +130,123 @@ U_BOOT_CMD( > "display MMC info", > "- display info of the current MMC device" > ); > +#ifdef CONFIG_SUPPORT_EMMC_RPMB > +static int confirm_key_prog(void) > +{ > + puts("Warning: Programming authentication key can be done only once !\n" > + " Use this command only if you are sure of what you are > doing,\n" > + "Really perform the key programming ? "); > + if (getc() == 'y') { Would it not makes sense to flush the input before reading the char, so that you don;t react on any type-ahead that might already be buffered? > + int c; > + > + putc('y'); > + c = getc(); > + putc('\n'); > + if (c == '\r') > + return 1; > + } Should we allow for 'Y"? And for "yes" / "Yes"? We have getenv_yesno() - maybe we should provide a similar function that can be used in other places where such interactive confirmation is needed? > + if (state != RPMB_INVALID) { Change this into if (state == RPMB_INVALID) return CMD_RET_USAGE; and avoid one level of indentation; this will make the code much easier to read. > + if (IS_SD(mmc)) { Is IS_SD() a reliable test for eMMC devics, or would that also return true in other cases? > + if (confirm_key_prog()) { > + if (mmc_rpmb_set_key(mmc, key_addr)) { > + printf("ERROR - Key already programmed > ?\n"); > + ret = CMD_RET_FAILURE; > + } > + } else { > + ret = CMD_RET_FAILURE; > + } You should really avoid deep nesting and take early exits. You can write this as: if (!confirm_key_prog()) return CMD_RET_FAILURE; if (mmc_rpmb_set_key(mmc, key_addr)) { printf("ERROR - Key already programmed ?\n"); ret = CMD_RET_FAILURE; } Please fix globally. > + } else if (state == RPMB_COUNTER) { > + unsigned long counter; > + if (mmc_rpmb_get_counter(mmc, &counter)) Please insert a blank line between declarations and code. > + printf("%d RPMB blocks %s: %s\n", > +n, argv[2], (n == cnt) ? "OK" : "ERROR"); As the input is in hex, it is usually also a good idea to (also) print the count in hex. > #endif /* CONFIG_SUPPORT_EMMC_BOOT */ > +#ifdef CONFIG_SUPPORT_EMMC_RPMB > + } else if (strcmp(argv[1], "rpmb") == 0) { > + return do_mmcrpmb(argc, argv); > +#endif /* CONFIG_SUPPORT_EMMC_RPMB */ I think that now, with more subcommands being added, we should convert the mmc code to proper subcommand handling. [It might even make sense to do so for "mmc rpmb", too.] 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 "The computer programmer is a creator of universes for which he alone is responsible. Universes of virtually unlimited complexity can be created in the form of computer programs." - Joseph Weizenbaum, _Computer Power and Human Reason_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/13] ARMv7: add PSCI support to u-boot
> No, so far there hasn't been much discussion, and people seem happy with > it. I have a couple of fixes lined up, but nothing major. So, I think PSCI 0.2 calls for function numbers in the 0x8400 range. Seems like we'll have to fix this in one of your patches: /* PSCI interface */ #define ARM_PSCI_FN_BASE0x95c1ba5e to be: #define ARM_PSCI_FN_BASE0x8400 Just thought I'd toss that out there, you know, if you were collecting fixes for a repost of your patches... :-) jdl On Thu, Apr 17, 2014 at 3:58 AM, Marc Zyngier wrote: > On Thu, Apr 17 2014 at 9:34:24 am BST, Albert ARIBAUD > wrote: >> Hi Marc, >> >> On Wed, 16 Apr 2014 17:09:07 +0100, Marc Zyngier >> wrote: >> >>> On 16/04/14 15:45, Albert ARIBAUD wrote: >>> > Hi Marc, >>> > >>> > On Sat, 15 Feb 2014 13:36:24 +, Marc Zyngier >>> > wrote: >>> > >>> >> PSCI is an ARM standard that provides a generic interface that >>> >> supervisory software can use to manage power in the following >>> >> situations: >>> >> - Core idle management >>> >> - CPU hotplug >>> >> - big.LITTLE migration models >>> >> - System shutdown and reset >>> >> >>> >> It basically allows the kernel to offload these tasks to the firmware, >>> >> and rely on common kernel side code. >>> >> >>> >> More importantly, it gives a way to ensure that CPUs enter the kernel >>> >> at the appropriate exception level (ie HYP mode, to allow the use of >>> >> the virtualization extensions), even across events like CPUs being >>> >> powered off/on or suspended. >>> >> >>> >> The main idea here is to turn some of the existing u-boot code into a >>> >> separate section that can live in secure RAM (or a reserved page of >>> >> memory), containing a secure monitor that will implement the PSCI >>> >> operations. This code will still be alive when u-boot is long gone, >>> >> hence the need for a piece of memory that will not be touched by the >>> >> OS. >>> >> >>> >> This patch series contains 4 parts: >>> >> - the first four patches are just bug fixes >>> >> - the next two refactor the HYP/non-secure code to allow relocation >>> >> in secure memory >>> >> - the next four contain the generic PSCI code and DT infrastructure >>> >> - the last three implement the CPU_ON method of the Allwinner A20 (aka >>> >> sun7i). >>> >> >>> >> I realize the A20 u-boot code is not upstream yet (BTW is anyone >>> >> actively working on that?), but hopefully that should give a good idea >>> >> of how things are structured so far. The patches are against the >>> >> mainline u-boot tree as of today, merged with the sunxi u-boot tree >>> >> of the day and the first 10 patches will directly apply to mainline >>> >> u-boot. >>> >> >>> >> As for using this code, it goes like this: >>> >> sun7i# ext2load mmc 0:1 0x40008000 zImage ; ext2load mmc 0:1 0x6000 >>> >> sun7i-a20-cubietruck.dtb >>> >> 2270120 bytes read in 117 ms (18.5 MiB/s) >>> >> 9138 bytes read in 3 ms (2.9 MiB/s) >>> >> sun7i# fdt addr 0x6000 ; fdt resize ; fdt set ethernet0 mac-address >>> >> "[5a fe b0 07 b0 07]" >>> >> sun7i# setenv bootargs console=ttyS0,115200 earlyprintk ip=dhcp >>> >> root=/dev/nfs nfsroot=/backup/a20_root,tcp >>> >> sun7i# bootz 0x40008000 - 0x6000 >>> >> >>> >> The kernel now boots in HYP mode, finds its secondary CPU without any >>> >> SMP code present in the kernel, and runs KVM out of the box. >>> >> I've been told the Xen/ARM guys managed to do the same fairly easily. >>> >> >>> >> This code has also been tested on a VExpress TC2, running KVM with all >>> >> 5 CPUs, in order to make sure there was no obvious regression. >>> >> >>> >> I'm wildly cross-posting this patch series, including to lists I'm not >>> >> subscribed to. Please keep me on Cc for any comment you may have. >>> >> >>> >> The code is also available at: >>> >> git://git.kernel.org/pub/scm/linux/kernel/git/maz/u-boot.git wip/psci >>> >> >>> >> Cheers, >>> >> >>> >> M. >>> > >>> > Marc, I'm unclear what you want to do with this series. You mention >>> > that its first 10 patches will apply to U-Boot, but I am not sure >>> > whether you are just indicating that it is possible to apply them or >>> > asking for these 10 patches to go in U-Boot mainline. Or is it >>> > something else yet? >>> >>> Well, I rarely write code just for the sake of forking a critical >>> project ;-) >>> >>> So let's be 100% explicit: Yes, I'm hereby asking for these patches to >>> be merged. They offer a service that is required by the Linux kernel as >>> well as Xen. They are in active use on the Allwinner sun7i platform as >>> well as Versatile Express (though the later doesn't have a PSCI >>> implementation). >>> >>> Now, given that two months have gone past without much comment other >>> than the odd "hey, works great", I don't really know where to take that. >>> >>> Are you willing to review the patches? >> >> Well, I rarely ask about patches just for the sake of conversation. O:-) >> >> So yes, I am willi
Re: [U-Boot] [PATCH 0/3] pcnet driver fixes
Hi Tom, 2014-04-07 17:41 GMT+02:00 Paul Burton : > This series fixes issues with the pcnet driver & its memory accesses. > > Previously the network interface on the MIPS Malta board was unreliable > & would often time out whilst transferring files via TFTP, but with this > series applied it is now stable. > > Paul Burton (3): > pcnet: access descriptor rings & init block uncached > pcnet: align rx buffers for cache invalidation > pcnet: force ordering of descriptor accesses > In patchwork someone assigned all patches in this series to you. Is that intentional or shall I pick them up for MIPS tree? -- - Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] buildman: make output dir configurable
On 17 April 2014 13:13, Daniel Schwierzeck wrote: > Add an option to specify the output directory to override the > default path '../'. This is useful for building in a ramdisk. > > Signed-off-by: Daniel Schwierzeck > Cc: Simon Glass Thanks. Acked-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] buildman: make output dir configurable
Add an option to specify the output directory to override the default path '../'. This is useful for building in a ramdisk. Signed-off-by: Daniel Schwierzeck Cc: Simon Glass --- Changes for v2: - improved help message --- tools/buildman/buildman.py | 3 +++ tools/buildman/control.py | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/buildman/buildman.py b/tools/buildman/buildman.py index 8822efe..73a5483 100755 --- a/tools/buildman/buildman.py +++ b/tools/buildman/buildman.py @@ -101,6 +101,9 @@ parser.add_option('-T', '--threads', type='int', default=None, help='Number of builder threads to use') parser.add_option('-u', '--show_unknown', action='store_true', default=False, help='Show boards with unknown build result') +parser.add_option('-o', '--output-dir', type='string', + dest='output_dir', default='..', + help='Directory where all builds happen and buildman has its workspace (default is ../)') parser.usage = """buildman -b [options] diff --git a/tools/buildman/control.py b/tools/buildman/control.py index 8e6a08f..d2f4102 100644 --- a/tools/buildman/control.py +++ b/tools/buildman/control.py @@ -145,7 +145,7 @@ def DoBuildman(options, args): options.step = len(series.commits) - 1 # Create a new builder with the selected options -output_dir = os.path.join('..', options.branch) +output_dir = os.path.join(options.output_dir, options.branch) builder = Builder(toolchains, output_dir, options.git_dir, options.threads, options.jobs, checkout=True, show_unknown=options.show_unknown, step=options.step) -- 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 0/5] Do not use __DATE__ and __TIME__ anymore
On Thu 17 Apr 2014 17:00:27 Masahiro Yamada wrote: > The aim of this series is to prohibit using __DATE__ and __TIME__. as long as the version.h isn't impacted, this should fine. i don't think it is as it looks like the build will generate U_BOOT_DATE and U_BOOT_TIME into a const string by hand. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] blackfin: replace bfin_gen_rand_mac() with eth_random_addr()
On Thu 17 Apr 2014 17:00:30 Masahiro Yamada wrote: > --- a/include/configs/tcm-bf537.h > +++ b/include/configs/tcm-bf537.h > @@ -73,7 +73,7 @@ > #define CONFIG_HOSTNAME tcm-bf537 > /* Uncomment next line to use fixed MAC address */ > /* #define CONFIG_ETHADDR02:80:ad:20:31:e8 */ > - > +#define CONFIG_LIB_RAND this should be in bfin_adi_common.h instead. i think that replaces the majority of your config updates (if not all). -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] patman: Don't request full names from get_maintainer
The Linux get_maintainer.pl can often produce a whole lot of results. As a result you'll sometimes blow your CC field over 1024 characters and that can cause listservs to reject your message. As a stopgap, call get_maintainer.pl with "--non" so it doesn't include real names. This will dramatically reduce the number of characters. Signed-off-by: Doug Anderson --- tools/patman/get_maintainer.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/patman/get_maintainer.py b/tools/patman/get_maintainer.py index 00b4939..a5160bc 100644 --- a/tools/patman/get_maintainer.py +++ b/tools/patman/get_maintainer.py @@ -43,5 +43,5 @@ def GetMaintainer(fname, verbose=False): print "WARNING: Couldn't find get_maintainer.pl" return [] -stdout = command.Output(get_maintainer, '--norolestats', fname) +stdout = command.Output(get_maintainer, '--norolestats', '--non', fname) return stdout.splitlines() -- 1.9.1.423.g4596e3a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Updating master with next
I've now merged next into master and pushed, along with re-applying the change that makes non-COFNIG_SYS_GENERIC_BOARD boards complain at run-time. I'm going to be grabbing some other patches shortly, of the type that easily conflict and I don't want to have to have them be rebased again. -- 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] am33xx: add SSC enable macro
On Thu, Apr 10, 2014 at 11:35:25AM +0200, yegorsli...@googlemail.com wrote: > From: Yegor Yefremov > > Signed-off-by: Yegor Yefremov > --- > arch/arm/include/asm/arch-am33xx/clock.h |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/include/asm/arch-am33xx/clock.h > b/arch/arm/include/asm/arch-am33xx/clock.h > index 7637457..f00fad3 100644 > --- a/arch/arm/include/asm/arch-am33xx/clock.h > +++ b/arch/arm/include/asm/arch-am33xx/clock.h > @@ -42,6 +42,8 @@ > #define MODULE_CLKCTRL_IDLEST_DISABLED 3 > > /* CM_CLKMODE_DPLL */ > +#define CM_CLKMODE_DPLL_SSC_EN_SHIFT 12 > +#define CM_CLKMODE_DPLL_SSC_EN_MASK (1 << 12) > #define CM_CLKMODE_DPLL_REGM4XEN_SHIFT 11 > #define CM_CLKMODE_DPLL_REGM4XEN_MASK(1 << 11) > #define CM_CLKMODE_DPLL_LPMODE_EN_SHIFT 10 OK, but what's going to use 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] usb:gadget:f_thor: fix write to filesystem by add dfu_flush()
On Thursday, April 17, 2014 at 07:31:00 PM, Przemyslaw Marczak wrote: > Since dfu read/write operations needs to be flushed manually, > writing to filesystem on MMC by thor was broken. MMC raw write > actually is working fine because current dfu_flush() function > writes filesystem only. This commit adds dfu_flush() to f_thor > and now filesystem write is working. > > This change was tested on Trats2 board. > > Signed-off-by: Przemyslaw Marczak > Cc: Lukasz Majewski > Cc: Marek Vasut > Cc: Heiko Schocher > Cc: Tom Rini > --- > drivers/usb/gadget/f_thor.c | 13 + > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c > index f5c0224..ba47945 100644 > --- a/drivers/usb/gadget/f_thor.c > +++ b/drivers/usb/gadget/f_thor.c > @@ -204,14 +204,14 @@ static long long int download_head(unsigned long long > total, > > static int download_tail(long long int left, int cnt) > { > + struct dfu_entity *dfu_entity = dfu_get_entity(alt_setting_num); > void *transfer_buffer = dfu_get_buf(); > int ret; > > debug("%s: left: %llu cnt: %d\n", __func__, left, cnt); > > if (left) { > - ret = dfu_write(dfu_get_entity(alt_setting_num), > - transfer_buffer, left, cnt++); > + ret = dfu_write(dfu_entity, transfer_buffer, left, cnt++); > if (ret) { > error("DFU write failed [%d]: left: %llu", ret, left); > return ret; > @@ -225,11 +225,16 @@ static int download_tail(long long int left, int cnt) >* This also frees memory malloc'ed by dfu_get_buf(), so no explicit >* need fo call dfu_free_buf() is needed. >*/ > - ret = dfu_write(dfu_get_entity(alt_setting_num), > - transfer_buffer, 0, cnt); > + ret = dfu_write(dfu_entity, transfer_buffer, 0, cnt); > if (ret) > error("DFU write failed [%d] cnt: %d", ret, cnt); Please split this into two patches, one which does cleanup (that's the part above) and one which fixes the functionality (that's the part below). > + ret = dfu_flush(dfu_entity, transfer_buffer, 0, cnt); > + if (ret) { > + error("DFU flush failed!"); > + return ret; > + } > + > return ret; > } Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb:gadget:f_thor: fix write to filesystem by add dfu_flush()
Since dfu read/write operations needs to be flushed manually, writing to filesystem on MMC by thor was broken. MMC raw write actually is working fine because current dfu_flush() function writes filesystem only. This commit adds dfu_flush() to f_thor and now filesystem write is working. This change was tested on Trats2 board. Signed-off-by: Przemyslaw Marczak Cc: Lukasz Majewski Cc: Marek Vasut Cc: Heiko Schocher Cc: Tom Rini --- drivers/usb/gadget/f_thor.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/usb/gadget/f_thor.c b/drivers/usb/gadget/f_thor.c index f5c0224..ba47945 100644 --- a/drivers/usb/gadget/f_thor.c +++ b/drivers/usb/gadget/f_thor.c @@ -204,14 +204,14 @@ static long long int download_head(unsigned long long total, static int download_tail(long long int left, int cnt) { + struct dfu_entity *dfu_entity = dfu_get_entity(alt_setting_num); void *transfer_buffer = dfu_get_buf(); int ret; debug("%s: left: %llu cnt: %d\n", __func__, left, cnt); if (left) { - ret = dfu_write(dfu_get_entity(alt_setting_num), - transfer_buffer, left, cnt++); + ret = dfu_write(dfu_entity, transfer_buffer, left, cnt++); if (ret) { error("DFU write failed [%d]: left: %llu", ret, left); return ret; @@ -225,11 +225,16 @@ static int download_tail(long long int left, int cnt) * This also frees memory malloc'ed by dfu_get_buf(), so no explicit * need fo call dfu_free_buf() is needed. */ - ret = dfu_write(dfu_get_entity(alt_setting_num), - transfer_buffer, 0, cnt); + ret = dfu_write(dfu_entity, transfer_buffer, 0, cnt); if (ret) error("DFU write failed [%d] cnt: %d", ret, cnt); + ret = dfu_flush(dfu_entity, transfer_buffer, 0, cnt); + if (ret) { + error("DFU flush failed!"); + return ret; + } + return ret; } -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] pull request for u-boot-tegra/master into ARM/master
Albert, Please pull u-boot-tegra/master into ARM/master. Thanks! ./MAKEALL -s tegra AOK, checkpatch.pl is OK, and ./MAKEALL -a arm only shows failures that were already present in ARM/master. The following changes since commit 1b82491ee6ee1e986e5521b33692a00e1f38fe75: board:tricorder: fixup SPL OOB layout (2014-04-11 10:08:42 -0400) are available in the git repository at: git://git.denx.de/u-boot-tegra.git master for you to fetch changes up to d381294aef4a5b6ddeda3685519330a5b73d884f: ARM: tegra: pack pinmux data tables tighter (2014-04-17 08:41:06 -0700) Stefan Agner (3): usb: tegra: fix USB2 powerdown for Tegra30 and later usb: tegra: fix PHY configuration usb: tegra: combine header file Stephen Warren (14): ARM: tegra: pinctrl: remove func_safe ARM: tegra: pinctrl: remove vddio ARM: tegra: pinctrl: make pmux_func values consistent on Tegra20 ARM: tegra: prototype pinmux_init() in board.h ARM: tegra: use apb_misc.h in more places ARM: tegra: pinctrl: remove duplication ARM: tegra: reduce public pinmux API ARM: tegra: pinmux naming consistency fixes ARM: tegra: Tegra20 pinmux cleanup ARM: tegra: Tegra30 pinmux cleanup ARM: tegra: Tegra114 pinmux cleanup ARM: tegra: Tegra124 pinmux cleanup ARM: tegra: add Jetson TK1 board ARM: tegra: pack pinmux data tables tighter arch/arm/cpu/arm720t/tegra-common/spl.c| 6 +- arch/arm/cpu/arm720t/tegra114/cpu.c| 4 +- arch/arm/cpu/arm720t/tegra124/cpu.c| 4 +- arch/arm/cpu/tegra-common/Makefile | 6 +- arch/arm/cpu/tegra-common/pinmux-common.c | 508 +++ arch/arm/cpu/tegra114-common/funcmux.c | 32 +- arch/arm/cpu/tegra114-common/pinmux.c | 895 +-- arch/arm/cpu/tegra124-common/funcmux.c | 38 +- arch/arm/cpu/tegra124-common/pinmux.c | 898 +-- arch/arm/cpu/tegra20-common/emc.c | 2 +- arch/arm/cpu/tegra20-common/funcmux.c | 185 ++-- arch/arm/cpu/tegra20-common/pinmux.c | 416 +++-- arch/arm/cpu/tegra20-common/warmboot.c | 8 +- arch/arm/cpu/tegra20-common/warmboot_avp.c | 6 +- arch/arm/cpu/tegra30-common/funcmux.c | 20 +- arch/arm/cpu/tegra30-common/pinmux.c | 948 ++-- arch/arm/dts/Makefile | 1 + arch/arm/dts/tegra124-jetson-tk1.dts | 84 ++ .../asm/{arch-tegra20 => arch-tegra}/apb_misc.h| 2 + arch/arm/include/asm/arch-tegra/board.h| 1 + arch/arm/include/asm/arch-tegra/pinmux.h | 185 arch/arm/include/asm/arch-tegra/usb.h | 223 - arch/arm/include/asm/arch-tegra114/pinmux.h| 836 ++ arch/arm/include/asm/arch-tegra114/usb.h | 156 arch/arm/include/asm/arch-tegra124/pinmux.h| 866 +++--- arch/arm/include/asm/arch-tegra124/usb.h | 268 -- arch/arm/include/asm/arch-tegra20/pinmux.h | 372 +++- arch/arm/include/asm/arch-tegra20/usb.h| 155 arch/arm/include/asm/arch-tegra30/pinmux.h | 963 - arch/arm/include/asm/arch-tegra30/usb.h| 168 .../common/pinmux-config-tamonten-ng.h | 492 +-- board/avionic-design/common/tamonten-ng.c | 12 +- board/avionic-design/common/tamonten.c | 4 +- board/compal/paz00/paz00.c | 22 +- board/compulab/trimslice/trimslice.c | 4 +- board/nvidia/cardhu/cardhu.c | 6 +- board/nvidia/cardhu/pinmux-config-cardhu.h | 498 +-- board/nvidia/common/board.c| 9 +- board/nvidia/dalmore/dalmore.c | 9 +- board/nvidia/dalmore/pinmux-config-dalmore.h | 388 - board/nvidia/harmony/harmony.c | 18 +- board/nvidia/jetson-tk1/Makefile | 9 + board/nvidia/jetson-tk1/jetson-tk1.c | 23 + board/nvidia/jetson-tk1/pinmux-config-jetson-tk1.h | 227 + board/nvidia/seaboard/seaboard.c | 6 +- board/nvidia/venice2/as3722_init.h | 4 + board/nvidia/venice2/pinmux-config-venice2.h | 360 board/nvidia/venice2/venice2.c | 15 +- .../colibri_t20-common/colibri_t20-common.c| 8 +- board/toradex/colibri_t20_iris/colibri_t20_iris.c | 4 +- boards.cfg | 1 + drivers/spi/tegra20_sflash.c | 6 +- drivers/usb/host/ehci-tegra.c | 28 +- drivers/video/tegra.c | 4 +- include/configs/jetson-tk1.h | 79 ++ 55 f
Re: [U-Boot] [PATCH 2/2] usb: r8a66597: Fix initilization size of r8a66597 info, structure
On Thursday, April 17, 2014 at 10:20:29 AM, yasuhisa umano wrote: > Initialization of r8a66597 info structure is not enough. > Because initilization was used size of pointer. > This fixes that use size of r8a6659 info structure. > > Signed-off-by: Yasuhisa Umano > --- > drivers/usb/host/r8a66597-hcd.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/host/r8a66597-hcd.c > b/drivers/usb/host/r8a66597-hcd.c index c58d2a9..8e82212 100644 > --- a/drivers/usb/host/r8a66597-hcd.c > +++ b/drivers/usb/host/r8a66597-hcd.c > @@ -807,7 +807,7 @@ int usb_lowlevel_init(int index, enum usb_init_type > init, void **controller) > > R8A66597_DPRINT("%s\n", __func__); > > - memset(r8a66597, 0, sizeof(r8a66597)); > + memset(r8a66597, 0, sizeof(struct r8a66597)); Let's use sizeof(*r8a66597) instead . This is more scalable as you won't need to adjust this code when you change the data type of the *r8a66597 pointer, I will adjust that and apply with sizeof(*r8a66597); , does that work for you? 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/2] usb: r8a66597: Fix initialization hub that using, R8A66597_MAX_ROOT_HUB
On Thursday, April 17, 2014 at 09:48:32 AM, yasuhisa umano wrote: > This driver is processed as two USB hub despite one. > The number of root hub is defined in R8A66597_MAX_ROOT_HUB. > This fixes that register is accessed by using the definition > of R8A66597_MAX_ROOT_HUB. > > Signed-off-by: Yasuhisa Umano > --- > drivers/usb/host/r8a66597-hcd.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/usb/host/r8a66597-hcd.c > b/drivers/usb/host/r8a66597-hcd.c index dfe5423..c58d2a9 100644 > --- a/drivers/usb/host/r8a66597-hcd.c > +++ b/drivers/usb/host/r8a66597-hcd.c > @@ -164,8 +164,8 @@ static int enable_controller(struct r8a66597 *r8a66597) > > r8a66597_bset(r8a66597, INTL, SOFCFG); > r8a66597_write(r8a66597, 0, INTENB0); > - r8a66597_write(r8a66597, 0, INTENB1); > - r8a66597_write(r8a66597, 0, INTENB2); > + for (port = 0; port < R8A66597_MAX_ROOT_HUB; port++) > + r8a66597_write(r8a66597, 0, get_intenb_reg(port)); Hmm, looking at get_intenb_reg(), this is slightly dangerous, but I will trust you you know what you are doing . I am a bit worried someone might set R8A66597_MAX_ROOT_HUB to value >2 and will wonder why doesn't it work. Anyway, I will apply this and if you feel my rant is valid, submit subsequent patch. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/2] eMMC: add support for operations in RPMB partition
This patch adds functions for read, write and authentication key programming for the Replay Protected Memory Block partition in the eMMC. Signed-off-by: Pierre Aubert CC: Pantelis Antoniou --- drivers/mmc/Makefile |1 + drivers/mmc/rpmb.c | 323 ++ include/mmc.h| 10 ++- lib/Makefile |3 + 4 files changed, 336 insertions(+), 1 deletions(-) create mode 100644 drivers/mmc/rpmb.c diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile index 931922b..4c6ab9e 100644 --- a/drivers/mmc/Makefile +++ b/drivers/mmc/Makefile @@ -30,6 +30,7 @@ obj-$(CONFIG_DWMMC) += dw_mmc.o obj-$(CONFIG_EXYNOS_DWMMC) += exynos_dw_mmc.o obj-$(CONFIG_ZYNQ_SDHCI) += zynq_sdhci.o obj-$(CONFIG_SOCFPGA_DWMMC) += socfpga_dw_mmc.o +obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb.o ifdef CONFIG_SPL_BUILD obj-$(CONFIG_SPL_MMC_BOOT) += fsl_esdhc_spl.o else diff --git a/drivers/mmc/rpmb.c b/drivers/mmc/rpmb.c new file mode 100644 index 000..05936f5 --- /dev/null +++ b/drivers/mmc/rpmb.c @@ -0,0 +1,323 @@ +/* + * Copyright 2014, Staubli Faverges + * Pierre Aubert + * + * eMMC- Replay Protected Memory Block + * According to JEDEC Standard No. 84-A441 + * + * SPDX-License-Identifier:GPL-2.0+ + */ + +#include +#include +#include +#include +#include "mmc_private.h" + +/* Request codes */ +#define RPMB_REQ_KEY 1 +#define RPMB_REQ_WCOUNTER 2 +#define RPMB_REQ_WRITE_DATA3 +#define RPMB_REQ_READ_DATA 4 +#define RPMB_REQ_STATUS5 + +/* Response code */ +#define RPMB_RESP_KEY 0x0100 +#define RPMB_RESP_WCOUNTER 0x0200 +#define RPMB_RESP_WRITE_DATA 0x0300 +#define RPMB_RESP_READ_DATA0x0400 + +/* Error codes */ +#define RPMB_OK0 +#define RPMB_ERR_GENERAL 1 +#define RPMB_ERR_AUTH 2 +#define RPMB_ERR_COUNTER 3 +#define RPMB_ERR_ADDRESS 4 +#define RPMB_ERR_WRITE 5 +#define RPMB_ERR_READ 6 +#define RPMB_ERR_KEY 7 +#define RPMB_ERR_CNT_EXPIRED 0x80 +#define RPMB_ERR_MSK 0x7 + +/* Sizes of RPMB data frame */ +#define RPMB_SZ_STUFF 196 +#define RPMB_SZ_MAC32 +#define RPMB_SZ_DATA 256 +#define RPMB_SZ_NONCE 16 + +#define SHA256_BLOCK_SIZE 64 + +/* Error messages */ +static const char * const rpmb_err_msg[] = { + "", + "General failure", + "Authentication failure", + "Counter failure", + "Address failure", + "Write failure", + "Read failure", + "Authentication key not yet programmed", +}; + + +/* Structure of RPMB data frame. */ +struct s_rpmb { + unsigned char stuff[RPMB_SZ_STUFF]; + unsigned char mac[RPMB_SZ_MAC]; + unsigned char data[RPMB_SZ_DATA]; + unsigned char nonce[RPMB_SZ_NONCE]; + unsigned long write_counter; + unsigned short address; + unsigned short block_count; + unsigned short result; + unsigned short request; +}; + +static int mmc_set_blockcount(struct mmc *mmc, unsigned int blockcount, + bool is_rel_write) +{ + struct mmc_cmd cmd = {0}; + + cmd.cmdidx = MMC_CMD_SET_BLOCK_COUNT; + cmd.cmdarg = blockcount & 0x; + if (is_rel_write) + cmd.cmdarg |= 1 << 31; + cmd.resp_type = MMC_RSP_R1; + + return mmc_send_cmd(mmc, &cmd, NULL); +} +static int mmc_rpmb_request(struct mmc *mmc, const struct s_rpmb *s, + unsigned int count, bool is_rel_write) +{ + struct mmc_cmd cmd = {0}; + struct mmc_data data; + int ret; + + ret = mmc_set_blockcount(mmc, count, is_rel_write); + if (ret) { +#ifdef CONFIG_MMC_RPMB_TRACE + printf("%s:mmc_set_blockcount-> %d\n", __func__, ret); +#endif + return 1; + } + + cmd.cmdidx = MMC_CMD_WRITE_MULTIPLE_BLOCK; + cmd.cmdarg = 0; + cmd.resp_type = MMC_RSP_R1b; + + data.src = (const char *)s; + data.blocks = 1; + data.blocksize = MMC_MAX_BLOCK_LEN; + data.flags = MMC_DATA_WRITE; + + ret = mmc_send_cmd(mmc, &cmd, &data); + if (ret) { +#ifdef CONFIG_MMC_RPMB_TRACE + printf("%s:mmc_send_cmd-> %d\n", __func__, ret); +#endif + return 1; + } + return 0; +} +static int mmc_rpmb_response(struct mmc *mmc, struct s_rpmb *s, +unsigned short expected) +{ + struct mmc_cmd cmd = {0}; + struct mmc_data data; + int ret; + + ret = mmc_set_blockcount(mmc, 1, false); + if (ret) { +#ifdef CONFIG_MMC_RPMB_TRACE + printf("%s:mmc_set_blockcount-> %d\n", __func__, ret); +#endif + return -1; + } + cmd.cmdidx = MMC_CMD_READ_MULTIPLE_BLOCK; + cmd.cmdarg = 0; + cmd.resp_type = MMC_RSP_R1; + + data.dest = (char *)s; + data.blocks = 1; + data.blocksize = MMC_MAX_BLOCK_LEN; + data.flags = MMC_DATA_READ;
[U-Boot] [PATCH V2 2/2] eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command
This sub-command adds support for the RPMB partition of an eMMC: * mmc rpmb key Programs the authentication key in the eMMC This key can not be overwritten. * mmc rpmb read <#count> [address of key] Reads <#count> blocks of 256 bytes in the RPMB partition beginning at block number . If the optionnal address of the authentication key is provided, the Message Authentication Code (MAC) is verified on each block. * mmc rpmb write <#count> Writes <#count> blocks of 256 bytes in the RPMB partition beginning at block number . The datas are signed with the key provided. * mmc rpmb counter Returns the 'Write counter' of the RPMB partition. The sub-command is conditional on compilation flag CONFIG_SUPPORT_EMMC_RPMB Signed-off-by: Pierre Aubert CC: Pantelis Antoniou --- common/cmd_mmc.c | 128 +- 1 files changed, 127 insertions(+), 1 deletions(-) diff --git a/common/cmd_mmc.c b/common/cmd_mmc.c index c1916c9..3cf11e7 100644 --- a/common/cmd_mmc.c +++ b/common/cmd_mmc.c @@ -130,7 +130,123 @@ U_BOOT_CMD( "display MMC info", "- display info of the current MMC device" ); +#ifdef CONFIG_SUPPORT_EMMC_RPMB +static int confirm_key_prog(void) +{ + puts("Warning: Programming authentication key can be done only once !\n" +" Use this command only if you are sure of what you are doing,\n" +"Really perform the key programming ? "); + if (getc() == 'y') { + int c; + + putc('y'); + c = getc(); + putc('\n'); + if (c == '\r') + return 1; + } + puts("Authentication key programming aborted\n"); + return 0; +} +static int do_mmcrpmb(int argc, char * const argv[]) +{ + enum rpmb_state { + RPMB_INVALID, + RPMB_READ, + RPMB_WRITE, + RPMB_KEY, + RPMB_COUNTER, + } state; + + state = RPMB_INVALID; + if (argc == 4 && strcmp(argv[2], "key") == 0) + state = RPMB_KEY; + if ((argc == 6 || argc == 7) && strcmp(argv[2], "read") == 0) + state = RPMB_READ; + else if (argc == 7 && strcmp(argv[2], "write") == 0) + state = RPMB_WRITE; + else if (argc == 3 && strcmp(argv[2], "counter") == 0) + state = RPMB_COUNTER; + + if (state != RPMB_INVALID) { + struct mmc *mmc = find_mmc_device(curr_device); + void *key_addr; + char original_part; + int ret; + + if (!mmc) { + printf("no mmc device at slot %x\n", curr_device); + return CMD_RET_FAILURE; + } + mmc_init(mmc); + if (IS_SD(mmc)) { + printf("It is not a EMMC device\n"); + return CMD_RET_FAILURE; + } + /* Switch to the RPMB partition */ + original_part = mmc->part_num; + if (mmc->part_num != MMC_PART_RPMB) { + if (mmc_switch_part(curr_device, MMC_PART_RPMB) != 0) + return CMD_RET_FAILURE; + mmc->part_num = MMC_PART_RPMB; + } + ret = CMD_RET_SUCCESS; + if (state == RPMB_KEY) { + key_addr = (void *)simple_strtoul(argv[3], NULL, 16); + if (confirm_key_prog()) { + if (mmc_rpmb_set_key(mmc, key_addr)) { + printf("ERROR - Key already programmed ?\n"); + ret = CMD_RET_FAILURE; + } + } else { + ret = CMD_RET_FAILURE; + } + } else if (state == RPMB_COUNTER) { + unsigned long counter; + if (mmc_rpmb_get_counter(mmc, &counter)) + ret = CMD_RET_FAILURE; + else + printf("Write counter= %lx\n", counter); + } else { + u16 blk, cnt; + void *addr; + int n; + + addr = (void *)simple_strtoul(argv[3], NULL, 16); + blk = simple_strtoul(argv[4], NULL, 16); + cnt = simple_strtoul(argv[5], NULL, 16); + + if (state == RPMB_READ) { + key_addr = (argc == 7) ? + (void *)simple_strtoul(argv[6], + NULL, 16) : + NULL; + n = mmc_rpmb_read(mmc, addr, blk, cnt, +
[U-Boot] [PATCH V2 0/2] eMMC: support for Read Protected Memory Block (RPMB)
This serie of patches adds some functions and a sub-command of 'mmc' for programming the authentication key and for reading and writing the RPMB partition of an eMMC according to the JEDEC standard No. 64-A441 The sub-command rpmb is enabled by the flag CONFIG_SUPPORT_EMMC_RPMB defined in the board configuration file. It has been tested on a SabreSDP iMX6 board. Changes in V2: - use ALLOC_CACHE_ALIGN_BUFFER in rpmb.c instead of a static buffer for the RPMB frames. Pierre Aubert (2): eMMC: add support for operations in RPMB partition eMMC: cmd_mmc.c adds the 'rpmb' sub-command for the 'mmc' command common/cmd_mmc.c | 128 - drivers/mmc/Makefile |1 + drivers/mmc/rpmb.c | 323 ++ include/mmc.h| 10 ++- lib/Makefile |3 + 5 files changed, 463 insertions(+), 2 deletions(-) create mode 100644 drivers/mmc/rpmb.c -- 1.7.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Do not use __DATE__ and __TIME__ anymore
Dear Masahiro, In message <20140417204113.6cec.aa925...@jp.panasonic.com> you wrote: > > I want to gather timestamp stuff to one place for easy control of it. All understood - but this should be documented in the commit message. 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 We are Microsoft. Unix is irrelevant. Openness is futile. Prepare to be assimilated. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/11] SPL: NAND: remove CONFIG_SYS_NAND_PAGE_SIZE
On Mon, Apr 14, 2014 at 4:38 AM, Stefano Babic wrote: > On 03/04/2014 08:01, Tim Harvey wrote: >> We only need to read in the size of struct image_header and thus don't >> need to know the page size of the nand device. >> >> Signed-off-by: Tim Harvey >> --- >> common/spl/spl_nand.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/common/spl/spl_nand.c b/common/spl/spl_nand.c >> index 9da0218..062461b 100644 >> --- a/common/spl/spl_nand.c >> +++ b/common/spl/spl_nand.c >> @@ -76,7 +76,7 @@ void spl_nand_load_image(void) >> #endif >> /* Load u-boot */ >> nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS, >> - CONFIG_SYS_NAND_PAGE_SIZE, (void *)header); >> + sizeof(*header), (void *)header); >> spl_parse_image_header(header); >> nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS, >> spl_image.size, (void *)spl_image.load_addr); >> > > Acked-by: Stefano Babic > > Best regards, > Stefano Babic > Scott, This should have been addressed to you in the first place as its NAND and not IMX specific. It's been +1'd and ack'd, so if you agree with it and commit it I'll remove it from my next patch series regarding IMX6 SPL NAND support. Tim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: consolidate arch/arm/include/asm/arch-*/spl.h
Hi Masahiro, On 16/04/2014 08:44, Masahiro Yamada wrote: > arch/arm/include/asm/spl.h requires all SoCs to have > arch/arm/include/asm/arch-*/spl.h. > > But many of them just define BOOT_DEVICE_* macros. > > Those macros are used in the "switch (boot_device) { ... }" > statement in common/spl/spl.c. > > So they should not be archtecture specific, but described as > a simpile enumeration. Absolutely right ! > > This commit merge most of arch/arm/include/asm/arch-*/spl.h > into arch/arm/include/asm/spl.h. > > With a little more effort, arch-zynq/spl.h and arch-socfpga/spl.h > will be merged, while I am not sure about OMAP and Exynos. > > Signed-off-by: Masahiro Yamada > Cc: Tom Rini > Cc: Michal Simek > Cc: Andreas Bießmann > Cc: Stephen Warren > Cc: Tom Warren > CC: Stefano Babic > CC: Minkyu Kang > Cc: Dinh Nguyen > --- > arch/arm/cpu/arm720t/tegra-common/spl.c | 2 +- > arch/arm/include/asm/arch-at91/spl.h | 24 > arch/arm/include/asm/arch-davinci/spl.h | 16 > arch/arm/include/asm/arch-mx35/spl.h | 22 -- > arch/arm/include/asm/arch-mx5/spl.h | 13 - > arch/arm/include/asm/arch-tegra114/spl.h | 22 -- > arch/arm/include/asm/arch-tegra124/spl.h | 13 - > arch/arm/include/asm/arch-tegra20/spl.h | 12 > arch/arm/include/asm/arch-tegra30/spl.h | 12 > arch/arm/include/asm/spl.h | 18 ++ > board/denx/m53evk/m53evk.c | 2 +- > 11 files changed, 20 insertions(+), 136 deletions(-) > delete mode 100644 arch/arm/include/asm/arch-at91/spl.h > delete mode 100644 arch/arm/include/asm/arch-davinci/spl.h > delete mode 100644 arch/arm/include/asm/arch-mx35/spl.h > delete mode 100644 arch/arm/include/asm/arch-mx5/spl.h > delete mode 100644 arch/arm/include/asm/arch-tegra114/spl.h > delete mode 100644 arch/arm/include/asm/arch-tegra124/spl.h > delete mode 100644 arch/arm/include/asm/arch-tegra20/spl.h > delete mode 100644 arch/arm/include/asm/arch-tegra30/spl.h > > diff --git a/arch/arm/cpu/arm720t/tegra-common/spl.c > b/arch/arm/cpu/arm720t/tegra-common/spl.c > index 5171a8f..8147806 100644 > --- a/arch/arm/cpu/arm720t/tegra-common/spl.c > +++ b/arch/arm/cpu/arm720t/tegra-common/spl.c > @@ -14,7 +14,7 @@ > #include > #include > #include > -#include > +#include > #include "cpu.h" > > void spl_board_init(void) > diff --git a/arch/arm/include/asm/arch-at91/spl.h > b/arch/arm/include/asm/arch-at91/spl.h > deleted file mode 100644 > index d8a87da..000 > --- a/arch/arm/include/asm/arch-at91/spl.h > +++ /dev/null > @@ -1,24 +0,0 @@ > -/* > - * Copyright (C) 2013 Atmel Corporation > - * Bo Shen > - * > - * SPDX-License-Identifier: GPL-2.0+ > - */ > - > -#ifndef _ASM_ARCH_SPL_H_ > -#define _ASM_ARCH_SPL_H_ > - > -enum { > - BOOT_DEVICE_NONE, > -#ifdef CONFIG_SYS_USE_MMC > - BOOT_DEVICE_MMC1, > - BOOT_DEVICE_MMC2, > - BOOT_DEVICE_MMC2_2, > -#elif CONFIG_SYS_USE_NANDFLASH > - BOOT_DEVICE_NAND, > -#elif CONFIG_SYS_USE_SERIALFLASH > - BOOT_DEVICE_SPI, > -#endif > -}; > - > -#endif > diff --git a/arch/arm/include/asm/arch-davinci/spl.h > b/arch/arm/include/asm/arch-davinci/spl.h > deleted file mode 100644 > index 5afe0d4..000 > --- a/arch/arm/include/asm/arch-davinci/spl.h > +++ /dev/null > @@ -1,16 +0,0 @@ > -/* > - * (C) Copyright 2012 > - * Texas Instruments, > - * > - * SPDX-License-Identifier: GPL-2.0+ > - */ > -#ifndef _ASM_ARCH_SPL_H_ > -#define _ASM_ARCH_SPL_H_ > - > -#define BOOT_DEVICE_NAND 1 > -#define BOOT_DEVICE_SPI 2 > -#define BOOT_DEVICE_MMC1 3 > -#define BOOT_DEVICE_MMC2 4 /* dummy */ > -#define BOOT_DEVICE_MMC2_2 5 /* dummy */ > - > -#endif > diff --git a/arch/arm/include/asm/arch-mx35/spl.h > b/arch/arm/include/asm/arch-mx35/spl.h > deleted file mode 100644 > index d0efec2..000 > --- a/arch/arm/include/asm/arch-mx35/spl.h > +++ /dev/null > @@ -1,22 +0,0 @@ > -/* > - * (C) Copyright 2012 > - * Texas Instruments, > - * > - * SPDX-License-Identifier: GPL-2.0+ > - */ > -#ifndef _ASM_ARCH_SPL_H_ > -#define _ASM_ARCH_SPL_H_ > - > -#define BOOT_DEVICE_NONE 0 > -#define BOOT_DEVICE_XIP 1 > -#define BOOT_DEVICE_XIPWAIT 2 > -#define BOOT_DEVICE_NAND 3 > -#define BOOT_DEVICE_ONENAND 4 > -#define BOOT_DEVICE_MMC1 5 > -#define BOOT_DEVICE_MMC2 6 > -#define BOOT_DEVICE_MMC2_2 7 > -#define BOOT_DEVICE_NOR 8 > -#define BOOT_DEVICE_I2C 9 > -#define BOOT_DEVICE_SPI 10 > - > -#endif > diff --git a/arch/arm/include/asm/arch-mx5/spl.h > b/arch/arm/include/asm/arch-mx5/spl.h > deleted file mode 100644 > index 20c6cae..000 > --- a/arch/arm/include/asm/arch-mx5/spl.h > +++ /dev/null > @@ -1,13 +0,0 @@ > -/* > - * Copyright (C) 2013 Marek Vasut > - * > - * SPDX-License-Identifier: GPL-2.0+ > - */ > - > -
Re: [U-Boot] [PATCH] tools: make imxheader size align on page size
Hi Stefan, On 16/04/2014 15:17, Stefan Agner wrote: > > Quite possible that an altered/correct FCB would actually work. But > speaking about FCB, is there already something for Vybrid? I'm currently > try to create an Image with FCB+IVT V2 header using the mxsboot utility, mxsboot is not the right tool. There are some discussion about this some time ago. The best thing is that mkimage can be improved to add the FCB when the image is generated. As far as I know, nobody has started to develop it - patches are welcome, if you decide to do it ;-) 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 06/11] MX6: add struct for sharing data between SPL and uboot
Hi Stefano, Tim, On 04/17/14 12:30, Stefano Babic wrote: > Hi Tim, > > On 17/04/2014 08:07, Tim Harvey wrote: >> On Mon, Apr 14, 2014 at 5:35 AM, Stefano Babic wrote: >>> Hi Tim, >>> >>> I see checking your patch that the MXS uses the same concept. And as far >>> as I can see, boot_mode_idx is used only to print the boot devioce >> >> Stefano, >> >> yes, that is where I got the concept from. > > Well, it slipped into mainline, but adding such a structure only to have > a better print is not very useful... > >> I've been told this before, but I've found that get_ram_size() will >> hang on an i.MX6 if you pass it a maxsize larger than the memory in >> your system. Perhaps you can verify you see the same behavior? > > get_ram_size() works if the memory is accessible, that means that no > exception is generated when it tries to access. If the RAM controller is > programmed for a larger amount of memory, because you can have board > with different capacity of RAM, get_ram_size() finds dynamically the > soldered value. > > However, if the RAM controller is programmed for an amount of RAM > smaller as what get_ram_size() tries to identify, an exception is > raised. In get_ram_size(start, size) we pass the maximum amount of > memory that the function is allowed to check. I can imagine we are > running in this case. Checking on i.MX6, we have both boards checking > the size with get_ram_size() as mx6sabresd, as well as boards fixing at > compile time the value of the RAM (nitrogen6x). get_ram_size() works on cm-fx6 all DRAM configurations. > >>> SPL is thought to generally load an image (of course, in most cases it >>> is u-boot). In Falcon mode, the kernel is started without running >>> u-boot, making this structure useless. Do we really need such a way (but >>> then, it must be generalized as SPL API), or can we get rid of it ? >> >> As we have an EEPROM on the board that tells us the physical ram size, >> I use that to avoid the lockup. > > It seems weird. There is several boards in mainline (I am sure about > Freescale's PowerPC) discovering the mounted RAM. Of course, this is > simpler if many parameters (row/columns/...) are the same, I am not sure > about this. Even if the parameters are different, this should not result in lockup... AFAICS, lockup of that type has nothing to do with the DRAM itself, but the controller configuration. > Are we sure it is not possible here ? What does it happen > with an inconsistent value in EEprom ? > >> Eventually I would like to read and >> validate the entire EEPROM once in SPL and pass this to u-boot.img to >> avoid reading and validating it again. I think this is a good example >> of why sharing data between SPL and u-boot.img could be useful. > > I am not sure, and I doubt it is a good idea to use persistent data to > store that. It is potentially dangerous, and if some reasons the EEprom > is changed, the board could not boot at all. This is more a question of design and definition of what purpose the eeprom should serve, so I would let the vendor decide if he wants to depend on eeprom or not. > > On the other side, I like the current concept that the SPL is simply a > loader and can load images of different types, and fixing an API between > SPL and U-Boot goes against this concept. I agree on this one, there is no real need (at least currently) to introduce such an API. Also, there are cases (e.g. cm-fx6) where the DRAM size can be determined by just reading the MMDC configuration and thus spare additional get_ram_size() call from U-Boot. -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/11] MX6: add struct for sharing data between SPL and uboot
Hi Igor, hi Tim On 17/04/2014 13:22, Igor Grinberg wrote: > > get_ram_size() works on cm-fx6 all DRAM configurations. As on most boards in mainline ;-) > >> SPL is thought to generally load an image (of course, in most cases it is u-boot). In Falcon mode, the kernel is started without running u-boot, making this structure useless. Do we really need such a way (but then, it must be generalized as SPL API), or can we get rid of it ? >>> >>> As we have an EEPROM on the board that tells us the physical ram size, >>> I use that to avoid the lockup. >> >> It seems weird. There is several boards in mainline (I am sure about >> Freescale's PowerPC) discovering the mounted RAM. Of course, this is >> simpler if many parameters (row/columns/...) are the same, I am not sure >> about this. > > Even if the parameters are different, this should not result in lockup... > AFAICS, lockup of that type has nothing to do with the DRAM itself, but > the controller configuration. Exactly, this is what I meant. Thanks for clarifying it better. > >> Are we sure it is not possible here ? What does it happen >> with an inconsistent value in EEprom ? >> >>> Eventually I would like to read and >>> validate the entire EEPROM once in SPL and pass this to u-boot.img to >>> avoid reading and validating it again. I think this is a good example >>> of why sharing data between SPL and u-boot.img could be useful. >> >> I am not sure, and I doubt it is a good idea to use persistent data to >> store that. It is potentially dangerous, and if some reasons the EEprom >> is changed, the board could not boot at all. > > This is more a question of design and definition of what purpose the eeprom > should serve, so I would let the vendor decide if he wants to depend on eeprom > or not. Agree. Parsing and evaluating vendor specific information can be done inside board specific part, as now in read_eeprom inside gw_ventana.c. Anyway, if there is a way to detect at runtime the hardware configuration, it remains a better way as to store the size into the Eeprom. Best regards, Stefano -- = 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 0/5] Do not use __DATE__ and __TIME__ anymore
Hi Wolfgang On Thu, 17 Apr 2014 13:07:32 +0200 Wolfgang Denk wrote: > Dear Masahiro, > > In message <1397721632-18797-1-git-send-email-yamad...@jp.panasonic.com> you > wrote: > > > > The aim of this series is to prohibit using __DATE__ and __TIME__. > > What is bad about using these? include/generated/timestamp_autogenerated.h provides us the last build date correctly because it is touched every time. __DATE__ or __TIME__ might give us unexpectedly old date because it is not updated unless the source file is modified. One more reason. Using __DATE__ / __TIME__ here and there makes the binary comparison difficult. I often use MD5SUM comparison to confirm that my changes to the build system still produce the same output. I want to generate the completely same result if the source code is the same. This can be achieved by simply disabling the timestamp file and version file. I want to gather timestamp stuff to one place for easy control of it. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] usb: r8a66597: Fix initialization hub that using, R8A66597_MAX_ROOT_HUB
On Thursday, April 17, 2014 at 09:48:32 AM, yasuhisa umano wrote: > This driver is processed as two USB hub despite one. > The number of root hub is defined in R8A66597_MAX_ROOT_HUB. > This fixes that register is accessed by using the definition > of R8A66597_MAX_ROOT_HUB. > > Signed-off-by: Yasuhisa Umano Is there any reason why those two patches were sent twice please ? They seem the same in both cases. Otherwise, I'm fine with those patches. 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/5] net: rename and refactor eth_rand_ethaddr() function
Dear Masahiro, In message <1397721632-18797-3-git-send-email-yamad...@jp.panasonic.com> you wrote: > Some functions in include/net.h are ported from > include/linux/etherdevice.h of Linux Kernel. > > For ex. > is_zero_ether_addr() > is_multicast_ether_addr() > is_broadcast_ether_addr() > is_valid_ether_addr(); > > So, we should use the same function name as Linux Kernel, > eth_rand_addr(), for consistency. > > Because eth_rand_addr() is impilemented as inline function, > it should not be surrounded by ifdef CONFIG_RANDOM_MACADDR. None of this is mentioned in the description of this patch series in your cover letter. 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 It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. - Franklin D. Roosevelt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Do not use __DATE__ and __TIME__ anymore
Dear Masahiro, In message <1397721632-18797-1-git-send-email-yamad...@jp.panasonic.com> you wrote: > > The aim of this series is to prohibit using __DATE__ and __TIME__. What is bad about using these? 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 It is easier to change the specification to fit the program than vice versa. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/13] ARMv7: add PSCI support to u-boot
On Thu, 2014-04-17 at 09:58 +0100, Marc Zyngier wrote: > Ian Campbell (cc-ed) is actively pushing out patches to support the A20 > in mainline U-Boot (I believe you've been on the receiving end of > these), Need to make a few more cleanups based on the review but v$NEXT should be along soon. > and I plan to rebase my series on top of his. In fact I was banking on it and have deliberately left SMP support out of the upstreaming series. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] Is there generic code to detect nand chip's ecc bits?
Hi, Scott: I have a question about nand chip's ecc bits: Nand chip usually declared its ecc bits for each 512 bytes in its data sheet. Such as: Some nand chips required 4bit ECC for each 512 bytes. Some nand chips required 2bit ECC for each 512 bytes. So, my question is: Could ecc bits be got from nand chip's flash id? Or other generic method to retrieve ECC bits required for every nand chip? Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] arm: ep9315: Return back Cirrus Logic EDB9315A board support
Hi Sergey, On Thu, 6 Mar 2014 21:20:20 +0400, Sergey Kostanbaev wrote: > diff --git a/arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S > b/arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S > index bf2fa2a..3ac0f88 100644 > --- a/arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S > +++ b/arch/arm/cpu/arm920t/ep93xx/lowlevel_init.S > @@ -1,49 +1,456 @@ > /* > * Low-level initialization for EP93xx > * > - * Copyright (C) 2009 Matthias Kaehlcke > + * Copyright (C) 2013 > + * Sergey Kostanabev fairwaves.ru> > * > - * Copyright (C) 2006 Dominic Rath > + * Copyright (C) 2006 Cirrus Logic Inc. Why do you remove existing copyright attributions? > [...] > + * Determine the size of the SDRAM. Use data=address for the scan. > + > + * Input:r0 - Start SDRAM address > + * Return: r0 - Single block size > + * r1 - Valid block mask > + * r2 - Total block count > + * Modifies: r0-r5 > + */ > +ep93xx_sdram_size: Is this needed? Can't the general get_ram_size() function be used? > diff --git a/arch/arm/include/asm/arch-ep93xx/ep93xx.h > b/arch/arm/include/asm/arch-ep93xx/ep93xx.h > index 9e7f2f3..71aa601 100644 > --- a/arch/arm/include/asm/arch-ep93xx/ep93xx.h > +++ b/arch/arm/include/asm/arch-ep93xx/ep93xx.h > @@ -580,3 +658,11 @@ struct syscon_regs { > /* > * 0x8095 - 0x9000: Reserved > */ > + > +/* > + * During low_level init we store memory layout in memory at specific > location > + */ > +#define UBOOT_MEMORYCNF_BANK_SIZE0x2000 > +#define UBOOT_MEMORYCNF_BANK_MASK0x2004 > +#define UBOOT_MEMORYCNF_BANK_COUNT 0x2008 > + Remove blank line at EOF. > diff --git a/board/cirrus/edb93xx/u-boot.lds b/board/cirrus/edb93xx/u-boot.lds Does this board need a specific .lds file? > [...] > + /DISCARD/ : { *(.dynsym) } > + /DISCARD/ : { *(.dynstr*) } > + /DISCARD/ : { *(.dynamic*) } > + /DISCARD/ : { *(.plt*) } > + /DISCARD/ : { *(.interp*) } > + /DISCARD/ : { *(.gnu*) } We don't /DISCARD/ these sections any more. If for some reason the generic .lds fils cannot be used, then adapt this one to current practice. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 00/13] ARMv7: add PSCI support to u-boot
Hi Marc, On Thu, 17 Apr 2014 09:58:19 +0100, Marc Zyngier wrote: > On Thu, Apr 17 2014 at 9:34:24 am BST, Albert ARIBAUD > wrote: > > Hi Marc, > > > > On Wed, 16 Apr 2014 17:09:07 +0100, Marc Zyngier > > wrote: > > > >> On 16/04/14 15:45, Albert ARIBAUD wrote: > >> > Hi Marc, > >> > > >> > On Sat, 15 Feb 2014 13:36:24 +, Marc Zyngier > >> > wrote: > >> > > >> >> PSCI is an ARM standard that provides a generic interface that > >> >> supervisory software can use to manage power in the following > >> >> situations: > >> >> - Core idle management > >> >> - CPU hotplug > >> >> - big.LITTLE migration models > >> >> - System shutdown and reset > >> >> > >> >> It basically allows the kernel to offload these tasks to the firmware, > >> >> and rely on common kernel side code. > >> >> > >> >> More importantly, it gives a way to ensure that CPUs enter the kernel > >> >> at the appropriate exception level (ie HYP mode, to allow the use of > >> >> the virtualization extensions), even across events like CPUs being > >> >> powered off/on or suspended. > >> >> > >> >> The main idea here is to turn some of the existing u-boot code into a > >> >> separate section that can live in secure RAM (or a reserved page of > >> >> memory), containing a secure monitor that will implement the PSCI > >> >> operations. This code will still be alive when u-boot is long gone, > >> >> hence the need for a piece of memory that will not be touched by the > >> >> OS. > >> >> > >> >> This patch series contains 4 parts: > >> >> - the first four patches are just bug fixes > >> >> - the next two refactor the HYP/non-secure code to allow relocation > >> >> in secure memory > >> >> - the next four contain the generic PSCI code and DT infrastructure > >> >> - the last three implement the CPU_ON method of the Allwinner A20 (aka > >> >> sun7i). > >> >> > >> >> I realize the A20 u-boot code is not upstream yet (BTW is anyone > >> >> actively working on that?), but hopefully that should give a good idea > >> >> of how things are structured so far. The patches are against the > >> >> mainline u-boot tree as of today, merged with the sunxi u-boot tree > >> >> of the day and the first 10 patches will directly apply to mainline > >> >> u-boot. > >> >> > >> >> As for using this code, it goes like this: > >> >> sun7i# ext2load mmc 0:1 0x40008000 zImage ; ext2load mmc 0:1 0x6000 > >> >> sun7i-a20-cubietruck.dtb > >> >> 2270120 bytes read in 117 ms (18.5 MiB/s) > >> >> 9138 bytes read in 3 ms (2.9 MiB/s) > >> >> sun7i# fdt addr 0x6000 ; fdt resize ; fdt set ethernet0 mac-address > >> >> "[5a fe b0 07 b0 07]" > >> >> sun7i# setenv bootargs console=ttyS0,115200 earlyprintk ip=dhcp > >> >> root=/dev/nfs nfsroot=/backup/a20_root,tcp > >> >> sun7i# bootz 0x40008000 - 0x6000 > >> >> > >> >> The kernel now boots in HYP mode, finds its secondary CPU without any > >> >> SMP code present in the kernel, and runs KVM out of the box. > >> >> I've been told the Xen/ARM guys managed to do the same fairly easily. > >> >> > >> >> This code has also been tested on a VExpress TC2, running KVM with all > >> >> 5 CPUs, in order to make sure there was no obvious regression. > >> >> > >> >> I'm wildly cross-posting this patch series, including to lists I'm not > >> >> subscribed to. Please keep me on Cc for any comment you may have. > >> >> > >> >> The code is also available at: > >> >> git://git.kernel.org/pub/scm/linux/kernel/git/maz/u-boot.git wip/psci > >> >> > >> >> Cheers, > >> >> > >> >> M. > >> > > >> > Marc, I'm unclear what you want to do with this series. You mention > >> > that its first 10 patches will apply to U-Boot, but I am not sure > >> > whether you are just indicating that it is possible to apply them or > >> > asking for these 10 patches to go in U-Boot mainline. Or is it > >> > something else yet? > >> > >> Well, I rarely write code just for the sake of forking a critical > >> project ;-) > >> > >> So let's be 100% explicit: Yes, I'm hereby asking for these patches to > >> be merged. They offer a service that is required by the Linux kernel as > >> well as Xen. They are in active use on the Allwinner sun7i platform as > >> well as Versatile Express (though the later doesn't have a PSCI > >> implementation). > >> > >> Now, given that two months have gone past without much comment other > >> than the odd "hey, works great", I don't really know where to take that. > >> > >> Are you willing to review the patches? > > > > Well, I rarely ask about patches just for the sake of conversation. O:-) > > > > So yes, I am willing to review them -- and I suspect others are, as > > well. Nobody commented the V3 series on the U-Boot list -- save for > > Jon's comment about the series needing a rebase -- which could mean no > > one here is unhappy with them... or they were discussed and possibly > > acted upon on linux-sunxi, where the replies were redirected. I don't > > follow linux-sunx closely, so I couldn't tell. :) > > No, so fa
Re: [U-Boot] [PATCH 06/11] MX6: add struct for sharing data between SPL and uboot
Hi Tim, On 17/04/2014 08:07, Tim Harvey wrote: > On Mon, Apr 14, 2014 at 5:35 AM, Stefano Babic wrote: >> Hi Tim, >> >> I see checking your patch that the MXS uses the same concept. And as far >> as I can see, boot_mode_idx is used only to print the boot devioce > > Stefano, > > yes, that is where I got the concept from. Well, it slipped into mainline, but adding such a structure only to have a better print is not very useful... > I've been told this before, but I've found that get_ram_size() will > hang on an i.MX6 if you pass it a maxsize larger than the memory in > your system. Perhaps you can verify you see the same behavior? get_ram_size() works if the memory is accessible, that means that no exception is generated when it tries to access. If the RAM controller is programmed for a larger amount of memory, because you can have board with different capacity of RAM, get_ram_size() finds dynamically the soldered value. However, if the RAM controller is programmed for an amount of RAM smaller as what get_ram_size() tries to identify, an exception is raised. In get_ram_size(start, size) we pass the maximum amount of memory that the function is allowed to check. I can imagine we are running in this case. Checking on i.MX6, we have both boards checking the size with get_ram_size() as mx6sabresd, as well as boards fixing at compile time the value of the RAM (nitrogen6x). >> SPL is thought to generally load an image (of course, in most cases it >> is u-boot). In Falcon mode, the kernel is started without running >> u-boot, making this structure useless. Do we really need such a way (but >> then, it must be generalized as SPL API), or can we get rid of it ? > > As we have an EEPROM on the board that tells us the physical ram size, > I use that to avoid the lockup. It seems weird. There is several boards in mainline (I am sure about Freescale's PowerPC) discovering the mounted RAM. Of course, this is simpler if many parameters (row/columns/...) are the same, I am not sure about this. Are we sure it is not possible here ? What does it happen with an inconsistent value in EEprom ? > Eventually I would like to read and > validate the entire EEPROM once in SPL and pass this to u-boot.img to > avoid reading and validating it again. I think this is a good example > of why sharing data between SPL and u-boot.img could be useful. I am not sure, and I doubt it is a good idea to use persistent data to store that. It is potentially dangerous, and if some reasons the EEprom is changed, the board could not boot at all. On the other side, I like the current concept that the SPL is simply a loader and can load images of different types, and fixing an API between SPL and U-Boot goes against this concept. 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] mmc: Handle switch error status bit in MMC card status
Hi Pantelis, > From: Gabbasov, Andrew > Sent: Thursday, April 03, 2014 13:32 > To: Pantelis Antoniou > Cc: u-boot@lists.denx.de > Subject: RE: [U-Boot] [PATCH] mmc: Handle switch error status bit in MMC card > status > > Hi Pantelis, > > > From: Pantelis Antoniou [pa...@antoniou-consulting.com] > > Sent: Wednesday, April 02, 2014 14:14 > > To: Gabbasov, Andrew > > Cc: u-boot@lists.denx.de > > Subject: Re: [U-Boot] [PATCH] mmc: Handle switch error status bit in MMC > > card status > > > > Hi Andrew, > > > > In general looks good; only a small nag. > > > > On Mar 24, 2014, at 9:39 AM, Andrew Gabbasov wrote: > > > > > MMC switch command for unsupported feature (e.g. bus width) sets a switch > > > error bit in card status. This bit should be checked, and, if it's set, > > > no access with new controller settings should be performed. > > > > [ skipped ] > > > @@ -505,7 +507,7 @@ static int mmc_change_freq(struct mmc *mmc) > > > err = mmc_switch(mmc, EXT_CSD_CMD_SET_NORMAL, EXT_CSD_HS_TIMING, 1); > > > > > > if (err) > > > - return err; > > > + return ((err == SWITCH_ERR) ? 0 : err); > > > > > > > Change to: > > > > return err == SWITCH_ERR ? 0 : err; > > > > No need for parentheses. > > Thank you for the review. > I'm sending a v2 patch with his change and also re-based to current master > head. Did you have a chance to look at the v2 patch (sent separately)? WIll you Ack it? Thanks! Best regards, Andrew ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/11] MX6: add boot device support SPL
Hi Tim, On 17/04/2014 08:16, Tim Harvey wrote: >>> + boot_dev = MX6_SATA_BOOT; >>> + break; >>> + /* Serial ROM: See 8.5.5.1, Table 8-22 */ >>> + case 0x3: >>> + /* BOOT_CFG4[2:0] */ >>> + switch ((soc_sbmr & 0x0700) >> 24) { >>> + case 0x0 ... 0x4: >>> + boot_dev = MX6_SPI_NOR_BOOT; >>> + break; >>> + case 0x5 ... 0x7: >>> + boot_dev = MX6_I2C_BOOT; >>> + break; >>> + } >>> + break; >>> + /* SD/eSD: 8.5.3, Table 8-15 */ >>> + case 0x4: >>> + case 0x5: >>> + boot_dev = MX6_SD_BOOT; >>> + break; >>> + /* MMC/eMMC: 8.5.3 */ >>> + case 0x6: >>> + case 0x7: >>> + boot_dev = MX6_MMC_BOOT; >>> + break; >>> + /* NAND Flash: 8.5.2 */ >>> + case 0x8 ... 0xf: >>> + boot_dev = MX6_NAND_BOOT; >>> + break; >>> + default: >>> + boot_dev = MX6_UNKNOWN_BOOT; >>> + break; >>> + } >>> + >> >> The function can be used as well for MX5 SOCs. Move it into imx-common, >> and use constants without SOC names. Instead of MX6_NAND_BOOT, >> IMX_NAND_BOOT (or whatever you find makes sense..) > > Are you saying the i.MX5's have the same register and meaning? I > figured the sbmr is different. The register is the same, and mostly with the same meaning. You do not need to care about it. Just put it into imx-common, and when someone will add support for MX5, this function will be analyzed and modified instead of adding a new one. > >> >>> + return boot_dev; >>> +} >>> + >>> + >>> void s_init(void) >>> { >>> struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR; >>> diff --git a/arch/arm/include/asm/arch-mx6/spl.h >>> b/arch/arm/include/asm/arch-mx6/spl.h >>> new file mode 100644 >>> index 000..5611c71 >>> --- /dev/null >>> +++ b/arch/arm/include/asm/arch-mx6/spl.h >>> @@ -0,0 +1,26 @@ >>> +/* >>> + * Copyright (C) 2013 TechNexion Ltd. >>> + * >>> + * Author: Richard Hu >>> + * >>> + * See file CREDITS for list of people who contributed to this >>> + * project. >>> + * >>> + * This program is free software; you can redistribute it and/or >>> + * modify it under the terms of the GNU General Public License as >>> + * published by the Free Software Foundation; either version 2 of >>> + * the License, or (at your option) any later version. >>> + */ >>> + >>> +#ifndef __ASM_ARCH_SPL_H__ >>> +#define __ASM_ARCH_SPL_H__ >>> + >>> +#define BOOT_DEVICE_MMC1 0 >>> +#define BOOT_DEVICE_MMC2 1 >>> +#define BOOT_DEVICE_MMC2_2 2 >>> +#define BOOT_DEVICE_NAND 3 >>> +#define BOOT_DEVICE_SATA 4 >>> +#define BOOT_DEVICE_USBETH 5 >>> +#define BOOT_DEVICE_NONE 6 >>> + >> >> They are only defines and are not yet related to i.MX6 anymnore, because >> you have already mapped them. What about to move this defines into >> imx-common ? > > ok > Masahiro has sent this week a patch to consolidate names, that are duplicated for all architecture: http://patchwork.ozlabs.org/patch/339438/ I think it is a very good idea to follow his approach. > > I hope to have a v2 posted soon. Please only wait until I send my remark regarding the patches with pinmux. 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 v3 00/13] ARMv7: add PSCI support to u-boot
On Thu, Apr 17 2014 at 9:34:24 am BST, Albert ARIBAUD wrote: > Hi Marc, > > On Wed, 16 Apr 2014 17:09:07 +0100, Marc Zyngier > wrote: > >> On 16/04/14 15:45, Albert ARIBAUD wrote: >> > Hi Marc, >> > >> > On Sat, 15 Feb 2014 13:36:24 +, Marc Zyngier >> > wrote: >> > >> >> PSCI is an ARM standard that provides a generic interface that >> >> supervisory software can use to manage power in the following >> >> situations: >> >> - Core idle management >> >> - CPU hotplug >> >> - big.LITTLE migration models >> >> - System shutdown and reset >> >> >> >> It basically allows the kernel to offload these tasks to the firmware, >> >> and rely on common kernel side code. >> >> >> >> More importantly, it gives a way to ensure that CPUs enter the kernel >> >> at the appropriate exception level (ie HYP mode, to allow the use of >> >> the virtualization extensions), even across events like CPUs being >> >> powered off/on or suspended. >> >> >> >> The main idea here is to turn some of the existing u-boot code into a >> >> separate section that can live in secure RAM (or a reserved page of >> >> memory), containing a secure monitor that will implement the PSCI >> >> operations. This code will still be alive when u-boot is long gone, >> >> hence the need for a piece of memory that will not be touched by the >> >> OS. >> >> >> >> This patch series contains 4 parts: >> >> - the first four patches are just bug fixes >> >> - the next two refactor the HYP/non-secure code to allow relocation >> >> in secure memory >> >> - the next four contain the generic PSCI code and DT infrastructure >> >> - the last three implement the CPU_ON method of the Allwinner A20 (aka >> >> sun7i). >> >> >> >> I realize the A20 u-boot code is not upstream yet (BTW is anyone >> >> actively working on that?), but hopefully that should give a good idea >> >> of how things are structured so far. The patches are against the >> >> mainline u-boot tree as of today, merged with the sunxi u-boot tree >> >> of the day and the first 10 patches will directly apply to mainline >> >> u-boot. >> >> >> >> As for using this code, it goes like this: >> >> sun7i# ext2load mmc 0:1 0x40008000 zImage ; ext2load mmc 0:1 0x6000 >> >> sun7i-a20-cubietruck.dtb >> >> 2270120 bytes read in 117 ms (18.5 MiB/s) >> >> 9138 bytes read in 3 ms (2.9 MiB/s) >> >> sun7i# fdt addr 0x6000 ; fdt resize ; fdt set ethernet0 mac-address >> >> "[5a fe b0 07 b0 07]" >> >> sun7i# setenv bootargs console=ttyS0,115200 earlyprintk ip=dhcp >> >> root=/dev/nfs nfsroot=/backup/a20_root,tcp >> >> sun7i# bootz 0x40008000 - 0x6000 >> >> >> >> The kernel now boots in HYP mode, finds its secondary CPU without any >> >> SMP code present in the kernel, and runs KVM out of the box. >> >> I've been told the Xen/ARM guys managed to do the same fairly easily. >> >> >> >> This code has also been tested on a VExpress TC2, running KVM with all >> >> 5 CPUs, in order to make sure there was no obvious regression. >> >> >> >> I'm wildly cross-posting this patch series, including to lists I'm not >> >> subscribed to. Please keep me on Cc for any comment you may have. >> >> >> >> The code is also available at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/maz/u-boot.git wip/psci >> >> >> >> Cheers, >> >> >> >> M. >> > >> > Marc, I'm unclear what you want to do with this series. You mention >> > that its first 10 patches will apply to U-Boot, but I am not sure >> > whether you are just indicating that it is possible to apply them or >> > asking for these 10 patches to go in U-Boot mainline. Or is it >> > something else yet? >> >> Well, I rarely write code just for the sake of forking a critical >> project ;-) >> >> So let's be 100% explicit: Yes, I'm hereby asking for these patches to >> be merged. They offer a service that is required by the Linux kernel as >> well as Xen. They are in active use on the Allwinner sun7i platform as >> well as Versatile Express (though the later doesn't have a PSCI >> implementation). >> >> Now, given that two months have gone past without much comment other >> than the odd "hey, works great", I don't really know where to take that. >> >> Are you willing to review the patches? > > Well, I rarely ask about patches just for the sake of conversation. O:-) > > So yes, I am willing to review them -- and I suspect others are, as > well. Nobody commented the V3 series on the U-Boot list -- save for > Jon's comment about the series needing a rebase -- which could mean no > one here is unhappy with them... or they were discussed and possibly > acted upon on linux-sunxi, where the replies were redirected. I don't > follow linux-sunx closely, so I couldn't tell. :) No, so far there hasn't been much discussion, and people seem happy with it. I have a couple of fixes lined up, but nothing major. Also, a number of the patches are actually fixes that should really make it into the U-Boot tree, no matter if the PSCI code is merged or not. Some of them make th
Re: [U-Boot] [PATCH] tools: make imxheader size align on page size
Hi Stefan, On 16/04/2014 15:36, Stefan Agner wrote: >>> >>> Can you better explain this ? There is only one board in mainline with >>> vf610. CONFIG_SYS_TEXT_BASE is set to 0x3f008000. I cannot get the >>> offset in your example. Are you referring to NAND page ? But if the >>> header must be aligned with the NAND page, this is pretty bad because we >>> have to adjust the header depending on the selected NAND chip. I do not >>> see this limitation in the manual. >> I've not submitted my board yet, I altered it to use 0x3f400800 as >> CONFIG_SYS_TEXT_BASE. I just realize that a header length of 0x7fc >> doesn't fit with 0x3f400404 even though (that would be 0x3f44 if >> anything). But the mkimage utility reports >> Load Address: 3f400420 >> Entry Point: 3f400800 >> I'm a bit confused now, why is the header only 0x400 now? > > Ok I checked this again, the header total size is _not_ 0x7fc, thats > imximage_init_loadsize, which is the header size + flash load size > (0x400 for NAND). > > The header total size is 0x3fc (sizeof(imx_header_v2_t)) right now. This > patch would make alter it to be exactly 0x400. This renforces my suspect. Making the image bigger, it seems that the SOC loads more data as before. However, reading in the manual, the initial load image (what the SOC should load initially) is 4K (Table 19.37), and adding 4 bytes should have no influence. > > In case this discussion ends up adding this padding word, I will send a > new patch with correct numbers and better description. It is not clear what is the cause of the issue and then which is the solution. Adding the pad at the moment seems only a work-around for you. 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 v3 00/13] ARMv7: add PSCI support to u-boot
Hi Marc, On Wed, 16 Apr 2014 17:09:07 +0100, Marc Zyngier wrote: > On 16/04/14 15:45, Albert ARIBAUD wrote: > > Hi Marc, > > > > On Sat, 15 Feb 2014 13:36:24 +, Marc Zyngier > > wrote: > > > >> PSCI is an ARM standard that provides a generic interface that > >> supervisory software can use to manage power in the following > >> situations: > >> - Core idle management > >> - CPU hotplug > >> - big.LITTLE migration models > >> - System shutdown and reset > >> > >> It basically allows the kernel to offload these tasks to the firmware, > >> and rely on common kernel side code. > >> > >> More importantly, it gives a way to ensure that CPUs enter the kernel > >> at the appropriate exception level (ie HYP mode, to allow the use of > >> the virtualization extensions), even across events like CPUs being > >> powered off/on or suspended. > >> > >> The main idea here is to turn some of the existing u-boot code into a > >> separate section that can live in secure RAM (or a reserved page of > >> memory), containing a secure monitor that will implement the PSCI > >> operations. This code will still be alive when u-boot is long gone, > >> hence the need for a piece of memory that will not be touched by the > >> OS. > >> > >> This patch series contains 4 parts: > >> - the first four patches are just bug fixes > >> - the next two refactor the HYP/non-secure code to allow relocation > >> in secure memory > >> - the next four contain the generic PSCI code and DT infrastructure > >> - the last three implement the CPU_ON method of the Allwinner A20 (aka > >> sun7i). > >> > >> I realize the A20 u-boot code is not upstream yet (BTW is anyone > >> actively working on that?), but hopefully that should give a good idea > >> of how things are structured so far. The patches are against the > >> mainline u-boot tree as of today, merged with the sunxi u-boot tree > >> of the day and the first 10 patches will directly apply to mainline > >> u-boot. > >> > >> As for using this code, it goes like this: > >> sun7i# ext2load mmc 0:1 0x40008000 zImage ; ext2load mmc 0:1 0x6000 > >> sun7i-a20-cubietruck.dtb > >> 2270120 bytes read in 117 ms (18.5 MiB/s) > >> 9138 bytes read in 3 ms (2.9 MiB/s) > >> sun7i# fdt addr 0x6000 ; fdt resize ; fdt set ethernet0 mac-address > >> "[5a fe b0 07 b0 07]" > >> sun7i# setenv bootargs console=ttyS0,115200 earlyprintk ip=dhcp > >> root=/dev/nfs nfsroot=/backup/a20_root,tcp > >> sun7i# bootz 0x40008000 - 0x6000 > >> > >> The kernel now boots in HYP mode, finds its secondary CPU without any > >> SMP code present in the kernel, and runs KVM out of the box. > >> I've been told the Xen/ARM guys managed to do the same fairly easily. > >> > >> This code has also been tested on a VExpress TC2, running KVM with all > >> 5 CPUs, in order to make sure there was no obvious regression. > >> > >> I'm wildly cross-posting this patch series, including to lists I'm not > >> subscribed to. Please keep me on Cc for any comment you may have. > >> > >> The code is also available at: > >> git://git.kernel.org/pub/scm/linux/kernel/git/maz/u-boot.git wip/psci > >> > >> Cheers, > >> > >> M. > > > > Marc, I'm unclear what you want to do with this series. You mention > > that its first 10 patches will apply to U-Boot, but I am not sure > > whether you are just indicating that it is possible to apply them or > > asking for these 10 patches to go in U-Boot mainline. Or is it > > something else yet? > > Well, I rarely write code just for the sake of forking a critical > project ;-) > > So let's be 100% explicit: Yes, I'm hereby asking for these patches to > be merged. They offer a service that is required by the Linux kernel as > well as Xen. They are in active use on the Allwinner sun7i platform as > well as Versatile Express (though the later doesn't have a PSCI > implementation). > > Now, given that two months have gone past without much comment other > than the odd "hey, works great", I don't really know where to take that. > > Are you willing to review the patches? Well, I rarely ask about patches just for the sake of conversation. O:-) So yes, I am willing to review them -- and I suspect others are, as well. Nobody commented the V3 series on the U-Boot list -- save for Jon's comment about the series needing a rebase -- which could mean no one here is unhappy with them... or they were discussed and possibly acted upon on linux-sunxi, where the replies were redirected. I don't follow linux-sunx closely, so I couldn't tell. :) Still, I am trying to figure out the whole Allwinner nebula and see how things are supposed to work out between their various SoCs and make sure to avoid duplicate/incompatible effort (you're mentioning the A20, there seems to be A31 work underway too elsewhere). I am starting to wonder whether an ARM allwinner sub-repo might make sense. Tom, Wolfgang? > Thanks, > > M. Amicalement, -- Albert. ___ U-Boot mailing list
[U-Boot] [PATCH 2/2] usb: r8a66597: Fix initilization size of r8a66597 info, structure
Initialization of r8a66597 info structure is not enough. Because initilization was used size of pointer. This fixes that use size of r8a6659 info structure. Signed-off-by: Yasuhisa Umano --- drivers/usb/host/r8a66597-hcd.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index c58d2a9..8e82212 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -807,7 +807,7 @@ int usb_lowlevel_init(int index, enum usb_init_type init, void **controller) R8A66597_DPRINT("%s\n", __func__); - memset(r8a66597, 0, sizeof(r8a66597)); + memset(r8a66597, 0, sizeof(struct r8a66597)); r8a66597->reg = CONFIG_R8A66597_BASE_ADDR; disable_controller(r8a66597); -- 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] e1000: remove redundant assignment
On Wed, Apr 16, 2014 at 6:15 AM, David Müller wrote: > > Signed-off-by: David Mueller > Joe Hershberger Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] net: rename and refactor eth_rand_ethaddr() function
On Thu, Apr 17, 2014 at 3:00 AM, Masahiro Yamada wrote: > > Some functions in include/net.h are ported from > include/linux/etherdevice.h of Linux Kernel. > > For ex. > is_zero_ether_addr() > is_multicast_ether_addr() > is_broadcast_ether_addr() > is_valid_ether_addr(); > > So, we should use the same function name as Linux Kernel, > eth_rand_addr(), for consistency. > > Because eth_rand_addr() is impilemented as inline function, > it should not be surrounded by ifdef CONFIG_RANDOM_MACADDR. > > Signed-off-by: Masahiro Yamada Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/5] ARM: refactor start.S files
Hi Gerhard, On Wed, 16 Apr 2014 23:57:11 +0200, Gerhard Sittig wrote: > On Tue, 2014-04-15 at 16:13 +0200, Albert ARIBAUD wrote: > > > > [ ... deeply nested 'git send-email' thread ... ] > > May I suggest the following git config option? > > [sendemail] > chainreplyto = false > > This creates "shallow threads", and improves consumption on the > receivers' side, allowing to more quickly tell patches from > review feedback, and better follow the series' structure. > > Just a thought, not picking at this specific submission, only > following up when I saw one of those occurances (thus the list > reply, too, for the archives) ... Thanks for th tip! Setting added on my ~/.gitconfig. > virtually yours > Gerhard Sittig Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] blackfin: replace bfin_gen_rand_mac() with eth_random_addr()
bfin_gen_rand_mac() uses __DATE__ as the seed for random ethernet address. This is not good. In the first place, it should not be implemented as a Bfin-specific function. Use eth_random_addr() instead. Signed-off-by: Masahiro Yamada Cc: Sonic Zhang --- arch/blackfin/include/asm/net.h | 28 board/bct-brettl2/bct-brettl2.c | 3 +-- board/bf518f-ezbrd/bf518f-ezbrd.c | 3 +-- board/bf526-ezbrd/bf526-ezbrd.c | 3 +-- board/bf527-ezkit/bf527-ezkit.c | 3 +-- board/bf537-minotaur/bf537-minotaur.c | 3 +-- board/bf537-pnav/bf537-pnav.c | 3 +-- board/bf537-srv1/bf537-srv1.c | 3 +-- board/bf537-stamp/bf537-stamp.c | 3 +-- board/cm-bf527/cm-bf527.c | 3 +-- board/cm-bf537e/cm-bf537e.c | 3 +-- board/cm-bf537u/cm-bf537u.c | 3 +-- board/dnp5370/dnp5370.c | 3 +-- board/ip04/ip04.c | 3 +-- board/tcm-bf518/tcm-bf518.c | 3 +-- board/tcm-bf537/tcm-bf537.c | 3 +-- include/configs/bct-brettl2.h | 1 + include/configs/bf518f-ezbrd.h| 2 +- include/configs/bf526-ezbrd.h | 2 +- include/configs/bf527-ezkit.h | 2 +- include/configs/bf537-minotaur.h | 1 + include/configs/bf537-pnav.h | 2 +- include/configs/bf537-srv1.h | 2 +- include/configs/bf537-stamp.h | 2 +- include/configs/cm-bf527.h| 2 +- include/configs/cm-bf537e.h | 2 +- include/configs/cm-bf537u.h | 2 +- include/configs/dnp5370.h | 2 ++ include/configs/ip04.h| 1 + include/configs/tcm-bf518.h | 2 +- include/configs/tcm-bf537.h | 2 +- 31 files changed, 31 insertions(+), 69 deletions(-) delete mode 100644 arch/blackfin/include/asm/net.h diff --git a/arch/blackfin/include/asm/net.h b/arch/blackfin/include/asm/net.h deleted file mode 100644 index 97cb466..000 --- a/arch/blackfin/include/asm/net.h +++ /dev/null @@ -1,28 +0,0 @@ -/* - * net.h - misc Blackfin network helpers - * - * Copyright (c) 2008-2009 Analog Devices Inc. - * - * Licensed under the GPL-2 or later. - */ - -#ifndef __ASM_BFIN_RAND_MAC__ -#define __ASM_BFIN_RAND_MAC__ - -/* If the board does not have a real MAC assigned to it, then generate a - * locally administrated pseudo-random one based on CYCLES and compile date. - */ -static inline void bfin_gen_rand_mac(uchar *mac_addr) -{ - /* make something up */ - const char s[] = __DATE__; - size_t i; - u32 cycles; - for (i = 0; i < 6; ++i) { - asm("%0 = CYCLES;" : "=r" (cycles)); - mac_addr[i] = cycles ^ s[i]; - } - mac_addr[0] = (mac_addr[0] | 0x02) & ~0x01; /* make it local unicast */ -} - -#endif diff --git a/board/bct-brettl2/bct-brettl2.c b/board/bct-brettl2/bct-brettl2.c index de5b9ff..6be9b18 100644 --- a/board/bct-brettl2/bct-brettl2.c +++ b/board/bct-brettl2/bct-brettl2.c @@ -12,7 +12,6 @@ #include #include #include -#include #include #include #include @@ -33,7 +32,7 @@ int checkboard(void) static void board_init_enetaddr(uchar *mac_addr) { puts("Warning: Generating 'random' MAC address\n"); - bfin_gen_rand_mac(mac_addr); + eth_random_addr(mac_addr); eth_setenv_enetaddr("ethaddr", mac_addr); } diff --git a/board/bf518f-ezbrd/bf518f-ezbrd.c b/board/bf518f-ezbrd/bf518f-ezbrd.c index 09a2353..3a94a57 100644 --- a/board/bf518f-ezbrd/bf518f-ezbrd.c +++ b/board/bf518f-ezbrd/bf518f-ezbrd.c @@ -13,7 +13,6 @@ #include #include #include -#include #include #include #include @@ -48,7 +47,7 @@ static void board_init_enetaddr(uchar *mac_addr) if (!valid_mac) { puts("Warning: Generating 'random' MAC address\n"); - bfin_gen_rand_mac(mac_addr); + eth_random_addr(mac_addr); } eth_setenv_enetaddr("ethaddr", mac_addr); diff --git a/board/bf526-ezbrd/bf526-ezbrd.c b/board/bf526-ezbrd/bf526-ezbrd.c index 4695b11..368d6be 100644 --- a/board/bf526-ezbrd/bf526-ezbrd.c +++ b/board/bf526-ezbrd/bf526-ezbrd.c @@ -12,7 +12,6 @@ #include #include #include -#include #include DECLARE_GLOBAL_DATA_PTR; @@ -45,7 +44,7 @@ static void board_init_enetaddr(uchar *mac_addr) if (!valid_mac) { puts("Warning: Generating 'random' MAC address\n"); - bfin_gen_rand_mac(mac_addr); + eth_random_addr(mac_addr); } eth_setenv_enetaddr("ethaddr", mac_addr); diff --git a/board/bf527-ezkit/bf527-ezkit.c b/board/bf527-ezkit/bf527-ezkit.c index 211cf24..88e1869 100644 --- a/board/bf527-ezkit/bf527-ezkit.c +++ b/board/bf527-ezkit/bf527-ezkit.c @@ -13,7 +13,6 @@ #include #include #include -#include #include DECLARE_GLOBAL_DATA_PTR; @@ -47,7 +46,7 @@ static void board_init_enetaddr(uchar *mac_addr) if (!valid_mac) { puts("Warning: Gener
[U-Boot] [PATCH 0/5] Do not use __DATE__ and __TIME__ anymore
The aim of this series is to prohibit using __DATE__ and __TIME__. Currently they are used in two files. [1] arch/blackfin/include/asm/net.h Blackfin is using __DATE__ as the seed for the random ethernet address. This feature will be replaced with genericly-used eth_random_addr(). [2] fs/ubifs/super.c __DATE__ and __TIME__ are used in dbg_msg(), so simply droppred. Masahiro Yamada (5): rand: do not surround function declarations by #ifdef net: rename and refactor eth_rand_ethaddr() function blackfin: replace bfin_gen_rand_mac() with eth_random_addr() fs: ubifs: drop __DATE__ and __TIME__ kbuild: build with -Werror=date-time if the compiler supports it Makefile | 3 +++ arch/blackfin/include/asm/net.h | 28 --- board/bct-brettl2/bct-brettl2.c | 3 +-- board/bf518f-ezbrd/bf518f-ezbrd.c | 3 +-- board/bf526-ezbrd/bf526-ezbrd.c | 3 +-- board/bf527-ezkit/bf527-ezkit.c | 3 +-- board/bf537-minotaur/bf537-minotaur.c | 3 +-- board/bf537-pnav/bf537-pnav.c | 3 +-- board/bf537-srv1/bf537-srv1.c | 3 +-- board/bf537-stamp/bf537-stamp.c | 3 +-- board/buffalo/lsxl/lsxl.c | 2 +- board/cm-bf527/cm-bf527.c | 3 +-- board/cm-bf537e/cm-bf537e.c | 3 +-- board/cm-bf537u/cm-bf537u.c | 3 +-- board/dnp5370/dnp5370.c | 3 +-- board/ip04/ip04.c | 3 +-- board/tcm-bf518/tcm-bf518.c | 3 +-- board/tcm-bf537/tcm-bf537.c | 3 +-- drivers/net/dm9000x.c | 2 +- drivers/net/ftmac110.c| 2 +- fs/ubifs/super.c | 1 - include/common.h | 2 -- include/configs/bct-brettl2.h | 1 + include/configs/bf518f-ezbrd.h| 2 +- include/configs/bf526-ezbrd.h | 2 +- include/configs/bf527-ezkit.h | 2 +- include/configs/bf537-minotaur.h | 1 + include/configs/bf537-pnav.h | 2 +- include/configs/bf537-srv1.h | 2 +- include/configs/bf537-stamp.h | 2 +- include/configs/cm-bf527.h| 2 +- include/configs/cm-bf537e.h | 2 +- include/configs/cm-bf537u.h | 2 +- include/configs/dnp5370.h | 2 ++ include/configs/ip04.h| 1 + include/configs/tcm-bf518.h | 2 +- include/configs/tcm-bf537.h | 2 +- include/net.h | 36 ++- net/eth.c | 22 - 39 files changed, 56 insertions(+), 114 deletions(-) delete mode 100644 arch/blackfin/include/asm/net.h -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] rand: do not surround function declarations by #ifdef
Signed-off-by: Masahiro Yamada --- include/common.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/common.h b/include/common.h index cbd3c9e..49feac2 100644 --- a/include/common.h +++ b/include/common.h @@ -834,12 +834,10 @@ char *strmhz(char *buf, unsigned long hz); #include /* lib/rand.c */ -#if defined(CONFIG_LIB_RAND) || defined(CONFIG_LIB_HW_RAND) #define RAND_MAX -1U void srand(unsigned int seed); unsigned int rand(void); unsigned int rand_r(unsigned int *seedp); -#endif /* common/console.c */ intconsole_init_f(void); /* Before relocation; uses the serial stuff */ -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] kbuild: build with -Werror=date-time if the compiler supports it
This commit has been imported from Linux Kernel: commit fe7c36c7bde12190341722af69358e42171162f3 Author: Josh Triplett Date: Mon Dec 23 13:56:06 2013 -0800 Makefile: Build with -Werror=date-time if the compiler supports it GCC 4.9 and newer have a new warning -Wdate-time, which warns on any use of __DATE__, __TIME__, or __TIMESTAMP__, which would make the build non-deterministic. Now that the kernel does not use any of those macros, turn on -Werror=date-time if available, to keep it that way. The kernel already (optionally) records this information at build time in a single place; other kernel code should not duplicate that. Signed-off-by: Masahiro Yamada --- Makefile | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Makefile b/Makefile index 0191869..09a370f 100644 --- a/Makefile +++ b/Makefile @@ -578,6 +578,9 @@ KBUILD_AFLAGS += -Wa,-gstabs,-S endif endif +# Prohibit date/time macros, which would make the build non-deterministic +KBUILD_CFLAGS += $(call cc-option,-Werror=date-time) + ifneq ($(CONFIG_SYS_TEXT_BASE),) KBUILD_CPPFLAGS += -DCONFIG_SYS_TEXT_BASE=$(CONFIG_SYS_TEXT_BASE) endif -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] fs: ubifs: drop __DATE__ and __TIME__
__DATE__ and __TIME__ should not be used anymore. Drop the debug message using them. Signed-off-by: Masahiro Yamada --- fs/ubifs/super.c | 1 - 1 file changed, 1 deletion(-) diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c index 67f115f..748ab67 100644 --- a/fs/ubifs/super.c +++ b/fs/ubifs/super.c @@ -734,7 +734,6 @@ static int mount_ubifs(struct ubifs_info *c) ubifs_msg("reserved for root: %llu bytes (%llu KiB)", c->report_rp_size, c->report_rp_size >> 10); - dbg_msg("compiled on: " __DATE__ " at " __TIME__); dbg_msg("min. I/O unit size: %d bytes", c->min_io_size); dbg_msg("LEB size:%d bytes (%d KiB)", c->leb_size, c->leb_size >> 10); -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] net: rename and refactor eth_rand_ethaddr() function
Some functions in include/net.h are ported from include/linux/etherdevice.h of Linux Kernel. For ex. is_zero_ether_addr() is_multicast_ether_addr() is_broadcast_ether_addr() is_valid_ether_addr(); So, we should use the same function name as Linux Kernel, eth_rand_addr(), for consistency. Because eth_rand_addr() is impilemented as inline function, it should not be surrounded by ifdef CONFIG_RANDOM_MACADDR. Signed-off-by: Masahiro Yamada --- board/buffalo/lsxl/lsxl.c | 2 +- drivers/net/dm9000x.c | 2 +- drivers/net/ftmac110.c| 2 +- include/net.h | 36 +++- net/eth.c | 22 -- 5 files changed, 22 insertions(+), 42 deletions(-) diff --git a/board/buffalo/lsxl/lsxl.c b/board/buffalo/lsxl/lsxl.c index eca1683..659a124 100644 --- a/board/buffalo/lsxl/lsxl.c +++ b/board/buffalo/lsxl/lsxl.c @@ -231,7 +231,7 @@ static void rescue_mode(void) printf("Entering rescue mode..\n"); #ifdef CONFIG_RANDOM_MACADDR if (!eth_getenv_enetaddr("ethaddr", enetaddr)) { - eth_random_enetaddr(enetaddr); + eth_random_addr(enetaddr); if (eth_setenv_enetaddr("ethaddr", enetaddr)) { printf("Failed to set ethernet address\n"); set_led(LED_ALARM_BLINKING); diff --git a/drivers/net/dm9000x.c b/drivers/net/dm9000x.c index b68d808..4de9d41 100644 --- a/drivers/net/dm9000x.c +++ b/drivers/net/dm9000x.c @@ -345,7 +345,7 @@ static int dm9000_init(struct eth_device *dev, bd_t *bd) if (!is_valid_ether_addr(dev->enetaddr)) { #ifdef CONFIG_RANDOM_MACADDR printf("Bad MAC address (uninitialized EEPROM?), randomizing\n"); - eth_random_enetaddr(dev->enetaddr); + eth_random_addr(dev->enetaddr); printf("MAC: %pM\n", dev->enetaddr); #else printf("WARNING: Bad MAC address (uninitialized EEPROM?)\n"); diff --git a/drivers/net/ftmac110.c b/drivers/net/ftmac110.c index 8eee272..98c4f09 100644 --- a/drivers/net/ftmac110.c +++ b/drivers/net/ftmac110.c @@ -425,7 +425,7 @@ int ftmac110_initialize(bd_t *bis) dev->recv = ftmac110_recv; if (!eth_getenv_enetaddr_by_index("eth", card_nr, dev->enetaddr)) - eth_random_enetaddr(dev->enetaddr); + eth_random_addr(dev->enetaddr); /* allocate tx descriptors (it must be 16 bytes aligned) */ chip->txd = dma_alloc_coherent( diff --git a/include/net.h b/include/net.h index 0802fad..735b0b9 100644 --- a/include/net.h +++ b/include/net.h @@ -130,23 +130,6 @@ extern int eth_setenv_enetaddr(char *name, const uchar *enetaddr); extern int eth_getenv_enetaddr_by_index(const char *base_name, int index, uchar *enetaddr); -#ifdef CONFIG_RANDOM_MACADDR -/* - * The u-boot policy does not allow hardcoded ethernet addresses. Under the - * following circumstances a random generated address is allowed: - * - in emergency cases, where you need a working network connection to set - *the ethernet address. - *Eg. you want a rescue boot and don't have a serial port to access the - *CLI to set environment variables. - * - * In these cases, we generate a random locally administered ethernet address. - * - * Args: - * enetaddr - returns 6 byte hardware address - */ -extern void eth_random_enetaddr(uchar *enetaddr); -#endif - extern int usb_eth_initialize(bd_t *bi); extern int eth_init(bd_t *bis);/* Initialize the device */ extern int eth_send(void *packet, int length);/* Send a packet */ @@ -674,6 +657,25 @@ static inline int is_valid_ether_addr(const u8 *addr) return !is_multicast_ether_addr(addr) && !is_zero_ether_addr(addr); } +/** + * eth_random_addr - Generate software assigned random Ethernet address + * @addr: Pointer to a six-byte array containing the Ethernet address + * + * Generate a random Ethernet address (MAC) that is not multicast + * and has the local assigned bit set. + */ +static inline void eth_random_addr(uchar *addr) +{ + int i; + unsigned int seed = get_timer(0); + + for (i = 0; i < 6; i++) + addr[i] = rand_r(&seed); + + addr[0] &= 0xfe;/* clear multicast bit */ + addr[0] |= 0x02;/* set local assignment bit (IEEE802) */ +} + /* Convert an IP address to a string */ extern void ip_to_string(IPaddr_t x, char *s); diff --git a/net/eth.c b/net/eth.c index 32bd10c..99386e3 100644 --- a/net/eth.c +++ b/net/eth.c @@ -63,28 +63,6 @@ static int eth_mac_skip(int index) return ((skip_state = getenv(enetvar)) != NULL); } -#ifdef CONFIG_RANDOM_MACADDR -void eth_random_enetaddr(uchar *enetaddr) -{ - uint32_t rval; - - srand(get_timer(0)); - - rval = rand(); - enetaddr[0] = rval & 0xff; - enetaddr[1] = (rval >> 8) & 0xff; - enetaddr[2] = (rval >> 16) & 0xff; - - rva
[U-Boot] [PATCH 1/2] usb: r8a66597: Fix initialization hub that using, R8A66597_MAX_ROOT_HUB
This driver is processed as two USB hub despite one. The number of root hub is defined in R8A66597_MAX_ROOT_HUB. This fixes that register is accessed by using the definition of R8A66597_MAX_ROOT_HUB. Signed-off-by: Yasuhisa Umano --- drivers/usb/host/r8a66597-hcd.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/host/r8a66597-hcd.c b/drivers/usb/host/r8a66597-hcd.c index dfe5423..c58d2a9 100644 --- a/drivers/usb/host/r8a66597-hcd.c +++ b/drivers/usb/host/r8a66597-hcd.c @@ -164,8 +164,8 @@ static int enable_controller(struct r8a66597 *r8a66597) r8a66597_bset(r8a66597, INTL, SOFCFG); r8a66597_write(r8a66597, 0, INTENB0); - r8a66597_write(r8a66597, 0, INTENB1); - r8a66597_write(r8a66597, 0, INTENB2); + for (port = 0; port < R8A66597_MAX_ROOT_HUB; port++) + r8a66597_write(r8a66597, 0, get_intenb_reg(port)); r8a66597_bset(r8a66597, CONFIG_R8A66597_ENDIAN & BIGEND, CFIFOSEL); r8a66597_bset(r8a66597, CONFIG_R8A66597_ENDIAN & BIGEND, D0FIFOSEL); -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc85xx: Add deep sleep support on T104xRDB
From: Tang Yuantian Add deep sleep support on T104xRDB platforms. Signed-off-by: Tang Yuantian --- board/freescale/t104xrdb/t104xrdb.c | 10 ++ include/configs/T104xRDB.h | 4 2 files changed, 14 insertions(+) diff --git a/board/freescale/t104xrdb/t104xrdb.c b/board/freescale/t104xrdb/t104xrdb.c index b48133a..fb5b849 100644 --- a/board/freescale/t104xrdb/t104xrdb.c +++ b/board/freescale/t104xrdb/t104xrdb.c @@ -17,6 +17,7 @@ #include #include #include +#include #include "t104xrdb.h" #include "cpld.h" @@ -104,3 +105,12 @@ void ft_board_setup(void *blob, bd_t *bd) fdt_fixup_fman_ethernet(blob); #endif } + +#ifdef CONFIG_DEEP_SLEEP +void board_mem_sleep_setup(void) +{ + /* Disable MCKE isolation */ + gpio_set_value(2, 0); + udelay(1); +} +#endif diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h index eaaf37d..0159b97 100644 --- a/include/configs/T104xRDB.h +++ b/include/configs/T104xRDB.h @@ -25,6 +25,10 @@ #define CONFIG_SYS_BOOK3E_HV /* Category E.HV supported */ #define CONFIG_MP /* support multiple processors */ +/* support deep sleep */ +#define CONFIG_DEEP_SLEEP +#define CONFIG_SILENT_CONSOLE + #ifndef CONFIG_SYS_TEXT_BASE #define CONFIG_SYS_TEXT_BASE 0xeff4 #endif -- 1.8.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mpc85xx: Add deep sleep support on T1040QDS
From: Tang Yuantian Add deep sleep support on T1040QDS platform. Signed-off-by: Tang Yuantian --- board/freescale/t1040qds/t1040qds.c | 12 include/configs/T1040QDS.h | 4 2 files changed, 16 insertions(+) diff --git a/board/freescale/t1040qds/t1040qds.c b/board/freescale/t1040qds/t1040qds.c index 3dec447..f1d7cde 100644 --- a/board/freescale/t1040qds/t1040qds.c +++ b/board/freescale/t1040qds/t1040qds.c @@ -18,6 +18,7 @@ #include #include #include +#include #include "../common/qixis.h" #include "t1040qds.h" @@ -245,3 +246,14 @@ int board_need_mem_reset(void) { return 1; } + +#ifdef CONFIG_DEEP_SLEEP +void board_mem_sleep_setup(void) +{ + /* does not provide HW signals for power management */ + QIXIS_WRITE(pwr_ctl[1], (QIXIS_READ(pwr_ctl[1]) & ~0x2)); + /* Disable MCKE isolation */ + gpio_set_value(2, 0); + udelay(1); +} +#endif diff --git a/include/configs/T1040QDS.h b/include/configs/T1040QDS.h index 030ea7e..745a2f2 100644 --- a/include/configs/T1040QDS.h +++ b/include/configs/T1040QDS.h @@ -43,6 +43,10 @@ #define CONFIG_SYS_BOOK3E_HV /* Category E.HV supported */ #define CONFIG_MP /* support multiple processors */ +/* support deep sleep */ +#define CONFIG_DEEP_SLEEP +#define CONFIG_SILENT_CONSOLE + #ifndef CONFIG_SYS_TEXT_BASE #define CONFIG_SYS_TEXT_BASE 0xeff4 #endif -- 1.8.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] mpc85xx/t104x: Add deep sleep framework support
From: Tang Yuantian When T104x soc wakes up from deep sleep, control is passed to the primary core that starts executing uboot. After re-initialized some IP blocks, like DDRC, kernel will take responsibility to continue to restore environment it leaves before. Signed-off-by: Tang Yuantian --- based on: git://git.denx.de/u-boot-mpc85xx.git branch: next tested on: t1040qds and t1040rdb platforms. v4: - refactor the framework. In the new patch, the entry is placed just after DDRC's initialization when resume. v3: - fix out-of-tree compile warning v2: - added explaination for CONFIG_DEEP_SLEEP - fixed some issues README | 4 +++ arch/powerpc/cpu/mpc85xx/cpu_init.c | 8 ++ arch/powerpc/lib/board.c| 16 drivers/ddr/fsl/mpc85xx_ddr_gen3.c | 52 ++--- include/fsl_ddr_sdram.h | 4 +++ 5 files changed, 80 insertions(+), 4 deletions(-) diff --git a/README b/README index 83a1b25..31e37cb 100644 --- a/README +++ b/README @@ -431,6 +431,10 @@ The following options need to be configured: This CONFIG is defined when the CPC is configured as SRAM at the time of U-boot entry and is required to be re-initialized. + CONFIG_DEEP_SLEEP + Inidcates this SoC supports deep sleep feature. If deep sleep is + supported, core will start to execute uboot when wakes up. + - Generic CPU options: CONFIG_SYS_BIG_ENDIAN, CONFIG_SYS_LITTLE_ENDIAN diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c index 941c20e..867abb6 100644 --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c @@ -350,6 +350,7 @@ void cpu_init_f (void) extern void m8560_cpm_reset (void); #ifdef CONFIG_SYS_DCSRBAR_PHYS ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR); + gd = (gd_t *)(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET); #endif #if defined(CONFIG_SECURE_BOOT) struct law_entry law; @@ -414,6 +415,13 @@ void cpu_init_f (void) in_be32(&gur->dcsrcr); #endif +#ifdef CONFIG_SYS_DCSRBAR_PHYS +#ifdef CONFIG_DEEP_SLEEP + /* disable the console if boot from deep sleep */ + if (in_be32(&gur->scrtsr[0]) & (1 << 3)) + gd->flags |= GD_FLG_SILENT | GD_FLG_DISABLE_CONSOLE; +#endif +#endif #ifdef CONFIG_SYS_FSL_ERRATUM_A007212 fsl_erratum_a007212_workaround(); #endif diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c index f86c6f3..8b03d3a 100644 --- a/arch/powerpc/lib/board.c +++ b/arch/powerpc/lib/board.c @@ -343,6 +343,13 @@ void board_init_f(ulong bootflag) #ifdef CONFIG_PRAM ulong reg; #endif +#ifdef CONFIG_DEEP_SLEEP + const ccsr_gur_t *gur = (void __iomem *)(CONFIG_SYS_MPC85xx_GUTS_ADDR); + struct ccsr_scfg *scfg = (void *)CONFIG_SYS_MPC85xx_SCFG; + u32 start_addr; + typedef void (*func_t)(void); + func_t kernel_resume; +#endif /* Pointer is writable since we allocated a register for it */ gd = (gd_t *) (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET); @@ -360,6 +367,15 @@ void board_init_f(ulong bootflag) if ((*init_fnc_ptr) () != 0) hang(); +#ifdef CONFIG_DEEP_SLEEP + /* Jump to kernel in deep sleep case */ + if (in_be32(&gur->scrtsr[0]) & (1 << 3)) { + start_addr = in_be32(&scfg->sparecr[1]); + kernel_resume = (func_t)start_addr; + kernel_resume(); + } +#endif + #ifdef CONFIG_POST post_bootmode_init(); post_run(NULL, POST_ROM | post_bootmode_get(NULL)); diff --git a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c index c805086..4d5572e 100644 --- a/drivers/ddr/fsl/mpc85xx_ddr_gen3.c +++ b/drivers/ddr/fsl/mpc85xx_ddr_gen3.c @@ -15,6 +15,7 @@ #error Invalid setting for CONFIG_CHIP_SELECTS_PER_CTRL #endif +DECLARE_GLOBAL_DATA_PTR; /* * regs has the to-be-set values for DDR controller registers @@ -43,6 +44,16 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs, u32 save1, save2; #endif +#ifdef CONFIG_DEEP_SLEEP + const ccsr_gur_t *gur = (void __iomem *)(CONFIG_SYS_MPC85xx_GUTS_ADDR); + bool sleep_flag = 0; +#endif + +#ifdef CONFIG_DEEP_SLEEP + if (in_be32(&gur->scrtsr[0]) & (1 << 3)) + sleep_flag = 1; +#endif + switch (ctrl_num) { case 0: ddr = (void *)CONFIG_SYS_FSL_DDR_ADDR; @@ -119,7 +130,13 @@ void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs, out_be32(&ddr->timing_cfg_0, regs->timing_cfg_0); out_be32(&ddr->timing_cfg_1, regs->timing_cfg_1); out_be32(&ddr->timing_cfg_2, regs->timing_cfg_2); - out_be32(&ddr->sdram_cfg_2, regs->ddr_sdram_cfg_2); +#ifdef CONFIG_DEEP_SLEEP + if (sleep_flag) + out
Re: [U-Boot] [PATCH 3/6] PPC: 85xx: Remove IVOR reset
> Am 17.04.2014 um 02:46 schrieb York Sun : > >> On 04/11/2014 08:09 AM, Alexander Graf wrote: >> diff --git a/nand_spl/board/freescale/mpc8572ds/Makefile >> b/nand_spl/board/freescale/mpc8572ds/Makefile >> index c639b12..c58b7a4 100644 >> --- a/nand_spl/board/freescale/mpc8572ds/Makefile >> +++ b/nand_spl/board/freescale/mpc8572ds/Makefile >> @@ -78,11 +78,6 @@ $(obj)/resetvec.S: >>@rm -f $@ >>ln -s $(srctree)/$(CPUDIR)/resetvec.S $@ >> >> -$(obj)/fixed_ivor.S: >> -@rm -f $@ >> -ln -sf $(srctree)/arch/powerpc/cpu/mpc85xx/fixed_ivor.S $@ >> - >> -$(obj)/start.S: $(obj)/fixed_ivor.S >>@rm -f $@ >>ln -sf $(srctree)/arch/powerpc/cpu/mpc85xx/start.S $@ > > You forgot to add back "$(obj)/start.S:". Don't send a new patch. I will fix > it > when I apply it. Oops :). Thanks a lot! Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot