Re: [U-Boot] [PATCH] fsl_i2c: Add write-then-read transaction interface for I2C slave
-Original Message-
From: Sun York-R58495
Sent: Saturday, March 08, 2014 3:10 AM
To: Leekha Shaveta-B20052; u-boot@lists.denx.de
Cc: Aggrwal Poonam-B10812; Aggrwal Poonam-B10812
Subject: Re: [PATCH] fsl_i2c: Add write-then-read transaction interface for I2C
slave
On 03/03/2014 12:58 AM, Shaveta Leekha wrote:
Most of the I2C slaves support accesses in the typical style
viz.read/write series of bytes at particular address offset.
These transactions are currently supportd in the i2c driver using
i2c_read and i2c_write APIs. I2C EEPROMs, RTC, etc fall in this
category.
The transactions look like:
START:Address:Tx:Offset:RESTART:Address[0..4]:Tx/Rx:data[0..n]:STOP
However there are certain devices which support accesses in terms of
the transactions as follows:
START:Address:Tx:Txdata[0..n1]:Clock_stretching:
RESTART:Address:Rx:data[0..n2]
The Txdata is typically a command and some associated data, similarly
Rxdata could be command status plus some data received as a response
to the command sent.
i2c_write_read() function provides support for such transactions
(multiple bytes write followed by read)
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
Signed-off-by: Shaveta Leekha shav...@freescale.com
---
drivers/i2c/fsl_i2c.c | 64 ++-
drivers/i2c/i2c_core.c |7 +
include/i2c.h | 19 ++---
3 files changed, 78 insertions(+), 12 deletions(-)
snip
diff --git a/include/i2c.h b/include/i2c.h index 1b4078e..7bac20a
100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -65,6 +65,9 @@ struct i2c_adapter {
int (*write)(struct i2c_adapter *adap, uint8_t chip,
uint addr, int alen, uint8_t *buffer,
int len);
+ int (*write_read)(struct i2c_adapter *adap, uint8_t chip,
+ uint8_t *wbuffer, int wlength, uint8_t *rbuffer,
+ int rlength);
uint(*set_bus_speed)(struct i2c_adapter *adap,
uint speed);
int speed;
@@ -75,13 +78,14 @@ struct i2c_adapter {
char*name;
};
-#define U_BOOT_I2C_MKENT_COMPLETE(_init, _probe, _read, _write, \
+#define U_BOOT_I2C_MKENT_COMPLETE(_init, _probe, _read, _write,
+_write_read, \
_set_speed, _speed, _slaveaddr, _hwadapnr, _name) \
{ \
.init = _init, \
.probe = _probe, \
.read = _read, \
.write = _write, \
+ .write_read = _write_read, \
.set_bus_speed = _set_speed, \
.speed = _speed, \
.slaveaddr = _slaveaddr, \
@@ -90,10 +94,11 @@ struct i2c_adapter {
.name = #_name \
};
-#define U_BOOT_I2C_ADAP_COMPLETE(_name, _init, _probe, _read, _write, \
- _set_speed, _speed, _slaveaddr, _hwadapnr) \
- ll_entry_declare(struct i2c_adapter, _name, i2c) = \
- U_BOOT_I2C_MKENT_COMPLETE(_init, _probe, _read, _write, \
+#define U_BOOT_I2C_ADAP_COMPLETE(_name, _init, _probe, _read, _write,
\
+ _write_read, _set_speed, _speed, _slaveaddr,\
+ _hwadapnr) \
+ ll_entry_declare(struct i2c_adapter, _name, i2c) = \
+ U_BOOT_I2C_MKENT_COMPLETE(_init, _probe, _read, _write,
+_write_read, \
_set_speed, _speed, _slaveaddr, _hwadapnr, _name);
struct i2c_adapter *i2c_get_adapter(int index); @@ -237,6 +242,8 @@
int i2c_read(uint8_t chip, unsigned int addr, int alen,
int i2c_write(uint8_t chip, unsigned int addr, int alen,
uint8_t *buffer, int len);
+int i2c_write_read(uint8_t chip, uchar *wbuffer, int wlen, uchar *rbuffer,
+ int rlen);
/*
* Utility routines to read/write registers.
@@ -302,6 +309,8 @@ int i2c_probe(uchar chip);
*/
int i2c_read(uchar chip, uint addr, int alen, uchar *buffer, int
len); int i2c_write(uchar chip, uint addr, int alen, uchar *buffer,
int len);
+int i2c_write_read(uchar chip, uchar *wbuffer, int wlen, uchar *rbuffer,
+ int rlen);
You need to be careful when changing the header file. If you compile other
platforms, you will see the error. Try ./MAKEALL -a powerpc. I don't know how
bad you broke other architectures.
[Leekha Shaveta-B20052] Agree. This may break i2c driver code for other
architectures.
For one of the I2C device for B4 platform, the read/write transaction cycle is
little different from
Other conventional I2C devices like EEPROM, PCA etc.
As its not right to change the header
Re: [U-Boot] [PATCH v3 4/8] rsa: add sha256-rsa2048 algorithm
Hello Simon,
Am 09.03.2014 06:33, schrieb Simon Glass:
Hi Heiko,
On 3 March 2014 04:19, Heiko Schocherh...@denx.de wrote:
based on patch from andr...@oetken.name:
http://patchwork.ozlabs.org/patch/294318/
commit message:
I currently need support for rsa-sha256 signatures in u-boot and found out that
the code for signatures is not very generic. Thus adding of different
hash-algorithms for rsa-signatures is not easy to do without copy-pasting the
rsa-code. I attached a patch for how I think it could be better and included
support for rsa-sha256. This is a fast first shot.
aditionally work:
- removed checkpatch warnings
- removed compiler warnings
- rebased against current head
Signed-off-by: Heiko Schocherh...@denx.de
Cc: andr...@oetken.name
Cc: Simon Glasss...@chromium.org
This looks good to me. However, when running it I hit this crash?
O=b/sandbox test/vboot/vboot_test.sh
Simple Verified Boot Test
=
Please see doc/uImage.FIT/verified-boot.txt for more information
/home/sjg/c/src/third_party/u-boot/files/b/sandbox/tools/mkimage -D -I
dts -O dtb -p 2000
Build keys
do sha1 test
Build FIT with signed images
Test Verified Boot Run: unsigned signatures:: OK
Sign images
Test Verified Boot Run: signed images: OK
Build FIT with signed configuration
Test Verified Boot Run: unsigned config: OK
Sign images
Test Verified Boot Run: signed config: OK
check signed config on the host
*** buffer overflow detected ***:
/home/sjg/c/src/third_party/u-boot/files/b/sandbox/tools/fit_check_sign
terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f07c7ba9f47]
/lib/x86_64-linux-gnu/libc.so.6(+0x109e40)[0x7f07c7ba8e40]
[...]
[vsyscall]
test/vboot/vboot_test.sh: line 65: 7597 Aborted (core
dumped) ${fit_check_sign} -f test.fit -k sandbox-u-boot.dtb ${tmp}
Verified boot key check on host failed, output follows:
Do you see this? Presumably not - I can dig a bit if you like?
No, I do not see this crash ... Hmm... you reply this error to the
4/8 patch of this series, but fit_check_sign is introduced in the
8/8 ... did you tried with all 8 patches applied?
Just tested with current head of U-Boot and I see no error:
commit 247161b8160fc699b0a517f081220bb50bc502a8
Merge: d57d60c 96ac18c
Author: Tom Rini tr...@ti.com
Date: Fri Mar 7 20:54:22 2014 -0500
Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx
$ O=sandbox ./test/vboot/vboot_test.sh
Simple Verified Boot Test
=
Please see doc/uImage.FIT/verified-boot.txt for more information
/home/hs/ids/u-boot/sandbox/tools/mkimage -D -I dts -O dtb -p 2000
Build keys
do sha1 test
Build FIT with signed images
Test Verified Boot Run: unsigned signatures:: OK
Sign images
Test Verified Boot Run: signed images: OK
Build FIT with signed configuration
Test Verified Boot Run: unsigned config: OK
Sign images
Test Verified Boot Run: signed config: OK
check signed config on the host
OK
Test Verified Boot Run: signed config: OK
Test Verified Boot Run: signed config with bad hash: OK
do sha256 test
Build FIT with signed images
Test Verified Boot Run: unsigned signatures:: OK
Sign images
Test Verified Boot Run: signed images: OK
Build FIT with signed configuration
Test Verified Boot Run: unsigned config: OK
Sign images
Test Verified Boot Run: signed config: OK
check signed config on the host
OK
Test Verified Boot Run: signed config: OK
Test Verified Boot Run: signed config with bad hash: OK
Test passed
pollux:u-boot hs [temp] $
Can you try with current head again?
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] video: Add support for TI's AM335x LCD-Controller
Hello Hannes,
Am 07.03.2014 11:28, schrieb Hannes Petermaier:
Hi Heiko,
Heiko Schocher wrote:
Hello Hannes,
Am 06.03.2014 15:24, schrieb Hannes Petermaier:
On 2014-03-06 14:58, Heiko Schocher wrote:
Hello Hannes,
Am 06.03.2014 14:39, schrieb Hannes Petermaier:
- Adds support for a minimal framebuffer driver of TI's AM335x SoC
to be compatible with Wolfgang Denk's LCD-Framework (CONFIG_LCD,
common/lcd.c)
Signed-off-by: Hannes Petermaieroe5...@oevsv.at
---
drivers/video/Makefile | 1 +
drivers/video/am335x-fb.c | 169
+
drivers/video/am335x-fb.h | 67 ++
3 files changed, 237 insertions(+)
create mode 100644 drivers/video/am335x-fb.c
create mode 100644 drivers/video/am335x-fb.h
Why you cannot use:
u-boot:drivers/video/da8xx-fb.c ?
bye,
Heiko
Hi Heiko,
for my opinion this clone of the linux-driver is very overloaded and
difficult to use/configure.
With the words 'small-is-beautiful' and 'keep-it-simple' i've wrote a
few lines which do the minimum:
- configure raster-controller
- setup DMA
- powerON Display
maybe we can use the small-version in other projects too.
Why is it difficult to use/configure the existing driver?
Look for example into the board/siemens/pxm2/board.c board, which uses
this driver. You have to define:
static struct da8xx_panel lcd_panels[]
static const struct display_panel disp_panel
static const struct lcd_ctrl_config lcd_cfg
and call da8xx_video_init(lcd_panels[0],lcd_cfg, lcd_cfg.bpp);
Thats all ...
i've looked around again for using the da8xx-fb driver and found another
detail which motivated me for writing a new instance.
--
par-vram_virt = malloc(par-vram_size);
par-vram_phys = (dma_addr_t) par-vram_virt;
debug(Requesting 0x%x bytes for framebuffer at 0x%x\n,
(unsigned int)par-vram_size,
(unsigned int)par-vram_virt);
if (!par-vram_virt) {
printf(GLCD: malloc for frame buffer failed\n);
goto err_release_fb;
}
gd-fb_base = (int)par-vram_virt;
--
da8xx-fb.c does allocate a new framebuffer by itself.
But in my case lcd-framework allready has reserved memory (on top of ram)
for framebuffer usage and i want use this memory from lcd-framework for
two reasons:
- don't waste memory
- have this memory really on top of ram to give the following OS (in my
case vxWorks) a pointer where it have to write Video-data.
maybe there are other possibilites to achieve this.
any ideas ?
Maybe you can introduce a common function like this? :
void *get_vram(size_t size)
{
if (gd-fb_base) {
if (gd-fb_size == size)
return gd-fb_base;
printf(fb size does not match\n);
} else {
void *ret = malloc(size);
if (ret) {
gd-fb_base = ret;
gd-fb_size = size;
}
return ret
}
return NULL;
}
(gd-fb_size is a new variable ...)
and use in your driver only:
par-vram_virt = get_vram(par-vram_size);
or, just only check in the driver, if gd-fb_base has a value, and
if so, do not malloc the vram ...
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: Handle .gnu.hash section in ldscripts
Hi Andreas, On Sun, 09 Mar 2014 21:52:44 +0100, Andreas Färber afaer...@suse.de wrote: Hi, Am 09.03.2014 21:34, schrieb Albert ARIBAUD: On Sun, 09 Mar 2014 21:22:34 +0100, Andreas Färber afaer...@suse.de wrote: Am 09.03.2014 21:05, schrieb Albert ARIBAUD: On Mon, 3 Mar 2014 08:00:52 +0100, Albert ARIBAUD albert.u.b...@aribaud.net wrote: On Sun, 02 Mar 2014 23:00:19 +0100, Andreas Färber afaer...@suse.de wrote: Am 02.03.2014 21:57, schrieb Andreas Färber: Am 02.03.2014 20:15, schrieb Albert ARIBAUD: On Sun, 02 Mar 2014 18:57:14 +0100, Andreas Färber afaer...@suse.de wrote: Am 22.02.2014 14:27, schrieb Albert ARIBAUD: On Thu, 13 Feb 2014 12:39:07 +0100, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Can you point me to the toolchain you are using, and if you are not building mainline code, can you make this code available to me somehow? [...] Our latest GCC 4.8.2 can be found here: https://build.opensuse.org/package/show/openSUSE:Factory:ARM/gcc48 Matching binutils 2.24 are here: https://build.opensuse.org/package/show/openSUSE:Factory:ARM/binutils Our latest U-Boot tarball and patches: https://build.opensuse.org/package/show/Base:System/u-boot Build logs can be found in the u-boot-* packages in the same project, with underscores stripped, e.g.: https://build.opensuse.org/package/show/Base:System/u-boot-am335xevm Thanks for your reply. Apparently, the problem does not appear for the boards in mainline U-Boot which I listed above with the source code from our v2014.01 tag and using gcc 4.8.1 from Linaro. I can install 4.8.2, but meanwhile, can you try to build v2014.01 for these boards with your setup? am335x_evm colibri_t20_iris highbank mx53loco omap3_beagle omap4_panda paz00 rpi_b I have commented out the patch in: https://build.opensuse.org/project/show/home:a_faerber:branches:Base:System While there are apparently frequent rebuilds scheduled ATM, it seemed like the colibri_t20_iris config intermittently built OK without it. Maybe some gcc 4.8 stable branch update [1] resolved it ... will keep an eye on the build status to confirm. If everything builds, I'm happy. Nah, still fails without the patch: [ 178s] gcc -E -g -Os -ffunction-sections -fdata-sections -fno-common -ffixed-r9 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x0010E000 -I/home/abuild/rpmbuild/BUILD/u-boot-2014.01/include -I/home/abuild/rpmbuild/BUILD/u-boot-2014.01/arch/arm/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.8/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mno-thumb-interwork -mabi=aapcs-linux -mword-relocations -march=armv7-a -include /home/abuild/rpmbuild/BUILD/u-boot-2014.01/include/u-boot/u-boot.lds.h -DCPUDIR=arch/arm/cpu/armv7 -ansi -D__ASSEMBLY__ -P - /home/abuild/rpmbuild/BUILD/u-boot-2014.01/arch/arm/cpu/u-boot.lds u-boot.lds [ 178s] cd /home/abuild/rpmbuild/BUILD/u-boot-2014.01 ld.bfd -pie -T u-boot.lds --gc-sections -Bstatic -Ttext 0x0010E000 arch/arm/cpu/armv7/start.o --start-group arch/arm/cpu/armv7/built-in.o arch/arm/cpu/armv7/tegra20/built-in.o arch/arm/cpu/built-in.o arch/arm/lib/built-in.o board/toradex/colibri_t20_iris/built-in.o common/built-in.o disk/built-in.o drivers/built-in.o drivers/dma/built-in.o drivers/gpio/built-in.o drivers/i2c/built-in.o drivers/input/built-in.o drivers/mmc/built-in.o drivers/mtd/built-in.o drivers/mtd/nand/built-in.o drivers/mtd/onenand/built-in.o drivers/mtd/spi/built-in.o drivers/net/built-in.o drivers/net/phy/built-in.o drivers/pci/built-in.o drivers/power/battery/built-in.o drivers/power/built-in.o drivers/power/fuel_gauge/built-in.o drivers/power/mfd/built-in.o drivers/power/pmic/built-in.o drivers/serial/built-in.o drivers/spi/built-in.o drivers/usb/eth/built-in.o drivers/usb/gadget/built-in.o drivers/usb/host/built-in.o drivers/usb/musb-new/built-in.o drivers/usb/musb/built-in.o drivers/usb/phy/built-in.o drivers/usb/ulpi/built-in.o fs/built-in.o lib/built-in.o lib/libfdt/built-in.o net/built-in.o test/built-in.o --end-group /home/abuild/rpmbuild/BUILD/u-boot-2014.01/arch/arm/lib/eabi_compat.o -L /usr/lib/gcc/armv7hl-suse-linux-gnueabi/4.8 -lgcc -Map u-boot.map -o u-boot [ 178s] ld.bfd: u-boot: could not find output section .gnu.hash [ 178s] ld.bfd: final link failed: Nonrepresentable section on output [ 178s] Makefile:556: recipe for target 'u-boot' failed [ 178s] make: *** [u-boot] Error 1 You are trying this with your codebase, right? If so, can you try and build vanilla v2014.01 with the exact same build environment? Commented out all our patches at: https://build.opensuse.org/project/show/home:a_faerber:branches:Base:System Failure of any sunxi-added targets is to be expected, of course. Not sure I'm getting this: if you build vanilla v2014.01, there shouldn't be any sunxi target built at all,
Re: [U-Boot] [PULL] u-boot-atmel/master - u-boot-arm/master
Hi Andreas, On Sun, 9 Mar 2014 19:50:12 +0100, Andreas Bießmann andreas.de...@googlemail.com wrote: Dear Albert Aribaud, please pull the following changes from u-boot-atmel/master into u-boot-arm/master. The following changes since commit de4fdfc1f22d70c23be5443dafacb8163023f9b1: Merge branch 'u-boot-tegra/master' into 'u-boot-arm/master' (2014-03-07 14:32:42 +0100) are available in the git repository at: git://git.denx.de/u-boot-atmel.git master for you to fetch changes up to 27019e4a949fc3be2e895ac20839c4d4d119f902: arm: atmel: sama5d3: add nand spl boot support (2014-03-09 19:19:13 +0100) Andreas Henriksson (2): at91sam9263ek: add mmc support at91 gpio: fix typo in compatibility macro Bo Shen (4): ARM: atmel: add sama5d3 Xplained board support arm: atmel: sama5d3: add spi spl boot support mtd: nand: atmel: prepare for nand spl boot support arm: atmel: sama5d3: add nand spl boot support arch/arm/cpu/arm926ejs/at91/at91sam9263_devices.c | 25 +++ arch/arm/cpu/at91-common/spl.c|4 + arch/arm/include/asm/arch-at91/gpio.h |2 +- arch/arm/include/asm/arch-at91/spl.h |4 + board/atmel/at91sam9263ek/at91sam9263ek.c | 10 + board/atmel/sama5d3_xplained/Makefile | 15 ++ board/atmel/sama5d3_xplained/sama5d3_xplained.c | 130 + board/atmel/sama5d3xek/sama5d3xek.c |4 + boards.cfg|2 + drivers/mtd/nand/atmel_nand.c | 208 + include/configs/at91sam9263ek.h | 13 ++ include/configs/sama5d3_xplained.h| 203 include/configs/sama5d3xek.h | 23 +++ include/nand.h|6 + 14 files changed, 648 insertions(+), 1 deletion(-) create mode 100644 board/atmel/sama5d3_xplained/Makefile create mode 100644 board/atmel/sama5d3_xplained/sama5d3_xplained.c create mode 100644 include/configs/sama5d3_xplained.h Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] at91: video: atmel_hlcdfb.c: fix bad timing configuration
The right correspondance between LCD margins and LCD timings is: * upper margin - vertical back porch * lower margin - vertical front porch * left margin - horizontal back porch * right margin - horizontal front porch Signed-off-by: Josh Wu josh...@atmel.com --- drivers/video/atmel_hlcdfb.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/video/atmel_hlcdfb.c b/drivers/video/atmel_hlcdfb.c index fc95897..e5d287d 100644 --- a/drivers/video/atmel_hlcdfb.c +++ b/drivers/video/atmel_hlcdfb.c @@ -144,12 +144,12 @@ void lcd_ctrl_init(void *lcdbase) value |= LCDC_LCDCFG1_HSPW(panel_info.vl_hsync_len - 1); lcdc_writel(regs-lcdc_lcdcfg1, value); - value = LCDC_LCDCFG2_VBPW(panel_info.vl_lower_margin); - value |= LCDC_LCDCFG2_VFPW(panel_info.vl_upper_margin - 1); + value = LCDC_LCDCFG2_VBPW(panel_info.vl_upper_margin); + value |= LCDC_LCDCFG2_VFPW(panel_info.vl_lower_margin - 1); lcdc_writel(regs-lcdc_lcdcfg2, value); - value = LCDC_LCDCFG3_HBPW(panel_info.vl_right_margin - 1); - value |= LCDC_LCDCFG3_HFPW(panel_info.vl_left_margin - 1); + value = LCDC_LCDCFG3_HBPW(panel_info.vl_left_margin - 1); + value |= LCDC_LCDCFG3_HFPW(panel_info.vl_right_margin - 1); lcdc_writel(regs-lcdc_lcdcfg3, value); /* Display size */ -- 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][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
-Original Message- From: Sun York-R58495 Sent: Saturday, March 08, 2014 12:01 AM To: Bansal Aneesh-B39320; u-boot@lists.denx.de Cc: Wood Scott-B07421 Subject: Re: [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS On 03/07/2014 05:23 AM, Aneesh Bansal wrote: Changes: 1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation from start.S 2. Clear the LAW and corresponding configuration for CPC. Boot ROM code uses it as hosekeeping area. 3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening in cpu_init_r. As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes. Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- README | 4 arch/powerpc/cpu/mpc85xx/cpu_init.c| 27 ++- arch/powerpc/cpu/mpc85xx/start.S | 3 ++- arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++ boards.cfg | 1 + 5 files changed, 35 insertions(+), 6 deletions(-) Changes from v3: Renamed the macro to indicate CPC configured as SRAM at U-boot entry to CONFIG_SYS_CPC_SRAM Aneesh, I understand you are trying to address the comment about when CPC needs to be disabled before initializing as normal CPC. But introducing CONFIG_SYS_CPC_SRAM seems even more confusing. Let's take one step back. In the previous patch we had defined it as CONFIG_SYS_SECURE_HKAREA_CPC. But as per the discussion on previous patch, we were advised to make it generic to have a macro stating that U-Boot is entered with the CPC configured as SRAM. CPC as SRAM can be used for many reasons. There is only one reason we should keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. For all other usages, we can safely reconfigure it as normal CPC after u-boot relocates itself into DDR. If u-boot's final destination is SRAM, it is a RAMBOOT. Can we use this condition to deal with CPC? There is a separate condition for secure boot in which CPC is required as SRAM. For NOR secure boot, user needs to initialize a housekeeping area using PBI commands and provide pointer to this housekeeping area to boot ROM. Currently we are using CPC configured as SRAM for this area. Since, this area was initialized as SRAM by PBI commands, there is no cleanup of this area by Boot ROM. Since out of ROM, this are is no longer required, in case of NOR secure boot we need to disable this setting. NOR secure boot is not a RAMBOOT. Do you see the need to disable CPC before relocation? You are doing so in this patch. Does the temporary LAW or address conflict with u-boot? Earlier we were disabling cpc in cpu_init_r. However since cache invalidation function was getting skipped in the process, it was causing random crashes. Skipping invalidation works in RAMBOOT scenario, however since we don’t have valid data when CPC is configured as cache for the secure boot scenario which is not RAMBOOT, these crashes were occurring in few platforms. As a result we had to move this disable code early in the sequence, so that invalidation of cache doesn’t get skipped. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot
-Original Message- From: Sun York-R58495 Sent: Saturday, March 08, 2014 12:31 AM To: Bansal Aneesh-B39320 Cc: Wood Scott-B07421; Wolfgang Denk; u-boot@lists.denx.de; Gupta Ruchika-R66431 Subject: Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot On 03/07/2014 10:57 AM, Scott Wood wrote: On Thu, 2014-03-06 at 03:24 -0600, Bansal Aneesh-B39320 wrote: -Original Message- From: Wood Scott-B07421 Sent: Wednesday, March 05, 2014 11:30 PM To: Bansal Aneesh-B39320 Cc: Sun York-R58495; Wolfgang Denk; u-boot@lists.denx.de; Gupta Ruchika-R66431 Subject: Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot On Tue, 2014-03-04 at 23:30 -0600, Bansal Aneesh-B39320 wrote: Yes, in case of secure boot from NAND, the DRAM is initialized by the BootROM and complete u-boot image is copied from NAND to DRAM by the BootROM. So, it should be called RAMBOOT. DRAM or SRAM? Having ROM initialize DDR is a bit scary. -Scott It can be either DDR or SRAM. It is not hardcoded in BootROM to initialize DDR. This depends on the config words (CF_WORDS) in the CF_HEADER. The Boot ROM code parses the config words and programs the addresses with data values accordingly. The user may opt to initialize DDR and get the image copied onto DDR or configure CPC as SRAM and get the Image copied onto SRAM. On 1010, P1010? LS1010? Something else? the CPC size is not big enough to accommodate the U-boot image. So, currently the CF_WORDS are for DDR to be initialized and copy the image on DDR. Generally if SPD is present, it should be used to init DDR rather than using hardcoded values. If U-Boot doesn't fit in SRAM, you can use SPL instead of hardcoded init. I agree with Scott on this point. Using hardcoded values totally skip DDR driver. You don't only lose the flexibility of various speeds, you also skip all workarounds implemented in DDR driver. York Currently we are following the same approach which was there for SPI and SD on P1010 i.e hardcoded initialization of DDR in platforms like P1010, 9131/9132 using config words. Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sh: ecovec: correct romImage address in comment
romImage is set by CONFIG_ECOVEC_ROMIMAGE_ADDR to 0xA004. Signed-off-by: Baruch Siach bar...@tkos.co.il --- board/renesas/ecovec/lowlevel_init.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/renesas/ecovec/lowlevel_init.S b/board/renesas/ecovec/lowlevel_init.S index eeebdd245f78..e4c40c861604 100644 --- a/board/renesas/ecovec/lowlevel_init.S +++ b/board/renesas/ecovec/lowlevel_init.S @@ -20,7 +20,7 @@ lowlevel_init: - /* jump to 0xA002 if bit 1 of PVDR_A */ + /* jump to CONFIG_ECOVEC_ROMIMAGE_ADDR if bit 1 of PVDR_A */ mov.l PVDR_A, r1 mov.l PVDR_D, r2 mov.b @r1, r0 -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sh: fix PFC registers definition for SH772{2, 3, 4}
Add missing port X data register, and fix the offset of ports Y and Z. Signed-off-by: Baruch Siach bar...@tkos.co.il --- I only have access to the SH7724 manual. But since the Linux kernel driver includes PXDR definition for SH7722 and SH7723, I assume this change is correct for them as well. --- arch/sh/include/asm/cpu_sh7722.h | 5 +++-- arch/sh/include/asm/cpu_sh7723.h | 5 +++-- arch/sh/include/asm/cpu_sh7724.h | 5 +++-- 3 files changed, 9 insertions(+), 6 deletions(-) diff --git a/arch/sh/include/asm/cpu_sh7722.h b/arch/sh/include/asm/cpu_sh7722.h index 7be37ae98421..bf57e18a64ee 100644 --- a/arch/sh/include/asm/cpu_sh7722.h +++ b/arch/sh/include/asm/cpu_sh7722.h @@ -1250,8 +1250,9 @@ #define PUDR0xA4050162 #define PVDR0xA4050164 #define PWDR0xA4050166 -#define PYDR0xA4050168 -#define PZDR0xA405016A +#define PXDR0xA4050168 +#define PYDR0xA405016A +#define PZDR0xA405016C /* UBC */ #define CBR00xFF20 diff --git a/arch/sh/include/asm/cpu_sh7723.h b/arch/sh/include/asm/cpu_sh7723.h index 3af0b0db2f8b..9d8cb8db444d 100644 --- a/arch/sh/include/asm/cpu_sh7723.h +++ b/arch/sh/include/asm/cpu_sh7723.h @@ -178,8 +178,9 @@ #define PUDR0xA4050162 #define PVDR0xA4050164 #define PWDR0xA4050166 -#define PYDR0xA4050168 -#define PZDR0xA405016A +#define PXDR0xA4050168 +#define PYDR0xA405016A +#define PZDR0xA405016C /* UBC */ /* H-UDI */ diff --git a/arch/sh/include/asm/cpu_sh7724.h b/arch/sh/include/asm/cpu_sh7724.h index 2c2a474d37fa..88c418a17f82 100644 --- a/arch/sh/include/asm/cpu_sh7724.h +++ b/arch/sh/include/asm/cpu_sh7724.h @@ -200,8 +200,9 @@ #define PUDR0xA4050162 #define PVDR0xA4050164 #define PWDR0xA4050166 -#define PYDR0xA4050168 -#define PZDR0xA405016A +#define PXDR0xA4050168 +#define PYDR0xA405016A +#define PZDR0xA405016C /* Ether */ #define EDMR 0xA460 -- 1.9.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot
On 03/10/2014 02:14 AM, Bansal Aneesh-B39320 wrote: -Original Message- From: Sun York-R58495 Sent: Saturday, March 08, 2014 12:31 AM To: Bansal Aneesh-B39320 Cc: Wood Scott-B07421; Wolfgang Denk; u-boot@lists.denx.de; Gupta Ruchika-R66431 Subject: Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot On 03/07/2014 10:57 AM, Scott Wood wrote: On Thu, 2014-03-06 at 03:24 -0600, Bansal Aneesh-B39320 wrote: -Original Message- From: Wood Scott-B07421 Sent: Wednesday, March 05, 2014 11:30 PM To: Bansal Aneesh-B39320 Cc: Sun York-R58495; Wolfgang Denk; u-boot@lists.denx.de; Gupta Ruchika-R66431 Subject: Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot On Tue, 2014-03-04 at 23:30 -0600, Bansal Aneesh-B39320 wrote: Yes, in case of secure boot from NAND, the DRAM is initialized by the BootROM and complete u-boot image is copied from NAND to DRAM by the BootROM. So, it should be called RAMBOOT. DRAM or SRAM? Having ROM initialize DDR is a bit scary. -Scott It can be either DDR or SRAM. It is not hardcoded in BootROM to initialize DDR. This depends on the config words (CF_WORDS) in the CF_HEADER. The Boot ROM code parses the config words and programs the addresses with data values accordingly. The user may opt to initialize DDR and get the image copied onto DDR or configure CPC as SRAM and get the Image copied onto SRAM. On 1010, P1010? LS1010? Something else? the CPC size is not big enough to accommodate the U-boot image. So, currently the CF_WORDS are for DDR to be initialized and copy the image on DDR. Generally if SPD is present, it should be used to init DDR rather than using hardcoded values. If U-Boot doesn't fit in SRAM, you can use SPL instead of hardcoded init. I agree with Scott on this point. Using hardcoded values totally skip DDR driver. You don't only lose the flexibility of various speeds, you also skip all workarounds implemented in DDR driver. York Currently we are following the same approach which was there for SPI and SD on P1010 i.e hardcoded initialization of DDR in platforms like P1010, 9131/9132 using config words. Understood. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
On 03/10/2014 02:14 AM, Bansal Aneesh-B39320 wrote: -Original Message- From: Sun York-R58495 Sent: Saturday, March 08, 2014 12:01 AM To: Bansal Aneesh-B39320; u-boot@lists.denx.de Cc: Wood Scott-B07421 Subject: Re: [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS On 03/07/2014 05:23 AM, Aneesh Bansal wrote: Changes: 1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation from start.S 2. Clear the LAW and corresponding configuration for CPC. Boot ROM code uses it as hosekeeping area. 3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening in cpu_init_r. As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes. Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- README | 4 arch/powerpc/cpu/mpc85xx/cpu_init.c| 27 ++- arch/powerpc/cpu/mpc85xx/start.S | 3 ++- arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++ boards.cfg | 1 + 5 files changed, 35 insertions(+), 6 deletions(-) Changes from v3: Renamed the macro to indicate CPC configured as SRAM at U-boot entry to CONFIG_SYS_CPC_SRAM Aneesh, I understand you are trying to address the comment about when CPC needs to be disabled before initializing as normal CPC. But introducing CONFIG_SYS_CPC_SRAM seems even more confusing. Let's take one step back. In the previous patch we had defined it as CONFIG_SYS_SECURE_HKAREA_CPC. But as per the discussion on previous patch, we were advised to make it generic to have a macro stating that U-Boot is entered with the CPC configured as SRAM. In your patch, you are using this new macro to disable SRAM. It would be more clear if the macro is named CONFIG_SYS_CPC_REINIT_F. CPC as SRAM can be used for many reasons. There is only one reason we should keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. For all other usages, we can safely reconfigure it as normal CPC after u-boot relocates itself into DDR. If u-boot's final destination is SRAM, it is a RAMBOOT. Can we use this condition to deal with CPC? There is a separate condition for secure boot in which CPC is required as SRAM. For NOR secure boot, user needs to initialize a housekeeping area using PBI commands and provide pointer to this housekeeping area to boot ROM. Currently we are using CPC configured as SRAM for this area. Since, this area was initialized as SRAM by PBI commands, there is no cleanup of this area by Boot ROM. Since out of ROM, this are is no longer required, in case of NOR secure boot we need to disable this setting. NOR secure boot is not a RAMBOOT. That's not conflict with my suggestion. This is NOT a RAMBOOT, so CPC should be reinitialized. Do you see the need to disable CPC before relocation? You are doing so in this patch. Does the temporary LAW or address conflict with u-boot? Earlier we were disabling cpc in cpu_init_r. However since cache invalidation function was getting skipped in the process, it was causing random crashes. Skipping invalidation works in RAMBOOT scenario, however since we don’t have valid data when CPC is configured as cache for the secure boot scenario which is not RAMBOOT, these crashes were occurring in few platforms. As a result we had to move this disable code early in the sequence, so that invalidation of cache doesn’t get skipped. As I suggested, if you have to do this before relocation, a macro CONFIG_SYS_CPC_REINIT_F makes more sense. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl_i2c: Add write-then-read transaction interface for I2C slave
On 03/09/2014 10:44 PM, Leekha Shaveta-B20052 wrote:
-Original Message-
From: Sun York-R58495
Sent: Saturday, March 08, 2014 3:10 AM
To: Leekha Shaveta-B20052; u-boot@lists.denx.de
Cc: Aggrwal Poonam-B10812; Aggrwal Poonam-B10812
Subject: Re: [PATCH] fsl_i2c: Add write-then-read transaction interface for
I2C slave
On 03/03/2014 12:58 AM, Shaveta Leekha wrote:
Most of the I2C slaves support accesses in the typical style
viz.read/write series of bytes at particular address offset.
These transactions are currently supportd in the i2c driver using
i2c_read and i2c_write APIs. I2C EEPROMs, RTC, etc fall in this
category.
The transactions look like:
START:Address:Tx:Offset:RESTART:Address[0..4]:Tx/Rx:data[0..n]:STOP
However there are certain devices which support accesses in terms of
the transactions as follows:
START:Address:Tx:Txdata[0..n1]:Clock_stretching:
RESTART:Address:Rx:data[0..n2]
The Txdata is typically a command and some associated data, similarly
Rxdata could be command status plus some data received as a response
to the command sent.
i2c_write_read() function provides support for such transactions
(multiple bytes write followed by read)
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
Signed-off-by: Shaveta Leekha shav...@freescale.com
---
drivers/i2c/fsl_i2c.c | 64
++-
drivers/i2c/i2c_core.c |7 +
include/i2c.h | 19 ++---
3 files changed, 78 insertions(+), 12 deletions(-)
snip
diff --git a/include/i2c.h b/include/i2c.h index 1b4078e..7bac20a
100644
--- a/include/i2c.h
+++ b/include/i2c.h
@@ -65,6 +65,9 @@ struct i2c_adapter {
int (*write)(struct i2c_adapter *adap, uint8_t chip,
uint addr, int alen, uint8_t *buffer,
int len);
+int (*write_read)(struct i2c_adapter *adap, uint8_t chip,
+uint8_t *wbuffer, int wlength, uint8_t *rbuffer,
+int rlength);
uint(*set_bus_speed)(struct i2c_adapter *adap,
uint speed);
int speed;
@@ -75,13 +78,14 @@ struct i2c_adapter {
char*name;
};
-#define U_BOOT_I2C_MKENT_COMPLETE(_init, _probe, _read, _write, \
+#define U_BOOT_I2C_MKENT_COMPLETE(_init, _probe, _read, _write,
+_write_read, \
_set_speed, _speed, _slaveaddr, _hwadapnr, _name) \
{ \
.init = _init, \
.probe = _probe, \
.read = _read, \
.write = _write, \
+.write_read = _write_read, \
.set_bus_speed = _set_speed, \
.speed = _speed, \
.slaveaddr = _slaveaddr, \
@@ -90,10 +94,11 @@ struct i2c_adapter {
.name = #_name \
};
-#define U_BOOT_I2C_ADAP_COMPLETE(_name, _init, _probe, _read, _write, \
-_set_speed, _speed, _slaveaddr, _hwadapnr) \
-ll_entry_declare(struct i2c_adapter, _name, i2c) = \
-U_BOOT_I2C_MKENT_COMPLETE(_init, _probe, _read, _write, \
+#define U_BOOT_I2C_ADAP_COMPLETE(_name, _init, _probe, _read, _write,
\
+_write_read, _set_speed, _speed, _slaveaddr,\
+_hwadapnr) \
+ll_entry_declare(struct i2c_adapter, _name, i2c) = \
+U_BOOT_I2C_MKENT_COMPLETE(_init, _probe, _read, _write,
+_write_read, \
_set_speed, _speed, _slaveaddr, _hwadapnr, _name);
struct i2c_adapter *i2c_get_adapter(int index); @@ -237,6 +242,8 @@
int i2c_read(uint8_t chip, unsigned int addr, int alen,
int i2c_write(uint8_t chip, unsigned int addr, int alen,
uint8_t *buffer, int len);
+int i2c_write_read(uint8_t chip, uchar *wbuffer, int wlen, uchar *rbuffer,
+int rlen);
/*
* Utility routines to read/write registers.
@@ -302,6 +309,8 @@ int i2c_probe(uchar chip);
*/
int i2c_read(uchar chip, uint addr, int alen, uchar *buffer, int
len); int i2c_write(uchar chip, uint addr, int alen, uchar *buffer,
int len);
+int i2c_write_read(uchar chip, uchar *wbuffer, int wlen, uchar *rbuffer,
+int rlen);
You need to be careful when changing the header file. If you compile other
platforms, you will see the error. Try ./MAKEALL -a powerpc. I don't know how
bad you broke other architectures.
[Leekha Shaveta-B20052] Agree. This may break i2c driver code for other
architectures.
For one of the I2C device for B4 platform, the read/write transaction cycle
is little different from
Other conventional I2C devices like EEPROM, PCA
Re: [U-Boot] [PATCH V2 1/3] part_efi: move uuid_string() and string_uuid() to lib/uuid.c
On 03/05/2014 09:45 AM, Przemyslaw Marczak wrote: Changes: Move functions: - disk/part_efi.c uuid_string() to lib/uuid.c - uuid_bin_to_str() - disk/part_efi.c string_uuid() to lib/uuid.c - uuid_str_to_bin() Update files: - include/common.h - disk/part_efi.c - lib/Makefile That's not a particularly useful patch description. How about: Move uuid-string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. Rename uuid_string() to uuid_bin_to_str(), so that's the naming is consistent with the existing uuid_str_to_bin(). Add an error return code to uuid_str_to_bin(). Convert existing users to the new library functions. This one patch, Acked-by: Stephen Warren swar...@nvidia.com diff --git a/lib/Makefile b/lib/Makefile obj-$(CONFIG_BOOTP_PXE) += uuid.o +obj-$(CONFIG_PARTITION_UUIDS) += uuid.o Oh, I hope listing uuid.o twice in obj-y won't cause any issue... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] part_efi: move uuid_string() and string_uuid() to lib/uuid.c
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 01:24 PM, Stephen Warren wrote: On 03/05/2014 09:45 AM, Przemyslaw Marczak wrote: Changes: Move functions: - disk/part_efi.c uuid_string() to lib/uuid.c - uuid_bin_to_str() - disk/part_efi.c string_uuid() to lib/uuid.c - uuid_str_to_bin() Update files: - include/common.h - disk/part_efi.c - lib/Makefile That's not a particularly useful patch description. How about: Move uuid-string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. Rename uuid_string() to uuid_bin_to_str(), so that's the naming is consistent with the existing uuid_str_to_bin(). Add an error return code to uuid_str_to_bin(). Convert existing users to the new library functions. This one patch, Acked-by: Stephen Warren swar...@nvidia.com As I'm applying and testing this locally right now, I'll take that better wording (and ack), thanks! diff --git a/lib/Makefile b/lib/Makefile obj-$(CONFIG_BOOTP_PXE) += uuid.o +obj-$(CONFIG_PARTITION_UUIDS) += uuid.o Oh, I hope listing uuid.o twice in obj-y won't cause any issue... Nope, we're good, it gets filtered now. We should handle this better once we have Kconfig in, but, one step at a time. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTHfY/AAoJENk4IS6UOR1W71YP/2tunn6ln8Qu3AG4YvcbSnQz FXESBryhXX4dzBnopwLRTi09zjfLQsT8a/uRpfPbo3OF7zUanoLCF11/eQK5k+Q9 3OcorHX98rozhC6/eyJfF7rzuznOKdh7IL+q+v715jll8riQAo103WVP8kPnjeoN KvZjl80ZLqX7qVTj4678wPQPJpjDFXF7uHrChfsEd3+XK31+MZrt58L58+VPARHA 43UghkcXGIP5ybFpi/h1N0b8Pu1AjOHC+WgHeUjdjfFiLL4laVFc3eVrPjsSltXf 7Ooq6tlFL9YtmtFToW/Ek2OeNN547bFxC7eVEMgzamUjFpYCTFh9E8ISTmhcJBK4 dnMNQ6obtVSZDYZD1PkPEpLvj48aKByXm2YIgdOo8Ds/Vza4g59VuCw6gFLPqQUz sR/+xr79GOTK+17ayTkacL0SS3FKbSWTSEtseLltaGtDOGE7UoWh8ENzmm8GwVdH rmxuR6ebYlLpINgT6oUvIA2i87vAZgjbaZMGzcC3SzI3ehakid3UfX7XBJ4xLJWj BNtuBq/k43SGsuC3IYAIl1HbQZiAKrQZhlqy80xp2EXp5MbSvEfaCnTV0sCHRWH4 fYoJ8v1ztHVn6Z8QfUL3mvJwR3BRd3UY/R4TD62/A054qPjisu8foFjpcrA+NrRq +OI1PLXI/hF5DG5gVsgM =pbb1 -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] part_efi: move uuid_string() and string_uuid() to lib/uuid.c
On 03/05/2014 09:45 AM, Przemyslaw Marczak wrote:
Changes:
Move functions:
- disk/part_efi.c uuid_string() to lib/uuid.c - uuid_bin_to_str()
- disk/part_efi.c string_uuid() to lib/uuid.c - uuid_str_to_bin()
diff --git a/lib/uuid.c b/lib/uuid.c
-void uuid_str_to_bin(const char *uuid, unsigned char *out)
+int uuid_str_to_bin(char *uuid, unsigned char *out)
{
uint16_t tmp16;
uint32_t tmp32;
uint64_t tmp64;
if (!uuid || !out)
- return;
+ return -EINVAL;
+
+ if (strlen(uuid) != UUID_STR_LEN)
+ return -EINVAL;
Oh. This patch won't compile, since UUID_STR_LEN doesn't exist yet.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 2/3] lib: uuid: add functions to generate UUID version 4
On 03/05/2014 09:45 AM, Przemyslaw Marczak wrote:
This patch adds support to generate UUID (Universally Unique Identifier)
in version 4 based on RFC4122, which is randomly.
Source: https://www.ietf.org/rfc/rfc4122.txt
Changes:
- add new config: CONFIG_RANDOM_UUID: compile uuid.c and rand.c
Update files:
- include/common.h
- lib/Makefile
- lib/uuid.c
The patch already contains the list of changed files; there's little
point duplicating this in the patch description.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
cc: Stephen Warren swar...@nvidia.com
cc: tr...@ti.com
s/cc/Cc/
diff --git a/lib/Makefile b/lib/Makefile
index 70962b2..64a430f 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -59,10 +59,12 @@ obj-y += linux_string.o
obj-$(CONFIG_REGEX) += slre.o
obj-y += string.o
obj-y += time.o
+obj-y += vsprintf.o
Moving vsprintf.o seems entirely unrelated to this patch. If you want to
clean that up, it should be a separate patch.
obj-$(CONFIG_TRACE) += trace.o
obj-$(CONFIG_BOOTP_PXE) += uuid.o
obj-$(CONFIG_PARTITION_UUIDS) += uuid.o
-obj-y += vsprintf.o
+obj-$(CONFIG_RANDOM_UUID) += uuid.o
+obj-$(CONFIG_RANDOM_UUID) += rand.o
obj-$(CONFIG_RANDOM_MACADDR) += rand.o
I really hope listing the same object multiple times in obj-y is OK.
Why not sort the lines you added so based on the config variable, so
obj-$(CONFIG_RANDOM_MACADDR) += rand.o
+obj-$(CONFIG_RANDOM_UUID) += rand.o
rather than:
+obj-$(CONFIG_RANDOM_UUID) += rand.o
obj-$(CONFIG_RANDOM_MACADDR) += rand.o
diff --git a/lib/uuid.c b/lib/uuid.c
index 803bdcd..c0218ba 100644
--- a/lib/uuid.c
+++ b/lib/uuid.c
@@ -7,6 +7,29 @@
#include linux/ctype.h
#include errno.h
#include common.h
+#include part_efi.h
+#include malloc.h
+
+#define UUID_STR_LEN 36
+#define UUID_STR_BYTE_LEN37
If UUID_STR_BYTE_LEN is the length in bytes, what units is UUID_STR_LEN
in? I suppose the difference is the NULL terminator, but the names don't
make that clear at all. I would suggest not defining UUID_STR_BYTE_LEN
at all, but rather just writing + 1 at the appropriate place in the
source code.
+#define UUID_BIN_BYTE_LEN16
Also, s/_BYTE// there.
+#define UUID_VERSION_CLEAR_BITS 0x0fff
s/CLEAR_BITS/MASK/
+struct uuid {
+ unsigned int time_low;
+ unsigned short time_mid;
+ unsigned short time_hi_and_version;
+ unsigned char clock_seq_hi_and_reserved;
+ unsigned char clock_seq_low;
+ unsigned char node[6];
+};
Is that structure definition endianness-safe?
+/*
+ * gen_rand_uuid() - this function generates 16 bytes len UUID V4 (randomly)
+ * and stores it at a given pointer.
I think this function generates a random binary UUID v4, and stores it
into the memory pointed at by the supplied pointer, which must be 16
bytes in size would be better.
+void gen_rand_uuid(unsigned char *uuid_bin)
+{
+ struct uuid *uuid = (struct uuid *)uuid_bin;
+ unsigned int *ptr = (unsigned int *)uuid_bin;
+ int i;
+
+ if (!uuid_bin)
+ return;
I think you should either (a) assume NULL will never be passed to this
function, or (b) return an error code if it happens. Silently failing to
do anything doesn't make sense.
+ memset(uuid_bin, 0x0, sizeof(struct uuid));
+
+ /* Set all fields randomly */
+ for (i = 0; i sizeof(struct uuid) / sizeof(*ptr); i++)
+ *(ptr + i) = rand();
If the entire thing is filled randomly, why memset() the struct?
+/*
+ * gen_rand_uuid_str() - this function generates UUID v4 (randomly)
+ * into 36 character hexadecimal ASCII string representation of a 128-bit
+ * (16 octets) UUID (Universally Unique Identifier) version 4 based on
RFC4122
+ * and stores it at a given pointer.
There's a lot of duplication in that description. I think this function
generates a random string-formatted UUID v4, and stores it into the
memory pointed at by the supplied pointer, which must be 37 bytes in
size would be better.
+void gen_rand_uuid_str(char *uuid_str)
+{
+ unsigned char uuid_bin[UUID_BIN_BYTE_LEN];
+
+ if (!uuid_str)
+ return;
Again, I would drop that error-checking.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] part_efi: move uuid_string() and string_uuid() to lib/uuid.c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/10/2014 01:29 PM, Stephen Warren wrote:
On 03/05/2014 09:45 AM, Przemyslaw Marczak wrote:
Changes:
Move functions:
- disk/part_efi.c uuid_string() to lib/uuid.c - uuid_bin_to_str()
- disk/part_efi.c string_uuid() to lib/uuid.c - uuid_str_to_bin()
diff --git a/lib/uuid.c b/lib/uuid.c
-void uuid_str_to_bin(const char *uuid, unsigned char *out)
+int uuid_str_to_bin(char *uuid, unsigned char *out)
{
uint16_t tmp16;
uint32_t tmp32;
uint64_t tmp64;
if (!uuid || !out)
-return;
+return -EINVAL;
+
+if (strlen(uuid) != UUID_STR_LEN)
+return -EINVAL;
Oh. This patch won't compile, since UUID_STR_LEN doesn't exist yet.
Yup, made this '36' and fixed in 2/3.
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJTHfi/AAoJENk4IS6UOR1Wf9QQAIpOqG7zaURNl4I8k+9wRTe+
M9qJB9a98diBFzUzFBwciwl3xZvXEDnxTyZmoXOCWLjOn46PCqCrufSj9A7F9vvC
XtOm5SQPJsteq8d2wsIqyg6CzkAv4fnQRAVQIsyY3cvOojLkqqU6tSZxI1ojNOea
FBEI0XzHmAb1CH5n/Fo9wN/MWMSUN5WIZPiCAqmMECWIJ0wEFrD70SXxItc40lTY
Ej7Cg9HwldlZhJ3gerlMN8MTZl+bmi2z0c0fF2vUgSa4X76s2h7xM/uKFS7VeDbO
NcIFITUWBfyhkvjfJrSJdR81sWJQEjsoDVA2YwgmfkIBTkAGOOfiEP0Lt1deZ1+O
vR9Dlt5lETscY76CFToOD6KlGRvZ+MKuP9Jvp8NljrOxCDevayxrWq/Vl5pwJbWs
WCoQmAUplVB08aeXjw0V/ZklXJTa51THQ40O1QMSSC17EQgd/kh0D4PqAhjUJ+M2
S/gyDm2PubZOJRwXdPT9Mv+q4emY5Dn/MiY3ZMBbMeqXytMe9J+3YY/EWkcVwgFU
LcbwxNKz7fqTtZkvNibuYxAjwPFqbh0/m2QxtqMtZs9aXHPT2Lno2HGcmLoaIUH/
RgCQjQjS7h+tC2NOc9OPNW+lfHFctHmkuv2GkhbGD2v0hamxJuMx8NxXVNYoClSR
X9PiT5VxoZtNW/SyX9ff
=QWYQ
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/3] cmd:gpt: randomly generate each partition uuid if undefined
On 03/05/2014 09:45 AM, Przemyslaw Marczak wrote:
Changes:
- randomly generate each partition uuid if undefined
- print info about generated uuid
- save environment on gpt write success
- update doc/README.gpt
diff --git a/common/cmd_gpt.c b/common/cmd_gpt.c
-static char extract_env(const char *str, char **env)
+static int extract_env(const char *str, char **env)
{
+ int ret = -1;
char *e, *s;
+ char uuid_str[37];
if (!str || strlen(str) 4)
return -1;
@@ -43,16 +45,25 @@ static char extract_env(const char *str, char **env)
memset(s + strlen(s) - 1, '\0', 1);
memmove(s, s + 2, strlen(s) - 1);
e = getenv(s);
- free(s);
if (e == NULL) {
- printf(Environmental '%s' not set\n, str);
- return -1; /* env not set */
+ printf(%s unset. , str);
+ gen_rand_uuid_str(uuid_str);
+ setenv(s, uuid_str);
+
+ e = getenv(s);
+ if (e) {
+ puts(Setting to random.\n);
Shouldn't this be printed right after the if (e == NULL) check above?
That's where the decision is made to generate a random UUID.
Here, if (!e), the code should return an error.
But, I still don't like changing the environment. Why can't the above
few lines be:
+ gen_rand_uuid_str(uuid_str);
+ e = uuid_str;
diff --git a/doc/README.gpt b/doc/README.gpt
uuid program is recommended to generate UUID string. Moreover it can decode
(-d switch) passed in UUID string. It can be used to generate partitions UUID
passed to u-boot environment variables.
+If each partition uuid no exists then it will be randomly generated.
If each means if all of them, implying that it's an all-or-nothing
solution, and the random generation only happens of none of the UUIDs
were supplied, not on a UUID-by-UUID basis. So, s/each/a/ or s/each/any/.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v2] mpc85xx/t104x: Add deep sleep framework support
On 02/28/2014 03:09 AM, yuantian.t...@freescale.com wrote: From: Tang Yuantian yuantian.t...@freescale.com 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 yuantian.t...@freescale.com --- v2: - added explaination for CONFIG_DEEP_SLEEP - fixed some issues README | 4 +++ arch/powerpc/cpu/mpc85xx/asm-offsets.c | 24 ++ Please fix the out-of-tree compiling issue. You will see it if you run make with O=path parameter. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 1/3] part_efi: move uuid_string() and string_uuid() to lib/uuid.c
On Mon, Mar 10, 2014 at 01:28:31PM -0400, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 01:24 PM, Stephen Warren wrote: On 03/05/2014 09:45 AM, Przemyslaw Marczak wrote: Changes: Move functions: - disk/part_efi.c uuid_string() to lib/uuid.c - uuid_bin_to_str() - disk/part_efi.c string_uuid() to lib/uuid.c - uuid_str_to_bin() Update files: - include/common.h - disk/part_efi.c - lib/Makefile That's not a particularly useful patch description. How about: Move uuid-string conversion functions into lib/uuid.c so they can be used by code outside part_efi.c. Rename uuid_string() to uuid_bin_to_str(), so that's the naming is consistent with the existing uuid_str_to_bin(). Add an error return code to uuid_str_to_bin(). Convert existing users to the new library functions. This one patch, Acked-by: Stephen Warren swar...@nvidia.com As I'm applying and testing this locally right now, I'll take that better wording (and ack), thanks! diff --git a/lib/Makefile b/lib/Makefile obj-$(CONFIG_BOOTP_PXE) += uuid.o +obj-$(CONFIG_PARTITION_UUIDS) += uuid.o Oh, I hope listing uuid.o twice in obj-y won't cause any issue... Nope, we're good, it gets filtered now. We should handle this better once we have Kconfig in, but, one step at a time. On second thought, and reading the rest of Stephen's review, please make a v3 of the series incorporating his feedback, making sure that the series is bisectable, we drop the unused str_ptr from 1/3 and also we catch the other direct use of '36' rather than UUID_STR_LEN in lib/uuid.c. Note that to maintain bisectablity I'm OK with adding '36' directly in one patch and removing in the next. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-usb/master
The following changes since commit 247161b8160fc699b0a517f081220bb50bc502a8: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2014-03-07 20:54:22 -0500) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to eb838e7d84a5211ccca0662297b4dfd1cc29e9df: usb: create common header virtual root hub descriptors (2014-03-10 18:53:36 +0100) Stephen Warren (3): ush: ehci: initialize altnext pointers in QH usb: ehci: fully align interrupt QHs/QTDs usb: create common header virtual root hub descriptors arch/mips/cpu/mips32/au1x00/au1x00_usb_ohci.c | 99 +- arch/powerpc/cpu/mpc5xxx/usb_ohci.c | 99 +- arch/powerpc/cpu/ppc4xx/usb_ohci.c| 99 +- arch/sparc/cpu/leon3/usb_uhci.c | 107 +++- board/mpl/common/usb_uhci.c | 115 +++--- drivers/usb/host/ehci-hcd.c | 8 -- drivers/usb/host/isp116x-hcd.c| 100 +-- drivers/usb/host/ohci-hcd.c | 98 +- drivers/usb/host/ohci-s3c24xx.c | 95 +--- drivers/usb/host/r8a66597-hcd.c | 104 +- drivers/usb/musb/musb_hcd.c | 93 +- include/usbroothubdes.h | 129 12 files changed, 149 insertions(+), 997 deletions(-) create mode 100644 include/usbroothubdes.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-arm/master
Hi Tom, The following changes since commit eeb72e67619b98d2502fe634a3a5d9953de92ad0: Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-02-26 16:49:58 -0500) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to 27019e4a949fc3be2e895ac20839c4d4d119f902: arm: atmel: sama5d3: add nand spl boot support (2014-03-09 19:19:13 +0100) Albert ARIBAUD (1): Merge branch 'u-boot-tegra/master' into 'u-boot-arm/master' Andreas Henriksson (2): at91sam9263ek: add mmc support at91 gpio: fix typo in compatibility macro Bo Shen (4): ARM: atmel: add sama5d3 Xplained board support arm: atmel: sama5d3: add spi spl boot support mtd: nand: atmel: prepare for nand spl boot support arm: atmel: sama5d3: add nand spl boot support Dave Gerlach (3): ARM: AM43xx: EMIF: configure self-refresh entry delay ARM: AM43xx: Write sdram_config to secure_emif_sdram_config ARM: AM43xx: Change DDR3 Reset Value Enric Balletbo i Serra (1): OMAP3: igep00x0: Enable required clocks for GPIO that are used. Hannes Petermaier (1): board/BuR/common: fix phy addresses Lokesh Vutla (1): ARM: AM4372: Update EMIF registers for DDR3 Mugunthan V N (6): drivers: net: cpsw: add support to have phy address from cpsw platform data ARM: AM43xx: clocks: Enable CPGMAC clock control ARM: AM43xx: Add CPSW support to AM43xx EPOS and GP EVM ARM: AM335x: add support for reading cpsw 2nd mac address from efuse ARM: DRA7xx: add support for reading cpsw 2nd mac from efuse ARM: AM43xx: Add Ethernet boot support to SPL Stefan Roese (1): arm: am335x: DXR2: Reset SMSC LAN9303 switch via GPIO upon bootup Stephen Warren (8): ARM: tegra: move CONFIG_TEGRAnn ARM: tegra: fix pmc_pwrgate_timer_mult register definition ARM: tegra: fix NV_PA_CSITE_BASE for Tegra124 ARM: tegra: simplify halt_avp() ARM: tegra: set CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS ARM: tegra: convert tegra to use distro defaults ARM: tegra: rework boot scripts ARM: tegra: implement bootcmd_pxe arch/arm/cpu/arm720t/tegra-common/cpu.c | 5 ++- arch/arm/cpu/arm720t/tegra124/cpu.c | 4 +-- arch/arm/cpu/arm926ejs/at91/at91sam9263_devices.c | 25 ++ arch/arm/cpu/armv7/am33xx/clock_am43xx.c | 1 + arch/arm/cpu/armv7/am33xx/ddr.c | 5 +-- arch/arm/cpu/armv7/am33xx/emif4.c | 2 +- arch/arm/cpu/at91-common/spl.c| 4 +++ arch/arm/include/asm/arch-at91/gpio.h | 2 +- arch/arm/include/asm/arch-at91/spl.h | 4 +++ arch/arm/include/asm/arch-tegra/pmc.h | 11 +++ arch/arm/include/asm/arch-tegra/tegra.h | 5 +++ arch/arm/include/asm/arch-tegra114/tegra.h| 2 ++ arch/arm/include/asm/arch-tegra124/tegra.h| 2 ++ arch/arm/include/asm/arch-tegra20/tegra.h | 2 ++ arch/arm/include/asm/arch-tegra30/tegra.h | 2 ++ board/BuR/common/common.c | 4 +-- board/atmel/at91sam9263ek/at91sam9263ek.c | 10 ++ board/atmel/sama5d3_xplained/Makefile | 15 + board/atmel/sama5d3_xplained/sama5d3_xplained.c | 130 board/atmel/sama5d3xek/sama5d3xek.c | 4 +++ board/compulab/cm_t335/cm_t335.c | 2 +- board/isee/igep0033/board.c | 2 +- board/phytec/pcm051/board.c | 4 +-- board/siemens/dxr2/board.c| 9 - board/siemens/dxr2/mux.c | 2 ++ board/siemens/pxm2/board.c| 4 +-- board/siemens/rut/board.c | 4 +-- board/silica/pengwyn/board.c | 4 +-- board/ti/am335x/board.c | 19 +-- board/ti/am43xx/board.c | 100 ++- board/ti/am43xx/mux.c | 44 +++-- board/ti/dra7xx/evm.c | 19 +-- board/ti/ti814x/evm.c | 4 +-- boards.cfg| 2 ++ drivers/mtd/nand/atmel_nand.c | 208 +++ drivers/net/cpsw.c| 4 +-- include/configs/am335x_evm.h | 1 - include/configs/am335x_igep0033.h | 1 - include/configs/am43xx_evm.h | 26 +++ include/configs/at91sam9263ek.h | 13 include/configs/bur_am335x_common.h
Re: [U-Boot] NAND SPL on imx6
Hi Andy, On 07/03/2014 13:36, Andy Ng wrote: Dear colleagues, Has anyone tried to build NAND SPL support on imx6. Does it work? SPL support is not yet done for i.MXes - definetely, it is one of the most important features we want to have in future. 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
[U-Boot] [PATCH] arm: exynos: Squash bogus warnings in pinmux
Squash these warnings in pinmux.c found with GCC 4.8:
/arch/arm/cpu/armv7/exynos/pinmux.c: In function 'exynos_pinmux_config':
/arch/arm/cpu/armv7/exynos/pinmux.c:687:28: warning: 'count' may be used
uninitialized in this function [-Wmaybe-uninitialized]
for (i = start; i start + count; i++) {
^
/arch/arm/cpu/armv7/exynos/pinmux.c:663:16: note: 'count' was declared here
int i, start, count;
^
/arch/arm/cpu/armv7/exynos/pinmux.c:687:28: warning: 'start' may be used
uninitialized in this function [-Wmaybe-uninitialized]
for (i = start; i start + count; i++) {
^
/arch/arm/cpu/armv7/exynos/pinmux.c:663:9: note: 'start' was declared here
int i, start, count;
^
/arch/arm/cpu/armv7/exynos/pinmux.c:689:19: warning: 'bank' may be used
uninitialized in this function [-Wmaybe-uninitialized]
s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
^
/arch/arm/cpu/armv7/exynos/pinmux.c:662:24: note: 'bank' was declared here
struct s5p_gpio_bank *bank;
^
/arch/arm/cpu/armv7/exynos/pinmux.c: In function 'exynos_pinmux_config':
/arch/arm/cpu/armv7/exynos/pinmux.c:687:28: warning: 'count' may be used
uninitialized in this function [-Wmaybe-uninitialized]
for (i = start; i start + count; i++) {
^
/arch/arm/cpu/armv7/exynos/pinmux.c:663:16: note: 'count' was declared here
int i, start, count;
^
/arch/arm/cpu/armv7/exynos/pinmux.c:687:28: warning: 'start' may be used
uninitialized in this function [-Wmaybe-uninitialized]
for (i = start; i start + count; i++) {
^
/arch/arm/cpu/armv7/exynos/pinmux.c:663:9: note: 'start' was declared here
int i, start, count;
^
/arch/arm/cpu/armv7/exynos/pinmux.c:689:19: warning: 'bank' may be used
uninitialized in this function [-Wmaybe-uninitialized]
s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
^
/arch/arm/cpu/armv7/exynos/pinmux.c:662:24: note: 'bank' was declared here
struct s5p_gpio_bank *bank;
^
Note that the warning is bogus, the function can never be called with invalid
'peripheral' argument. GCC just cannot analyze this.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Akshay Saraswat aksha...@samsung.com
Cc: Rajeshwari S Shinde rajeshwar...@samsung.com
Cc: Simon Glass s...@chromium.org
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/exynos/pinmux.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/cpu/armv7/exynos/pinmux.c
b/arch/arm/cpu/armv7/exynos/pinmux.c
index 645c497..61759a4 100644
--- a/arch/arm/cpu/armv7/exynos/pinmux.c
+++ b/arch/arm/cpu/armv7/exynos/pinmux.c
@@ -39,6 +39,9 @@ static void exynos5_uart_config(int peripheral)
start = 4;
count = 2;
break;
+ default:
+ debug(%s: invalid peripheral %d, __func__, peripheral);
+ return;
}
for (i = start; i start + count; i++) {
s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
@@ -74,6 +77,9 @@ static void exynos5420_uart_config(int peripheral)
start = 4;
count = 2;
break;
+ default:
+ debug(%s: invalid peripheral %d, __func__, peripheral);
+ return;
}
for (i = start; i start + count; i++) {
@@ -110,6 +116,9 @@ static int exynos5_mmc_config(int peripheral, int flags)
bank = gpio1-c4;
bank_ext = NULL;
break;
+ default:
+ debug(%s: invalid peripheral %d, __func__, peripheral);
+ return -1;
}
if ((flags PINMUX_FLAG_8BIT_MODE) !bank_ext) {
debug(SDMMC device %d does not support 8bit mode,
@@ -683,6 +692,9 @@ static void exynos4_uart_config(int peripheral)
start = 4;
count = 2;
break;
+ default:
+ debug(%s: invalid peripheral %d, __func__, peripheral);
+ return;
}
for (i = start; i start + count; i++) {
s5p_gpio_set_pull(bank, i, GPIO_PULL_NONE);
--
1.8.5.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: exynos: Squash bogus warnings in pinmux
Hi Marek,
On 10 March 2014 13:04, Marek Vasut ma...@denx.de wrote:
Squash these warnings in pinmux.c found with GCC 4.8:
/arch/arm/cpu/armv7/exynos/pinmux.c: In function 'exynos_pinmux_config':
/arch/arm/cpu/armv7/exynos/pinmux.c:687:28: warning: 'count' may be used
uninitialized in this function [-Wmaybe-uninitialized]
for (i = start; i start + count; i++) {
^
/arch/arm/cpu/armv7/exynos/pinmux.c:663:16: note: 'count' was declared here
int i, start, count;
^
/arch/arm/cpu/armv7/exynos/pinmux.c:687:28: warning: 'start' may be used
uninitialized in this function [-Wmaybe-uninitialized]
for (i = start; i start + count; i++) {
^
/arch/arm/cpu/armv7/exynos/pinmux.c:663:9: note: 'start' was declared here
int i, start, count;
^
/arch/arm/cpu/armv7/exynos/pinmux.c:689:19: warning: 'bank' may be used
uninitialized in this function [-Wmaybe-uninitialized]
s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
^
/arch/arm/cpu/armv7/exynos/pinmux.c:662:24: note: 'bank' was declared here
struct s5p_gpio_bank *bank;
^
/arch/arm/cpu/armv7/exynos/pinmux.c: In function 'exynos_pinmux_config':
/arch/arm/cpu/armv7/exynos/pinmux.c:687:28: warning: 'count' may be used
uninitialized in this function [-Wmaybe-uninitialized]
for (i = start; i start + count; i++) {
^
/arch/arm/cpu/armv7/exynos/pinmux.c:663:16: note: 'count' was declared here
int i, start, count;
^
/arch/arm/cpu/armv7/exynos/pinmux.c:687:28: warning: 'start' may be used
uninitialized in this function [-Wmaybe-uninitialized]
for (i = start; i start + count; i++) {
^
/arch/arm/cpu/armv7/exynos/pinmux.c:663:9: note: 'start' was declared here
int i, start, count;
^
/arch/arm/cpu/armv7/exynos/pinmux.c:689:19: warning: 'bank' may be used
uninitialized in this function [-Wmaybe-uninitialized]
s5p_gpio_cfg_pin(bank, i, GPIO_FUNC(0x2));
^
/arch/arm/cpu/armv7/exynos/pinmux.c:662:24: note: 'bank' was declared here
struct s5p_gpio_bank *bank;
^
Note that the warning is bogus, the function can never be called with invalid
'peripheral' argument. GCC just cannot analyze this.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Akshay Saraswat aksha...@samsung.com
Cc: Rajeshwari S Shinde rajeshwar...@samsung.com
Cc: Simon Glass s...@chromium.org
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Tom Rini tr...@ti.com
Acked-by: Simon Glass s...@chromium.org
Thanks Marek, great to get that annoyance fixed.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am335x_evm: Remove SPI SPL from NOR support target
When using the am335x_evm_nor target one is generally expecting to be used in an environment when you want to program the NOR and not a deployment type target. In addition this only supports the Beaglebone White with the memory cape and NOR module installed, which precludes the presence of SPI flash. Drop SPI as we were getting close to the binary limit in some cases and slightly over with other toolchains. Signed-off-by: Tom Rini tr...@ti.com --- include/configs/am335x_evm.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index 2020e7f..fd6f52c 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -442,6 +442,8 @@ #define CONFIG_SYS_FLASH_BASE (0x0800) #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
Re: [U-Boot] [PATCH v7] socfpga: Add socfpga preloader signing to mkimage
[ Cc: to Masahiro for the tools/ vs lib/ build support part ]
On Mon, Mar 10, 2014 at 16:04 +1300, Charles Manning wrote:
On Sunday 09 March 2014 05:51:23 Gerhard Sittig wrote:
On Thu, Mar 06, 2014 at 15:40 +1300, Charles Manning wrote:
--- /dev/null
+++ b/lib/bzlib_crc32.c
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ *
+ * This provides a CRC-32 using the tables in bzlib_crctable.c
+ */
+
+#include bzlib_crc32.h
+#include bzlib_private.h
+
+uint32_t bzlib_crc32(uint32_t crc, const void *_buf, int length)
+{
+ const uint8_t *buf = _buf;
+
+ crc ^= ~0;
+
+ while (length--) {
+ crc = (crc 8) ^ BZ2_crc32Table[((crc 24) ^ *buf) 0xff];
+ buf++;
+ }
+
+ crc ^= ~0;
+
+ return crc;
+}
Since you already include the private bzlib header for the
BZ2_crc32Table[] declaration, you might as well use the
BZ_INITIALISE_CRC(), BZ_FINALISE_CRC(), and BZ_UPDATE_CRC()
macros declared from there (right next to the table's
declaration), instead of re-inventing how the CRC gets
calculated.
If you think that makes it more clear I shall do that. I don't think though
that it really is any clearer.
Admittedly your wrapper is thin. Yet it duplicates what the
bzlib header already provides. And does so in different phrases
(i.e. textually does not match the original, so probably gets
missed upon searches).
It's more a matter of consistency to re-use the code as well as
the table of the bzip2 implementation, instead of re-inventing
both or using parts of it only.
You probably should determine whether you want to provide one
routine to do the complete calculate over a given byte stream,
without any previous CRC value -- this is what your current use
case is. Or whether you want to provide three primitives to
initialize, update, and finalize a CRC (which is not used yet).
Or whether you want to provide the three primitives plus one
convenience wrapper.
I try to use a single familiar function, like crc32() does.
You can start with 0, then use it with the results.
eg
crc = crc32(0, first_buff,...);
crc = crc32(crc, second_bufer,...);
This only works by coincidence because the final XOR and the
initial value happen to be complimentary and only by chance the
value of zero works. So it's not a general pattern, but a
specific feature of this very implementation.
Given that your current application only determines CRC values
for complete buffers and nothing is done piecemeal, I'd suggest
to provide the one convenience wrapper routine which does not
take a previous partial result.
Should other use cases later require incremental calculation,
they can introduce and use the three primitives to open, iterate
and close the calculation. This better reflects what's
happening. Or am I being overly picky?
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -70,6 +70,8 @@ RSA_OBJS-$(CONFIG_FIT_SIGNATURE) := rsa-sign.o
# common objs for dumpimage and mkimage
dumpimage-mkimage-objs := aisimage.o \
$(FIT_SIG_OBJS-y) \
+ bzlib_crc32.o \
+ bzlib_crctable.o \
crc32.o \
default_image.o \
fit_image.o \
@@ -85,6 +87,7 @@ dumpimage-mkimage-objs := aisimage.o \
os_support.o \
pblimage.o \
sha1.o \
+ socfpgaimage.o \
ublimage.o \
$(LIBFDT_OBJS) \
$(RSA_OBJS-y)
diff --git a/tools/bzlib_crc32.c b/tools/bzlib_crc32.c
new file mode 100644
index 000..b7f7aa5
--- /dev/null
+++ b/tools/bzlib_crc32.c
@@ -0,0 +1 @@
+#include ../lib/bzlib_crc32.c
diff --git a/tools/bzlib_crctable.c b/tools/bzlib_crctable.c
new file mode 100644
index 000..53d38ef
--- /dev/null
+++ b/tools/bzlib_crctable.c
@@ -0,0 +1 @@
+#include ../bzlib_crctable.c
diff --git a/tools/bzlib_private.h b/tools/bzlib_private.h
new file mode 100644
index 000..cfb74be
--- /dev/null
+++ b/tools/bzlib_private.h
@@ -0,0 +1 @@
+#include lib/bzlib_private.h
Now this is incredibly ugly. You are duplicating lib/ stuff in
tools/ and build it there as well? Or not at all build it in
lib/ where the code actually resides?
It's only a side note that
#include for *.c is problematic as some compilers do
semi-intelligent stuff when the filename does not end in .h and
then break compilation, so this hack should neither get spread
nor suggested for use.
I absolutely agree this is very, very, ugly.
I was just following the current way of doing things. This is how crc32.c,
sha1.c, md5.c, fdt.c and many others are handled.
I expect that this is worth a refactorisation effort, but I think that
Re: [U-Boot] [PATCH] lcd: Add support for CONFIG_LCD_NOSTDOUT
On Sat, Mar 08, 2014 at 20:46 +0100, Hannes Petermaier wrote: Hi Gerhard, On 2014-03-06 20:49, Gerhard Sittig wrote: In general U-Boot tries to get away from the multitude of ifdefs where possible. I'm afraid adding a new one needs a very good reason to get perceived as welcome. By the way i've found a passage within README, which tells to do so as id id: '* If you modify existing code, make sure that your new code does not add to the memory footprint of the code ;-) Small is beautiful! When adding new features, these should compile conditionally only (using #ifdef), and the resulting code with the new feature disabled must not need more memory than the old code without your modification. ' whats your opinion about this ? This policy may not apply here. It's applicable to larger chunks of new code, like complete drivers or complex features. Not everyone wants support for unused features in their executables that need to fit in constrained resources. That's well understood. Your case is different. There is a feature, it's already present and small and unconditional. And your change even shortcuts this small portion. I guess that adding another compiler switch for this may not be appropriate. But let's see what others have to say. I'm not an expert in policy. virtually yours Gerhard Sittig -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] omap24xx_i2c: i2c 16-bit write to pcf8575
On Wed, Mar 05, 2014 at 04:01:47PM -0500, Richard Retanubun wrote: Hello, My platform is a dra7xx_evm. My code baseline is denx master I am trying to write to the pcf8575 i2c gpio expander at address 0x21 (bit P4) I can read 16-bit okay in this version, but 16-bit writing is not working. // Display current values i2c md 21 0.0 2 : f7 eb.. // Set bit P4 to 1 i2c mw 21 0.0 0xffeb 2 // But it remains at 0xf7 i2c md 21 0.0 2 : f7 eb.. When we put scopes on the i2c lines, it seems that the i2c mw transaction produces a longer i2c bus sequence that does not map to the [Start:Addr:W:A:P7-P0:A:P17-P10:A:Stop] that the pcf8575 device expects. Either I am invoking i2c mw incorrectly, or the oma24xx_i2c driver is not handling i2c 16-bit writes correctly yet. Any hints will be appreciated. Thanks for everyone's time Have you tried doing it progmatically rather than via the command line? You may indeed be running into something we don't support in i2c mw, if I skim the comments right. -- 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 v7] socfpga: Add socfpga preloader signing to mkimage
Dear Gerhard
Thank you for your further comments and clarifications, may I press you for a
few more?
On Tuesday 11 March 2014 08:36:24 Gerhard Sittig wrote:
[ Cc: to Masahiro for the tools/ vs lib/ build support part ]
On Mon, Mar 10, 2014 at 16:04 +1300, Charles Manning wrote:
On Sunday 09 March 2014 05:51:23 Gerhard Sittig wrote:
On Thu, Mar 06, 2014 at 15:40 +1300, Charles Manning wrote:
--- /dev/null
+++ b/lib/bzlib_crc32.c
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2014 Charles Manning cdhmann...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * This provides a CRC-32 using the tables in bzlib_crctable.c
+ */
+
+#include bzlib_crc32.h
+#include bzlib_private.h
+
+uint32_t bzlib_crc32(uint32_t crc, const void *_buf, int length)
+{
+ const uint8_t *buf = _buf;
+
+ crc ^= ~0;
+
+ while (length--) {
+ crc = (crc 8) ^ BZ2_crc32Table[((crc 24) ^ *buf)
0xff];
+ buf++;
+ }
+
+ crc ^= ~0;
+
+ return crc;
+}
Since you already include the private bzlib header for the
BZ2_crc32Table[] declaration, you might as well use the
BZ_INITIALISE_CRC(), BZ_FINALISE_CRC(), and BZ_UPDATE_CRC()
macros declared from there (right next to the table's
declaration), instead of re-inventing how the CRC gets
calculated.
If you think that makes it more clear I shall do that. I don't think
though that it really is any clearer.
Admittedly your wrapper is thin. Yet it duplicates what the
bzlib header already provides. And does so in different phrases
(i.e. textually does not match the original, so probably gets
missed upon searches).
It's more a matter of consistency to re-use the code as well as
the table of the bzip2 implementation, instead of re-inventing
both or using parts of it only.
It does not bug me to use either way. I shall use that.
You probably should determine whether you want to provide one
routine to do the complete calculate over a given byte stream,
without any previous CRC value -- this is what your current use
case is. Or whether you want to provide three primitives to
initialize, update, and finalize a CRC (which is not used yet).
Or whether you want to provide the three primitives plus one
convenience wrapper.
I try to use a single familiar function, like crc32() does.
You can start with 0, then use it with the results.
eg
crc = crc32(0, first_buff,...);
crc = crc32(crc, second_bufer,...);
This only works by coincidence because the final XOR and the
initial value happen to be complimentary and only by chance the
value of zero works. So it's not a general pattern, but a
specific feature of this very implementation.
Given that your current application only determines CRC values
for complete buffers and nothing is done piecemeal, I'd suggest
to provide the one convenience wrapper routine which does not
take a previous partial result.
Should other use cases later require incremental calculation,
they can introduce and use the three primitives to open, iterate
and close the calculation. This better reflects what's
happening. Or am I being overly picky?
Perhaps picky, but I do not mind losing this.
The issue is that these functions are often used on long sequences one buffer
at a time (eg. doing a crc on 100k, but getting the data in 1k blocks).
This implementation does not need the multi-buffer support, but when I
refactor the crcs in mkimage (as I have undertaken to do - even though it is
of no direct utility to me at all), there might be a need to use
multi-buffer.
For now I will just provide a single buffer version, and will widen it up if
need be later.
--- a/tools/Makefile
+++ b/tools/Makefile
@@ -70,6 +70,8 @@ RSA_OBJS-$(CONFIG_FIT_SIGNATURE) := rsa-sign.o
# common objs for dumpimage and mkimage
dumpimage-mkimage-objs := aisimage.o \
$(FIT_SIG_OBJS-y) \
+ bzlib_crc32.o \
+ bzlib_crctable.o \
crc32.o \
default_image.o \
fit_image.o \
@@ -85,6 +87,7 @@ dumpimage-mkimage-objs := aisimage.o \
os_support.o \
pblimage.o \
sha1.o \
+ socfpgaimage.o \
ublimage.o \
$(LIBFDT_OBJS) \
$(RSA_OBJS-y)
diff --git a/tools/bzlib_crc32.c b/tools/bzlib_crc32.c
new file mode 100644
index 000..b7f7aa5
--- /dev/null
+++ b/tools/bzlib_crc32.c
@@ -0,0 +1 @@
+#include ../lib/bzlib_crc32.c
diff --git a/tools/bzlib_crctable.c b/tools/bzlib_crctable.c
new file mode 100644
index 000..53d38ef
---
Re: [U-Boot] [U-Boot, v3, 1/4] ahci-plat: Provide a weak scsi_init hook
On Fri, Mar 07, 2014 at 01:20:56AM +, Ian Campbell wrote: This allow the platform to register the platform ahci device. Signed-off-by: Ian Campbell i...@hellion.org.uk Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ANN] U-Boot v2014.04-rc2 released
Hey all, I've pushed v2014.04-rc2 out to the repository and tarballs should exist soon. The good news this time around is Masahiro did some more updates to the system and we're now building faster than before. This should be noticable in both the single config build and arch/soc/vendor/etc builds. As always, if anything is broken please speak up. Thanks all! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] .gitignore: ignore include/config/*
On Mon, Mar 10, 2014 at 10:47:19AM +0900, Masahiro Yamada wrote: --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index ee16d8c..f3f3a2a 100644 --- a/Makefile +++ b/Makefile @@ -1022,7 +1022,7 @@ define filechk_timestamp.h LC_ALL=C date +'#define U_BOOT_TIME %T') endef -$(version_h): $(srctree)/Makefile FORCE +$(version_h): include/config/uboot.release FORCE $(call filechk,version.h) $(timestamp_h): $(srctree)/Makefile FORCE Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] kbuild: fix a bug of make rule of version_autogenerated.h
On Mon, Mar 10, 2014 at 10:42:27AM +0900, Masahiro Yamada wrote: include/generated/version_autogenerated.h was not correctly generated on the parallel build (with -j option). Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Reported-by: Andreas Bießmann andreas.de...@googlemail.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] m68k: Remove M5271EVB and idmr board support
On Fri, Feb 21, 2014 at 09:55:16AM +0900, Masahiro Yamada wrote: CONFIG_SYS_HZ must be always 1000, but M5271EVB.h defines it as 100 and idmr.h defines it as (5000 / 64). When compiling these two boards, a warning message is displayed: time.c:14:2: warning: #warning CONFIG_SYS_HZ must be 1000 and should not be defined by platforms [-Wcpp] There are no board maintainers for them so this commit just deletes them. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Jason Jin jason@freescale.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v3,2/4] highbank: use scsi_init hook
On Fri, Mar 07, 2014 at 01:20:57AM +, Ian Campbell wrote: Signed-off-by: Ian Campbell i...@hellion.org.uk Acked-by: Rob Herring r...@kernel.org Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Mon, Mar 10, 2014 at 06:55:49PM +0100, Marek Vasut wrote: The following changes since commit 247161b8160fc699b0a517f081220bb50bc502a8: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2014-03-07 20:54:22 -0500) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to eb838e7d84a5211ccca0662297b4dfd1cc29e9df: usb: create common header virtual root hub descriptors (2014-03-10 18:53:36 +0100) Stephen Warren (3): ush: ehci: initialize altnext pointers in QH usb: ehci: fully align interrupt QHs/QTDs usb: create common header virtual root hub descriptors arch/mips/cpu/mips32/au1x00/au1x00_usb_ohci.c | 99 +- arch/powerpc/cpu/mpc5xxx/usb_ohci.c | 99 +- arch/powerpc/cpu/ppc4xx/usb_ohci.c| 99 +- arch/sparc/cpu/leon3/usb_uhci.c | 107 +++- board/mpl/common/usb_uhci.c | 115 +++--- drivers/usb/host/ehci-hcd.c | 8 -- drivers/usb/host/isp116x-hcd.c| 100 +-- drivers/usb/host/ohci-hcd.c | 98 +- drivers/usb/host/ohci-s3c24xx.c | 95 +--- drivers/usb/host/r8a66597-hcd.c | 104 +- drivers/usb/musb/musb_hcd.c | 93 +- include/usbroothubdes.h | 129 12 files changed, 149 insertions(+), 997 deletions(-) create mode 100644 include/usbroothubdes.h Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,v3,3/4] ahci: wait longer for link.
On Fri, Mar 07, 2014 at 01:20:58AM +, Ian Campbell wrote: I have observed timeouts on a cubietruck. The increase to 40ms is completely arbitrary and Works For Me(tm). I couldn't find a good reference for how long you are supposed to wait, although googling around it seems like tens of ms rather than single digits is more common. I don't think there is any harm in waiting a bit longer. Signed-off-by: Ian Campbell i...@hellion.org.uk Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot, V3] cfb_console: align fields in gzipped .bmp files
On Sat, Mar 08, 2014 at 07:55:52AM -0700, Eric Nelson wrote: .bmp files contain 32-bit integers aligned at offsets of +2, +6, et cetera within the bmp_header structure (see include/bmp_layout.h). Support for gzip-compressed .bmp files is present in the cfb_console display subsystem by uncompressing them prior to use. This patch forces the in-memory header to be aligned properly for these compressed images by extracting them to a 2-byte offset in the memory returned by malloc. Since malloc will always return a 4-byte aligned value, this forces the .bmp header fields to be naturally aligned on 4-byte addresses. Refer to these files for more details: doc/README.displaying-bmps doc/README.arm-unaligned-accesses Signed-off-by: Eric Nelson eric.nel...@boundarydevices.com Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-arm/master
On Mon, Mar 10, 2014 at 07:16:44PM +0100, Albert ARIBAUD wrote: Hi Tom, The following changes since commit eeb72e67619b98d2502fe634a3a5d9953de92ad0: Merge branch 'master' of git://git.denx.de/u-boot-arm (2014-02-26 16:49:58 -0500) are available in the git repository at: git://git.denx.de/u-boot-arm master for you to fetch changes up to 27019e4a949fc3be2e895ac20839c4d4d119f902: arm: atmel: sama5d3: add nand spl boot support (2014-03-09 19:19:13 +0100) Albert ARIBAUD (1): Merge branch 'u-boot-tegra/master' into 'u-boot-arm/master' Andreas Henriksson (2): at91sam9263ek: add mmc support at91 gpio: fix typo in compatibility macro Bo Shen (4): ARM: atmel: add sama5d3 Xplained board support arm: atmel: sama5d3: add spi spl boot support mtd: nand: atmel: prepare for nand spl boot support arm: atmel: sama5d3: add nand spl boot support Dave Gerlach (3): ARM: AM43xx: EMIF: configure self-refresh entry delay ARM: AM43xx: Write sdram_config to secure_emif_sdram_config ARM: AM43xx: Change DDR3 Reset Value Enric Balletbo i Serra (1): OMAP3: igep00x0: Enable required clocks for GPIO that are used. Hannes Petermaier (1): board/BuR/common: fix phy addresses Lokesh Vutla (1): ARM: AM4372: Update EMIF registers for DDR3 Mugunthan V N (6): drivers: net: cpsw: add support to have phy address from cpsw platform data ARM: AM43xx: clocks: Enable CPGMAC clock control ARM: AM43xx: Add CPSW support to AM43xx EPOS and GP EVM ARM: AM335x: add support for reading cpsw 2nd mac address from efuse ARM: DRA7xx: add support for reading cpsw 2nd mac from efuse ARM: AM43xx: Add Ethernet boot support to SPL Stefan Roese (1): arm: am335x: DXR2: Reset SMSC LAN9303 switch via GPIO upon bootup Stephen Warren (8): ARM: tegra: move CONFIG_TEGRAnn ARM: tegra: fix pmc_pwrgate_timer_mult register definition ARM: tegra: fix NV_PA_CSITE_BASE for Tegra124 ARM: tegra: simplify halt_avp() ARM: tegra: set CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS ARM: tegra: convert tegra to use distro defaults ARM: tegra: rework boot scripts ARM: tegra: implement bootcmd_pxe arch/arm/cpu/arm720t/tegra-common/cpu.c | 5 ++- arch/arm/cpu/arm720t/tegra124/cpu.c | 4 +-- arch/arm/cpu/arm926ejs/at91/at91sam9263_devices.c | 25 ++ arch/arm/cpu/armv7/am33xx/clock_am43xx.c | 1 + arch/arm/cpu/armv7/am33xx/ddr.c | 5 +-- arch/arm/cpu/armv7/am33xx/emif4.c | 2 +- arch/arm/cpu/at91-common/spl.c| 4 +++ arch/arm/include/asm/arch-at91/gpio.h | 2 +- arch/arm/include/asm/arch-at91/spl.h | 4 +++ arch/arm/include/asm/arch-tegra/pmc.h | 11 +++ arch/arm/include/asm/arch-tegra/tegra.h | 5 +++ arch/arm/include/asm/arch-tegra114/tegra.h| 2 ++ arch/arm/include/asm/arch-tegra124/tegra.h| 2 ++ arch/arm/include/asm/arch-tegra20/tegra.h | 2 ++ arch/arm/include/asm/arch-tegra30/tegra.h | 2 ++ board/BuR/common/common.c | 4 +-- board/atmel/at91sam9263ek/at91sam9263ek.c | 10 ++ board/atmel/sama5d3_xplained/Makefile | 15 + board/atmel/sama5d3_xplained/sama5d3_xplained.c | 130 board/atmel/sama5d3xek/sama5d3xek.c | 4 +++ board/compulab/cm_t335/cm_t335.c | 2 +- board/isee/igep0033/board.c | 2 +- board/phytec/pcm051/board.c | 4 +-- board/siemens/dxr2/board.c| 9 - board/siemens/dxr2/mux.c | 2 ++ board/siemens/pxm2/board.c| 4 +-- board/siemens/rut/board.c | 4 +-- board/silica/pengwyn/board.c | 4 +-- board/ti/am335x/board.c | 19 +-- board/ti/am43xx/board.c | 100 ++- board/ti/am43xx/mux.c | 44 +++-- board/ti/dra7xx/evm.c | 19 +-- board/ti/ti814x/evm.c | 4 +-- boards.cfg| 2 ++ drivers/mtd/nand/atmel_nand.c | 208 +++ drivers/net/cpsw.c| 4 +-- include/configs/am335x_evm.h | 1 - include/configs/am335x_igep0033.h | 1 -
Re: [U-Boot] net: asix: don't pad odd-length TX packets
Hi Marek, On Sat, Mar 8, 2014 at 5:32 AM, Marek Vasut ma...@denx.de wrote: On Friday, March 07, 2014 at 11:27:37 PM, Tom Rini wrote: Applied to u-boot/master, thanks! Uh, where did Joe disappear to anyway ? Best regards, Marek Vasut I've been traveling a lot recently and have not had much time for reviewing and testing patches. I expect to get back into it u-boot more heavily in a few months. Regards, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v5] nand/denali: Adding Denali NAND driver support
To add the Denali NAND driver support into U-Boot. It required
information such as register base address from configuration
header file within include/configs folder.
Signed-off-by: Chin Liang See cl...@altera.com
Cc: Artem Bityutskiy artem.bityuts...@linux.intel.com
Cc: David Woodhouse david.woodho...@intel.com
Cc: Brian Norris computersforpe...@gmail.com
Cc: Scott Wood scottw...@freescale.com
Cc: Masahiro Yamada yamad...@jp.panasonic.com
---
Changes for v5
- Rename denali_nand to denali only
- Rename the macro for ctrl and data address
Changes for v4
- Added cache flush to handle dcache enabled
- Used standard return where 0 for pass
- Removed unnecessary casting
- Used standard readl and writel
Changes for v3
- Fixed coding style
Changes for v2
- Enable this driver support for SOCFPGA
---
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/denali.c | 1144 +
drivers/mtd/nand/denali.h | 496
3 files changed, 1641 insertions(+)
create mode 100644 drivers/mtd/nand/denali.c
create mode 100644 drivers/mtd/nand/denali.h
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 02b149c..76ae105 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_NAND_ECC_BCH) += nand_bch.o
obj-$(CONFIG_NAND_ATMEL) += atmel_nand.o
obj-$(CONFIG_DRIVER_NAND_BFIN) += bfin_nand.o
obj-$(CONFIG_NAND_DAVINCI) += davinci_nand.o
+obj-$(CONFIG_NAND_DENALI) += denali.o
obj-$(CONFIG_NAND_FSL_ELBC) += fsl_elbc_nand.o
obj-$(CONFIG_NAND_FSL_IFC) += fsl_ifc_nand.o
obj-$(CONFIG_NAND_FSL_UPM) += fsl_upm.o
diff --git a/drivers/mtd/nand/denali.c b/drivers/mtd/nand/denali.c
new file mode 100644
index 000..7bda1e2
--- /dev/null
+++ b/drivers/mtd/nand/denali.c
@@ -0,0 +1,1144 @@
+/*
+ * Copyright (C) 2013-2014 Altera Corporation www.altera.com
+ * Copyright (C) 2009-2010, Intel Corporation and its suppliers.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include nand.h
+#include asm/errno.h
+#include asm/io.h
+
+#include denali.h
+
+#define NAND_DEFAULT_TIMINGS -1
+
+static struct denali_nand_info denali;
+static int onfi_timing_mode = NAND_DEFAULT_TIMINGS;
+
+/* We define a macro here that combines all interrupts this driver uses into
+ * a single constant value, for convenience. */
+#define DENALI_IRQ_ALL (INTR_STATUS__DMA_CMD_COMP | \
+ INTR_STATUS__ECC_TRANSACTION_DONE | \
+ INTR_STATUS__ECC_ERR | \
+ INTR_STATUS__PROGRAM_FAIL | \
+ INTR_STATUS__LOAD_COMP | \
+ INTR_STATUS__PROGRAM_COMP | \
+ INTR_STATUS__TIME_OUT | \
+ INTR_STATUS__ERASE_FAIL | \
+ INTR_STATUS__RST_COMP | \
+ INTR_STATUS__ERASE_COMP | \
+ INTR_STATUS__ECC_UNCOR_ERR | \
+ INTR_STATUS__INT_ACT | \
+ INTR_STATUS__LOCKED_BLK)
+
+/* indicates whether or not the internal value for the flash bank is
+ * valid or not */
+#define CHIP_SELECT_INVALID-1
+
+#define SUPPORT_8BITECC1
+
+/* These constants are defined by the driver to enable common driver
+ * configuration options. */
+#define SPARE_ACCESS 0x41
+#define MAIN_ACCESS0x42
+#define MAIN_SPARE_ACCESS 0x43
+
+#define DENALI_UNLOCK_START0x10
+#define DENALI_UNLOCK_END 0x11
+#define DENALI_LOCK0x21
+#define DENALI_LOCK_TIGHT 0x31
+#define DENALI_BUFFER_LOAD 0x60
+#define DENALI_BUFFER_WRITE0x62
+
+#define DENALI_READ0
+#define DENALI_WRITE 0x100
+
+/* types of device accesses. We can issue commands and get status */
+#define COMMAND_CYCLE 0
+#define ADDR_CYCLE 1
+#define STATUS_CYCLE 2
+
+/* this is a helper macro that allows us to
+ * format the bank into the proper bits for the controller */
+#define BANK(x) ((x) 24)
+
+/* Interrupts are cleared by writing a 1 to the appropriate status bit */
+static inline void clear_interrupt(uint32_t irq_mask)
+{
+ uint32_t intr_status_reg = 0;
+ intr_status_reg = INTR_STATUS(denali.flash_bank);
+ writel(irq_mask, denali.flash_reg + intr_status_reg);
+}
+
+static uint32_t read_interrupt_status(void)
+{
+ uint32_t intr_status_reg = 0;
+ intr_status_reg = INTR_STATUS(denali.flash_bank);
+ return readl(denali.flash_reg + intr_status_reg);
+}
+
+static void clear_interrupts(void)
+{
+ uint32_t status = 0;
+ status = read_interrupt_status();
+ clear_interrupt(status);
+ denali.irq_status = 0;
+}
+
+static void denali_irq_enable(uint32_t int_mask)
+{
+ int i;
+ for (i = 0; i denali.max_banks; ++i)
+ writel(int_mask, denali.flash_reg + INTR_EN(i));
+}
+
+static uint32_t wait_for_irq(uint32_t irq_mask)
+{
+ unsigned long timeout = 100;
+ uint32_t intr_status;
+
+ do {
+
Re: [U-Boot] [PATCH v4 1/2] nand/denali: Adding Denali NAND driver support
Hi Mashiro, On Mon, 2014-03-10 at 11:42 +0900, Masahiro Yamada wrote: Hello Chin, I've posted my feedback. I hope it is helpful for you. http://patchwork.ozlabs.org/patch/327943/ Great, I will patch them. From the patch, I saw your DMA sequence code and the discrepancy. For the data portion, I spotted you set the bit 31:16. But inside my datasheet, its marked as reserved. Wonder the version of Denali controller I have is older? Probably we can probe the Cadence then. At same time, I will send out new patch to capture the fix before forget. Yes, please. I am interested in this mystery. I really suspect there are some incompatible versions in Denali IP. I sent a question about this to Cadence. They did not admit it. (But I doubt it.) By the way, Panasonic have been using Denali NAND controller IP since 2010. I refer to Denali NAND Flash Memory Controller User's Guide issued on Nov. 30, 2010. Unfortunately, I can not share it because it is marked as confidential. Yup, me too. My one is having same title but dated Feb 28, 2011. I also checked the latest Feb 14, 2013 and it matched with 2011. Seems they changed in between 2010 and 2011. Wonder you have any newer version? To work around this, I presume we might to have some #if #else to separate the version differences. Thanks Chin Liang 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][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
On Fri, 2014-03-07 at 11:07 -0800, York Sun wrote: On 03/07/2014 11:00 AM, Scott Wood wrote: On Fri, 2014-03-07 at 10:58 -0800, York Sun wrote: On 03/07/2014 10:54 AM, Scott Wood wrote: On Fri, 2014-03-07 at 10:30 -0800, York Sun wrote: On 03/07/2014 05:23 AM, Aneesh Bansal wrote: Changes: 1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation from start.S 2. Clear the LAW and corresponding configuration for CPC. Boot ROM code uses it as hosekeeping area. 3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening in cpu_init_r. As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes. Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- README | 4 arch/powerpc/cpu/mpc85xx/cpu_init.c| 27 ++- arch/powerpc/cpu/mpc85xx/start.S | 3 ++- arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++ boards.cfg | 1 + 5 files changed, 35 insertions(+), 6 deletions(-) Changes from v3: Renamed the macro to indicate CPC configured as SRAM at U-boot entry to CONFIG_SYS_CPC_SRAM Aneesh, I understand you are trying to address the comment about when CPC needs to be disabled before initializing as normal CPC. But introducing CONFIG_SYS_CPC_SRAM seems even more confusing. Let's take one step back. CPC as SRAM can be used for many reasons. There is only one reason we should keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. For all other usages, we can safely reconfigure it as normal CPC after u-boot relocates itself into DDR. If u-boot's final destination is SRAM, it is a RAMBOOT. Can we use this condition to deal with CPC? Even if CPC is the final destination, shouldn't RAMBOOT imply that DDR has been initialized? No. RAMBOOT implies u-boot shouldn't initialize RAM. There may be cases where u-boot needs to run in SRAM without DDR. It doesn't matter if the RAM is SRAM or DRAM. There are some situations where we run U-Boot out of SRAM without relocating to DDR, but I can't think of a situation where we wouldn't want to use DDR at all (e.g. for loading an OS to). I generally agree with you. Loading OS needs more RAM. I am trying to simplify the condition to reinitialize CPC. My point is only one situation requires the CPC to act as SRAM. We can brainstorm how useful it is. For example, as a recovery method if using JTAG tool to enable CPC as SRAM and to load u-boot into it, one can skip the steps to initialize DDR to run an full-feature u-boot and reflash the board. What's relevant isn't whether there is a use case for not needing DDR, but whether there's a use case for having a special build of U-Boot that skips initializing DDR. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
On Mon, 2014-03-10 at 08:38 -0700, York Sun wrote: On 03/10/2014 02:14 AM, Bansal Aneesh-B39320 wrote: -Original Message- From: Sun York-R58495 Sent: Saturday, March 08, 2014 12:01 AM To: Bansal Aneesh-B39320; u-boot@lists.denx.de Cc: Wood Scott-B07421 Subject: Re: [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS Do you see the need to disable CPC before relocation? You are doing so in this patch. Does the temporary LAW or address conflict with u-boot? Earlier we were disabling cpc in cpu_init_r. However since cache invalidation function was getting skipped in the process, it was causing random crashes. Skipping invalidation works in RAMBOOT scenario, however since we don’t have valid data when CPC is configured as cache for the secure boot scenario which is not RAMBOOT, these crashes were occurring in few platforms. As a result we had to move this disable code early in the sequence, so that invalidation of cache doesn’t get skipped. As I suggested, if you have to do this before relocation, a macro CONFIG_SYS_CPC_REINIT_F makes more sense. How hard would it be to check the status of CPC at runtime, or just unconditionally reinit (for non-ramboot)? I don't think I ever saw an answer to the question of what harm it does to leave CPC alone until the normal place where we init CPC. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot
On Mon, 2014-03-10 at 04:14 -0500, Bansal Aneesh-B39320 wrote: -Original Message- From: Sun York-R58495 Sent: Saturday, March 08, 2014 12:31 AM To: Bansal Aneesh-B39320 Cc: Wood Scott-B07421; Wolfgang Denk; u-boot@lists.denx.de; Gupta Ruchika-R66431 Subject: Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot On 03/07/2014 10:57 AM, Scott Wood wrote: On Thu, 2014-03-06 at 03:24 -0600, Bansal Aneesh-B39320 wrote: -Original Message- From: Wood Scott-B07421 Sent: Wednesday, March 05, 2014 11:30 PM To: Bansal Aneesh-B39320 Cc: Sun York-R58495; Wolfgang Denk; u-boot@lists.denx.de; Gupta Ruchika-R66431 Subject: Re: [U-Boot] [PATCH 1/3] powerpc/p1010rdb: SECURE BOOT- define CONFIG_SYS_RAMBOOT for NAND boot On Tue, 2014-03-04 at 23:30 -0600, Bansal Aneesh-B39320 wrote: Yes, in case of secure boot from NAND, the DRAM is initialized by the BootROM and complete u-boot image is copied from NAND to DRAM by the BootROM. So, it should be called RAMBOOT. DRAM or SRAM? Having ROM initialize DDR is a bit scary. -Scott It can be either DDR or SRAM. It is not hardcoded in BootROM to initialize DDR. This depends on the config words (CF_WORDS) in the CF_HEADER. The Boot ROM code parses the config words and programs the addresses with data values accordingly. The user may opt to initialize DDR and get the image copied onto DDR or configure CPC as SRAM and get the Image copied onto SRAM. On 1010, P1010? LS1010? Something else? the CPC size is not big enough to accommodate the U-boot image. So, currently the CF_WORDS are for DDR to be initialized and copy the image on DDR. Generally if SPD is present, it should be used to init DDR rather than using hardcoded values. If U-Boot doesn't fit in SRAM, you can use SPL instead of hardcoded init. I agree with Scott on this point. Using hardcoded values totally skip DDR driver. You don't only lose the flexibility of various speeds, you also skip all workarounds implemented in DDR driver. York Currently we are following the same approach which was there for SPI and SD on P1010 i.e hardcoded initialization of DDR in platforms like P1010, 9131/9132 using config words. I don't know about 9131/9132, but on P1010RDB we now use SPL to init DDR when booting from SPI/SD. In any case, we've always done it this way isn't really a good reason. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
On 03/10/2014 04:55 PM, Scott Wood wrote: On Mon, 2014-03-10 at 08:38 -0700, York Sun wrote: On 03/10/2014 02:14 AM, Bansal Aneesh-B39320 wrote: -Original Message- From: Sun York-R58495 Sent: Saturday, March 08, 2014 12:01 AM To: Bansal Aneesh-B39320; u-boot@lists.denx.de Cc: Wood Scott-B07421 Subject: Re: [PATCH][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS Do you see the need to disable CPC before relocation? You are doing so in this patch. Does the temporary LAW or address conflict with u-boot? Earlier we were disabling cpc in cpu_init_r. However since cache invalidation function was getting skipped in the process, it was causing random crashes. Skipping invalidation works in RAMBOOT scenario, however since we don’t have valid data when CPC is configured as cache for the secure boot scenario which is not RAMBOOT, these crashes were occurring in few platforms. As a result we had to move this disable code early in the sequence, so that invalidation of cache doesn’t get skipped. As I suggested, if you have to do this before relocation, a macro CONFIG_SYS_CPC_REINIT_F makes more sense. How hard would it be to check the status of CPC at runtime, or just unconditionally reinit (for non-ramboot)? That's what I was suggesting. I don't think I ever saw an answer to the question of what harm it does to leave CPC alone until the normal place where we init CPC. Aneesh seems to believe disabling and re-initializing CPC in cpu_inti_r is too late for SECURE BOOT. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 12/12] kbuild: delete SPLTREE and TPLTREE
These variable are no longer used. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Makefile | 4 1 file changed, 4 deletions(-) diff --git a/Makefile b/Makefile index fa1e0ae..c8d5ccc 100644 --- a/Makefile +++ b/Makefile @@ -165,10 +165,6 @@ VPATH := $(srctree)$(if $(KBUILD_EXTMOD),:$(KBUILD_EXTMOD)) export srctree objtree VPATH -SPLTREE:= $(objtree)/spl -TPLTREE:= $(objtree)/tpl -export SPLTREE TPLTREE - MKCONFIG := $(srctree)/mkconfig export MKCONFIG -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/12] kbuild: use short logs for some board specific make rules
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: David Updegraff d...@cray.com Cc: Andre Schwarz andre.schw...@matrix-vision.de --- board/cray/L1/Makefile | 15 --- board/matrix_vision/mvblm7/Makefile | 8 +++- board/matrix_vision/mvsmr/Makefile | 8 +++- 3 files changed, 26 insertions(+), 5 deletions(-) diff --git a/board/cray/L1/Makefile b/board/cray/L1/Makefile index 63f43da..655f530 100644 --- a/board/cray/L1/Makefile +++ b/board/cray/L1/Makefile @@ -9,10 +9,19 @@ obj-y = L1.o flash.o obj-y += init.o obj-y += bootscript.o -$(obj)/bootscript.c: $(obj)/bootscript.image - od -t x1 -v -A x $^ | awk -f $(srctree)/$(src)/x2c.awk $@ +quiet_cmd_awk = AWK $@ + cmd_awk = od -t x1 -v -A x $ | $(AWK) -f $(filter-out $,$^) $@ +$(obj)/bootscript.c: $(obj)/bootscript.image $(src)/x2c.awk + $(call cmd,awk) + +quiet_cmd_mkimage = UIMAGE $@ +cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $ $@ \ +$(if $(KBUILD_VERBOSE:1=), /dev/null) + +MKIMAGEFLAGS_bootscript.image := -A ppc -O linux -T script -C none \ + -a 0 -e 0 -n bootscript $(obj)/bootscript.image: $(src)/bootscript.hush - -$(OBJTREE)/tools/mkimage -A ppc -O linux -T script -C none -a 0 -e 0 -n bootscript -d $ $@ + $(call cmd,mkimage) clean-files := bootscript.c bootscript.image \ No newline at end of file diff --git a/board/matrix_vision/mvblm7/Makefile b/board/matrix_vision/mvblm7/Makefile index 1bc1d61..b5987fd 100644 --- a/board/matrix_vision/mvblm7/Makefile +++ b/board/matrix_vision/mvblm7/Makefile @@ -8,5 +8,11 @@ obj-y := mvblm7.o pci.o fpga.o extra-y := bootscript.img +quiet_cmd_mkimage = UIMAGE $@ +cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $ $@ \ +$(if $(KBUILD_VERBOSE:1=), /dev/null) + +MKIMAGEFLAGS_bootscript.image := -T script -C none -n M7_script + $(obj)/bootscript.img: $(src)/bootscript - @mkimage -T script -C none -n M7_script -d $ $@ + $(call cmd,mkimage) diff --git a/board/matrix_vision/mvsmr/Makefile b/board/matrix_vision/mvsmr/Makefile index 9454259..fae7ec2 100644 --- a/board/matrix_vision/mvsmr/Makefile +++ b/board/matrix_vision/mvsmr/Makefile @@ -12,5 +12,11 @@ obj-y:= mvsmr.o fpga.o extra-y := bootscript.img +quiet_cmd_mkimage = UIMAGE $@ +cmd_mkimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -d $ $@ \ +$(if $(KBUILD_VERBOSE:1=), /dev/null) + +MKIMAGEFLAGS_bootscript.image := -T script -C none -n mvSMR_Script + $(obj)/bootscript.img: $(src)/bootscript - @mkimage -T script -C none -n mvSMR_Script -d $ $@ + $(call cmd,mkimage) -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/12] kbuild: use $(KBUILD_SRC) to check out-of-tree build
Non-empty $(KBUILD_SRC) means out-of-tree build.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Makefile | 8 +++-
mkconfig | 4 ++--
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/Makefile b/Makefile
index 8a1fe9b..1b1cfb8 100644
--- a/Makefile
+++ b/Makefile
@@ -556,11 +556,9 @@ export CONFIG_SYS_TEXT_BASE
# Use UBOOTINCLUDE when you must reference the include/ directory.
# Needed to be compatible with the O= option
-UBOOTINCLUDE:=
-ifneq ($(OBJTREE),$(SRCTREE))
-UBOOTINCLUDE += -I$(OBJTREE)/include
-endif
-UBOOTINCLUDE += -I$(srctree)/include \
+UBOOTINCLUDE:= \
+ -Iinclude \
+ $(if $(KBUILD_SRC), -I$(srctree)/include) \
-I$(srctree)/arch/$(ARCH)/include
NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
diff --git a/mkconfig b/mkconfig
index 9827e4d..b755d2a 100755
--- a/mkconfig
+++ b/mkconfig
@@ -103,7 +103,7 @@ fi
#
# Create link to architecture specific headers
#
-if [ $SRCTREE != $OBJTREE ] ; then
+if [ -n $KBUILD_SRC ] ; then
mkdir -p ${OBJTREE}/include
LNPREFIX=${SRCTREE}/arch/${arch}/include/asm/
cd ${OBJTREE}/include
@@ -125,7 +125,7 @@ if [ ${arch} = arm ] ; then
ln -s ${LNPREFIX}proc-armv asm/proc
fi
-if [ $SRCTREE = $OBJTREE ] ; then
+if [ -z $KBUILD_SRC ] ; then
cd ${SRCTREE}/include
fi
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/12] Kbuild: A collection of more refactoring
- Convert more make rules to Kbuild style to use short logs.
- Consolidate TOPDIR, OBJTREE, SRCTREE
- Other minor refactoring
Masahiro Yamada (12):
kbuild,mxs: use short logs for MXS images
kbuild: use short logs for some board specific make rules
kbuild,x86: use a short log for arch/x86/lib/libgcc.a
x86: specify CONFIG_USE_PRIVATE_LIBGCC more simply
kbuild: delete redundant LDSCRIPT definition
freescale: pblimage: refactor CONFIG_SYS_FSL_PBL_{PBI,RCW}
kirkwood: kwbimage: refactor CONFIG_SYS_KWD_CONFIG
kbuild: use $(KBUILD_SRC) to check out-of-tree build
kbuild: rename TOPDIR to stctree
kbuild: rename SRCTREE to srctree
kbuild: rename OBJTREE to objtree
kbuild: delete SPLTREE and TPLTREE
Makefile | 43 +++
arch/arc/config.mk| 2 --
arch/arm/cpu/arm926ejs/mxs/Makefile | 13
arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg | 4 +--
arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg | 4 +--
arch/arm/cpu/arm926ejs/mxs/u-boot-imx23.bd| 4 +--
arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd| 4 +--
arch/arm/include/asm/arch-kirkwood/config.h | 2 +-
arch/m68k/cpu/mcf52x2/config.mk | 16 +-
arch/m68k/cpu/mcf532x/config.mk | 6 ++--
arch/m68k/cpu/mcf5445x/config.mk | 4 +--
arch/microblaze/config.mk | 2 --
arch/openrisc/config.mk | 2 --
arch/powerpc/cpu/ppc4xx/config.mk | 4 +--
arch/x86/config.mk| 4 +--
arch/x86/lib/Makefile | 5 ++--
board/ait/cam_enc_4xx/config.mk | 2 +-
board/avnet/fx12mm/Makefile | 2 +-
board/avnet/v5fx30teval/Makefile | 2 +-
board/cray/L1/Makefile| 15 --
board/hymod/config.mk | 2 +-
board/korat/config.mk | 2 +-
board/matrix_vision/mvblm7/Makefile | 8 -
board/matrix_vision/mvsmr/Makefile| 8 -
board/xilinx/ml507/Makefile | 2 +-
config.mk | 10 +++
doc/README.SPL| 2 +-
doc/README.TPL| 2 +-
doc/README.commands | 2 +-
doc/README.kwbimage | 2 +-
include/configs/B4860QDS.h| 4 +--
include/configs/P2041RDB.h| 5 ++--
include/configs/T1040QDS.h| 4 +--
include/configs/T208xQDS.h| 6 ++--
include/configs/T208xRDB.h| 4 +--
include/configs/T4240QDS.h| 4 +--
include/configs/corenet_ds.h | 14 -
include/configs/km/kmp204x-common.h | 4 +--
include/configs/km_kirkwood.h | 15 --
include/configs/lacie_kw.h| 4 +--
include/configs/lsxl.h| 4 +--
mkconfig | 12
nand_spl/board/freescale/mpc8315erdb/Makefile | 22 +++---
nand_spl/board/freescale/mpc8536ds/Makefile | 28 -
nand_spl/board/freescale/mpc8569mds/Makefile | 28 -
nand_spl/board/freescale/mpc8572ds/Makefile | 28 -
nand_spl/board/freescale/p1023rds/Makefile| 28 -
nand_spl/board/freescale/p1_p2_rdb/Makefile | 28 -
nand_spl/board/sheldon/simpc8313/Makefile | 22 +++---
spl/Makefile | 22 +++---
tools/Makefile| 6 ++--
tools/env/Makefile| 2 +-
52 files changed, 235 insertions(+), 239 deletions(-)
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/12] kbuild: rename TOPDIR to stctree
Prior to Kbuild, $(TOPDIR) or $(SRCTREE) was used for pointing to the top of source directory. (No difference between the two.) In Kbuild style, $(srctree) is used instead. This commit renames TOPDIR to srctree and delete the defition of TOPDIR. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- Makefile | 19 +-- arch/m68k/cpu/mcf52x2/config.mk | 14 +++--- arch/m68k/cpu/mcf532x/config.mk | 4 ++-- arch/m68k/cpu/mcf5445x/config.mk | 2 +- arch/powerpc/cpu/ppc4xx/config.mk | 2 +- board/hymod/config.mk | 2 +- board/korat/config.mk | 2 +- config.mk | 8 doc/README.SPL| 2 +- doc/README.TPL| 2 +- doc/README.commands | 2 +- nand_spl/board/freescale/mpc8315erdb/Makefile | 2 +- nand_spl/board/freescale/mpc8536ds/Makefile | 2 +- nand_spl/board/freescale/mpc8569mds/Makefile | 2 +- nand_spl/board/freescale/mpc8572ds/Makefile | 2 +- nand_spl/board/freescale/p1023rds/Makefile| 2 +- nand_spl/board/freescale/p1_p2_rdb/Makefile | 2 +- nand_spl/board/sheldon/simpc8313/Makefile | 2 +- spl/Makefile | 10 +- 19 files changed, 41 insertions(+), 42 deletions(-) diff --git a/Makefile b/Makefile index 1b1cfb8..f18f3eb 100644 --- a/Makefile +++ b/Makefile @@ -169,8 +169,7 @@ OBJTREE := $(objtree) SPLTREE:= $(OBJTREE)/spl TPLTREE:= $(OBJTREE)/tpl SRCTREE:= $(srctree) -TOPDIR := $(SRCTREE) -export TOPDIR SRCTREE OBJTREE SPLTREE TPLTREE +export SRCTREE OBJTREE SPLTREE TPLTREE MKCONFIG := $(SRCTREE)/mkconfig export MKCONFIG @@ -490,7 +489,7 @@ endif # standard location. ifndef LDSCRIPT - #LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds.debug + #LDSCRIPT := $(srctree)/board/$(BOARDDIR)/u-boot.lds.debug ifdef CONFIG_SYS_LDSCRIPT # need to strip off double quotes LDSCRIPT := $(srctree)/$(CONFIG_SYS_LDSCRIPT:%=%) @@ -500,19 +499,19 @@ endif # If there is no specified link script, we look in a number of places for it ifndef LDSCRIPT ifeq ($(CONFIG_NAND_U_BOOT),y) - LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot-nand.lds + LDSCRIPT := $(srctree)/board/$(BOARDDIR)/u-boot-nand.lds ifeq ($(wildcard $(LDSCRIPT)),) - LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot-nand.lds + LDSCRIPT := $(srctree)/$(CPUDIR)/u-boot-nand.lds endif endif ifeq ($(wildcard $(LDSCRIPT)),) - LDSCRIPT := $(TOPDIR)/board/$(BOARDDIR)/u-boot.lds + LDSCRIPT := $(srctree)/board/$(BOARDDIR)/u-boot.lds endif ifeq ($(wildcard $(LDSCRIPT)),) - LDSCRIPT := $(TOPDIR)/$(CPUDIR)/u-boot.lds + LDSCRIPT := $(srctree)/$(CPUDIR)/u-boot.lds endif ifeq ($(wildcard $(LDSCRIPT)),) - LDSCRIPT := $(TOPDIR)/arch/$(ARCH)/cpu/u-boot.lds + LDSCRIPT := $(srctree)/arch/$(ARCH)/cpu/u-boot.lds endif endif @@ -666,7 +665,7 @@ export PLATFORM_LIBS # Pass the version down so we can handle backwards compatibility # on the fly. LDPPFLAGS += \ - -include $(TOPDIR)/include/u-boot/u-boot.lds.h \ + -include $(srctree)/include/u-boot/u-boot.lds.h \ -DCPUDIR=$(CPUDIR) \ $(shell $(LD) --version | \ sed -ne 's/GNU ld version \([0-9][0-9]*\)\.\([0-9][0-9]*\).*/-DLD_MAJOR=\1 -DLD_MINOR=\2/p') @@ -1240,7 +1239,7 @@ distclean: mrproper -type f -print | xargs rm -f backup: - F=`basename $(TOPDIR)` ; cd .. ; \ + F=`basename $(srctree)` ; cd .. ; \ gtar --force-local -zcvf `LC_ALL=C date +$$F-%Y-%m-%d-%T.tar.gz` $$F help: diff --git a/arch/m68k/cpu/mcf52x2/config.mk b/arch/m68k/cpu/mcf52x2/config.mk index 25f98de..ebf75e6 100644 --- a/arch/m68k/cpu/mcf52x2/config.mk +++ b/arch/m68k/cpu/mcf52x2/config.mk @@ -8,13 +8,13 @@ # cfg=$(shell grep configs $(OBJTREE)/include/config.h | sed 's/.*\(configs.*\)/\1/') -is5208:=$(shell grep CONFIG_M5208 $(TOPDIR)/include/$(cfg)) -is5249:=$(shell grep CONFIG_M5249 $(TOPDIR)/include/$(cfg)) -is5253:=$(shell grep CONFIG_M5253 $(TOPDIR)/include/$(cfg)) -is5271:=$(shell grep CONFIG_M5271 $(TOPDIR)/include/$(cfg)) -is5272:=$(shell grep CONFIG_M5272 $(TOPDIR)/include/$(cfg)) -is5275:=$(shell grep CONFIG_M5275 $(TOPDIR)/include/$(cfg)) -is5282:=$(shell grep CONFIG_M5282 $(TOPDIR)/include/$(cfg)) +is5208:=$(shell grep CONFIG_M5208 $(srctree)/include/$(cfg)) +is5249:=$(shell grep CONFIG_M5249 $(srctree)/include/$(cfg)) +is5253:=$(shell grep CONFIG_M5253 $(srctree)/include/$(cfg)) +is5271:=$(shell grep CONFIG_M5271
[U-Boot] [PATCH 05/12] kbuild: delete redundant LDSCRIPT definition
$(SRCTREE)/$(CPUDIR)/u-boot.lds is our default location
of arch-specific linker script.
Remove redundant definitions in
arch/{arc,microblaze,openrisc}/config.mk.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Alexey Brodkin alexey.brod...@synopsys.com
Cc: Michal Simek michal.si...@xilinx.com
Cc: Stefan Kristiansson stefan.kristians...@saunalahti.fi
---
arch/arc/config.mk| 2 --
arch/microblaze/config.mk | 2 --
arch/openrisc/config.mk | 2 --
3 files changed, 6 deletions(-)
diff --git a/arch/arc/config.mk b/arch/arc/config.mk
index d9f5d9d..a3b8df7 100644
--- a/arch/arc/config.mk
+++ b/arch/arc/config.mk
@@ -23,8 +23,6 @@ endif
PLATFORM_CPPFLAGS += -ffixed-r25 -D__ARC__ -DCONFIG_ARC -gdwarf-2
-LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds
-
# Needed for relocation
LDFLAGS_FINAL += -pie
diff --git a/arch/microblaze/config.mk b/arch/microblaze/config.mk
index cdb321a..98bbf79 100644
--- a/arch/microblaze/config.mk
+++ b/arch/microblaze/config.mk
@@ -15,5 +15,3 @@ endif
CONFIG_STANDALONE_LOAD_ADDR ?= 0x80F0
PLATFORM_CPPFLAGS += -ffixed-r31 -D__microblaze__
-
-LDSCRIPT ?= $(SRCTREE)/$(CPUDIR)/u-boot.lds
diff --git a/arch/openrisc/config.mk b/arch/openrisc/config.mk
index 981edff..9902b9a 100644
--- a/arch/openrisc/config.mk
+++ b/arch/openrisc/config.mk
@@ -14,5 +14,3 @@ endif
PLATFORM_CPPFLAGS += -DCONFIG_OPENRISC -D__OR1K__ -ffixed-r10
CONFIG_STANDALONE_LOAD_ADDR ?= 0x4
-
-LDSCRIPT ?= $(SRCTREE)/$(CPUDIR)/u-boot.lds
--
1.8.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/12] x86: specify CONFIG_USE_PRIVATE_LIBGCC more simply
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Simon Glass s...@chromium.org --- arch/x86/config.mk | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/x86/config.mk b/arch/x86/config.mk index 1e52a5e..38cb7c9 100644 --- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -29,6 +29,4 @@ LDFLAGS_FINAL += --wrap=__divdi3 --wrap=__udivdi3 LDFLAGS_FINAL += --wrap=__moddi3 --wrap=__umoddi3 export NORMAL_LIBGCC = $(shell $(CC) $(CFLAGS) -print-libgcc-file-name) -PREFIXED_LIBGCC = $(OBJTREE)/arch/$(ARCH)/lib/$(shell basename $(NORMAL_LIBGCC)) - -CONFIG_USE_PRIVATE_LIBGCC=$(shell dirname $(PREFIXED_LIBGCC)) +CONFIG_USE_PRIVATE_LIBGCC := arch/x86/lib -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 06/12] freescale: pblimage: refactor CONFIG_SYS_FSL_PBL_{PBI, RCW}
Pull out $(SRCTREE)/ from CONFIG_SYS_FSL_PBL_PBI and CONFIG_SYS_FSL_PBL_RCW and push it into the top Makefile. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: York Sun york...@freescale.com Cc: Poonam Aggrwal poonam.aggr...@freescale.com Cc: Valentin Longchamp valentin.longch...@keymile.com --- Makefile| 4 ++-- include/configs/B4860QDS.h | 4 ++-- include/configs/P2041RDB.h | 5 ++--- include/configs/T1040QDS.h | 4 ++-- include/configs/T208xQDS.h | 6 +++--- include/configs/T208xRDB.h | 4 ++-- include/configs/T4240QDS.h | 4 ++-- include/configs/corenet_ds.h| 14 +- include/configs/km/kmp204x-common.h | 4 ++-- 9 files changed, 22 insertions(+), 27 deletions(-) diff --git a/Makefile b/Makefile index 0df3780..198efa3 100644 --- a/Makefile +++ b/Makefile @@ -805,8 +805,8 @@ MKIMAGEFLAGS_u-boot.img = -A $(ARCH) -T firmware -C none -O u-boot \ MKIMAGEFLAGS_u-boot.kwb = -n $(CONFIG_SYS_KWD_CONFIG) -T kwbimage \ -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) -MKIMAGEFLAGS_u-boot.pbl = -n $(CONFIG_SYS_FSL_PBL_RCW) \ - -R $(CONFIG_SYS_FSL_PBL_PBI) -T pblimage +MKIMAGEFLAGS_u-boot.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:%=%) \ + -R $(srctree)/$(CONFIG_SYS_FSL_PBL_PBI:%=%) -T pblimage u-boot.img u-boot.kwb u-boot.pbl: u-boot.bin FORCE $(call if_changed,mkimage) diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h index 64acc88..b248302 100644 --- a/include/configs/B4860QDS.h +++ b/include/configs/B4860QDS.h @@ -16,8 +16,8 @@ #ifdef CONFIG_RAMBOOT_PBL #define CONFIG_RAMBOOT_TEXT_BASE CONFIG_SYS_TEXT_BASE #define CONFIG_RESET_VECTOR_ADDRESS0xfffc -#define CONFIG_SYS_FSL_PBL_PBI $(SRCTREE)/board/freescale/b4860qds/b4_pbi.cfg -#define CONFIG_SYS_FSL_PBL_RCW $(SRCTREE)/board/freescale/b4860qds/b4_rcw.cfg +#define CONFIG_SYS_FSL_PBL_PBI board/freescale/b4860qds/b4_pbi.cfg +#define CONFIG_SYS_FSL_PBL_RCW board/freescale/b4860qds/b4_rcw.cfg #endif #ifdef CONFIG_SRIO_PCIE_BOOT_SLAVE diff --git a/include/configs/P2041RDB.h b/include/configs/P2041RDB.h index 47c6384..b3880f1 100644 --- a/include/configs/P2041RDB.h +++ b/include/configs/P2041RDB.h @@ -18,9 +18,8 @@ #ifdef CONFIG_RAMBOOT_PBL #define CONFIG_RAMBOOT_TEXT_BASE CONFIG_SYS_TEXT_BASE #define CONFIG_RESET_VECTOR_ADDRESS0xfffc -#define CONFIG_SYS_FSL_PBL_PBI $(SRCTREE)/board/freescale/corenet_ds/pbi.cfg -#define CONFIG_SYS_FSL_PBL_RCW \ - $(SRCTREE)/board/freescale/corenet_ds/rcw_p2041rdb.cfg +#define CONFIG_SYS_FSL_PBL_PBI board/freescale/corenet_ds/pbi.cfg +#define CONFIG_SYS_FSL_PBL_RCW board/freescale/corenet_ds/rcw_p2041rdb.cfg #endif #ifdef CONFIG_SRIO_PCIE_BOOT_SLAVE diff --git a/include/configs/T1040QDS.h b/include/configs/T1040QDS.h index e776a46..993f9ae 100644 --- a/include/configs/T1040QDS.h +++ b/include/configs/T1040QDS.h @@ -32,8 +32,8 @@ #ifdef CONFIG_RAMBOOT_PBL #define CONFIG_RAMBOOT_TEXT_BASE CONFIG_SYS_TEXT_BASE #define CONFIG_RESET_VECTOR_ADDRESS0xfffc -#define CONFIG_SYS_FSL_PBL_PBI $(SRCTREE)/board/freescale/t1040qds/t1040_pbi.cfg -#define CONFIG_SYS_FSL_PBL_RCW $(SRCTREE)/board/freescale/t1040qds/t1040_rcw.cfg +#define CONFIG_SYS_FSL_PBL_PBI board/freescale/t1040qds/t1040_pbi.cfg +#define CONFIG_SYS_FSL_PBL_RCW board/freescale/t1040qds/t1040_rcw.cfg #endif /* High Level Configuration Options */ diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h index c6a30db..399ddbb 100644 --- a/include/configs/T208xQDS.h +++ b/include/configs/T208xQDS.h @@ -48,11 +48,11 @@ #ifdef CONFIG_RAMBOOT_PBL #define CONFIG_RAMBOOT_TEXT_BASE CONFIG_SYS_TEXT_BASE #define CONFIG_RESET_VECTOR_ADDRESS0xfffc -#define CONFIG_SYS_FSL_PBL_PBI $(SRCTREE)/board/freescale/t208xqds/t208x_pbi.cfg +#define CONFIG_SYS_FSL_PBL_PBI board/freescale/t208xqds/t208x_pbi.cfg #if defined(CONFIG_PPC_T2080) -#define CONFIG_SYS_FSL_PBL_RCW $(SRCTREE)/board/freescale/t208xqds/t2080_rcw.cfg +#define CONFIG_SYS_FSL_PBL_RCW board/freescale/t208xqds/t2080_rcw.cfg #elif defined(CONFIG_PPC_T2081) -#define CONFIG_SYS_FSL_PBL_RCW $(SRCTREE)/board/freescale/t208xqds/t2081_rcw.cfg +#define CONFIG_SYS_FSL_PBL_RCW board/freescale/t208xqds/t2081_rcw.cfg #endif #endif diff --git a/include/configs/T208xRDB.h b/include/configs/T208xRDB.h index 979843b..743eee3 100644 --- a/include/configs/T208xRDB.h +++ b/include/configs/T208xRDB.h @@ -41,8 +41,8 @@ #ifdef CONFIG_RAMBOOT_PBL #define CONFIG_RAMBOOT_TEXT_BASE CONFIG_SYS_TEXT_BASE #define CONFIG_RESET_VECTOR_ADDRESS0xfffc -#define CONFIG_SYS_FSL_PBL_PBI $(SRCTREE)/board/freescale/t208xrdb/t2080_pbi.cfg -#define CONFIG_SYS_FSL_PBL_RCW $(SRCTREE)/board/freescale/t208xrdb/t2080_rcw.cfg +#define CONFIG_SYS_FSL_PBL_PBI board/freescale/t208xrdb/t2080_pbi.cfg +#define CONFIG_SYS_FSL_PBL_RCW
[U-Boot] [PATCH 10/12] kbuild: rename SRCTREE to srctree
Prior to Kbuild, $(TOPDIR) or $(SRCTREE) was used for
pointing to the top of source directory.
(No difference between the two.)
In Kbuild style, $(srctree) is used for instead.
This commit renames SRCTREE to srctree and deletes the
defition of SRCTREE.
Note that SRCTREE in scripts/kernel-doc, scripts/docproc.c,
doc/DocBook/Makefile should be keep.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Makefile | 5 ++---
board/ait/cam_enc_4xx/config.mk | 2 +-
board/avnet/fx12mm/Makefile | 2 +-
board/avnet/v5fx30teval/Makefile | 2 +-
board/xilinx/ml507/Makefile | 2 +-
config.mk | 2 +-
mkconfig | 4 ++--
nand_spl/board/freescale/mpc8315erdb/Makefile | 18 +-
nand_spl/board/freescale/mpc8536ds/Makefile | 24
nand_spl/board/freescale/mpc8569mds/Makefile | 24
nand_spl/board/freescale/mpc8572ds/Makefile | 24
nand_spl/board/freescale/p1023rds/Makefile| 24
nand_spl/board/freescale/p1_p2_rdb/Makefile | 24
nand_spl/board/sheldon/simpc8313/Makefile | 18 +-
spl/Makefile | 4 ++--
tools/Makefile| 6 +++---
tools/env/Makefile| 2 +-
17 files changed, 93 insertions(+), 94 deletions(-)
diff --git a/Makefile b/Makefile
index f18f3eb..a8ca5e9 100644
--- a/Makefile
+++ b/Makefile
@@ -168,10 +168,9 @@ export srctree objtree VPATH
OBJTREE:= $(objtree)
SPLTREE:= $(OBJTREE)/spl
TPLTREE:= $(OBJTREE)/tpl
-SRCTREE:= $(srctree)
-export SRCTREE OBJTREE SPLTREE TPLTREE
+export OBJTREE SPLTREE TPLTREE
-MKCONFIG := $(SRCTREE)/mkconfig
+MKCONFIG := $(srctree)/mkconfig
export MKCONFIG
# Make sure CDPATH settings don't interfere
diff --git a/board/ait/cam_enc_4xx/config.mk b/board/ait/cam_enc_4xx/config.mk
index c7cfaca..2022151 100644
--- a/board/ait/cam_enc_4xx/config.mk
+++ b/board/ait/cam_enc_4xx/config.mk
@@ -7,7 +7,7 @@
# (mem base + reserved)
#
-UBL_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/ublimage.cfg
+UBL_CONFIG = $(srctree)/board/$(BOARDDIR)/ublimage.cfg
ifndef CONFIG_SPL_BUILD
ALL-y += u-boot.ubl
else
diff --git a/board/avnet/fx12mm/Makefile b/board/avnet/fx12mm/Makefile
index 37fb02f..618b42f 100644
--- a/board/avnet/fx12mm/Makefile
+++ b/board/avnet/fx12mm/Makefile
@@ -8,4 +8,4 @@
obj-y += fx12mm.o
-include $(SRCTREE)/board/xilinx/ppc405-generic/Makefile
+include $(srctree)/board/xilinx/ppc405-generic/Makefile
diff --git a/board/avnet/v5fx30teval/Makefile b/board/avnet/v5fx30teval/Makefile
index f7d0417..8c41af0 100644
--- a/board/avnet/v5fx30teval/Makefile
+++ b/board/avnet/v5fx30teval/Makefile
@@ -8,4 +8,4 @@
obj-y += v5fx30teval.o
-include $(SRCTREE)/board/xilinx/ppc440-generic/Makefile
+include $(srctree)/board/xilinx/ppc440-generic/Makefile
diff --git a/board/xilinx/ml507/Makefile b/board/xilinx/ml507/Makefile
index 3c84651..9a3809f 100644
--- a/board/xilinx/ml507/Makefile
+++ b/board/xilinx/ml507/Makefile
@@ -8,4 +8,4 @@
obj-y += ml507.o
-include $(SRCTREE)/board/xilinx/ppc440-generic/Makefile
+include $(srctree)/board/xilinx/ppc440-generic/Makefile
diff --git a/config.mk b/config.mk
index 9bf4eda..05864aa 100644
--- a/config.mk
+++ b/config.mk
@@ -25,7 +25,7 @@ OBJCOPYFLAGS :=
# Check if arch/$ARCH/cpu/$CPU exists, otherwise assume arch/$ARCH/cpu contains
# CPU-specific code.
CPUDIR=arch/$(ARCH)/cpu/$(CPU)
-ifneq ($(SRCTREE)/$(CPUDIR),$(wildcard $(SRCTREE)/$(CPUDIR)))
+ifneq ($(srctree)/$(CPUDIR),$(wildcard $(srctree)/$(CPUDIR)))
CPUDIR=arch/$(ARCH)/cpu
endif
diff --git a/mkconfig b/mkconfig
index b755d2a..17ff298 100755
--- a/mkconfig
+++ b/mkconfig
@@ -105,7 +105,7 @@ fi
#
if [ -n $KBUILD_SRC ] ; then
mkdir -p ${OBJTREE}/include
- LNPREFIX=${SRCTREE}/arch/${arch}/include/asm/
+ LNPREFIX=${srctree}/arch/${arch}/include/asm/
cd ${OBJTREE}/include
mkdir -p asm
else
@@ -126,7 +126,7 @@ if [ ${arch} = arm ] ; then
fi
if [ -z $KBUILD_SRC ] ; then
- cd ${SRCTREE}/include
+ cd ${srctree}/include
fi
#
diff --git a/nand_spl/board/freescale/mpc8315erdb/Makefile
b/nand_spl/board/freescale/mpc8315erdb/Makefile
index 4eec00f..e3c87cf 100644
--- a/nand_spl/board/freescale/mpc8315erdb/Makefile
+++ b/nand_spl/board/freescale/mpc8315erdb/Makefile
@@ -44,28 +44,28 @@ $(nandobj)u-boot.lds: $(LDSCRIPT)
# create symbolic links for common files
$(obj)/start.S:
- ln -sf $(SRCTREE)/arch/powerpc/cpu/mpc83xx/start.S $@
+ ln -sf $(srctree)/arch/powerpc/cpu/mpc83xx/start.S $@
$(obj)/nand_boot_fsl_elbc.c:
- ln -sf $(SRCTREE)/nand_spl/nand_boot_fsl_elbc.c $@
+ ln -sf
[U-Boot] [PATCH 11/12] kbuild: rename OBJTREE to objtree
Prior to Kbuild, $(OBJTREE) was used for pointing to the
top of build directory with absolute path.
In Kbuild style, $(objtree) is used instead.
This commit renames OBJTREE to objtree and delete the
defition of OBJTREE.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
Makefile | 7 +++
arch/m68k/cpu/mcf52x2/config.mk | 2 +-
arch/m68k/cpu/mcf532x/config.mk | 2 +-
arch/m68k/cpu/mcf5445x/config.mk | 2 +-
arch/powerpc/cpu/ppc4xx/config.mk | 2 +-
mkconfig | 4 ++--
nand_spl/board/freescale/mpc8315erdb/Makefile | 2 +-
nand_spl/board/freescale/mpc8536ds/Makefile | 2 +-
nand_spl/board/freescale/mpc8569mds/Makefile | 2 +-
nand_spl/board/freescale/mpc8572ds/Makefile | 2 +-
nand_spl/board/freescale/p1023rds/Makefile| 2 +-
nand_spl/board/freescale/p1_p2_rdb/Makefile | 2 +-
nand_spl/board/sheldon/simpc8313/Makefile | 2 +-
spl/Makefile | 8
14 files changed, 20 insertions(+), 21 deletions(-)
diff --git a/Makefile b/Makefile
index a8ca5e9..fa1e0ae 100644
--- a/Makefile
+++ b/Makefile
@@ -165,10 +165,9 @@ VPATH := $(srctree)$(if
$(KBUILD_EXTMOD),:$(KBUILD_EXTMOD))
export srctree objtree VPATH
-OBJTREE:= $(objtree)
-SPLTREE:= $(OBJTREE)/spl
-TPLTREE:= $(OBJTREE)/tpl
-export OBJTREE SPLTREE TPLTREE
+SPLTREE:= $(objtree)/spl
+TPLTREE:= $(objtree)/tpl
+export SPLTREE TPLTREE
MKCONFIG := $(srctree)/mkconfig
export MKCONFIG
diff --git a/arch/m68k/cpu/mcf52x2/config.mk b/arch/m68k/cpu/mcf52x2/config.mk
index ebf75e6..34ad99e 100644
--- a/arch/m68k/cpu/mcf52x2/config.mk
+++ b/arch/m68k/cpu/mcf52x2/config.mk
@@ -7,7 +7,7 @@
# SPDX-License-Identifier: GPL-2.0+
#
-cfg=$(shell grep configs $(OBJTREE)/include/config.h | sed
's/.*\(configs.*\)/\1/')
+cfg=$(shell grep configs $(objtree)/include/config.h | sed
's/.*\(configs.*\)/\1/')
is5208:=$(shell grep CONFIG_M5208 $(srctree)/include/$(cfg))
is5249:=$(shell grep CONFIG_M5249 $(srctree)/include/$(cfg))
is5253:=$(shell grep CONFIG_M5253 $(srctree)/include/$(cfg))
diff --git a/arch/m68k/cpu/mcf532x/config.mk b/arch/m68k/cpu/mcf532x/config.mk
index 0a248c3..af94354 100644
--- a/arch/m68k/cpu/mcf532x/config.mk
+++ b/arch/m68k/cpu/mcf532x/config.mk
@@ -7,7 +7,7 @@
# SPDX-License-Identifier: GPL-2.0+
#
-cfg=$(shell grep configs $(OBJTREE)/include/config.h | sed
's/.*\(configs.*\)/\1/')
+cfg=$(shell grep configs $(objtree)/include/config.h | sed
's/.*\(configs.*\)/\1/')
is5301x:=$(shell grep CONFIG_MCF5301x $(srctree)/include/$(cfg))
is532x:=$(shell grep CONFIG_MCF532x $(srctree)/include/$(cfg))
diff --git a/arch/m68k/cpu/mcf5445x/config.mk b/arch/m68k/cpu/mcf5445x/config.mk
index 2f310a5..5fd0d4d 100644
--- a/arch/m68k/cpu/mcf5445x/config.mk
+++ b/arch/m68k/cpu/mcf5445x/config.mk
@@ -9,7 +9,7 @@
# SPDX-License-Identifier: GPL-2.0+
#
-cfg=$(shell grep configs $(OBJTREE)/include/config.h | sed
's/.*\(configs.*\)/\1/')
+cfg=$(shell grep configs $(objtree)/include/config.h | sed
's/.*\(configs.*\)/\1/')
is5441x:=$(shell grep CONFIG_MCF5441x $(srctree)/include/$(cfg))
ifneq (,$(findstring CONFIG_MCF5441x,$(is5441x)))
diff --git a/arch/powerpc/cpu/ppc4xx/config.mk
b/arch/powerpc/cpu/ppc4xx/config.mk
index 907a3dd..102f069 100644
--- a/arch/powerpc/cpu/ppc4xx/config.mk
+++ b/arch/powerpc/cpu/ppc4xx/config.mk
@@ -7,7 +7,7 @@
PLATFORM_CPPFLAGS += -DCONFIG_4xx -mstring -msoft-float
-cfg=$(shell grep configs $(OBJTREE)/include/config.h | sed
's/.*\(configs.*\)/\1/')
+cfg=$(shell grep configs $(objtree)/include/config.h | sed
's/.*\(configs.*\)/\1/')
is440:=$(shell grep CONFIG_440 $(srctree)/include/$(cfg))
ifneq (,$(findstring CONFIG_440,$(is440)))
diff --git a/mkconfig b/mkconfig
index 17ff298..cd911a9 100755
--- a/mkconfig
+++ b/mkconfig
@@ -104,9 +104,9 @@ fi
# Create link to architecture specific headers
#
if [ -n $KBUILD_SRC ] ; then
- mkdir -p ${OBJTREE}/include
+ mkdir -p ${objtree}/include
LNPREFIX=${srctree}/arch/${arch}/include/asm/
- cd ${OBJTREE}/include
+ cd ${objtree}/include
mkdir -p asm
else
cd arch/${arch}/include
diff --git a/nand_spl/board/freescale/mpc8315erdb/Makefile
b/nand_spl/board/freescale/mpc8315erdb/Makefile
index e3c87cf..f4e7854 100644
--- a/nand_spl/board/freescale/mpc8315erdb/Makefile
+++ b/nand_spl/board/freescale/mpc8315erdb/Makefile
@@ -8,7 +8,7 @@
PAD_TO := 0xfff04000
-nandobj:= $(OBJTREE)/nand_spl/
+nandobj:= $(objtree)/nand_spl/
LDSCRIPT= $(srctree)/nand_spl/board/$(BOARDDIR)/u-boot.lds
LDFLAGS := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE_SPL) \
diff --git a/nand_spl/board/freescale/mpc8536ds/Makefile
b/nand_spl/board/freescale/mpc8536ds/Makefile
index eefa44d..c639b12 100644
---
[U-Boot] [PATCH 03/12] kbuild, x86: use a short log for arch/x86/lib/libgcc.a
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Simon Glass s...@chromium.org --- arch/x86/lib/Makefile | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile index a35d062..f7303ab 100644 --- a/arch/x86/lib/Makefile +++ b/arch/x86/lib/Makefile @@ -23,5 +23,6 @@ obj-$(CONFIG_CMD_ZBOOT) += zimage.o LIBGCC := $(notdir $(NORMAL_LIBGCC)) extra-y := $(LIBGCC) -$(obj)/$(LIBGCC): $(NORMAL_LIBGCC) - $(OBJCOPY) $ $@ --prefix-symbols=__normal_ +OBJCOPYFLAGS := --prefix-symbols=__normal_ +$(obj)/$(LIBGCC): $(NORMAL_LIBGCC) FORCE + $(call if_changed,objcopy) -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/12] kbuild,mxs: use short logs for MXS images
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
Cc: Marek Vasut ma...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Otavio Salvador ota...@ossystems.com.br
Cc: Lauri Hintsala lauri.hints...@bluegiga.com
---
Hi MXS board maitainers,
I think this commit is probably correct.
(I mean, it still generates correct u-boot.sb image)
But I could not corfirm it by binary comparison.
Every build generates a different u-boot.sb
even if no source file is changed.
I wish someone could do run test this patch.
Makefile | 2 +-
arch/arm/cpu/arm926ejs/mxs/Makefile | 13 +++--
arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg | 4 ++--
arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg | 4 ++--
arch/arm/cpu/arm926ejs/mxs/u-boot-imx23.bd | 4 ++--
arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd | 4 ++--
6 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/Makefile b/Makefile
index b795338..0df3780 100644
--- a/Makefile
+++ b/Makefile
@@ -858,7 +858,7 @@ u-boot.ais: spl/u-boot-spl.ais u-boot.img FORCE
$(call if_changed,pad_cat)
u-boot.sb: u-boot.bin spl/u-boot-spl.bin
- $(Q)$(MAKE) $(build)=arch/arm/cpu/arm926ejs/mxs $(objtree)/u-boot.sb
+ $(Q)$(MAKE) $(build)=arch/arm/cpu/arm926ejs/mxs u-boot.sb
# On x600 (SPEAr600) U-Boot is appended to U-Boot SPL.
# Both images are created using mkimage (crc etc), so that the ROM
diff --git a/arch/arm/cpu/arm926ejs/mxs/Makefile
b/arch/arm/cpu/arm926ejs/mxs/Makefile
index 152546e..1eee661 100644
--- a/arch/arm/cpu/arm926ejs/mxs/Makefile
+++ b/arch/arm/cpu/arm926ejs/mxs/Makefile
@@ -14,11 +14,12 @@ obj-y += spl_boot.o spl_lradc_init.o spl_mem_init.o
spl_power_init.o
endif
# Specify the target for use in elftosb call
-MKIMAGE_TARGET-$(CONFIG_MX23) = mx23
-MKIMAGE_TARGET-$(CONFIG_MX28) = mx28
+MKIMAGE_TARGET-$(CONFIG_MX23) = mxsimage.mx23.cfg
+MKIMAGE_TARGET-$(CONFIG_MX28) = mxsimage.mx28.cfg
-$(OBJTREE)/mxsimage.cfg:
$(SRCTREE)/$(CPUDIR)/$(SOC)/mxsimage.$(MKIMAGE_TARGET-y).cfg
- sed s@OBJTREE@$(OBJTREE)@g $^ $@
+quiet_cmd_mkimage_mxs = UIMAGE $@
+cmd_mkimage_mxs = $(objtree)/tools/mkimage -n $ -T mxsimage $@ \
+ $(if $(KBUILD_VERBOSE:1=), /dev/null)
-$(OBJTREE)/u-boot.sb: $(OBJTREE)/u-boot.bin $(OBJTREE)/spl/u-boot-spl.bin
$(OBJTREE)/mxsimage.cfg
- $(OBJTREE)/tools/mkimage -n $(OBJTREE)/mxsimage.cfg -T mxsimage $@
+u-boot.sb: $(src)/$(MKIMAGE_TARGET-y) u-boot.bin spl/u-boot-spl.bin FORCE
+ $(call if_changed,mkimage_mxs)
diff --git a/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg
b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg
index c9cf4b3..8118767 100644
--- a/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg
+++ b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg
@@ -1,6 +1,6 @@
SECTION 0x0 BOOTABLE
TAG LAST
- LOAD 0x0OBJTREE/spl/u-boot-spl.bin
+ LOAD 0x0spl/u-boot-spl.bin
CALL 0x14 0x0
- LOAD 0x4100 OBJTREE/u-boot.bin
+ LOAD 0x4100 u-boot.bin
CALL 0x4100 0x0
diff --git a/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg
b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg
index 676f5c8..ea772f0 100644
--- a/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg
+++ b/arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg
@@ -1,8 +1,8 @@
SECTION 0x0 BOOTABLE
TAG LAST
- LOAD 0x0OBJTREE/spl/u-boot-spl.bin
+ LOAD 0x0spl/u-boot-spl.bin
LOAD IVT 0x8000 0x14
CALL HAB 0x8000 0x0
- LOAD 0x4100 OBJTREE/u-boot.bin
+ LOAD 0x4100 u-boot.bin
LOAD IVT 0x8000 0x4100
CALL HAB 0x8000 0x0
diff --git a/arch/arm/cpu/arm926ejs/mxs/u-boot-imx23.bd
b/arch/arm/cpu/arm926ejs/mxs/u-boot-imx23.bd
index 8b6c30e..3a51879 100644
--- a/arch/arm/cpu/arm926ejs/mxs/u-boot-imx23.bd
+++ b/arch/arm/cpu/arm926ejs/mxs/u-boot-imx23.bd
@@ -4,8 +4,8 @@ options {
}
sources {
- u_boot_spl=OBJTREE/spl/u-boot-spl.bin;
- u_boot=OBJTREE/u-boot.bin;
+ u_boot_spl=spl/u-boot-spl.bin;
+ u_boot=u-boot.bin;
}
section (0) {
diff --git a/arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd
b/arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd
index a5fa648..c60615a 100644
--- a/arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd
+++ b/arch/arm/cpu/arm926ejs/mxs/u-boot-imx28.bd
@@ -1,6 +1,6 @@
sources {
- u_boot_spl=OBJTREE/spl/u-boot-spl.bin;
- u_boot=OBJTREE/u-boot.bin;
+ u_boot_spl=spl/u-boot-spl.bin;
+ u_boot=u-boot.bin;
}
section (0) {
--
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][v4] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for B4860QDS
On 03/10/2014 04:24 PM, Scott Wood wrote: On Fri, 2014-03-07 at 11:07 -0800, York Sun wrote: On 03/07/2014 11:00 AM, Scott Wood wrote: On Fri, 2014-03-07 at 10:58 -0800, York Sun wrote: On 03/07/2014 10:54 AM, Scott Wood wrote: On Fri, 2014-03-07 at 10:30 -0800, York Sun wrote: On 03/07/2014 05:23 AM, Aneesh Bansal wrote: Changes: 1. L2 cache is being invalidated by Boot ROM code for e6500 core. So removing the invalidation from start.S 2. Clear the LAW and corresponding configuration for CPC. Boot ROM code uses it as hosekeeping area. 3. For Secure boot, CPC is configured as SRAM and used as house keeping area. This configuration is to be disabled once in uboot. Earlier this disabling of CPC as SRAM was happening in cpu_init_r. As a result cache invalidation function was getting skipped in case CPC is configured as SRAM.This was causing random crashes. Signed-off-by: Aneesh Bansal aneesh.ban...@freescale.com --- README | 4 arch/powerpc/cpu/mpc85xx/cpu_init.c| 27 ++- arch/powerpc/cpu/mpc85xx/start.S | 3 ++- arch/powerpc/include/asm/fsl_secure_boot.h | 6 ++ boards.cfg | 1 + 5 files changed, 35 insertions(+), 6 deletions(-) Changes from v3: Renamed the macro to indicate CPC configured as SRAM at U-boot entry to CONFIG_SYS_CPC_SRAM Aneesh, I understand you are trying to address the comment about when CPC needs to be disabled before initializing as normal CPC. But introducing CONFIG_SYS_CPC_SRAM seems even more confusing. Let's take one step back. CPC as SRAM can be used for many reasons. There is only one reason we should keep it as SRAM, i.e. u-boot is indeed using SRAM as its final destination. For all other usages, we can safely reconfigure it as normal CPC after u-boot relocates itself into DDR. If u-boot's final destination is SRAM, it is a RAMBOOT. Can we use this condition to deal with CPC? Even if CPC is the final destination, shouldn't RAMBOOT imply that DDR has been initialized? No. RAMBOOT implies u-boot shouldn't initialize RAM. There may be cases where u-boot needs to run in SRAM without DDR. It doesn't matter if the RAM is SRAM or DRAM. There are some situations where we run U-Boot out of SRAM without relocating to DDR, but I can't think of a situation where we wouldn't want to use DDR at all (e.g. for loading an OS to). I generally agree with you. Loading OS needs more RAM. I am trying to simplify the condition to reinitialize CPC. My point is only one situation requires the CPC to act as SRAM. We can brainstorm how useful it is. For example, as a recovery method if using JTAG tool to enable CPC as SRAM and to load u-boot into it, one can skip the steps to initialize DDR to run an full-feature u-boot and reflash the board. What's relevant isn't whether there is a use case for not needing DDR, but whether there's a use case for having a special build of U-Boot that skips initializing DDR. There are cases, such as using JTAG tools before, using PBI commands recently. There have been other cases when DDR is not or cannot be used, a RAMBOOT u-boot will use SRAM. All these cases need u-boot skipping initializing DDR. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Is non-English documentation allowed ?
Hello Wolfgang, Tom In U-Boot, is there any rule to restrict documents written in a language other than English? I found a README file written in Germany by chance: board/lwmon/README.keybd Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
