[U-Boot] SPL binary too large for OMAP4460 OCM
Hi everybody, I need to add functionality to the SPL code. I tried to implement in a memory-saving way, however, the SPL is about 45 kB after compilation. To get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 * 1024). Now, the SPL as well as u-boot won't boot. After the device' (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output on terminal. My question: is it theoretically possible to to establish a successfully booting SPL with ~45 kB in size for this device? The device' on-chip-memory is 56kB so it could fit in there. If so, what needs to be configured / tuned to get it working? Are there any other features I could omit from the binary to make it smaller? Thanks a lot, André ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/3] ARM: atmel: add RNDIS gadget support
Hi Bo, Marek, On 09/04/2013 04:01 AM, Bo Shen wrote: Hi Marek Vasut, On 09/04/2013 09:55 AM, Marek Vasut wrote: I have considered to put this in driver, however, different Atmel SoC have different attributes for each endpoint and different number of endpoint. for example; at91sam9x5: EP(ep1, 1, 1024, 2, 1, 1) sama5d3x: EP(ep1, 1, 1024, 3, 1, 0) So, if I put this in driver, there will be many #ifdef. If newly SoC added, maybe we will need to add #ifdef again. So, I put it here. Can you not pull it into some header file at least? Having it in the board file will clearly result in duplication. OK, I will put it into header file. I'm fine with a header too. But for the records, the mentioned file is _not_ board code but SoC code. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] SPL binary too large for OMAP4460 OCM
Hi everybody, I need to add functionality to the SPL code. I tried to implement in a memory-saving way, however, the SPL is about 45 kB after compilation. To get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 * 1024). Now, the SPL as well as u-boot won't boot. After the device' (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output on terminal. My question: is it theoretically possible to to establish a successfully booting SPL with ~45 kB in size for this device? The device' on-chip-memory is 56kB so it could fit in there. If so, what needs to be configured / tuned to get it working? Are there any other features I could omit from the binary to make it smaller? Thanks a lot, -b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND write error with HW ECC on OMAP3
Dear Ash Charles, On 09/03/2013 09:34 PM, Ash Charles wrote: Hi, When using 'nandecc hw' on an OMAP3 platform, data is not being correctly written to NAND. I see the issue on 2013.10-rc2 and 2013.07 but not on 2012.10. Specifically, when I read back a SPL binary written with hardware Hamming ECC, I don't get a matching CRC. With the BCH8 ECC algorithm, the CRC is correct (but SPL must be written with Hamming otherwise the board doesn't boot) I've shown my steps here: http://pastebin.com/tLZsr9zH The expected CRC is 46745188. Any suggestions/ideas much appreciated! I'd swear this worked when I changed the command to use BCH ... I'll check it again today. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - arm/zynq v3
On 09/03/2013 02:12 PM, Albert ARIBAUD wrote: Hi Michal, On Mon, 19 Aug 2013 09:36:33 +0200, Michal Simek mon...@monstr.eu wrote: Hi Albert, please pull these 3 zynq patches to your arm tree. I have rebased the tree on the 2013.07 to remove that new nds32 patches. There is still pending the arm: lds: Remove libgcc eabi exception handling tables patch. Have you considered to also add it? v3: - Rebase on the v2013.07 because Albert didn't want to nds32 stuff v2: - Changed email address, - There was incorrect rebase which I have fixed - correct sha1 now Thanks. Michal The following changes since commit 62c175fbb8a0f9a926c88294ea9f7e88eb898f6c: Prepare v2013.07 (2013-07-23 07:58:13 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git zynq for you to fetch changes up to 037e0d25c6ee6367beca3062759993d10759dff2: zynq: Enable axi ethernet and emaclite driver initialization (2013-08-19 09:32:00 +0200) Michal Simek (3): zynq: Add new ddrc driver for ECC support zynq: slcr: Wait 100ms till clk is properly setup zynq: Enable axi ethernet and emaclite driver initialization arch/arm/cpu/armv7/zynq/Makefile | 1 + arch/arm/cpu/armv7/zynq/ddrc.c | 50 ++ arch/arm/cpu/armv7/zynq/slcr.c | 2 +- arch/arm/include/asm/arch-zynq/hardware.h | 8 + arch/arm/include/asm/arch-zynq/sys_proto.h | 1 + board/xilinx/zynq/board.c | 19 6 files changed, 80 insertions(+), 1 deletion(-) create mode 100644 arch/arm/cpu/armv7/zynq/ddrc.c Applied to u-boot-arm/master, thanks! Thanks. What about this patch arm: lds: Remove libgcc eabi exception handling tables? Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/3] ARM: atmel: add RNDIS gadget support
Hi Andreas,
On 9/4/2013 15:32, Andreas Bießmann wrote:
Hi Bo, Marek,
On 09/04/2013 04:01 AM, Bo Shen wrote:
Hi Marek Vasut,
On 09/04/2013 09:55 AM, Marek Vasut wrote:
I have considered to put this in driver, however, different Atmel SoC
have different attributes for each endpoint and different number of
endpoint.
for example;
at91sam9x5: EP(ep1, 1, 1024, 2, 1, 1)
sama5d3x: EP(ep1, 1, 1024, 3, 1, 0)
So, if I put this in driver, there will be many #ifdef. If newly SoC
added, maybe we will need to add #ifdef again. So, I put it here.
Can you not pull it into some header file at least? Having it in the
board file
will clearly result in duplication.
OK, I will put it into header file.
I'm fine with a header too. But for the records, the mentioned file is
_not_ board code but SoC code.
I will create a header file named atmel_usba_udc.h as other peripheral
(at91_udc.h is reserved for full speed usb device), and put it under
arm/arm/include/asm/arch-at91/, the contents as following, does it OK?
---8---
/*
* Copyright (C) 2005-2013 Atmel Corporation
* Bo Shen voice.s...@atmel.com
*
* SPDX-License-Identifier: GPL-2.0+
*/
#ifndef __ATMEL_USBA_UDC_H__
#define __ATMEL_USBA_UDC_H__
#include linux/usb/atmel_usba_udc.h
#define EP(nam, idx, maxpkt, maxbk, dma, isoc) \
[idx] = { \
.name = nam, \
.index = idx, \
.fifo_size = maxpkt, \
.nr_banks = maxbk,\
.can_dma= dma, \
.can_isoc = isoc, \
}
#if defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \
defined(CONFIG_AT91SAM9X5)
static struct usba_ep_data usba_udc_ep[] = {
EP(ep0, 0, 64, 1, 0, 0),
... ...
EP(ep6, 6, 1024, 3, 1, 1),
};
#elif defined(CONFIG_SAMA5D3)
static struct usba_ep_data usba_udc_ep[] = {
EP(ep0, 0, 64, 1, 0, 0),
..
EP(ep15, 15, 1024, 2, 0, 0),
};
#else
# error NO usba_udc_ep defined
#endif
#undef EP
struct usba_platform_data pdata = {
.num_ep = ARRAY_SIZE(usba_udc_ep),
.ep = usba_udc_ep,
};
#endif
---8---
Best regards
Andreas Bießmann
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/3] ARM: atmel: add RNDIS gadget support
Hi Bo,
On 09/04/2013 09:42 AM, Bo Shen wrote:
Hi Andreas,
On 9/4/2013 15:32, Andreas Bießmann wrote:
Hi Bo, Marek,
On 09/04/2013 04:01 AM, Bo Shen wrote:
Hi Marek Vasut,
On 09/04/2013 09:55 AM, Marek Vasut wrote:
I have considered to put this in driver, however, different Atmel SoC
have different attributes for each endpoint and different number of
endpoint.
for example;
at91sam9x5: EP(ep1, 1, 1024, 2, 1, 1)
sama5d3x: EP(ep1, 1, 1024, 3, 1, 0)
So, if I put this in driver, there will be many #ifdef. If newly SoC
added, maybe we will need to add #ifdef again. So, I put it here.
Can you not pull it into some header file at least? Having it in the
board file
will clearly result in duplication.
OK, I will put it into header file.
I'm fine with a header too. But for the records, the mentioned file is
_not_ board code but SoC code.
I will create a header file named atmel_usba_udc.h as other peripheral
(at91_udc.h is reserved for full speed usb device), and put it under
arm/arm/include/asm/arch-at91/, the contents as following, does it OK?
---8---
/*
* Copyright (C) 2005-2013 Atmel Corporation
* Bo Shen voice.s...@atmel.com
*
* SPDX-License-Identifier: GPL-2.0+
*/
#ifndef __ATMEL_USBA_UDC_H__
#define __ATMEL_USBA_UDC_H__
#include linux/usb/atmel_usba_udc.h
#define EP(nam, idx, maxpkt, maxbk, dma, isoc) \
[idx] = { \
.name = nam, \
.index = idx, \
.fifo_size = maxpkt, \
.nr_banks = maxbk,\
.can_dma= dma, \
.can_isoc = isoc, \
}
#if defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \
defined(CONFIG_AT91SAM9X5)
static struct usba_ep_data usba_udc_ep[] = {
EP(ep0, 0, 64, 1, 0, 0),
... ...
EP(ep6, 6, 1024, 3, 1, 1),
};
#elif defined(CONFIG_SAMA5D3)
static struct usba_ep_data usba_udc_ep[] = {
EP(ep0, 0, 64, 1, 0, 0),
..
EP(ep15, 15, 1024, 2, 0, 0),
};
#else
# error NO usba_udc_ep defined
#endif
#undef EP
struct usba_platform_data pdata = {
.num_ep = ARRAY_SIZE(usba_udc_ep),
.ep = usba_udc_ep,
};
#endif
---8---
I'm fine with that. Was the g45/9X5 defined before or is it new in that
patch?
Best regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL binary too large for OMAP4460 OCM
On Wednesday 04 September 2013 01:01 PM, bin4ry wrote: Hi everybody, I need to add functionality to the SPL code. I tried to implement in a memory-saving way, however, the SPL is about 45 kB after compilation. To get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 * 1024). Now, the SPL as well as u-boot won't boot. After the device' (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output on terminal. My question: is it theoretically possible to to establish a successfully booting SPL with ~45 kB in size for this device? The device' on-chip-memory is 56kB so it could fit in there. If so, what needs to be configured / tuned to get it working? Are there any other features I could omit from the binary to make it smaller? Thanks a lot, -b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Do you have a Secure device or GP ? Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL binary too large for OMAP4460 OCM
Hi On Wed, Sep 4, 2013 at 10:44 AM, Sricharan R r.sricha...@ti.com wrote: On Wednesday 04 September 2013 01:01 PM, bin4ry wrote: Hi everybody, I need to add functionality to the SPL code. I tried to implement in a memory-saving way, however, the SPL is about 45 kB after compilation. To get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 * 1024). Now, the SPL as well as u-boot won't boot. After the device' (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output on terminal. My question: is it theoretically possible to to establish a successfully booting SPL with ~45 kB in size for this device? The device' on-chip-memory is 56kB so it could fit in there. If so, what needs to be configured / tuned to get it working? Are there any other features I could omit from the binary to make it smaller? Thanks a lot, -b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Do you have a Secure device or GP ? if it is Pandaboard? No he has not. I have increased up to 40Kb and it works with serial boot and sdcard/emmc boot. Michael Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND write error with HW ECC on OMAP3
Dear Ash Charles,
On 09/04/2013 09:35 AM, Andreas Bießmann wrote:
Dear Ash Charles,
On 09/03/2013 09:34 PM, Ash Charles wrote:
Hi,
When using 'nandecc hw' on an OMAP3 platform, data is not being
correctly written to NAND. I see the issue on 2013.10-rc2 and 2013.07
but not on 2012.10. Specifically, when I read back a SPL binary
written with hardware Hamming ECC, I don't get a matching CRC. With
the BCH8 ECC algorithm, the CRC is correct (but SPL must be written
with Hamming otherwise the board doesn't boot)
I've shown my steps here: http://pastebin.com/tLZsr9zH
The expected CRC is 46745188.
Any suggestions/ideas much appreciated!
I'd swear this worked when I changed the command to use BCH ... I'll
check it again today.
I can't confirm your complaints. Here it works (at least on tricorder,
which utilizes BCH for U-Boot section in SPL):
---8---
U-Boot SPL 2013.10-rc2-00014-g2d5878e (Sep 04 2013 - 10:39:57)
reading u-boot.img
reading u-boot.img
U-Boot 2013.10-rc2-00014-g2d5878e (Sep 04 2013 - 10:39:57)
OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-200MHz, Max CPU Clock 1 Ghz
OMAP3 Tricorder + LPDDR/NAND
I2C: ready
DRAM: 128 MiB
NAND: 512 MiB
MMC: OMAP SD/MMC: 0
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Board : serial
Die ID #24629e3801683b060102002d
Hit any key to stop autoboot: 0
OMAP3 Tricorder # fatload mmc 0 ${loadaddr} MLO
reading MLO
55052 bytes read in 11 ms (4.8 MiB/s)
OMAP3 Tricorder # nandecc hw
1-bit hamming HW ECC selected
OMAP3 Tricorder # nand erase.part SPL
NAND erase.part: device 0 offset 0x0, size 0x2
Erasing at 0x0 -- 100% complete.
OK
OMAP3 Tricorder # crc32 ${loadaddr} ${filesize}
CRC32 for 8200 ... 8200d70b == b182f0a2
OMAP3 Tricorder # nand write ${loadaddr} SPL ${filesize}
NAND write: device 0 offset 0x0, size 0xd70c
55052 bytes written: OK
OMAP3 Tricorder # nand read 0x8000 SPL ${filesize}
NAND read: device 0 offset 0x0, size 0xd70c
55052 bytes read: OK
OMAP3 Tricorder # crc32 0x8000 ${filesize}
CRC32 for 8000 ... 8000d70b == b182f0a2
OMAP3 Tricorder #
---8---
The 14 patches on top of -rc2 are just local board changes (will be sent
soon):
---8---
2d5878e (HEAD, tricorder-TOT) tricorder: fixup for led.c
c3806ea tricorder: read kernel directly from NAND
c158ec1 tricorder: switch to alternative memtest
9bcc57b tricorder: Make u-boot faster
441857b tricorder: add led support
b8bb65a tricorder: panic() on unknown board
8c5e0a8 tricorder: add tricordereeprom command
4c86cad tricorder: add mtdparts to environment
3ac9838 tricorder: add cmdline history
7fe344d tricorder: move commonargs to common settings
3bd1a05 tricorder: add configuration for a flashcard u-boot
d2578c5 tricorder: use generic provided loadaddr
649f8dc tricorder: update flash partitioning
e34c01a tricorder: remove lcdmode from bootargs
fb18fa9 (tag: v2013.10-rc2, origin/master, origin/HEAD, cs/master)
Prepare v2013.10-rc2
---8---
Best regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL binary too large for OMAP4460 OCM
On Wednesday 04 September 2013 02:18 PM, Michael Trimarchi wrote: Hi On Wed, Sep 4, 2013 at 10:44 AM, Sricharan R r.sricha...@ti.com wrote: On Wednesday 04 September 2013 01:01 PM, bin4ry wrote: Hi everybody, I need to add functionality to the SPL code. I tried to implement in a memory-saving way, however, the SPL is about 45 kB after compilation. To get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 * 1024). Now, the SPL as well as u-boot won't boot. After the device' (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output on terminal. My question: is it theoretically possible to to establish a successfully booting SPL with ~45 kB in size for this device? The device' on-chip-memory is 56kB so it could fit in there. If so, what needs to be configured / tuned to get it working? Are there any other features I could omit from the binary to make it smaller? Thanks a lot, -b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Do you have a Secure device or GP ? if it is Pandaboard? No he has not. I have increased up to 40Kb and it works with serial boot and sdcard/emmc boot. Sorry i missed to read PANDA. So it is anyways GP. and you changed the CONFIG_SPL_TEXT_BASE as well right ? Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL binary too large for OMAP4460 OCM
Am 04.09.2013 10:56, schrieb Sricharan R: On Wednesday 04 September 2013 02:18 PM, Michael Trimarchi wrote: Hi On Wed, Sep 4, 2013 at 10:44 AM, Sricharan R r.sricha...@ti.com wrote: On Wednesday 04 September 2013 01:01 PM, bin4ry wrote: Hi everybody, I need to add functionality to the SPL code. I tried to implement in a memory-saving way, however, the SPL is about 45 kB after compilation. To get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 * 1024). Now, the SPL as well as u-boot won't boot. After the device' (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output on terminal. My question: is it theoretically possible to to establish a successfully booting SPL with ~45 kB in size for this device? The device' on-chip-memory is 56kB so it could fit in there. If so, what needs to be configured / tuned to get it working? Are there any other features I could omit from the binary to make it smaller? Thanks a lot, -b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Do you have a Secure device or GP ? if it is Pandaboard? No he has not. I have increased up to 40Kb and it works with serial boot and sdcard/emmc boot. Sorry i missed to read PANDA. So it is anyways GP. and you changed the CONFIG_SPL_TEXT_BASE as well right ? Regards, Sricharan First off, sorry for double-posting to this list. No, the PandaBoard is no HS but a GP device. This is my configuration: /* Defines for SPL */ #define CONFIG_SPL #define CONFIG_SPL_TEXT_BASE0x40303000 #define CONFIG_SPL_MAX_SIZE(45 * 1024) #define CONFIG_SPL_STACKLOW_LEVEL_SRAM_STACK The MLO binary has 46094 Bytes. Actually I should have enough space (from 0x4030 - 0x4030bfff - ~49 kB). However, the device does not start. Right now I am reviewing the code to check, whether it is because of the code and not because of the size that makes u-boot does not start. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL binary too large for OMAP4460 OCM
On Wednesday 04 September 2013 02:34 PM, bin4ry wrote: Am 04.09.2013 10:56, schrieb Sricharan R: On Wednesday 04 September 2013 02:18 PM, Michael Trimarchi wrote: Hi On Wed, Sep 4, 2013 at 10:44 AM, Sricharan R r.sricha...@ti.com wrote: On Wednesday 04 September 2013 01:01 PM, bin4ry wrote: Hi everybody, I need to add functionality to the SPL code. I tried to implement in a memory-saving way, however, the SPL is about 45 kB after compilation. To get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 * 1024). Now, the SPL as well as u-boot won't boot. After the device' (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output on terminal. My question: is it theoretically possible to to establish a successfully booting SPL with ~45 kB in size for this device? The device' on-chip-memory is 56kB so it could fit in there. If so, what needs to be configured / tuned to get it working? Are there any other features I could omit from the binary to make it smaller? Thanks a lot, -b ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Do you have a Secure device or GP ? if it is Pandaboard? No he has not. I have increased up to 40Kb and it works with serial boot and sdcard/emmc boot. Sorry i missed to read PANDA. So it is anyways GP. and you changed the CONFIG_SPL_TEXT_BASE as well right ? Regards, Sricharan First off, sorry for double-posting to this list. No, the PandaBoard is no HS but a GP device. This is my configuration: /* Defines for SPL */ #define CONFIG_SPL #define CONFIG_SPL_TEXT_BASE0x40303000 #define CONFIG_SPL_MAX_SIZE(45 * 1024) #define CONFIG_SPL_STACKLOW_LEVEL_SRAM_STACK The MLO binary has 46094 Bytes. Actually I should have enough space (from 0x4030 - 0x4030bfff - ~49 kB). However, the device does not start. Right now I am reviewing the code to check, whether it is because of the code and not because of the size that makes u-boot does not start. Can you try by setting CONFIG_SPL_TEXT_BASE 0x40300350 ? Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL binary too large for OMAP4460 OCM
Hi,
On Wednesday 04 September 2013 02:34 PM, bin4ry wrote:
Am 04.09.2013 10:56, schrieb Sricharan R:
On Wednesday 04 September 2013 02:18 PM, Michael Trimarchi wrote:
Hi
On Wed, Sep 4, 2013 at 10:44 AM, Sricharan R r.sricha...@ti.com wrote:
On Wednesday 04 September 2013 01:01 PM, bin4ry wrote:
Hi everybody,
I need to add functionality to the SPL code. I tried to implement in a
memory-saving way, however, the SPL is about 45 kB after compilation. To
get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 *
1024). Now, the SPL as well as u-boot won't boot. After the device'
(PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output
on terminal.
My question: is it theoretically possible to to establish a successfully
booting SPL with ~45 kB in size for this device? The device'
on-chip-memory is 56kB so it could fit in there. If so, what needs to be
configured / tuned to get it working? Are there any other features I
could omit from the binary to make it smaller?
Thanks a lot,
-b
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Do you have a Secure device or GP ?
if it is Pandaboard? No he has not. I have increased up to 40Kb and it
works with serial boot and
sdcard/emmc boot.
Sorry i missed to read PANDA. So it is anyways GP.
and you changed the CONFIG_SPL_TEXT_BASE as well right ?
Regards,
Sricharan
First off, sorry for double-posting to this list.
No, the PandaBoard is no HS but a GP device.
This is my configuration:
/* Defines for SPL */
#define CONFIG_SPL
#define CONFIG_SPL_TEXT_BASE0x40303000
#define CONFIG_SPL_MAX_SIZE(45 * 1024)
#define CONFIG_SPL_STACKLOW_LEVEL_SRAM_STACK
The MLO binary has 46094 Bytes. Actually I should have enough space
(from 0x4030 - 0x4030bfff - ~49 kB). However, the device does not
start. Right now I am reviewing the code to check, whether it is because
of the code and not because of the size that makes u-boot does not start.
Just for testing you can try the following diff:
The start address where the Image is downloaded is changed
and now the max size is ~46KB.
diff --git a/arch/arm/include/asm/arch-omap4/omap.h
b/arch/arm/include/asm/arch-omap4/omap.h
index 3823a37..7c98360 100644
--- a/arch/arm/include/asm/arch-omap4/omap.h
+++ b/arch/arm/include/asm/arch-omap4/omap.h
@@ -109,7 +109,7 @@ struct s32ktimer {
* Non-secure RAM starts at 0x4030 for GP devices. But we keep SRAM_BASE
* at 0x40304000(EMU base) so that our code works for both EMU and GP
*/
-#define NON_SECURE_SRAM_START 0x40304000
+#define NON_SECURE_SRAM_START 0x4030
#define NON_SECURE_SRAM_END0x4030E000 /* Not inclusive */
#define SRAM_SCRATCH_SPACE_ADDRNON_SECURE_SRAM_START
/* base address for indirect vectors (internal boot mode) */
diff --git a/include/configs/omap4_common.h b/include/configs/omap4_common.h
index e9f2383..5177313 100644
--- a/include/configs/omap4_common.h
+++ b/include/configs/omap4_common.h
@@ -250,8 +250,8 @@
/* Defines for SPL */
#define CONFIG_SPL
#define CONFIG_SPL_FRAMEWORK
-#define CONFIG_SPL_TEXT_BASE 0x40304350
-#define CONFIG_SPL_MAX_SIZE(38 * 1024)
+#define CONFIG_SPL_TEXT_BASE 0x4030
+#define CONFIG_SPL_MAX_SIZE0x4030C000 - CONFIG_SPL_TEXT_BASE
#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
#define CONFIG_SPL_DISPLAY_PRINT
Thanks and regards,
Lokesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] current version of u-boot doesn't seem to load kernel for beaglebone black
On Tue, 3 Sep 2013, Robert P. J. Day wrote:
just checked out and built u-boot for beaglebone black:
$ make am335x_boneblack_config
built, copied only MLO and u-boot.img to SD card so i could run u-boot
off of SD card but boot the rest out of the eMMC, and got:
U-Boot# run bootcmd
mmc1(part 0) is current device
mmc_send_cmd : timeout: No status update
SD/MMC found on device 1
reading uEnv.txt
26 bytes read in 3 ms (7.8 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc ...
24808 bytes read in 43 ms (562.5 KiB/s)
Wrong Image Format for bootm command
ERROR: can't get kernel image!
mmc1(part 0) is current device
mmc_send_cmd : timeout: No status update
SD/MMC found on device 1
reading uEnv.txt
26 bytes read in 3 ms (7.8 KiB/s)
Loaded environment from uEnv.txt
Importing environment from mmc ...
24808 bytes read in 43 ms (562.5 KiB/s)
Wrong Image Format for bootm command
ERROR: can't get kernel image!
## Error: nandboot not defined
which seems to be because the uImage file isn't being loaded into
memory at ${loadaddr}, so that the subsequent command:
bootm ${loadaddr} - ${fdtaddr}
will naturally fail as there's no valid kernel image at that address.
i'm looking at the new environment, and i don't see where the kernel
image is loaded into memory. thoughts?
following up on my own post, it would *seem* that what one needs is
the following patch:
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index e0a87f8..7969e07 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -132,7 +132,9 @@
echo Running uenvcmd ...; \
run uenvcmd; \
fi; \
- run mmcloados; \
+ if run loaduimage; then \
+ run mmcloados; \
+ fi; \
fi;\0 \
spiboot=echo Booting from spi ...; \
run spiargs; \
otherwise, i just don't see where the kernel image is going to be
loaded for a BBB config and build, and it's *always* going to fail
getting a proper kernel image. thoughts?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot 2009.11.1 USB Issue and Building U-Boot 2013.07
Dear Chuck Wical usb start fatload usb 0 $(loadaddr) rootfs.ext2.gz.uboot where loadaddr is the same address used by tftp. Your load address 0 is wrong. On AT91 systems addresses greater than 0x2010 should be used (RAM location). Regards jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-atmel/master - u-boot-arm/master
Hi Albert, can you please wait applying this? I have another 2-3 patches for this release. Best regards Andreas Bießmann On 08/22/2013 05:04 PM, Andreas Bießmann wrote: Dear Albert Aribaud, The following changes since commit 9ed887caecb9ecb0c68773a1870d143b9f28d3da: Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2013-08-17 18:24:13 +0200) are available in the git repository at: git://git.denx.de/u-boot-atmel.git master for you to fetch changes up to bc6958988726977b4089da1b13f6467e8e28efd2: arm: atmel: cpux9k2: board update and enhancement (2013-08-22 16:52:40 +0200) Bo Shen (10): net: macb: fix the following building warning arm: atmel: add gmac support for sama5d3xek board arm: atmel: add nand trimffs subcommand for at91sam9n12 and at91sam9x5 arm: sama5d3: fix smc cs related registers offset arm: sama5d3: remove unused define arm: atmel: sama5d3: fix typo error for CONFIG_ENV_IS_NOWHERE arm: atmel: remove the config.mk file gpio: atmel: fix code to use pointer for pio port gpio: atmel: add gpio common API support gpio: atmel: add copyright and remove error header info Jens Scharsig (BuS Elektronik) (1): arm: atmel: cpux9k2: board update and enhancement Wu, Josh (5): ARM: at91: atmel_nand: pmecc driver will select the galois table by sector size ARM: at91: sama5d3: remove unused definition about PMECC alpha table offset linux/compat.h: move dev_err, dev_info and dev_dbg from usb driver to compat.h mtd: atmel_nand: alloc memory instead of use static array for pmecc data ARM: at91: atmel_nand: add code to check the ONFI parameter ECC requirement arch/arm/cpu/armv7/at91/sama5d3_devices.c| 24 +++ arch/arm/include/asm/arch-at91/at91_common.h |1 + arch/arm/include/asm/arch-at91/at91sam9x5.h |6 + arch/arm/include/asm/arch-at91/sama5d3.h |2 - arch/arm/include/asm/arch-at91/sama5d3_smc.h |2 +- board/atmel/at91sam9m10g45ek/config.mk |1 - board/atmel/at91sam9x5ek/config.mk |1 - board/atmel/sama5d3xek/sama5d3xek.c | 20 ++ doc/README.atmel_pmecc | 14 -- drivers/gpio/at91_gpio.c | 295 -- drivers/mtd/nand/atmel_nand.c| 198 - drivers/net/macb.c | 12 +- drivers/usb/musb-new/linux-compat.h | 16 -- include/configs/at91sam9m10g45ek.h |2 + include/configs/at91sam9n12ek.h |3 + include/configs/at91sam9x5ek.h |5 +- include/configs/eb_cpux9k2.h | 62 +++--- include/configs/sama5d3xek.h | 10 +- include/linux/compat.h |8 + 19 files changed, 486 insertions(+), 196 deletions(-) delete mode 100644 board/atmel/at91sam9m10g45ek/config.mk delete mode 100644 board/atmel/at91sam9x5ek/config.mk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] pull request for u-boot-tegra/master into ARM/master
Hi Tom, On Mon, 19 Aug 2013 15:57:27 -0700, Tom Warren twarren.nvi...@gmail.com wrote: Albert, Please pull u-boot-tegra/master into ARM/master. Thanks! ./MAKEALL -s tegra AOK, checkpatch.pl is clean. TomR - hopefully if Albert can get this in quickly, it can make 2013.10-RC1 (or 2). The following changes since commit 9ed887caecb9ecb0c68773a1870d143b9f28d3da: Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2013-08-17 18:24:1$ are available in the git repository at: git://git.denx.de/u-boot-tegra master for you to fetch changes up to 8258c126143034bef2e35e01b2e14f2d90a7e0b5: ARM: tegra: support raw ramdisks (2013-08-19 15:31:37 -0700) Stephen Warren (1): ARM: tegra: support raw ramdisks Thierry Reding (2): ARM: tegra: Make cache line size SoC specific ARM: tegra: Enable data cache on Dalmore include/configs/dalmore.h | 3 --- include/configs/tegra-common.h| 3 +-- include/configs/tegra114-common.h | 3 +++ include/configs/tegra20-common.h | 3 +++ include/configs/tegra30-common.h | 3 +++ 5 files changed, 10 insertions(+), 5 deletions(-) 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
Re: [U-Boot] [PATCH] ums: Add dev num parameter. Check mmc device before do ums init.
Hello Marek,
Thank you for reply.
On 09/04/2013 12:26 AM, Marek Vasut wrote:
Dear Przemyslaw Marczak,
This change allows using every mmc device instance with ums, like eMMC
or SD cards. Now MMC device is checked before ums is inited.
Example of use: ums device_number for mmc devices.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Marek Vasut marek.va...@gmail.com
---
board/samsung/trats/trats.c | 12 +++-
common/cmd_usb_mass_storage.c | 30 ++
include/usb_mass_storage.h|4 ++--
3 files changed, 19 insertions(+), 27 deletions(-)
diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index 7f61d17..b7f7b05 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -816,17 +816,11 @@ static struct ums_board_info ums_board = {
},
};
-struct ums_board_info *board_ums_init(unsigned int dev_num, unsigned int
offset, - unsigned int part_size)
+struct ums_board_info *board_ums_init(struct mmc *mmc, unsigned int
offset, + unsigned int part_size)
{
- struct mmc *mmc;
-
- mmc = find_mmc_device(dev_num);
- if (!mmc)
- return NULL;
-
ums_board.ums_dev.mmc = mmc;
- ums_board.ums_dev.dev_num = dev_num;
+ ums_board.ums_dev.dev_num = mmc-block_dev.dev;
You already pass mmc, why pass mmc-block_dev.dev too? Is it not a little
redundant?
You are right, it is little redundant but pointer to this structure is
returned so we expect that structure fields were proper filled, right?
ums_board.ums_dev.offset = offset;
ums_board.ums_dev.part_size = part_size;
diff --git a/common/cmd_usb_mass_storage.c b/common/cmd_usb_mass_storage.c
index 33a4715..62c1308 100644
--- a/common/cmd_usb_mass_storage.c
+++ b/common/cmd_usb_mass_storage.c
@@ -14,6 +14,7 @@
int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
int argc, char * const argv[])
{
+ struct mmc *mmc = NULL;
char *ep;
unsigned int dev_num = 0, offset = 0, part_size = 0;
int rc;
@@ -21,29 +22,29 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
struct ums_board_info *ums_info;
static char *s = ums;
- if (argc 2) {
- printf(usage: ums dev - e.g. ums 0\n);
- return 0;
- }
+ if (argc 2)
+ return CMD_RET_USAGE;
UMS works on MMC devices only right now?
Yes, it is.
dev_num = (int)simple_strtoul(argv[1], ep, 16);
- if (dev_num) {
- puts(\nSet eMMC device to 0! - e.g. ums 0\n);
- goto fail;
+ mmc = find_mmc_device(dev_num);
+ if (!mmc) {
+ printf(UMS error: invalid mmc device num: %d.\n, dev_num);
+ return CMD_RET_FAILURE;
}
board_usb_init();
- ums_info = board_ums_init(dev_num, offset, part_size);
+ ums_info = board_ums_init(mmc, offset, part_size);
if (!ums_info) {
- printf(MMC: %d - NOT available\n, dev_num);
- goto fail;
+ printf(UMS is not supported on this board.\n);
puts()
Right, I will change it in patch v2.
+ return CMD_RET_FAILURE;
}
+
rc = fsg_init(ums_info);
if (rc) {
printf(cmd ums: fsg_init failed\n);
- goto fail;
+ return CMD_RET_FAILURE;
}
g_dnl_register(s);
@@ -61,13 +62,10 @@ int do_usb_mass_storage(cmd_tbl_t *cmdtp, int flag,
}
exit:
g_dnl_unregister();
- return 0;
-
-fail:
- return -1;
+ return CMD_RET_SUCCESS;
}
U_BOOT_CMD(ums, CONFIG_SYS_MAXARGS, 1, do_usb_mass_storage,
Use the UMS [User Mass Storage],
- ums - User Mass Storage Gadget
+ ums dev e.g. ums 0
);
diff --git a/include/usb_mass_storage.h b/include/usb_mass_storage.h
index 35cdcc3..0f94f31 100644
--- a/include/usb_mass_storage.h
+++ b/include/usb_mass_storage.h
@@ -34,8 +34,8 @@ extern void board_usb_init(void);
extern int fsg_init(struct ums_board_info *);
extern void fsg_cleanup(void);
-extern struct ums_board_info *board_ums_init(unsigned int,
-unsigned int, unsigned int);
+extern struct ums_board_info *board_ums_init(struct mmc *, unsigned int,
+ unsigned int);
extern int usb_gadget_handle_interrupts(void);
extern int fsg_main_thread(void *);
Best regards,
Marek Vasut
Thank you,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] SPL: P1022DS: switch to new multibus/multiadapter support
From: Ying Zhang b40...@freescale.com
- Added section u_boot_list in arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
- Use the function i2c_init_all instead of i2c_init
Signed-off-by: Ying Zhang b40...@freescale.com
---
arch/powerpc/cpu/mpc85xx/u-boot-spl.lds |5 +
board/freescale/p1022ds/spl.c |6 +-
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
index 85ec74b..bc13267 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
@@ -44,6 +44,11 @@ SECTIONS
}
_edata = .;
+ . = ALIGN(4);
+ .u_boot_list : {
+ KEEP(*(SORT(.u_boot_list*)));
+ }
+
. = .;
__start___ex_table = .;
__ex_table : { *(__ex_table) }
diff --git a/board/freescale/p1022ds/spl.c b/board/freescale/p1022ds/spl.c
index b9dbf81..7f151e3 100644
--- a/board/freescale/p1022ds/spl.c
+++ b/board/freescale/p1022ds/spl.c
@@ -102,7 +102,11 @@ void board_init_r(gd_t *gd, ulong dest_addr)
env_relocate();
#endif
- i2c_init(CONFIG_SYS_FSL_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+#ifdef CONFIG_SYS_I2C
+ i2c_init_all();
+#else
+ i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+#endif
gd-ram_size = initdram(0);
#ifdef CONFIG_SPL_NAND_BOOT
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] SPL: P1022DS: switch to new multibus/multiadapter support
From: Ying Zhang b40...@freescale.com
- Added section u_boot_list in arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
- Use the function i2c_init_all instead of i2c_init
Signed-off-by: Ying Zhang b40...@freescale.com
---
arch/powerpc/cpu/mpc85xx/u-boot-spl.lds |5 +
board/freescale/p1022ds/spl.c |6 +-
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
index 85ec74b..bc13267 100644
--- a/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
+++ b/arch/powerpc/cpu/mpc85xx/u-boot-spl.lds
@@ -44,6 +44,11 @@ SECTIONS
}
_edata = .;
+ . = ALIGN(4);
+ .u_boot_list : {
+ KEEP(*(SORT(.u_boot_list*)));
+ }
+
. = .;
__start___ex_table = .;
__ex_table : { *(__ex_table) }
diff --git a/board/freescale/p1022ds/spl.c b/board/freescale/p1022ds/spl.c
index b9dbf81..7f151e3 100644
--- a/board/freescale/p1022ds/spl.c
+++ b/board/freescale/p1022ds/spl.c
@@ -102,7 +102,11 @@ void board_init_r(gd_t *gd, ulong dest_addr)
env_relocate();
#endif
- i2c_init(CONFIG_SYS_FSL_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+#ifdef CONFIG_SYS_I2C
+ i2c_init_all();
+#else
+ i2c_init(CONFIG_SYS_I2C_SPEED, CONFIG_SYS_I2C_SLAVE);
+#endif
gd-ram_size = initdram(0);
#ifdef CONFIG_SPL_NAND_BOOT
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: atmel_nand: support for software BCH ECC
Hi Bo, On 08/28/2013 04:54 PM, Bo Shen wrote: Add possible to use software BCH ECC for atmel nand driver Signed-off-by: Bo Shen voice.s...@gmail.com --- drivers/mtd/nand/atmel_nand.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c index 96aca00..52efbee 100644 --- a/drivers/mtd/nand/atmel_nand.c +++ b/drivers/mtd/nand/atmel_nand.c @@ -1177,7 +1177,11 @@ int atmel_nand_chip_init(int devnum, ulong base_addr) mtd-priv = nand; nand-IO_ADDR_R = nand-IO_ADDR_W = (void __iomem *)base_addr; +#ifdef CONFIG_NAND_ECC_BCH + nand-ecc.mode = NAND_ECC_SOFT_BCH; +#else nand-ecc.mode = NAND_ECC_SOFT; +#endif I don't think this is enough for sw supported bch. Where do you feed the libbch? Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-atmel/master - u-boot-arm/master
Hi Andreas, On Thu, 22 Aug 2013 17:04:43 +0200, Andreas Bießmann andreas.de...@googlemail.com wrote: Dear Albert Aribaud, The following changes since commit 9ed887caecb9ecb0c68773a1870d143b9f28d3da: Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2013-08-17 18:24:13 +0200) are available in the git repository at: git://git.denx.de/u-boot-atmel.git master for you to fetch changes up to bc6958988726977b4089da1b13f6467e8e28efd2: arm: atmel: cpux9k2: board update and enhancement (2013-08-22 16:52:40 +0200) Bo Shen (10): net: macb: fix the following building warning arm: atmel: add gmac support for sama5d3xek board arm: atmel: add nand trimffs subcommand for at91sam9n12 and at91sam9x5 arm: sama5d3: fix smc cs related registers offset arm: sama5d3: remove unused define arm: atmel: sama5d3: fix typo error for CONFIG_ENV_IS_NOWHERE arm: atmel: remove the config.mk file gpio: atmel: fix code to use pointer for pio port gpio: atmel: add gpio common API support gpio: atmel: add copyright and remove error header info Jens Scharsig (BuS Elektronik) (1): arm: atmel: cpux9k2: board update and enhancement Wu, Josh (5): ARM: at91: atmel_nand: pmecc driver will select the galois table by sector size ARM: at91: sama5d3: remove unused definition about PMECC alpha table offset linux/compat.h: move dev_err, dev_info and dev_dbg from usb driver to compat.h mtd: atmel_nand: alloc memory instead of use static array for pmecc data ARM: at91: atmel_nand: add code to check the ONFI parameter ECC requirement arch/arm/cpu/armv7/at91/sama5d3_devices.c| 24 +++ arch/arm/include/asm/arch-at91/at91_common.h |1 + arch/arm/include/asm/arch-at91/at91sam9x5.h |6 + arch/arm/include/asm/arch-at91/sama5d3.h |2 - arch/arm/include/asm/arch-at91/sama5d3_smc.h |2 +- board/atmel/at91sam9m10g45ek/config.mk |1 - board/atmel/at91sam9x5ek/config.mk |1 - board/atmel/sama5d3xek/sama5d3xek.c | 20 ++ doc/README.atmel_pmecc | 14 -- drivers/gpio/at91_gpio.c | 295 -- drivers/mtd/nand/atmel_nand.c| 198 - drivers/net/macb.c | 12 +- drivers/usb/musb-new/linux-compat.h | 16 -- include/configs/at91sam9m10g45ek.h |2 + include/configs/at91sam9n12ek.h |3 + include/configs/at91sam9x5ek.h |5 +- include/configs/eb_cpux9k2.h | 62 +++--- include/configs/sama5d3xek.h | 10 +- include/linux/compat.h |8 + 19 files changed, 486 insertions(+), 196 deletions(-) delete mode 100644 board/atmel/at91sam9m10g45ek/config.mk delete mode 100644 board/atmel/at91sam9x5ek/config.mk 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
Re: [U-Boot] [PULL] u-boot-atmel/master - u-boot-arm/master
Hi Andreas, On Wed, 04 Sep 2013 11:40:16 +0200, Andreas Bießmann andreas.de...@googlemail.com wrote: Hi Albert, can you please wait applying this? I have another 2-3 patches for this release. Argh! I've pushed it already. Just give me a new PR for these 2-3 patches, I'll take it in today. Best regards Andreas Bießmann Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for TechNexion edm1-cf-imx6 SoM
Stefano,
On Fri, 30 Aug 2013 16:43:28 +0200 Stefano Babic sba...@denx.de wrote:
Hi Tapani,
On some things we probably need some clarification, see inlined responses
to some of your questions.
I hope I can help you.
Well, we start to get it. Correct us if we are wrong.
Ma main concern iy your patchset is that the tables must be maintained
and duplicated in the source code. However, on the board if a pin is
dedicated to a specific function, it will be dedicated for the same
function even with the other variants of the processor.
We agree fully. Again, no need to beat a dead horse. :-)
The reason our patch used duplicate tables was because of the way our original
idea was received on the u-boot mailing list. It had the definitions just once.
Using C structure in u-boot is a strict rule - if you see, all code is
done in this way. No new code is accepted with base + offset syntax.
Are the strict rules written down somewhere, so people less involved in
u-boot development can read them before submitting?
We both know it is not valid C to use structs the way you want us to.
It is a quirk of the compiler that it works at all. The coding standard
for u-boot sounds to be very picky to adhere to the C standard.
Afair, Microsoft shot themselves in the foot badly assuming structs could be
used this way in early versions of MS Office. (Wrote structs to files, but
new versions could not load since the memory layout was different).
Sure, we might do it for the mmdc. But long term maintainable, it is not.
* It is a lot of effort to do struct accessors for huge tables. Both
of IOMUX and MMDC are large (offsets of 0x800+).
You forget that for iomuxc the job was already done - there is structure
and functions to setup the pinmux.
You would not accept code using the current iomux structure...
Having struct
accessors would take quite long to enter manually (two tables of 500+
entries
each, and different between cpu types). This would be hours, if not a day of
braindead work without any tangible benefit.
Sorry, I see benefits in terms of readability and maintenability of the
source code and it makes easier to add new boards. This is the reason
why there are accessors for iomuxc(), as well as for most SOC's internal
controller.
If making the addition of new boards easier is a goal, there are other parts
of the process that are currently a greater hurdle than writing the code. :-)
I could make those tables of { offset, value } and do the writels using
a for-loop, but that would just mariginally improve on the ugliness.
It is not what I meant - if we see the code, we can recognize the
sequence how the DDR3 must be programmed. We can have a function
realizing the logic (that is, wehich registers in which sequence) must
be written, and taking as arguments the parameters (calibration, and so
on) that for each chip are different. In other words, I would like that
some kind of function will be moved into common code, and not here in
board code.
To summarize, we are expected to:
(i) Create a more general DDR3 API for IMX6, to setup memory chips on any board?
(ii) Use the above API to redo our already working DDR setup for our board.
(iii) Rewrite the iomux struct(s) to more accurately reflect the iomux memory
space.
There is more than plain pinmuxing there.
(iv) Rewrite any code that gets broken from changing the iomux struct(s)
(v) Use the new struct(s) in setting up memory for our board
Some of the above might need to be done differently for different cpu variants.
We are worried that we might not familiar enough with u-boot development to get
such changes accepted in reasonable time.
Did we understand this correctly?
regards,
Tapani
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [U-boot] IRQ_STACK_START alignment question
Hi, experts: I have a question about IRQ statck pointer alignment. In arch/arm/lib/interrupts.c : In Interrupt_init(void) function: IRQ_STACK_START = gd-irq_sp - 4; IRQ_STACK_START_IN = gd-irq_sp + 8; FIQ_STACK_START = IRQ_STACK_START - CONFIG_STACKSIZE_IRQ; It seems not do alignment operation for IRQ_STACK_START / FIQ_STACK_START . Best wishes, ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-atmel/master - u-boot-arm/master
Hi Albert, On 09/04/2013 01:10 PM, Albert ARIBAUD wrote: Hi Andreas, On Wed, 04 Sep 2013 11:40:16 +0200, Andreas Bießmann andreas.de...@googlemail.com wrote: Hi Albert, can you please wait applying this? I have another 2-3 patches for this release. Argh! I've pushed it already. Just give me a new PR for these 2-3 patches, I'll take it in today. no problem, I'll send it the next few hours (just test building) Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: atmel_nand: support for software BCH ECC
Hi Andreas, On 9/4/2013 6:23 PM, Andreas Bießmann wrote: Hi Bo, On 08/28/2013 04:54 PM, Bo Shen wrote: Add possible to use software BCH ECC for atmel nand driver Signed-off-by: Bo Shen voice.s...@gmail.com --- drivers/mtd/nand/atmel_nand.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c index 96aca00..52efbee 100644 --- a/drivers/mtd/nand/atmel_nand.c +++ b/drivers/mtd/nand/atmel_nand.c @@ -1177,7 +1177,11 @@ int atmel_nand_chip_init(int devnum, ulong base_addr) mtd-priv = nand; nand-IO_ADDR_R = nand-IO_ADDR_W = (void __iomem *)base_addr; +#ifdef CONFIG_NAND_ECC_BCH + nand-ecc.mode = NAND_ECC_SOFT_BCH; +#else nand-ecc.mode = NAND_ECC_SOFT; +#endif I don't think this is enough for sw supported bch. Where do you feed the libbch? Yes, we need libbch. If we really want to enable software BCH support. It also need add following two options in board configuration file. ---8--- #define CONFIG_NAND_ECC_BCH #define CONFIG_BCH ---8--- So, this patch give us option to enable software BCH. Best regards Andreas Bießmann Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: atmel_nand: support for software BCH ECC
Hi Bo, On 09/04/2013 02:11 PM, Bo Shen wrote: Hi Andreas, On 9/4/2013 6:23 PM, Andreas Bießmann wrote: Hi Bo, On 08/28/2013 04:54 PM, Bo Shen wrote: Add possible to use software BCH ECC for atmel nand driver Signed-off-by: Bo Shen voice.s...@gmail.com --- drivers/mtd/nand/atmel_nand.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c index 96aca00..52efbee 100644 --- a/drivers/mtd/nand/atmel_nand.c +++ b/drivers/mtd/nand/atmel_nand.c @@ -1177,7 +1177,11 @@ int atmel_nand_chip_init(int devnum, ulong base_addr) mtd-priv = nand; nand-IO_ADDR_R = nand-IO_ADDR_W = (void __iomem *)base_addr; +#ifdef CONFIG_NAND_ECC_BCH +nand-ecc.mode = NAND_ECC_SOFT_BCH; +#else nand-ecc.mode = NAND_ECC_SOFT; +#endif I don't think this is enough for sw supported bch. Where do you feed the libbch? Yes, we need libbch. If we really want to enable software BCH support. It also need add following two options in board configuration file. ---8--- #define CONFIG_NAND_ECC_BCH #define CONFIG_BCH ---8--- So, this patch give us option to enable software BCH. got it. So the NAND_ECC_BCH is the adoption for the SW BCH correction in mtd layer. I understand that this would be helpful for at91 SoC without PMECC HW. But there is no user currently, so I hesitate to apply this. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net, phy, cpsw: fix unaligned access if no phy found
if phy_connect() did not find a phy, phydev is not initialized and following code in cpsw_phy_init() maybe crashes. Fix this. Signed-off-by: Heiko Schocher h...@denx.de Cc: Joe Hershberger joe.hershber...@gmail.com Cc: Mugunthan V N mugunthan...@ti.com Cc: Tom Rini tr...@ti.com --- Found on the dxr2 board with no phy connected to the board, U-Boot crashes with: U-Boot 2013.07-12701-gea98378-dirty (Sep 04 2013 - 06:58:16) I2C: ready DRAM: 128 MiB Enable d-cache FactorySet is not right in eeprom. NAND: 256 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 8-bit BCH HW ECC selected Net: Could not get PHY for cpsw: addr 0 data abort MAYBE you should read doc/README.arm-unaligned-accesses pc : [87f80574] lr : [87f80fcc] sp : 86f5aee0 ip : 0034 fp : 80100020 r10: 0014 r9 : 07e5d000 r8 : 86f5af30 r7 : 86f5f750 r6 : 86f5f804 r5 : 86f5f708 r4 : 86f5f750 r3 : r2 : r1 : 87fa4d08 r0 : Flags: nZCv IRQs off FIQs on Mode SVC_32 Resetting CPU ... resetting ... --- drivers/net/cpsw.c | 3 +++ 1 Datei geändert, 3 Zeilen hinzugefügt(+) diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c index 9bab71a..b18d528 100644 --- a/drivers/net/cpsw.c +++ b/drivers/net/cpsw.c @@ -947,6 +947,9 @@ static int cpsw_phy_init(struct eth_device *dev, struct cpsw_slave *slave) dev, slave-data-phy_if); + if (!phydev) + return -1; + phydev-supported = supported; phydev-advertising = phydev-supported; -- 1.7.11.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] SPL binary too large for OMAP4460 OCM
Hi, André From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] on behalf of André Schaller [an.sch...@googlemail.com] Sent: Wednesday, September 04, 2013 10:09 AM To: u-boot@lists.denx.de Subject: [U-Boot] SPL binary too large for OMAP4460 OCM Hi everybody, I need to add functionality to the SPL code. I tried to implement in a memory-saving way, however, the SPL is about 45 kB after compilation. To get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 * 1024). Now, the SPL as well as u-boot won't boot. After the device' (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output on terminal. My question: is it theoretically possible to to establish a successfully booting SPL with ~45 kB in size for this device? The device' on-chip-memory is 56kB so it could fit in there. If so, what needs to be configured / tuned to get it working? Are there any other features I could omit from the binary to make it smaller? Thanks a lot, André ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot We can use the area 0x4030 - 0x4030bfff for downloading the SPL image. If the image exceed this - it leads to corrupting the ROM code stack and the device hangs up. See my patch [U-Boot] [RFC PATCH] armv7:omap4-common: Correct check of the SPL image size. (It's not in mainline. I'll do some corrections and send v2 soon.) For HS devices the SPL image is loaded from the address 0x40304350. So we have 0x4030bfff - 0x40304350 = 0x7CAF = 31,919 bytes for SPL. The area from 0x4030 till 0x40304350 in HS devices is used for security data. If you have GP device you can use the whole 0x4030 - 0x4030bfff space i.e. 49,152 bytes, just change #define CONFIG_SPL_TEXT_BASE from 0x40304350 to 0x4030. Best regards, Oleg http://www.globallogic.com/email_disclaimer.txt http://www.globallogic.com/email_disclaimer.txt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am335x_evm.h: Add back the actual load of the kernel image
Somewhere along the line of refactoring the am335x header files, the kernel image load was lost, so put it back in. Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h index e0a87f8..7969e07 100644 --- a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@ -132,7 +132,9 @@ echo Running uenvcmd ...; \ run uenvcmd; \ fi; \ - run mmcloados; \ + if run loaduimage; then \ + run mmcloados; \ + fi; \ fi;\0 \ spiboot=echo Booting from spi ...; \ run spiargs; \ -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: atmel_nand: support for software BCH ECC
Hi Andreas, On 9/4/2013 8:30 PM, Andreas Bießmann wrote: Yes, we need libbch. If we really want to enable software BCH support. It also need add following two options in board configuration file. ---8--- #define CONFIG_NAND_ECC_BCH #define CONFIG_BCH ---8--- So, this patch give us option to enable software BCH. got it. So the NAND_ECC_BCH is the adoption for the SW BCH correction in mtd layer. I understand that this would be helpful for at91 SoC without PMECC HW. But there is no user currently, so I hesitate to apply this. Frankly, there is no EK boards from Atmel use software BCH now, however, a lot of customers use NAND with 224 bytes OOB, can not use software ECC, they need use software BCH. So, I think it is better to apply this patch. If it will break the rule of u-boot, then I think we can wait real user in u-boot need this and then apply this patch. Best regards Andreas Bießmann Best Regards, Bo Shen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/5] mtd: nand: omap: optimize and clean-up of OMAP NAND driver
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/02/2013 10:56 AM, Gupta, Pekon wrote: On 08/29/2013 01:26 PM, Gupta, Pekon wrote: [snip] I think we should move the selected message to a debug(). Second part of string nand: selected OMAP_ECC_BCH8_CODE_HW was specifically added in board_nand_init() because currently there is no way to identify the ECC scheme being used in u-boot. Unless digging into source code and reviewing board file. And many time end-users face ECC scheme mis-match between u-boot and linux when flashing kernel and file-system from u-boot. Thus this print helps in identifying the ECC scheme being used from logs. So, please keep this print nand: selected ecc-scheme .. ? I'd rather not as we should have left the mis-match problems in the past. We don't generally offer commands to switch ECC schemes as everyone is using the same now. When we do need to offer switching for legacy reasons that's when we should say what we're on. I think we should not deprecate the 'ecc_switching_utility', bcoz there are multiple scenarios even in newer devices where it is useful.. Example-1: using built-in NAND devices [snip] The ROM already needs to handle this mode and simply go with on die ECC and we need to mirror this behaviour. Example-2: upgrading ECC on legacy devices There are many users with devices in production, who would like to upgrade to newer ECC schemes (like BCH16), only when these drivers are stable. Such users depend on u-boot to switch newer ECC schemes (like BCH16) and then re-flash upgraded kernel and file-systems on remote machines. In such cases also 'ecc_switching_utility' is helpful. But they've got a problem today, which is that the ROM demands BCH16 already, so they have to use BCH16 or not be booting from NAND. Though I don't want to be stubborn here.. But if your plan is to completely remove 'ecc_switching_utility' support then I would move back to V2 version of this patch, where ecc scheme is selected by #CONFIGS, so that only that code footprint gets optimized. Please let me know, which way to go forward.. - [Patch V2 xx] where ECC selection is via #CONFIGS - [Patch V3 xx] where ECC selection can be done via software (ecc_switching_utility) Incase you opt for [V3], my humble request is to keep above prints and not to convert them into 'debug' (please) :-) We need to do run-time detection of what ecc mode is to be used. We don't want to expose the 'nandecc' type command we have on OMAP3 without a real case (and I don't count ones that can be constructed as an example on beaglebone + capes, but I do count real hardware designs). - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSJyzJAAoJENk4IS6UOR1WfiQP/Rwr5Gcqvg4RP6Rp7ppN0HSm suzbjCTgsWxY9SeSEO1L4GiGWRxZSAKkdE/KSYTPRPfjrdev+i6poZfoI6JlMK64 d/HnI37yAV4dOYA3tQImyXfZi+8teWKqm4vXyRsQqq9tJFmGppX4iRV9G8OVBUJv lZVEw+OpW2Fktq+jcMskwGz3TKYmMTDh4GlcQnX3BHltkOGe1lkCMmQoxxyAYkfO /O1gvwrvUhzkjgkRIG18rlHW34qMZqflAIfHNjSxXLpeuDYkCi6EsCJHTpelQuYG 3+9fAGY4zSleR+e29QfrgyuOSwR3s+ElZ1VmNRl7e0TeE9yb20frZCJhfYAq1vYu wjeKJcfkscPRYaGTUc7jhyyMgK2hrCk9kVCOdRfUrJe+ElaqlhU1/ugOADQky8bN QxqGwhSpPT8tLKBrUaIqix3DOMdt1yQXos+qhaFba73zMO+gwAtEHVWQELQIASLD K3mAcs3vfDzMvLke95xPNLA7KP09O9LV892ND+5v8/6UVDUQX2IyEjTjLKDeG7Ae P9OgE90UlbgxC7vEbtt1rxDLrhLr57EECigKjFhFsfFdSMkj+FEnyxb0Dmp+5JRY s0QxaRAz4nvpFW1KcTY2fhIaqiYEgLEMRcgcwiQeVxqezQAtRFlK9xAX7DmCjw5K zgzrEslpmfYxi3+DcF4Y =K7aI -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] RFC, am335x_evm.h patch for u-boot on SD and rest on eMMC on BBB
soldiering on with my configuring and building u-boot for my BBB, i have a proposal for include/configs/am335x_evm.h: #define CONFIG_BOOTCOMMAND \ run findfdt; \ run mmcboot; \ setenv mmcdev 1; \ setenv bootpart 1:2; \ setenv mmcroot /dev/mmcblk1p2 ro; \-- add this line run mmcboot; \ run nandboot; the rationale is for when there is a full, bootable OS in eMMC on the BBB, but someone wants to experiment with newer u-boot MLO and u-boot.img files. as you can see, there is an early attempt to run mmcboot off of SD card and, if that fails, the env vars are tweaked to now point to eMMC as plan B: setenv mmcdev 1; \ setenv bootpart 1:2; \ but if mmcroot isn't similariy tweaked, the boot process will still try to mount the second partition on the SD card as the root filesystem, which makes little sense. i realize you can use uEnv.txt to fix this, but it seems that the *default* should be that, if you're switching to eMMC for the boot partition, it only makes to switch to the same device for the root filesystem. thoughts? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net, phy, cpsw: fix unaligned access if no phy found
On Wed, Sep 04, 2013 at 02:16:01PM +0200, Heiko Schocher wrote: if phy_connect() did not find a phy, phydev is not initialized and following code in cpsw_phy_init() maybe crashes. Fix this. Signed-off-by: Heiko Schocher h...@denx.de Cc: Joe Hershberger joe.hershber...@gmail.com Cc: Mugunthan V N mugunthan...@ti.com Cc: Tom Rini tr...@ti.com --- Found on the dxr2 board with no phy connected to the board, U-Boot crashes with: U-Boot 2013.07-12701-gea98378-dirty (Sep 04 2013 - 06:58:16) I2C: ready DRAM: 128 MiB Enable d-cache FactorySet is not right in eeprom. NAND: 256 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 8-bit BCH HW ECC selected Net: Could not get PHY for cpsw: addr 0 data abort MAYBE you should read doc/README.arm-unaligned-accesses pc : [87f80574] lr : [87f80fcc] sp : 86f5aee0 ip : 0034 fp : 80100020 r10: 0014 r9 : 07e5d000 r8 : 86f5af30 r7 : 86f5f750 r6 : 86f5f804 r5 : 86f5f708 r4 : 86f5f750 r3 : r2 : r1 : 87fa4d08 r0 : Flags: nZCv IRQs off FIQs on Mode SVC_32 Resetting CPU ... resetting ... --- drivers/net/cpsw.c | 3 +++ 1 Datei ge??ndert, 3 Zeilen hinzugef??gt(+) diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c index 9bab71a..b18d528 100644 --- a/drivers/net/cpsw.c +++ b/drivers/net/cpsw.c @@ -947,6 +947,9 @@ static int cpsw_phy_init(struct eth_device *dev, struct cpsw_slave *slave) dev, slave-data-phy_if); + if (!phydev) + return -1; + phydev-supported = supported; phydev-advertising = phydev-supported; This isn't really an unaligned access problem it's a NULL pointer dereference, so I'll re-word the commit message when I grab this for u-boot-ti soon. -- 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] SPL binary too large for OMAP4460 OCM
On Wed, Sep 04, 2013 at 11:43:01AM +0300, Oleg Kosheliev wrote: Hi, Andr? From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] on behalf of Andr? Schaller [an.sch...@googlemail.com] Sent: Wednesday, September 04, 2013 10:09 AM To: u-boot@lists.denx.de Subject: [U-Boot] SPL binary too large for OMAP4460 OCM Hi everybody, I need to add functionality to the SPL code. I tried to implement in a memory-saving way, however, the SPL is about 45 kB after compilation. To get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 * 1024). Now, the SPL as well as u-boot won't boot. After the device' (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output on terminal. My question: is it theoretically possible to to establish a successfully booting SPL with ~45 kB in size for this device? The device' on-chip-memory is 56kB so it could fit in there. If so, what needs to be configured / tuned to get it working? Are there any other features I could omit from the binary to make it smaller? Thanks a lot, Andr? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot We can use the area 0x4030 - 0x4030bfff for downloading the SPL image. If the image exceed this - it leads to corrupting the ROM code stack and the device hangs up. See my patch [U-Boot] [RFC PATCH] armv7:omap4-common: Correct check of the SPL image size. (It's not in mainline. I'll do some corrections and send v2 soon.) For HS devices the SPL image is loaded from the address 0x40304350. So we have 0x4030bfff - 0x40304350 = 0x7CAF = 31,919 bytes for SPL. The area from 0x4030 till 0x40304350 in HS devices is used for security data. FWIW, this issue is one reason I think we need to stop trying to make GP devices work kinda-sorta like the HS devices do and instead add a CONFIG for HS devices that sets things correctly. -- 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] SPL binary too large for OMAP4460 OCM
On Wednesday 04 September 2013 06:48 PM, Tom Rini wrote: On Wed, Sep 04, 2013 at 11:43:01AM +0300, Oleg Kosheliev wrote: Hi, Andr? From: u-boot-boun...@lists.denx.de [u-boot-boun...@lists.denx.de] on behalf of Andr? Schaller [an.sch...@googlemail.com] Sent: Wednesday, September 04, 2013 10:09 AM To: u-boot@lists.denx.de Subject: [U-Boot] SPL binary too large for OMAP4460 OCM Hi everybody, I need to add functionality to the SPL code. I tried to implement in a memory-saving way, however, the SPL is about 45 kB after compilation. To get compilation working, I had to set CONFIG_SPL_MAX_SIZE to (45 * 1024). Now, the SPL as well as u-boot won't boot. After the device' (PandaBoard ES - OMAP4460) reset, nothing happens regarding it's output on terminal. My question: is it theoretically possible to to establish a successfully booting SPL with ~45 kB in size for this device? The device' on-chip-memory is 56kB so it could fit in there. If so, what needs to be configured / tuned to get it working? Are there any other features I could omit from the binary to make it smaller? Thanks a lot, Andr? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot We can use the area 0x4030 - 0x4030bfff for downloading the SPL image. If the image exceed this - it leads to corrupting the ROM code stack and the device hangs up. See my patch [U-Boot] [RFC PATCH] armv7:omap4-common: Correct check of the SPL image size. (It's not in mainline. I'll do some corrections and send v2 soon.) For HS devices the SPL image is loaded from the address 0x40304350. So we have 0x4030bfff - 0x40304350 = 0x7CAF = 31,919 bytes for SPL. The area from 0x4030 till 0x40304350 in HS devices is used for security data. FWIW, this issue is one reason I think we need to stop trying to make GP devices work kinda-sorta like the HS devices do and instead add a CONFIG for HS devices that sets things correctly. Yes, correct for OMAP4. Regards, Sricharan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: tegra: Add the Tamonten™ NG Evaluation Carrier board
Add support for the new Tamonten™ NG platform from Avionic Design.
Currently only I2C, MMC, USB and ethernet have been tested.
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
---
.../common/pinmux-config-tamonten-ng.h | 385 +
board/avionic-design/common/tamonten-ng.c | 129 +++
board/avionic-design/dts/tegra30-tamonten.dtsi | 74
board/avionic-design/dts/tegra30-tec-ng.dts| 8 +
board/avionic-design/tec-ng/Makefile | 32 ++
boards.cfg | 1 +
include/configs/tec-ng.h | 84 +
7 files changed, 713 insertions(+)
create mode 100644 board/avionic-design/common/pinmux-config-tamonten-ng.h
create mode 100644 board/avionic-design/common/tamonten-ng.c
create mode 100644 board/avionic-design/dts/tegra30-tamonten.dtsi
create mode 100644 board/avionic-design/dts/tegra30-tec-ng.dts
create mode 100644 board/avionic-design/tec-ng/Makefile
create mode 100644 include/configs/tec-ng.h
diff --git a/board/avionic-design/common/pinmux-config-tamonten-ng.h
b/board/avionic-design/common/pinmux-config-tamonten-ng.h
new file mode 100644
index 000..39df731
--- /dev/null
+++ b/board/avionic-design/common/pinmux-config-tamonten-ng.h
@@ -0,0 +1,385 @@
+/*
+ * (C) Copyright 2013
+ * Avionic Design GmbH www.avionic-design.de
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef _PINMUX_CONFIG_TAMONTEN_NG_H_
+#define _PINMUX_CONFIG_TAMONTEN_NG_H_
+
+#define DEFAULT_PINMUX(_pingroup, _mux, _pull, _tri, _io) \
+ { \
+ .pingroup = PINGRP_##_pingroup, \
+ .func = PMUX_FUNC_##_mux, \
+ .pull = PMUX_PULL_##_pull,\
+ .tristate = PMUX_TRI_##_tri, \
+ .io = PMUX_PIN_##_io, \
+ .lock = PMUX_PIN_LOCK_DEFAULT,\
+ .od = PMUX_PIN_OD_DEFAULT, \
+ .ioreset= PMUX_PIN_IO_RESET_DEFAULT,\
+ }
+
+#define I2C_PINMUX(_pingroup, _mux, _pull, _tri, _io, _lock, _od) \
+ { \
+ .pingroup = PINGRP_##_pingroup, \
+ .func = PMUX_FUNC_##_mux, \
+ .pull = PMUX_PULL_##_pull,\
+ .tristate = PMUX_TRI_##_tri, \
+ .io = PMUX_PIN_##_io, \
+ .lock = PMUX_PIN_LOCK_##_lock,\
+ .od = PMUX_PIN_OD_##_od,\
+ .ioreset= PMUX_PIN_IO_RESET_DEFAULT,\
+ }
+
+#define LV_PINMUX(_pingroup, _mux, _pull, _tri, _io, _lock, _ioreset) \
+ { \
+ .pingroup = PINGRP_##_pingroup, \
+ .func = PMUX_FUNC_##_mux, \
+ .pull = PMUX_PULL_##_pull,\
+ .tristate = PMUX_TRI_##_tri, \
+ .io = PMUX_PIN_##_io, \
+ .lock = PMUX_PIN_LOCK_##_lock,\
+ .od = PMUX_PIN_OD_DEFAULT, \
+ .ioreset= PMUX_PIN_IO_RESET_##_ioreset \
+ }
+
+#define DEFAULT_PADCFG(_padgrp, _slwf, _slwr, _drvup, _drvdn, _lpmd, _schmt,
_hsm) \
+ { \
+ .padgrp = PDRIVE_PINGROUP_##_padgrp,\
+ .slwf = _slwf,\
+ .slwr = _slwr,\
+ .drvup = _drvup, \
+ .drvdn = _drvdn, \
+ .lpmd = PGRP_LPMD_##_lpmd,\
+ .schmt = PGRP_SCHMT_##_schmt, \
+ .hsm= PGRP_HSM_##_hsm, \
+ }
+
+static struct pingroup_config tamonten_ng_pinmux_common[] = {
+ /* SDMMC1 pinmux */
+ DEFAULT_PINMUX(SDMMC1_CLK, SDMMC1, NORMAL, NORMAL, INPUT),
+ DEFAULT_PINMUX(SDMMC1_CMD, SDMMC1, UP, NORMAL, INPUT),
+ DEFAULT_PINMUX(SDMMC1_DAT0, SDMMC1, UP, NORMAL, INPUT),
+ DEFAULT_PINMUX(SDMMC1_DAT1, SDMMC1, UP, NORMAL, INPUT),
+ DEFAULT_PINMUX(SDMMC1_DAT2, SDMMC1, UP, NORMAL, INPUT),
+ DEFAULT_PINMUX(SDMMC1_DAT3, SDMMC1, UP, NORMAL, INPUT),
+
+ /* SDMMC3 pinmux */
+ DEFAULT_PINMUX(SDMMC3_CLK, SDMMC3, NORMAL, NORMAL, INPUT),
+ DEFAULT_PINMUX(SDMMC3_CMD, SDMMC3, UP, NORMAL, INPUT),
+ DEFAULT_PINMUX(SDMMC3_DAT0, SDMMC3, UP, NORMAL, INPUT),
+
[U-Boot] [PATCH 1/2] ARM: tegra: support SKU b1 of Tegra30
Add the Tegra30 SKU b1 and treat it like other Tegra30 chips.
Signed-off-by: Alban Bedel alban.be...@avionic-design.de
Reviewed-by: Julian Scheel julian.sch...@avionic-design.de
---
arch/arm/cpu/tegra-common/ap.c | 1 +
arch/arm/include/asm/arch-tegra/tegra.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/cpu/tegra-common/ap.c b/arch/arm/cpu/tegra-common/ap.c
index 6fb11cb..9e4085c 100644
--- a/arch/arm/cpu/tegra-common/ap.c
+++ b/arch/arm/cpu/tegra-common/ap.c
@@ -71,6 +71,7 @@ int tegra_get_chip_sku(void)
switch (sku_id) {
case SKU_ID_T33:
case SKU_ID_T30:
+ case SKU_ID_T30MQS:
return TEGRA_SOC_T30;
}
break;
diff --git a/arch/arm/include/asm/arch-tegra/tegra.h
b/arch/arm/include/asm/arch-tegra/tegra.h
index 25d1fc4..6b6ce85 100644
--- a/arch/arm/include/asm/arch-tegra/tegra.h
+++ b/arch/arm/include/asm/arch-tegra/tegra.h
@@ -65,6 +65,7 @@ enum {
SKU_ID_T25E = 0x1c,
SKU_ID_T33 = 0x80,
SKU_ID_T30 = 0x81, /* Cardhu value */
+ SKU_ID_T30MQS = 0xb1,
SKU_ID_T114_ENG = 0x00, /* Dalmore value, unfused */
SKU_ID_T114_1 = 0x01,
};
--
1.8.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/3] ARM: atmel: add RNDIS gadget support
Dear Andreas Bießmann,
Hi Bo,
On 09/04/2013 09:42 AM, Bo Shen wrote:
Hi Andreas,
On 9/4/2013 15:32, Andreas Bießmann wrote:
Hi Bo, Marek,
On 09/04/2013 04:01 AM, Bo Shen wrote:
Hi Marek Vasut,
On 09/04/2013 09:55 AM, Marek Vasut wrote:
I have considered to put this in driver, however, different Atmel
SoC have different attributes for each endpoint and different
number of endpoint.
for example;
at91sam9x5: EP(ep1, 1, 1024, 2, 1, 1)
sama5d3x: EP(ep1, 1, 1024, 3, 1, 0)
So, if I put this in driver, there will be many #ifdef. If newly SoC
added, maybe we will need to add #ifdef again. So, I put it here.
Can you not pull it into some header file at least? Having it in the
board file
will clearly result in duplication.
OK, I will put it into header file.
I'm fine with a header too. But for the records, the mentioned file is
_not_ board code but SoC code.
I will create a header file named atmel_usba_udc.h as other peripheral
(at91_udc.h is reserved for full speed usb device), and put it under
arm/arm/include/asm/arch-at91/, the contents as following, does it OK?
---8---
/*
* Copyright (C) 2005-2013 Atmel Corporation
* Bo Shen voice.s...@atmel.com
*
* SPDX-License-Identifier: GPL-2.0+
*/
#ifndef __ATMEL_USBA_UDC_H__
#define __ATMEL_USBA_UDC_H__
#include linux/usb/atmel_usba_udc.h
#define EP(nam, idx, maxpkt, maxbk, dma, isoc) \
[idx] = { \
.name = nam, \
.index = idx, \
.fifo_size = maxpkt, \
.nr_banks = maxbk,\
.can_dma= dma, \
.can_isoc = isoc, \
}
#if defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45) || \
defined(CONFIG_AT91SAM9X5)
static struct usba_ep_data usba_udc_ep[] = {
EP(ep0, 0, 64, 1, 0, 0),
... ...
EP(ep6, 6, 1024, 3, 1, 1),
};
#elif defined(CONFIG_SAMA5D3)
static struct usba_ep_data usba_udc_ep[] = {
EP(ep0, 0, 64, 1, 0, 0),
..
EP(ep15, 15, 1024, 2, 0, 0),
};
#else
# error NO usba_udc_ep defined
#endif
#undef EP
struct usba_platform_data pdata = {
.num_ep = ARRAY_SIZE(usba_udc_ep),
.ep = usba_udc_ep,
};
#endif
---8---
I'm fine with that.
Same here, I'm fine with it
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ums: Add dev num parameter. Check mmc device before do ums init.
Dear Przemyslaw Marczak,
Hello Marek,
Thank you for reply.
On 09/04/2013 12:26 AM, Marek Vasut wrote:
Dear Przemyslaw Marczak,
This change allows using every mmc device instance with ums, like eMMC
or SD cards. Now MMC device is checked before ums is inited.
Example of use: ums device_number for mmc devices.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Marek Vasut marek.va...@gmail.com
---
board/samsung/trats/trats.c | 12 +++-
common/cmd_usb_mass_storage.c | 30 ++
include/usb_mass_storage.h|4 ++--
3 files changed, 19 insertions(+), 27 deletions(-)
diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index 7f61d17..b7f7b05 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -816,17 +816,11 @@ static struct ums_board_info ums_board = {
},
};
-struct ums_board_info *board_ums_init(unsigned int dev_num, unsigned
int offset, -unsigned int part_size)
+struct ums_board_info *board_ums_init(struct mmc *mmc, unsigned int
offset, + unsigned int part_size)
{
- struct mmc *mmc;
-
- mmc = find_mmc_device(dev_num);
- if (!mmc)
- return NULL;
-
ums_board.ums_dev.mmc = mmc;
- ums_board.ums_dev.dev_num = dev_num;
+ ums_board.ums_dev.dev_num = mmc-block_dev.dev;
You already pass mmc, why pass mmc-block_dev.dev too? Is it not a
little redundant?
You are right, it is little redundant but pointer to this structure is
returned so we expect that structure fields were proper filled, right?
Why not just remove the dev_num field ? The UMS core can retrieve that
information itself.
[...]
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Huang Shijie, 于 2013年09月03日 19:53, Marek Vasut 写道: questions comes to mind. Is JFFS2 support in Linux 3.7 not compatible with JFFS2 in Linux -next? Is this true? Can I not mount JFFS2 partition under Linux-next The jffs2 does not changed since the linux 3.7. All the changes happened in the drivers and mtd code. OK, JFFS2 aside then, let's focus on MTD core code. The gpmi does not support the jffs2 all the time. Only apply the slc/mlc patch set, the gpmi can support the jffs2. How come hector was then able to write his JFFS2 partition ? So the jffs2 support is compatiable all the time. Is the old Freescale 2.6.35 GPMI NAND format compatible with the one after applying this patchset? that I could mount with Linux 3.7 and earlier? I think the mount can be succeeded. Ok, does that mean that we need this patchset in U-Boot in order to properly write JFFS2 onto GPMI NAND there? Is that the message you wanted to relay to us? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] USB: xHCI: Add header for readl/writel functions
Dear Dan Murphy, Add the asm/io.h header to resolve implicit declaration of readl/writel Signed-off-by: Dan Murphy dmur...@ti.com --- drivers/usb/host/xhci.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h index 467afe0..91935f0 100644 --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -27,6 +27,8 @@ #ifndef HOST_XHCI_H_ #define HOST_XHCI_H_ +#include asm/io.h + #include asm/cache.h #include linux/list.h I think this can be merged into Vivek's next round? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/7] USB: xHCI: Add stack support for xHCI
Dear Dan Murphy, On 08/21/2013 05:12 AM, Vivek Gautam wrote: This adds stack layer for eXtensible Host Controller Interface which facilitates use of USB 3.0 in host mode. Adapting xHCI host controller driver in linux-kernel by Sarah Sharp to needs in u-boot. This adds the basic xHCI host controller driver with bare minimum features: - Control/Bulk transfer support has been added with required infrastructure for necessary xHC data structures. - Stream protocol hasn't been supported yet. - No support for quirky devices has been added. Signed-off-by: Vikas C Sajjan vikas.saj...@samsung.com Signed-off-by: Julius Werner jwer...@chromium.org Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Simon Glass s...@chromium.org Cc: Minkyu Kang mk7.k...@samsung.com Cc: Dan Murphy dmur...@ti.com Cc: Marek Vasut ma...@denx.de [...] Besides what Dan said, please see [1] , point 4. I miss the exact point in Linux kernel history (read commit hash) from which this code was imported at least. [1] http://www.denx.de/wiki/view/U-Boot/Patches#Attributing_Code_Copyrights_Sign Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/4] MTD UBI fixes
This patchset corrects a few issues I've had whilst using UBI with U-boot. The first 3 are bug fixes, the 4th is an addition I needed in order to write a large root filesystem into my NAND device. Changes since v1: - Fixed style issues in cmd_ubi: add write.part command... as per Stefan Roese's comments. - Expanded upon the condition patch 1 fixes in response to the queries from Stefan, see the commit message for further detail. - Added patch 3 cmd_ubi: use int64_t volume size for 'ubi create' which it seems appropriate to include in this series. Paul Burton (4): mtd: driver _read() returns max_bitflips; mtd_read() returns -EUCLEAN cmd_mtdparts: use 64 bits for flash size, partition size offset cmd_ubi: use int64_t volume size for 'ubi create' cmd_ubi: add write.part command, to write a volume in multiple parts common/cmd_mtdparts.c | 54 ++ common/cmd_ubi.c | 79 +++--- doc/README.ubi | 3 ++ drivers/mtd/mtdcore.c | 14 ++- drivers/mtd/mtdpart.c | 12 +++--- drivers/mtd/nand/nand_base.c | 18 +++-- drivers/mtd/onenand/onenand_base.c | 3 +- include/jffs2/load_kernel.h| 6 +-- include/linux/mtd/nand.h | 3 ++ 9 files changed, 129 insertions(+), 63 deletions(-) -- 1.8.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] cmd_mtdparts: use 64 bits for flash size, partition size offset
This matches the 64 bit size in struct mtd_info and allows the mtdparts
command to function correctly with a flash = 4GiB. Format specifiers
for size offset are given the ll length, matching its use in
drivers/mtd in absence of something like inttypes.h/PRIx64.
Signed-off-by: Paul Burton paul.bur...@imgtec.com
---
common/cmd_mtdparts.c | 54 -
include/jffs2/load_kernel.h | 6 ++---
2 files changed, 32 insertions(+), 28 deletions(-)
diff --git a/common/cmd_mtdparts.c b/common/cmd_mtdparts.c
index 3023479..453ed57 100644
--- a/common/cmd_mtdparts.c
+++ b/common/cmd_mtdparts.c
@@ -93,13 +93,13 @@
DECLARE_GLOBAL_DATA_PTR;
/* special size referring to all the remaining space in a partition */
-#define SIZE_REMAINING 0x
+#define SIZE_REMAINING (~0llu)
/* special offset value, it is used when not provided by user
*
* this value is used temporarily during parsing, later such offests
* are recalculated */
-#define OFFSET_NOT_SPECIFIED 0x
+#define OFFSET_NOT_SPECIFIED (~0llu)
/* minimum partition size */
#define MIN_PART_SIZE 4096
@@ -160,9 +160,9 @@ static int device_del(struct mtd_device *dev);
* @param retptr output pointer to next char after parse completes (output)
* @return resulting unsigned int
*/
-static unsigned long memsize_parse (const char *const ptr, const char **retptr)
+static u64 memsize_parse (const char *const ptr, const char **retptr)
{
- unsigned long ret = simple_strtoul(ptr, (char **)retptr, 0);
+ u64 ret = simple_strtoull(ptr, (char **)retptr, 0);
switch (**retptr) {
case 'G':
@@ -193,20 +193,20 @@ static unsigned long memsize_parse (const char *const
ptr, const char **retptr)
* @param buf output buffer
* @param size size to be converted to string
*/
-static void memsize_format(char *buf, u32 size)
+static void memsize_format(char *buf, u64 size)
{
#define SIZE_GB ((u32)1024*1024*1024)
#define SIZE_MB ((u32)1024*1024)
#define SIZE_KB ((u32)1024)
if ((size % SIZE_GB) == 0)
- sprintf(buf, %ug, size/SIZE_GB);
+ sprintf(buf, %llug, size/SIZE_GB);
else if ((size % SIZE_MB) == 0)
- sprintf(buf, %um, size/SIZE_MB);
+ sprintf(buf, %llum, size/SIZE_MB);
else if (size % SIZE_KB == 0)
- sprintf(buf, %uk, size/SIZE_KB);
+ sprintf(buf, %lluk, size/SIZE_KB);
else
- sprintf(buf, %u, size);
+ sprintf(buf, %llu, size);
}
/**
@@ -310,6 +310,7 @@ static int part_validate_eraseblock(struct mtdids *id,
struct part_info *part)
struct mtd_info *mtd = NULL;
int i, j;
ulong start;
+ u64 offset, size;
if (get_mtd_info(id-type, id-num, mtd))
return 1;
@@ -321,14 +322,16 @@ static int part_validate_eraseblock(struct mtdids *id,
struct part_info *part)
* Only one eraseregion (NAND, OneNAND or uniform NOR),
* checking for alignment is easy here
*/
- if ((unsigned long)part-offset % mtd-erasesize) {
+ offset = part-offset;
+ if (do_div(offset, mtd-erasesize)) {
printf(%s%d: partition (%s) start offset
alignment incorrect\n,
MTD_DEV_TYPE(id-type), id-num, part-name);
return 1;
}
- if (part-size % mtd-erasesize) {
+ size = part-size;
+ if (do_div(size, mtd-erasesize)) {
printf(%s%d: partition (%s) size alignment
incorrect\n,
MTD_DEV_TYPE(id-type), id-num, part-name);
return 1;
@@ -396,7 +399,7 @@ static int part_validate(struct mtdids *id, struct
part_info *part)
part-size = id-size - part-offset;
if (part-offset id-size) {
- printf(%s: offset %08x beyond flash size %08x\n,
+ printf(%s: offset %08llx beyond flash size %08llx\n,
id-mtd_id, part-offset, id-size);
return 1;
}
@@ -579,8 +582,8 @@ static int part_add(struct mtd_device *dev, struct
part_info *part)
static int part_parse(const char *const partdef, const char **ret, struct
part_info **retpart)
{
struct part_info *part;
- unsigned long size;
- unsigned long offset;
+ u64 size;
+ u64 offset;
const char *name;
int name_len;
unsigned int mask_flags;
@@ -599,7 +602,7 @@ static int part_parse(const char *const partdef, const char
**ret, struct part_i
} else {
size = memsize_parse(p, p);
if (size MIN_PART_SIZE) {
- printf(partition size too small (%lx)\n, size);
+ printf(partition size too small (%llx)\n,
[U-Boot] [PATCH v2 1/4] mtd: driver _read() returns max_bitflips; mtd_read() returns -EUCLEAN
Linux modified the MTD driver interface in commit edbc4540 (with the
same name as this commit). The effect is that calls to mtd_read will
not return -EUCLEAN if the number of ECC-corrected bit errors is below
a certain threshold, which defaults to the strength of the ECC. This
allows -EUCLEAN to stop indicating some bits were corrected and begin
indicating a large number of bits were corrected, the data held in
this region of flash may be lost soon. UBI makes use of this and when
-EUCLEAN is returned from mtd_read it will move data to another block
of flash. Without adopting this interface change UBI on U-boot attempts
to move data between blocks every time a single bit is corrected using
the ECC, which is a very common occurance on some devices.
For some devices where bit errors are common enough, UBI can get stuck
constantly moving data around because each block it attempts to use has
a single bit error. This condition is hit when wear_leveling_worker
attempts to move data from one PEB to another in response to an
-EUCLEAN/UBI_IO_BITFLIPS error. When this happens ubi_eba_copy_leb is
called to perform the data copy, and after the data is written it is
read back to check its validity. If that read returns UBI_IO_BITFLIPS
(in response to an MTD -EUCLEAN) then ubi_eba_copy_leb returns 1 to
wear_leveling worker, which then proceeds to schedule the destination
PEB for erasure. This leads to erase_worker running on the PEB, and
following a successful erase wear_leveling_worker is called which
begins this whole cycle all over again. The end result is that (without
UBI debug output enabled) the boot appears to simply hang whilst in
reality U-boot busily works away at destroying a block of the NAND
flash. Debug output from this situation:
UBI DBG: ensure_wear_leveling: schedule scrubbing
UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 1027
UBI DBG: ubi_io_read: read 4096 bytes from PEB 1027:4096
UBI DBG: ubi_eba_copy_leb: copy LEB 0:0, PEB 1027 to PEB 4083
UBI DBG: ubi_eba_copy_leb: read 1040384 bytes of data
UBI DBG: ubi_io_read: read 1040384 bytes from PEB 1027:8192
UBI: fixable bit-flip detected at PEB 1027
UBI DBG: ubi_io_write_vid_hdr: write VID header to PEB 4083
UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:4096
UBI DBG: ubi_io_read_vid_hdr: read VID header from PEB 4083
UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:4096
UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:8192
UBI DBG: ubi_io_read: read 4096 bytes from PEB 4083:8192
UBI: fixable bit-flip detected at PEB 4083
UBI DBG: schedule_erase: schedule erasure of PEB 4083, EC 55, torture 0
UBI DBG: erase_worker: erase PEB 4083 EC 55
UBI DBG: sync_erase: erase PEB 4083, old EC 55
UBI DBG: do_sync_erase: erase PEB 4083
UBI DBG: sync_erase: erased PEB 4083, new EC 56
UBI DBG: ubi_io_write_ec_hdr: write EC header to PEB 4083
UBI DBG: ubi_io_write: write 4096 bytes to PEB 4083:0
UBI DBG: ensure_wear_leveling: schedule scrubbing
UBI DBG: wear_leveling_worker: scrub PEB 1027 to PEB 4083
...
This patch adopts the interface change as in Linux commit edbc4540 in
order to avoid such situations. Given that none of the drivers under
drivers/mtd return -EUCLEAN, this should only affect those using
software ECC. I have tested that it works on a board which is
currently out of tree, but which I hope to be able to begin
upstreaming soon.
Signed-off-by: Paul Burton paul.bur...@imgtec.com
---
Changes from v1:
- Expanded upon the condition this fixes in the commit message.
---
drivers/mtd/mtdcore.c | 14 +-
drivers/mtd/mtdpart.c | 12 ++--
drivers/mtd/nand/nand_base.c | 18 ++
drivers/mtd/onenand/onenand_base.c | 3 ++-
include/linux/mtd/nand.h | 3 +++
5 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c
index 49c0814..deda5f2 100644
--- a/drivers/mtd/mtdcore.c
+++ b/drivers/mtd/mtdcore.c
@@ -217,11 +217,23 @@ int mtd_erase(struct mtd_info *mtd, struct erase_info
*instr)
int mtd_read(struct mtd_info *mtd, loff_t from, size_t len, size_t *retlen,
u_char *buf)
{
+ int ret_code;
if (from 0 || from mtd-size || len mtd-size - from)
return -EINVAL;
if (!len)
return 0;
- return mtd-_read(mtd, from, len, retlen, buf);
+
+ /*
+* In the absence of an error, drivers return a non-negative integer
+* representing the maximum number of bitflips that were corrected on
+* any one ecc region (if applicable; zero otherwise).
+*/
+ ret_code = mtd-_read(mtd, from, len, retlen, buf);
+ if (unlikely(ret_code 0))
+ return ret_code;
+ if (mtd-ecc_strength == 0)
+ return 0; /* device lacks ecc */
+ return ret_code = mtd-bitflip_threshold ? -EUCLEAN : 0;
[U-Boot] [PATCH 3/4] cmd_ubi: use int64_t volume size for 'ubi create'
int64_t matches the bytes field in struct ubi_mkvol_req to which the
size is assigned. With the prior signed 32 bit integer, volumes were
restricted to being less than 2GiB in size.
Signed-off-by: Paul Burton paul.bur...@imgtec.com
---
common/cmd_ubi.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/common/cmd_ubi.c b/common/cmd_ubi.c
index 5ba4feb..f11cb61 100644
--- a/common/cmd_ubi.c
+++ b/common/cmd_ubi.c
@@ -167,7 +167,7 @@ bad:
return err;
}
-static int ubi_create_vol(char *volume, int size, int dynamic)
+static int ubi_create_vol(char *volume, int64_t size, int dynamic)
{
struct ubi_mkvol_req req;
int err;
@@ -191,7 +191,7 @@ static int ubi_create_vol(char *volume, int size, int
dynamic)
printf(verify_mkvol_req failed %d\n, err);
return err;
}
- printf(Creating %s volume %s of size %d\n,
+ printf(Creating %s volume %s of size %lld\n,
dynamic ? dynamic : static, volume, size);
/* Call real ubi create volume */
return ubi_create_volume(ubi, req);
@@ -498,7 +498,7 @@ int ubi_part(char *part_name, const char *vid_header_offset)
static int do_ubi(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
- size_t size = 0;
+ int64_t size = 0;
ulong addr = 0;
if (argc 2)
@@ -558,13 +558,13 @@ static int do_ubi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
/* E.g., create volume size */
if (argc == 4) {
- size = simple_strtoul(argv[3], NULL, 16);
+ size = simple_strtoull(argv[3], NULL, 16);
argc--;
}
/* Use maximum available size */
if (!size) {
- size = ubi-avail_pebs * ubi-leb_size;
- printf(No size specified - Using max size (%u)\n,
size);
+ size = (int64_t)ubi-avail_pebs * ubi-leb_size;
+ printf(No size specified - Using max size (%lld)\n,
size);
}
/* E.g., create volume */
if (argc == 3)
@@ -590,7 +590,7 @@ static int do_ubi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
ret = ubi_volume_write(argv[3], (void *)addr, size);
if (!ret) {
- printf(%d bytes written to volume %s\n, size,
+ printf(%lld bytes written to volume %s\n, size,
argv[3]);
}
@@ -613,7 +613,7 @@ static int do_ubi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
if (argc == 3) {
- printf(Read %d bytes from volume %s to %lx\n, size,
+ printf(Read %lld bytes from volume %s to %lx\n, size,
argv[3], addr);
return ubi_volume_read(argv[3], (char *)addr, size);
--
1.8.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] patchwork updated
Hey all, I've gone over the unassigned patchwork queue and done a triage and assign. There's some obvious superseded patches I'll mark soon, if not beaten to it. Any incorrect assignments are clearly my fault. -- 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] [PATCH v2 4/4] cmd_ubi: add write.part command, to write a volume in multiple parts
This allows you to write data to an UBI volume when the amount of memory
available to write that data from is less than the total size of the
data. For example, you may split a root filesystem UBIFS image into
parts, provide the total size of the image to the first write.part
command and then use multiple write.part commands to write the
subsequent parts of the volume. This results in a sequence of commands
akin to:
ext4load mmc 0:1 0x8000 rootfs.ubifs.0
ubi write.part 0x8000 root 0x0800 0x1800
ext4load mmc 0:1 0x8000 rootfs.ubifs.1
ubi write.part 0x8000 root 0x0800
ext4load mmc 0:1 0x8000 rootfs.ubifs.2
ubi write.part 0x8000 root 0x0800
This would write 384MiB of data to the UBI volume 'root' whilst only
requiring 128MiB of said data to be held in memory at a time.
Signed-off-by: Paul Burton paul.bur...@imgtec.com
---
Changes from v1:
- Style fixes (braces) to address Stefan Roese's comments.
---
common/cmd_ubi.c | 63 ++--
doc/README.ubi | 3 +++
2 files changed, 51 insertions(+), 15 deletions(-)
diff --git a/common/cmd_ubi.c b/common/cmd_ubi.c
index f11cb61..122ba7e 100644
--- a/common/cmd_ubi.c
+++ b/common/cmd_ubi.c
@@ -266,28 +266,15 @@ out_err:
return err;
}
-int ubi_volume_write(char *volume, void *buf, size_t size)
+int ubi_volume_continue_write(char *volume, void *buf, size_t size)
{
int err = 1;
- int rsvd_bytes = 0;
struct ubi_volume *vol;
vol = ubi_find_volume(volume);
if (vol == NULL)
return ENODEV;
- rsvd_bytes = vol-reserved_pebs * (ubi-leb_size - vol-data_pad);
- if (size 0 || size rsvd_bytes) {
- printf(size volume size! Aborting!\n);
- return EINVAL;
- }
-
- err = ubi_start_update(ubi, vol, size);
- if (err 0) {
- printf(Cannot start volume update\n);
- return -err;
- }
-
err = ubi_more_update_data(ubi, vol, buf, size);
if (err 0) {
printf(Couldnt or partially wrote data\n);
@@ -314,6 +301,37 @@ int ubi_volume_write(char *volume, void *buf, size_t size)
return 0;
}
+int ubi_volume_begin_write(char *volume, void *buf, size_t size,
+ size_t full_size)
+{
+ int err = 1;
+ int rsvd_bytes = 0;
+ struct ubi_volume *vol;
+
+ vol = ubi_find_volume(volume);
+ if (vol == NULL)
+ return ENODEV;
+
+ rsvd_bytes = vol-reserved_pebs * (ubi-leb_size - vol-data_pad);
+ if (size 0 || size rsvd_bytes) {
+ printf(size volume size! Aborting!\n);
+ return EINVAL;
+ }
+
+ err = ubi_start_update(ubi, vol, full_size);
+ if (err 0) {
+ printf(Cannot start volume update\n);
+ return -err;
+ }
+
+ return ubi_volume_continue_write(volume, buf, size);
+}
+
+int ubi_volume_write(char *volume, void *buf, size_t size)
+{
+ return ubi_volume_begin_write(volume, buf, size, size);
+}
+
int ubi_volume_read(char *volume, char *buf, size_t size)
{
int err, lnum, off, len, tbuf_size;
@@ -588,7 +606,20 @@ static int do_ubi(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
addr = simple_strtoul(argv[2], NULL, 16);
size = simple_strtoul(argv[4], NULL, 16);
- ret = ubi_volume_write(argv[3], (void *)addr, size);
+ if (strlen(argv[1]) == 10
+ strncmp(argv[1] + 5, .part, 5) == 0) {
+ if (argc 6) {
+ ret = ubi_volume_continue_write(argv[3],
+ (void *)addr, size);
+ } else {
+ size_t full_size;
+ full_size = simple_strtoul(argv[5], NULL, 16);
+ ret = ubi_volume_begin_write(argv[3],
+ (void *)addr, size, full_size);
+ }
+ } else {
+ ret = ubi_volume_write(argv[3], (void *)addr, size);
+ }
if (!ret) {
printf(%lld bytes written to volume %s\n, size,
argv[3]);
@@ -636,6 +667,8 @@ U_BOOT_CMD(
- create volume name with size\n
ubi write[vol] address volume size
- Write volume from address with size\n
+ ubi write.part address volume size [fullsize]\n
+- Write part of a volume from address\n
ubi read[vol] address volume [size]
- Read volume to address with size\n
ubi remove[vol] volume
diff --git a/doc/README.ubi b/doc/README.ubi
index 3cf4ef2..d82c75c 100644
--- a/doc/README.ubi
+++ b/doc/README.ubi
@@ -14,6 +14,8 @@ ubi part [part] [offset]
ubi info [l[ayout]] - Display volume and
Re: [U-Boot] [PATCH v2 6/7] config: arm: exynos5250: Define CONFIG_SYS_CACHELINE_SIZE
Dear Vivek Gautam, XHCI stack driver needs this to align buffers to CacheLine boundary. So define the same to be '64' Signed-off-by: Vivek Gautam gautam.vi...@samsung.com Cc: Julius Werner jwer...@chromium.org Cc: Simon Glass s...@chromium.org Cc: Minkyu Kang mk7.k...@samsung.com Cc: Dan Murphy dmur...@ti.com Cc: Marek Vasut ma...@denx.de --- include/configs/exynos5250-dt.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/exynos5250-dt.h b/include/configs/exynos5250-dt.h index 8f8f85f..86d57e3 100644 --- a/include/configs/exynos5250-dt.h +++ b/include/configs/exynos5250-dt.h @@ -37,6 +37,8 @@ /* Keep L2 Cache Disabled */ #define CONFIG_SYS_DCACHE_OFF +#define CONFIG_SYS_CACHELINE_SIZE64 + /* Enable ACE acceleration for SHA1 and SHA256 */ #define CONFIG_EXYNOS_ACE_SHA #define CONFIG_SHA_HW_ACCEL Albert, care to apply this one separatelly? Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] spl_mmc: only call printf or puts with CONFIG_SPL_LIBCOMMON_SUPPORT
If we don't have CONFIG_SPL_LIBCOMMON_SUPPORT defined then stdio
functions are unavailable calling them will cause a link failure.
Signed-off-by: Paul Burton paul.bur...@imgtec.com
---
common/spl/spl_mmc.c | 16
1 file changed, 16 insertions(+)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index 5e7e0fe..fc2f226 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -44,8 +44,10 @@ static int mmc_load_image_raw(struct mmc *mmc, unsigned long
sector)
(void *)spl_image.load_addr);
end:
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
if (err == 0)
printf(spl: mmc blk read err - %lu\n, err);
+#endif
return (err == 0);
}
@@ -57,7 +59,9 @@ static int mmc_load_image_raw_os(struct mmc *mmc)
CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR,
CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS,
(void *)CONFIG_SYS_SPL_ARGS_ADDR)) {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
printf(mmc args blk read error\n);
+#endif
return -1;
}
@@ -83,9 +87,11 @@ static int mmc_load_image_fat(struct mmc *mmc, const char
*filename)
err = file_fat_read(filename, (u8 *)spl_image.load_addr, 0);
end:
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
if (err = 0)
printf(spl: error reading image %s, err - %d\n,
filename, err);
+#endif
return (err = 0);
}
@@ -98,8 +104,10 @@ static int mmc_load_image_fat_os(struct mmc *mmc)
err = file_fat_read(CONFIG_SPL_FAT_LOAD_ARGS_NAME,
(void *)CONFIG_SYS_SPL_ARGS_ADDR, 0);
if (err = 0) {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
printf(spl: error reading image %s, err - %d\n,
CONFIG_SPL_FAT_LOAD_ARGS_NAME, err);
+#endif
return -1;
}
@@ -119,13 +127,17 @@ void spl_mmc_load_image(void)
/* We register only one device. So, the dev id is always 0 */
mmc = find_mmc_device(0);
if (!mmc) {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
puts(spl: mmc device not found!!\n);
+#endif
hang();
}
err = mmc_init(mmc);
if (err) {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
printf(spl: mmc init failed: err - %d\n, err);
+#endif
hang();
}
@@ -144,7 +156,9 @@ void spl_mmc_load_image(void)
err = fat_register_device(mmc-block_dev,
CONFIG_SYS_MMC_SD_FAT_BOOT_PARTITION);
if (err) {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
printf(spl: fat register err - %d\n, err);
+#endif
hang();
}
@@ -154,7 +168,9 @@ void spl_mmc_load_image(void)
err = mmc_load_image_fat(mmc, CONFIG_SPL_FAT_LOAD_PAYLOAD_NAME);
#endif
} else {
+#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
puts(spl: wrong MMC boot mode\n);
+#endif
hang();
}
--
1.8.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] spl: remove unnecessary ( ARM specific) include of asm/utils.h
ARM is the only architecture which includes this header and nothing in spl_mmc.c makes use of it. Remove the include. Signed-off-by: Paul Burton paul.bur...@imgtec.com --- common/spl/spl_mmc.c | 1 - 1 file changed, 1 deletion(-) diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c index f27b4c2..5e7e0fe 100644 --- a/common/spl/spl_mmc.c +++ b/common/spl/spl_mmc.c @@ -9,7 +9,6 @@ #include common.h #include spl.h #include asm/u-boot.h -#include asm/utils.h #include mmc.h #include fat.h #include version.h -- 1.8.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] mtd: atmel_nand: pmecc: fix bug fail to correct bit error in 1024-bytes sector
Dear Josh Wu, Josh Wu josh...@atmel.com writes: The PMECC use BCH algorithm to correct error. In BCH algorithm, the primitive polynomial value is GF(2^13) for 512-bytes sector size. And it is GF(2^14) for 1024-bytes sector size. This patch will choose correct degree of the remainders (13 or 14) for applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-atmel/master - u-boot-arm/master
Dear Albert Aribaud, please pull these two fixes into u-boot-arm/master for 2013.10 release. The following changes since commit 4eef93da262048eb1118e726b3ec5b8ebd3c6c91: Merge branch 'u-boot-atmel/master' into 'u-boot-arm/master' (2013-09-04 11:50:25 +0200) are available in the git repository at: git://git.denx.de/u-boot-atmel.git master for you to fetch changes up to 27871e6b519ccd933bd91c879241995c272fef3b: ARM: atmel: sama5d3: drop unused CONFIG_NET_MULTI (2013-09-04 17:07:30 +0200) Bo Shen (1): ARM: atmel: sama5d3: drop unused CONFIG_NET_MULTI Wu, Josh (1): mtd: atmel_nand: pmecc: fix bug fail to correct bit error in 1024-bytes sector drivers/mtd/nand/atmel_nand.c |3 ++- include/configs/sama5d3xek.h |1 - 2 files changed, 2 insertions(+), 2 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Tom, On Wed, 28 Aug 2013 14:25:07 -0400, Tom Rini tr...@ti.com wrote: Hello, The following changes since commit 9ed887caecb9ecb0c68773a1870d143b9f28d3da: Merge branch 'u-boot-imx/master' into 'u-boot-arm/master' (2013-08-17 18:24:13 +0200) are available in the git repository at: git://git.denx.de/u-boot-ti.git master for you to fetch changes up to 901ce27c6f018992b7dd6c08d3c98cf217cc4c96: siemens-am33x-common.h: Always build CONFIG_OMAP_GPIO support (2013-08-28 12:01:30 -0400) Albert ARIBAUD (1): arm: omap3: fix SRAM copy and execution sequence Heiko Schocher (6): arm, am33xx: add defines for gmii_sel_register bits arm, am335x: add some missing registers and defines for lcd and epwm support arm, spl: add watchdog library to SPL arm, am335x: add watchdog support video: add formike lcd panel init arm, am335x: add support for 3 siemens boards Javier Martinez Canillas (1): ARM: igep00x0.h: Enable raw initrd support Lubomir Popov (1): ARM: OMAP4470: Add Elpida EDB8164B3PF memory configuration Oleksandr Tyshchenko (1): sdp4430: Initialize board id using CONFIG_MACH_TYPE Taras Kondratiuk (3): ARM: OMAP4470: Add OMAP4470 identification ARM: OMAP4470: Add voltage and dpll data ARM: OMAP4460: sdp: Limit TPS mux config to 4460 Tom Rini (13): am33xx: Correct and expand comments on CONFIG_SPL_MAX_SIZE TI:armv7: Move CONFIG_SPL_LIBDISK_SUPPORT to MMC section omap5: Expand CONFIG_SPL_MAX_SIZE and comment upon SRAM_SCRATCH_SPACE_ADDR TI:am335x: Better comment and organize the networking related options am335x_evm: Add comment by SPL SPI support am335x_evm: Regroup USB options TI:armv7: Re-order slightly the generic CONFIG options, expand related comments am335x_evm: Update README for customization TI:am33xx: Move SPL YMODEM support to the per-board config TI:omap5: Clarify comments about SPL and DDR timings in common config omap5_uevm: Better comment why we have TCA642X and the reset time dra7xx_evm: Re-order and comment the networking related config options siemens-am33x-common.h: Always build CONFIG_OMAP_GPIO support MAINTAINERS|5 + arch/arm/cpu/armv7/omap3/clock.c |6 +- arch/arm/cpu/armv7/omap3/lowlevel_init.S |8 +- arch/arm/cpu/armv7/omap4/hw_data.c | 36 ++ arch/arm/cpu/armv7/omap4/hwinit.c |3 + arch/arm/cpu/armv7/omap4/sdram_elpida.c| 41 +- arch/arm/include/asm/arch-am33xx/cpu.h | 74 ++- arch/arm/include/asm/arch-am33xx/hardware_am33xx.h |7 + arch/arm/include/asm/arch-am33xx/omap.h|2 +- arch/arm/include/asm/arch-omap3/clock.h|2 - arch/arm/include/asm/arch-omap4/clock.h|7 +- arch/arm/include/asm/arch-omap4/omap.h |1 + arch/arm/include/asm/arch-omap5/omap.h | 11 +- arch/arm/include/asm/omap_common.h |1 + board/isee/igep0033/board.c|6 +- board/phytec/pcm051/board.c|2 - board/siemens/common/board.c | 171 +++ board/siemens/common/factoryset.c | 284 +++ board/siemens/common/factoryset.h | 27 ++ board/siemens/dxr2/Makefile| 49 ++ board/siemens/dxr2/board.c | 241 + board/siemens/dxr2/board.h | 69 +++ board/siemens/dxr2/mux.c | 112 + board/siemens/pxm2/Makefile| 49 ++ board/siemens/pxm2/board.c | 429 board/siemens/pxm2/board.h | 22 + board/siemens/pxm2/mux.c | 186 +++ board/siemens/pxm2/pmic.h | 71 +++ board/siemens/rut/Makefile | 49 ++ board/siemens/rut/board.c | 432 + board/siemens/rut/board.h | 22 + board/siemens/rut/mux.c| 347 + board/ti/am335x/README | 28 +- board/ti/am335x/board.c|6 +- board/ti/sdp4430/sdp.c |4 +- boards.cfg |3 + doc/README.SPL |2 +- drivers/video/Makefile |1 + drivers/video/formike.c| 511 drivers/watchdog/Makefile |1 + drivers/watchdog/omap_wdt.c
[U-Boot] [PATCH 5/5] mmc: don't support write erase for SPL builds
For SPL builds this is just dead code since we'll only need to read.
Eliminating it results in a significant size reduction for the SPL
binary.
Signed-off-by: Paul Burton paul.bur...@imgtec.com
---
drivers/mmc/mmc.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 30a985b..d305257 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -248,6 +248,7 @@ err_out:
static unsigned long
mmc_berase(int dev_num, lbaint_t start, lbaint_t blkcnt)
{
+#ifndef CONFIG_SPL_BUILD
int err = 0;
struct mmc *mmc = find_mmc_device(dev_num);
lbaint_t blk = 0, blk_r = 0;
@@ -281,6 +282,9 @@ mmc_berase(int dev_num, lbaint_t start, lbaint_t blkcnt)
}
return blk;
+#else /* CONFIG_SPL_BUILD */
+ return -1;
+#endif
}
static ulong
@@ -349,6 +353,7 @@ mmc_write_blocks(struct mmc *mmc, lbaint_t start, lbaint_t
blkcnt, const void*sr
static ulong
mmc_bwrite(int dev_num, lbaint_t start, lbaint_t blkcnt, const void*src)
{
+#ifndef CONFIG_SPL_BUILD
lbaint_t cur, blocks_todo = blkcnt;
struct mmc *mmc = find_mmc_device(dev_num);
@@ -368,6 +373,9 @@ mmc_bwrite(int dev_num, lbaint_t start, lbaint_t blkcnt,
const void*src)
} while (blocks_todo 0);
return blkcnt;
+#else /* CONFIG_SPL_BUILD */
+ return 0;
+#endif
}
static int mmc_read_blocks(struct mmc *mmc, void *dst, lbaint_t start,
--
1.8.3.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: atmel_nand: support for software BCH ECC
Hi Bo, On 09/04/2013 02:46 PM, Bo Shen wrote: On 9/4/2013 8:30 PM, Andreas Bießmann wrote: Yes, we need libbch. If we really want to enable software BCH support. It also need add following two options in board configuration file. ---8--- #define CONFIG_NAND_ECC_BCH #define CONFIG_BCH ---8--- So, this patch give us option to enable software BCH. got it. So the NAND_ECC_BCH is the adoption for the SW BCH correction in mtd layer. I understand that this would be helpful for at91 SoC without PMECC HW. But there is no user currently, so I hesitate to apply this. Frankly, there is no EK boards from Atmel use software BCH now, however, a lot of customers use NAND with 224 bytes OOB, can not use software ECC, they need use software BCH. I understand this. But it will be a piece of dead code until a user of it would be submitted. So, I think it is better to apply this patch. If it will break the rule of u-boot, then I think we can wait real user in u-boot need this and then apply this patch. I'd like to hear Scott's comment on that. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: atmel: sama5d3: drop unused CONFIG_NET_MULTI
Dear Bo Shen, Bo Shen voice.s...@gmail.com writes: Drop unused CONFIG_NET_MULTI Signed-off-by: Bo Shen voice.s...@gmail.com --- include/configs/sama5d3xek.h |1 - 1 file changed, 1 deletion(-) applied to u-boot-atmel/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] mmc: don't call *printf or puts when SPL !CONFIG_SPL_LIBCOMMON_SUPPORT
If we don't have CONFIG_SPL_LIBCOMMON_SUPPORT defined then stdio
*printf functions are unavailable calling them will cause a link
failure.
Signed-off-by: Paul Burton paul.bur...@imgtec.com
---
drivers/mmc/mmc.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 5502675..30a985b 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -135,8 +135,10 @@ static int mmc_send_status(struct mmc *mmc, int timeout)
MMC_STATE_PRG)
break;
else if (cmd.response[0] MMC_STATUS_MASK) {
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
printf(Status Error: 0x%08X\n,
cmd.response[0]);
+#endif
return COMM_ERR;
}
} else if (--retries 0)
@@ -151,7 +153,9 @@ static int mmc_send_status(struct mmc *mmc, int timeout)
printf(CURR STATE:%d\n, status);
#endif
if (timeout = 0) {
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
printf(Timeout waiting card ready\n);
+#endif
return TIMEOUT;
}
@@ -181,7 +185,9 @@ struct mmc *find_mmc_device(int dev_num)
return m;
}
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
printf(MMC Device %d not found\n, dev_num);
+#endif
return NULL;
}
@@ -233,7 +239,9 @@ static ulong mmc_erase_t(struct mmc *mmc, ulong start,
lbaint_t blkcnt)
return 0;
err_out:
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
puts(mmc erase failed\n);
+#endif
return err;
}
@@ -248,6 +256,7 @@ mmc_berase(int dev_num, lbaint_t start, lbaint_t blkcnt)
if (!mmc)
return -1;
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
if ((start % mmc-erase_grp_size) || (blkcnt % mmc-erase_grp_size))
printf(\n\nCaution! Your devices Erase group is 0x%x\n
The erase range would be change to
@@ -255,6 +264,7 @@ mmc_berase(int dev_num, lbaint_t start, lbaint_t blkcnt)
mmc-erase_grp_size, start ~(mmc-erase_grp_size - 1),
((start + blkcnt + mmc-erase_grp_size)
~(mmc-erase_grp_size - 1)) - 1);
+#endif
while (blk blkcnt) {
blk_r = ((blkcnt - blk) mmc-erase_grp_size) ?
@@ -281,8 +291,10 @@ mmc_write_blocks(struct mmc *mmc, lbaint_t start, lbaint_t
blkcnt, const void*sr
int timeout = 1000;
if ((start + blkcnt) mmc-block_dev.lba) {
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
printf(MMC: block number 0x LBAF exceeds max(0x LBAF )\n,
start + blkcnt, mmc-block_dev.lba);
+#endif
return 0;
}
@@ -306,7 +318,9 @@ mmc_write_blocks(struct mmc *mmc, lbaint_t start, lbaint_t
blkcnt, const void*sr
data.flags = MMC_DATA_WRITE;
if (mmc_send_cmd(mmc, cmd, data)) {
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
printf(mmc write failed\n);
+#endif
return 0;
}
@@ -318,7 +332,9 @@ mmc_write_blocks(struct mmc *mmc, lbaint_t start, lbaint_t
blkcnt, const void*sr
cmd.cmdarg = 0;
cmd.resp_type = MMC_RSP_R1b;
if (mmc_send_cmd(mmc, cmd, NULL)) {
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
printf(mmc fail to send stop cmd\n);
+#endif
return 0;
}
}
@@ -385,7 +401,9 @@ static int mmc_read_blocks(struct mmc *mmc, void *dst,
lbaint_t start,
cmd.cmdarg = 0;
cmd.resp_type = MMC_RSP_R1b;
if (mmc_send_cmd(mmc, cmd, NULL)) {
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
printf(mmc fail to send stop cmd\n);
+#endif
return 0;
}
}
@@ -405,8 +423,10 @@ static ulong mmc_bread(int dev_num, lbaint_t start,
lbaint_t blkcnt, void *dst)
return 0;
if ((start + blkcnt) mmc-block_dev.lba) {
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
printf(MMC: block number 0x LBAF exceeds max(0x LBAF )\n,
start + blkcnt, mmc-block_dev.lba);
+#endif
return 0;
}
@@ -1268,6 +1288,7 @@ static int mmc_startup(struct mmc *mmc)
mmc-block_dev.blksz = mmc-read_bl_len;
mmc-block_dev.log2blksz = LOG2(mmc-block_dev.blksz);
mmc-block_dev.lba = lldiv(mmc-capacity, mmc-read_bl_len);
+#if !defined(CONFIG_SPL_BUILD) || defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
Re: [U-Boot] [PATCH 0/5] SPL/MMC size fixes
Bah, the subject should have read size optimisations and fixes but you get the idea... Thanks, Paul On 04/09/13 16:12, Paul Burton wrote: This series reduces the size of the SPL when compiled with MMC support, and fixes build issues if the target does not include libcommon in SPL, or if the target is not ARM based. Both of these are true of my board which is currently out of tree, but which I hope to be able to upstream soon. In the meantime I figured the size optimisations may be of use to others. Paul Burton (5): spl: remove unnecessary ( ARM specific) include of asm/utils.h spl_mmc: only call printf or puts with CONFIG_SPL_LIBCOMMON_SUPPORT mmc: don't call *printf or puts when SPL !CONFIG_SPL_LIBCOMMON_SUPPORT mmc: size optimization when !CONFIG_MMC_SPI mmc: don't support write erase for SPL builds common/spl/spl_mmc.c | 17 - drivers/mmc/mmc.c| 44 include/mmc.h| 4 3 files changed, 64 insertions(+), 1 deletion(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] USB: xHCI: Add header for readl/writel functions
Marek On 09/04/2013 09:17 AM, Marek Vasut wrote: Dear Dan Murphy, Add the asm/io.h header to resolve implicit declaration of readl/writel Signed-off-by: Dan Murphy dmur...@ti.com --- drivers/usb/host/xhci.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h index 467afe0..91935f0 100644 --- a/drivers/usb/host/xhci.h +++ b/drivers/usb/host/xhci.h @@ -27,6 +27,8 @@ #ifndef HOST_XHCI_H_ #define HOST_XHCI_H_ +#include asm/io.h + #include asm/cache.h #include linux/list.h I think this can be merged into Vivek's next round? Best regards, Marek Vasut I hope so this was one of my comments as the asm/io.h showed up in the xhci top level so not sure why it was not included in the global header. So if v3 has this in xhci.h I am OK with gettin rid of this patch Dan -- -- Dan Murphy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot 2009.11.1 USB Issue and Building U-Boot 2013.07
Dear Chuck, please always keep the mailing list on Cc: And please don't top post / full quote. Thanks. In message 005001cea968$9eaa58e0$dbff0aa0$@amanomcgann.com you wrote: Thank you for the reply! Yes the same loadaddr is used for both tftp and fatload as follows: loadaddr=0x2100 OK. I'm not sure what you mean by a complete console log so a little direction would be helpful so I can provide what you are asking for. I Please copy all input and all output of your system into a file and include this with your posting. For example, you coul use the script command, or your terminal emulator may have a logging feature, or you could simply use copy paste. can tell you when I run the commands manually I get the same result each time. I have attached a txt file that shows what happens when I run the command. At the bottom of the file I included the environment variables. If you look at the variable usbgetrootfs this is the command being run. I cannot see any such attachment. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When the bosses talk about improving productivity, they are never talking about themselves. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote: Dear Huang Shijie, How come hector was then able to write his JFFS2 partition ? If he uses the gpmi, he should not write the JFFS2, since the gpmi does not support the jffs2. He will get the failure in the end. So the jffs2 support is compatiable all the time. Is the old Freescale 2.6.35 GPMI NAND format compatible with the one after applying this patchset? Not compatible. This patch set is still underreview. that I could mount with Linux 3.7 and earlier? I think the mount can be succeeded. Ok, does that mean that we need this patchset in U-Boot in order to properly write JFFS2 onto GPMI NAND there? Is that the message you wanted to relay to us? Besides this patchset, the u-boot needs more patches to sync with the kernel mtd code. Such as the full-id features. thanks Huang Shijie ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] mmc: size optimization when !CONFIG_MMC_SPI
When CONFIG_MMC_SPI is not enabled, the MMC_MODE_SPI capability can never be set. However there is code in mmc.c which uses the mmc_host_is_spi macro to check that capability act accordingly. If we expand that macro to 0 when CONFIG_MMC_SPI is not set (since it will always be 0 at runtime anyway) then the compiler can optimize away the SPI-specific code paths in mmc.c. Signed-off-by: Paul Burton paul.bur...@imgtec.com --- include/mmc.h | 4 1 file changed, 4 insertions(+) diff --git a/include/mmc.h b/include/mmc.h index 228d771..214b9ed 100644 --- a/include/mmc.h +++ b/include/mmc.h @@ -335,7 +335,11 @@ int mmc_start_init(struct mmc *mmc); void mmc_set_preinit(struct mmc *mmc, int preinit); #ifdef CONFIG_GENERIC_MMC +#ifdef CONFIG_MMC_SPI #define mmc_host_is_spi(mmc) ((mmc)-host_caps MMC_MODE_SPI) +#else +#define mmc_host_is_spi(mmc) 0 +#endif struct mmc *mmc_spi_init(uint bus, uint cs, uint speed, uint mode); #else int mmc_legacy_init(int verbose); -- 1.8.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/5] SPL/MMC size fixes
This series reduces the size of the SPL when compiled with MMC support, and fixes build issues if the target does not include libcommon in SPL, or if the target is not ARM based. Both of these are true of my board which is currently out of tree, but which I hope to be able to upstream soon. In the meantime I figured the size optimisations may be of use to others. Paul Burton (5): spl: remove unnecessary ( ARM specific) include of asm/utils.h spl_mmc: only call printf or puts with CONFIG_SPL_LIBCOMMON_SUPPORT mmc: don't call *printf or puts when SPL !CONFIG_SPL_LIBCOMMON_SUPPORT mmc: size optimization when !CONFIG_MMC_SPI mmc: don't support write erase for SPL builds common/spl/spl_mmc.c | 17 - drivers/mmc/mmc.c| 44 include/mmc.h| 4 3 files changed, 64 insertions(+), 1 deletion(-) -- 1.8.3.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ums: Add dev num parameter. Check mmc device before do ums init.
On 09/04/2013 02:34 PM, Marek Vasut wrote:
Dear Przemyslaw Marczak,
Hello Marek,
Thank you for reply.
On 09/04/2013 12:26 AM, Marek Vasut wrote:
Dear Przemyslaw Marczak,
This change allows using every mmc device instance with ums, like eMMC
or SD cards. Now MMC device is checked before ums is inited.
Example of use: ums device_number for mmc devices.
Signed-off-by: Przemyslaw Marczak p.marc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Marek Vasut marek.va...@gmail.com
---
board/samsung/trats/trats.c | 12 +++-
common/cmd_usb_mass_storage.c | 30 ++
include/usb_mass_storage.h|4 ++--
3 files changed, 19 insertions(+), 27 deletions(-)
diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
index 7f61d17..b7f7b05 100644
--- a/board/samsung/trats/trats.c
+++ b/board/samsung/trats/trats.c
@@ -816,17 +816,11 @@ static struct ums_board_info ums_board = {
},
};
-struct ums_board_info *board_ums_init(unsigned int dev_num, unsigned
int offset, - unsigned int part_size)
+struct ums_board_info *board_ums_init(struct mmc *mmc, unsigned int
offset, + unsigned int part_size)
{
- struct mmc *mmc;
-
- mmc = find_mmc_device(dev_num);
- if (!mmc)
- return NULL;
-
ums_board.ums_dev.mmc = mmc;
- ums_board.ums_dev.dev_num = dev_num;
+ ums_board.ums_dev.dev_num = mmc-block_dev.dev;
You already pass mmc, why pass mmc-block_dev.dev too? Is it not a
little redundant?
You are right, it is little redundant but pointer to this structure is
returned so we expect that structure fields were proper filled, right?
Why not just remove the dev_num field ? The UMS core can retrieve that
information itself.
[...]
Best regards,
Marek Vasut
Hello,
I'm making little UMS code refactor now. I will consider your suggestion.
Regards,
--
Przemyslaw Marczak
Samsung RD Institute Poland
Samsung Electronics
p.marc...@samsung.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Marek,
On 09/04/2013 04:38 PM, Marek Vasut wrote:
Dear Huang Shijie,
On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote:
Dear Huang Shijie,
How come hector was then able to write his JFFS2 partition ?
If he uses the gpmi, he should not write the JFFS2, since the gpmi
does not support the jffs2. He will get the failure in the end.
Hector, can you comment on this?
I don't think I'm following these comments. The facts are:
1) A JFFS2 filesystem image written with nandwrite (mtd-utils v1.5.0)
a) does not mount on kernel v3.10
b) mounts OK on linux-next kernel (v3.12) with the patchset [1] from
Huang
(actually I didn't use linux-next but instead a v3.10 where I merged all the commits
done to MTD in linux-next, which are a lot).
2) A JFFS2 filesystem image written with U-Boot v2013.01
a) mounts OK on old FSL kernel 2.6.35
b) does not mount on kernel v3.10 (neither on v3.8, I believe).
c) does not mount on linux-next with the patchset [1]
[1] http://lists.infradead.org/pipermail/linux-mtd/2013-August/048360.html
Marek, could you please confirm 2b on your side, just in case I'm doing anything wrong
in my custom U-Boot?
So the jffs2 support is compatiable all the time.
Is the old Freescale 2.6.35 GPMI NAND format compatible with the one
after applying this patchset?
Not compatible.
This patch set is still underreview.
So this patch breaks compatiblity with FSL kernel release? This needs fixing,
otherwise it's impossible to do a drop-in replacement for the ancient FSL
kernel.
that I could mount with Linux 3.7 and earlier?
I think the mount can be succeeded.
Ok, does that mean that we need this patchset in U-Boot in order to
properly write JFFS2 onto GPMI NAND there? Is that the message you
wanted to relay to us?
Besides this patchset, the u-boot needs more patches to sync with the
kernel mtd code. Such as the full-id features.
Can you elaborate on this more? This is very vague, I would like to know what
exactly is missing.
Yes, please, we need more details. This seems to be related with how the MTD drivers
(in Linux and in U-Boot) access the OOB area to store the JFFS2 cleanmarkers, right?
The error I'm receiving from the kernel is at fs/jffs2/wbuf.c
if (!oinfo || oinfo-oobavail == 0) {
pr_err(inconsistent device description\n);
return -EINVAL;
}
Best regards,
--
Hector Palacios
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot 2009.11.1 USB Issue and Building U-Boot 2013.07
Wolfgang, please always keep the mailing list on Cc: My apologies but in my line of work I have to be careful about reply all so there are times I hit reply automatically. And please don't top post / full quote. Thanks. Again, my apologies since I keep all emails in thread form here at work for reference. I will do my best to not top post on these forms. I cannot see any such attachment. I failed to attached the file. It is now attached. It is just a copy paste but yes, GtkTerm does have a method to save the screen. It's probably easier to just copy and paste. And before anything is said about what is used for a console it simply works the best for my application. Chuck Wical Embedded Software Engineer Amano McGann, Inc. 651 Taft Street, NE Minneapolis, MN 55413 Tel: 612-331-2020 Fax: 612-331-5187 chuck.wi...@amanomcgann.com loadaddr=0x2100 U-Boot usb start (Re)start USB... USB: scanning bus for devices... 2 USB Device(s) found scanning bus for storage devices... 1 Storage Device(s) found U-Boot usb info 1: Hub, USB Revision 1.10 - OHCI Root Hub - Class: Hub - PacketSize: 8 Configurations: 1 - Vendor: 0x Product 0x Version 0.0 Configuration: 1 - Interfaces: 1 Self Powered 0mA Interface: 0 - Alternate Setting 0, Endpoints: 1 - Class Hub - Endpoint 1 In Interrupt MaxPacket 2 Interval 255ms 2: Mass Storage, USB Revision 2.0 - USB Flash Disk 9D785E10 - Class: (from Interface) Mass Storage - PacketSize: 64 Configurations: 1 - Vendor: 0x058f Product 0x6387 Version 1.2 Configuration: 1 - Interfaces: 1 Bus Powered 100mA Interface: 0 - Alternate Setting 0, Endpoints: 2 - Class Mass Storage, Transp. SCSI, Bulk only - Endpoint 1 Out Bulk MaxPacket 64 - Endpoint 2 In Bulk MaxPacket 64 U-Boot usb storage Device 0: Vendor: USB Rev: 8.07 Prod: Flash Disk Type: Removable Hard Disk Capacity: 241.0 MB = 0.2 GB (493568 x 512) U-Boot fatload usb 0 $(loadaddr) rootfs.ext2.gz.uboot reading rootfs.ext2.gz.uboot ..RomBOOT U-Boot 2009.11.1 (Aug 27 2013 - 13:43:57) DRAM: 64 MB NAND: 256 MiB In:serial Out: serial Err: serial Net: macb0 macb0: Starting autonegotiation... macb0: Autonegotiation complete macb0: link up, 100Mbps full-duplex (lpa: 0x45e1) Hit any key to stop autoboot: 0 U-Boot Environment Variables autoload=no\0 \ console=quiet\0 \ dbgconsole=console=ttyS0,115200\0 \ ethaddr=00:01:02:03:04:05\0 \ loadaddr=0x2100\0 \ ramdiskaddr=0x2140\0 \ ubootaddr=0x2\0 \ ubootsize=0xE\0 \ kerneladdr=0x10\0 \ kernelsize=0x40\0 \ etcaddr=0x50\0 \ etcsize=0x10\0 \ rootfsaddr=0x60\0 \ rootfssize=0x100\0 \ nandload=nand read.jffs2 $(loadaddr) $(kerneladdr) $(kernelsize); nand read.jffs2 $(ramdiskaddr) $(rootfsaddr) $(rootfssize)\0 \ flashuboot=tftp $(loadaddr) u-boot.bin; nand erase $(ubootaddr) $(ubootsize); nand write.jffs2 $(loadaddr) $(ubootaddr) $(ubootsize)\0 \ flashkernel=tftp $(loadaddr) uImage; nand erase $(kerneladdr) $(kernelsize); nand write.jffs2 $(loadaddr) $(kerneladdr) $(kernelsize)\0 \ flashetc=tftp $(loadaddr) etc.jffs2; nand erase $(etcaddr) $(etcsize); nand write.jffs2 $(loadaddr) $(etcaddr) $(etcsize)\0 \ flashrootfs=tftp $(loadaddr) rootfs.ext2.gz.uboot; nand erase $(rootfsaddr) $(rootfssize); nand write.jffs2 $(loadaddr) $(rootfsaddr) $(rootfssize)\0 \ flashall=run flashkernel; run flashetc; run flashrootfs\0 \ usbgetkernel=fatload usb 0 $(loadaddr) uImage\0 \ usbkernel= nand erase $(kerneladdr) $(kernelsize); nand write.jffs2 $(loadaddr) $(kerneladdr) $(kernelsize)\0 \ usbgetetc=fatload usb 0 $(loadaddr) etc.jffs2\0 \ usbetc=nand erase $(etcaddr) $(etcsize); nand write.jffs2 $(loadaddr) $(etcaddr) $(etcsize)\0 \ usbgetrootfs=fatload usb 0 $(loadaddr) rootfs.ext2.gz.uboot\0 \ usbrootfs=nand erase $(rootfsaddr) $(rootfssize); nand write.jffs2 $(loadaddr) $(rootfsaddr) $(rootfssize)\0 \ usbflash=run usbgetkernel usbkernel usbgetetc usbetc usbgetrootfs usbrootfs\0 \ memboot=bootm $(loadaddr) $(ramdiskaddr)\0___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/p1010rdb-pb: add support for p1010rdb-pb board
On Thu, 2013-08-29 at 06:10 -0500, Liu Shengzhou-B36685 wrote:
-Original Message-
From: Wood Scott-B07421
Sent: Wednesday, August 14, 2013 8:35 AM
To: Liu Shengzhou-B36685
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] powerpc/p1010rdb-pb: add support for
p1010rdb-pb
board
struct law_entry law_table[] = {
-#ifndef CONFIG_SDCARD
SET_LAW(CONFIG_SYS_FLASH_BASE_PHYS, LAW_SIZE_32M, LAW_TRGT_IF_IFC),
SET_LAW(CONFIG_SYS_CPLD_BASE_PHYS, LAW_SIZE_128K, LAW_TRGT_IF_IFC),
SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_IFC),
-#endif };
If this is applicable to the current board as well (is that P1010RDB-PA?),
then
it isn't related to adding PB support and thus belongs in a separate patch.
As P1010RDB-PA will no longer be supported officially,
Why? Don't confuse Freescale supporting the board with U-Boot
supporting the board.
but we still keep previous code for P1010RDB-PA.
will add some description for P1010RDB-PA in commit message.
I don't see how this answers my question.
+uint pin_mux;
This is too generic for a global variable. Does it even need to be global?
Will rename to static uint sd_ifc_mux, need to be global for invoking in
several different functions.
If it's static, it's not global.
+#if defined(CONFIG_P1010RDB) defined(DEBUG)
void cpld_show(void)
{
struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE);
- printf(CPLD: V%x.%x PCBA: V%x.0\n,
- in_8(cpld_data-cpld_ver) 0xF0,
- in_8(cpld_data-cpld_ver) 0x0F,
- in_8(cpld_data-pcba_ver) 0x0F);
Why are you removing this? Where is cpld_show() called?
previous code for debug, actually no longer needed, will remove cpld_show().
Make such cleanup a separate patch.
@@ -246,6 +446,16 @@ void fdt_del_sdhc(void *blob)
}
}
+void fdt_del_ifc(void *blob)
+{
+ int nodeoff = 0;
+
+ while ((nodeoff = fdt_node_offset_by_compatible(blob, 0,
+ fsl,ifc)) = 0) {
+ fdt_del_node(blob, nodeoff);
+ }
+}
Is this PB-specific? If no, why is it in this patch? If not, why isn't the
caller guarded by the PB ifdef?
for both PA and PB, this patch also tune for PA(though PA no longer be
supported officially).
Why is it in this patch?
+
+U_BOOT_CMD(
+ mux, 2, 0, pin_mux_cmd,
+ configure multiplexing pin for IFC/SDHC bus in runtime,
+ bus_type (e.g. mux sdhc)
+);
Are you sure this is a good idea? What happens to the drivers using said
hardware at the time? Granted they should be idle when not running a
command
that actively uses them, but still... Usually we use hwconfig for this
sort of thing.
The patch supports two ways simultaneously:
1) mux command: for temporary use case in runtime for accessing IFC and SDHC
without reboot,
this way is very useful in practice and in some test cases.
2) hwconfig: for long-term use case.
This should be a separate patch from basic board support.
-#define CONFIG_SYS_DDR_MODE_2_8000x8000c000
+#define CONFIG_SYS_DDR_MODE_1_8000x00441420
+#define CONFIG_SYS_DDR_MODE_2_8000x
#define CONFIG_SYS_DDR_INTERVAL_800 0x0C300100
-#define CONFIG_SYS_DDR_WRLVL_CONTROL_800 0x8655A608
+#define CONFIG_SYS_DDR_WRLVL_CONTROL_800 0x8675f608
Shouldn't this be ifdeffed by the board revision?
No, this is for both PA and PB. old parameters were not the optimal,
will add some description for P1010RDB-PA in commit message.
Separate patch.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: tegra: support SKU b1 of Tegra30
On 09/04/2013 07:00 AM, Alban Bedel wrote:
Add the Tegra30 SKU b1 and treat it like other Tegra30 chips.
CC'ing the Tegra maintainer would be helpful (Tom Warren; I CC'd him here)
diff --git a/arch/arm/cpu/tegra-common/ap.c b/arch/arm/cpu/tegra-common/ap.c
@@ -71,6 +71,7 @@ int tegra_get_chip_sku(void)
switch (sku_id) {
case SKU_ID_T33:
case SKU_ID_T30:
+ case SKU_ID_T30MQS:
Where does the name T30MQS come from? Tom, can you verify what we call
the SKUs internally?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND write error with HW ECC on OMAP3
On Wed, Sep 4, 2013 at 1:54 AM, Andreas Bießmann
andreas.de...@googlemail.com wrote:
I can't confirm your complaints. Here it works (at least on tricorder,
which utilizes BCH for U-Boot section in SPL):
Hi Andreas,
Thanks for your response---this was very helpful. When I boot my
board using the tricorder board file, it flashes nand correctly.
Likewise, I moved over some of the NAND configuration from
include/configs/tricorder.h to include/configs/omap3_overo.h and,
after a little rearranging to enlarge SPL, it also flashed NAND
correctly.
So...any guesses what it is about setting these variables that gets
NAND flashing to work properly?
+#define CONFIG_NAND_OMAP_BCH8
+#define CONFIG_BCH
-#define CONFIG_SYS_NAND_ECCPOS {2, 3, 4, 5, 6, 7, 8, 9,\
- 10, 11, 12, 13}
+#define CONFIG_SYS_NAND_ECCPOS {12, 13, 14, 15, 16, 17, 18, 19, 20, \
+21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,\
+34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46,\
+47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59,\
+60, 61, 62, 63}
-#define CONFIG_SYS_NAND_ECCBYTES 3
+#define CONFIG_SYS_NAND_ECCBYTES 13
--Ash
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ARM: tegra: Add the Tamonten™ NG Evaluation Carrier board
On 09/04/2013 07:00 AM, Alban Bedel wrote:
Add support for the new Tamonten™ NG platform from Avionic Design.
Currently only I2C, MMC, USB and ethernet have been tested.
(Also CC'ing the Tegra maintainer here)
diff --git a/board/avionic-design/common/tamonten-ng.c
b/board/avionic-design/common/tamonten-ng.c
+void pmu_write(uchar reg, uchar data) +{ + int i; +
i2c_set_bus_num(0); /* PMU is on bus 0 */ + for (i = 0; i
MAX_I2C_RETRY; ++i) { + if (i2c_write(PMU_I2C_ADDRESS, reg, 1,
data, 1)) + udelay(100); + else +
break; +} +}
Is there really a need to retry the I2C transactions? If so, why do
they fail? I assume this was just copy/pasted from some other board
file, and there's no need for any retries?
It'd be nice if there was a proper PMU subsystem, so we could have a
specific driver for each PMU chip, rather than having
open-coded/custom writes to the PMU registers in each board file, but
I guess that's not an issue with this patch specfically.
diff --git a/include/configs/tec-ng.h b/include/configs/tec-ng.h
+/* support the new (FDT-based) image format */ +#define
CONFIG_FIT
Hmmm. Do the standard Tegra boot scripts in tegra-common-post.h deal
well with FIT? I've tried to avoid FIT usage as much as possible.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gpmi-nand driver and jffs2 support
Dear Huang Shijie, On Wed, Sep 04, 2013 at 04:00:36PM +0200, Marek Vasut wrote: Dear Huang Shijie, How come hector was then able to write his JFFS2 partition ? If he uses the gpmi, he should not write the JFFS2, since the gpmi does not support the jffs2. He will get the failure in the end. Hector, can you comment on this? So the jffs2 support is compatiable all the time. Is the old Freescale 2.6.35 GPMI NAND format compatible with the one after applying this patchset? Not compatible. This patch set is still underreview. So this patch breaks compatiblity with FSL kernel release? This needs fixing, otherwise it's impossible to do a drop-in replacement for the ancient FSL kernel. that I could mount with Linux 3.7 and earlier? I think the mount can be succeeded. Ok, does that mean that we need this patchset in U-Boot in order to properly write JFFS2 onto GPMI NAND there? Is that the message you wanted to relay to us? Besides this patchset, the u-boot needs more patches to sync with the kernel mtd code. Such as the full-id features. Can you elaborate on this more? This is very vague, I would like to know what exactly is missing. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6sabresd: Add LVDS splash screen support
mx6sabresd boards can be connected to a Hannstar XGA LVDS panel.
Add support for displaying U-boot splashscreen on it.
By default, HDMI splash is selected.
In order to use splash via LVDS, do the following in the U-boot prompt:
setenv panel Hannstar-XGA
save
and reboot.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx6sabresd/mx6sabresd.c | 166
1 file changed, 145 insertions(+), 21 deletions(-)
diff --git a/board/freescale/mx6sabresd/mx6sabresd.c
b/board/freescale/mx6sabresd/mx6sabresd.c
index 5db516d..f3ccc7b 100644
--- a/board/freescale/mx6sabresd/mx6sabresd.c
+++ b/board/freescale/mx6sabresd/mx6sabresd.c
@@ -234,47 +234,171 @@ int board_phy_config(struct phy_device *phydev)
}
#if defined(CONFIG_VIDEO_IPUV3)
-static struct fb_videomode const hdmi = {
- .name = HDMI,
- .refresh= 60,
- .xres = 1024,
- .yres = 768,
- .pixclock = 15385,
- .left_margin= 220,
- .right_margin = 40,
- .upper_margin = 21,
- .lower_margin = 7,
- .hsync_len = 60,
- .vsync_len = 10,
- .sync = FB_SYNC_EXT,
- .vmode = FB_VMODE_NONINTERLACED
+struct display_info_t {
+ int bus;
+ int addr;
+ int pixfmt;
+ int (*detect)(struct display_info_t const *dev);
+ void(*enable)(struct display_info_t const *dev);
+ struct fb_videomode mode;
};
-int board_video_skip(void)
+static int detect_hdmi(struct display_info_t const *dev)
{
- int ret;
+ struct hdmi_regs *hdmi = (struct hdmi_regs *)HDMI_ARB_BASE_ADDR;
+ return readb(hdmi-phy_stat0) HDMI_DVI_STAT;
+}
- ret = ipuv3_fb_init(hdmi, 0, IPU_PIX_FMT_RGB24);
+static void do_enable_hdmi(struct display_info_t const *dev)
+{
+ imx_enable_hdmi_phy();
+}
- if (ret)
- printf(HDMI cannot be configured: %d\n, ret);
+static void enable_lvds(struct display_info_t const *dev)
+{
+ struct iomuxc *iomux = (struct iomuxc *)
+ IOMUXC_BASE_ADDR;
+ u32 reg = readl(iomux-gpr[2]);
+ reg |= IOMUXC_GPR2_DATA_WIDTH_CH0_24BIT |
+ IOMUXC_GPR2_DATA_WIDTH_CH1_24BIT;
+ writel(reg, iomux-gpr[2]);
+}
+static struct display_info_t const displays[] = {{
+ .bus= -1,
+ .addr = 0,
+ .pixfmt = IPU_PIX_FMT_RGB24,
+ .detect = detect_hdmi,
+ .enable = do_enable_hdmi,
+ .mode = {
+ .name = HDMI,
+ .refresh= 60,
+ .xres = 1024,
+ .yres = 768,
+ .pixclock = 15385,
+ .left_margin= 220,
+ .right_margin = 40,
+ .upper_margin = 21,
+ .lower_margin = 7,
+ .hsync_len = 60,
+ .vsync_len = 10,
+ .sync = FB_SYNC_EXT,
+ .vmode = FB_VMODE_NONINTERLACED
+} }, {
+ .bus= -1,
+ .addr = 0,
+ .pixfmt = IPU_PIX_FMT_LVDS666,
+ .detect = NULL,
+ .enable = enable_lvds,
+ .mode = {
+ .name = Hannstar-XGA,
+ .refresh= 60,
+ .xres = 1024,
+ .yres = 768,
+ .pixclock = 15385,
+ .left_margin= 220,
+ .right_margin = 40,
+ .upper_margin = 21,
+ .lower_margin = 7,
+ .hsync_len = 60,
+ .vsync_len = 10,
+ .sync = FB_SYNC_EXT,
+ .vmode = FB_VMODE_NONINTERLACED
+} } };
- imx_enable_hdmi_phy();
- return ret;
+int board_video_skip(void)
+{
+ int i;
+ int ret;
+ char const *panel = getenv(panel);
+ if (!panel) {
+ for (i = 0; i ARRAY_SIZE(displays); i++) {
+ struct display_info_t const *dev = displays+i;
+ if (dev-detect(dev)) {
+ panel = dev-mode.name;
+ printf(auto-detected panel %s\n, panel);
+ break;
+ }
+ }
+ if (!panel) {
+ panel = displays[0].mode.name;
+ printf(No panel detected: default to %s\n, panel);
+ }
+ } else {
+ for (i = 0; i ARRAY_SIZE(displays); i++) {
+ if (!strcmp(panel, displays[i].mode.name))
+ break;
+ }
+ }
+ if (i ARRAY_SIZE(displays)) {
+ ret = ipuv3_fb_init(displays[i].mode, 0,
+ displays[i].pixfmt);
+ if (!ret) {
+ displays[i].enable(displays+i);
+
Re: [U-Boot] [PATCH] net, phy, cpsw: fix unaligned access if no phy found
On Wed, Sep 4, 2013 at 7:16 AM, Heiko Schocher h...@denx.de wrote: if phy_connect() did not find a phy, phydev is not initialized and following code in cpsw_phy_init() maybe crashes. Fix this. Signed-off-by: Heiko Schocher h...@denx.de Cc: Joe Hershberger joe.hershber...@gmail.com Cc: Mugunthan V N mugunthan...@ti.com Cc: Tom Rini tr...@ti.com Acked-by: Joe Hershberger joe.hershber...@ni.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Compiling certain files with extra compiler flags
Does u-boot provide the ability to change compilation options 'on the fly', say when certain files need to be compiled for symbolic debugging? I looked but did not find any. How about something like this: vvv $ git diff config.mk diff --git a/config.mk b/config.mk index 853e6d8..41cafbb 100644 --- a/config.mk +++ b/config.mk @@ -406,7 +406,7 @@ $(obj)%.o: %.c ifneq ($(CHECKSRC),0) $(CHECK) $(CHECKFLAGS) $(ALL_CFLAGS) $ endif - $(CC) $(ALL_CFLAGS) -o $@ $ -c + $(CC) $(ALL_CFLAGS) $(CPP_$(subst .,_,$)) -o $@ $ -c $(obj)%.i: %.c $(CPP) $(ALL_CFLAGS) -o $@ $ -c $(obj)%.s: %.c ^ Then, say I want to have spl_boot.c compiled with extra flags, just invoking make like this does the trick: CPP_spl_boot_c='-O0 -fno-default-inline' make ... Or is there a better way? --vb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] MTD: atmel_nand: support for software BCH ECC
On Wed, 2013-09-04 at 17:15 +0200, Andreas Bießmann wrote: Hi Bo, On 09/04/2013 02:46 PM, Bo Shen wrote: On 9/4/2013 8:30 PM, Andreas Bießmann wrote: Yes, we need libbch. If we really want to enable software BCH support. It also need add following two options in board configuration file. ---8--- #define CONFIG_NAND_ECC_BCH #define CONFIG_BCH ---8--- So, this patch give us option to enable software BCH. got it. So the NAND_ECC_BCH is the adoption for the SW BCH correction in mtd layer. I understand that this would be helpful for at91 SoC without PMECC HW. But there is no user currently, so I hesitate to apply this. Frankly, there is no EK boards from Atmel use software BCH now, however, a lot of customers use NAND with 224 bytes OOB, can not use software ECC, they need use software BCH. I understand this. But it will be a piece of dead code until a user of it would be submitted. So, I think it is better to apply this patch. If it will break the rule of u-boot, then I think we can wait real user in u-boot need this and then apply this patch. I'd like to hear Scott's comment on that. Is this for the benefit of out-of-tree boards, or for boards which will be submitted but haven't yet? In the latter case, it could be submitted at the same time. In the former case, of course we encourage the boards to be submitted, and we don't generally add code solely for the benefit of out-of-tree boards. In any case, this is minor enough that I don't care all that much. If we ever get kconfig, then hopefully the dead code rules will relax to code which could be enabled through some legal config, rather than code which is enabled in some default config for a board. Things like allyesconfig and randconfig could help with build test coverage. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: gadget: Fix data aborts during USB ethernet boot
On 08/27/2013 08:52 AM, Marek Vasut wrote:
Dear Joel Fernandes,
As seen on GCC 4.6 Linaro compiler, control_req buffer is not aligned
on 4 byte boundaray causing data aborts in eth_setup - conf_buf
during dhcp boot over usb_ether. Fix the issue my aligning control_req
buffer to 4-byte boundary.
Tested on am335x_evm platform (beaglebone).
Applies on 2013.10-rc1 branch.
Cc: Tom Rini tr...@ti.com
Signed-off-by: Joel Fernandes jo...@ti.com
Please keep me in the CC next time.
Ok.
---
drivers/usb/gadget/ether.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 579893c..251d7b2 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -849,7 +849,7 @@ static struct usb_gadget_strings stringtab = {
};
/*
*/ -static u8 control_req[USB_BUFSIZ];
+static u8 control_req[USB_BUFSIZ] __attribute__ ((aligned(4)));
Please make this cacheline aligned, so we get rid of bounce buffering of the
requests on stupid hardware.
#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS)
static u8 status_req[STATUS_BYTECOUNT] __attribute__ ((aligned(4)));
This could also use fixing, but the STATUS_BYTECOUNT would need to be
up-aligned
as well then. Some DEFINE_CACHE_ALIGN_BUFFER might help in both cases here.
Ok, how about __aligned(CONFIG_SYS_CACHELINE_SIZE) instead of defining
a new DEFINE_CACHE_ALIGN_BUFFER macro?
Can you explain what you meant by STATUS_BYTECOUNT up-aligned and why its needed
to be up-aligned?
Regards,
-Joel
#endif
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: gadget: Fix data aborts during USB ethernet boot
Dear Joel Fernandes,
On 08/27/2013 08:52 AM, Marek Vasut wrote:
Dear Joel Fernandes,
As seen on GCC 4.6 Linaro compiler, control_req buffer is not aligned
on 4 byte boundaray causing data aborts in eth_setup - conf_buf
during dhcp boot over usb_ether. Fix the issue my aligning control_req
buffer to 4-byte boundary.
Tested on am335x_evm platform (beaglebone).
Applies on 2013.10-rc1 branch.
Cc: Tom Rini tr...@ti.com
Signed-off-by: Joel Fernandes jo...@ti.com
Please keep me in the CC next time.
Ok.
---
drivers/usb/gadget/ether.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 579893c..251d7b2 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -849,7 +849,7 @@ static struct usb_gadget_strings stringtab = {
};
/*=
===
*/ -static u8 control_req[USB_BUFSIZ];
+static u8 control_req[USB_BUFSIZ] __attribute__ ((aligned(4)));
Please make this cacheline aligned, so we get rid of bounce buffering of
the requests on stupid hardware.
#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS)
static u8 status_req[STATUS_BYTECOUNT] __attribute__ ((aligned(4)));
This could also use fixing, but the STATUS_BYTECOUNT would need to be
up-aligned as well then. Some DEFINE_CACHE_ALIGN_BUFFER might help in
both cases here.
Ok, how about __aligned(CONFIG_SYS_CACHELINE_SIZE) instead of defining
a new DEFINE_CACHE_ALIGN_BUFFER macro?
THis is already defined and used throughout the USB code, check
include/common.h
IIRC.
Can you explain what you meant by STATUS_BYTECOUNT up-aligned and why its
needed to be up-aligned?
it's 16 bytes now, no? Up-align it to cacheline size.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: gadget: Fix data aborts during USB ethernet boot
On 09/04/2013 04:38 PM, Marek Vasut wrote:
Dear Joel Fernandes,
On 08/27/2013 08:52 AM, Marek Vasut wrote:
Dear Joel Fernandes,
As seen on GCC 4.6 Linaro compiler, control_req buffer is not aligned
on 4 byte boundaray causing data aborts in eth_setup - conf_buf
during dhcp boot over usb_ether. Fix the issue my aligning control_req
buffer to 4-byte boundary.
Tested on am335x_evm platform (beaglebone).
Applies on 2013.10-rc1 branch.
Cc: Tom Rini tr...@ti.com
Signed-off-by: Joel Fernandes jo...@ti.com
Please keep me in the CC next time.
Ok.
---
drivers/usb/gadget/ether.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 579893c..251d7b2 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -849,7 +849,7 @@ static struct usb_gadget_strings stringtab = {
};
/*=
===
*/ -static u8 control_req[USB_BUFSIZ];
+static u8 control_req[USB_BUFSIZ] __attribute__ ((aligned(4)));
Please make this cacheline aligned, so we get rid of bounce buffering of
the requests on stupid hardware.
#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS)
static u8 status_req[STATUS_BYTECOUNT] __attribute__ ((aligned(4)));
This could also use fixing, but the STATUS_BYTECOUNT would need to be
up-aligned as well then. Some DEFINE_CACHE_ALIGN_BUFFER might help in
both cases here.
Ok, how about __aligned(CONFIG_SYS_CACHELINE_SIZE) instead of defining
a new DEFINE_CACHE_ALIGN_BUFFER macro?
THis is already defined and used throughout the USB code, check
include/common.h
IIRC.
Can you explain what you meant by STATUS_BYTECOUNT up-aligned and why its
needed to be up-aligned?
it's 16 bytes now, no? Up-align it to cacheline size.
Ok, that makes sense. Thanks. Hope below patch is OK, but I have to test it more
once I am near a setup and can send out a proper patch later today.
If its ok can you explain technical reason for need to up-align array size to
cacheline size, and why aligning only buffer location is not enough?
Also I saw the following comment before the macro definition:
* Usage of this macro shall be avoided or used with extreme care!
Regards,
-Joel
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 579893c..700d5fb 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -849,9 +849,10 @@ static struct usb_gadget_strings stringtab = {
};
/**/
-static u8 control_req[USB_BUFSIZ];
+DEFINE_CACHE_ALIGN_BUFFER(u8, control_req, USB_BUFSIZ);
+
#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS)
-static u8 status_req[STATUS_BYTECOUNT] __attribute__ ((aligned(4)));
+DEFINE_CACHE_ALIGN_BUFFER(u8, status_req, STATUS_BYTECOUNT);
#endif
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: gadget: Fix data aborts during USB ethernet boot
Dear Joel Fernandes,
On 09/04/2013 04:38 PM, Marek Vasut wrote:
Dear Joel Fernandes,
On 08/27/2013 08:52 AM, Marek Vasut wrote:
Dear Joel Fernandes,
As seen on GCC 4.6 Linaro compiler, control_req buffer is not aligned
on 4 byte boundaray causing data aborts in eth_setup - conf_buf
during dhcp boot over usb_ether. Fix the issue my aligning control_req
buffer to 4-byte boundary.
Tested on am335x_evm platform (beaglebone).
Applies on 2013.10-rc1 branch.
Cc: Tom Rini tr...@ti.com
Signed-off-by: Joel Fernandes jo...@ti.com
Please keep me in the CC next time.
Ok.
---
drivers/usb/gadget/ether.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 579893c..251d7b2 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -849,7 +849,7 @@ static struct usb_gadget_strings stringtab = {
};
/*===
== ===
*/ -static u8 control_req[USB_BUFSIZ];
+static u8 control_req[USB_BUFSIZ] __attribute__ ((aligned(4)));
Please make this cacheline aligned, so we get rid of bounce buffering
of the requests on stupid hardware.
#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS)
static u8 status_req[STATUS_BYTECOUNT] __attribute__ ((aligned(4)));
This could also use fixing, but the STATUS_BYTECOUNT would need to be
up-aligned as well then. Some DEFINE_CACHE_ALIGN_BUFFER might help in
both cases here.
Ok, how about __aligned(CONFIG_SYS_CACHELINE_SIZE) instead of defining
a new DEFINE_CACHE_ALIGN_BUFFER macro?
THis is already defined and used throughout the USB code, check
include/common.h IIRC.
Can you explain what you meant by STATUS_BYTECOUNT up-aligned and why
its needed to be up-aligned?
it's 16 bytes now, no? Up-align it to cacheline size.
Ok, that makes sense. Thanks. Hope below patch is OK, but I have to test it
more once I am near a setup and can send out a proper patch later today.
If its ok can you explain technical reason for need to up-align array size
to cacheline size, and why aligning only buffer location is not enough?
Also I saw the following comment before the macro definition:
* Usage of this macro shall be avoided or used with extreme care!
Regards,
-Joel
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 579893c..700d5fb 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -849,9 +849,10 @@ static struct usb_gadget_strings stringtab = {
};
/*
*/ -static u8 control_req[USB_BUFSIZ];
+DEFINE_CACHE_ALIGN_BUFFER(u8, control_req, USB_BUFSIZ);
+
#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS)
-static u8 status_req[STATUS_BYTECOUNT] __attribute__ ((aligned(4)));
+DEFINE_CACHE_ALIGN_BUFFER(u8, status_req, STATUS_BYTECOUNT);
#endif
Yeah, I think so. Repost V2 and we should be cool here.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND write error with HW ECC on OMAP3
Hi,
I did a little bit more work with git bisect and found an issue on
commit c788ecfdc3eb577757ffc1bfb8416added07ef33 nand: Move the
sub-page read support enable to a flag.
Making this change on top of v2013.07 allowed me to again write to
NAND correctly.
-#define NAND_HAS_SUBPAGE_READ(chip) ((chip-options NAND_SUBPAGE_READ))
+#define NAND_HAS_SUBPAGE_READ(chip) ((chip-ecc.mode == NAND_ECC_SOFT) \
+(chip-page_shift 9))
Like some other OMAP3 platforms, my platform uses 1-bit hardware ECC
for the first NAND partition and software ECC elsewhere. Does this
ecc.mode switch need to be partition specific?
--Ash
On Wed, Sep 4, 2013 at 11:00 AM, Ash Charles ashchar...@gmail.com wrote:
On Wed, Sep 4, 2013 at 1:54 AM, Andreas Bießmann
andreas.de...@googlemail.com wrote:
I can't confirm your complaints. Here it works (at least on tricorder,
which utilizes BCH for U-Boot section in SPL):
Hi Andreas,
Thanks for your response---this was very helpful. When I boot my
board using the tricorder board file, it flashes nand correctly.
Likewise, I moved over some of the NAND configuration from
include/configs/tricorder.h to include/configs/omap3_overo.h and,
after a little rearranging to enlarge SPL, it also flashed NAND
correctly.
So...any guesses what it is about setting these variables that gets
NAND flashing to work properly?
+#define CONFIG_NAND_OMAP_BCH8
+#define CONFIG_BCH
-#define CONFIG_SYS_NAND_ECCPOS {2, 3, 4, 5, 6, 7, 8, 9,\
- 10, 11, 12, 13}
+#define CONFIG_SYS_NAND_ECCPOS {12, 13, 14, 15, 16, 17, 18, 19, 20, \
+21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,\
+34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46,\
+47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59,\
+60, 61, 62, 63}
-#define CONFIG_SYS_NAND_ECCBYTES 3
+#define CONFIG_SYS_NAND_ECCBYTES 13
--Ash
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] usb: gadget: Fix data aborts during USB ethernet boot
As seen on GCC 4.6 Linaro compiler, control_req buffer is not aligned
on 4 byte boundaray causing data aborts in eth_setup - conf_buf
during dhcp boot over usb_ether. Fix the issue my aligning control_req
buffer to 4-byte boundary.
Tested on am335x_evm platform (beaglebone).
Applies on 2013.10-rc1 branch.
Cc: Tom Rini tr...@ti.com
Cc: Marek Vasut ma...@denx.de
Signed-off-by: Joel Fernandes jo...@ti.com
---
v2 changes:
- Using DEFINE_CACHE_ALIGN_BUFFER macro for the alignment.
- Also fixed alignment for status_req.
drivers/usb/gadget/ether.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 579893c..700d5fb 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -849,9 +849,10 @@ static struct usb_gadget_strings stringtab = {
};
/**/
-static u8 control_req[USB_BUFSIZ];
+DEFINE_CACHE_ALIGN_BUFFER(u8, control_req, USB_BUFSIZ);
+
#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS)
-static u8 status_req[STATUS_BYTECOUNT] __attribute__ ((aligned(4)));
+DEFINE_CACHE_ALIGN_BUFFER(u8, status_req, STATUS_BYTECOUNT);
#endif
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] usb: gadget: Fix data aborts during USB ethernet boot
As seen on GCC 4.6 Linaro compiler, control_req buffer is not aligned
on 4 byte boundaray causing data aborts in eth_setup - conf_buf
during dhcp boot over usb_ether. Fix the issue my aligning control_req
buffer using DEFINE_CACHE_ALIGN_BUFFER.
Tested on am335x_evm platform (beaglebone).
Applies on 2013.10-rc1 branch.
Cc: Tom Rini tr...@ti.com
Cc: Marek Vasut ma...@denx.de
Signed-off-by: Joel Fernandes jo...@ti.com
---
v2 changes:
- Using DEFINE_CACHE_ALIGN_BUFFER macro for the alignment.
- Also fixed alignment for status_req.
v3 changes:
- Adjusted commit message for v2 change.
drivers/usb/gadget/ether.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 579893c..700d5fb 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -849,9 +849,10 @@ static struct usb_gadget_strings stringtab = {
};
/**/
-static u8 control_req[USB_BUFSIZ];
+DEFINE_CACHE_ALIGN_BUFFER(u8, control_req, USB_BUFSIZ);
+
#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS)
-static u8 status_req[STATUS_BYTECOUNT] __attribute__ ((aligned(4)));
+DEFINE_CACHE_ALIGN_BUFFER(u8, status_req, STATUS_BYTECOUNT);
#endif
--
1.8.1.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] usb: gadget: Fix data aborts during USB ethernet boot
Hi Joel Fernandes,
On 09/05/2013 07:55 AM, Joel Fernandes wrote:
As seen on GCC 4.6 Linaro compiler, control_req buffer is not aligned
on 4 byte boundaray causing data aborts in eth_setup - conf_buf
during dhcp boot over usb_ether. Fix the issue my aligning control_req
buffer using DEFINE_CACHE_ALIGN_BUFFER.
Tested on am335x_evm platform (beaglebone).
Applies on 2013.10-rc1 branch.
Cc: Tom Rini tr...@ti.com
Cc: Marek Vasut ma...@denx.de
Signed-off-by: Joel Fernandes jo...@ti.com
---
v2 changes:
- Using DEFINE_CACHE_ALIGN_BUFFER macro for the alignment.
- Also fixed alignment for status_req.
v3 changes:
- Adjusted commit message for v2 change.
drivers/usb/gadget/ether.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
Test on sama5d3xek board with RNDIS gadget, it still has the unaligned
access issue.
However, I test with this patch usb: gadget: config: fix unaligned
access issues from: Troy Kisky troy.ki...@boundarydevices.com really
fix the unaligned access issue.
more information at: http://patchwork.ozlabs.org/patch/264151/
diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
index 579893c..700d5fb 100644
--- a/drivers/usb/gadget/ether.c
+++ b/drivers/usb/gadget/ether.c
@@ -849,9 +849,10 @@ static struct usb_gadget_strings stringtab = {
};
/**/
-static u8 control_req[USB_BUFSIZ];
+DEFINE_CACHE_ALIGN_BUFFER(u8, control_req, USB_BUFSIZ);
+
#if defined(CONFIG_USB_ETH_CDC) || defined(CONFIG_USB_ETH_RNDIS)
-static u8 status_req[STATUS_BYTECOUNT] __attribute__ ((aligned(4)));
+DEFINE_CACHE_ALIGN_BUFFER(u8, status_req, STATUS_BYTECOUNT);
#endif
Best Regards,
Bo Shen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] powerpc/p1010rdb: update readme for p1010rdb-pb board
- Remove duplicate doc/README.p1010rdb - Update for P1010RDB-PB board P1010RDB-PB is a variation of previous P1010RDB-PA board. Henceforth we support P1010RDB-PB board instead of P1010RDB-PA. Signed-off-by: Shengzhou Liu shengzhou@freescale.com --- v2: removed duplicate doc/README.p1010rdb board/freescale/p1010rdb/README | 285 ++-- doc/README.p1010rdb | 199 2 files changed, 127 insertions(+), 357 deletions(-) delete mode 100644 doc/README.p1010rdb diff --git a/board/freescale/p1010rdb/README b/board/freescale/p1010rdb/README index 7f18aaa..4d6553d 100644 --- a/board/freescale/p1010rdb/README +++ b/board/freescale/p1010rdb/README @@ -1,58 +1,40 @@ Overview = -The P1010RDB is a Freescale reference design board that hosts the P1010 SoC. +The P1010RDB is a Freescale Reference Design Board that hosts the P1010 SoC. +P1010RDB-PB is a variation of previous P1010RDB-PA board. The P1010 is a cost-effective, low-power, highly integrated host processor -based on a Power Architecture e500v2 core (maximum core frequency 800/1000 MHz), -that addresses the requirements of several routing, gateways, storage, consumer, +based on a Power Architecture e500v2 core (maximum core frequency 1GHz),that +addresses the requirements of several routing, gateways, storage, consumer, and industrial applications. Applications of interest include the main CPUs and I/O processors in network attached storage (NAS), the voice over IP (VoIP) router/gateway, and wireless LAN (WLAN) and industrial controllers. -The P1010RDB board features are as follows: +The P1010RDB-PB board features are as following: Memory subsystem: - - 1Gbyte unbuffered DDR3 SDRAM discrete devices (32-bit bus) - - 32 Mbyte NOR flash single-chip memory - - 32 Mbyte NAND flash memory - - 256 Kbit M24256 I2C EEPROM - - 16 Mbyte SPI memory + - 1G bytes unbuffered DDR3 SDRAM discrete devices (32-bit bus) + - 32M bytes NOR flash single-chip memory + - 2G bytes NAND flash memory + - 16M bytes SPI memory + - 256K bit M24256 I2C EEPROM - I2C Board EEPROM 128x8 bit memory - SD/MMC connector to interface with the SD memory card Interfaces: - - PCIe: - - Lane0: x1 mini-PCIe slot - - Lane1: x1 PCIe standard slot - - SATA: - - 1 internal SATA connector to 2.5” 160G SATA2 HDD - - 1 eSATA connector to rear panel - - 10/100/1000 BaseT Ethernet ports: - - eTSEC1, RGMII: one 10/100/1000 port using Vitesse VSC8641XKO - - eTSEC2, SGMII: one 10/100/1000 port using Vitesse VSC8221 - - eTSEC3, SGMII: one 10/100/1000 port using Vitesse VSC8221 - - USB 2.0 port: - - x1 USB2.0 port via an external ULPI PHY to micro-AB connector - - x1 USB2.0 port via an internal UTMI PHY to micro-AB connector - - FlexCAN ports: - - 2 DB-9 female connectors for FlexCAN bus(revision 2.0B) - interface; - - DUART interface: - - DUART interface: supports two UARTs up to 115200 bps for - console display - - RJ45 connectors are used for these 2 UART ports. - - TDM - - 2 FXS ports connected via an external SLIC to the TDM interface. - SLIC is controllled via SPI. - - 1 FXO port connected via a relay to FXS for switchover to POTS + - Three 10/100/1000 BaseT Ethernet ports (One RGMII and two SGMII) + - PCIe 2.0: two x1 mini-PCIe slots + - SATA 2.0: two SATA interfaces + - USB 2.0: one USB interface + - FlexCAN: two FlexCAN interfaces (revision 2.0B) + - UART: one USB-to-Serial interface + - TDM: 2 FXS ports connected via an external SLIC to the TDM interface. + 1 FXO port connected via a relay to FXS for switchover to POTS + Board connectors: - Mini-ITX power supply connector - JTAG/COP for debugging -IEEE Std. 1588 signals for test and measurement -Real-time clock on I2C bus -POR - - support critical POR setting changed via switch on board -PCB - - 6-layer routing (4-layer signals, 2-layer power and ground) +POR: support critical POR setting changed via switch on board +PCB: 6-layer routing (4-layer signals, 2-layer power and ground) Physical Memory Map on P1010RDB === @@ -77,132 +59,119 @@ Configure the serial port of the attached computer with the following values: -Flow Control: Hardware/None -Settings of DIP-switch -== - SW4[1:4]= and SW6[4]=0 for boot from 16bit NOR flash - SW4[1:4]= 1000 and SW6[4]=1 for boot from 8bit NAND flash - SW4[1:4]= 0110 and SW6[4]=0 for boot from SPI flash +P1010RDB-PB default DIP-switch settings +=== +SW1[1:8]= 10101010 +SW2[1:8]=
[U-Boot] [PATCH v1 0/2] arm, da85x: updates for the ipam390 board
enable the RBL/UBL ECC layout through CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC define see for more info: http://processors.wiki.ti.com/index.php/DM365_Nand_ECC_layout and use this on the ipam390 board. Also do some minor changes for this board: - update default environment - change A2CR to correct value for UART boot mode - adapt cs3cfg timings for nand - change LED bootmode signalization Heiko Schocher (2): nand, davinci: add special UBL ecc position arm, da85x: update for the ipam390 board board/Barix/ipam390/ipam390-ais-uart.cfg | 2 +- board/Barix/ipam390/ipam390.c| 29 -- drivers/mtd/nand/davinci_nand.c | 10 + include/configs/ipam390.h| 35 4 Dateien geändert, 42 Zeilen hinzugefügt(+), 34 Zeilen entfernt(-) Signed-off-by: Heiko Schocher h...@denx.de Cc: Tom Rini tr...@ti.com Cc: Scott Wood scottw...@freescale.com -- 1.7.11.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 1/2] nand, davinci: add special UBL ecc position
enable the RBL/UBL ECC layout through
CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC define
see for more info:
http://processors.wiki.ti.com/index.php/DM365_Nand_ECC_layout
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Tom Rini tr...@ti.com
Cc: Scott Wood scottw...@freescale.com
---
drivers/mtd/nand/davinci_nand.c | 10 ++
1 Datei geändert, 10 Zeilen hinzugefügt(+)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index d8bb5d3..9f5bd85 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -267,6 +267,15 @@ static struct nand_ecclayout
nand_davinci_4bit_layout_oobfirst = {
#if defined(CONFIG_SYS_NAND_PAGE_2K)
.eccbytes = 40,
.eccpos = {
+#ifdef CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC
+ 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
+ 22, 23, 24, 25, 26, 27, 28, 29, 30, 31,
+ 38, 39, 40, 41, 42, 43, 44, 45, 46, 47,
+ 54, 55, 56, 57, 58, 59, 60, 61, 62, 63,
+ },
+ .oobfree = {
+ {2, 4}, {16, 6}, {32, 6}, {48, 6},
+#else
24, 25, 26, 27, 28,
29, 30, 31, 32, 33, 34, 35, 36, 37, 38,
39, 40, 41, 42, 43, 44, 45, 46, 47, 48,
@@ -275,6 +284,7 @@ static struct nand_ecclayout
nand_davinci_4bit_layout_oobfirst = {
},
.oobfree = {
{.offset = 2, .length = 22, },
+#endif /* #ifdef CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC */
},
#elif defined(CONFIG_SYS_NAND_PAGE_4K)
.eccbytes = 80,
--
1.7.11.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1 2/2] arm, da85x: update for the ipam390 board
- switch to correct ecc layout used by the RBL
enable CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC
- update default environment
- change A2CR to correct value for UART boot mode
- adapt cs3cfg timings for nand
- change LED bootmode signalization
Signed-off-by: Heiko Schocher h...@denx.de
Cc: Tom Rini tr...@ti.com
---
board/Barix/ipam390/ipam390-ais-uart.cfg | 2 +-
board/Barix/ipam390/ipam390.c| 29 --
include/configs/ipam390.h| 35
3 Dateien geändert, 32 Zeilen hinzugefügt(+), 34 Zeilen entfernt(-)
diff --git a/board/Barix/ipam390/ipam390-ais-uart.cfg
b/board/Barix/ipam390/ipam390-ais-uart.cfg
index e1a99f2..709cf23 100644
--- a/board/Barix/ipam390/ipam390-ais-uart.cfg
+++ b/board/Barix/ipam390/ipam390-ais-uart.cfg
@@ -109,7 +109,7 @@ CLK2XSRC = 0x
;NANDFCR = 0x
[EMIF25ASYNC]
A1CR = 0x
-A2CR = 0x3FFE
+A2CR = 0x04202110
A3CR = 0x
A4CR = 0x
NANDFCR = 0x0012
diff --git a/board/Barix/ipam390/ipam390.c b/board/Barix/ipam390/ipam390.c
index f3f276e..ae88b42 100644
--- a/board/Barix/ipam390/ipam390.c
+++ b/board/Barix/ipam390/ipam390.c
@@ -264,7 +264,7 @@ void show_boot_progress(int status)
static int green;
if (red == 0)
- red = init_led(CONFIG_IPAM390_GPIO_LED_RED, red, LED_OFF);
+ red = init_led(CONFIG_IPAM390_GPIO_LED_RED, red, LED_ON);
if (red != CONFIG_IPAM390_GPIO_LED_RED)
return;
if (green == 0)
@@ -277,10 +277,10 @@ void show_boot_progress(int status)
case BOOTSTAGE_ID_RUN_OS:
/*
* set normal state
-* LED Red : off
+* LED Red : on
* LED green: off
*/
- gpio_set_value(red, LED_OFF);
+ gpio_set_value(red, LED_ON);
gpio_set_value(green, LED_OFF);
break;
case BOOTSTAGE_ID_MAIN_LOOP:
@@ -326,23 +326,12 @@ int spl_start_uboot(void)
if (!bootmode)
if (ret == 0)
bootmode = 1;
- if (bootmode) {
- /*
-* Booting U-Boot
-* LED Red : on
-* LED green: off
-*/
- init_led(CONFIG_IPAM390_GPIO_LED_RED, red, LED_ON);
- init_led(CONFIG_IPAM390_GPIO_LED_GREEN, green, LED_OFF);
- } else {
- /*
-* Booting Linux
-* LED Red : off
-* LED green: off
-*/
- init_led(CONFIG_IPAM390_GPIO_LED_RED, red, LED_OFF);
- init_led(CONFIG_IPAM390_GPIO_LED_GREEN, green, LED_OFF);
- }
+ /*
+* LED red : on
+* LED green: off
+*/
+ init_led(CONFIG_IPAM390_GPIO_LED_RED, red, LED_ON);
+ init_led(CONFIG_IPAM390_GPIO_LED_GREEN, green, LED_OFF);
return bootmode;
}
#endif
diff --git a/include/configs/ipam390.h b/include/configs/ipam390.h
index 82d4298..155663e 100644
--- a/include/configs/ipam390.h
+++ b/include/configs/ipam390.h
@@ -122,13 +122,13 @@
(3 DV_DDR_SDCR_IBANK_SHIFT) |\
(2 DV_DDR_SDCR_PAGESIZE_SHIFT))
-#define CONFIG_SYS_DA850_CS3CFG(DAVINCI_ABCR_WSETUP(2) | \
+#define CONFIG_SYS_DA850_CS3CFG(DAVINCI_ABCR_WSETUP(1) | \
DAVINCI_ABCR_WSTROBE(2) | \
- DAVINCI_ABCR_WHOLD(1) | \
+ DAVINCI_ABCR_WHOLD(0) | \
DAVINCI_ABCR_RSETUP(1) | \
- DAVINCI_ABCR_RSTROBE(4) | \
- DAVINCI_ABCR_RHOLD(0) | \
- DAVINCI_ABCR_TA(1) | \
+ DAVINCI_ABCR_RSTROBE(2) | \
+ DAVINCI_ABCR_RHOLD(1) | \
+ DAVINCI_ABCR_TA(0) | \
DAVINCI_ABCR_ASIZE_8BIT)
@@ -161,6 +161,7 @@
#undef CONFIG_SYS_NAND_HW_ECC
#define CONFIG_SYS_MAX_NAND_DEVICE 1 /* Max number of NAND devices */
#define CONFIG_SYS_NAND_HW_ECC_OOBFIRST
+#define CONFIG_NAND_6BYTES_OOB_FREE_10BYTES_ECC
#define CONFIG_SYS_NAND_5_ADDR_CYCLE
#define CONFIG_SYS_NAND_PAGE_SIZE (2 10)
#define CONFIG_SYS_NAND_BLOCK_SIZE (128 10)
@@ -173,11 +174,10 @@
CONFIG_SYS_MALLOC_LEN - \
GENERATED_GBL_DATA_SIZE)
#define CONFIG_SYS_NAND_ECCPOS { \
- 24, 25, 26, 27, 28, \
- 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, \
- 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, \
- 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, \
- 59, 60, 61, 62, 63 }
+
Re: [U-Boot] [PATCH] net, phy, cpsw: fix unaligned access if no phy found
Hello Tom, Am 04.09.2013 15:14, schrieb Tom Rini: On Wed, Sep 04, 2013 at 02:16:01PM +0200, Heiko Schocher wrote: if phy_connect() did not find a phy, phydev is not initialized and following code in cpsw_phy_init() maybe crashes. Fix this. Signed-off-by: Heiko Schocherh...@denx.de Cc: Joe Hershbergerjoe.hershber...@gmail.com Cc: Mugunthan V Nmugunthan...@ti.com Cc: Tom Rinitr...@ti.com --- Found on the dxr2 board with no phy connected to the board, U-Boot crashes with: U-Boot 2013.07-12701-gea98378-dirty (Sep 04 2013 - 06:58:16) I2C: ready DRAM: 128 MiB Enable d-cache FactorySet is not right in eeprom. NAND: 256 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 8-bit BCH HW ECC selected Net: Could not get PHY for cpsw: addr 0 data abort MAYBE you should read doc/README.arm-unaligned-accesses pc : [87f80574] lr : [87f80fcc] sp : 86f5aee0 ip : 0034 fp : 80100020 r10: 0014 r9 : 07e5d000 r8 : 86f5af30 r7 : 86f5f750 r6 : 86f5f804 r5 : 86f5f708 r4 : 86f5f750 r3 : r2 : r1 : 87fa4d08 r0 : Flags: nZCv IRQs off FIQs on Mode SVC_32 Resetting CPU ... resetting ... --- drivers/net/cpsw.c | 3 +++ 1 Datei ge??ndert, 3 Zeilen hinzugef??gt(+) diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c index 9bab71a..b18d528 100644 --- a/drivers/net/cpsw.c +++ b/drivers/net/cpsw.c @@ -947,6 +947,9 @@ static int cpsw_phy_init(struct eth_device *dev, struct cpsw_slave *slave) dev, slave-data-phy_if); + if (!phydev) + return -1; + phydev-supported= supported; phydev-advertising = phydev-supported; This isn't really an unaligned access problem it's a NULL pointer dereference, so I'll re-word the commit message when I grab this for u-boot-ti soon. Yes, thanks ... Hmm.. there are also problems if starting tftp on such a hardware ... I found more issues in this driver ... I repost a v2 soon ... 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
