Re: [U-Boot] am335x: GPMC: reading speed with prefetch mode
Hi, On 03/20/2015 12:24 PM, Yegor Yefremov wrote: I've also put printf() into omap_nand_read_prefetch8() just to make sure it is called - it was called. Does it fall back to polled mode because the engine is busy maybe? See the comment in the code that deals with the return value of __read_prefetch_aligned(). Not that I'd be aware of such an issue, but maybe you need to enable to enable some module or clock? Further ideas? It's been a while, but when I worked on cutting down the boot times of a custom AM335x board months ago, these were the steps that I took: * I tweaked the NAND timing values in the DTS, and then looked at the GPMC timing values Linux calculated from that and copied it over to U-Boot. This gave a NAND read speed-up of ~20-30% in comparison to the defaults U-Boot ships with. * Implementing the GPMC prefetch operations boosted the speed by of raw NAND reads by approximately factor 2. * The NAND bad block table scan was reduced to the first 64 blocks, because this is all I cared for from U-Boot anyway, and Linux will do the same anyway at a later point. This brought down the scan process from ~2s to some milliseconds. * In the SPL code, the CPU was put in GHz mode as early as possible. That improved load times again, and also reduced the time spent in the kernel decompressor. I Linux I had ti,nand-xfer-type = polled;. After replacing it with ti,nand-xfer-type = prefetch-polled; I now get # dd if=/dev/mtdblock5 of=/dev/null bs=2M count=8 8+0 records in 8+0 records out 16777216 bytes (17 MB) copied, 2.58744 s, 6.5 MB/s instead of: # dd if=/dev/mtdblock5 of=/dev/null bs=2M count=8 8+0 records in 8+0 records out 16777216 bytes (17 MB) copied, 6.05157 s, 2.8 MB/s Do I see it right, that DMA support is not implemented in am33xx.dtsi? Right, I just double-checked with the DTS we were using. It had no specific ti,nand-xfer-type setting, so it should default to prefetch-polled. So it seems DMA is not in place for this board and the gpmc-nand driver. Sorry for the confusion. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] am335x: GPMC: reading speed with prefetch mode
Hi, On 03/19/2015 02:41 PM, Yegor Yefremov wrote: I've got v2015.04-rc4 running on my custom am335x (600MHz) based board. My 8-bit NAND chip: [17.297793 0.004021] omap-gpmc 5000.gpmc: GPMC revision 6.0 [17.303850 0.006057] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xda [17.309706 0.005856] nand: Micron MT29F2G08ABAEAWP [17.312823 0.003117] nand: 256MiB, SLC, page size: 2048, OOB size: 64 [17.317311 0.004488] nand: using OMAP_ECC_BCH8_CODE_HW ECC scheme I need to load about 17Mb FIT image from UBIFS partition. In Linux it takes about 7 seconds: # time cp /mnt/kernel-fit.itb /tmp/ real0m 7.12s user0m 0.00s sys 0m 6.89s But U-Boot needs about twice the time: On my boards, I didn't load the uImage through UBIFS but directly from the raw mtdblock device. That might make a significant difference, depending on how UBIFS is implemented in U-Boot. For performance tests, I recommend you compare the numbers using 'dd' from the mtdblock device under Linux, and 'nand read.i' from U-Boot. Linux will, however, still be faster due to DMA, which is unsuable from U-Boot due to the lack of interrupt handlers. But in my tests, enabling the prefetch mode in U-Boot gave me a speed-up of roughly factor 2 IIRC. Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] am335x: GPMC: reading speed with prefetch mode
On 03/19/2015 04:13 PM, Yegor Yefremov wrote: Strange. Have tried with nand read command, but still the same result with and without CONFIG_NAND_OMAP_GPMC_PREFETCH : [2.150655 0.001006] NAND read: device 0 offset 0x26, size 0x120 [15.978943 13.828288] 18874368 bytes read: OK What about adding some debug prints to the prefetch setup function and see if it is executed at all? Daniel, do you have the numbers? Images size and load time? What can I expect? I don't currently have the setup at hand, sorry. But the number I recall from an email conversation back then is: The time from power-on, loading SPL, loading U-Boot, leeching a 6MB uImage, jumping into it waiting for the console to start dumping the kernel boot messages was less than 5 seconds in total. Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] mtd: OMAP: Enable GPMC prefetch mode
Hi Guido,
thanks for your feedback!
On 12/19/2014 05:27 PM, Guido MartÃnez wrote:
+/**
+ * omap_prefetch_enable - configures and starts prefetch transfer
+ * @fifo_th: fifo threshold to be used for read/ write
+ * @count: number of bytes to be transferred
+ * @is_write: prefetch read(0) or write post(1) mode
+ */
+static int omap_prefetch_enable(int fifo_th, unsigned int count, int
is_write)
+{
+uint32_t val;
+
+if (fifo_th PREFETCH_FIFOTHRESHOLD_MAX)
+return -EINVAL;
+
+if (readl(gpmc_cfg-prefetch_control))
+return -EBUSY;
+
+/* Set the amount of bytes to be prefetched */
+writel(count, gpmc_cfg-prefetch_config2);
+
+val = (cs PREFETCH_CONFIG1_CS_SHIFT) | (is_write 1) |
On a current U-boot cs doesn't exist. I think you might want to pass a
struct omap_nand_info * and use info-cs.
I fixed this last bit, and tested it. It results in 2.5x speed
improvements on a Micron NAND. So, thanks :) !
If you resend, you have my Reviewed-by and Tested-by.
That's great to hear. However, I'm not currently working on this
project, so I don't have a chance to respin the patch. In case any of
the maintainers is interested, I guess that's easy enough to tweak on
the fly when merging the patch :)
Thanks,
Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] usb: musb-new: core: set MUSB_POWER_HSENAB in MUSB_POWER for host mode
This bit allows the MUSB controller to negotiate for high-speed mode when the device is reset by the hub. If unset, Babble errors occur with high-speed mass storage devices right after the first packet. This condition is not caught by the interrupt handles in U-Boot, so no recovery is done, and the USB communication is stuck. To fix this, set the bit unconditionally, not only for CONFIG_USB_GADGET_DUALSPEED but also for host-only modes. Signed-off-by: Daniel Mack zon...@gmail.com --- drivers/usb/musb-new/musb_core.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/usb/musb-new/musb_core.c b/drivers/usb/musb-new/musb_core.c index 36681b6..eeaacdf 100644 --- a/drivers/usb/musb-new/musb_core.c +++ b/drivers/usb/musb-new/musb_core.c @@ -943,9 +943,7 @@ void musb_start(struct musb *musb) /* put into basic highspeed mode and start session */ musb_writeb(regs, MUSB_POWER, MUSB_POWER_ISOUPDATE -#ifdef CONFIG_USB_GADGET_DUALSPEED | MUSB_POWER_HSENAB -#endif /* ENSUSPEND wedges tusb */ /* | MUSB_POWER_ENSUSPEND */ ); -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/2] OMAP/GPMC: speed up NAND read access
Hi, On 06/26/2014 08:08 AM, Gupta, Pekon wrote: From: Daniel Mack [mailto:zon...@gmail.com] Resending this since I got no replies on the first version. I also fixed up the commit log of #1. I plan to test this, but there is still a long pending list of patches which for me to test in kernel and u-boot. So it might take bit time. But really thanks much for this feature addition. Just a minor feedback, if you like it... GPMC controller support various transfer modes - POLLED: default mode - PREFETCH_POLLED : as added in this patch - PREFETCH_IRQ: not implemented/required - PREFETCH_DMA: not implemented/required (1) Will it be okay to use following config names, this would be synonymous to the xfer-modes DT binding used in kernel ? CONFIG_NAND_OMAP_XFER_MODE_POLLED CONFIG_NAND_OMAP_XFER_MODE_PREFETCH_POLLED Yes, I've seen that, but decided for shorter names as we will never support DMA or IRQ modes from U-Boot. But I can of course change that, I'd ultimately leave such decisions up to you :) (2) It would be good if you can make PREFETCH_POLLED mode as default And instead make POLLED mode selectable. #ifdef CONFIG_NAND_OMAP_XFER_MODE_POLLED /* old behavior */ #else /* /* default PREFETCH_POLLED mode */ #endif Ok, but then we'd need something that selects PREFETCH_POLLED automatically if nothing else is selected in the config. I wanted to avoid yet another mandatory config symbol that have to be patched into all existing configs. Could you lay out how that would be done? However, let me first test your patch, and these minor nit-picks (if required) can be done later. Alright. I'm in no hurry with this. Good to know it's on your list. Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] OMAP/GPMC: speed up NAND read access
Resending this since I got no replies on the first version. I also fixed up the commit log of #1. I spent some time looking into boot times of AM335x platforms. One big improvement I made came with adding support for GPMC prefetch mode, which gave a speed-up of NAND reads of roughly factor 2. This is what patch #1 does. Note that this is currently limited to read operations in 8-bit mode, but I believe it could be easily extended to 16-bit operations if anyone has hardware to test it on. Using the engine for write mode speed improvements should also be doable, but I didn't spend time on it yet. That can be added as a separate patch later. Patch #2 decreases the GPMC memory map window size from 256MiB to 16MiB. Admittedly, I'm not quite sure about the reason, but a read from offset 0 in this memory area will freeze U-Boot instantly if the size is configured to 256MiB. As contents of the FIFO are accessed in a pseudo-mode from offset 0 anyway, it doesn't really matter. What I also did to further speed up my boot was to tweak the GPMC parameters for the NAND chip on our boards, but that's not part of this patch set, and probably deserves a little more cleanup. Test results and feedback very welcome. Thanks, Daniel Daniel Mack (2): mtd: OMAP: Enable GPMC prefetch mode ARM: omap-common: gpmp: decrease memory region size to 16MiB arch/arm/cpu/armv7/omap-common/mem-common.c | 2 +- doc/README.nand | 5 ++ drivers/mtd/nand/omap_gpmc.c| 115 +++- include/linux/mtd/omap_gpmc.h | 6 +- 4 files changed, 124 insertions(+), 4 deletions(-) -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] mtd: OMAP: Enable GPMC prefetch mode
Enable GPMC's prefetch feature for NAND access. This speeds up NAND read
access a lot by pre-fetching contents in the background and reading them
through the FIFO address.
The current implementation has two limitations:
a) it only works in 8-bit mode
b) it only supports read access
Both is easily fixable by someone who has hardware to implement it.
Note that U-Boot code uses non word-aligned buffers to read data into, and
request read lengths that are not multiples of 4, so both partial buffers
(head and tail) have to be addressed.
Tested on AM335x hardware.
Signed-off-by: Daniel Mack zon...@gmail.com
---
doc/README.nand | 5 ++
drivers/mtd/nand/omap_gpmc.c | 115 +-
include/linux/mtd/omap_gpmc.h | 6 ++-
3 files changed, 123 insertions(+), 3 deletions(-)
diff --git a/doc/README.nand b/doc/README.nand
index 70cf768..6459f2a 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -292,6 +292,11 @@ Platform specific options
Thus BCH16 can be supported on 4K page NAND.
+CONFIG_NAND_OMAP_PREFETCH
+ On OMAP platforms that use the GPMC controller (CONFIG_NAND_OMAP_GPMC),
+ this options enables the code that uses the prefetch mode to speed up
+ read operations.
+
NOTE:
=
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index 1acf06b..e2d57bd 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -446,6 +446,113 @@ static int omap_correct_data_bch(struct mtd_info *mtd,
uint8_t *dat,
return (err) ? err : error_count;
}
+#ifdef CONFIG_NAND_OMAP_GPMC_PREFETCH
+
+#define PREFETCH_CONFIG1_CS_SHIFT 24
+#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
+#define PREFETCH_FIFOTHRESHOLD(val)((val) 8)
+#define PREFETCH_STATUS_COUNT(val) (val 0x3fff)
+#define PREFETCH_STATUS_FIFO_CNT(val) ((val 24) 0x7F)
+#define ENABLE_PREFETCH(1 7)
+
+/**
+ * omap_prefetch_enable - configures and starts prefetch transfer
+ * @fifo_th: fifo threshold to be used for read/ write
+ * @count: number of bytes to be transferred
+ * @is_write: prefetch read(0) or write post(1) mode
+ */
+static int omap_prefetch_enable(int fifo_th, unsigned int count, int is_write)
+{
+ uint32_t val;
+
+ if (fifo_th PREFETCH_FIFOTHRESHOLD_MAX)
+ return -EINVAL;
+
+ if (readl(gpmc_cfg-prefetch_control))
+ return -EBUSY;
+
+ /* Set the amount of bytes to be prefetched */
+ writel(count, gpmc_cfg-prefetch_config2);
+
+ val = (cs PREFETCH_CONFIG1_CS_SHIFT) | (is_write 1) |
+ PREFETCH_FIFOTHRESHOLD(fifo_th) | ENABLE_PREFETCH;
+ writel(val, gpmc_cfg-prefetch_config1);
+
+ /* Start the prefetch engine */
+ writel(1, gpmc_cfg-prefetch_control);
+
+ return 0;
+}
+
+/**
+ * omap_prefetch_reset - disables and stops the prefetch engine
+ */
+static void omap_prefetch_reset(void)
+{
+ writel(0, gpmc_cfg-prefetch_control);
+ writel(0, gpmc_cfg-prefetch_config1);
+}
+
+static int __read_prefetch_aligned(struct nand_chip *chip, uint32_t *buf, int
len)
+{
+ int ret;
+ uint32_t cnt;
+
+ ret = omap_prefetch_enable(PREFETCH_FIFOTHRESHOLD_MAX, len, 0);
+ if (ret 0)
+ return ret;
+
+ do {
+ int i;
+
+ cnt = readl(gpmc_cfg-prefetch_status);
+ cnt = PREFETCH_STATUS_FIFO_CNT(cnt);
+
+ for (i = 0; i cnt / 4; i++) {
+ *buf++ = readl(CONFIG_SYS_NAND_BASE);
+ len -= 4;
+ }
+ } while (len);
+
+ omap_prefetch_reset();
+
+ return 0;
+}
+
+static void omap_nand_read_prefetch8(struct mtd_info *mtd, uint8_t *buf, int
len)
+{
+ int ret;
+ uint32_t head, tail;
+ struct nand_chip *chip = mtd-priv;
+
+ /*
+* If the destination buffer is unaligned, start with reading
+* the overlap byte-wise.
+*/
+ head = ((uint32_t) buf) % 4;
+ if (head) {
+ nand_read_buf(mtd, buf, head);
+ buf += head;
+ len -= head;
+ }
+
+ /*
+* Only transfer multiples of 4 bytes in a pre-fetched fashion.
+* If there's a residue, care for it byte-wise afterwards.
+*/
+ tail = len % 4;
+
+ ret = __read_prefetch_aligned(chip, (uint32_t *) buf, len - tail);
+ if (ret 0) {
+ /* fallback in case the prefetch engine is busy */
+ nand_read_buf(mtd, buf, len);
+ } else if (tail) {
+ buf += len - tail;
+ nand_read_buf(mtd, buf, tail);
+ }
+}
+#endif /* CONFIG_NAND_OMAP_GPMC_PREFETCH */
+
/**
* omap_read_page_bch - hardware ecc based page read function
* @mtd: mtd info structure
@@ -883,11 +990,15 @@ int board_nand_init(struct nand_chip *nand)
if (err)
return err;
-#ifdef
[U-Boot] [PATCH v2 2/2] ARM: omap-common: gpmp: decrease memory region size to 16MiB
That memory area is not used except for the first location, so it doesn't
matter. However, with the length configured to 256MiB, U-Boot crased when
accessing contents of the map.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/cpu/armv7/omap-common/mem-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/mem-common.c
b/arch/arm/cpu/armv7/omap-common/mem-common.c
index 944ef84..3595806 100644
--- a/arch/arm/cpu/armv7/omap-common/mem-common.c
+++ b/arch/arm/cpu/armv7/omap-common/mem-common.c
@@ -99,7 +99,7 @@ void gpmc_init(void)
M_NAND_GPMC_CONFIG6,
0
};
- u32 size = GPMC_SIZE_256M;
+ u32 size = GPMC_SIZE_16M;
u32 base = CONFIG_SYS_NAND_BASE;
#elif defined(CONFIG_CMD_ONENAND)
const u32 gpmc_regs[GPMC_MAX_REG] = { ONENAND_GPMC_CONFIG1,
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/2] OMAP/GPMC: speed up NAND read access
Hi Tom, On 06/25/2014 03:00 PM, Tom Rini wrote: On Wed, Jun 25, 2014 at 02:43:31PM +0200, Daniel Mack wrote: Resending this since I got no replies on the first version. I also fixed up the commit log of #1. Sorry, I intended to play with it, but got busy. No problem. I just don't want it to get lost. Can you do a v3 where you also enable this on am335x_evm which is where I assume you did, or at least can, test the code? Thanks! No, I only successfully tested this on an own board implementation. I didn't know whether am335x_evm has 8-bit or 16-bit NAND. I didn't touch the config of any board I don't have access to as I can't test such a change :) Can you just add #define CONFIG_NAND_OMAP_GPMC_PREFETCH in your config and commit it with your S-o-b if it works for you? Thanks, Daniel signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mtd: OMAP: Enable GPMC prefetch mode
Enable GPMC's prefetch feature for NAND access. This speeds up NAND read
access a lot by pre-fetching contents in the background and reading them
through the FIFO address.
The current implementation has two limitations:
a) it only works for 16bit
b) it only supports read access
Both is easily fixable by someone who has hardware to implement it.
Note that U-Boot code uses non word-aligned buffers to read data into, and
request read lengths that are not multiples of 4, so both partial buffers
(head and tail) have to be addressed.
Tested on AM335x hardware.
Signed-off-by: Daniel Mack zon...@gmail.com
---
doc/README.nand | 5 ++
drivers/mtd/nand/omap_gpmc.c | 115 +-
include/linux/mtd/omap_gpmc.h | 6 ++-
3 files changed, 123 insertions(+), 3 deletions(-)
diff --git a/doc/README.nand b/doc/README.nand
index 70cf768..6459f2a 100644
--- a/doc/README.nand
+++ b/doc/README.nand
@@ -292,6 +292,11 @@ Platform specific options
Thus BCH16 can be supported on 4K page NAND.
+CONFIG_NAND_OMAP_PREFETCH
+ On OMAP platforms that use the GPMC controller (CONFIG_NAND_OMAP_GPMC),
+ this options enables the code that uses the prefetch mode to speed up
+ read operations.
+
NOTE:
=
diff --git a/drivers/mtd/nand/omap_gpmc.c b/drivers/mtd/nand/omap_gpmc.c
index 1acf06b..e2d57bd 100644
--- a/drivers/mtd/nand/omap_gpmc.c
+++ b/drivers/mtd/nand/omap_gpmc.c
@@ -446,6 +446,113 @@ static int omap_correct_data_bch(struct mtd_info *mtd,
uint8_t *dat,
return (err) ? err : error_count;
}
+#ifdef CONFIG_NAND_OMAP_GPMC_PREFETCH
+
+#define PREFETCH_CONFIG1_CS_SHIFT 24
+#define PREFETCH_FIFOTHRESHOLD_MAX 0x40
+#define PREFETCH_FIFOTHRESHOLD(val)((val) 8)
+#define PREFETCH_STATUS_COUNT(val) (val 0x3fff)
+#define PREFETCH_STATUS_FIFO_CNT(val) ((val 24) 0x7F)
+#define ENABLE_PREFETCH(1 7)
+
+/**
+ * omap_prefetch_enable - configures and starts prefetch transfer
+ * @fifo_th: fifo threshold to be used for read/ write
+ * @count: number of bytes to be transferred
+ * @is_write: prefetch read(0) or write post(1) mode
+ */
+static int omap_prefetch_enable(int fifo_th, unsigned int count, int is_write)
+{
+ uint32_t val;
+
+ if (fifo_th PREFETCH_FIFOTHRESHOLD_MAX)
+ return -EINVAL;
+
+ if (readl(gpmc_cfg-prefetch_control))
+ return -EBUSY;
+
+ /* Set the amount of bytes to be prefetched */
+ writel(count, gpmc_cfg-prefetch_config2);
+
+ val = (cs PREFETCH_CONFIG1_CS_SHIFT) | (is_write 1) |
+ PREFETCH_FIFOTHRESHOLD(fifo_th) | ENABLE_PREFETCH;
+ writel(val, gpmc_cfg-prefetch_config1);
+
+ /* Start the prefetch engine */
+ writel(1, gpmc_cfg-prefetch_control);
+
+ return 0;
+}
+
+/**
+ * omap_prefetch_reset - disables and stops the prefetch engine
+ */
+static void omap_prefetch_reset(void)
+{
+ writel(0, gpmc_cfg-prefetch_control);
+ writel(0, gpmc_cfg-prefetch_config1);
+}
+
+static int __read_prefetch_aligned(struct nand_chip *chip, uint32_t *buf, int
len)
+{
+ int ret;
+ uint32_t cnt;
+
+ ret = omap_prefetch_enable(PREFETCH_FIFOTHRESHOLD_MAX, len, 0);
+ if (ret 0)
+ return ret;
+
+ do {
+ int i;
+
+ cnt = readl(gpmc_cfg-prefetch_status);
+ cnt = PREFETCH_STATUS_FIFO_CNT(cnt);
+
+ for (i = 0; i cnt / 4; i++) {
+ *buf++ = readl(CONFIG_SYS_NAND_BASE);
+ len -= 4;
+ }
+ } while (len);
+
+ omap_prefetch_reset();
+
+ return 0;
+}
+
+static void omap_nand_read_prefetch8(struct mtd_info *mtd, uint8_t *buf, int
len)
+{
+ int ret;
+ uint32_t head, tail;
+ struct nand_chip *chip = mtd-priv;
+
+ /*
+* If the destination buffer is unaligned, start with reading
+* the overlap byte-wise.
+*/
+ head = ((uint32_t) buf) % 4;
+ if (head) {
+ nand_read_buf(mtd, buf, head);
+ buf += head;
+ len -= head;
+ }
+
+ /*
+* Only transfer multiples of 4 bytes in a pre-fetched fashion.
+* If there's a residue, care for it byte-wise afterwards.
+*/
+ tail = len % 4;
+
+ ret = __read_prefetch_aligned(chip, (uint32_t *) buf, len - tail);
+ if (ret 0) {
+ /* fallback in case the prefetch engine is busy */
+ nand_read_buf(mtd, buf, len);
+ } else if (tail) {
+ buf += len - tail;
+ nand_read_buf(mtd, buf, tail);
+ }
+}
+#endif /* CONFIG_NAND_OMAP_GPMC_PREFETCH */
+
/**
* omap_read_page_bch - hardware ecc based page read function
* @mtd: mtd info structure
@@ -883,11 +990,15 @@ int board_nand_init(struct nand_chip *nand)
if (err)
return err;
-#ifdef
[U-Boot] [PATCH 0/2] OMAP/GPMC: speed up NAND read access
Hi, I spent some time looking into boot times of AM335x platforms. One big improvement I made came with adding support for GPMC prefetch mode, which gave a speed-up of NAND reads of roughly factor 2. This is what patch #1 does. Note that this is currently limited to read operations in 8-bit mode, but I believe it could be easily extended to 16-bit operations if anyone has hardware to test it on. Using the engine for write mode speed improvements should also be doable, but I didn't spend time on it yet. That can be added as a separate patch later. Patch #2 decreases the GPMC memory map window size from 256MiB to 16MiB. Admittedly, I'm not quite sure about the reason, but a read from offset 0 in this memory area will freeze U-Boot instantly if the size is configured to 256MiB. As contents of the FIFO are accessed in a pseudo-mode from offset 0 anyway, it doesn't really matter. What I also did to further speed up my boot was to tweak the GPMC parameters for the NAND chip on our boards, but that's not part of this patch set, and probably deserves a little more cleanup. Test results and feedback very welcome. Thanks, Daniel Daniel Mack (2): mtd: OMAP: Enable GPMC prefetch mode ARM: omap-common: gpmp: decrease memory region size to 16MiB arch/arm/cpu/armv7/omap-common/mem-common.c | 2 +- doc/README.nand | 5 ++ drivers/mtd/nand/omap_gpmc.c| 115 +++- include/linux/mtd/omap_gpmc.h | 6 +- 4 files changed, 124 insertions(+), 4 deletions(-) -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: omap-common: gpmp: decrease memory region size to 16MiB
That memory area is not used except for the first location, so it doesn't
matter. However, with the length configured to 256MiB, U-Boot crased when
accessing contents of the map.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/cpu/armv7/omap-common/mem-common.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/mem-common.c
b/arch/arm/cpu/armv7/omap-common/mem-common.c
index 944ef84..3595806 100644
--- a/arch/arm/cpu/armv7/omap-common/mem-common.c
+++ b/arch/arm/cpu/armv7/omap-common/mem-common.c
@@ -99,7 +99,7 @@ void gpmc_init(void)
M_NAND_GPMC_CONFIG6,
0
};
- u32 size = GPMC_SIZE_256M;
+ u32 size = GPMC_SIZE_16M;
u32 base = CONFIG_SYS_NAND_BASE;
#elif defined(CONFIG_CMD_ONENAND)
const u32 gpmc_regs[GPMC_MAX_REG] = { ONENAND_GPMC_CONFIG1,
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merging device trees at runtime for module-based systems
On 03.11.2012 16:25, David Gibson wrote: On Thu, Nov 01, 2012 at 10:24:06AM +0100, Daniel Mack wrote: On 01.11.2012 04:26, David Gibson wrote: On Fri, Oct 26, 2012 at 09:24:11AM +0200, Daniel Mack wrote: I would especially like to know where such a new functionality should live, which data types it should operate on and what would be an appropriate name for it. So.. the first thought I have reading the original mail in the thread is that it's arguable that you really want a more heavyweight firmware for this setup, that actively maintains a live device tree as OF does, rather than u-boot which is pretty oriented towards a close-to-static device setup. That's just a thought though, I'm not saying that at least some of this functionality doesn't belong in libfdt. So, my thought would be that stuff for manipulating big chunks of tree should go in a new .c file inside the libfdt tree. We already have del_node and nop_node of course, which can remove whole subtrees. I guess the big extra function you'd want would be something like: fdt_graft(void *fdt, int offset, void *subtree); Which would graft the tree blob give by subtree into the master tree (fdt) at node 'offset'. Actually that might need to take a name for the top-level of the subtree to take in the new tree too. I called the function fdt_overlay, but I guess the implementation is similar to what you thought of. I pushed it here, see the topmost 3 commits: https://github.com/zonque/dtc/commits/overlay Interesting. So, it seems to me that fdt_graft() and fdt_overlay() are different operations - both could be potentially useful. fdt_graft() would attach a new subtree somewhere within the master tree, with the assumption that the root of the subtree would become a new node in the resulting tree. Overwriting an existing subtree with a new one would be an error for a graft. fdt_overlay, as you've implemented, can either add new nodes or modify existing ones by replacing or adding new properties. So, some notes on the actual implementation: The in-place modification of the given path (which should really be const char *) in your fdt_add_subnode_r() is nasty, nasty, nasty. And it's unnecessary because you can use the existing fdt_add_subnode_namelen() to work with subsections of the path without needing to either have a temporary buffer or do in-place modification. Ok - thanks for the hint. I was looking for a nicer way as I also was really unhappy about the implementation, but without access to heap operations and avoid eating up too much stack, I thought this is a nasty but working solution. After all, that whole hacking was just meant as a proof of concept for the result, which failed ;) ...except, I don't think you actually need fdt_add_subnoode_r() for your overlay implementation in any case. AFAICT in your fdt_overlay() implementation you're only adding nodes from the second tree if they contain properties (the fdt_add_subnode_r() call is under the FDT_PROP case). I'm not sure if that was a deliberate policy decision - if so I really can't see a reason for it. That was merely to spare some cycles, as fdt_add_subnode_r() turned out not to be free of costs. If instead you *always* add subnodes when they exist in the second tree, you'll be doing your add nodes from the FDT_BEGIN_NODE tag case. And you always get BEGIN_NODE tags for parents before subnodes, so you can naturally add your new subnode path component by component without having to walk down the path again in fdt_add_subnode_r(). As an added bonus you no longer need pathbuf and it's arbitrary size limit. Yes, I had something like that in mind, but that requires keeping the state of both trees around and care for the stacking etc. Hrm.. wait... I guess you need a stack so you can handle FDT_END_NODE correctly. I suspect a recursive solution (effectively using the machine stack) would still take less (machine) stack space than pathbuf. Especially if pathbuf was increased up to PATH_MAX, which is my usual rule of thumb when I can't avoid an arbitrary buffer size. On a tangent, note that fdt_graft() as defined above, unlike fdt_overlay() would allow a considerably optimized implementation. Instead of doing lots of individual inserts into the tree (and therefore a lot of memmove()s), you could do one big _fdt_splice(), copy in the grafted tree's structure block, then run through it correcting property name offsets. Given the fact that this implementation turns out to be inappropriate as solution to my actual problem, I'm uncertain whether it should be merged at all. Dunno of how much use that would be for others after all. Many thanks for you input, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merging device trees at runtime for module-based systems
On 01.11.2012 04:26, David Gibson wrote: On Fri, Oct 26, 2012 at 09:24:11AM +0200, Daniel Mack wrote: I would especially like to know where such a new functionality should live, which data types it should operate on and what would be an appropriate name for it. So.. the first thought I have reading the original mail in the thread is that it's arguable that you really want a more heavyweight firmware for this setup, that actively maintains a live device tree as OF does, rather than u-boot which is pretty oriented towards a close-to-static device setup. That's just a thought though, I'm not saying that at least some of this functionality doesn't belong in libfdt. So, my thought would be that stuff for manipulating big chunks of tree should go in a new .c file inside the libfdt tree. We already have del_node and nop_node of course, which can remove whole subtrees. I guess the big extra function you'd want would be something like: fdt_graft(void *fdt, int offset, void *subtree); Which would graft the tree blob give by subtree into the master tree (fdt) at node 'offset'. Actually that might need to take a name for the top-level of the subtree to take in the new tree too. I called the function fdt_overlay, but I guess the implementation is similar to what you thought of. I pushed it here, see the topmost 3 commits: https://github.com/zonque/dtc/commits/overlay Things get trickier when you consider what might need to be tweaked in the subtree to make it fit into the master tree. If it requires widespread alterations through the subtree that's going to get really ugly and I think you would be better off with a firmware with a fuller handling of a live device tree. But I think that can probably be avoided with proper design of the bindings. To get that to work you'll need to make sure you use some sort of local addressing within the subtree. Then it should only be necessary to insert/alter a ranges property at the top level of the subtree (or possibly its parent) to map that correctly into the global address space. Likewise interrupts within the subtree probably shouldn't address an external interrupt controller but rather the root of the tree. You can then insert an interrupt-map property which will wire those into the global interrupt tree. As pointed out on another end of this thread, the use of my simple implementation is rather limited. I need to think about something more sophisticated, or abadon the idea alltogether. Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merging device trees at runtime for module-based systems
cc devicetree-discuss. Here's a reference to the full thread:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/145221/
On 26.10.2012 20:39, Stephen Warren wrote:
On 10/24/2012 03:47 AM, Daniel Mack wrote:
Hi,
a project I'm involved in uses a module/baseboard combo, and components
on either board are described in DT. I'm currently using separate dts
files which build upon each other with include statements, which works
fine for development.
In production though, we will certainly have running changes (and hence
different versions) over the lifetime of the product for both the
baseboard and the module, and the hardware has support for identifying
the versions of both sides at runtime.
So let's say we have n versions of the baseboard and m versions of the
module, we would much like to only prepare n + m files, instead of n * m
by pre-compiling every possible combination (some of which may actually
never occur 'in the wild').
So my question is: is it possible to do that kind of assembly of a
number of files at runtime in U-Boot? I guess all it takes is merging a
number of trees together, right? I browsed through the APIs but couldn't
yet find an clear approach to that kind of problem. If not, what would
it take to add that functionality? I can probably help with the
implementation if someone tells me what would be the right way.
Yes, solving this would be very useful; it's a wide-spread problem.
Some thoughts though:
Simply overlaying two DTBs on top of each-other (in the same fashion
that dtc's /include/ statement would do at compile-time) might not be
fully general enough, although perhaps it would be sufficient for your
immediate needs.
For example, lets say that a GPIO is routed from a device on the main
board to a device on a daughter board, or even from one daughter board
into the main board and back out to a different daughter board. Now,
consider that the different board(s) that are the source of the GPIO
might use completely different SoCs or versions of the SoC, which might
require using a different GPIO specifier to represent the signal. That
means you need to change the .dtb file for the client of the GPIO
depending on the HW or .dtb that provides the GPIO. That's certainly not
a simple matter of merging multiple .dtb blobs together.
Hmm. After implementing a very simple overlay approach, I can now see
your point :) Yes in fact, that's a real problem.
The same issue could easily apply to I2C or SPI buses, chip selects, etc.
One solution would be to explicitly represent a connector or
connection-point in DT, such that the connector can implement the naming
of all signals that pass through it, and provide a translation point for
hooking the two DT fragments together. This seems within the spirit of DT.
Yes, but you still can't handle references that way.
Let me try and conclude this for others. Say the module tree A looks
something like this:
/ {
multi-regulator {
vcc1v8: regulator@0 {
/* ... */
};
};
};
... and the baseboard (B), that makes use of (and hence depends on)
the module, has something like this:
/ {
consumer {
main-supply = vcc1v8;
};
};
Now, let's say in a subsequent version of the module, we change whatever
provides that supply for 1.8 volts, but the consumer on the baseboard
shouldn't care much of course, thanks to all the abstraction layers that
we have now in the kernel.
However, the problem here is that I can't just compile trees A and B
individually into .dtbs that get merged later, because dtc will bail on
the unresolved reference of vcc1v8 of course. And cases like this are
the whole reason why I started to think about modularization of trees in
the first place.
So the simple overlay method doesn't help here at all, even though I can
share the code if anyone's interested.
Another solution might be some form of variables/macros/code in the DTB
that can be used to parameterize other DTBs that get merged with it.
This is probably an enormous can of worms.
Yes, exactly, a can of worms and most probably unmaintainble in real
life. I start to believe that the cleanest solution to this would be to
have full DTC functionality in U-Boot and compile the tree from dts, but
then again I have no clue on how to handle the file lookups that arise
from includes. Do you think it would it be worth going that way?
If not, I guess we're down to n*m files eventually, which is really sad
as they might even become a storage problem at some point.
Thanks for your input,
Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merging device trees at runtime for module-based systems
On 01.11.2012 00:13, Stephen Warren wrote:
On 10/31/2012 05:00 PM, Daniel Mack wrote:
cc devicetree-discuss. Here's a reference to the full thread:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/145221/
On 26.10.2012 20:39, Stephen Warren wrote:
On 10/24/2012 03:47 AM, Daniel Mack wrote:
Hi,
a project I'm involved in uses a module/baseboard combo, and components
on either board are described in DT. I'm currently using separate dts
files which build upon each other with include statements, which works
fine for development.
In production though, we will certainly have running changes (and hence
different versions) over the lifetime of the product for both the
baseboard and the module, and the hardware has support for identifying
the versions of both sides at runtime.
So let's say we have n versions of the baseboard and m versions of the
module, we would much like to only prepare n + m files, instead of n * m
by pre-compiling every possible combination (some of which may actually
never occur 'in the wild').
So my question is: is it possible to do that kind of assembly of a
number of files at runtime in U-Boot? I guess all it takes is merging a
number of trees together, right? I browsed through the APIs but couldn't
yet find an clear approach to that kind of problem. If not, what would
it take to add that functionality? I can probably help with the
implementation if someone tells me what would be the right way.
Yes, solving this would be very useful; it's a wide-spread problem.
Some thoughts though:
Simply overlaying two DTBs on top of each-other (in the same fashion
that dtc's /include/ statement would do at compile-time) might not be
fully general enough, although perhaps it would be sufficient for your
immediate needs.
For example, lets say that a GPIO is routed from a device on the main
board to a device on a daughter board, or even from one daughter board
into the main board and back out to a different daughter board. Now,
consider that the different board(s) that are the source of the GPIO
might use completely different SoCs or versions of the SoC, which might
require using a different GPIO specifier to represent the signal. That
means you need to change the .dtb file for the client of the GPIO
depending on the HW or .dtb that provides the GPIO. That's certainly not
a simple matter of merging multiple .dtb blobs together.
Hmm. After implementing a very simple overlay approach, I can now see
your point :) Yes in fact, that's a real problem.
The same issue could easily apply to I2C or SPI buses, chip selects, etc.
One solution would be to explicitly represent a connector or
connection-point in DT, such that the connector can implement the naming
of all signals that pass through it, and provide a translation point for
hooking the two DT fragments together. This seems within the spirit of DT.
Yes, but you still can't handle references that way.
Let me try and conclude this for others. Say the module tree A looks
something like this:
/ {
multi-regulator {
vcc1v8: regulator@0 {
/* ... */
};
};
};
... and the baseboard (B), that makes use of (and hence depends on)
the module, has something like this:
/ {
consumer {
main-supply = vcc1v8;
};
};
Now, let's say in a subsequent version of the module, we change whatever
provides that supply for 1.8 volts, but the consumer on the baseboard
shouldn't care much of course, thanks to all the abstraction layers that
we have now in the kernel.
However, the problem here is that I can't just compile trees A and B
individually into .dtbs that get merged later, because dtc will bail on
the unresolved reference of vcc1v8 of course. And cases like this are
the whole reason why I started to think about modularization of trees in
the first place.
So the simple overlay method doesn't help here at all, even though I can
share the code if anyone's interested.
Yes, you've understood me exactly.
The connector-base approach I was thinking about might look (very very)
roughly as follows:
main board:
/ {
multi-regulator {
vcc1v8: regulator@0 {
/* ... */
};
};
connector {
compatible = vendor,board-socket-a;
vcc1v8-supply = vcc1v8;
};
};
child board:
/ {
connector {
compatible = vendor,board-plug-a;
vcc1v8: regulator {
};
};
consumer {
main-supply = vcc1v8;
};
};
... which doesn't eally make the individual bits more readable.
... plus some logic so
Re: [U-Boot] Merging device trees at runtime for module-based systems
On 26.10.2012 02:53, David Gibson wrote: On Thu, Oct 25, 2012 at 10:46:32PM +0200, Wolfgang Denk wrote: Dear Daniel, In message 50893633.6070...@gmail.com you wrote: Overwrites must be addressed in the first place. The most common example is that a more generic part (the module tree) registers all details about a peripheral up-front but then sets its status to 'disabled'. That way, the more specific part (the base board tree) can overwrite this property to 'okay' at wish to enable it and not care for the pre-defined details. This is also how we do things in our device-trees. Agreed. I definitely can see the benefit of such a feature and would be happy if you could go forward and implement it. Ok then. I guess this should be something that can eventually be merged back into libfdt? I can't speak for the FDT custodian, but I think this makes a lot of sense. As a rule I'm happy to see more functionality for libfdt. I've only seen bits and pieces of this thread, though, so I'd need to see a summary of what exactly is being proposed. That's strange, as I copied you from the very first posting. Anyway, here's the archive: http://lists.denx.de/pipermail/u-boot/2012-October/138227.html I would especially like to know where such a new functionality should live, which data types it should operate on and what would be an appropriate name for it. Many thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Merging device trees at runtime for module-based systems
Hi Wolfgang, On 25.10.2012 14:44, Wolfgang Denk wrote: In message 5087b919.2010...@gmail.com you wrote: So let's say we have n versions of the baseboard and m versions of the module, we would much like to only prepare n + m files, instead of n * m by pre-compiling every possible combination (some of which may actually never occur 'in the wild'). What you are facing is a situation that 1) appears to be pretty common, and 2) has (AFAICT) not been truely satisfactory solved yet. So my question is: is it possible to do that kind of assembly of a number of files at runtime in U-Boot? I guess all it takes is merging a number of trees together, right? I browsed through the APIs but couldn't yet find an clear approach to that kind of problem. If not, what would it take to add that functionality? I can probably help with the implementation if someone tells me what would be the right way. I think it should be possible to overlay several DT images; ideally these would be strictly orthogonal, i. e. the newly loaded one would only add new properties, but I think it should be also no problem to define some latest-wins policy, i. e. in case of already existing properties the newly loaded ones would just overwrite the previous settings. Overwrites must be addressed in the first place. The most common example is that a more generic part (the module tree) registers all details about a peripheral up-front but then sets its status to 'disabled'. That way, the more specific part (the base board tree) can overwrite this property to 'okay' at wish to enable it and not care for the pre-defined details. This is also how we do things in our device-trees. I definitely can see the benefit of such a feature and would be happy if you could go forward and implement it. Ok then. I guess this should be something that can eventually be merged back into libfdt? Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Merging device trees at runtime for module-based systems
Hi, a project I'm involved in uses a module/baseboard combo, and components on either board are described in DT. I'm currently using separate dts files which build upon each other with include statements, which works fine for development. In production though, we will certainly have running changes (and hence different versions) over the lifetime of the product for both the baseboard and the module, and the hardware has support for identifying the versions of both sides at runtime. So let's say we have n versions of the baseboard and m versions of the module, we would much like to only prepare n + m files, instead of n * m by pre-compiling every possible combination (some of which may actually never occur 'in the wild'). So my question is: is it possible to do that kind of assembly of a number of files at runtime in U-Boot? I guess all it takes is merging a number of trees together, right? I browsed through the APIs but couldn't yet find an clear approach to that kind of problem. If not, what would it take to add that functionality? I can probably help with the implementation if someone tells me what would be the right way. Any pointer greatly appreciated. Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] OMAP I2C: fix handling of alen = 0
Allow raw I2C message transfers by setting the alen parameter to 0.
Currently, this doesn't work due to false assumptions to what is
appearantly considered a corner case.
With this patch applied, it is possible to send multibyte transfers
in one single transaction instead of using multiple STOP-bit-ommited
transfers.
Signed-off-by: Daniel Mack zon...@gmail.com
Cc: Dirk Behme dirk.be...@gmail.com
Cc: Igor Grinberg grinb...@compulab.co.il
Cc: Tom Rini tr...@ti.com
Cc: Steve Sakoman sako...@gmail.com
Cc: Michal Simek mon...@monstr.eu
Cc: Wolfgang Denk w...@denx.de
Cc: Tom Rix tom@windriver.com
---
On a OMAP3-based board, I needed raw I2C messages to configure
peripheral devices, and it turned out that the current omap-i2c
driver is not capable of send such due to assumption that are
made wrt register/payload data on the wire.
I couldn't figure who's best to take care for such a patch, so I
picked some people who have been working on this driver and
similar boards before.
Thanks for routing this in the right direction :)
drivers/i2c/omap24xx_i2c.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/omap24xx_i2c.c b/drivers/i2c/omap24xx_i2c.c
index f06af02..30914df 100644
--- a/drivers/i2c/omap24xx_i2c.c
+++ b/drivers/i2c/omap24xx_i2c.c
@@ -401,7 +401,7 @@ int i2c_write(uchar chip, uint addr, int alen, uchar
*buffer, int len)
i2c_error = 1;
if (!i2c_error) {
- if (status I2C_STAT_XRDY) {
+ if (status I2C_STAT_XRDY alen 0) {
switch (alen) {
#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
defined(CONFIG_AM33XX)
@@ -445,7 +445,7 @@ int i2c_write(uchar chip, uint addr, int alen, uchar
*buffer, int len)
i2c_error = 1;
if (!i2c_error) {
- for (i = ((alen 1) ? 0 : 1); i len; i++) {
+ for (i = ((alen == 1) ? 1 : 0); i len; i++) {
if (status I2C_STAT_XRDY) {
#if defined(CONFIG_OMAP243X) || defined(CONFIG_OMAP34XX) || \
defined(CONFIG_AM33XX)
--
1.7.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Toradex Colibri, PXA-270 (ARM)
Hello, i recently stumbled upon a compile-error which appears after trying to compile via /./MAKEALL --arch arm --cpu pxa --vendor toradex/ , it appears U-Boot uses software-FP whereas the native XScale-libs use hardware-FP, see for yourself please : /[dmack@Blizzard ~/workspace/u-boot]$ ./MAKEALL --arch arm --cpu pxa --vendor toradex/ /Configuring for colibri_pxa270 board.../ /arm-linux-ld: ERROR: /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_udivsi3.oS) uses hardware FP, whereas u-boot uses software FP/ /arm-linux-ld: failed to merge target specific data of file /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_udivsi3.oS)/ /arm-linux-ld: ERROR: /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_divsi3.oS) uses hardware FP, whereas u-boot uses software FP/ /arm-linux-ld: failed to merge target specific data of file /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_divsi3.oS)/ /arm-linux-ld: ERROR: /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_umodsi3.oS) uses hardware FP, whereas u-boot uses software FP/ /arm-linux-ld: failed to merge target specific data of file /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_umodsi3.oS)/ /arm-linux-ld: ERROR: /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_modsi3.oS) uses hardware FP, whereas u-boot uses software FP/ /arm-linux-ld: failed to merge target specific data of file /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_modsi3.oS)/ /arm-linux-ld: ERROR: /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_dvmd_lnx.oS) uses hardware FP, whereas u-boot uses software FP/ /arm-linux-ld: failed to merge target specific data of file /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_dvmd_lnx.oS)/ /arm-linux-ld: ERROR: /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_lshrdi3.oS) uses hardware FP, whereas u-boot uses software FP/ /arm-linux-ld: failed to merge target specific data of file /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_lshrdi3.oS)/ /arm-linux-ld: ERROR: /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_ashldi3.oS) uses hardware FP, whereas u-boot uses software FP/ /arm-linux-ld: failed to merge target specific data of file /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_ashldi3.oS)/ /arm-linux-ld: ERROR: /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_udivdi3.oS) uses hardware FP, whereas u-boot uses software FP/ /arm-linux-ld: failed to merge target specific data of file /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_udivdi3.oS)/ /arm-linux-ld: ERROR: /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_clz.oS) uses hardware FP, whereas u-boot uses software FP/ /arm-linux-ld: failed to merge target specific data of file /usr/lib/gcc/arm-xscale-linux-gnu/3.4.6/libgcc.a(_clz.oS)/ /make: *** [u-boot] Fehler 1/ /size: './u-boot': No such file/ /- SUMMARY / /Boards compiled: 1/ /Boards with warnings or errors: 1 ( colibri_pxa270 )/ /--/ Is there a solution for this, am i missing something? Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] part_dos: check status flags of partitions
ping?
On Mon, Sep 28, 2009 at 12:04:00PM +0200, Daniel Mack wrote:
The current fatload code has a problem together with the way the DOS
partition parser is implemented.
This hit me when I tried to load a file from a USB stick which had no
partition table but a FAT16 directly written to the first sector.
With such an environment, get_partition_info_extended() still finds a
valid partition at the first sector since the 0x55aa magic is valid for
both the MBR and the FAT boot sector.
As a result, part_offset in fs/fat/fat.c is then set to some ridiculous
value and the code searching for the directory entry gets lots in an
endless loop.
The fix is quite simple though - we just need to check the status field
of the partitions more stricly. According to the specs, it may only
contain 0x00 and 0x80. If get_partition_info() fails for this case, the
fatload code falls back to the assumption that there is no partition
table and does the right thing then.
Please consider applying the following patch.
Daniel
From 381a85bf04adc228cc70e8fa7af899a6dbf07e42 Mon Sep 17 00:00:00 2001
From: Daniel Mack dan...@caiaq.de
Date: Mon, 28 Sep 2009 11:40:38 +0200
Subject: [PATCH] part_dos: check status flags of partitions
Only read partitions which have 0x00 or 0x80 set in their status field.
All others are invalid.
Signed-off-by: Daniel Mack dan...@caiaq.de
---
disk/part_dos.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 93bf3dd..e32d58e 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -188,7 +188,8 @@ static int get_partition_info_extended (block_dev_desc_t
*dev_desc, int ext_part
* fdisk does not show the extended partitions that
* are not in the MBR
*/
- if ((pt-sys_ind != 0)
+ if (((pt-boot_ind ~0x80) == 0)
+ (pt-sys_ind != 0)
(part_num == which_part)
(is_extended(pt-sys_ind) == 0)) {
info-blksz = 512;
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] part_dos: check status flags of partitions
The current fatload code has a problem together with the way the DOS
partition parser is implemented.
This hit me when I tried to load a file from a USB stick which had no
partition table but a FAT16 directly written to the first sector.
With such an environment, get_partition_info_extended() still finds a
valid partition at the first sector since the 0x55aa magic is valid for
both the MBR and the FAT boot sector.
As a result, part_offset in fs/fat/fat.c is then set to some ridiculous
value and the code searching for the directory entry gets lots in an
endless loop.
The fix is quite simple though - we just need to check the status field
of the partitions more stricly. According to the specs, it may only
contain 0x00 and 0x80. If get_partition_info() fails for this case, the
fatload code falls back to the assumption that there is no partition
table and does the right thing then.
Please consider applying the following patch.
Daniel
From 381a85bf04adc228cc70e8fa7af899a6dbf07e42 Mon Sep 17 00:00:00 2001
From: Daniel Mack dan...@caiaq.de
Date: Mon, 28 Sep 2009 11:40:38 +0200
Subject: [PATCH] part_dos: check status flags of partitions
Only read partitions which have 0x00 or 0x80 set in their status field.
All others are invalid.
Signed-off-by: Daniel Mack dan...@caiaq.de
---
disk/part_dos.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/disk/part_dos.c b/disk/part_dos.c
index 93bf3dd..e32d58e 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -188,7 +188,8 @@ static int get_partition_info_extended (block_dev_desc_t
*dev_desc, int ext_part
* fdisk does not show the extended partitions that
* are not in the MBR
*/
- if ((pt-sys_ind != 0)
+ if (((pt-boot_ind ~0x80) == 0)
+ (pt-sys_ind != 0)
(part_num == which_part)
(is_extended(pt-sys_ind) == 0)) {
info-blksz = 512;
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] pxa: add clock for system bus 2 arbiter
ping? On Tue, Jun 23, 2009 at 05:30:04PM +0200, Daniel Mack wrote: From: Daniel Mack dan...@caiaq.de To: u-boot@lists.denx.de Cc: Daniel Mack dan...@caiaq.de Subject: [PATCH 1/2] pxa: add clock for system bus 2 arbiter Date: Tue, 23 Jun 2009 17:30:04 +0200 Message-Id: 1245771005-23299-1-git-send-email-dan...@caiaq.de X-Mailer: git-send-email 1.6.3.1 This clock is needed for systems using the USB2 device unit or the 2d graphics accelerator. Signed-off-by: Daniel Mack dan...@caiaq.de --- include/asm-arm/arch-pxa/pxa-regs.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/arch-pxa/pxa-regs.h b/include/asm-arm/arch-pxa/pxa-regs.h index 5a0885a..1f81e11 100644 --- a/include/asm-arm/arch-pxa/pxa-regs.h +++ b/include/asm-arm/arch-pxa/pxa-regs.h @@ -1952,6 +1952,7 @@ typedef void(*ExcpHndlr) (void) ; #define CKENA_2_USBHOST (1 2)/* USB Host Unit Clock Enable */ #define CKENA_1_LCD (1 1)/* LCD Unit Clock Enable */ +#define CKENB_9_SYSBUS2 (1 9)/* System bus 2 */ #define CKENB_8_1WIRE((1 8) + 32) /* One Wire Interface Unit Clock Enable */ #define CKENB_7_GPIO ((1 7) + 32) /* GPIO Clock Enable */ #define CKENB_6_IRQ ((1 6) + 32) /* Interrupt Controller Clock Enable */ -- 1.6.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] pxa: fix CKEN_B register bits
ping? On Tue, Jun 23, 2009 at 05:30:05PM +0200, Daniel Mack wrote: From: Daniel Mack dan...@caiaq.de To: u-boot@lists.denx.de Cc: Daniel Mack dan...@caiaq.de Subject: [PATCH 2/2] pxa: fix CKEN_B register bits Date: Tue, 23 Jun 2009 17:30:05 +0200 Message-Id: 1245771005-23299-2-git-send-email-dan...@caiaq.de X-Mailer: git-send-email 1.6.3.1 The current defition for CKEN_B register bits is nonsense. Adding 32 to the shifted value is equal to '| (1 5)', and this bit is marked 'reserved' in the PXA docs. Signed-off-by: Daniel Mack dan...@caiaq.de --- include/asm-arm/arch-pxa/pxa-regs.h | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/include/asm-arm/arch-pxa/pxa-regs.h b/include/asm-arm/arch-pxa/pxa-regs.h index 1f81e11..2a723dc 100644 --- a/include/asm-arm/arch-pxa/pxa-regs.h +++ b/include/asm-arm/arch-pxa/pxa-regs.h @@ -1953,12 +1953,12 @@ typedef void (*ExcpHndlr) (void) ; #define CKENA_1_LCD (1 1)/* LCD Unit Clock Enable */ #define CKENB_9_SYSBUS2 (1 9)/* System bus 2 */ -#define CKENB_8_1WIRE((1 8) + 32) /* One Wire Interface Unit Clock Enable */ -#define CKENB_7_GPIO ((1 7) + 32) /* GPIO Clock Enable */ -#define CKENB_6_IRQ ((1 6) + 32) /* Interrupt Controller Clock Enable */ -#define CKENB_4_I2C ((1 4) + 32) /* I2C Unit Clock Enable */ -#define CKENB_1_PWM1 ((1 1) + 32) /* PWM2 PWM3 Clock Enable */ -#define CKENB_0_PWM0 ((1 0) + 32) /* PWM0 PWM1 Clock Enable */ +#define CKENB_8_1WIRE(1 8)/* One Wire Interface Unit Clock Enable */ +#define CKENB_7_GPIO (1 7)/* GPIO Clock Enable */ +#define CKENB_6_IRQ (1 6)/* Interrupt Controller Clock Enable */ +#define CKENB_4_I2C (1 4)/* I2C Unit Clock Enable */ +#define CKENB_1_PWM1 (1 1)/* PWM2 PWM3 Clock Enable */ +#define CKENB_0_PWM0 (1 0)/* PWM0 PWM1 Clock Enable */ #else /* if defined CONFIG_CPU_MONAHANS */ -- 1.6.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] pxa: fix CKEN_B register bits
The current defition for CKEN_B register bits is nonsense. Adding 32 to the shifted value is equal to '| (1 5)', and this bit is marked 'reserved' in the PXA docs. Signed-off-by: Daniel Mack dan...@caiaq.de --- include/asm-arm/arch-pxa/pxa-regs.h | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/include/asm-arm/arch-pxa/pxa-regs.h b/include/asm-arm/arch-pxa/pxa-regs.h index 1f81e11..2a723dc 100644 --- a/include/asm-arm/arch-pxa/pxa-regs.h +++ b/include/asm-arm/arch-pxa/pxa-regs.h @@ -1953,12 +1953,12 @@ typedef void(*ExcpHndlr) (void) ; #define CKENA_1_LCD(1 1)/* LCD Unit Clock Enable */ #define CKENB_9_SYSBUS2(1 9)/* System bus 2 */ -#define CKENB_8_1WIRE ((1 8) + 32) /* One Wire Interface Unit Clock Enable */ -#define CKENB_7_GPIO ((1 7) + 32) /* GPIO Clock Enable */ -#define CKENB_6_IRQ((1 6) + 32) /* Interrupt Controller Clock Enable */ -#define CKENB_4_I2C((1 4) + 32) /* I2C Unit Clock Enable */ -#define CKENB_1_PWM1 ((1 1) + 32) /* PWM2 PWM3 Clock Enable */ -#define CKENB_0_PWM0 ((1 0) + 32) /* PWM0 PWM1 Clock Enable */ +#define CKENB_8_1WIRE (1 8)/* One Wire Interface Unit Clock Enable */ +#define CKENB_7_GPIO (1 7)/* GPIO Clock Enable */ +#define CKENB_6_IRQ(1 6)/* Interrupt Controller Clock Enable */ +#define CKENB_4_I2C(1 4)/* I2C Unit Clock Enable */ +#define CKENB_1_PWM1 (1 1)/* PWM2 PWM3 Clock Enable */ +#define CKENB_0_PWM0 (1 0)/* PWM0 PWM1 Clock Enable */ #else /* if defined CONFIG_CPU_MONAHANS */ -- 1.6.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] pxa: add clock for system bus 2 arbiter
This clock is needed for systems using the USB2 device unit or the 2d graphics accelerator. Signed-off-by: Daniel Mack dan...@caiaq.de --- include/asm-arm/arch-pxa/pxa-regs.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/arch-pxa/pxa-regs.h b/include/asm-arm/arch-pxa/pxa-regs.h index 5a0885a..1f81e11 100644 --- a/include/asm-arm/arch-pxa/pxa-regs.h +++ b/include/asm-arm/arch-pxa/pxa-regs.h @@ -1952,6 +1952,7 @@ typedef void (*ExcpHndlr) (void) ; #define CKENA_2_USBHOST(1 2)/* USB Host Unit Clock Enable */ #define CKENA_1_LCD(1 1)/* LCD Unit Clock Enable */ +#define CKENB_9_SYSBUS2(1 9)/* System bus 2 */ #define CKENB_8_1WIRE ((1 8) + 32) /* One Wire Interface Unit Clock Enable */ #define CKENB_7_GPIO ((1 7) + 32) /* GPIO Clock Enable */ #define CKENB_6_IRQ((1 6) + 32) /* Interrupt Controller Clock Enable */ -- 1.6.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] Add generic bit operations
On Fri, Jun 05, 2009 at 10:44:21PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: This adds generic bit operations for all platforms and enables includes the implementations from asm-arm. Code taken from Linux kernel. the __set_bit, __clear_bit, __change_bit co generic is used on arm ok Do you mean it worked before? Or are you referring to the version I posted which you think is ok? but be aware that we use it in U-Boot so NACK You use what? The functions I removed? I doubt that. The functions marked 'external' have no implementation, and I also don't believe the static inlines did the right thing (note the shift operations). and please do not rename __xxx by xxx they do not mean the same think the __xxx can be re-ordered and the xxx not Sorry, I don't get it - what's your point about the status quo in the sources and about the patches? Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UBI on NAND flash again
On Thu, Jun 04, 2009 at 08:42:40AM +0200, Stefan Roese wrote: defaults: mtdids : nand0=nand0 mtdparts: mtdparts=nand0:512k(u-boot),128k(env),384k(splash),3M(kernel),-(ubilayer) $ ubi part ubilayer Creating 1 MTD partitions on nand0: 0x0040-0x0800 : mtd=4 UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size:126976 bytes UBI: smallest flash I/O unit:2048 UBI: VID header offset: 2048 (aligned 2048) UBI: data offset:4096 UBI error: ubi_init: cannot attach mtd1 UBI error: ubi_init: UBI error: cannot initialize UBI, error -12 UBI init error -12 exit not allowed from main input shell. Did you erase the FLASH partition? If not please try again after erasing. I used ubiformat from Linux using /dev/ubi0 which is attached to /dev/mtd4 which again points to the same area in the flash than 'ubilayer' does in U-Boot. So I should be able to access that same volume from the bootloader, right? Or do I miss some important point? Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UBI on NAND flash again
On Thu, Jun 04, 2009 at 10:15:30AM +0200, Stefan Roese wrote: Hmm. That still doesn't work for me, and I still wonder about the 'attaching mtd1 to ubi0' string, which looks like a mismatch to me. I would have to check in more details here. But I'm pretty sure this is not the reason for your failure. Here a log from one of mine UBI systems: Oh well - you're right. The code failed in vmalloc() due to a too small CONFIG_SYS_MALLOC_LEN which I needed to augment to 512kB. The 'mtd1' totally mislead me. Sorry for the noise, and thanks for your help :) Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UBI on NAND flash again
On Thu, Jun 04, 2009 at 11:27:07AM +0200, Wolfgang Denk wrote: Oh well - you're right. The code failed in vmalloc() due to a too small CONFIG_SYS_MALLOC_LEN which I needed to augment to 512kB. But then a big, fat error message is needed there! In vmalloc(), yes. That bug could hit any code that deals with dynamically allocated memory. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] (no subject)
The following patch series is needed to build U-Boot for ARM platforms with CONFIG_CMD_UBIFS set. The UBIFS layer uses bit operation functions which are currently only implemented for PPC, and the ARM bit operation definitions are unused and wrong. [PATCH 1/3] ARM: remove unused bit operations [PATCH 2/3] Add generic bit operations [PATCH 3/3] ARM: add unaligned macros ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] ARM: remove unused bit operations
Remove include/asm-arm/bitops.h a bunch of 'external' marked functions
from include/asm-arm/bitops.h. They are not implemented anywhere in the
sources, so this forward declaration is wrong.
Also remove the functions __set_bit, __clear_bit, __change_bit,
__test_and_set_bit, __test_and_clear_bit and __test_and_change_bit.
All these functions can be implemented in a generic fashion which will
be done in the next patch.
Signed-off-by: Daniel Mack dan...@caiaq.de
---
include/asm-arm/bitops.h | 70 --
1 files changed, 0 insertions(+), 70 deletions(-)
diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
index 4b8bab2..3ffd4d5 100644
--- a/include/asm-arm/bitops.h
+++ b/include/asm-arm/bitops.h
@@ -20,76 +20,6 @@
#define smp_mb__before_clear_bit() do { } while (0)
#define smp_mb__after_clear_bit() do { } while (0)
-/*
- * Function prototypes to keep gcc -Wall happy.
- */
-extern void set_bit(int nr, volatile void * addr);
-
-static inline void __set_bit(int nr, volatile void *addr)
-{
- ((unsigned char *) addr)[nr 3] |= (1U (nr 7));
-}
-
-extern void clear_bit(int nr, volatile void * addr);
-
-static inline void __clear_bit(int nr, volatile void *addr)
-{
- ((unsigned char *) addr)[nr 3] = ~(1U (nr 7));
-}
-
-extern void change_bit(int nr, volatile void * addr);
-
-static inline void __change_bit(int nr, volatile void *addr)
-{
- ((unsigned char *) addr)[nr 3] ^= (1U (nr 7));
-}
-
-extern int test_and_set_bit(int nr, volatile void * addr);
-
-static inline int __test_and_set_bit(int nr, volatile void *addr)
-{
- unsigned int mask = 1 (nr 7);
- unsigned int oldval;
-
- oldval = ((unsigned char *) addr)[nr 3];
- ((unsigned char *) addr)[nr 3] = oldval | mask;
- return oldval mask;
-}
-
-extern int test_and_clear_bit(int nr, volatile void * addr);
-
-static inline int __test_and_clear_bit(int nr, volatile void *addr)
-{
- unsigned int mask = 1 (nr 7);
- unsigned int oldval;
-
- oldval = ((unsigned char *) addr)[nr 3];
- ((unsigned char *) addr)[nr 3] = oldval ~mask;
- return oldval mask;
-}
-
-extern int test_and_change_bit(int nr, volatile void * addr);
-
-static inline int __test_and_change_bit(int nr, volatile void *addr)
-{
- unsigned int mask = 1 (nr 7);
- unsigned int oldval;
-
- oldval = ((unsigned char *) addr)[nr 3];
- ((unsigned char *) addr)[nr 3] = oldval ^ mask;
- return oldval mask;
-}
-
-extern int find_first_zero_bit(void * addr, unsigned size);
-extern int find_next_zero_bit(void * addr, int size, int offset);
-
-/*
- * This routine doesn't need to be atomic.
- */
-static inline int test_bit(int nr, const void * addr)
-{
-return ((unsigned char *) addr)[nr 3] (1U (nr 7));
-}
/*
* ffz = Find First Zero in word. Undefined if no zero exists,
--
1.6.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] ARM: add unaligned macros
Signed-off-by: Daniel Mack dan...@caiaq.de --- include/asm-arm/unaligned.h | 14 ++ 1 files changed, 14 insertions(+), 0 deletions(-) create mode 100644 include/asm-arm/unaligned.h diff --git a/include/asm-arm/unaligned.h b/include/asm-arm/unaligned.h new file mode 100644 index 000..dd7d852 --- /dev/null +++ b/include/asm-arm/unaligned.h @@ -0,0 +1,14 @@ +#ifndef _ASM_ARM_UNALIGNED_H +#define _ASM_ARM_UNALIGNED_H + +#ifdef __KERNEL__ + +#include linux/unaligned/access_ok.h +#include linux/unaligned/generic.h + +#define get_unaligned __get_unaligned_le +#define put_unaligned __put_unaligned_le + +#endif /* __KERNEL__ */ +#endif /* _ASM_ARM_UNALIGNED_H */ + -- 1.6.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] Add generic bit operations
This adds generic bit operations for all platforms and enables includes
the implementations from asm-arm.
Code taken from Linux kernel.
Signed-off-by: Daniel Mack dan...@caiaq.de
---
include/asm-arm/bitops.h |2 +
include/asm-generic/bitops.h | 151 ++
2 files changed, 153 insertions(+), 0 deletions(-)
create mode 100644 include/asm-generic/bitops.h
diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
index 3ffd4d5..97abea6 100644
--- a/include/asm-arm/bitops.h
+++ b/include/asm-arm/bitops.h
@@ -15,6 +15,8 @@
#ifndef __ASM_ARM_BITOPS_H
#define __ASM_ARM_BITOPS_H
+#include asm-generic/bitops.h
+
#ifdef __KERNEL__
#define smp_mb__before_clear_bit() do { } while (0)
diff --git a/include/asm-generic/bitops.h b/include/asm-generic/bitops.h
new file mode 100644
index 000..088e5da
--- /dev/null
+++ b/include/asm-generic/bitops.h
@@ -0,0 +1,151 @@
+#ifndef _ASM_GENERIC_BITOPS_H_
+#define _ASM_GENERIC_BITOPS_H_
+
+#include asm/types.h
+
+#define BIT(nr)(1UL (nr))
+#define BIT_MASK(nr) (1UL ((nr) % BITS_PER_LONG))
+#define BIT_WORD(nr) ((nr) / BITS_PER_LONG)
+#define BITS_PER_BYTE 8
+#define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long))
+
+/**
+ * set_bit - Set a bit in memory
+ * @nr: the bit to set
+ * @addr: the address to start counting from
+ *
+ * Unlike set_bit(), this function is non-atomic and may be reordered.
+ * If it's called on the same region of memory simultaneously, the effect
+ * may be that only one operation succeeds.
+ */
+static inline void set_bit(int nr, volatile unsigned long *addr)
+{
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+
+ *p |= mask;
+}
+
+static inline void clear_bit(int nr, volatile unsigned long *addr)
+{
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+
+ *p = ~mask;
+}
+
+/**
+ * change_bit - Toggle a bit in memory
+ * @nr: the bit to change
+ * @addr: the address to start counting from
+ *
+ * Unlike change_bit(), this function is non-atomic and may be reordered.
+ * If it's called on the same region of memory simultaneously, the effect
+ * may be that only one operation succeeds.
+ */
+static inline void change_bit(int nr, volatile unsigned long *addr)
+{
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+
+ *p ^= mask;
+}
+
+/**
+ * test_and_set_bit - Set a bit and return its old value
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail. You must protect multiple accesses with a lock.
+ */
+static inline int test_and_set_bit(int nr, volatile unsigned long *addr)
+{
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+ unsigned long old = *p;
+
+ *p = old | mask;
+ return (old mask) != 0;
+}
+
+/**
+ * test_and_clear_bit - Clear a bit and return its old value
+ * @nr: Bit to clear
+ * @addr: Address to count from
+ *
+ * This operation is non-atomic and can be reordered.
+ * If two examples of this operation race, one can appear to succeed
+ * but actually fail. You must protect multiple accesses with a lock.
+ */
+static inline int test_and_clear_bit(int nr, volatile unsigned long *addr)
+{
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+ unsigned long old = *p;
+
+ *p = old ~mask;
+ return (old mask) != 0;
+}
+
+/* WARNING: non atomic and it can be reordered! */
+static inline int test_and_change_bit(int nr,
+ volatile unsigned long *addr)
+{
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+ unsigned long old = *p;
+
+ *p = old ^ mask;
+ return (old mask) != 0;
+}
+
+/**
+ * test_bit - Determine whether a bit is set
+ * @nr: bit number to test
+ * @addr: Address to start counting from
+ */
+static inline int test_bit(int nr, const volatile unsigned long *addr)
+{
+ return 1UL (addr[BIT_WORD(nr)] (nr (BITS_PER_LONG-1)));
+}
+
+/**
+ * fls - find last (most-significant) bit set
+ * @x: the word to search
+ *
+ * This is defined the same way as ffs.
+ * Note fls(0) = 0, fls(1) = 1, fls(0x8000) = 32.
+ */
+
+static inline int fls(int x)
+{
+ int r = 32;
+
+ if (!x)
+ return 0;
+ if (!(x 0xu)) {
+ x = 16;
+ r -= 16;
+ }
+ if (!(x 0xff00u)) {
+ x = 8;
+ r -= 8;
+ }
+ if (!(x 0xf000u)) {
+ x = 4;
+ r -= 4
Re: [U-Boot] [PATCH 2/3] Add generic bit operations
On Thu, Jun 04, 2009 at 01:45:22PM +0200, Wolfgang Denk wrote: +#define BIT(nr)(1UL (nr)) +#define BIT_MASK(nr) (1UL ((nr) % BITS_PER_LONG)) +#define BIT_WORD(nr) ((nr) / BITS_PER_LONG) +#define BITS_PER_BYTE 8 +#define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long)) You see, this is plain wrong on PowerPC. On PowerPC, bit number 0 is the most significant bit, not the least significant one as you assume here. So using this well-intended code on a PowerPC system will most likely get you in trouble. Well, the idea is to let those platforms use the generic operations that do not bring their owm ones. The code above is not on use by PPC, so it doesn't harm either. [And you cannot even use a generic definition for PowerPC, as some- thing like #define BIT(nr) (0x8000 (nr)) will only work on 32 bit systems but be wrong on 64 bit ones.] That is why PPC implements that in its own fashion. Fair enough. Let's get rid of this stuff, it is confusing. Hmm, and how? Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] Add generic bit operations
On Thu, Jun 04, 2009 at 01:47:17PM +0200, Wolfgang Denk wrote:
+static inline void clear_bit(int nr, volatile unsigned long *addr)
+{
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+
+ *p = ~mask;
+}
Such code has no chance of being accepted anyway.
It tries to be generic and does not care if you use it on memory or
device addresses - but for device addresses, the use of proper I/O
accessor functions is mandatory.
And the functions I removed from asm-arm/bitops.h did that?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ARM: add unaligned macros
On Thu, Jun 04, 2009 at 12:27:21PM +0200, Daniel Mack wrote:
---
include/asm-arm/unaligned.h | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
create mode 100644 include/asm-arm/unaligned.h
This one was too easy, updated patch below.
With that one applied, the lzo1x decompressor and the whole ubifs works
fine on an ARM PXA3xx.
Daniel
From 827de3c735a829de64a07467e7d10c07299cfe04 Mon Sep 17 00:00:00 2001
From: Daniel Mack dan...@caiaq.de
Date: Thu, 4 Jun 2009 12:19:52 +0200
Subject: [PATCH] ARM: add unaligned macros
Unaligned data access is evil on ARMs, especially when no magic foo like
Linux' traps clean up after us, hence choose the 'packed struct' way.
Signed-off-by: Daniel Mack dan...@caiaq.de
---
include/asm-arm/unaligned.h | 14 ++
include/linux/unaligned/le_struct.h | 36 +
include/linux/unaligned/packed_struct.h | 44 +++
3 files changed, 94 insertions(+), 0 deletions(-)
create mode 100644 include/asm-arm/unaligned.h
create mode 100644 include/linux/unaligned/le_struct.h
create mode 100644 include/linux/unaligned/packed_struct.h
diff --git a/include/asm-arm/unaligned.h b/include/asm-arm/unaligned.h
new file mode 100644
index 000..569db55
--- /dev/null
+++ b/include/asm-arm/unaligned.h
@@ -0,0 +1,14 @@
+#ifndef _ASM_ARM_UNALIGNED_H
+#define _ASM_ARM_UNALIGNED_H
+
+#ifdef __KERNEL__
+
+#include linux/unaligned/le_struct.h
+#include linux/unaligned/generic.h
+
+#define get_unaligned __get_unaligned_le
+#define put_unaligned __put_unaligned_le
+
+#endif /* __KERNEL__ */
+#endif /* _ASM_ARM_UNALIGNED_H */
+
diff --git a/include/linux/unaligned/le_struct.h
b/include/linux/unaligned/le_struct.h
new file mode 100644
index 000..088c457
--- /dev/null
+++ b/include/linux/unaligned/le_struct.h
@@ -0,0 +1,36 @@
+#ifndef _LINUX_UNALIGNED_LE_STRUCT_H
+#define _LINUX_UNALIGNED_LE_STRUCT_H
+
+#include linux/unaligned/packed_struct.h
+
+static inline u16 get_unaligned_le16(const void *p)
+{
+ return __get_unaligned_cpu16((const u8 *)p);
+}
+
+static inline u32 get_unaligned_le32(const void *p)
+{
+ return __get_unaligned_cpu32((const u8 *)p);
+}
+
+static inline u64 get_unaligned_le64(const void *p)
+{
+ return __get_unaligned_cpu64((const u8 *)p);
+}
+
+static inline void put_unaligned_le16(u16 val, void *p)
+{
+ __put_unaligned_cpu16(val, p);
+}
+
+static inline void put_unaligned_le32(u32 val, void *p)
+{
+ __put_unaligned_cpu32(val, p);
+}
+
+static inline void put_unaligned_le64(u64 val, void *p)
+{
+ __put_unaligned_cpu64(val, p);
+}
+
+#endif /* _LINUX_UNALIGNED_LE_STRUCT_H */
diff --git a/include/linux/unaligned/packed_struct.h
b/include/linux/unaligned/packed_struct.h
new file mode 100644
index 000..5034257
--- /dev/null
+++ b/include/linux/unaligned/packed_struct.h
@@ -0,0 +1,44 @@
+#ifndef _LINUX_UNALIGNED_PACKED_STRUCT_H
+#define _LINUX_UNALIGNED_PACKED_STRUCT_H
+
+struct __una_u16 { u16 x __attribute__((packed)); } __attribute__((packed));
+struct __una_u32 { u32 x __attribute__((packed)); } __attribute__((packed));
+struct __una_u64 { u64 x __attribute__((packed)); } __attribute__((packed));
+
+static inline u16 __get_unaligned_cpu16(const void *p)
+{
+ const struct __una_u16 *ptr = (const struct __una_u16 *)p;
+ return ptr-x;
+}
+
+static inline u32 __get_unaligned_cpu32(const void *p)
+{
+ const struct __una_u32 *ptr = (const struct __una_u32 *)p;
+ return ptr-x;
+}
+
+static inline u64 __get_unaligned_cpu64(const void *p)
+{
+ const struct __una_u64 *ptr = (const struct __una_u64 *)p;
+ return ptr-x;
+}
+
+static inline void __put_unaligned_cpu16(u16 val, void *p)
+{
+ struct __una_u16 *ptr = (struct __una_u16 *)p;
+ ptr-x = val;
+}
+
+static inline void __put_unaligned_cpu32(u32 val, void *p)
+{
+ struct __una_u32 *ptr = (struct __una_u32 *)p;
+ ptr-x = val;
+}
+
+static inline void __put_unaligned_cpu64(u64 val, void *p)
+{
+ struct __una_u64 *ptr = (struct __una_u64 *)p;
+ ptr-x = val;
+}
+
+#endif /* _LINUX_UNALIGNED_PACKED_STRUCT_H */
--
1.6.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] Add generic bit operations
On Thu, Jun 04, 2009 at 01:59:22PM +0200, Wolfgang Denk wrote: And the functions I removed from asm-arm/bitops.h did that? No. Let's be happy that we have eliminated some poor code, and if we add a replacement, let's make sure not to repeat the mistakes of the past again. Ok. I just saw ubifs implementing its own set_bit() functions and considered that the wrong place for such functions to live in. ext2 seems to do the same things, also minix. Platforms which want to enable support for these filesystems have to do an evil #define to map ext2_set_bit() to the platform specific version. Which is all bogus, you might agree. And because of that situation, ubifs can't currently build for anything else than ppc (according to 'git grep -w fls include/asm*'). Hence I thought it might be a good idea (or at least a good start thereof) to put the functions where I believe they belong to - a 'generic' place. Anyway - applying the first patch of this series would at least prevent others from being mislead by dead and wrong code. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] ARM: add unaligned macros
On Thu, Jun 04, 2009 at 09:03:47PM +0200, Wolfgang Denk wrote:
+static inline u16 get_unaligned_le16(const void *p)
+{
+ return __get_unaligned_cpu16((const u8 *)p);
+}
+
+static inline u32 get_unaligned_le32(const void *p)
+{
+ return __get_unaligned_cpu32((const u8 *)p);
+}
+
+static inline u64 get_unaligned_le64(const void *p)
+{
+ return __get_unaligned_cpu64((const u8 *)p);
+}
Are these 3 really all u8 pointers, or is this a copy paste error?
Yes, this is how it came from the Linux kernel and my tests show that
these access methods work well.
Is there any guarantee that such macros are never used on device
registers and the like?
Well - how can I guarantee that? Anyway - the functions can be enhanced
later to make them work with different types of memories. For now, they
implement a working set of functions to allow ubifs (and probably other
code as well) to be compiled and ran on ARMs.
Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] UBI on NAND flash again
I know there has been some traffic regaring the UBI layer recently, however, reading the conversations didn't solve the issue I'm facing. With a current U-Boot (git as of today) and 128MB NAND flash on a PXA303, I get the following: $ mtdparts device nand0 nand0, # parts = 5 #: namesizeoffset mask_flags 0: u-boot 0x0008 0x 0 1: env 0x0002 0x0008 0 2: splash 0x0006 0x000a 0 3: kernel 0x0030 0x0010 0 4: ubilayer0x07c0 0x0040 0 active partition: nand0,0 - (u-boot) 0x0008 @ 0x defaults: mtdids : nand0=nand0 mtdparts: mtdparts=nand0:512k(u-boot),128k(env),384k(splash),3M(kernel),-(ubilayer) $ ubi part ubilayer Creating 1 MTD partitions on nand0: 0x0040-0x0800 : mtd=4 UBI: attaching mtd1 to ubi0 UBI: physical eraseblock size: 131072 bytes (128 KiB) UBI: logical eraseblock size:126976 bytes UBI: smallest flash I/O unit:2048 UBI: VID header offset: 2048 (aligned 2048) UBI: data offset:4096 UBI error: ubi_init: cannot attach mtd1 UBI error: ubi_init: UBI error: cannot initialize UBI, error -12 UBI init error -12 exit not allowed from main input shell. What puzzles me is this 'UBI: attaching mtd1 to ubi0' - shouldn't that be 'mtd4'? The same layout works well under Linux, btw. Any hints? Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: unbreak PXA build by defining UP2OCR
On Thu, May 07, 2009 at 11:02:34PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote: Can you please run a git show 24e37645 again? To me it seems that this commit - removed the usage of UP2OCR from board/delta/delta.c but also - added the usage of UP2OCR to the new file cpu/pxa/usb.c without defining it. So the comment seems absolutely correct to me. Maybe I'm missing something? It's me I mix the commit this commit 3ccbfb25f48a:Support for PXA27X UDC. brake the pxa support by removing the UP2OCR I was just running 'git blame' on the file that broke the build and pointed out the commit that added the line that made the trouble. I don't see what shouldn't be correct about that? Anyway, feel free to change the commit log if you like, I don't care. Most important thing is that things get fixed. Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: unbreak PXA build by defining UP2OCR
On Tue, May 05, 2009 at 12:58:57AM +0200, Wolfgang Denk wrote: the usb driver use the same file for supporting all the PXA and as it's store in a generic header. We must define the register only the specific pxa version and when the same register could mean differents things depending the pxa version That's the theory. Praxis is that we have a bug, and we need a fix. And we seem to have one. Correct. It does not build anymore. Another possibility is to revert the commit which caused the trouble and make Markus Klotzbuecher fix it in a way Jean-Christophe PLAGNIOL-VILLARD likes. - how many PXA platforms with USB support do we have? That's not the point. I for myself won't bring my board support into U-Boot's mainline (at least not now) because that would help nobody as nobody except for me has the hardware the code was written for. And I guess I'm not the only one. IMO hings should compile, even when the config for this is not in your repository; hope you agree. In other words - is your concern a real problem, or just a theoretical one? Code using that macro is guarded by MONAHANS #ifdefs anyway, his point is solely not to have it in the register headers. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: unbreak PXA build by defining UP2OCR
On Tue, May 05, 2009 at 12:28:33PM +0200, Wolfgang Denk wrote: That's not the point. I for myself won't bring my board support into U-Boot's mainline (at least not now) because that would help nobody as nobody except for me has the hardware the code was written for. And I guess I'm not the only one. Well, that is your decision. But if you chose your place intentionally outside the community that you should not be surprised if you only receive pretty limited support from that community either. Well, I was just talking about the config itself - I _do_ merge everything else upstream. IMO hings should compile, even when the config for this is not in your repository; hope you agree. No, I disagree. I don't care at all about any out-of-tree ports that might exist anywhere. I will not waste any thoughts about the eventual possibility that changes to the mainline U-Boot code might cause problems in such out-of-tree ports. That's not our problem. What we're facing here is a clear build breakage that occurs in a combination of valid configuration flags. It's not an out-of-tree port. I was just reporting that in order to help other who might face a similar problem. In other words - is your concern a real problem, or just a theoretical one? Code using that macro is guarded by MONAHANS #ifdefs anyway, his point is solely not to have it in the register headers. ...where it could be protected by a similar #ifdef, so I really don't see where the problem is. Me neither. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: unbreak PXA build by defining UP2OCR
U-Boot does not currently build for PXA platforms with USB support enabled. This is due to commit 24e37645e7378b20fa8f20e2996c8fb8e9 which introduced the usage of UP2OCR without defining it. Signed-off-by: Daniel Mack dan...@caiaq.de Cc: Markus Klotzbuecher m...@denx.de --- include/asm-arm/arch-pxa/pxa-regs.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/arch-pxa/pxa-regs.h b/include/asm-arm/arch-pxa/pxa-regs.h index a8d30e2..5a0885a 100644 --- a/include/asm-arm/arch-pxa/pxa-regs.h +++ b/include/asm-arm/arch-pxa/pxa-regs.h @@ -992,6 +992,10 @@ typedef void (*ExcpHndlr) (void) ; #define UHCHIE __REG(0x4C68) #define UHCHIT __REG(0x4C6C) +#if defined(CONFIG_CPU_MONAHANS) +#define UP2OCR __REG(0x40600020) +#endif + #define UHCHR_FSBIR(10) #define UHCHR_FHR (11) #define UHCHR_CGR (12) -- 1.6.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Toradex board with Colibri PXA270
On Tue, Apr 28, 2009 at 11:37:14AM +0200, Daniel Stenberg wrote: I'm currently working with a Toradex board featuring a Colibri PXA270 module, and I noticed this attempt to get a Colibri PXA270 patch applied http://lists.denx.de/pipermail/u-boot/2009-April/050634.html ... which seems it didn't get anywhere further than so. The conclusion, or should I say request, from there was to make more parts re-used within the source tree to reduce code duplication and I can only agree with that. Seeing that this is a PXA(270) equipped board, wouldn't it make sense to do some of the low level init etc stuff in the cpu-specific area (cpu/pxa/) ? The entire gpio handling (and similar) is after all common for all PXA270 isn't it? So, is there anyone with more specific thoughts or opinions on this? What can I do to push this forward to the next level? In case you do that, please call the board 'colibri-pxa270' in folder and config file names, not just 'colibri' like in the version you referred to above. There are versions of that modules with pxa3[012]0 CPUs which are entirely different and need extra care. I submitted a patch to support that module 1,5 years ago - if you miss some pieces, you might have a look here: http://lists.denx.de/pipermail/u-boot/2007-November/026890.html Bringing this in shape is a good idea, though. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] smc911x: do net reset the chip if no EEPROM is connected
On Sun, Apr 26, 2009 at 11:14:06PM -0400, Mike Frysinger wrote: On Tuesday 21 April 2009 07:13:10 Daniel Mack wrote: On Wed, Apr 08, 2009 at 11:57:37PM -0400, Mike Frysinger wrote: Not if the MAC is stored in the volatile smc911x registers. Issuing a soft reset flushes these values - if U-Boot does that, the OS has no change getting them. then either your u-boot or your OS is misconfigured and you need to fix that. as clearly stated in docs/README.enetaddr, the environment is the place where mac addresses live when there is no dedicated storage (like an eeprom). ignoring that, the mac address doesnt magically get programmed. if no network operation was initiated, then the part wouldnt have been programmed anyways, so you're still left with an OS that cant get itself functional. Ok, true. Thanks for pointing this out. usually what i suggest to people are things like: - pass $(ethaddr) via kernel command line and parse /proc/cmdline - use the u-boot tools to read the u-boot env directly - set the hw address with `ifconfig` or similar tool ... which doesn't help much when it's about booting from NFS root. The particular problem here is that the MAC changes from what it's set to in U-Boot during the TFTP transaction and the randomly chosen one in Linux (which takes place because after the reset, the MAC is all 0xff). And that in turn confuses the ARP caches on other hosts. My patch solves that issue for that very case; that's why it's still in my local tree. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot memory dump
On Sat, Apr 25, 2009 at 11:41:43AM -0500, alfred steele wrote: I am using uboot on the MX31 PDk board. I am trying to dump the contents of a status register found at location 50004004. This status register shows the status of the SDHC( SD card host controller) like interrupt , card insertion, card removal etc. According to the MX31 manual, the status register i.e the contents at the corresponding memory location should change on events like card insertion and removal. But the contents aren't changing as expected. I have verified this with Linux and it works. The difference is most probably that under Linux, your IOMUX is set up correctly. IOW, the CPU does not see any external peripherals unless you enable the pins for the specific function you're trying to use. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling smc911x driver
On Wed, Apr 22, 2009 at 09:20:15PM -0700, Steve Sakoman wrote: Files longer that 544 bytes result in a timeout error: Overo # tftp test.txt smc911x: initializing smc911x: detected LAN9221 controller smc911x: phy initialized smc911x: MAC aa:bb:cc:dd:ee:ff TFTP from server 192.168.0.210; our IP address is 192.168.0.223 Filename 'test.txt'. Load address: 0x8200 Loading: T T T T T T T T T T Retry count exceeded; starting again Any ideas what might be going wrong here? Hmm. I had a similar issue a while ago and the reason was that on PXA3xx CPUs, the timer register behaved differently than on PXA2xxs and that was never tested. In fact, it was counting magnitudes faster there which made the network code bail out way to early. This was fixed for the platform I'm working with, but maybe you got a similar problem. Other than that, there might be something weird with your network. I'd suggest running wireshark on some host on that LAN and have a close look on the packets. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting uImage on the mx31
On Thu, Apr 23, 2009 at 09:20:41AM -0500, alfred steele wrote: Any hints? I hope with, 0x80008000 as the load address on the MX31, you eliminate the cause of one probable failure, overlay memory with the existing code on RAM e.g. existing u-boot and the compressed kernel image mc911x: MAC 92:92:92:bb:bb:bb TFTP from server 206.44.18.25; our IP address is 206.44.18.31 Filename 'uImage_spin2'. Load address: 0x8080 Loading: # # done Bytes transferred = 1665060 (196824 hex) ## Booting kernel from Legacy Image at 8080 ... Image Name: Linux-2.6.24-140-g68eb4b4 Created: 2009-04-23 3:28:44 UTC Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1664996 Bytes = 1.6 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux. ... done, booting the kernel. See http://lists.arm.linux.org.uk/lurker/message/20081210.174754.29691349.en.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling smc911x driver
On Wed, Apr 22, 2009 at 07:52:40AM -0700, Steve Sakoman wrote: Now things seem to initialize properly: U-Boot 2009.03 (Apr 22 2009 - 07:28:04) OMAP3503-GP rev 2, CPU-OPP2 L3-165MHz Gumstix Overo board + LPDDR/NAND DRAM: 256 MB NAND: 256 MiB In:serial Out: serial Err: serial Initializing ethernet smc911x smc911x: initializing smc911x: detected LAN9221 controller smc911x: phy initialized smc911x: MAC 4a:18:56:55:9d:38 How did you set this MAC address? Does the hardware read it from a connected EEPROM or did you manually set it in your environment. If you face the latter case, you could try applying the patch I sent in some days ago. Without that patch, the hardware is not made aware of the configured address and hence the internal filter will drop all non-broadcast packets it receives. With this patch applied, however, the LAN9220 chip works well on our own PXA design. Maybe that helps. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] smc911x: write back the manually set MAC address
On Wed, Apr 08, 2009 at 01:23:37PM +0200, Daniel Mack wrote:
Signed-off-by: Daniel Mack dan...@caiaq.de
Cc: Sascha Hauer s.ha...@pengutronix.de
ping.
---
drivers/net/smc911x.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 30f2dc2..8c9a2a8 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -41,8 +41,13 @@ static int smx911x_handle_mac_address(bd_t *bd)
unsigned long addrh, addrl;
uchar m[6];
- /* if the environment has a valid mac address then use it */
- if (!eth_getenv_enetaddr(ethaddr, m)) {
+ if (eth_getenv_enetaddr(ethaddr, m)) {
+ /* if the environment has a valid mac address then use it */
+ addrl = m[0] | (m[1] 8) | (m[2] 16) | (m[3] 24);
+ addrh = m[4] | (m[5] 8);
+ smc911x_set_mac_csr(ADDRL, addrl);
+ smc911x_set_mac_csr(ADDRH, addrh);
+ } else {
/* if not, try to get one from the eeprom */
addrh = smc911x_get_mac_csr(ADDRH);
addrl = smc911x_get_mac_csr(ADDRL);
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] smc911x: do net reset the chip if no EEPROM is connected
On Wed, Apr 08, 2009 at 11:57:37PM -0400, Mike Frysinger wrote: Not if the MAC is stored in the volatile smc911x registers. Issuing a soft reset flushes these values - if U-Boot does that, the OS has no change getting them. then either your u-boot or your OS is misconfigured and you need to fix that. as clearly stated in docs/README.enetaddr, the environment is the place where mac addresses live when there is no dedicated storage (like an eeprom). ignoring that, the mac address doesnt magically get programmed. if no network operation was initiated, then the part wouldnt have been programmed anyways, so you're still left with an OS that cant get itself functional. Ok, true. Thanks for pointing this out. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] smc911x: write back the manually set MAC address
Hi Sascha, On Tue, Apr 21, 2009 at 01:38:23PM +0200, Sascha Hauer wrote: On Wed, Apr 08, 2009 at 01:23:37PM +0200, Daniel Mack wrote: If the MAX address is given by the environment, write it back to the hardware. Signed-off-by: Daniel Mack dan...@caiaq.de Cc: Sascha Hauer s.ha...@pengutronix.de Acked-by: Sascha Hauer s.ha...@pengutronix.de Anyway, you shouldn't rely on this. I'm the original author of this driver, but I do not use U-Boot-v1 anymore, so I can't tell if this breaks something or not. No problem. I just Cc'ed all email addresses I could find in the code. Who will pick that one and the one regarding support for the 9220 controller for mainline? Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] smc911x: write back the manually set MAC address
On Tue, Apr 21, 2009 at 06:28:34AM -0700, Ben Warren wrote: Anyway, you shouldn't rely on this. I'm the original author of this driver, but I do not use U-Boot-v1 anymore, so I can't tell if this breaks something or not. No problem. I just Cc'ed all email addresses I could find in the code. Who will pick that one and the one regarding support for the 9220 controller for mainline? Network drivers are my responsibility. Please CC me in the future as it stands out more clearly. I guess I was waiting on you to resolve 3/3, but instead can pick up parts 1 and 2 if you like. I'll try to solve 3/3 in another fashion, so feel free to merge the other two. Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] smc911x: add support for LAN9220
Signed-off-by: Daniel Mack dan...@caiaq.de
Cc: Sascha Hauer s.ha...@pengutronix.de
---
drivers/net/smc911x.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 80d2ce0..2b01cf5 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -382,6 +382,7 @@ static inline void smc911x_reg_write(u32 addr, u32 val)
#define CHIP_9216 0x116a
#define CHIP_9217 0x117a
#define CHIP_9218 0x118a
+#define CHIP_9220 0x9220
struct chip_id {
u16 id;
@@ -398,6 +399,7 @@ static const struct chip_id chip_ids[] = {
{ CHIP_9216, LAN9216 },
{ CHIP_9217, LAN9217 },
{ CHIP_9218, LAN9218 },
+ { CHIP_9220, LAN9220 },
{ 0, NULL },
};
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] smc911x: write back the manually set MAC address
If the MAX address is given by the environment, write it back to the
hardware.
Signed-off-by: Daniel Mack dan...@caiaq.de
Cc: Sascha Hauer s.ha...@pengutronix.de
---
drivers/net/smc911x.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 30f2dc2..8c9a2a8 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -41,8 +41,13 @@ static int smx911x_handle_mac_address(bd_t *bd)
unsigned long addrh, addrl;
uchar m[6];
- /* if the environment has a valid mac address then use it */
- if (!eth_getenv_enetaddr(ethaddr, m)) {
+ if (eth_getenv_enetaddr(ethaddr, m)) {
+ /* if the environment has a valid mac address then use it */
+ addrl = m[0] | (m[1] 8) | (m[2] 16) | (m[3] 24);
+ addrh = m[4] | (m[5] 8);
+ smc911x_set_mac_csr(ADDRL, addrl);
+ smc911x_set_mac_csr(ADDRH, addrh);
+ } else {
/* if not, try to get one from the eeprom */
addrh = smc911x_get_mac_csr(ADDRH);
addrl = smc911x_get_mac_csr(ADDRL);
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] smc911x: do net reset the chip if no EEPROM is connected
On boards without EEPROMs, don't reset the chip on U-Boot's exit so that
the MAC set by environment settings can be used by the OS later.
Signed-off-by: Daniel Mack dan...@caiaq.de
Cc: Sascha Hauer s.ha...@pengutronix.de
---
drivers/net/smc911x.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 8c9a2a8..f777ae9 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -225,7 +225,9 @@ int eth_send(volatile void *packet, int length)
void eth_halt(void)
{
+#ifndef CONFIG_DRIVER_SMC911X_NO_EEPROM
smc911x_reset();
+#endif
}
int eth_rx(void)
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ne2000: take MAC address from config if available
Picking up an acient thread, On Sun, Dec 14, 2008 at 12:39:10PM +0100, Daniel Mack wrote: On Sun, Dec 14, 2008 at 12:12:24PM +0100, Wolfgang Denk wrote: This adds CONFIG_NE2000_NOPROM. If set, the ethernet MAC address is taken from the environment variable 'ethaddr' and the NIC is configured accordingly. Needed for boards that don't have an EEPROM to store this setting permanently. Signed-off-by: Daniel Mack dan...@caiaq.de --- ne2000_base.c | 38 -- 1 file changed, 28 insertions(+), 10 deletions(-) Why do we need a special CONFIG_ option? is it not possible to detect (by software) that there is no EEPROM available, and auto-adjust? Hmm, what's bad about a special config variable? I agree that in general, auto-probing is a good thing, but in U-Boot with its per-board configuration file concept, I don't see much advantage. It is very unlikely that a certain board is produced with and without an EEPROM. Note that there is existing policy how to handle the situation that we have both a MAC address stored in some other storeage (like EEPROM on the NIC) and in the ethaddr environment variable (see for example drivers/net/cs8900.c). In the end, the code shall always only rely on the U-Boot environment settings. I can send a new version of this patch following this, but I wonder why such a logic has to be implemented in the ethernet drivers and did not find a well-defined place in some kind of layer all drivers make use of? Wouldn't it make more sense to put some effort in this direction? Is there any reason why there was no reply to this anymore suddenly? Did it sound like too much work for anyone to do it the right way? I'll get back to this project soon and will need to address the same problems agains like many weeks ago, and unfortunately, nothing happened to all the issues I pointed out back then, not a single patch I sent in has been taken. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ne2000: take MAC address from config if available
Hi Wolfgang, On Sun, Dec 14, 2008 at 12:12:24PM +0100, Wolfgang Denk wrote: This adds CONFIG_NE2000_NOPROM. If set, the ethernet MAC address is taken from the environment variable 'ethaddr' and the NIC is configured accordingly. Needed for boards that don't have an EEPROM to store this setting permanently. Signed-off-by: Daniel Mack dan...@caiaq.de --- ne2000_base.c | 38 -- 1 file changed, 28 insertions(+), 10 deletions(-) Why do we need a special CONFIG_ option? is it not possible to detect (by software) that there is no EEPROM available, and auto-adjust? Hmm, what's bad about a special config variable? I agree that in general, auto-probing is a good thing, but in U-Boot with its per-board configuration file concept, I don't see much advantage. It is very unlikely that a certain board is produced with and without an EEPROM. Note that there is existing policy how to handle the situation that we have both a MAC address stored in some other storeage (like EEPROM on the NIC) and in the ethaddr environment variable (see for example drivers/net/cs8900.c). In the end, the code shall always only rely on the U-Boot environment settings. I can send a new version of this patch following this, but I wonder why such a logic has to be implemented in the ethernet drivers and did not find a well-defined place in some kind of layer all drivers make use of? Wouldn't it make more sense to put some effort in this direction? Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] add support for Toradex Colibri PXA300 module
Hi, On Sat, Dec 06, 2008 at 06:11:04PM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote: On 18:42 Sat 29 Nov , Daniel Mack wrote: Hi, this patch adds support for Toradex' Colibri PXA300 module. I had to modify the AX88796 driver a bit to make it work, but that goes in a different patch. some general comment please becarefull on the 80 chars limit please check all the whitespace please replace all hardcoded value with macro This patch can't go in as it is anyway, as some others this one depends on are still pending, rejected or uncommented. Namely the timer issue and the one regarding ax88796 register access functions. I'll wait until those are cleared and repost. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net/net.c: add get_timer_ms()
Make timeout implementation in net/net.c take into account the
CONFIG_SYS_HZ variable. This is needed for all CPUs where the default
timer is running on anything else than 1000.
Signed-off-by: Daniel Mack [EMAIL PROTECTED]
---
net/net.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/net/net.c b/net/net.c
index 77e83b5..1c48236 100644
--- a/net/net.c
+++ b/net/net.c
@@ -206,6 +206,11 @@ uchar NetArpWaitPacketBuf[PKTSIZE_ALIGN +
PKTALIGN];
ulong NetArpWaitTimerStart;
intNetArpWaitTry;
+static long get_timer_ms(long base)
+{
+ return get_timer(base) / (CONFIG_SYS_HZ / 1000);
+}
+
void ArpRequest (void)
{
int i;
@@ -256,7 +261,7 @@ void ArpTimeoutCheck(void)
if (!NetArpWaitPacketIP)
return;
- t = get_timer(0);
+ t = get_timer_ms(0);
/* check for arp timeout */
if ((t - NetArpWaitTimerStart) ARP_TIMEOUT) {
@@ -517,7 +522,7 @@ restart:
* Check for a timeout, and run the timeout handler
* if we have one.
*/
- if (timeHandler ((get_timer(0) - timeStart) timeDelta)) {
+ if (timeHandler ((get_timer_ms(0) - timeStart) timeDelta))
{
thand_f *x;
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
@@ -639,7 +644,7 @@ NetSetTimeout(ulong iv, thand_f * f)
timeHandler = (thand_f *)0;
} else {
timeHandler = f;
- timeStart = get_timer(0);
+ timeStart = get_timer_ms(0);
timeDelta = iv;
}
}
@@ -684,7 +689,7 @@ NetSendUDPPacket(uchar *ether, IPaddr_t dest, int dport,
int sport, int len)
/* and do the ARP request */
NetArpWaitTry = 1;
- NetArpWaitTimerStart = get_timer(0);
+ NetArpWaitTimerStart = get_timer_ms(0);
ArpRequest();
return 1; /* waiting */
}
@@ -755,7 +760,7 @@ int PingSend(void)
/* and do the ARP request */
NetArpWaitTry = 1;
- NetArpWaitTimerStart = get_timer(0);
+ NetArpWaitTimerStart = get_timer_ms(0);
ArpRequest();
return 1; /* waiting */
}
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/net.c: add get_timer_ms()
Hi,
On Fri, Dec 05, 2008 at 09:26:27PM +0100, Wolfgang Denk wrote:
net/net.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/net/net.c b/net/net.c
index 77e83b5..1c48236 100644
--- a/net/net.c
+++ b/net/net.c
@@ -206,6 +206,11 @@ uchar NetArpWaitPacketBuf[PKTSIZE_ALIGN +
PKTALIGN];
ulong NetArpWaitTimerStart;
intNetArpWaitTry;
+static long get_timer_ms(long base)
+{
+ return get_timer(base) / (CONFIG_SYS_HZ / 1000);
+}
+
This is by definition a NO-OP at best, and misleading and wrong
otherwise. get_timer() is defined to return millisecond resolution,
and CONFIG_SYS_HZ is supposed to be 1000.
The timer implementation (at least the one for PXA processors) assumes
that the OSCR register increments 1000 times a second. Which it doesn't
for PXA3xx variants. Hence, all functions from cpu/pxa/interrupts.c will
behave entirely differently on a PXA270 compared to a PXA3xx, and so all
code using this functions will break.
That's what I've experienced, and as I didn't find a proper place to fix
it at a sane level, I fixed the problem locally. I agree that this might
not be the best place, so I'll happily accept better proposals.
So in a correct configuration get_timer_ms() is the same as
get_timer(), and if CONFIG_SYS_HZ is (incorrectly) not set to 1000
Why is a CONFIG_SYS_HZ != 1000 considered incorrect? Or let me spin it
that way: if that's incorrect, what does this variable exist for at all?
while get_timer() is implemented correctly, then get_timer_ms()
willnot do what it claims to do.
What is get_timer() supposed to return, anyway? I didn't find any
documentation about it and assumed that it straightly returns the
primary system timer of the CPU (which it perfectly does for PXAs).
Not to mention what happens if someone has CONFIG_SYS_HZ defined as
999, for example.
Not sure whether I got your point here. If the system timer increments
999 times per second and CONFIG_SYS_HZ is set accordingly, my function
does the right thing, doesn't it? I'm not up to any flamewar, I just
want to understand where you see the problem.
As fas as I understand the big picture, a function like mine should
exist somewhere in the code. Probably not in net/net.c, though.
Best regards,
Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/net.c: add get_timer_ms()
On Fri, Dec 05, 2008 at 10:01:44PM +0100, Wolfgang Denk wrote: The timer implementation (at least the one for PXA processors) assumes that the OSCR register increments 1000 times a second. Which it doesn't for PXA3xx variants. Hence, all functions from cpu/pxa/interrupts.c will behave entirely differently on a PXA270 compared to a PXA3xx, and so all code using this functions will break. So this is a bug, and needs to be fixed. Ok. Do you want me to submit some #ifdef MONAHANS patch for the pxa ge_timer() function or is anyone working on major reworks for this anyway? Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net/net.c: correct timeout function
On Fri, Nov 28, 2008 at 05:25:29PM +0100, Daniel Mack wrote: the net/net.c implemenation of timeouts assumes that get_timer() returns values in milliseconds. As this is true for most platforms, it does not apply to PXA3x where the OSCR register increments with more than 3MHz. The following patch fixes the problem by calculation with the CONFIG_SYS_HZ variable. [...] Just curious - was this patch taken? Same question for the ones sent in mails labeled [PATCH] ne2000: take MAC address from config if available (+follow-ups) [PATCH] PXA3xx: fix CKEN[AB] Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ne2000: take MAC address from config if available
This adds CONFIG_NE2000_NOPROM. If set, the ethernet MAC address is taken
from the environment variable 'ethaddr' and the NIC is configured
accordingly. Needed for boards that don't have an EEPROM to store this
setting permanently.
Signed-off-by: Daniel Mack [EMAIL PROTECTED]
---
ne2000_base.c | 38 --
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ne2000_base.c b/drivers/net/ne2000_base.c
index f93f932..86c1380 100644
--- a/drivers/net/ne2000_base.c
+++ b/drivers/net/ne2000_base.c
@@ -669,7 +669,6 @@ void uboot_push_tx_done(int key, int val) {
int eth_init(bd_t *bd) {
int r;
u8 dev_addr[6];
- char ethaddr[20];
PRINTK(### eth_init\n);
@@ -693,16 +692,35 @@ int eth_init(bd_t *bd) {
nic.base = (u8 *) CONFIG_DRIVER_NE2000_BASE;
- r = get_prom(dev_addr, nic.base);
- if (!r)
- return -1;
+#ifndef CONFIG_NE2000_NOPROM
+ {
+ char ethaddr[20];
+ r = get_prom(dev_addr, nic.base);
+ if (!r)
+ return -1;
+
+ sprintf (ethaddr, %02X:%02X:%02X:%02X:%02X:%02X,
+dev_addr[0], dev_addr[1],
+dev_addr[2], dev_addr[3],
+dev_addr[4], dev_addr[5]) ;
+ PRINTK(Set environment from HW MAC addr = \%s\\n, ethaddr);
+ setenv (ethaddr, ethaddr);
+ }
+#else /* CONFIG_NE2000_NOPROM */
+ {
+ char *s = getenv(ethaddr);
- sprintf (ethaddr, %02X:%02X:%02X:%02X:%02X:%02X,
-dev_addr[0], dev_addr[1],
-dev_addr[2], dev_addr[3],
-dev_addr[4], dev_addr[5]) ;
- PRINTK(Set environment from HW MAC addr = \%s\\n, ethaddr);
- setenv (ethaddr, ethaddr);
+ if (!s) {
+ printf (CONFIG_NE2000_NOPROM set but no
+ ethaddr given in environment.\n);
+ return -1;
+ }
+
+ /* convert the string notation */
+ for (r = 0; r 6; r++)
+ dev_addr[r] = simple_strtol(s + (r * 3), NULL, 16);
+ }
+#endif
nic.data = nic.base + DP_DATA;
nic.tx_buf1 = START_PG;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to backup the working u-boot image from the flash image.
Hi, On Mon, Dec 01, 2008 at 12:13:28PM +0530, Mohamed Thalib .H wrote: Since I dont have the source code of u-boot image which is prgrammed in the board. I want to know how can I back up the working u-boot present in the flash and store it in a file in my system before flashing the new u-boot. so the working image can used to restore the board to working condition at any time. Where did you get the board with the binary from? As U-Boot is GPL'ized free software, you have the right to get the sources from anyone who handed out the binary to you. It's not a matter of courtesy but an obligation. Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ne2000: take MAC address from config if available
Hi Ben,
On Fri, Nov 28, 2008 at 09:27:37PM -0800, Ben Warren wrote:
the board I'm currently working on has an ASIX AX88796 NE2000 clone but
no EEPROM attached to it. Hence, the get_prom() routine returns zeros
only so the system won't work.
This patch takes the MAC address given by CONFIG_ETHADDR and translates
it to numeric values. This could probably go to some other, more generic
place, but I didn't find any.
CONFIG_ETHADDR is bad and shouldn't be used unless you only ever plan on
building one board. No new board ports will be accepted that define it.
I agree it's a hack, but in order to boot the board from ethernet, there
is need for something, even if it's not perfect.
What would be better here, although it's still not very good, would be to
have something like CONFIG_NE2000_NOPROM, and if defined, make a
'getenv(ethaddr)' call and program the hardware with the return value
(with proper error checking, of course).
I agree. See the patch below.
Thanks,
Daniel
This patch adds CONFIG_NE2000_NOPROM as configuration variable and reads
the 'ethaddr' setting from environment to set up the adapter.
Signed-off-by: Daniel Mack [EMAIL PROTECTED]
diff --git a/drivers/net/ne2000_base.c b/drivers/net/ne2000_base.c
index f93f932..86c1380 100644
--- a/drivers/net/ne2000_base.c
+++ b/drivers/net/ne2000_base.c
@@ -669,7 +669,6 @@ void uboot_push_tx_done(int key, int val) {
int eth_init(bd_t *bd) {
int r;
u8 dev_addr[6];
- char ethaddr[20];
PRINTK(### eth_init\n);
@@ -693,16 +692,35 @@ int eth_init(bd_t *bd) {
nic.base = (u8 *) CONFIG_DRIVER_NE2000_BASE;
- r = get_prom(dev_addr, nic.base);
- if (!r)
- return -1;
+#ifndef CONFIG_NE2000_NOPROM
+ {
+ char ethaddr[20];
+ r = get_prom(dev_addr, nic.base);
+ if (!r)
+ return -1;
+
+ sprintf (ethaddr, %02X:%02X:%02X:%02X:%02X:%02X,
+dev_addr[0], dev_addr[1],
+dev_addr[2], dev_addr[3],
+dev_addr[4], dev_addr[5]) ;
+ PRINTK(Set environment from HW MAC addr = \%s\\n, ethaddr);
+ setenv (ethaddr, ethaddr);
+ }
+#else /* CONFIG_NE2000_NOPROM */
+ {
+ char *s = getenv(ethaddr);
- sprintf (ethaddr, %02X:%02X:%02X:%02X:%02X:%02X,
-dev_addr[0], dev_addr[1],
-dev_addr[2], dev_addr[3],
-dev_addr[4], dev_addr[5]) ;
- PRINTK(Set environment from HW MAC addr = \%s\\n, ethaddr);
- setenv (ethaddr, ethaddr);
+ if (!s) {
+ printf (CONFIG_NE2000_NOPROM set but no
+ ethaddr given in environment.\n);
+ return -1;
+ }
+
+ /* convert the string notation */
+ for (r = 0; r 6; r++)
+ dev_addr[r] = simple_strtol(s + (r * 3), NULL, 16);
+ }
+#endif
nic.data = nic.base + DP_DATA;
nic.tx_buf1 = START_PG;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] iPAQ 21x support (+PXA3xx NAND flash and MMC)
Hi Oliver, On Sat, Nov 29, 2008 at 02:03:25PM +, Oliver Ford wrote: I've recently started trying to use U-boot on an iPAQ 214 which runs on a PXA310 cpu. I've got the basic boot up, NAND flash and MMC systems working so far. I originally tried to use the zylonite's nand.c that's already in u-boot but it was very flaky and didn't support several things I needed like large-page command set and the hardware ecc. I've now copied the latest pxa3xx nand flash code from the kernel and just modified it to cope without DMA and without IRQs. Great. I'm not sure it exactly fits in with the u-boot nand code (eg. it does an internal read ID scan to find the right command set) but it works a lot better than the board/zylonite/nand.c. Would this be useful to anyone else? Yes, absolutely - to me. I'm sitting on this at this very moment :) I was also thinking about implementing this as a PXA3xx generic layer for small pages, large pages, 8bit and 16bit so the same code does not need to be copied to all the board implementations over and over again. But I'm not sure whether there are any plans to do this as I didn't follow the development of this project for a long time. Anyways, I'd appreciate if you could send over what you got. Many thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] add support for Toradex Colibri PXA300 module
Hi,
this patch adds support for Toradex' Colibri PXA300 module. I had to
modify the AX88796 driver a bit to make it work, but that goes in a
different patch.
Also, the board code does not support NAND yet. I'll implement the code
from Oliver Ford soon.
Signed-off-by: Daniel Mack [EMAIL PROTECTED]
diff --git a/MAKEALL b/MAKEALL
index dbed268..868205f 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -554,6 +554,7 @@ LIST_at91= \
LIST_pxa= \
cerf250 \
+ colibri_pxa300 \
cradle \
csb226 \
delta \
diff --git a/Makefile b/Makefile
index befb608..ee94d17 100644
--- a/Makefile
+++ b/Makefile
@@ -2804,6 +2804,9 @@ actux4_config : unconfig
cerf250_config : unconfig
@$(MKCONFIG) $(@:_config=) arm pxa cerf250
+colibri_pxa300_config: unconfig
+ @$(MKCONFIG) $(@:_config=) arm pxa colibri_pxa300
+
cradle_config : unconfig
@$(MKCONFIG) $(@:_config=) arm pxa cradle
diff --git a/board/colibri_pxa300/Makefile b/board/colibri_pxa300/Makefile
new file mode 100644
index 000..2fa3fb9
--- /dev/null
+++ b/board/colibri_pxa300/Makefile
@@ -0,0 +1,51 @@
+#
+# (C) Copyright 2000-2006
+# Wolfgang Denk, DENX Software Engineering, [EMAIL PROTECTED]
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS := colibri_pxa300.o
+SOBJS := lowlevel_init.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/colibri_pxa300/colibri_pxa300.c
b/board/colibri_pxa300/colibri_pxa300.c
new file mode 100644
index 000..2c2b0d7
--- /dev/null
+++ b/board/colibri_pxa300/colibri_pxa300.c
@@ -0,0 +1,61 @@
+/*
+ * (C) Copyright 2008
+ * Daniel Mack, caiaq GbR [EMAIL PROTECTED]
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Miscelaneous platform dependent initialisations
+ */
+
+int board_init (void)
+{
+ /* arch number for linux kernel */
+ gd-bd-bi_arch_number = MACH_TYPE_COLIBRI300;
+
+ /* adress of boot parameters */
+ gd-bd-bi_boot_params = 0xa100;
+
+ return 0;
+}
+
+int board_late_init(void)
+{
+ setenv(stdout, serial);
+ setenv(stderr, serial);
+ return 0;
+}
+
+int dram_init (void)
+{
+ gd-bd-bi_dram[0].start = PHYS_SDRAM_1;
+ gd-bd-bi_dram[0].size = PHYS_SDRAM_1_SIZE;
+ gd-bd-bi_dram[1].start = PHYS_SDRAM_2;
+ gd-bd-bi_dram[1].size = PHYS_SDRAM_2_SIZE;
+ gd-bd-bi_dram[2].start = PHYS_SDRAM_3;
+ gd-bd-bi_dram[2].size = PHYS_SDRAM_3_SIZE;
+ gd-bd-bi_dram[3].start = PHYS_SDRAM_4;
+ gd-bd-bi_dram[3].size = PHYS_SDRAM_4_SIZE;
+ return 0;
+}
diff --git a/board/colibri_pxa300/config.mk b/board/colibri_pxa300/config.mk
new file mode 100644
index 000..350ff3d
--- /dev/null
+++ b/board/colibri_pxa300/config.mk
@@ -0,0 +1,2 @@
+TEXT_BASE = 0x8100
+
diff --git
[U-Boot] [PATCH] net/net.c: correct timeout function
Hi,
the net/net.c implemenation of timeouts assumes that get_timer() returns
values in milliseconds. As this is true for most platforms, it does not
apply to PXA3x where the OSCR register increments with more than 3MHz.
The following patch fixes the problem by calculation with the
CONFIG_SYS_HZ variable.
Best regards,
Daniel
diff --git a/net/net.c b/net/net.c
index 77e83b5..b9326de 100644
--- a/net/net.c
+++ b/net/net.c
@@ -206,6 +206,11 @@ uchar NetArpWaitPacketBuf[PKTSIZE_ALIGN +
PKTALIGN];
ulong NetArpWaitTimerStart;
intNetArpWaitTry;
+static long net_get_timer(long base)
+{
+ return get_timer(base) / (CONFIG_SYS_HZ / 1000);
+}
+
void ArpRequest (void)
{
int i;
@@ -256,7 +261,7 @@ void ArpTimeoutCheck(void)
if (!NetArpWaitPacketIP)
return;
- t = get_timer(0);
+ t = net_get_timer(0);
/* check for arp timeout */
if ((t - NetArpWaitTimerStart) ARP_TIMEOUT) {
@@ -517,7 +522,7 @@ restart:
* Check for a timeout, and run the timeout handler
* if we have one.
*/
- if (timeHandler ((get_timer(0) - timeStart) timeDelta)) {
+ if (timeHandler ((net_get_timer(0) - timeStart)
timeDelta)) {
thand_f *x;
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
@@ -639,7 +644,7 @@ NetSetTimeout(ulong iv, thand_f * f)
timeHandler = (thand_f *)0;
} else {
timeHandler = f;
- timeStart = get_timer(0);
+ timeStart = net_get_timer(0);
timeDelta = iv;
}
}
@@ -684,7 +689,7 @@ NetSendUDPPacket(uchar *ether, IPaddr_t dest, int dport,
int sport, int len)
/* and do the ARP request */
NetArpWaitTry = 1;
- NetArpWaitTimerStart = get_timer(0);
+ NetArpWaitTimerStart = net_get_timer(0);
ArpRequest();
return 1; /* waiting */
}
@@ -755,7 +760,7 @@ int PingSend(void)
/* and do the ARP request */
NetArpWaitTry = 1;
- NetArpWaitTimerStart = get_timer(0);
+ NetArpWaitTimerStart = net_get_timer(0);
ArpRequest();
return 1; /* waiting */
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ne2000: take MAC address from config if available
Hi,
the board I'm currently working on has an ASIX AX88796 NE2000 clone but
no EEPROM attached to it. Hence, the get_prom() routine returns zeros
only so the system won't work.
This patch takes the MAC address given by CONFIG_ETHADDR and translates
it to numeric values. This could probably go to some other, more generic
place, but I didn't find any.
Best regards,
Daniel
diff --git a/drivers/net/ne2000_base.c b/drivers/net/ne2000_base.c
index f93f932..f8480a3 100644
--- a/drivers/net/ne2000_base.c
+++ b/drivers/net/ne2000_base.c
@@ -693,6 +693,7 @@ int eth_init(bd_t *bd) {
nic.base = (u8 *) CONFIG_DRIVER_NE2000_BASE;
+#ifndef CONFIG_ETHADDR
r = get_prom(dev_addr, nic.base);
if (!r)
return -1;
@@ -703,6 +704,20 @@ int eth_init(bd_t *bd) {
dev_addr[4], dev_addr[5]) ;
PRINTK(Set environment from HW MAC addr = \%s\\n, ethaddr);
setenv (ethaddr, ethaddr);
+#else /* CONFIG_ETHADDR */
+#define STR(X) #X
+#define XSTR(X) STR(X)
+ strncpy(ethaddr, XSTR(CONFIG_ETHADDR), sizeof(ethaddr));
+
+ /* replace all colons by NULL characters */
+ for (r = 0; r strlen(ethaddr); r++)
+ if (ethaddr[r] == ':')
+ ethaddr[r] = '\0';
+
+ /* convert the string notation */
+ for (r = 0; r 6; r++)
+ dev_addr[r] = simple_strtol(ethaddr + (r * 3), NULL, 16);
+#endif
nic.data = nic.base + DP_DATA;
nic.tx_buf1 = START_PG;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] fix lib_arm/bootm.c
Hi, while digging thru the sources to find out why U-Boot won't start my Linux kernel, I stumbled over lib_arm/bootm.c and its check for the falg variable. I wonder how this ever worked as the condition is really heavy to match unless BOOTM_STATE_OS_GO is 0 which it isn't. So I guess the patch below is mandatory or you could write an unlikely() around that check ;) Best regards, Daniel diff --git a/lib_arm/bootm.c b/lib_arm/bootm.c index 8e264ce..58a101f 100644 --- a/lib_arm/bootm.c +++ b/lib_arm/bootm.c @@ -67,7 +67,7 @@ int do_bootm_linux(int flag, int argc, char *argv[], bootm_headers_t *images) char *commandline = getenv (bootargs); #endif - if ((flag != 0) || (flag != BOOTM_STATE_OS_GO)) + if ((flag != 0) (flag != BOOTM_STATE_OS_GO)) return 1; theKernel = (void (*)(int, int, uint))images-ep; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] gd_t/bd_t on ARM
Hi, I'm hunting weird behaviours with the gd_t global data pointer on my PXA300 board board. The pointer gets set up fine in lib_arm/boot.c and gd-bd is filled in my board specific code. However, after the tftp download is finished, the content of these structures have been destroyed and overwritten with garbage. I suspect a stack corruption to be the culprit, an overflow or overlap, as it seems to happen randomly, after a while and some function calls. Any hints about that? Also, I wonder why the pointer to this struct is not placed *after* U-Boot's own code as shown in the patch below. This works fine for me now. Any oppinion on that? Thanks and best regards, Daniel diff --git a/lib_arm/board.c b/lib_arm/board.c index 4ba1f5e..90ad5f7 100644 --- a/lib_arm/board.c +++ b/lib_arm/board.c @@ -282,12 +282,12 @@ void start_armboot (void) #endif /* Pointer is writable since we allocated a register for it */ - gd = (gd_t*)(_armboot_start - CONFIG_SYS_MALLOC_LEN - sizeof(gd_t)); + gd = (gd_t*) _bss_end; /* compiler optimization barrier needed for GCC = 3.4 */ __asm__ __volatile__(: : :memory); memset ((void*)gd, 0, sizeof (gd_t)); - gd-bd = (bd_t*)((char*)gd - sizeof(bd_t)); + gd-bd = (bd_t*)((char*)gd + sizeof(gd_t)); memset (gd-bd, 0, sizeof (bd_t)); gd-flags |= GD_FLG_RELOC; ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] PXA3xx: fix CKEN[AB]
Hi, there are some bits in PXA3xx' CKENA/CKENB registers which need to be set always, according to the documentation. They are actually different for the three families, but as there is no way to keep track of them yet in U-Boot, I'd rather apply this patch and enable some clocks on some processors which are not neccessarily needed. Best regards, Daniel diff --git a/cpu/pxa/start.S b/cpu/pxa/start.S index 63ab0c5..9d74d6c 100644 --- a/cpu/pxa/start.S +++ b/cpu/pxa/start.S @@ -235,10 +235,10 @@ cpu_init_crit: /* turn off all clocks but the ones we will definitly require */ ldr r1, =CKENA - ldr r2, =(CKENA_22_FFUART | CKENA_10_SRAM | CKENA_9_SMC | CKENA_8_DMC) + ldr r2, =(CKENA_22_FFUART | CKENA_10_SRAM | CKENA_9_SMC | CKENA_8_DMC | CKENA_SETALWAYS) str r2, [r1] ldr r1, =CKENB - ldr r2, =(CKENB_6_IRQ) + ldr r2, =(CKENB_6_IRQ | CKENB_SETALWAYS) str r2, [r1] #endif /* !CONFIG_CPU_MONAHANS */ diff --git a/include/asm-arm/arch-pxa/pxa-regs.h b/include/asm-arm/arch-pxa/pxa-regs.h index e014568..25d640b 100644 --- a/include/asm-arm/arch-pxa/pxa-regs.h +++ b/include/asm-arm/arch-pxa/pxa-regs.h @@ -1757,6 +1757,7 @@ typedef void (*ExcpHndlr) (void) ; #define CKENA_3_CAMERA (1 3)/* Camera Interface Clock Enable */ #define CKENA_2_USBHOST(1 2)/* USB Host Unit Clock Enable */ #define CKENA_1_LCD(1 1)/* LCD Unit Clock Enable */ +#define CKENA_SETALWAYS(0x80a1)/* bits marked 'SETALWAYS' */ #define CKENB_8_1WIRE ((1 8) + 32) /* One Wire Interface Unit Clock Enable */ #define CKENB_7_GPIO ((1 7) + 32) /* GPIO Clock Enable */ @@ -1764,6 +1765,7 @@ typedef void (*ExcpHndlr) (void) ; #define CKENB_4_I2C((1 4) + 32) /* I2C Unit Clock Enable */ #define CKENB_1_PWM1 ((1 1) + 32) /* PWM2 PWM3 Clock Enable */ #define CKENB_0_PWM0 ((1 0) + 32) /* PWM0 PWM1 Clock Enable */ +#define CKENB_SETALWAYS(0xfffcfc4c)/* bits marked 'SETALWAYS' */ #else /* if defined CONFIG_CPU_MONAHANS */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] gd_t/bd_t on ARM
Hi Remy, On Fri, Nov 28, 2008 at 10:39:49PM +0100, Remy Bohmer wrote: I'm hunting weird behaviours with the gd_t global data pointer on my PXA300 board board. The pointer gets set up fine in lib_arm/boot.c and gd-bd is filled in my board specific code. However, after the tftp download is finished, the content of these structures have been destroyed and overwritten with garbage. I suspect a stack corruption to be the culprit, an overflow or overlap, as it seems to happen randomly, after a while and some function calls. Any hints about that? Hook up a JTAG (or preferable an ETM) debugger and start tracing? I did that for a couple of hours now and got somehow stuck with it. However, I believe it's not related to my board specific code, so I wanted to ask whether anyone else had similar trouble with the cutting edge source tree. Also, I wonder why the pointer to this struct is not placed *after* U-Boot's own code as shown in the patch below. This works fine for me now. Any oppinion on that? Aren't you just hiding the symptoms here? It seems that there is something really wrong and by moving the global structures probably a different memory area is overwritten, but the problem should still be there... Of course. That wasn't meant to be the fix for the other problem, I was just curious as this other location makes more sense to me and also does not require CONFIG_SYS_GBL_DATA_SIZE anymore. If I got that right, this variable has to be set to something at least sizeof(gd_t)+sizeof(bd_t). Right? Best regards, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
