Re: [U-Boot] [PATCH 0/6] IXP: Make IXP compile with arm-linux-gnueabi- and fix it
On 03/06/2012 01:18 AM, Marek Vasut wrote:
This series of patches makes ARM/IXP platform compile with usual
arm-linux-gnueabi- toolchain. Also, fix the IXP build errors detected with
gcc4.6.
Marek Vasut (6):
Examples: Properly append LDFLAGS to LD command
IXP: Make IXP buildable with arm-linux- toolchains
IXP: Fix missing MACH_TYPE_{ACTUX?,PNB3,DVLHOST}
IXP: Squash warnings in IXP NPE
IXP: Move PDNB3 and SCPU from Makefile to boards.cfg
IXP: Fix NAND build warning on PDNB3 and SCPU
Makefile | 12
arch/arm/cpu/ixp/config.mk |3 +++
arch/arm/cpu/ixp/npe/IxEthAcc.c |2 +-
arch/arm/cpu/ixp/npe/IxEthDBAPISupport.c |3 ---
arch/arm/cpu/ixp/npe/IxQMgrDispatcher.c |3 ---
board/actux1/actux1.c|2 --
board/actux2/actux2.c|2 --
board/actux3/actux3.c|2 --
board/actux4/actux4.c|2 --
board/dvlhost/dvlhost.c |2 --
board/prodrive/pdnb3/nand.c |9 ++---
board/prodrive/pdnb3/pdnb3.c |3 ---
boards.cfg |2 ++
examples/standalone/Makefile |2 +-
include/configs/actux1.h |2 ++
include/configs/actux2.h |2 ++
include/configs/actux3.h |2 ++
include/configs/actux4.h |2 ++
include/configs/dvlhost.h|2 ++
include/configs/pdnb3.h |2 ++
20 files changed, 25 insertions(+), 36 deletions(-)
Cc: Bryan Hundvenbryanhund...@gmail.com
Cc: Michael Schwingenrincew...@discworld.dascon.de
Can you guys please verify if after applying these patches, IXP builds with your
armeb toolchains?
Also, can you please try if binaries built with usual arm-linux-gnueabi-
toolchain (linaro, codesourcery whatever ...) now produce bootable result (this
is very important, I'd be happy if they did so we can get rid of that whole
armeb compiler stuff)?
Sure, but this might take me some weeks. Thanks for the effort!
cu
Michael
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bug in cfb_console driver
Hi,
On Mon, 05 Mar 2012 11:42:13 +0100
Pali Rohár pali.ro...@gmail.com wrote:
...
Hi, thanks. If you need some more info write me.
Can you please test with attached patch? Does it help to solve
your problem on N900?
Thanks,
Anatolij
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index 904caf7..5076e31 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -610,17 +610,24 @@ static void video_set_cursor(void)
console_cursor(1);
}
-static void video_invertchar(int xx, int yy)
+static void video_draw_cursor(int xx, int yy, int on)
{
int firstx = xx * VIDEO_PIXEL_SIZE;
int lastx = (xx + VIDEO_FONT_WIDTH) * VIDEO_PIXEL_SIZE;
int firsty = yy * VIDEO_LINE_LEN;
int lasty = (yy + VIDEO_FONT_HEIGHT) * VIDEO_LINE_LEN;
int x, y;
+ char val;
+
+ if (on)
+ val = 0xff;
+ else
+ val = 0;
+
for (y = firsty; y lasty; y += VIDEO_LINE_LEN) {
for (x = firstx; x lastx; x++) {
u8 *dest = (u8 *)(video_fb_address) + x + y;
- *dest = ~*dest;
+ *dest = val;
}
}
}
@@ -651,14 +658,14 @@ void console_cursor(int state)
if (cursor_state != state) {
if (cursor_state) {
/* turn off the cursor */
- video_invertchar(old_col * VIDEO_FONT_WIDTH,
- old_row * VIDEO_FONT_HEIGHT +
- video_logo_height);
+ video_draw_cursor(old_col * VIDEO_FONT_WIDTH,
+ old_row * VIDEO_FONT_HEIGHT +
+ video_logo_height, 0);
} else {
- /* turn off the cursor and record where it is */
- video_invertchar(console_col * VIDEO_FONT_WIDTH,
- console_row * VIDEO_FONT_HEIGHT +
- video_logo_height);
+ /* turn on the cursor and record where it is */
+ video_draw_cursor(console_col * VIDEO_FONT_WIDTH,
+ console_row * VIDEO_FONT_HEIGHT +
+ video_logo_height, 1);
old_col = console_col;
old_row = console_row;
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] USB:gadget:designware Fix memory nonalignment issue
Dear Marek,
On 3/5/2012 11:51 PM, Marek Vasut wrote:
Dear Amit Virdi,
From: Shiraz Hashimshiraz.has...@st.com
While receiving packets from FIFO sometimes the buffer provided was
nonaligned. Fix this by taking a temporary aligned buffer and then
copying the content to nonaligned buffer.
Signed-off-by: Shiraz Hashimshiraz.has...@st.com
Signed-off-by: Amit Virdiamit.vi...@st.com
---
drivers/usb/gadget/designware_udc.c | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/designware_udc.c
b/drivers/usb/gadget/designware_udc.c index d4b53a2..878123c 100644
--- a/drivers/usb/gadget/designware_udc.c
+++ b/drivers/usb/gadget/designware_udc.c
@@ -202,6 +202,7 @@ static int usbgetpckfromfifo(int epNum, u8 *bufp, u32
len) u32 i, nw, nb;
u32 *wrdp;
u8 *bytp;
+ u32 tmp[128];
if (readl(udc_regs_p-dev_stat) DEV_STAT_RXFIFO_EMPTY)
return -1;
@@ -209,7 +210,12 @@ static int usbgetpckfromfifo(int epNum, u8 *bufp, u32
len) nw = len / sizeof(u32);
nb = len % sizeof(u32);
- wrdp = (u32 *)bufp;
+ /* use tmp buf if bufp is not word aligned */
+ if ((int)bufp 0x3)
+ wrdp = (u32 *)tmp[0];
+ else
+ wrdp = (u32 *)bufp;
+
for (i = 0; i nw; i++) {
writel(readl(fifo_ptr), wrdp);
wrdp++;
@@ -223,6 +229,13 @@ static int usbgetpckfromfifo(int epNum, u8 *bufp, u32
len) }
readl(outep_regs_p[epNum].write_done);
+ /* copy back tmp buffer to bufp if bufp is not word aligned */
+ if ((int)bufp 0x3) {
+ bytp = (u8 *)tmp[0];
+ for (i = 0; i len; i++)
+ bufp[i] = bytp[i];
+ }
+
return 0;
}
This addresses EHCI cache problem, that's why you need bounce buffer, right?
No. The problem was we were copying data word-by-word to a non-word
aligned memory in the USB gadget. So, this is different from the USB
host controller issue.
Thanks n Regards
Amit Virdi
This is the patch from Puneet, can you give it a go and tell me if EHCI works
for you without 4/4 patch from your series or do you still see issues?
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/126447
Thanks in advance!
Best regards,
Marek Vasut
.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] md,mw commands
Hi, Iam using 256MB RAM on arm11 board.I just tried md,mw commands from uboot like the following mw C80 0x 0x500 here C80 is the 200MB of RAM MCS8142 md C80 0c80: 0c800010: 0c800020: 0c800030: 0c800040: 0c800050: 0c800060: 0c800070: 0c800080: 0c800090: 0c8000a0: 0c8000b0: 0c8000c0: 0c8000d0: 0c8000e0: 0c8000f0: mw 3200 0x 0x500 here 3200 is the 800MB of RAM MCS8142 md 3200 3200: 3210: 3220: 3230: 3240: 3250: 3260: 3270: How it is possible to see the data even after the 256MB of RAM.If i give the sizes like 256MB ,512MB mw command get hangs otherwise the data is writing to the RAM even the size exceeds the size of actual RAM. Please help me. Thanks V.Balaji ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/8 v3] powerpc/corenet_ds: Correct the compilation errors about ENV
When defined CONFIG_ENV_IS_NOWHERE, there will be some compilation errors: ./common/env_nowhere.o: In function `env_relocate_spec': ./common/env_nowhere.c:38: multiple definition of `env_relocate_spec' ./common/env_flash.o: ./common/env_flash.c:326: first defined here ./common/env_nowhere.o: In function `env_get_char_spec': ./common/env_nowhere.c:42: multiple definition of `env_get_char_spec' ./common/env_flash.o:./common/env_flash.c:78: first defined here ./common/env_nowhere.o: In function `env_init': ./common/env_nowhere.c:51: multiple definition of `env_init' ./common/env_flash.o:./common/env_flash.c:237: first defined here make[1]: *** [./common/libcommon.o] Error 1 make[1]: Leaving directory `./common' make: *** [./common/libcommon.o] Error 2 Remove the CONFIG_ENV_IS_IN_FLASH if defined CONFIG_ENV_IS_NOWHERE. Signed-off-by: Liu Gang gang@freescale.com --- Changes in v2: - Subject changed to powerpc/corenet_ds. - Change the commit message more clearly. Changes in v3: - No include/configs/corenet_ds.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/corenet_ds.h b/include/configs/corenet_ds.h index 5067bb7..89e6b6e 100644 --- a/include/configs/corenet_ds.h +++ b/include/configs/corenet_ds.h @@ -104,6 +104,8 @@ #define CONFIG_ENV_IS_IN_NAND #define CONFIG_ENV_SIZECONFIG_SYS_NAND_BLOCK_SIZE #define CONFIG_ENV_OFFSET (5 * CONFIG_SYS_NAND_BLOCK_SIZE) +#elif defined(CONFIG_ENV_IS_NOWHERE) +#define CONFIG_ENV_SIZE0x2000 #else #define CONFIG_ENV_IS_IN_FLASH #define CONFIG_ENV_ADDR(CONFIG_SYS_MONITOR_BASE - CONFIG_ENV_SECT_SIZE) -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/8 v3] powerpc/corenet_ds: Slave module for boot from SRIO
For the powerpc processors with SRIO interface, boot location can be configured
from SRIO1 or SRIO2 by RCW. The processor booting from SRIO can do without flash
for u-boot image. The image can be fetched from another processor's memory
space by SRIO link connected between them.
The processor boots from SRIO is slave, the processor boots from normal flash
memory space and can help slave to boot from its memory space is master.
They are different environments and requirements:
master:
1. NOR flash for its own u-boot image, ucode and ENV space.
2. Slave's u-boot image in master NOR flash.
3. Normally boot from local NOR flash.
4. Configure SRIO switch system if needed.
slave:
1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV.
2. Boot location should be set to SRIO1 or SRIO2 by RCW.
3. RCW should configure the SerDes, SRIO interfaces correctly.
4. Slave must be powered on after master's boot.
5. Must define CONFIG_SYS_QE_FMAN_FW_IN_REMOTE because of no ucode
locally.
For the slave module, need to finish these processes:
1. Set the boot location to SRIO1 or SRIO2 by RCW.
2. Set a specific TLB entry for the boot process.
3. Set a LAW entry with the TargetID SRIO1 or SRIO2 for the boot.
4. Slave's u-boot image should be generated specifically by
make _SRIOBOOT_SLAVE_config.
This will set SYS_TEXT_BASE=0xFFF8 and other configurations.
Signed-off-by: Liu Gang gang@freescale.com
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
Changes in v2:
- Subject changed to powerpc/corenet_ds.
- Use (void *) instead of (u32) when calling out_be32().
- Use NOR flash instead of Nor flash.
- Get rid of the base address + offset notation. Use C structs
instead.
- Get rid of hard coded magic numbers. Use macro instead.
- Use debug() instead of printf().
- Add the description for CONFIG_SYS_QE_FMAN_FW_IN_REMOTE and also
update the README for this.
Changes in v3:
- No
README |6 ++
board/freescale/common/p_corenet/law.c |9 +
board/freescale/common/p_corenet/tlb.c |9 +
boards.cfg |3 +++
drivers/net/fm/fm.c|2 ++
include/configs/corenet_ds.h | 28
6 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/README b/README
index eba6378..719cc20 100644
--- a/README
+++ b/README
@@ -3384,6 +3384,12 @@ within that device.
Specifies that QE/FMAN firmware is located on the primary SPI
device. CONFIG_SYS_FMAN_FW_ADDR is the byte offset on that device.
+- CONFIG_SYS_QE_FMAN_FW_IN_REMOTE
+ Specifies that QE/FMAN firmware is located in the remote (master)
+ memory space. CONFIG_SYS_FMAN_FW_ADDR is a virtual address which
+ can be mapped from slave TLB-slave LAW-slave SRIO outbound window
+ -master inbound window-master LAW-the ucode address in master's
+ NOR flash.
Building the Software:
==
diff --git a/board/freescale/common/p_corenet/law.c
b/board/freescale/common/p_corenet/law.c
index 09ef561..1fbab4d 100644
--- a/board/freescale/common/p_corenet/law.c
+++ b/board/freescale/common/p_corenet/law.c
@@ -48,6 +48,15 @@ struct law_entry law_table[] = {
#ifdef CONFIG_SYS_NAND_BASE_PHYS
SET_LAW(CONFIG_SYS_NAND_BASE_PHYS, LAW_SIZE_1M, LAW_TRGT_IF_LBC),
#endif
+#ifdef CONFIG_SRIOBOOT_SLAVE
+#if defined(CONFIG_SRIOBOOT_SLAVE_PORT0)
+ SET_LAW(CONFIG_SYS_SRIOBOOT_SLAVE_ADDR_PHYS,
+ LAW_SIZE_1M, LAW_TRGT_IF_RIO_1),
+#elif defined(CONFIG_SRIOBOOT_SLAVE_PORT1)
+ SET_LAW(CONFIG_SYS_SRIOBOOT_SLAVE_ADDR_PHYS,
+ LAW_SIZE_1M, LAW_TRGT_IF_RIO_2),
+#endif
+#endif
};
int num_law_entries = ARRAY_SIZE(law_table);
diff --git a/board/freescale/common/p_corenet/tlb.c
b/board/freescale/common/p_corenet/tlb.c
index 6a0026a..a8c8b3c 100644
--- a/board/freescale/common/p_corenet/tlb.c
+++ b/board/freescale/common/p_corenet/tlb.c
@@ -66,6 +66,15 @@ struct fsl_e_tlb_entry tlb_table[] = {
SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L3_ADDR, CONFIG_SYS_INIT_L3_ADDR,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
0, 0, BOOKE_PAGESZ_1M, 1),
+#elif defined(CONFIG_SRIOBOOT_SLAVE)
+ /*
+* SRIOBOOT-SLAVE. When slave boot, the address of the
+* space is at 0xfff0, it covered the 0xf000.
+*/
+ SET_TLB_ENTRY(1, CONFIG_SYS_SRIOBOOT_SLAVE_ADDR,
+ CONFIG_SYS_SRIOBOOT_SLAVE_ADDR_PHYS,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_W|MAS2_G,
+ 0, 0, BOOKE_PAGESZ_1M, 1),
#else
SET_TLB_ENTRY(1, 0xf000, 0xf000,
MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
diff --git a/boards.cfg b/boards.cfg
index 30b9b51..11f9ef2
Re: [U-Boot] [PATCH 0/6] IXP: Make IXP compile with arm-linux-gnueabi- and fix it
Dear Michael Schwingen,
On 03/06/2012 01:18 AM, Marek Vasut wrote:
This series of patches makes ARM/IXP platform compile with usual
arm-linux-gnueabi- toolchain. Also, fix the IXP build errors detected
with gcc4.6.
Marek Vasut (6):
Examples: Properly append LDFLAGS to LD command
IXP: Make IXP buildable with arm-linux- toolchains
IXP: Fix missing MACH_TYPE_{ACTUX?,PNB3,DVLHOST}
IXP: Squash warnings in IXP NPE
IXP: Move PDNB3 and SCPU from Makefile to boards.cfg
IXP: Fix NAND build warning on PDNB3 and SCPU
Makefile | 12
arch/arm/cpu/ixp/config.mk |3 +++
arch/arm/cpu/ixp/npe/IxEthAcc.c |2 +-
arch/arm/cpu/ixp/npe/IxEthDBAPISupport.c |3 ---
arch/arm/cpu/ixp/npe/IxQMgrDispatcher.c |3 ---
board/actux1/actux1.c|2 --
board/actux2/actux2.c|2 --
board/actux3/actux3.c|2 --
board/actux4/actux4.c|2 --
board/dvlhost/dvlhost.c |2 --
board/prodrive/pdnb3/nand.c |9 ++---
board/prodrive/pdnb3/pdnb3.c |3 ---
boards.cfg |2 ++
examples/standalone/Makefile |2 +-
include/configs/actux1.h |2 ++
include/configs/actux2.h |2 ++
include/configs/actux3.h |2 ++
include/configs/actux4.h |2 ++
include/configs/dvlhost.h|2 ++
include/configs/pdnb3.h |2 ++
20 files changed, 25 insertions(+), 36 deletions(-)
Cc: Bryan Hundvenbryanhund...@gmail.com
Cc: Michael Schwingenrincew...@discworld.dascon.de
Can you guys please verify if after applying these patches, IXP builds
with your armeb toolchains?
Also, can you please try if binaries built with usual arm-linux-gnueabi-
toolchain (linaro, codesourcery whatever ...) now produce bootable result
(this is very important, I'd be happy if they did so we can get rid of
that whole armeb compiler stuff)?
Sure, but this might take me some weeks. Thanks for the effort!
cu
Michael
so I'll push these upstream and you'll let me know if something got broken
later, this fix is better than nothing, ok?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8] usb: align buffers at cacheline
Dear Puneet Saxena, Hi Simon, I do see only first warning on all the devices and rest of the warnings on a few mass storage device. My patch fixing these warnings is not accepted. Please see below link for further info - http://lists.denx.de/pipermail/u-boot/2012-March/119404.html IMO, these warnings spew when we expects some info e.g. device descriptor, manf id, prod id... from the device. The root cause of the issue is some race condition in H/w due to which, even though we receive STD_ASS(Async sequence status) as 0 still transfer descriptor token is not updated. Thanx Regards, Puneet I'd really love to accept the patch, but I can see it exposes even worse issue, so I'd be really happy to fix the root cause of the problem instead of putting layers of hack-arounds on top of it. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] usb: align buffers at cacheline
Dear Mike Frysinger, On Friday 02 March 2012 11:45:15 Wolfgang Denk wrote: That's what I did in original patch where I am aligning it by adding the line +/* Device Descriptor */ +#ifdef ARCH_DMA_MINALIGN + struct usb_device_descriptor descriptor + __attribute__((aligned(ARCH_DMA_MINALIGN))); +#else + struct usb_device_descriptor descriptor; +#endif in usb.h Line:112 M I see ...and I told you it's wrong? I must have misunderstood, I'm sorry about that. But if you actually do this, you can avoid memcpy, right? And eventually wd can also avoid the #ifdef ? I guess the __attribute__((aligned...)) would not hurt anything? the reason i disliked that was because it adds padding to the structure. on my system, seems to go from 144 bytes to 160, and the other goes from 1352 to 1376. the scsi structure isn't specific to usb either. i can't tell if this is a structure that represents data on the wire ... the fact it's written all using char types makes me suspicious. if it is, then obviously we can't change the padding in the struct. further, it doesn't seem like Linux imposes this restriction at the structure level (does it do memcopies instead ?), and imposing it on arbitrary members in there w/out documentation easily leads to rot. if the code changes and no longer needs this alignment, how do we tell ? if the code starts transferring another structure, do we end up aligning every member in there until there's padding everywhere ? -mike I believe this is OK, we're properly aligning only descriptors. Note that the USB stack in linux and in uboot is different. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] USB:gadget:designware Fix memory nonalignment issue
Dear Amit Virdi,
Dear Marek,
On 3/5/2012 11:51 PM, Marek Vasut wrote:
Dear Amit Virdi,
From: Shiraz Hashimshiraz.has...@st.com
While receiving packets from FIFO sometimes the buffer provided was
nonaligned. Fix this by taking a temporary aligned buffer and then
copying the content to nonaligned buffer.
Signed-off-by: Shiraz Hashimshiraz.has...@st.com
Signed-off-by: Amit Virdiamit.vi...@st.com
---
drivers/usb/gadget/designware_udc.c | 15 ++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/gadget/designware_udc.c
b/drivers/usb/gadget/designware_udc.c index d4b53a2..878123c 100644
--- a/drivers/usb/gadget/designware_udc.c
+++ b/drivers/usb/gadget/designware_udc.c
@@ -202,6 +202,7 @@ static int usbgetpckfromfifo(int epNum, u8 *bufp,
u32 len) u32 i, nw, nb;
u32 *wrdp;
u8 *bytp;
+ u32 tmp[128];
if (readl(udc_regs_p-dev_stat) DEV_STAT_RXFIFO_EMPTY)
return -1;
@@ -209,7 +210,12 @@ static int usbgetpckfromfifo(int epNum, u8 *bufp,
u32 len) nw = len / sizeof(u32);
nb = len % sizeof(u32);
- wrdp = (u32 *)bufp;
+ /* use tmp buf if bufp is not word aligned */
+ if ((int)bufp 0x3)
+ wrdp = (u32 *)tmp[0];
+ else
+ wrdp = (u32 *)bufp;
+
for (i = 0; i nw; i++) {
writel(readl(fifo_ptr), wrdp);
wrdp++;
@@ -223,6 +229,13 @@ static int usbgetpckfromfifo(int epNum, u8 *bufp,
u32 len) }
readl(outep_regs_p[epNum].write_done);
+ /* copy back tmp buffer to bufp if bufp is not word aligned */
+ if ((int)bufp 0x3) {
+ bytp = (u8 *)tmp[0];
+ for (i = 0; i len; i++)
+ bufp[i] = bytp[i];
+ }
+
return 0;
}
This addresses EHCI cache problem, that's why you need bounce buffer,
right?
No. The problem was we were copying data word-by-word to a non-word
aligned memory in the USB gadget. So, this is different from the USB
host controller issue.
I see ... why isn't buffer aligned by the usb stack then?
Thanks!
Thanks n Regards
Amit Virdi
This is the patch from Puneet, can you give it a go and tell me if EHCI
works for you without 4/4 patch from your series or do you still see
issues?
http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/126447
Thanks in advance!
Best regards,
Marek Vasut
.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Buildroot] Craneboard with Uboot and xloader
The first problem is the lack of informations about Craneboard in the craneboard TI wiki for example the display over DVI informations... the other problem is that impossible to use BUILDROOT to create a distribution for Craneboard with any vanilla kernel version (2.6.37; 2.6.39.1,..). the only version that works is that provided by TI and it's based on 2.6.32 vanilla kernel which is an older version for many tools. We need a little description how to adapt Buildroot for compiling any recent kernel version and other things for working on Craneboard ! we need a kernel config file who work with recent version of vanilla kernel and not generate a compile error or a kernel panic when booting ! I tested all the possibilities with Buildroot 2012.02 and nothing works. Thank you for your help On Tue, Mar 6, 2012 at 10:33 AM, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: Le Tue, 6 Mar 2012 10:19:57 +0100, Mohamed HAMZAOUI requin...@gmail.com a écrit : So far I have not been able to compile another kernel version other than ( https://github.com/craneboard/craneboard-kernel.git) with buildroot. What problems do you have? Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/8 v3] powerpc/corenet_ds: Slave uploads ucode when boot from SRIO
When boot from SRIO, slave's ucode can be stored in master's memory space,
then slave can fetch the ucode image through SRIO interface. For the
corenet platform, ucode is for Fman.
Master needs to:
1. Put the slave's ucode image into it's own memory space.
2. Set an inbound SRIO window covered slave's ucode stored in master's
memory space.
Slave needs to:
1. Set a specific TLB entry in order to fetch ucode from master.
2. Set a LAW entry with the TargetID SRIO1 or SRIO2 for ucode.
Signed-off-by: Liu Gang gang@freescale.com
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
Changes in v2:
- Subject changed to powerpc/corenet_ds.
- Use (void *) instead of (u32) when calling out_be32().
- Use NOR flash instead of Nor flash.
- Get rid of the base address + offset notation. Use C structs
instead.
- Get rid of hard coded magic numbers. Use macro instead.
- Use debug() instead of printf().
- Correct some comment style errors.
Changes in v3:
- No
arch/powerpc/cpu/mpc8xxx/srio.c| 25 +
board/freescale/common/p_corenet/law.c |4
board/freescale/common/p_corenet/tlb.c | 10 ++
include/configs/corenet_ds.h | 12 +++-
4 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/cpu/mpc8xxx/srio.c b/arch/powerpc/cpu/mpc8xxx/srio.c
index 77fa32f..e593f22 100644
--- a/arch/powerpc/cpu/mpc8xxx/srio.c
+++ b/arch/powerpc/cpu/mpc8xxx/srio.c
@@ -100,8 +100,8 @@ void srio_boot_master(void)
debug(SRIOBOOT - MASTER: Master port [ %d ] for srio boot.\n,
CONFIG_SRIOBOOT_MASTER_PORT);
- /* configure inbound window5 for slave's u-boot image */
- debug(SRIOBOOT - MASTER: Inbound window 5 for slave's image;
+ /* configure inbound window for slave's u-boot image */
+ debug(SRIOBOOT - MASTER: Inbound window for slave's image;
Local = 0x%llx, Srio = 0x%llx, Size = 0x%x\n,
(u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_LAW_PHYS1,
(u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_SRIO_PHYS1,
@@ -117,8 +117,8 @@ void srio_boot_master(void)
SRIO_IB_ATMU_AR
| atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_IMAGE_SIZE));
- /* configure inbound window4 for slave's u-boot image */
- debug(SRIOBOOT - MASTER: Inbound window 4 for slave's image;
+ /* configure inbound window for slave's u-boot image */
+ debug(SRIOBOOT - MASTER: Inbound window for slave's image;
Local = 0x%llx, Srio = 0x%llx, Size = 0x%x\n,
(u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_LAW_PHYS2,
(u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_SRIO_PHYS2,
@@ -133,5 +133,22 @@ void srio_boot_master(void)
.port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[1].riwar,
SRIO_IB_ATMU_AR
| atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_IMAGE_SIZE));
+
+ /* configure inbound window for slave's ucode */
+ debug(SRIOBOOT - MASTER: Inbound window for slave's ucode;
+ Local = 0x%llx, Srio = 0x%llx, Size = 0x%x\n,
+ (u64)CONFIG_SRIOBOOT_SLAVE_UCODE_LAW_PHYS,
+ (u64)CONFIG_SRIOBOOT_SLAVE_UCODE_SRIO_PHYS,
+ CONFIG_SRIOBOOT_SLAVE_UCODE_SIZE);
+ out_be32((void *)srio-atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[2].riwtar,
+ CONFIG_SRIOBOOT_SLAVE_UCODE_LAW_PHYS 12);
+ out_be32((void *)srio-atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[2].riwbar,
+ CONFIG_SRIOBOOT_SLAVE_UCODE_SRIO_PHYS 12);
+ out_be32((void *)srio-atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[2].riwar,
+ SRIO_IB_ATMU_AR
+ | atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_UCODE_SIZE));
}
#endif
diff --git a/board/freescale/common/p_corenet/law.c
b/board/freescale/common/p_corenet/law.c
index 1fbab4d..c4566dd 100644
--- a/board/freescale/common/p_corenet/law.c
+++ b/board/freescale/common/p_corenet/law.c
@@ -52,9 +52,13 @@ struct law_entry law_table[] = {
#if defined(CONFIG_SRIOBOOT_SLAVE_PORT0)
SET_LAW(CONFIG_SYS_SRIOBOOT_SLAVE_ADDR_PHYS,
LAW_SIZE_1M, LAW_TRGT_IF_RIO_1),
+ SET_LAW(CONFIG_SYS_SRIOBOOT_UCODE_ENV_ADDR_PHYS,
+ LAW_SIZE_1M, LAW_TRGT_IF_RIO_1),
#elif defined(CONFIG_SRIOBOOT_SLAVE_PORT1)
SET_LAW(CONFIG_SYS_SRIOBOOT_SLAVE_ADDR_PHYS,
LAW_SIZE_1M, LAW_TRGT_IF_RIO_2),
+ SET_LAW(CONFIG_SYS_SRIOBOOT_UCODE_ENV_ADDR_PHYS,
+ LAW_SIZE_1M, LAW_TRGT_IF_RIO_2),
#endif
#endif
};
diff --git a/board/freescale/common/p_corenet/tlb.c
b/board/freescale/common/p_corenet/tlb.c
index a8c8b3c..da21627 100644
---
[U-Boot] [PATCH 7/8 v3] powerpc/corenet_ds: Slave reads ENV from master when boot from SRIO
When boot from SRIO, slave's ENV can be stored in master's memory space,
then slave can fetch the ENV through SRIO interface.
NOTE: Because the slave can not erase, write master's NOR flash by SRIO
interface, so it can not modify the ENV parameters stored in
master's NOR flash using saveenv or other commands.
Master needs to:
1. Put the slave's ENV into it's own memory space.
2. Set an inbound SRIO window covered slave's ENV stored in master's
memory space.
Slave needs to:
1. Set a specific TLB entry in order to fetch ucode and ENV from master.
2. Set a LAW entry with the TargetID SRIO1 or SRIO2 for ucode and ENV.
Signed-off-by: Liu Gang gang@freescale.com
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
Changes in v2:
- Subject changed to powerpc/corenet_ds.
- Update the README for CONFIG_ENV_IS_IN_REMOTE.
- Use (void *) instead of (u32) when calling out_be32().
- Use NOR flash instead of Nor flash.
- Get rid of the base address + offset notation. Use C structs
instead.
- Get rid of hard coded magic numbers. Use macro instead.
- Use debug() instead of printf().
- Some code styles changed.
Changes in v3:
- No
README | 18 +
arch/powerpc/cpu/mpc8xxx/srio.c | 17
common/Makefile |1 +
common/cmd_nvedit.c |3 +-
common/env_remote.c | 79 +++
include/configs/corenet_ds.h| 13 ++
6 files changed, 130 insertions(+), 1 deletions(-)
create mode 100644 common/env_remote.c
diff --git a/README b/README
index 719cc20..ab61ed2 100644
--- a/README
+++ b/README
@@ -2943,6 +2943,24 @@ to save the current settings.
environment area within the total memory of your DataFlash placed
at the specified address.
+- CONFIG_ENV_IS_IN_REMOTE:
+
+ Define this if you have a remote memory space which you
+ want to use for the local device's environment.
+
+ - CONFIG_ENV_ADDR:
+ - CONFIG_ENV_SIZE:
+
+ These two #defines specify the address and size of the
+ environment area within the remote memory space. The
+ local device can get the environment from remote memory
+ space by SRIO or other links.
+
+BE CAREFUL! For some special cases, the local device can not use
+saveenv command. For example, the local device will get the
+environment stored in a remote NOR flash by SRIO link, but it can
+not erase, write this NOR flash by SRIO interface.
+
- CONFIG_ENV_IS_IN_NAND:
Define this if you have a NAND device which you want to use
diff --git a/arch/powerpc/cpu/mpc8xxx/srio.c b/arch/powerpc/cpu/mpc8xxx/srio.c
index e593f22..5694561 100644
--- a/arch/powerpc/cpu/mpc8xxx/srio.c
+++ b/arch/powerpc/cpu/mpc8xxx/srio.c
@@ -150,5 +150,22 @@ void srio_boot_master(void)
.port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[2].riwar,
SRIO_IB_ATMU_AR
| atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_UCODE_SIZE));
+
+ /* configure inbound window for slave's ENV */
+ debug(SRIOBOOT - MASTER: Inbound window for slave's ENV;
+ Local = 0x%llx, Siro = 0x%llx, Size = 0x%x\n,
+ CONFIG_SRIOBOOT_SLAVE_ENV_LAW_PHYS,
+ CONFIG_SRIOBOOT_SLAVE_ENV_SRIO_PHYS,
+ CONFIG_SRIOBOOT_SLAVE_ENV_SIZE);
+ out_be32((void *)srio-atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[3].riwtar,
+ CONFIG_SRIOBOOT_SLAVE_ENV_LAW_PHYS 12);
+ out_be32((void *)srio-atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[3].riwbar,
+ CONFIG_SRIOBOOT_SLAVE_ENV_SRIO_PHYS 12);
+ out_be32((void *)srio-atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[3].riwar,
+ SRIO_IB_ATMU_AR
+ | atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_ENV_SIZE));
}
#endif
diff --git a/common/Makefile b/common/Makefile
index 2d9ae8c..bd9e8a3 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -58,6 +58,7 @@ COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o
COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o
COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o
COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o
+COBJS-$(CONFIG_ENV_IS_IN_REMOTE) += env_remote.o
COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o
# command
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 20080dc..359d1bf 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -65,9 +65,10 @@ DECLARE_GLOBAL_DATA_PTR;
!defined(CONFIG_ENV_IS_IN_NVRAM) \
!defined(CONFIG_ENV_IS_IN_ONENAND) \
!defined(CONFIG_ENV_IS_IN_SPI_FLASH) \
+ !defined(CONFIG_ENV_IS_IN_REMOTE)\
!defined(CONFIG_ENV_IS_NOWHERE)
# error Define one of CONFIG_ENV_IS_IN_{EEPROM|FLASH|DATAFLASH|ONENAND|\
[U-Boot] [PATCH 3/8 v3] powerpc/corenet_ds: Document for the boot from SRIO
This document describes the implementation of the boot from SRIO, includes the introduction of envionment, an example based on P4080DS platform, an example of the slave's RCW, and the description about how to use this feature. Signed-off-by: Liu Gang gang@freescale.com --- Changes in v2: - Subject changed to powerpc/corenet_ds. - Change the name of the document for corenet platform. Changes in v3: - No doc/README.srio-boot-corenet | 103 ++ 1 files changed, 103 insertions(+), 0 deletions(-) create mode 100644 doc/README.srio-boot-corenet diff --git a/doc/README.srio-boot-corenet b/doc/README.srio-boot-corenet new file mode 100644 index 000..56b094c --- /dev/null +++ b/doc/README.srio-boot-corenet @@ -0,0 +1,103 @@ +-- +SRIO Boot on Corenet Platforms +-- + +For some PowerPC processors with SRIO interface, boot location can be configured +to SRIO by RCW. The processor booting from SRIO can do without flash for u-boot +image, ucode and ENV. All the images can be fetched from another processor's +memory space by SRIO link connected between them. + +This document describes the processes based on an example implemented on P4080DS +platforms and a RCW example with boot from SRIO configuration. + +Environment of the SRIO boot: + a) Master and slave can be SOCs in one board or SOCs in separate boards. + b) They are connected with SRIO links, whether 1x or 4x, and directly or + through switch system. + c) Only Master has NorFlash for booting, and all the Master's and Slave's + U-Boot images, UCodes will be stored in this flash. + d) Slave has its own EEPROM for RCW and PBI. + e) Slave's RCW should configure the SerDes for SRIO boot port, set the boot + location to SRIO, and holdoff all the cores if needed. + + ----- --- + | | | | | | + | | | | | | + | NorFlash|-| Master |SRIO | Slave |[EEPROM] + | | | |===| | + | | | | | | + ----- --- + +The example based on P4080DS platform: + Two P4080DS platforms can be used to implement the boot from SRIO. Their SRIO + ports 0 will be connected directly and will be used for the boot from SRIO. + + 1. Slave's RCW example for boot from SRIO port 0 and core 0 not in holdoff. + : aa55 aa55 010e 0100 0c58 + 0010: 1818 1818 7440 4000 2000 + 0020: f400 0100 + 0030: 0083 + 0040: 0813 8040 698b 93fe + + 2. Slave's RCW example for boot from SRIO port 0 and all cores in holdoff. + : aa55 aa55 010e 0100 0c58 + 0010: 1818 1818 7440 4000 2000 + 0020: f440 0100 + 0030: 0083 + 0040: 0813 8040 063c 778f + + 3. Sequence in Step by Step. + a) Update RCW for slave with boot from SRIO port 0 configuration. + b) Program slave's U-Boot image, UCode, and ENV parameters into master's + NorFlash. + c) Start up master and it will boot up normally from its NorFlash. + Then, it will finish necessary configurations for slave's boot from + SRIO port 0. + d) Master will set inbound SRIO windows covered slave's U-Boot image stored + in master's NorFlash. + e) Master will set an inbound SRIO window covered slave's UCode stored in + master's NorFlash. + f) Master will set an inbound SRIO window covered slave's ENV stored in + master's NorFlash. + g) If need to release slave's core, master will set outbound SRIO windows + in order to configure slave's registers for the core's releasing. + h) If all cores of slave in holdoff, slave should be powered on before all + the above master's steps, and wait to be released by master. If not all + cores in holdoff, that means core 0 will start up normally, slave should + be powered on after all the above master's steps. In the startup phase + of the slave from SRIO, it will finish some necessary configurations. + i) Slave will set a specific TLB entry for the boot process. + j) Slave
[U-Boot] [PATCH 4/8 v3] powerpc/corenet_ds: Master module for boot from SRIO
For the powerpc processors with SRIO interface, boot location can be configured
from SRIO1 or SRIO2 by RCW. The processor booting from SRIO can do without flash
for u-boot image. The image can be fetched from another processor's memory
space by SRIO link connected between them.
The processor boots from SRIO is slave, the processor boots from normal flash
memory space and can help slave to boot from its memory space is master.
They are different environments and requirements:
master:
1. NOR flash for its own u-boot image, ucode and ENV space.
2. Slave's u-boot image in master NOR flash.
3. Normally boot from local NOR flash.
4. Configure SRIO switch system if needed.
slave:
1. Just has EEPROM for RCW. No flash for u-boot image, ucode and ENV.
2. Boot location should be set to SRIO1 or SRIO2 by RCW.
3. RCW should configure the SerDes, SRIO interfaces correctly.
4. Slave must be powered on after master's boot.
For the master module, need to finish these processes:
1. Initialize the SRIO port and address space.
2. Set inbound SRIO windows covered slave's u-boot image stored in
master's NOR flash.
3. Master's u-boot image should be generated specifically by
make _SRIOBOOT_MASTER_config
4. Master must boot first, and then slave can be powered on.
Signed-off-by: Liu Gang gang@freescale.com
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
Changes in v2:
- Subject changed to powerpc/corenet_ds.
- Use (void *) instead of (u32) when calling out_be32().
- Use NOR flash instead of Nor flash.
- Get rid of the base address + offset notation. Use C structs
instead.
- Get rid of hard coded magic numbers. Use macro instead.
- Use debug() instead of printf().
Changes in v3:
- No
arch/powerpc/cpu/mpc85xx/cpu_init.c |6 ++-
arch/powerpc/cpu/mpc8xxx/srio.c | 51 +++
arch/powerpc/include/asm/fsl_srio.h | 61 +
arch/powerpc/include/asm/immap_85xx.h |3 ++
boards.cfg|3 ++
include/configs/corenet_ds.h | 18 ++
6 files changed, 140 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsl_srio.h
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 2e4a06c..97a7fe1 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -37,6 +37,7 @@
#include asm/mmu.h
#include asm/fsl_law.h
#include asm/fsl_serdes.h
+#include asm/fsl_srio.h
#include linux/compiler.h
#include mp.h
#ifdef CONFIG_SYS_QE_FMAN_FW_IN_NAND
@@ -48,8 +49,6 @@
DECLARE_GLOBAL_DATA_PTR;
-extern void srio_init(void);
-
#ifdef CONFIG_QE
extern qe_iop_conf_t qe_iop_conf_tab[];
extern void qe_config_iopin(u8 port, u8 pin, int dir,
@@ -443,6 +442,9 @@ skip_l2:
#ifdef CONFIG_SYS_SRIO
srio_init();
+#ifdef CONFIG_SRIOBOOT_MASTER
+ srio_boot_master();
+#endif
#endif
#if defined(CONFIG_MP)
diff --git a/arch/powerpc/cpu/mpc8xxx/srio.c b/arch/powerpc/cpu/mpc8xxx/srio.c
index e46d328..77fa32f 100644
--- a/arch/powerpc/cpu/mpc8xxx/srio.c
+++ b/arch/powerpc/cpu/mpc8xxx/srio.c
@@ -21,6 +21,10 @@
#include config.h
#include asm/fsl_law.h
#include asm/fsl_serdes.h
+#include asm/fsl_srio.h
+
+#define SRIO_PORT_ACCEPT_ALL 0x1001
+#define SRIO_IB_ATMU_AR 0x80f55000
#if defined(CONFIG_FSL_CORENET)
#define _DEVDISR_SRIO1 FSL_CORENET_DEVDISR_SRIO1
@@ -84,3 +88,50 @@ void srio_init(void)
setbits_be32(gur-devdisr, _DEVDISR_RMU);
}
}
+
+#ifdef CONFIG_SRIOBOOT_MASTER
+void srio_boot_master(void)
+{
+ struct ccsr_rio *srio = (void *)CONFIG_SYS_FSL_SRIO_ADDR;
+
+ /* set port accept-all */
+ out_be32((void *)srio-impl.port[CONFIG_SRIOBOOT_MASTER_PORT].ptaacr,
+ SRIO_PORT_ACCEPT_ALL);
+
+ debug(SRIOBOOT - MASTER: Master port [ %d ] for srio boot.\n,
+ CONFIG_SRIOBOOT_MASTER_PORT);
+ /* configure inbound window5 for slave's u-boot image */
+ debug(SRIOBOOT - MASTER: Inbound window 5 for slave's image;
+ Local = 0x%llx, Srio = 0x%llx, Size = 0x%x\n,
+ (u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_LAW_PHYS1,
+ (u64)CONFIG_SRIOBOOT_SLAVE_IMAGE_SRIO_PHYS1,
+ CONFIG_SRIOBOOT_SLAVE_IMAGE_SIZE);
+ out_be32((void *)srio-atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[0].riwtar,
+ CONFIG_SRIOBOOT_SLAVE_IMAGE_LAW_PHYS1 12);
+ out_be32((void *)srio-atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[0].riwbar,
+ CONFIG_SRIOBOOT_SLAVE_IMAGE_SRIO_PHYS1 12);
+ out_be32((void *)srio-atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].inbw[0].riwar,
+ SRIO_IB_ATMU_AR
+
[U-Boot] [PATCH 8/8 v3] powerpc/corenet_ds: Slave core in holdoff when boot from SRIO
When boot from SRIO, slave's core can be in holdoff after powered on for
some specific requirements. Master can release the slave's core at the
right time by SRIO interface.
Master needs to:
1. Set outbound SRIO windows in order to configure slave's registers
for the core's releasing.
2. Check the SRIO port status when release slave core, if no errors,
will implement the process of the slave core's releasing.
Slave needs to:
1. Set all the cores in holdoff by RCW.
2. Be powered on before master's boot.
Signed-off-by: Liu Gang gang@freescale.com
Signed-off-by: Shaohui Xie shaohui@freescale.com
---
Changes in v2:
- Subject changed to powerpc/corenet_ds.
- Use (void *) instead of (u32) when calling out_be32().
- Use NOR flash instead of Nor flash.
- Get rid of the base address + offset notation. Use C structs
instead.
- Get rid of hard coded magic numbers. Use macro instead.
- Use debug() instead of printf().
Changes in v3:
- No
arch/powerpc/cpu/mpc85xx/cpu_init.c |3 +
arch/powerpc/cpu/mpc8xxx/srio.c | 125 +++
arch/powerpc/include/asm/fsl_srio.h |3 +
include/configs/corenet_ds.h|4 +
4 files changed, 135 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c
b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 97a7fe1..2cd5db7 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -444,6 +444,9 @@ skip_l2:
srio_init();
#ifdef CONFIG_SRIOBOOT_MASTER
srio_boot_master();
+#ifdef CONFIG_SRIOBOOT_SLAVE_HOLDOFF
+ srio_boot_master_release_slave();
+#endif
#endif
#endif
diff --git a/arch/powerpc/cpu/mpc8xxx/srio.c b/arch/powerpc/cpu/mpc8xxx/srio.c
index 5694561..c7f3949 100644
--- a/arch/powerpc/cpu/mpc8xxx/srio.c
+++ b/arch/powerpc/cpu/mpc8xxx/srio.c
@@ -25,6 +25,12 @@
#define SRIO_PORT_ACCEPT_ALL 0x1001
#define SRIO_IB_ATMU_AR 0x80f55000
+#define SRIO_OB_ATMU_AR_MAINT 0x80077000
+#define SRIO_OB_ATMU_AR_RW 0x80045000
+#define SRIO_LCSBA1CSR_OFFSET 0x5c
+#define SRIO_MAINT_WIN_SIZE 0x100 /* 16M */
+#define SRIO_RW_WIN_SIZE 0x10 /* 1M */
+#define SRIO_LCSBA1CSR 0x6000
#if defined(CONFIG_FSL_CORENET)
#define _DEVDISR_SRIO1 FSL_CORENET_DEVDISR_SRIO1
@@ -168,4 +174,123 @@ void srio_boot_master(void)
SRIO_IB_ATMU_AR
| atmu_size_mask(CONFIG_SRIOBOOT_SLAVE_ENV_SIZE));
}
+
+#ifdef CONFIG_SRIOBOOT_SLAVE_HOLDOFF
+void srio_boot_master_release_slave(void)
+{
+ struct ccsr_rio *srio = (void *)CONFIG_SYS_FSL_SRIO_ADDR;
+ u32 escsr;
+ debug(SRIOBOOT - MASTER:
+ Check the port status and release slave core ...\n);
+
+ escsr = in_be32((void *)srio-lp_serial
+ .port[CONFIG_SRIOBOOT_MASTER_PORT].pescsr);
+ if (escsr 0x2) {
+ if (escsr 0x10100) {
+ debug(SRIOBOOT - MASTER: Port [ %d ] is error.\n,
+ CONFIG_SRIOBOOT_MASTER_PORT);
+ } else {
+ debug(SRIOBOOT - MASTER:
+ Port [ %d ] is ready, now release
slave's core ...\n,
+ CONFIG_SRIOBOOT_MASTER_PORT);
+ /*
+* configure outbound window
+* with maintenance attribute to set slave's LCSBA1CSR
+*/
+ out_be32((void *)srio-atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT]
+ .outbw[1].rowtar, 0);
+ out_be32((void *)srio-atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT]
+ .outbw[1].rowtear, 0);
+ if (CONFIG_SRIOBOOT_MASTER_PORT)
+ out_be32((void *)srio-atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT]
+ .outbw[1].rowbar,
+ CONFIG_SYS_SRIO2_MEM_PHYS 12);
+ else
+ out_be32((void *)srio-atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT]
+ .outbw[1].rowbar,
+ CONFIG_SYS_SRIO1_MEM_PHYS 12);
+ out_be32((void *)srio-atmu
+ .port[CONFIG_SRIOBOOT_MASTER_PORT]
+ .outbw[1].rowar,
+ SRIO_OB_ATMU_AR_MAINT
+ | atmu_size_mask(SRIO_MAINT_WIN_SIZE));
+
+ /*
+* configure outbound window
+* with R/W attribute to set slave's BRR
+*/
+
[U-Boot] [PATCH 1/8 v3] powerpc/srio: Rewrite the struct ccsr_rio
Rewrite this struct for the support of two ports and two message
units registers.
Signed-off-by: Liu Gang gang@freescale.com
---
Changes in v2:
- Change the subject and commit message.
- Remove the offsets in the comments.
- Rewrite the struct for the support of two ports
and two message units registers.
Changes in v3:
- Move some SRIO macros to the appropriate board
configure header files.
arch/powerpc/include/asm/immap_85xx.h | 384 +++--
include/configs/MPC8548CDS.h |5 +
include/configs/MPC8568MDS.h |5 +
include/configs/MPC8569MDS.h |5 +
include/configs/P2020DS.h |5 +
include/configs/P2041RDB.h|3 +
include/configs/corenet_ds.h |7 +
7 files changed, 254 insertions(+), 160 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_85xx.h
b/arch/powerpc/include/asm/immap_85xx.h
index 9b08cb8..42db6c9 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1353,171 +1353,235 @@ typedef struct ccsr_cpm {
} ccsr_cpm_t;
#endif
-/* RapidIO Registers */
-typedef struct ccsr_rio {
- u32 didcar; /* Device Identity Capability */
- u32 dicar; /* Device Information Capability */
- u32 aidcar; /* Assembly Identity Capability */
- u32 aicar; /* Assembly Information Capability */
- u32 pefcar; /* Processing Element Features Capability */
- u32 spicar; /* Switch Port Information Capability */
- u32 socar; /* Source Operations Capability */
- u32 docar; /* Destination Operations Capability */
+#ifdef CONFIG_SYS_SRIO
+/* Architectural regsiters */
+struct rio_arch {
+ u32 didcar; /* Device Identity CAR */
+ u32 dicar; /* Device Information CAR */
+ u32 aidcar; /* Assembly Identity CAR */
+ u32 aicar; /* Assembly Information CAR */
+ u32 pefcar; /* Processing Element Features CAR */
+ u8 res0[4];
+ u32 socar; /* Source Operations CAR */
+ u32 docar; /* Destination Operations CAR */
u8 res1[32];
- u32 msr;/* Mailbox Cmd And Status */
- u32 pwdcsr; /* Port-Write Doorbell Cmd And Status */
+ u32 mcsr; /* Mailbox CSR */
+ u32 pwdcsr; /* Port-Write and Doorbell CSR */
u8 res2[4];
u32 pellccsr; /* Processing Element Logic Layer CCSR */
u8 res3[12];
- u32 lcsbacsr; /* Local Cfg Space Base Addr Cmd Status */
- u32 bdidcsr;/* Base Device ID Cmd Status */
+ u32 lcsbacsr; /* Local Configuration Space BACSR */
+ u32 bdidcsr;/* Base Device ID CSR */
u8 res4[4];
- u32 hbdidlcsr; /* Host Base Device ID Lock Cmd Status */
- u32 ctcsr; /* Component Tag Cmd Status */
- u8 res5[144];
- u32 pmbh0csr; /* Port Maint. Block Hdr 0 Cmd Status */
- u8 res6[28];
- u32 pltoccsr; /* Port Link Time-out Ctrl Cmd Status */
- u32 prtoccsr; /* Port Response Time-out Ctrl Cmd Status */
- u8 res7[20];
- u32 pgccsr; /* Port General Cmd Status */
- u32 plmreqcsr; /* Port Link Maint. Request Cmd Status */
- u32 plmrespcsr; /* Port Link Maint. Response Cmd Status */
- u32 plascsr;/* Port Local Ackid Status Cmd Status */
- u8 res8[12];
- u32 pescsr; /* Port Error Status Cmd Status */
- u32 pccsr; /* Port Control Cmd Status */
- u8 res9[65184];
- u32 cr; /* Port Control Cmd Status */
- u8 res10[12];
- u32 pcr;/* Port Configuration */
- u32 peir; /* Port Error Injection */
- u8 res11[3048];
- u32 rowtar0;/* RIO Outbound Window Translation Addr 0 */
- u8 res12[12];
- u32 rowar0; /* RIO Outbound Attrs 0 */
- u8 res13[12];
- u32 rowtar1;/* RIO Outbound Window Translation Addr 1 */
- u8 res14[4];
- u32 rowbar1;/* RIO Outbound Window Base Addr 1 */
- u8 res15[4];
- u32 rowar1; /* RIO Outbound Attrs 1 */
- u8 res16[12];
- u32 rowtar2;/* RIO Outbound Window Translation Addr 2 */
- u8 res17[4];
- u32 rowbar2;/* RIO Outbound Window Base Addr 2 */
- u8 res18[4];
- u32 rowar2; /* RIO Outbound Attrs 2 */
- u8 res19[12];
- u32 rowtar3;/* RIO Outbound Window Translation Addr 3 */
- u8 res20[4];
- u32 rowbar3;/* RIO Outbound Window Base Addr 3 */
- u8
Re: [U-Boot] [PATCH] sc520: fix build warning about unused temp var
Hi Mike, On 03/06/2012 08:55 AM, Mike Frysinger wrote: Building the eNET_SRAM board fails for me: sc520_timer.c: In function 'sc520_udelay': sc520_timer.c:81:7: error: variable 'temp' set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors make[1]: *** [sc520_timer.o] Error 1 Signed-off-by: Mike Frysinger vap...@gentoo.org Applied Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-x86/master
Hi Wolfgang, The following changes since commit fca94c3fd5deef33442813475a5af1650f2d2830: integrator: remove fragile delay loop from PCI code (2012-03-04 21:15:31 +0100) are available in the git repository at: git://git.denx.de/u-boot-x86.git master Mike Frysinger (1): sc520: fix build warning about unused temp var arch/x86/cpu/sc520/sc520_timer.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] IXP: Make IXP compile with arm-linux-gnueabi- and fix it
On 03/06/2012 09:19 AM, Marek Vasut wrote:
Dear Michael Schwingen,
On 03/06/2012 01:18 AM, Marek Vasut wrote:
This series of patches makes ARM/IXP platform compile with usual
arm-linux-gnueabi- toolchain. Also, fix the IXP build errors detected
with gcc4.6.
Marek Vasut (6):
Examples: Properly append LDFLAGS to LD command
IXP: Make IXP buildable with arm-linux- toolchains
IXP: Fix missing MACH_TYPE_{ACTUX?,PNB3,DVLHOST}
IXP: Squash warnings in IXP NPE
IXP: Move PDNB3 and SCPU from Makefile to boards.cfg
IXP: Fix NAND build warning on PDNB3 and SCPU
Makefile | 12
arch/arm/cpu/ixp/config.mk |3 +++
arch/arm/cpu/ixp/npe/IxEthAcc.c |2 +-
arch/arm/cpu/ixp/npe/IxEthDBAPISupport.c |3 ---
arch/arm/cpu/ixp/npe/IxQMgrDispatcher.c |3 ---
board/actux1/actux1.c|2 --
board/actux2/actux2.c|2 --
board/actux3/actux3.c|2 --
board/actux4/actux4.c|2 --
board/dvlhost/dvlhost.c |2 --
board/prodrive/pdnb3/nand.c |9 ++---
board/prodrive/pdnb3/pdnb3.c |3 ---
boards.cfg |2 ++
examples/standalone/Makefile |2 +-
include/configs/actux1.h |2 ++
include/configs/actux2.h |2 ++
include/configs/actux3.h |2 ++
include/configs/actux4.h |2 ++
include/configs/dvlhost.h|2 ++
include/configs/pdnb3.h |2 ++
20 files changed, 25 insertions(+), 36 deletions(-)
Cc: Bryan Hundvenbryanhund...@gmail.com
Cc: Michael Schwingenrincew...@discworld.dascon.de
Can you guys please verify if after applying these patches, IXP builds
with your armeb toolchains?
Also, can you please try if binaries built with usual arm-linux-gnueabi-
toolchain (linaro, codesourcery whatever ...) now produce bootable result
(this is very important, I'd be happy if they did so we can get rid of
that whole armeb compiler stuff)?
Sure, but this might take me some weeks. Thanks for the effort!
cu
Michael
so I'll push these upstream and you'll let me know if something got broken
later, this fix is better than nothing, ok?
Fine with me. Is upstream master or pxa/ixp?
cu
Michael
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/7 V2] IXP: Make IXP compile with arm-linux-gnueabi- and fix it
From: Marek Vasut marek.va...@gmail.com
This series of patches makes ARM/IXP platform compile with usual
arm-linux-gnueabi- toolchain. Also, fix the IXP build errors detected with
gcc4.6.
Marek Vasut (7):
Examples: Properly append LDFLAGS to LD command
IXP: Make IXP buildable with arm-linux- toolchains
IXP: Fix missing MACH_TYPE_{ACTUX?,PNB3,DVLHOST}
IXP: Squash warnings in IXP NPE
IXP: Move PDNB3 and SCPU from Makefile to boards.cfg
IXP: Fix NAND build warning on PDNB3 and SCPU
IXP: Fix GPIO_INT_ACT_LOW_SET()
Makefile | 12
arch/arm/cpu/ixp/config.mk |3 +++
arch/arm/cpu/ixp/npe/IxEthAcc.c |2 +-
arch/arm/cpu/ixp/npe/IxEthDBAPISupport.c |3 ---
arch/arm/cpu/ixp/npe/IxQMgrDispatcher.c |3 ---
arch/arm/include/asm/arch-ixp/ixp425.h | 10 --
board/actux1/actux1.c|2 --
board/actux2/actux2.c|2 --
board/actux3/actux3.c|2 --
board/actux4/actux4.c|2 --
board/dvlhost/dvlhost.c |2 --
board/prodrive/pdnb3/nand.c | 16 +++-
board/prodrive/pdnb3/pdnb3.c |3 ---
boards.cfg |2 ++
examples/standalone/Makefile |2 +-
include/configs/actux1.h |2 ++
include/configs/actux2.h |2 ++
include/configs/actux3.h |2 ++
include/configs/actux4.h |2 ++
include/configs/dvlhost.h|2 ++
include/configs/pdnb3.h |2 ++
21 files changed, 30 insertions(+), 48 deletions(-)
Cc: Bryan Hundven bryanhund...@gmail.com
Cc: Michael Schwingen rincew...@discworld.dascon.de
V2: Fix remaining issues in nand.c and actux4
--
1.7.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/7 RESEND] Examples: Properly append LDFLAGS to LD command
The LD command in examples/standalone/Makefile ignored platform specific LDFLAGS setup. Pass these LDFLAGS to the command. Signed-off-by: Marek Vasut ma...@denx.de Cc: Bryan Hundven bryanhund...@gmail.com Cc: Michael Schwingen rincew...@discworld.dascon.de --- examples/standalone/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/examples/standalone/Makefile b/examples/standalone/Makefile index e23865b..baaa2fb 100644 --- a/examples/standalone/Makefile +++ b/examples/standalone/Makefile @@ -96,7 +96,7 @@ $(LIB): $(obj).depend $(LIBOBJS) $(ELF): $(obj)%: $(obj)%.o $(LIB) - $(LD) -g -Ttext $(CONFIG_STANDALONE_LOAD_ADDR) \ + $(LD) $(LDFLAGS) -g -Ttext $(CONFIG_STANDALONE_LOAD_ADDR) \ -o $@ -e $(SYM_PREFIX)$(notdir $(:.o=)) $ $(LIB) \ -L$(gcclibdir) -lgcc -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/7 RESEND] IXP: Make IXP buildable with arm-linux- toolchains
Add -EB flag to LD to switch endianness of the linker. This should make armeb targets buildable again. Also, make use of U-Boot's internal libgcc instead of toolchain's one, this works around the use of libraries from GCC, which might be little endian. Signed-off-by: Marek Vasut ma...@denx.de Cc: Bryan Hundven bryanhund...@gmail.com Cc: Michael Schwingen rincew...@discworld.dascon.de --- arch/arm/cpu/ixp/config.mk |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/cpu/ixp/config.mk b/arch/arm/cpu/ixp/config.mk index 9149665..b02e8af 100644 --- a/arch/arm/cpu/ixp/config.mk +++ b/arch/arm/cpu/ixp/config.mk @@ -28,6 +28,9 @@ PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float -mbig-endian PLATFORM_CPPFLAGS += -mbig-endian -march=armv5te -mtune=strongarm1100 +PLATFORM_LDFLAGS += -EB +USE_PRIVATE_LIBGCC = yes + # -fdata-sections triggers section .bss overlaps section .rel.dyn linker error PLATFORM_RELFLAGS += -ffunction-sections LDFLAGS_u-boot += --gc-sections -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/7 RESEND] IXP: Fix missing MACH_TYPE_{ACTUX?, PNB3, DVLHOST}
These symbols are no longer defined in Linux-ARM's mach-types files. Replace
these with CONFIG_MACH_TYPE instead.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Bryan Hundven bryanhund...@gmail.com
Cc: Michael Schwingen rincew...@discworld.dascon.de
---
board/actux1/actux1.c|2 --
board/actux2/actux2.c|2 --
board/actux3/actux3.c|2 --
board/actux4/actux4.c|2 --
board/dvlhost/dvlhost.c |2 --
board/prodrive/pdnb3/pdnb3.c |3 ---
include/configs/actux1.h |2 ++
include/configs/actux2.h |2 ++
include/configs/actux3.h |2 ++
include/configs/actux4.h |2 ++
include/configs/dvlhost.h|2 ++
include/configs/pdnb3.h |2 ++
12 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/board/actux1/actux1.c b/board/actux1/actux1.c
index 2f631b7..bc68eb3 100644
--- a/board/actux1/actux1.c
+++ b/board/actux1/actux1.c
@@ -59,8 +59,6 @@ int board_early_init_f(void)
int board_init(void)
{
- gd-bd-bi_arch_number = MACH_TYPE_ACTUX1;
-
/* adress of boot parameters */
gd-bd-bi_boot_params = 0x0100;
diff --git a/board/actux2/actux2.c b/board/actux2/actux2.c
index 9040a09..9e9e600 100644
--- a/board/actux2/actux2.c
+++ b/board/actux2/actux2.c
@@ -59,8 +59,6 @@ int board_early_init_f(void)
int board_init(void)
{
- gd-bd-bi_arch_number = MACH_TYPE_ACTUX2;
-
/* adress of boot parameters */
gd-bd-bi_boot_params = 0x0100;
diff --git a/board/actux3/actux3.c b/board/actux3/actux3.c
index 64e5215..7559c1d 100644
--- a/board/actux3/actux3.c
+++ b/board/actux3/actux3.c
@@ -57,8 +57,6 @@ int board_early_init_f(void)
int board_init(void)
{
- gd-bd-bi_arch_number = MACH_TYPE_ACTUX3;
-
/* adress of boot parameters */
gd-bd-bi_boot_params = 0x0100;
diff --git a/board/actux4/actux4.c b/board/actux4/actux4.c
index d20d881..6303c1e 100644
--- a/board/actux4/actux4.c
+++ b/board/actux4/actux4.c
@@ -54,8 +54,6 @@ int board_early_init_f(void)
int board_init(void)
{
- gd-bd-bi_arch_number = MACH_TYPE_ACTUX4;
-
/* adress of boot parameters */
gd-bd-bi_boot_params = 0x0100;
diff --git a/board/dvlhost/dvlhost.c b/board/dvlhost/dvlhost.c
index 561e47f..c2c67cc 100644
--- a/board/dvlhost/dvlhost.c
+++ b/board/dvlhost/dvlhost.c
@@ -46,8 +46,6 @@ int board_early_init_f(void)
int board_init(void)
{
- gd-bd-bi_arch_number = MACH_TYPE_DVLHOST;
-
/* adress of boot parameters */
gd-bd-bi_boot_params = 0x0100;
diff --git a/board/prodrive/pdnb3/pdnb3.c b/board/prodrive/pdnb3/pdnb3.c
index 3aaebf2..d3ee133 100644
--- a/board/prodrive/pdnb3/pdnb3.c
+++ b/board/prodrive/pdnb3/pdnb3.c
@@ -46,9 +46,6 @@ static unsigned long old_val = 0;
*/
int board_init(void)
{
- /* arch number of PDNB3 */
- gd-bd-bi_arch_number = MACH_TYPE_PDNB3;
-
/* adress of boot parameters */
gd-bd-bi_boot_params = 0x0100;
diff --git a/include/configs/actux1.h b/include/configs/actux1.h
index 00780d0..bdd2239 100644
--- a/include/configs/actux1.h
+++ b/include/configs/actux1.h
@@ -29,6 +29,8 @@
#define CONFIG_IXP425 1
#define CONFIG_ACTUX1 1
+#defineCONFIG_MACH_TYPE1479
+
#define CONFIG_DISPLAY_CPUINFO 1
#define CONFIG_DISPLAY_BOARDINFO 1
diff --git a/include/configs/actux2.h b/include/configs/actux2.h
index cb97434..c55571c 100644
--- a/include/configs/actux2.h
+++ b/include/configs/actux2.h
@@ -29,6 +29,8 @@
#define CONFIG_IXP425 1
#define CONFIG_ACTUX2 1
+#defineCONFIG_MACH_TYPE1480
+
#define CONFIG_DISPLAY_CPUINFO 1
#define CONFIG_DISPLAY_BOARDINFO 1
diff --git a/include/configs/actux3.h b/include/configs/actux3.h
index 816d982..78ee2b5 100644
--- a/include/configs/actux3.h
+++ b/include/configs/actux3.h
@@ -29,6 +29,8 @@
#define CONFIG_IXP425 1
#define CONFIG_ACTUX3 1
+#defineCONFIG_MACH_TYPE1481
+
#define CONFIG_DISPLAY_CPUINFO 1
#define CONFIG_DISPLAY_BOARDINFO 1
diff --git a/include/configs/actux4.h b/include/configs/actux4.h
index 90badd3..c1105df 100644
--- a/include/configs/actux4.h
+++ b/include/configs/actux4.h
@@ -29,6 +29,8 @@
#define CONFIG_IXP425 1
#define CONFIG_ACTUX4 1
+#defineCONFIG_MACH_TYPE1532
+
#define CONFIG_DISPLAY_CPUINFO 1
#define CONFIG_DISPLAY_BOARDINFO 1
diff --git a/include/configs/dvlhost.h b/include/configs/dvlhost.h
index 86fecd1..4eda91e 100644
--- a/include/configs/dvlhost.h
+++ b/include/configs/dvlhost.h
@@ -30,6 +30,8 @@
#define CONFIG_IXP425 1
#define CONFIG_DVLHOST 1
+#defineCONFIG_MACH_TYPE1343
+
#define CONFIG_DISPLAY_CPUINFO 1
#define
[U-Boot] [PATCH 4/7 RESEND] IXP: Squash warnings in IXP NPE
IxEthAcc.c: In function ‘ixEthAccInit’:
IxEthAcc.c:105:21: warning: comparison between ‘IxEthDBStatus’ and ‘enum
anonymous’ [-Wenum-compare]
IxEthDBAPISupport.c: In function ‘ixEthDBPortAddressSet’:
IxEthDBAPISupport.c:633:18: warning: variable ‘ackPortAddressLock’ set but not
used [-Wunused-but-set-variable]
IxQMgrDispatcher.c: In function ‘ixQMgrLLPShow’:
IxQMgrDispatcher.c:1194:18: warning: variable ‘q’ set but not used
[-Wunused-but-set-variable]
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Bryan Hundven bryanhund...@gmail.com
Cc: Michael Schwingen rincew...@discworld.dascon.de
---
arch/arm/cpu/ixp/npe/IxEthAcc.c |2 +-
arch/arm/cpu/ixp/npe/IxEthDBAPISupport.c |3 ---
arch/arm/cpu/ixp/npe/IxQMgrDispatcher.c |3 ---
3 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/arm/cpu/ixp/npe/IxEthAcc.c b/arch/arm/cpu/ixp/npe/IxEthAcc.c
index 061b24b..20d3d9e 100644
--- a/arch/arm/cpu/ixp/npe/IxEthAcc.c
+++ b/arch/arm/cpu/ixp/npe/IxEthAcc.c
@@ -102,7 +102,7 @@ PUBLIC IxEthAccStatus ixEthAccInit()
/*
* Initialize Control plane
*/
- if (ixEthDBInit() != IX_ETH_ACC_SUCCESS)
+ if (ixEthDBInit() != IX_ETH_DB_SUCCESS)
{
IX_ETH_ACC_WARNING_LOG(ixEthAccInit: EthDB init failed\n, 0, 0, 0, 0,
0, 0);
diff --git a/arch/arm/cpu/ixp/npe/IxEthDBAPISupport.c
b/arch/arm/cpu/ixp/npe/IxEthDBAPISupport.c
index 25633a3..36bc200 100644
--- a/arch/arm/cpu/ixp/npe/IxEthDBAPISupport.c
+++ b/arch/arm/cpu/ixp/npe/IxEthDBAPISupport.c
@@ -630,7 +630,6 @@ IX_ETH_DB_PUBLIC
IxEthDBStatus ixEthDBPortAddressSet(IxEthDBPortId portID, IxEthDBMacAddr
*macAddr)
{
IxNpeMhMessage message;
-IxOsalMutex *ackPortAddressLock;
IX_STATUS result;
/* use this macro instead CHECK_PORT
@@ -644,8 +643,6 @@ IxEthDBStatus ixEthDBPortAddressSet(IxEthDBPortId portID,
IxEthDBMacAddr *macAdd
return IX_ETH_DB_PORT_UNINITIALIZED;
}
-ackPortAddressLock = ixEthDBPortInfo[portID].npeAckLock;
-
/* Operation stops here when Ethernet Learning is not enabled */
if(IX_FEATURE_CTRL_SWCONFIG_DISABLED ==
ixFeatureCtrlSwConfigurationCheck(IX_FEATURECTRL_ETH_LEARNING))
diff --git a/arch/arm/cpu/ixp/npe/IxQMgrDispatcher.c
b/arch/arm/cpu/ixp/npe/IxQMgrDispatcher.c
index 642e67a..9cb1439 100644
--- a/arch/arm/cpu/ixp/npe/IxQMgrDispatcher.c
+++ b/arch/arm/cpu/ixp/npe/IxQMgrDispatcher.c
@@ -1191,7 +1191,6 @@ ixQMgrLLPShow (int resetStats)
{
#ifndef NDEBUG
UINT8 i = 0;
-IxQMgrQInfo *q;
UINT32 intEnableRegVal = 0;
printf (Livelock statistics are printed on the fly.\n);
@@ -1200,8 +1199,6 @@ ixQMgrLLPShow (int resetStats)
for (i=0; i= IX_QMGR_MAX_LOW_QUE_TABLE_INDEX; i++)
{
-q = dispatchQInfo[i];
-
if (ixQMgrQTypes[i] != IX_QMGR_TYPE_REALTIME_OTHER)
{
printf ( %2d , i);
--
1.7.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/7 RESEND] IXP: Move PDNB3 and SCPU from Makefile to boards.cfg
Signed-off-by: Marek Vasut ma...@denx.de Cc: Bryan Hundven bryanhund...@gmail.com Cc: Michael Schwingen rincew...@discworld.dascon.de --- Makefile | 12 boards.cfg |2 ++ 2 files changed, 2 insertions(+), 12 deletions(-) diff --git a/Makefile b/Makefile index 11aac21..858ddb8 100644 --- a/Makefile +++ b/Makefile @@ -678,18 +678,6 @@ SX1_config:unconfig @$(MKCONFIG) -n $@ SX1 arm arm925t sx1 # -## XScale Systems -# - -pdnb3_config \ -scpu_config: unconfig - @mkdir -p $(obj)include - @if [ $(findstring scpu_,$@) ] ; then \ - echo #define CONFIG_SCPU $(obj)include/config.h ; \ - fi - @$(MKCONFIG) -n $@ -a pdnb3 arm ixp pdnb3 prodrive - -# ## ARM1176 Systems # smdk6400_noUSB_config \ diff --git a/boards.cfg b/boards.cfg index 28cc345..ade2034 100644 --- a/boards.cfg +++ b/boards.cfg @@ -244,6 +244,8 @@ actux2 arm ixp actux3 arm ixp actux4 arm ixp dvlhost arm ixp +pdnb3arm ixp pdnb3 prodrive +scpu arm ixp pdnb3 prodrive - pdnb3:SCPU balloon3 arm pxa lubbock arm pxa palmld arm pxa -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 7/7] IXP: Fix GPIO_INT_ACT_LOW_SET()
From: Marek Vasut marek.va...@gmail.com The GPIO_INT_ACT_LOW_SET was incorrectly handling interrupt lines higher than 7. This is due to the fact that there are two registers for total of 16 lines. Signed-off-by: Marek Vasut marek.va...@gmail.com Cc: Bryan Hundven bryanhund...@gmail.com Cc: Michael Schwingen rincew...@discworld.dascon.de --- arch/arm/include/asm/arch-ixp/ixp425.h | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/include/asm/arch-ixp/ixp425.h b/arch/arm/include/asm/arch-ixp/ixp425.h index 5132607..c2e9c82 100644 --- a/arch/arm/include/asm/arch-ixp/ixp425.h +++ b/arch/arm/include/asm/arch-ixp/ixp425.h @@ -358,6 +358,9 @@ #define IXP425_GPIO_GPCLKR IXP425_GPIO_REG(IXP425_GPIO_GPCLKR_OFFSET) #define IXP425_GPIO_GPDBSELRIXP425_GPIO_REG(IXP425_GPIO_GPDBSELR_OFFSET) +#define IXP425_GPIO_GPITR(line)(((line) = 8) ? \ + IXP425_GPIO_GPIT2R : IXP425_GPIO_GPIT1R) + /* * Macros to make it easy to access the GPIO registers */ @@ -365,8 +368,11 @@ #define GPIO_OUTPUT_DISABLE(line) *IXP425_GPIO_GPOER |= (1 (line)) #define GPIO_OUTPUT_SET(line) *IXP425_GPIO_GPOUTR |= (1 (line)) #define GPIO_OUTPUT_CLEAR(line)*IXP425_GPIO_GPOUTR = ~(1 (line)) -#define GPIO_INT_ACT_LOW_SET(line) *IXP425_GPIO_GPIT1R = \ - (*IXP425_GPIO_GPIT1R ~(0x7 (line * 3))) | (0x1 (line * 3)) +#define GPIO_INT_ACT_LOW_SET(line) \ + *IXP425_GPIO_GPITR(line) = \ + (*IXP425_GPIO_GPITR(line) \ + ~(0x7 (((line) 0x7) * 3))) | \ + (0x1 (((line) 0x7) * 3)) \ /* * Constants to make it easy to access Timer Control/Status registers -- 1.7.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 6/7 V2] IXP: Fix NAND build warning on PDNB3 and SCPU
nand.c: In function ‘pdnb3_nand_read_buf’:
nand.c:107:4: warning: dereferencing type-punned pointer will break
strict-aliasing rules [-Wstrict-aliasing]
nand.c: In function ‘pdnb3_nand_dev_ready’:
nand.c:124:18: warning: variable ‘val’ set but not used
[-Wunused-but-set-variable]
Remove the 4-byte-at-time read mode altogether, the most is bogus and will
likely cause unaligned accesses.
Signed-off-by: Marek Vasut ma...@denx.de
Cc: Bryan Hundven bryanhund...@gmail.com
Cc: Michael Schwingen rincew...@discworld.dascon.de
---
board/prodrive/pdnb3/nand.c | 16 +++-
1 files changed, 3 insertions(+), 13 deletions(-)
V2: Drop the 4 byte access altogether, fix readb() call
diff --git a/board/prodrive/pdnb3/nand.c b/board/prodrive/pdnb3/nand.c
index 2efe027..6d1f203 100644
--- a/board/prodrive/pdnb3/nand.c
+++ b/board/prodrive/pdnb3/nand.c
@@ -96,16 +96,8 @@ static void pdnb3_nand_read_buf(struct mtd_info *mtd, u_char
*buf, int len)
{
int i;
- if (len % 4) {
- for (i = 0; i len; i++)
- buf[i] = readb((pdnb3_ndfc-data));
- } else {
- ulong *ptr = (ulong *)buf;
- int count = len 2;
-
- for (i = 0; i count; i++)
- *ptr++ = readl((pdnb3_ndfc-data));
- }
+ for (i = 0; i len; i++)
+ buf[i] = readb((pdnb3_ndfc-data));
}
static int pdnb3_nand_verify_buf(struct mtd_info *mtd, const u_char *buf, int
len)
@@ -121,12 +113,10 @@ static int pdnb3_nand_verify_buf(struct mtd_info *mtd,
const u_char *buf, int le
static int pdnb3_nand_dev_ready(struct mtd_info *mtd)
{
- volatile u_char val;
-
/*
* Blocking read to wait for NAND to be ready
*/
- val = readb((pdnb3_ndfc-wait));
+ readb((pdnb3_ndfc-wait));
/*
* Return always true
--
1.7.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB:host: Attribute packed removed from usb structures
Hello Mike and Marek,
On 2/29/2012 3:55 PM, Amit Virdi wrote:
Hello Mike,
On 2/28/2012 6:26 AM, Mike Frysinger wrote:
On Monday 27 February 2012 15:53:29 Marek Vasut wrote:
On Monday 27 February 2012 08:14:26 Marek Vasut wrote:
On 2/25/2012 3:42 PM, Albert ARIBAUD wrote:
Le 24/02/2012 12:58, Amit Virdi a écrit :
Packed attribute is forcing a bytewise write on device registers,
there by, resulting in a misbehavior on gcc-4.4.1.
Reverting the structures to non-packed
If (just asking, not asserting) the issue is caused by fields being
u8 where u8 access is not possible, then should you not make the
fields u16 / u32 according to access requirements?
The problem is not with the fields being of a different width. AFAIK,
the packed attribute changes the generated code to access even the
word field elements in a byte by byte manner
Infact, there is a discussion on lkml that I can point
https://lkml.org/lkml/2011/4/27/278
It seems that the discussion did not lead to a conclusion but it was
sensible (at least for ARM) to remove the packed attribute from this
structure
What does the USB spec say ? It might be a HW bug?
it isn't covered by the USB spec. these are structs for hardware
registers in the EHCI usb host controller.
I see ... so replacing them with unions of accessors where it colides
might
work ?
i'm not entirely sure what you're asking, but i think you're pointing
to the
right answer: drivers/usb/host/ehci.h:ehci_{read,write}l() should
*not* be
casting/derferencing the pointers directly. they should instead be using
standard {read,write}l() funcs from asm/io.h.
Amit: can you post a new patch that does that instead ? don't touch the
packed attribute, but change ehci_readl() to use readl() and
ehci_writel() to
use writel() ?
I'll make the changes and post the patch after testing successfully.
I did the changes suggested by you and tested the build. The issue
didn't come up. Then I reverted the code to the original (attributes
retained and ehci directly de-referencing the pointers. The issue didn't
come here too.
Today, I used armv7-linux-gcc (GCC) v4.6.2
So I suspect there has been some fix done in the GCC.
Now, even with the packed attributes, the word fields are accessed
word-by-word in contrast to the earlier observed behavior
(byte-by-byte). I could see ldr and str in the disassembly.
May be, we can discard this patch and keep drivers/usb/host/ehci.h intact.
Thanks
Amit Virdi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX6: imx_ccm is a constant that points to a register set
On 05/03/2012 17:34, Eric Nelson wrote:
Hi Eric,
If we're going to use globals to point at register banks, they
should be constant and visible.
---
ok, but why are we going to use global pointers ? We have global
constants (in imx-regs.h) and each part of code sets its local copy
without using global pointers, that require also some rules and naming
conventions to avoid conflicts.
arch/arm/cpu/armv7/mx6/clock.c |2 +-
arch/arm/include/asm/arch-mx6/imx-regs.h |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index ef98563..eb1f09b 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -34,7 +34,7 @@ enum pll_clocks {
PLL_ENET, /* ENET PLL */
};
-struct imx_ccm_reg *imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;
+struct imx_ccm_reg *const imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;
As far as I see, this is used only in clock.c - and it must be static.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB:host: Attribute packed removed from usb structures
Dear Amit Virdi,
Hello Mike and Marek,
On 2/29/2012 3:55 PM, Amit Virdi wrote:
Hello Mike,
On 2/28/2012 6:26 AM, Mike Frysinger wrote:
On Monday 27 February 2012 15:53:29 Marek Vasut wrote:
On Monday 27 February 2012 08:14:26 Marek Vasut wrote:
On 2/25/2012 3:42 PM, Albert ARIBAUD wrote:
Le 24/02/2012 12:58, Amit Virdi a écrit :
Packed attribute is forcing a bytewise write on device registers,
there by, resulting in a misbehavior on gcc-4.4.1.
Reverting the structures to non-packed
If (just asking, not asserting) the issue is caused by fields being
u8 where u8 access is not possible, then should you not make the
fields u16 / u32 according to access requirements?
The problem is not with the fields being of a different width.
AFAIK, the packed attribute changes the generated code to access
even the word field elements in a byte by byte manner
Infact, there is a discussion on lkml that I can point
https://lkml.org/lkml/2011/4/27/278
It seems that the discussion did not lead to a conclusion but it was
sensible (at least for ARM) to remove the packed attribute from this
structure
What does the USB spec say ? It might be a HW bug?
it isn't covered by the USB spec. these are structs for hardware
registers in the EHCI usb host controller.
I see ... so replacing them with unions of accessors where it colides
might
work ?
i'm not entirely sure what you're asking, but i think you're pointing
to the
right answer: drivers/usb/host/ehci.h:ehci_{read,write}l() should
*not* be
casting/derferencing the pointers directly. they should instead be using
standard {read,write}l() funcs from asm/io.h.
Amit: can you post a new patch that does that instead ? don't touch the
packed attribute, but change ehci_readl() to use readl() and
ehci_writel() to
use writel() ?
I'll make the changes and post the patch after testing successfully.
I did the changes suggested by you and tested the build. The issue
didn't come up. Then I reverted the code to the original (attributes
retained and ehci directly de-referencing the pointers. The issue didn't
come here too.
Today, I used armv7-linux-gcc (GCC) v4.6.2
So I suspect there has been some fix done in the GCC.
Now, even with the packed attributes, the word fields are accessed
word-by-word in contrast to the earlier observed behavior
(byte-by-byte). I could see ldr and str in the disassembly.
May be, we can discard this patch and keep drivers/usb/host/ehci.h intact.
Can you check with different toolchain please?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PULL] u-boot-pxa/master
Dear Albert ARIBAUD,
The following changes since commit 3513896e57c6757c411e0633ccb5da08c36ad7d4:
Fix erroneous 32-bit access to hw_clkctrl_frac0 and hw_clkctrl_frac1
registers
(2012-03-05 13:36:36 +0100)
are available in the git repository at:
git://git.denx.de/u-boot-pxa.git master
for you to fetch changes up to d85feeff3e8fc458654274835b2cf8e61070cdf4:
IXP: Fix GPIO_INT_ACT_LOW_SET() (2012-03-06 11:57:43 +0100)
Marek Vasut (7):
Examples: Properly append LDFLAGS to LD command
IXP: Make IXP buildable with arm-linux- toolchains
IXP: Fix missing MACH_TYPE_{ACTUX?,PNB3,DVLHOST}
IXP: Squash warnings in IXP NPE
IXP: Move PDNB3 and SCPU from Makefile to boards.cfg
IXP: Fix NAND build warning on PDNB3 and SCPU
IXP: Fix GPIO_INT_ACT_LOW_SET()
Makefile | 12
arch/arm/cpu/ixp/config.mk |3 +++
arch/arm/cpu/ixp/npe/IxEthAcc.c |2 +-
arch/arm/cpu/ixp/npe/IxEthDBAPISupport.c |3 ---
arch/arm/cpu/ixp/npe/IxQMgrDispatcher.c |3 ---
arch/arm/include/asm/arch-ixp/ixp425.h | 10 --
board/actux1/actux1.c|2 --
board/actux2/actux2.c|2 --
board/actux3/actux3.c|2 --
board/actux4/actux4.c|2 --
board/dvlhost/dvlhost.c |2 --
board/prodrive/pdnb3/nand.c | 16 +++-
board/prodrive/pdnb3/pdnb3.c |3 ---
boards.cfg |2 ++
examples/standalone/Makefile |2 +-
include/configs/actux1.h |2 ++
include/configs/actux2.h |2 ++
include/configs/actux3.h |2 ++
include/configs/actux4.h |2 ++
include/configs/dvlhost.h|2 ++
include/configs/pdnb3.h |2 ++
21 files changed, 30 insertions(+), 48 deletions(-)
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building imximage for mx53ard board, supporting NAND and YAFFS2
On 3/6/12, Bud Miljkovic bud_miljko...@trimble.com wrote: However, I would want to initially boot from SD-card and I would like to be able to generate an imx image of the u-boot when running make. Booting from SD card was the only boot method I tested on mx53ard in mainline U-boot. All you need to do is: make mx53ard_config make u-boot.imx Then flash u-boot.imx into the SD card as per instructions from doc/README.imximage Booting from NAND I haven't tested, but the procedure to generate u-boot.imx is the same. Please note that the boot from NAND relies on the mx53 ROM. If you need to store environment variables in NAND, for example, then you would need to add support for mx5 nand driver. Regards, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] net: allow setting env enetaddr from net device setting
Wolfgang, Mike,
On 02/01/2012 05:27 PM, Rob Herring wrote:
From: Rob Herring rob.herr...@calxeda.com
If the net driver has setup a valid ethernet address and an ethernet
address is not set in the environment already, then set the environment
variables from the net driver setting.
This enables pxe booting on boards which don't set ethaddr env variable.
Signed-off-by: Rob Herring rob.herr...@calxeda.com
---
Wolfgang,
This now prints a warning. If both env and device mac's are set, then the
behavior is unchanged and the env setting is used.
v3:
- print a warning if using mac address from the net device
v2:
- Re-wrote to always setup ethaddr env variables
Any comments on this?
Rob
Rob
doc/README.enetaddr |4 +++-
net/eth.c | 21 ++---
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/doc/README.enetaddr b/doc/README.enetaddr
index 2d8e24f..6c61817 100644
--- a/doc/README.enetaddr
+++ b/doc/README.enetaddr
@@ -32,7 +32,9 @@ Correct flow of setting up the MAC address (summarized):
1. Read from hardware in initialize() function
2. Read from environment in net/eth.c after initialize()
-3. Give priority to the value in the environment if a conflict
+3. Write value to environment if setup in struct eth_device-enetaddr by
driver
+ initialize() function. Give priority to the value in the environment if a
+ conflict.
4. Program the address into hardware if the following conditions are met:
a) The relevant driver has a 'write_addr' function
b) The user hasn't set an 'ethmacskip' environment variable
diff --git a/net/eth.c b/net/eth.c
index b4b9b43..f75a944 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -62,6 +62,15 @@ int eth_getenv_enetaddr_by_index(const char *base_name,
int index,
return eth_getenv_enetaddr(enetvar, enetaddr);
}
+int eth_setenv_enetaddr_by_index(const char *base_name, int index,
+ uchar *enetaddr)
+{
+ char enetvar[32];
+ sprintf(enetvar, index ? %s%daddr : %saddr, base_name, index);
+ return eth_setenv_enetaddr(enetvar, enetaddr);
+}
+
+
static int eth_mac_skip(int index)
{
char enetvar[15];
@@ -175,9 +184,15 @@ int eth_write_hwaddr(struct eth_device *dev, const char
*base_name,
unsigned char env_enetaddr[6];
int ret = 0;
- if (!eth_getenv_enetaddr_by_index(base_name, eth_number, env_enetaddr))
- return -1;
-
+ if (!eth_getenv_enetaddr_by_index(base_name, eth_number, env_enetaddr))
{
+ if (!is_valid_ether_addr(dev-enetaddr))
+ return -1;
+ eth_setenv_enetaddr_by_index(base_name, eth_number,
+ dev-enetaddr);
+ printf(\nWarning: %s using MAC address from net device\n,
+ dev-name);
+ return 0;
+ }
if (memcmp(env_enetaddr, \0\0\0\0\0\0, 6)) {
if (memcmp(dev-enetaddr, \0\0\0\0\0\0, 6)
memcmp(dev-enetaddr, env_enetaddr, 6)) {
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] AVR32 removal due to lack of custodian.
Around Sun 04 Mar 2012 21:55:22 +0100 or thereabout, Wolfgang Denk wrote: Dear Andreas, In message 4f4b681d.8070...@gmail.com you wrote: well, there where at least two users (sven and I) last year ... ... I'm willing to get u-boot avr32 support to live on for at least some years, if no one else volunteers. Thanks a lot for volunteering. Please send me your ssh public key so I can give you write access to the AVR32 repo. Thanks from my side as well, U-Boot has not been prioritized by me for some time. And with limited time, it would be good that somebody active keeps an eye open. -- mvh Hans-Christian Egtvedt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
On Tue, Mar 6, 2012 at 12:29 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hi Tom, Le 06/03/2012 00:03, Tom Rini a écrit : Hello, The following changes since commit 3513896e57c6757c411e0633ccb5da08c36ad7d4: Robert Delien (1): Fix erroneous 32-bit access to hw_clkctrl_frac0 and hw_clkctrl_frac1 registers are available in the git repository at: git://git.denx.de/u-boot-ti.git master Matt Porter (2): SPL: Add YMODEM over UART load support SPL: Enable YMODEM support on BeagleBone and AM335x EVM Tom Rini (6): .gitignore: Add .su files config.mk: Make cc-option create a file under include/generated config.mk: Check for -fstack-usage support spl.c: Use __noreturn decorator README: document more SPL config options SPL: Add README.omap3 .gitignore | 1 + Makefile | 2 +- README | 69 + arch/arm/cpu/armv7/omap-common/Makefile | 3 + arch/arm/cpu/armv7/omap-common/spl.c | 10 +++- arch/arm/cpu/armv7/omap-common/spl_ymodem.c | 76 +++ arch/arm/include/asm/omap_common.h | 3 + common/Makefile | 3 + config.mk | 11 +++-- doc/SPL/README.omap3 | 74 ++ include/configs/am335x_evm.h | 1 + lib/Makefile | 3 + 12 files changed, 238 insertions(+), 18 deletions(-) create mode 100644 arch/arm/cpu/armv7/omap-common/spl_ymodem.c create mode 100644 doc/SPL/README.omap3 With the documentation / related changes, Wolfgang said on IRC he was OK for now with the additional SPL bits going on. All these commits are feature additions posted after the merge window, aren't they? The first part was a little late (Jan 31st) and that was held up until Wolfgang was happy with the second set. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i.MX6: imx_ccm is a constant that points to a register set
On 03/06/2012 05:23 AM, Stefano Babic wrote:
On 05/03/2012 17:34, Eric Nelson wrote:
Hi Eric,
If we're going to use globals to point at register banks, they
should be constant and visible.
---
ok, but why are we going to use global pointers ? We have global
constants (in imx-regs.h) and each part of code sets its local copy
without using global pointers, that require also some rules and naming
conventions to avoid conflicts.
I'm just trying to follow convention here. My preference would be
to make these constants visible to the compiler in some way.
arch/arm/cpu/armv7/mx6/clock.c |2 +-
arch/arm/include/asm/arch-mx6/imx-regs.h |2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
index ef98563..eb1f09b 100644
--- a/arch/arm/cpu/armv7/mx6/clock.c
+++ b/arch/arm/cpu/armv7/mx6/clock.c
@@ -34,7 +34,7 @@ enum pll_clocks {
PLL_ENET, /* ENET PLL */
};
-struct imx_ccm_reg *imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;
+struct imx_ccm_reg *const imx_ccm = (struct imx_ccm_reg *)CCM_BASE_ADDR;
As far as I see, this is used only in clock.c - and it must be static.
I ran into this when trying to fix setup_sata() in mx6qsabrelite.c as shown in
this patch.
The same sort of question (how to define the register sets) will occur for
other register sets.
For the iomux, I used a #define, but that seems wrong too
(not least because it isn't UPPERCASE).
#define iomuxc ((struct iomuxc_base_regs *)IOMUXC_BASE_ADDR)
The other way around this is to hide all register accesses behind the
drivers. IOW, add routines for each of the accesses and hide the
details in clock.c
void mx6_enable_sata_clock();
...
void mx6_enable_enet_pll();
but there will almost certainly be board-specific tweaks and I'm not
sure the extra level of abstraction helps.
Let me know your thoughts about how to structure this stuff.
Regards,
Eric
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] doc: Add documentation for mpc85xx debugger support
Dear Prabhakar Kushwaha, In message 1329296027-28471-1-git-send-email-prabha...@freescale.com you wrote: This describes requirement of e500 and e500v2 processor to support any debugger. it also provide an insight of switch used and defined. Signed-off-by: Radu Lazarescu radu.lazare...@freescale.com Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com --- Applies on http://git.denx.de/u-boot.git branch master doc/README.mpc85xx_debugger | 44 +++ 1 files changed, 44 insertions(+), 0 deletions(-) create mode 100644 doc/README.mpc85xx_debugger This document contains a number of typos and othe rerrors, mixed with inconsitent indentation (some lines use TABs, others use spaces). I suggest you clean it up and have it reviewed by a native speaker before resubmitting. Regarding the split into 4 separate patches: this makes no sense to me. For example, in this patch you reference new (and undocumented config options like CONFIG_E500_V1_V2) without ever using them. Please squash patches. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The two most common things in the universe are hydrogen and stupi- dity. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] powerpc/85xx:Fix MSR[DE] bit in MSR to support debugger
Dear Prabhakar Kushwaha, In message 1329296042-28506-1-git-send-email-prabha...@freescale.com you wrote: Debugger's ability to debug an application is constrained by the architecture's debug IP / run-control solution that may impose certain requirements for the application itself. Similarly, when referring to the e500 and e500v2 architecture, there are two basic rules any application has to respect in order to allow full debugging support: 1. Keep MSR[DE] bit set 2. Have a valid opcode that can be fetched from the debug exception vector [IVPR|IVOR15]. Here MSR = Machine State register This patch makes sure of point 1 and make MSR[DE] bit is set uniformaly across the different execution in address space. Does it make sense to repeast the whole README here? diff --git a/arch/powerpc/cpu/mpc85xx/start.S b/arch/powerpc/cpu/mpc85xx/start.S index 7bfa2d5..09111e6 100644 --- a/arch/powerpc/cpu/mpc85xx/start.S +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -82,6 +82,11 @@ .globl _start_e500 _start_e500: +#if defined(CONFIG_E500_V1_V2) +/* Enable debug exception */ + li r1,MSR_DE + mtmsr r1 +#endif Why is this #ifdef needed here? #if defined(CONFIG_SECURE_BOOT) defined(CONFIG_E500MC) /* ISBC uses L2 as stack. @@ -729,8 +734,8 @@ create_init_ram_area: msync tlbwe - lis r6,MSR_IS|MSR_DS@h - ori r6,r6,MSR_IS|MSR_DS@l + lis r6,MSR_IS|MSR_DS|MSR_DE@h + ori r6,r6,MSR_IS|MSR_DS|MSR_DE@l And why don;t we need such an #ifdef here? Also, CONFIG_E500_V1_V2 is undocumented. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de (The Chief Programmer) personally defines the functional and performance specifications, designs the program, codes it, tests it, and writes its documentation... He needs great talent, ten years experience and considerable systems and applications knowledge, whether in applied mathematics, business data handling, or whatever. - Fred P. Brooks, _The Mythical Man Month_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] powerpc/85xx:Update NOR code base to support debugger
Dear Prabhakar Kushwaha, In message 1329296055-28541-1-git-send-email-prabha...@freescale.com you wrote: Update the NOR code base to support NOR-boot debugging. It ovecome e500 and e500v2's second limitation i.e. IVPR + IVOR15 should be valid fetchable OP code address. While executing in translated space (AS=1), whenever a debug exception is generated, the MSR[DS/IS] gets cleared and the processor tries to fetch an instruction from the debug exception vector (IVPR|IVOR15); since now we are in AS=0, the application needs to ensure the proper configuration to have IVOR|IVOR15 accessible from AS=0 also. Signed-off-by: Radu Lazarescu radu.lazare...@freescale.com Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com ... + _mas0 = MAS0_TLBSEL(1) | + MAS0_ESEL(CONFIG_DEBUGGER_TEMP_TLB); You are using an undocumented CONFIG_ option here. +++ b/arch/powerpc/cpu/mpc85xx/start.S @@ -184,6 +184,48 @@ l2_disabled: andi. r1,r3,L1CSR0_DCE@l beq 2b +#if defined(CONFIG_E500_V1_V2) !defined(CONFIG_SYS_RAMBOOT) What if no such debug support is needed, and code size hurts? @@ -107,6 +107,7 @@ #define CONFIG_MAX_CPUS 1 #define CONFIG_FSL_SDHC_V2_3 #define CONFIG_SYS_FSL_NUM_LAWS 12 +#define CONFIG_DEBUGGER_TEMP_TLB 3 Undocumented! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If at first you don't succeed, you are running about average. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cfi: fix the incomplete erased status check in buffer write
Hi htbegin,
first sorry for the late review.
On Sunday 19 February 2012 12:48:37 htbegin wrote:
Without the fix, flash_write_cfibuffer will return timeout error
instead of not-erased error when all bytes in the first word of
a sector are 0xFF and other words are not.
Signed-off-by: htbegin hotfor...@gmail.com
Please use your real name here in the s-o-b line.
---
drivers/mtd/cfi_flash.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 722c3fc..35294bc 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -873,7 +873,7 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp, void *src = cp;
void *dst = (void *)dest;
void *dst2 = dst;
- int flag = 0;
+ int flag = 1;
uint offset = 0;
unsigned int shift;
uchar write_cmd;
@@ -898,7 +898,7 @@ static int flash_write_cfibuffer (flash_info_t * info,
ulong dest, uchar * cp,
cnt = len shift;
- while ((cnt-- 0) (flag == 0)) {
+ while ((cnt-- 0) (flag == 1)) {
switch (info-portwidth) {
case FLASH_CFI_8BIT:
flag = ((flash_read8(dst2) flash_read8(src)) ==
I checked your patch, and it seems to me that you have spotted a problem. But
your problem description above doesn't seem to be totally correct. From my
understanding, the loop checking for not erased flash aborts directly once
0xff is found. So that the check doesn't continue till the first non-0xff word
as it should be.
Can you confirm this? Then please re-send you patch with a new patch
description and a correct name in the Signed-off-by line.
Thanks.
Best regards,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/85xx:Add PSC9131 RDB Support
Dear Prabhakar Kushwaha, In message 4f3b8bb7.9020...@freescale.com you wrote: +#define CONFIG_UBOOTPATH u-boot.bin /* U-Boot image on TFTP server */ CONFIG_ options are kind of special; if you define new ones (which should only be done when it really makes sense - this appears not to be the case here) you must also add documentation for these to the README. I am not clear about this. These are already defined and used by other platforms. Maybe you can add the documentation anyway? Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A memorandum is written not to inform the reader, but to protect the writer. -- Dean Acheson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] md,mw commands
Hi V.Balaji, Le 2012-03-06 10:41, VISWANADHULA BALAJI a écrit : Hi, Iam using 256MB RAM on arm11 board.I just tried md,mw commands from uboot like the following mw C80 0x 0x500 here C80 is the 200MB of RAM MCS8142 md C80 0c80: 0c800010: 0c800020: 0c800030: 0c800040: 0c800050: 0c800060: 0c800070: 0c800080: 0c800090: 0c8000a0: 0c8000b0: 0c8000c0: 0c8000d0: 0c8000e0: 0c8000f0: mw 3200 0x 0x500 here 3200 is the 800MB of RAM MCS8142 md 3200 3200: 3210: 3220: 3230: 3240: 3250: 3260: 3270: How it is possible to see the data even after the 256MB of RAM.If i give the sizes like 256MB ,512MB mw command get hangs otherwise the data is writing to the RAM even the size exceeds the size of actual RAM. Please help me. Did you check the configuration of your board's memory controller, especially how chip select mechanism is mapped onto ARM11 address space? A bad configuration can mirror the actual 256 MB several times over a bigger area -- so address 0 of your RAM would be seen at ARM11 address 0, but also 0x1000, 0x2000, etc. A quick check would be to write something at 0x1000 and then read 0x2000, and see if it mirrors 0x1000. Thanks V.Balaji Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: replace wait_ms() with mdelay()
On Mon, Mar 05, 2012 at 09:04:41PM -0500, Mike Frysinger wrote: On Monday 05 March 2012 20:46:40 Graeme Russ wrote: On Tue, Mar 6, 2012 at 12:42 PM, Mike Frysinger wrote: On Monday 05 March 2012 19:15:54 Marek Vasut wrote: Acked-by: Marek Vasut ma...@denx.de Thanks for your patch, it's on it's way to application :) generally the maintainer who is picking up the patch and sending on to wolfgang would add a s-o-b rather than a-b tag ... I've always seen s-o-b as 'I contributed to this patch' and a-b as 'I think this patch looks good (and I may have even compiled it)' and t-b as 'I actually ran this on real hardware' the Linux kernel wisdom is s-o-b means 'i handled this patch in transit to merge' while a-b means 'looks good to me' But didn't we have this discussion a few months ago and the answer was that U-Boot isn't the kernel and custodians don't S-O-B every patch they add, just A-B/T-B (and then it's at their discretion). -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2][v2] powerpc/85xx:Add PSC9131 RDB Support
Dear Prabhakar Kushwaha,
In message 1329304781-27758-1-git-send-email-prabha...@freescale.com you
wrote:
...
+#define CONFIG_L2_CACHE /* toggle L2 cache */
+#define CONFIG_BTB /* toggle branch predition */
Toggle? Do you really toggle, or enable?
+#define CONFIG_ADDR_STREAMING/* toggle addr streaming */
What is this good for?
It is undocumented, and there is no code that uses it.
+#define CONFIG_SYS_MEMTEST_START 0x /* memtest works on */
+#define CONFIG_SYS_MEMTEST_END 0x1fff
Have these been tested? A memtest starting at 0x is likely to
overwrite the exception vectors - I would expect the system will crash
or hang immediately?
+#define CONFIG_PANIC_HANG/* do not reset board on panic */
Why is this needed?
...
+#define CONFIG_HOSTNAME PSC9131rdb
+#define CONFIG_ROOTPATH /opt/nfsroot
+#define CONFIG_BOOTFILE uImage
+#define CONFIG_UBOOTPATH u-boot.bin /* U-Boot image on TFTP server */
+
+#define CONFIG_BAUDRATE 115200
+
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ netdev=eth0\0 \
+ uboot= MK_STR(CONFIG_UBOOTPATH) \0 \
Why didn't you follow my change request here? Define as u-boot.bin
so it is at least consistent with the other strings, and drop the
MK_STR here.
...
--- /dev/null
+++ b/nand_spl/board/freescale/psc9131rdb/Makefile
...
--- /dev/null
+++ b/nand_spl/board/freescale/psc9131rdb/nand_boot.c
Sorry, but this is the old, legacy SPL code. Please do not use this
any more for new board.
Use the new code (in /spl/ directory) instead.
+#define udelay(x) \
+ {int i, j; for (i = 0; i x; i++) for (j = 0; j 1; j++); }
Have you ever tested this? Or looked at what the compiler generates
for it?
+unsigned long ddr_freq_mhz;
Do you have BSS before relocation?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
God runs electromagnetics by wave theory on Monday, Wednesday, and
Friday, and the Devil runs them by quantum theory on Tuesday, Thurs-
day, and Saturday. -- William Bragg
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Allow newlines within command environment vars
Dear Simon Glass, In message capnjgz1bmmrn-+bhfr9gch-5wf4wsz_7qa53c_chplebl2y...@mail.gmail.com you wrote: ... The environment variables preboot, bootcmd and menucmd can hold a command to execute. This change permits these variables to have newlines so that they work the same as the 'source' command. ... The first patch is just a clean-up and should not change any behaviour. This second patch changes the behaviour of the named env variables. So which commit introduced the breakage, then? Which breakage are you referring to? The intent of these two patches is to add a new feature (proposed by Michael Walle mich...@walle.cc who also provided a patch) on top of the command refactor series. Sorry, there is some confusion here but I'm not sure what it is. Guess I'm confused. I don't understand in which way the variables listed here (preboot, bootcmd and menucmd) are special - actually all variables can hold commands, that then can be executed using the run command. If newline is a valid command separator (and I think it is), this should work for _all_ variable. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Backed up the system lately? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] USB:gadget:designware Fix memory nonalignment issue
On Tuesday 06 March 2012 04:51:57 Marek Vasut wrote:
On 3/5/2012 11:51 PM, Marek Vasut wrote:
Amit Virdi wrote:
While receiving packets from FIFO sometimes the buffer provided was
nonaligned. Fix this by taking a temporary aligned buffer and then
copying the content to nonaligned buffer.
--- a/drivers/usb/gadget/designware_udc.c
+++ b/drivers/usb/gadget/designware_udc.c
@@ -202,6 +202,7 @@ static int usbgetpckfromfifo(int epNum, u8 *bufp,
u32 len) u32 i, nw, nb;
u32 *wrdp;
u8 *bytp;
+u32 tmp[128];
if (readl(udc_regs_p-dev_stat) DEV_STAT_RXFIFO_EMPTY)
return -1;
@@ -209,7 +210,12 @@ static int usbgetpckfromfifo(int epNum, u8 *bufp,
u32 len) nw = len / sizeof(u32);
nb = len % sizeof(u32);
-wrdp = (u32 *)bufp;
+/* use tmp buf if bufp is not word aligned */
+if ((int)bufp 0x3)
+wrdp = (u32 *)tmp[0];
+else
+wrdp = (u32 *)bufp;
+
for (i = 0; i nw; i++) {
writel(readl(fifo_ptr), wrdp);
wrdp++;
@@ -223,6 +229,13 @@ static int usbgetpckfromfifo(int epNum, u8 *bufp,
u32 len) }
readl(outep_regs_p[epNum].write_done);
+/* copy back tmp buffer to bufp if bufp is not word aligned */
+if ((int)bufp 0x3) {
+bytp = (u8 *)tmp[0];
+for (i = 0; i len; i++)
+bufp[i] = bytp[i];
+}
+
return 0;
}
This addresses EHCI cache problem, that's why you need bounce buffer,
right?
No. The problem was we were copying data word-by-word to a non-word
aligned memory in the USB gadget. So, this is different from the USB
host controller issue.
I see ... why isn't buffer aligned by the usb stack then?
because it might not be a requirement higher up. i.e. it's dealing with a
data byte stream. forcing all higher layers to use 32bit alignment because
this host controller requires 32bit alignment in its FIFOs is incorrect.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] USB:gadget:designware Fix memory nonalignment issue
On Thursday 16 February 2012 07:03:38 Amit Virdi wrote:
--- a/drivers/usb/gadget/designware_udc.c
+++ b/drivers/usb/gadget/designware_udc.c
+ /* copy back tmp buffer to bufp if bufp is not word aligned */
+ if ((int)bufp 0x3) {
+ bytp = (u8 *)tmp[0];
+ for (i = 0; i len; i++)
+ bufp[i] = bytp[i];
+ }
memcpy(bufp, tmp, len) ?
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB:host: Attribute packed removed from usb structures
On Tuesday 06 March 2012 07:06:22 Amit Virdi wrote:
On 2/29/2012 3:55 PM, Amit Virdi wrote:
On 2/28/2012 6:26 AM, Mike Frysinger wrote:
On Monday 27 February 2012 15:53:29 Marek Vasut wrote:
On Monday 27 February 2012 08:14:26 Marek Vasut wrote:
On 2/25/2012 3:42 PM, Albert ARIBAUD wrote:
Le 24/02/2012 12:58, Amit Virdi a écrit :
Packed attribute is forcing a bytewise write on device registers,
there by, resulting in a misbehavior on gcc-4.4.1.
Reverting the structures to non-packed
If (just asking, not asserting) the issue is caused by fields being
u8 where u8 access is not possible, then should you not make the
fields u16 / u32 according to access requirements?
The problem is not with the fields being of a different width.
AFAIK, the packed attribute changes the generated code to access
even the word field elements in a byte by byte manner
Infact, there is a discussion on lkml that I can point
https://lkml.org/lkml/2011/4/27/278
It seems that the discussion did not lead to a conclusion but it was
sensible (at least for ARM) to remove the packed attribute from this
structure
What does the USB spec say ? It might be a HW bug?
it isn't covered by the USB spec. these are structs for hardware
registers in the EHCI usb host controller.
I see ... so replacing them with unions of accessors where it colides
might
work ?
i'm not entirely sure what you're asking, but i think you're pointing
to the
right answer: drivers/usb/host/ehci.h:ehci_{read,write}l() should
*not* be
casting/derferencing the pointers directly. they should instead be using
standard {read,write}l() funcs from asm/io.h.
Amit: can you post a new patch that does that instead ? don't touch the
packed attribute, but change ehci_readl() to use readl() and
ehci_writel() to
use writel() ?
I'll make the changes and post the patch after testing successfully.
I did the changes suggested by you and tested the build. The issue
didn't come up. Then I reverted the code to the original (attributes
retained and ehci directly de-referencing the pointers. The issue didn't
come here too.
Today, I used armv7-linux-gcc (GCC) v4.6.2
So I suspect there has been some fix done in the GCC.
Now, even with the packed attributes, the word fields are accessed
word-by-word in contrast to the earlier observed behavior
(byte-by-byte). I could see ldr and str in the disassembly.
May be, we can discard this patch and keep drivers/usb/host/ehci.h intact.
not sure ... in general, device registers should be accessed with io.h helpers
instead of dereferenced by volatile pointers. i can think of cases on Blackfin
where the io.h helpers would be required, and even using volatile pointers
could result in misbehavior.
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: replace wait_ms() with mdelay()
On Tuesday 06 March 2012 10:03:19 Tom Rini wrote: On Mon, Mar 05, 2012 at 09:04:41PM -0500, Mike Frysinger wrote: On Monday 05 March 2012 20:46:40 Graeme Russ wrote: On Tue, Mar 6, 2012 at 12:42 PM, Mike Frysinger wrote: On Monday 05 March 2012 19:15:54 Marek Vasut wrote: Acked-by: Marek Vasut ma...@denx.de Thanks for your patch, it's on it's way to application :) generally the maintainer who is picking up the patch and sending on to wolfgang would add a s-o-b rather than a-b tag ... I've always seen s-o-b as 'I contributed to this patch' and a-b as 'I think this patch looks good (and I may have even compiled it)' and t-b as 'I actually ran this on real hardware' the Linux kernel wisdom is s-o-b means 'i handled this patch in transit to merge' while a-b means 'looks good to me' But didn't we have this discussion a few months ago and the answer was that U-Boot isn't the kernel and custodians don't S-O-B every patch they add, just A-B/T-B (and then it's at their discretion). could be and i just missed it. personally, i don't see the point in diverging from the workflow that the kernel pioneered and u-boot just picked up, but whatever. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib: zlib: update to 1.2.6
On Tuesday 06 March 2012 03:55:19 Lei Wen wrote: In this patch, I update the current zlib from 1.2.5 to 1.2.6. There is a lot of warnings when using checkpatch script, I don't know whether I should fix it or not... Since it is just copy from as it is from upstream zlib 1.2.6, so I didn't do the correction, so don't be panic when use checkpatch. did you test the performance ? i found it went down a bit which is why i didn't post a patch to update it to a newer version. improvements in API's we don't use aren't a good reason for updating ... -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/28] arm: Use sections header to obtain link symbols
On Tuesday 06 March 2012 01:24:21 Simon Glass wrote: On Mon, Mar 5, 2012 at 9:03 PM, Mike Frysinger wrote: On Thursday 16 February 2012 09:48:58 Simon Glass wrote: --- a/board/cm4008/flash.c +++ b/board/cm4008/flash.c #include common.h +#include asm-generic/sections.h arches should provide asm/sections.h, and those are the only headers that should know about asm-generic/sections.h Similar to my previous comment, but why does each arch have to have subtly-different section symbol names? From what I have seen so far there can be unified also. Blackfin has linker symbols that don't belong in any other port. this is also how the kernel does it, and i don't see value in diverging here. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 6/9] Create a single cmd_call() function to handle command execution
On Tuesday 06 March 2012 01:14:10 Simon Glass wrote: On Mon, Mar 5, 2012 at 8:40 PM, Mike Frysinger wrote: On Wednesday 15 February 2012 00:59:23 Simon Glass wrote: --- a/include/command.h +++ b/include/command.h @@ -150,4 +152,5 @@ extern int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]); #if defined(CONFIG_NEEDS_MANUAL_RELOC) void fixup_cmdtable(cmd_tbl_t *cmdtp, int size); #endif + #endif /* __COMMAND_H */ unrelated whitespace change Done. I will send a new version of this patch and mark the dropped one 'archived' in patchwork. Do you think that is enough? should be. i change the state of all previous versions of patches that i post as superseded. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4] usb: align buffers at cacheline
On Tuesday 06 March 2012 03:24:34 Marek Vasut wrote: On Friday 02 March 2012 11:45:15 Wolfgang Denk wrote: That's what I did in original patch where I am aligning it by adding the line +/* Device Descriptor */ +#ifdef ARCH_DMA_MINALIGN + struct usb_device_descriptor descriptor + __attribute__((aligned(ARCH_DMA_MINALIGN))); +#else + struct usb_device_descriptor descriptor; +#endif in usb.h Line:112 I see ...and I told you it's wrong? I must have misunderstood, I'm sorry about that. But if you actually do this, you can avoid memcpy, right? And eventually wd can also avoid the #ifdef ? I guess the __attribute__((aligned...)) would not hurt anything? the reason i disliked that was because it adds padding to the structure. on my system, seems to go from 144 bytes to 160, and the other goes from 1352 to 1376. the scsi structure isn't specific to usb either. i can't tell if this is a structure that represents data on the wire ... the fact it's written all using char types makes me suspicious. if it is, then obviously we can't change the padding in the struct. further, it doesn't seem like Linux imposes this restriction at the structure level (does it do memcopies instead ?), and imposing it on arbitrary members in there w/out documentation easily leads to rot. if the code changes and no longer needs this alignment, how do we tell ? if the code starts transferring another structure, do we end up aligning every member in there until there's padding everywhere ? I believe this is OK, we're properly aligning only descriptors. you're looking at one change (the one quoted above). i was referring to the scsi structure change (which is not quoted above). Note that the USB stack in linux and in uboot is different. i know the stacks are different, but they do share. my point was that if Linux is managing this, then why can't we ? or maybe we're fighting over an insignificant memcpy ... the scsi buffer is all of 64 bytes. on some systems, that's like 1 cache line :P. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] net: fec_mxc: allow use with cache enabled
On 03/05/2012 01:06 PM, Marek Vasut wrote:
Dear Eric Nelson,
ensure that transmit and receive buffers are cache-line aligned
invalidate cache after each packet received
flush cache before transmitting
Original patch by Marek:
http://lists.denx.de/pipermail/u-boot/2012-February/117695.html
Would be cool to Cc me :-p
Sorry about that.
All right, let's review this!
Signed-off-by: Eric Nelsoneric.nel...@boundarydevices.com
---
drivers/net/fec_mxc.c | 243
+ drivers/net/fec_mxc.h |
19 +
2 files changed, 184 insertions(+), 78 deletions(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 1fdd071..0e35377 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -50,6 +50,33 @@ DECLARE_GLOBAL_DATA_PTR;
#define CONFIG_FEC_MXC_SWAP_PACKET
#endif
+#ifndefCONFIG_FEC_DESC_ALIGNMENT
+#defineCONFIG_FEC_DESC_ALIGNMENT ARCH_DMA_MINALIGN
+#endif
+
+#ifndefCONFIG_FEC_DATA_ALIGNMENT
+#defineCONFIG_FEC_DATA_ALIGNMENT ARCH_DMA_MINALIGN
+#endif
The above shoul be the bigger of CONFIG_SYS_CACHELINE_SIZE and ARCH_DMA_ALIGN
(use max() ).
Eventually, we should unify cache and DMA stuff and make only one macro (ALIGN)
and be done with it.
btw. I can't seem to find a platform using different alignment for DATA and
DESC, let's make it one ( ... #define CONFIG_FEC_ALIGN max(ARCH_DMA_MINALIGN,
CONFIG_SYS_CACHELINE_SIZE), ok?
I was thinking the same thing but concerned that I missed something.
+
+/* Check various alignment issues at compile time */
+#if ((CONFIG_FEC_DESC_ALIGNMENT 16) || (CONFIG_FEC_DESC_ALIGNMENT % 16
!= 0)) +#error CONFIG_FEC_DESC_ALIGNMENT must be multiple of 16!
+#endif
+
+#if ((CONFIG_FEC_DATA_ALIGNMENT 16) || (CONFIG_FEC_DATA_ALIGNMENT % 16
!= 0)) +#error CONFIG_FEC_DATA_ALIGNMENT must be multiple of 16!
+#endif
+
+#if ((PKTALIGN CONFIG_FEC_DATA_ALIGNMENT) || \
+ (PKTALIGN % CONFIG_FEC_DATA_ALIGNMENT != 0))
+#error PKTALIGN must be multiple of CONFIG_FEC_DATA_ALIGNMENT!
+#endif
+
+#if ((PKTSIZE_ALIGN CONFIG_FEC_DATA_ALIGNMENT) || \
+ (PKTSIZE_ALIGN % CONFIG_FEC_DATA_ALIGNMENT != 0))
+#error PKTSIZE_ALIGN must be multiple of CONFIG_FEC_DATA_ALIGNMENT!
+#endif
+
#undef DEBUG
struct nbuf {
@@ -259,43 +286,52 @@ static int fec_tx_task_disable(struct fec_priv *fec)
* Initialize receive task's buffer descriptors
* @param[in] fec all we know about the device yet
* @param[in] count receive buffer count to be allocated
- * @param[in] size size of each receive buffer
+ * @param[in] dsize desired size of each receive buffer
* @return 0 on success
*
* For this task we need additional memory for the data buffers. And each
* data buffer requires some alignment. Thy must be aligned to a specific
- * boundary each (DB_DATA_ALIGNMENT).
+ * boundary each.
*/
-static int fec_rbd_init(struct fec_priv *fec, int count, int size)
+static int fec_rbd_init(struct fec_priv *fec, int count, int dsize)
{
- int ix;
- uint32_t p = 0;
-
- /* reserve data memory and consider alignment */
- if (fec-rdb_ptr == NULL)
- fec-rdb_ptr = malloc(size * count + DB_DATA_ALIGNMENT);
- p = (uint32_t)fec-rdb_ptr;
- if (!p) {
- puts(fec_mxc: not enough malloc memory\n);
- return -ENOMEM;
- }
- memset((void *)p, 0, size * count + DB_DATA_ALIGNMENT);
- p += DB_DATA_ALIGNMENT-1;
- p= ~(DB_DATA_ALIGNMENT-1);
-
- for (ix = 0; ix count; ix++) {
- writel(p,fec-rbd_base[ix].data_pointer);
- p += size;
- writew(FEC_RBD_EMPTY,fec-rbd_base[ix].status);
- writew(0,fec-rbd_base[ix].data_length);
- }
+ uint32_t size;
+ int i;
+
/*
-* mark the last RBD to close the ring
+* Allocate memory for the buffers. This allocation respects the
+* alignment
*/
- writew(FEC_RBD_WRAP | FEC_RBD_EMPTY,fec-rbd_base[ix - 1].status);
+ size = roundup(dsize, CONFIG_FEC_DATA_ALIGNMENT);
+ for (i = 0; i count; i++) {
+ uint32_t data_ptr = readl(fec-rbd_base[i].data_pointer);
+ if (0 == data_ptr) {
We should fix this yoda condition while at it.
Wise, Yoda was...
I've been in the habit of putting constants on the left ever since reading
Code Complete many years ago.
That said, I'll swap it in V3.
+ uint8_t *data = memalign(CONFIG_FEC_DATA_ALIGNMENT,
+size);
NOTE[1]: This is good, each RECEIVE DATA BUFFER is properly aligned at
allocation time and therefore IS CACHE SAFE.
+ if (!data) {
+ printf(%s: error allocating rxbuf %d\n,
+ __func__, i);
+ goto err;
+
Re: [U-Boot] [PATCH] env: Add the ability to merge the saved env with the default.
Mike, On Mon, Mar 5, 2012 at 8:27 PM, Mike Frysinger vap...@gentoo.org wrote: this is kind of a crappy interface. Agreed. also, doesn't the existing `env import` do this ? * env import [-d] [-t | -b | -c] addr [size] * -d: delete existing environment before importing; * otherwise overwrite / append to existion definitions so if we imported the default, we'd get this ? It's not quite possible to just import the default from the saved for two reasons: 1. I don't know of any way to import the default. It's not stored at any well-known address or with any well-known size. 2. The order of precedence would be a little different (default would override saved). ...but I think you're right that using env import is the better way to go. I can always have the default boot command load the overrides into memory and the import them. That works just fine for us. Thank you for your review and suggestion! Please consider this patch abandoned. -Doug ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] net: fec_mxc: allow use with cache enabled
On 03/06/2012 10:06 AM, Eric Nelson wrote:
On 03/05/2012 01:06 PM, Marek Vasut wrote:
Dear Eric Nelson,
snip
+ if (!fec-rbd_base) {
+ ret = -ENOMEM;
+ goto err2;
+ }
+ memset(fec-rbd_base, 0, size);
+ }
We might want to flush the descriptors to memory after they have been inited?
We're also missing a flush after the call to fec_rbd_init().
I'm inclined to move that call to right after the memset and before
a newly-added flush and do the same with the call to tbd_init().
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] OneNAND custodian (was: Re: [RESEND 0/4] onenand: OneNAND board dependent probe and fixes for Samsung targets)
On 03/06/2012 12:54 AM, Lukasz Majewski wrote: This patch sets add board dependent onenand probes. Several fixes for GONI and Exynos4210 (C210_universal) targets have been added. Tested at: Samsung S5PC110 GONI Samsung Exynos4210 (S5PC210 Universal) Lukasz Majewski (4): onenand:samsung Target dependent OneNAND chip probe function onenand:samsung OneNAND chip probe functions added for GONI and Exynos4210 onenand: Replace ONENAND_IS_MLC() test with ONENAND_HAS_4KB() onenand: samsung: Enable support OneNAND support at Samsung's Exynos4210 Is anyone interested in being a OneNAND custodian? I've taken some OneNAND patches in the past, but it's a completely separate subsystem from NAND, and nobody seems interested in changing that. I not only have no hardware, but also no documentation other than marketing materials. I lack the context to properly review OneNAND patches. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env: Add the ability to merge the saved env with the default.
Dear Doug Anderson, In message CAD=FV=Ws+FuCqUXRd3-PJS-2y5PTspgegMftvTOQqhK=96y...@mail.gmail.com you wrote: It's not quite possible to just import the default from the saved for two reasons: 1. I don't know of any way to import the default. It's not stored at any well-known address or with any well-known size. Then save it to a well-known address. env reset followed by env export should be a reasonably straughtforward way to get there. 2. The order of precedence would be a little different (default would override saved). I'm not sure I understand what you mean. You can chose if you import the saved defaults before or after your private settings. ...but I think you're right that using env import is the better way to go. I can always have the default boot command load the overrides into memory and the import them. That works just fine for us. Thank you for your review and suggestion! Please consider this patch abandoned. Done. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Es sind überhaupt nur die Dummköpfe, die sich den Befehlen der Mäch- tigen widersetzen. Um sie zu ruinieren ist es genug, ihre Befehle treu zu erfüllen. - Peter Hacks: Die schöne Helena ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] net: allow setting env enetaddr from net device setting
Dear Rob Herring, In message 1328138854-28612-1-git-send-email-robherri...@gmail.com you wrote: --- a/doc/README.enetaddr +++ b/doc/README.enetaddr @@ -32,7 +32,9 @@ Correct flow of setting up the MAC address (summarized): 1. Read from hardware in initialize() function 2. Read from environment in net/eth.c after initialize() -3. Give priority to the value in the environment if a conflict +3. Write value to environment if setup in struct eth_device-enetaddr by driver + initialize() function. Give priority to the value in the environment if a + conflict. Sorry, but this description is not correct. You say here that the environment variable should always be written, but this is not the case. Only if it does not exist it shall be set. If it exists, it shall only be read, and in case of inconsistencies a warning shall be printed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Too many people are ready to carry the stool when the piano needs to be moved. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/9] Unified command execution in one place
Dear Simon Glass, In message 1329285566-30386-1-git-send-email-...@chromium.org you wrote: At present two parsers have similar code to execute commands. Also cmd_usage() is called all over the place. This series adds a single function which processes commands called cmd_process(). This new function understands return codes, and in particular CMD_RET_USAGE to indicate a usage error. So rather than calling cmd_usage() themselves, the command handlers can just return this error. There appears to be a run_command2() which is used to run commands with the selected parser. This series changes this in two separate steps to just run_command(), and renames the old run_command() to builtin_run_command(). No one should call this outside main.c since if the hush parser is being used it is wrong to call it. The built-in parser code could move into a separate file perhaps in a future patch. The overall series reduces code size on ARM by about 1KB on my ~160KB U-Boot text region when the hush parser is used, and around 60 bytes when it isn't. I tested this on PPC (TQM5200 config): add/remove: 2/0 grow/shrink: 3/40 up/down: 268/-740 (-472) and ARM (m28evk config): add/remove: 1/0 grow/shrink: 5/38 up/down: 212/-1404 (-1192) so this looks good to me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de NOTE: The Most Fundamental Particles in This Product Are Held Together by a Gluing Force About Which Little is Currently Known and Whose Adhesive Power Can Therefore Not Be Permanently Guaranteed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] net: fec_mxc: allow use with cache enabled
Dear Eric Nelson,
On 03/06/2012 10:06 AM, Eric Nelson wrote:
On 03/05/2012 01:06 PM, Marek Vasut wrote:
Dear Eric Nelson,
snip
+ if (!fec-rbd_base) {
+ ret = -ENOMEM;
+ goto err2;
+ }
+ memset(fec-rbd_base, 0, size);
+ }
We might want to flush the descriptors to memory after they have been
inited?
We're also missing a flush after the call to fec_rbd_init().
I think we need only one flush in the whole allocation sequence. But you're
probably right here.
I'm inclined to move that call to right after the memset and before
a newly-added flush and do the same with the call to tbd_init().
You mean into fec_rbd_init() ?
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] net: allow setting env enetaddr from net device setting
On 03/06/2012 01:30 PM, Wolfgang Denk wrote: Dear Rob Herring, In message 1328138854-28612-1-git-send-email-robherri...@gmail.com you wrote: --- a/doc/README.enetaddr +++ b/doc/README.enetaddr @@ -32,7 +32,9 @@ Correct flow of setting up the MAC address (summarized): 1. Read from hardware in initialize() function 2. Read from environment in net/eth.c after initialize() -3. Give priority to the value in the environment if a conflict +3. Write value to environment if setup in struct eth_device-enetaddr by driver + initialize() function. Give priority to the value in the environment if a + conflict. Sorry, but this description is not correct. You say here that the environment variable should always be written, but this is not the case. Only if it does not exist it shall be set. If it exists, it shall only be read, and in case of inconsistencies a warning shall be printed. How about this: 3. Always use the value in the environment if there is a conflict. If the environment variable is not set and the driver initialized struct eth_device-enetaddr, then print a warning and set the environment variable to initialized by the driver. Rob Best regards, Wolfgang Denk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/9] Unified command execution in one place
Hi Wolfgang, On Tue, Mar 6, 2012 at 11:51 AM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message 1329285566-30386-1-git-send-email-...@chromium.org you wrote: At present two parsers have similar code to execute commands. Also cmd_usage() is called all over the place. This series adds a single function which processes commands called cmd_process(). This new function understands return codes, and in particular CMD_RET_USAGE to indicate a usage error. So rather than calling cmd_usage() themselves, the command handlers can just return this error. There appears to be a run_command2() which is used to run commands with the selected parser. This series changes this in two separate steps to just run_command(), and renames the old run_command() to builtin_run_command(). No one should call this outside main.c since if the hush parser is being used it is wrong to call it. The built-in parser code could move into a separate file perhaps in a future patch. The overall series reduces code size on ARM by about 1KB on my ~160KB U-Boot text region when the hush parser is used, and around 60 bytes when it isn't. I tested this on PPC (TQM5200 config): add/remove: 2/0 grow/shrink: 3/40 up/down: 268/-740 (-472) and ARM (m28evk config): add/remove: 1/0 grow/shrink: 5/38 up/down: 212/-1404 (-1192) so this looks good to me. OK good. Hoping it sorts out the command success/failure problem you saw with the last version also. Out of interest what tool are you using to display that information? Regards, Simon Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de NOTE: The Most Fundamental Particles in This Product Are Held Together by a Gluing Force About Which Little is Currently Known and Whose Adhesive Power Can Therefore Not Be Permanently Guaranteed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] env: Add the ability to merge the saved env with the default.
On Tuesday 06 March 2012 12:07:10 you wrote: On Mon, Mar 5, 2012 at 8:27 PM, Mike Frysinger wrote: also, doesn't the existing `env import` do this ? * env import [-d] [-t | -b | -c] addr [size] * -d: delete existing environment before importing; * otherwise overwrite / append to existion definitions so if we imported the default, we'd get this ? It's not quite possible to just import the default from the saved for two reasons: 1. I don't know of any way to import the default. It's not stored at any well-known address or with any well-known size. 2. The order of precedence would be a little different (default would override saved). ...but I think you're right that using env import is the better way to go. I can always have the default boot command load the overrides into memory and the import them. That works just fine for us. i think this thread is what i was remembering: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/109115 with that in place, it should be easy to implement the functionality you desire on top of that right ? -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 1/9] Remove CMD_PXE's static on run_command()
Dear Simon Glass, In message 1329285566-30386-2-git-send-email-...@chromium.org you wrote: It really isn't clear why this is here and there is no comment, so drop it. Signed-off-by: Simon Glass s...@chromium.org --- common/main.c|3 --- include/common.h |2 -- 2 files changed, 0 insertions(+), 5 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are three principal ways to lose money: wine, women, and engi- neers. While the first two are more pleasant, the third is by far the more certain. - Baron Rothschild, ca. 1800 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/9] Rename run_command() to builtin_run_command()
Dear Simon Glass, In message 1329285566-30386-3-git-send-email-...@chromium.org you wrote: The current run_command() is only one of the parsing options - the other is hush. We should not call run_command() when the hush parser is being used. So we rename this function to better explain its purpose. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v4: - Minor comment change for call to builtin_run_command() Changes in v5: - Adjust commit message to make it easier for Mike to grok arch/arm/cpu/arm926ejs/kirkwood/cpu.c |2 +- board/esd/common/auto_update.c|2 +- board/esd/common/cmd_loadpci.c|2 +- board/esd/du440/du440.c |2 +- common/cmd_bedbug.c |2 +- common/cmd_bootm.c|2 +- common/cmd_source.c |4 ++-- common/main.c |9 + include/common.h |2 +- 9 files changed, 14 insertions(+), 13 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Of all possible committee reactions to any given agenda item, the reaction that will occur is the one which will liberate the greatest amount of hot air.-- Thomas L. Martin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/9] Rename run_command2() to run_command()
Dear Simon Glass, In message 1329285566-30386-4-git-send-email-...@chromium.org you wrote: This is a more sensible name, so rename it. Signed-off-by: Simon Glass s...@chromium.org --- common/cmd_pxe.c |2 +- common/main.c| 10 +- include/common.h |2 +- 3 files changed, 7 insertions(+), 7 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Always try to do things in chronological order; it's less confusing that way. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 5/9] Don't include standard parser if hush is used
Dear Simon Glass, In message 1329285566-30386-6-git-send-email-...@chromium.org you wrote: This saves about 1KB of code space on ARM with CONFIG_SYS_HUSH_PARSER defined. Signed-off-by: Simon Glass s...@chromium.org --- common/main.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If A equals success, then the formula is A = X + Y + Z. X is work. Y is play. Z is keep your mouth shut. - Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 6/9] Create a single cmd_call() function to handle command execution
Dear Simon Glass, In message 1329285566-30386-7-git-send-email-...@chromium.org you wrote: We should aim for a single point of entry to the commands, whichever parser is used. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v5: - Move cmd_call() prototype inside existing #ifdef __ASSEMBLY__ - Tidy up function comment to bring in changes in a later patch common/command.c | 21 + common/hush.c |9 +++-- common/main.c |3 +-- include/command.h |3 +++ 4 files changed, 28 insertions(+), 8 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When you say I wrote a program that crashed Windows, people just stare at you blankly and say Hey, I got those with the system, *for free*.- Linus Torvalds in 3itc77$9...@ninurta.fer.uni-lj.si ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 7/9] Remove interleave of non-U-Boot code in hush
Dear Simon Glass, In message 1329285566-30386-8-git-send-email-...@chromium.org you wrote: There is a nasty interleave of #ifdefs in hush.c where the two code paths have different indents. Remove this ickiness. Signed-off-by: Simon Glass s...@chromium.org Acked-by: Mike Frysinger vap...@gentoo.org --- common/hush.c | 24 +++- 1 files changed, 11 insertions(+), 13 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The evolution of the human race will not be accomplished in the ten thousand years of tame animals, but in the million years of wild animals, because man is and will always be a wild animal. - Charles Galton Darwin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 8/9] Add cmd_process() to process commands in one place
Dear Simon Glass, In message 1329285566-30386-9-git-send-email-...@chromium.org you wrote: We currently have the same code in hush.c and main.c. This brings the code into one place. As an added feature, if the command function returns CMD_RET_USAGE then cmd_process() will print a usage message for the command before returning the standard failure code of 1. ARM code size increases about 32 bytes with this clean-up. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v4: - Add a 'repeatable' parameter to cmd_process() - Make cmd_process() return only success (0) or failure (1) - Rationalise return codes to 0, 1 and usage Changes in v5: - Use existing #ifdef __ASSEMBLY__ rather than create a new one common/command.c | 41 - common/hush.c | 52 common/main.c | 37 + include/command.h | 29 - 4 files changed, 81 insertions(+), 78 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ... bacteriological warfare ... hard to believe we were once foolish enough to play around with that. -- McCoy, The Omega Glory, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 9/9] Convert cmd_usage() calls in common to use a return value
Dear Simon Glass, In message 1329285566-30386-10-git-send-email-...@chromium.org you wrote: Change all files in common/ to use CMD_RET_USAGE instead of calling cmd_usage() directly. This saves about 100 byte or so on ARM. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Fix minor errors one of which created a warning - Squash i2c patch into the common/ patch Changes in v3: - Rebase to master common/cmd_bedbug.c|4 ++-- common/cmd_bmp.c |6 +++--- common/cmd_boot.c |2 +- common/cmd_bootm.c |4 ++-- common/cmd_cache.c |4 ++-- common/cmd_dataflash_mmc_mux.c |2 +- common/cmd_date.c |3 +-- common/cmd_dcr.c |8 common/cmd_df.c|2 +- common/cmd_eeprom.c|2 +- common/cmd_ext2.c |4 ++-- common/cmd_fdc.c |2 +- common/cmd_fdos.c |2 +- common/cmd_fdt.c | 14 +++--- common/cmd_fitupd.c|2 +- common/cmd_flash.c | 14 +++--- common/cmd_fpga.c |4 ++-- common/cmd_gpio.c |2 +- common/cmd_i2c.c | 32 common/cmd_ide.c | 10 +- common/cmd_irq.c |2 +- common/cmd_itest.c |2 +- common/cmd_led.c |6 +++--- common/cmd_load.c |2 +- common/cmd_log.c |4 ++-- common/cmd_md5sum.c|2 +- common/cmd_mdio.c |2 +- common/cmd_mem.c | 22 +++--- common/cmd_mfsl.c | 10 +- common/cmd_mgdisk.c|2 +- common/cmd_mii.c |4 ++-- common/cmd_misc.c |2 +- common/cmd_mmc.c | 14 +++--- common/cmd_mmc_spi.c |3 +-- common/cmd_mp.c|8 common/cmd_mtdparts.c |2 +- common/cmd_nand.c |6 +++--- common/cmd_net.c |6 +++--- common/cmd_nvedit.c| 22 +++--- common/cmd_onenand.c | 12 ++-- common/cmd_otp.c |2 +- common/cmd_pci.c |2 +- common/cmd_portio.c|4 ++-- common/cmd_pxe.c |8 common/cmd_reiser.c|4 ++-- common/cmd_sata.c |8 common/cmd_scsi.c | 15 --- common/cmd_setexpr.c |2 +- common/cmd_sf.c|2 +- common/cmd_sha1sum.c |2 +- common/cmd_strings.c |2 +- common/cmd_time.c |4 ++-- common/cmd_ubi.c |4 ++-- common/cmd_ubifs.c | 10 +- common/cmd_unzip.c |2 +- common/cmd_usb.c |6 +++--- common/main.c |2 +- 57 files changed, 167 insertions(+), 168 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It may be bad manners to talk with your mouth full, but it isn't too good either if you speak when your head is empty. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] PPC: Drop mv6436x_eth_initialize() from net/eth.c
Dear Marek Vasut, In message 1330763972-28106-1-git-send-email-ma...@denx.de you wrote: This function was defined as an extern in net/eth.c, drop that and use standard means of calling it. Signed-off-by: Marek Vasut ma...@denx.de Cc: Reinhard Arlt reinhard.a...@esd-electronics.com --- board/Marvell/db64360/db64360.c |6 +- board/Marvell/db64360/eth.h |1 + board/esd/cpci750/cpci750.c |5 + board/esd/cpci750/eth.h |1 + net/eth.c |4 5 files changed, 12 insertions(+), 5 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You Earth people glorified organized violence for forty centuries. But you imprison those who employ it privately. -- Spock, Dagger of the Mind, stardate 2715.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] PPC: Drop mv6446x_eth_initialize() from net/eth.c
Dear Marek Vasut, In message 1330763972-28106-2-git-send-email-ma...@denx.de you wrote: This function was defined as an extern in net/eth.c, drop that and use standard means of calling it. Signed-off-by: Marek Vasut ma...@denx.de Cc: Stefan Roese s...@denx.de --- board/Marvell/db64460/db64460.c |6 +- board/Marvell/db64460/eth.h |2 ++ board/prodrive/p3mx/eth.h |1 + board/prodrive/p3mx/p3mx.c |5 + net/eth.c |5 - 5 files changed, 13 insertions(+), 6 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A weak mind is like a microscope, which magnifies trifling things, but cannot receive great ones. -- Philip Earl of Chesterfield ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Dear Albert ARIBAUD, In message 4f55bcdc.70...@aribaud.net you wrote: With the documentation / related changes, Wolfgang said on IRC he was OK for now with the additional SPL bits going on. All these commits are feature additions posted after the merge window, aren't they? Yes, but they got added because I asked for them before I wanted to see the SPL stuff go in. So let's pull this into the upcoming release anyway, please. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I mean, I . . . think to understand you, I just don't know what you are saying ...- Terry Pratchett, _Soul Music_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-x86/master
Dear Graeme Russ, In message 4f55e395.1080...@gmail.com you wrote: Hi Wolfgang, The following changes since commit fca94c3fd5deef33442813475a5af1650f2d2830: integrator: remove fragile delay loop from PCI code (2012-03-04 21:15:31 +0100) are available in the git repository at: git://git.denx.de/u-boot-x86.git master Mike Frysinger (1): sc520: fix build warning about unused temp var arch/x86/cpu/sc520/sc520_timer.c |5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Making files is easy under the UNIX operating system. Therefore, users tend to create numerous files using large amounts of file space. It has been said that the only standard thing about all UNIX systems is the message-of-the-day telling users to clean up their files.-- System V.2 administrator's guide ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] net: allow setting env enetaddr from net device setting
Dear Rob, In message 4f566d05.5020...@gmail.com you wrote: +3. Write value to environment if setup in struct eth_device-enetaddr by driver + initialize() function. Give priority to the value in the environment if a + conflict. Sorry, but this description is not correct. You say here that the environment variable should always be written, but this is not the case. Only if it does not exist it shall be set. If it exists, it shall only be read, and in case of inconsistencies a warning shall be printed. How about this: 3. Always use the value in the environment if there is a conflict. If the environment variable is not set and the driver initialized struct eth_device-enetaddr, then print a warning and set the environment variable to initialized by the driver. I find you make it difficult to read without need by explaining it backwards. The environment variable will be compared to the driver initialized struct eth_device-enetaddr. If they differ, a warning is printed, an the environment variable will be used unchanged. If the environment variable is not set, it will be initialized from eth_device-enetaddr, and a warning will be printed. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Ninety-Ninety Rule of Project Schedules: The first ninety percent of the task takes ninety percent of the time, and the last ten percent takes the other ninety percent. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/9] Unified command execution in one place
Dear Simon Glass, In message capnjgz3p_qt42ye+hxe86owden8c9gr+m4e+jwkgdhngd7u...@mail.gmail.com you wrote: OK good. Hoping it sorts out the command success/failure problem you saw with the last version also. I've pulled it, further testing will show ;-) Out of interest what tool are you using to display that information? bloat-o-meter from the kernel directory, like that: - bloat-o-meter u-boot-before-arm u-boot-after-arm add/remove: 1/0 grow/shrink: 5/38 up/down: 212/-1404 (-1192) function old new delta cmd_process- 180+180 static.mod_mem 316 328 +12 do_env_export596 604 +8 do_run 116 120 +4 do_mem_crc 168 172 +4 do_env_set28 32 +4 do_ubifs_mount88 84 -4 do_nandboot 608 604 -4 do_mem_mw188 184 -4 do_mem_loop 244 240 -4 do_mem_cp216 212 -4 do_gpio 288 284 -4 do_go112 108 -4 do_ext2ls296 292 -4 do_ext2load 768 764 -4 do_env_edit 104 100 -4 do_env_default72 68 -4 netboot_common 676 668 -8 do_usbboot 836 828 -8 do_spi_flash13641356 -8 do_setexpr 416 408 -8 do_nand 24762468 -8 do_i2c_mw252 244 -8 do_i2c_md424 416 -8 do_i2c_loop 220 212 -8 do_i2c_crc 276 268 -8 do_date 284 276 -8 static.mod_i2c_mem 520 508 -12 do_sleep 128 116 -12 do_ping 132 120 -12 do_mtdparts 14081396 -12 do_mem_md216 204 -12 do_mem_cmp 396 384 -12 do_ubifs_load212 196 -16 do_mmcops 10721056 -16 do_mii 19201904 -16 do_mem_nm 24 8 -16 do_mem_mm 24 8 -16 do_i2c_read 188 172 -16 do_eeprom292 276 -16 do_i2c_nm 28 8 -20 do_i2c_mm 28 8 -20 run_list_real 20721984 -88 run_command 976 8-968 Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is easier to port a shell than a shell script. - Larry Wall ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] main: unify command parsing functions
Dear Michael Walle, In message 1326499314-8121-1-git-send-email-mich...@walle.cc you wrote: Introduce source_commands() which incorporates run_command2() and parts of source(). All command script are now treated the same, that is newlines are accepted within a command script and variable. Please check if this is still needed after applying Simon Glass' Unified command execution in one place series (and if so, please rebase against current master). Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Very ugly or very beautiful women should be flattered on their understanding, and mediocre ones on their beauty. -- Philip Earl of Chesterfield ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Makefile: Remove mmc_spl related enteries
Dear Chander Kashyap, In message 1320727394-3427-1-git-send-email-chander.kash...@linaro.org you wrote: As mmc_spl now follows spl infrastructure, removed unwanted enteries in Makefile for mmc_spl related compilation. Signed-off-by: Chander Kashyap chander.kash...@linaro.org --- Makefile |8 1 files changed, 0 insertions(+), 8 deletions(-) Applied, thanks. [Typo fixed when committing]. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de IBM uses what I like to call the 'hole-in-the-ground technique' to destroy the competition. IBM digs a big HOLE in the ground and covers it with leaves. It then puts a big POT OF GOLD nearby. Then it gives the call, 'Hey, look at all this gold, get over here fast.' As soon as the competitor approaches the pot, he falls into the pit - John C. Dvorak ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] add nand spl boot for qi_lb60 board
Dear Xiangfu Liu, In message 1326207993-17791-1-git-send-email-xian...@openmobilefree.net you wrote: Signed-off-by: Xiangfu Liu xian...@openmobilefree.net --- Changes for v2: -Add CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST -Cleanup jz4740_nand.c a little Changes for v3: -Remove CONFIG_NAND_SPL_TEXT_BASE, fix the wrong TEXT base under SPL u-boot.lds -Remove overcomplicated 'dd', pad to 32KB SPL instead of 256. comments added in Makefile -Cleanup the qi_lb60.h arch/mips/cpu/xburst/cpu.c |4 + arch/mips/cpu/xburst/start_spl.S | 65 + drivers/mtd/nand/jz4740_nand.c | 40 - include/configs/qi_lb60.h| 166 -- nand_spl/board/qi/qi_lb60/Makefile | 124 + nand_spl/board/qi/qi_lb60/nand_spl.c | 37 nand_spl/board/qi/qi_lb60/u-boot.lds | 62 + 7 files changed, 407 insertions(+), 91 deletions(-) create mode 100644 arch/mips/cpu/xburst/start_spl.S create mode 100644 nand_spl/board/qi/qi_lb60/Makefile create mode 100644 nand_spl/board/qi/qi_lb60/nand_spl.c create mode 100644 nand_spl/board/qi/qi_lb60/u-boot.lds I don't want to see more boards added to the old /nand_spl/ infrastructure. You said you were converting to /spl/ instead? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Die Scheu vor Verantwortung ist die Krankheit unserer Zeit. -- Otto von Bismarck ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: checkstack.pl from Linux added to tools
Dear Tom Rini, In message 1328227625-24653-1-git-send-email-tr...@ti.com you wrote: Added from Linux - commit 62aa2b537c6f5957afd98e29f96897419ed5ebab Signed-off-by: Tom Rini tr...@ti.com --- Makefile|5 ++ tools/checkstack.pl | 172 +++ 2 files changed, 177 insertions(+), 0 deletions(-) create mode 100755 tools/checkstack.pl Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The typical page layout program is nothing more than an electronic light table for cutting and pasting documents. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_cache: use cache/invalidate functions available in common.h
Dear Stefan Kristiansson, In message 1320121272-17613-1-git-send-email-stefan.kristians...@saunalahti.fi you wrote: flush_dcache()/flush_icache() aren't defined in common.h, flush_dcache_all()/invalidate_icache_all() however are. Let the icache and dcache commands use those instead. Signed-off-by: Stefan Kristiansson stefan.kristians...@saunalahti.fi --- common/cmd_cache.c | 16 1 files changed, 8 insertions(+), 8 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The lesser of two evils -- is evil. - Seymour (Sy) Leon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] image: Support FDTs already loaded at their load address
Dear Stephen Warren, In message 1320164902-24190-2-git-send-email-swar...@nvidia.com you wrote: boot_get_fdt() expects a uImage-wrapped FDT to be loaded to a staging location, and then memmove()s it to the load address specified in the header. This change enhances boot_get_fdt() to detect when the image has already been loaded to the correct address, and skip this memmove(). The detection algorithm was written to match the equivalent for the kernel; see bootm_load_os()'s IH_COMP_NONE case. v2: New patch Signed-off-by: Stephen Warren swar...@nvidia.com --- common/image.c | 13 ++--- 1 files changed, 10 insertions(+), 3 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Death, when unnecessary, is a tragic thing. -- Flint, Requiem for Methuselah, stardate 5843.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] net: fec_mxc: allow use with cache enabled
On 03/06/2012 12:49 PM, Marek Vasut wrote:
Dear Eric Nelson,
On 03/06/2012 10:06 AM, Eric Nelson wrote:
On 03/05/2012 01:06 PM, Marek Vasut wrote:
Dear Eric Nelson,
snip
+ if (!fec-rbd_base) {
+ ret = -ENOMEM;
+ goto err2;
+ }
+ memset(fec-rbd_base, 0, size);
+ }
We might want to flush the descriptors to memory after they have been
inited?
We're also missing a flush after the call to fec_rbd_init().
I think we need only one flush in the whole allocation sequence. But you're
probably right here.
Yeah. There's no point in doing memset() and flush() just to write them
again and not flush the proper values.
I'm inclined to move that call to right after the memset and before
a newly-added flush and do the same with the call to tbd_init().
You mean into fec_rbd_init() ?
fec_tbd_init(). See below.
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 0db5ca9..d5d0d5e 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -544,6 +544,7 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
goto err1;
}
memset(fec-tbd_base, 0, size);
+ fec_tbd_init(fec);
flush_dcache_range((unsigned)fec-tbd_base, size);
}
@@ -560,6 +561,13 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
goto err2;
}
memset(fec-rbd_base, 0, size);
+ /*
+* Initialize RxBD ring
+*/
+ if (fec_rbd_init(fec, FEC_RBD_NUM, FEC_MAX_PKT_SIZE) 0) {
+ ret = -ENOMEM;
+ goto err3;
+ }
flush_dcache_range((unsigned)fec-rbd_base,
(unsigned)fec-rbd_base + size);
}
@@ -619,16 +627,6 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
writel((uint32_t)fec-tbd_base, fec-eth-etdsr);
writel((uint32_t)fec-rbd_base, fec-eth-erdsr);
- /*
-* Initialize RxBD/TxBD rings
-*/
- if (fec_rbd_init(fec, FEC_RBD_NUM, FEC_MAX_PKT_SIZE) 0) {
- ret = -ENOMEM;
- goto err3;
- }
- fec_tbd_init(fec);
-
-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] net: fec_mxc: allow use with cache enabled
Dear Eric Nelson,
On 03/06/2012 12:45 PM, Marek Vasut wrote:
Dear Eric Nelson,
On 03/05/2012 01:06 PM, Marek Vasut wrote:
Dear Eric Nelson,
ensure that transmit and receive buffers are cache-line aligned
invalidate cache after each packet received
flush cache before transmitting
Original patch by Marek:
http://lists.denx.de/pipermail/u-boot/2012-February/117695.html
Would be cool to Cc me :-p
Sorry about that.
It's ok, don't worry about it ;-)
[...]
I think this writel() call is bogus and should be removed in
subsequent patch and replaced with simple assignment. It was here
probably due to cache issues on PPC?
The RBD has me puzzled. Do we treat them like registers and use
readx/writex or like in-RAM data structures...
I'd go for the in-RAM data structures, but such conversion should happen
in a separate patch only AFTER the cache support is in.
[...]
Sounds good.
+if (!fec-rbd_base) {
+ret = -ENOMEM;
+goto err2;
+}
+memset(fec-rbd_base, 0, size);
+}
We might want to flush the descriptors to memory after they have been
inited?
Again, good catch.
On this topic (initialization of RBD), I had a bit of a concern
regarding the initialization of things.
In fec_open, the receive buffer descriptors are initialized and the
last one set is to 'wrap'. If this code were to execute when the
controller is live, bad things would surely happen.
I traced through all of the paths I can see, and I believe that
we're safe. It appears that fec_halt() will be called prior to
any call to fec_init() and fec_open().
Yes, this will only happen if something went wrong.
In fec_open() a number of calls to fec_rbd_clean() are made and
a single flush_dcache() is made afterwards.
While this works and causes less thrashing than per-RBD flushes,
I think the code would be simpler if fec_rbd_clean just did the
flush itself. This would also remove the need for a separate
flush in fec_recv.
Not really, rbd might be (and likely is) smaller than cache line,
therefore you won't be able to flush single rbd, unless it's cacheline
aligned, which wastes space.
[...]
Yeah. Please disregard my comments. I wrote that before I fully
appreciated what was being done in fec_recv().
+invalidate_dcache_range(addr, addr + size);
+
The idea here is the following (demo uses 32byte long cachelines):
[DESC1][DESC2][DESC3][DESC4][DESC5][DESC6]
`--- cacheline '
We want to start retrieving contents of DESC3, therefore addr points
to DESC1, size is size of cacheline (I hope there's no hardware with
8 byte cachelines, but this should be ok here).
NOTE[5]: Here we can invalidate the whole cacheline, because the
descriptors so far were modified only be hardware, not by us. We are
not writing anything there so we won't loose any information.
NOTE[6]: This invalidation ensures that we always have a fresh copy of
the cacheline containing all the descriptors, therefore we always have
a fresh status of the descriptors we are about to pick. Since this is
a sequential execution, the cache eviction should not kick in here (or
might it?).
Another way to look at this is this:
After fec_open(), the hardware owns the rbd, and all we should do
is read it. In order to make sure we don't have a stale copy, we
need to call invalidate() before looking at the values.
Tracing the code to find out whether this is true, the only write I see
is within fec_recv() when the last descriptor is full, when the driver
takes ownership of **all** of the descriptors, calling fec_rbd_clean()
on each.
The only thing that looks funky is this:
size = (CONFIG_FEC_ALIGN / sizeof(struct fec_bd)) - 1;
if ((fec-rbd_index size) == size) {
Wouldn't a test of rbd_index against FEC_RBD_NUM be more appropriate?
i.e.
if (fec-rbd_index == FEC_RBD_NUM-1) {
I believe the FEC doesn't always start from rbd_index == 0, and if you
were to receive more than 64 rbds between open() and close(), this
implementation works, your would fail.
Yep. Disregard that too.
snip
The solution is the following:
1) Compute how many descriptors are per-cache line
2) Make sure FEC_RBD_NUM * sizeof(struct fec_bd) is at least 2 *
CONFIG_FEC_DATA_ALIGNMENT in size, see NOTE[11].
3) Once the last RX buffer in the cacheline is processed, mark them all
clean and flush them all, see NOTE[10].
NOTE[10]: This is legal, because the hardware won't use RX descriptors
that it marked dirty (which means not picked up by software yet). We
clean the desciptors in an order the hardware would pick them up again
so there's no problem with race condition either.
Re: [U-Boot] [PATCH V2] net: fec_mxc: allow use with cache enabled
On 03/06/2012 02:22 PM, Marek Vasut wrote:
Dear Eric Nelson,
On 03/06/2012 12:45 PM, Marek Vasut wrote:
Dear Eric Nelson,
On 03/05/2012 01:06 PM, Marek Vasut wrote:
Dear Eric Nelson,
ensure that transmit and receive buffers are cache-line aligned
invalidate cache after each packet received
flush cache before transmitting
Original patch by Marek:
http://lists.denx.de/pipermail/u-boot/2012-February/117695.html
Would be cool to Cc me :-p
Sorry about that.
It's ok, don't worry about it ;-)
[...]
I think this writel() call is bogus and should be removed in
subsequent patch and replaced with simple assignment. It was here
probably due to cache issues on PPC?
The RBD has me puzzled. Do we treat them like registers and use
readx/writex or like in-RAM data structures...
I'd go for the in-RAM data structures, but such conversion should happen
in a separate patch only AFTER the cache support is in.
[...]
Sounds good.
+ if (!fec-rbd_base) {
+ ret = -ENOMEM;
+ goto err2;
+ }
+ memset(fec-rbd_base, 0, size);
+ }
We might want to flush the descriptors to memory after they have been
inited?
Again, good catch.
On this topic (initialization of RBD), I had a bit of a concern
regarding the initialization of things.
In fec_open, the receive buffer descriptors are initialized and the
last one set is to 'wrap'. If this code were to execute when the
controller is live, bad things would surely happen.
I traced through all of the paths I can see, and I believe that
we're safe. It appears that fec_halt() will be called prior to
any call to fec_init() and fec_open().
Yes, this will only happen if something went wrong.
In fec_open() a number of calls to fec_rbd_clean() are made and
a single flush_dcache() is made afterwards.
While this works and causes less thrashing than per-RBD flushes,
I think the code would be simpler if fec_rbd_clean just did the
flush itself. This would also remove the need for a separate
flush in fec_recv.
Not really, rbd might be (and likely is) smaller than cache line,
therefore you won't be able to flush single rbd, unless it's cacheline
aligned, which wastes space.
[...]
Yeah. Please disregard my comments. I wrote that before I fully
appreciated what was being done in fec_recv().
+ invalidate_dcache_range(addr, addr + size);
+
The idea here is the following (demo uses 32byte long cachelines):
[DESC1][DESC2][DESC3][DESC4][DESC5][DESC6]
`--- cacheline '
We want to start retrieving contents of DESC3, therefore addr points
to DESC1, size is size of cacheline (I hope there's no hardware with
8 byte cachelines, but this should be ok here).
NOTE[5]: Here we can invalidate the whole cacheline, because the
descriptors so far were modified only be hardware, not by us. We are
not writing anything there so we won't loose any information.
NOTE[6]: This invalidation ensures that we always have a fresh copy of
the cacheline containing all the descriptors, therefore we always have
a fresh status of the descriptors we are about to pick. Since this is
a sequential execution, the cache eviction should not kick in here (or
might it?).
Another way to look at this is this:
After fec_open(), the hardware owns the rbd, and all we should do
is read it. In order to make sure we don't have a stale copy, we
need to call invalidate() before looking at the values.
Tracing the code to find out whether this is true, the only write I see
is within fec_recv() when the last descriptor is full, when the driver
takes ownership of **all** of the descriptors, calling fec_rbd_clean()
on each.
The only thing that looks funky is this:
size = (CONFIG_FEC_ALIGN / sizeof(struct fec_bd)) - 1;
if ((fec-rbd_index size) == size) {
Wouldn't a test of rbd_index against FEC_RBD_NUM be more appropriate?
i.e.
if (fec-rbd_index == FEC_RBD_NUM-1) {
I believe the FEC doesn't always start from rbd_index == 0, and if you
were to receive more than 64 rbds between open() and close(), this
implementation works, your would fail.
Yep. Disregard that too.
snip
The solution is the following:
1) Compute how many descriptors are per-cache line
2) Make sure FEC_RBD_NUM * sizeof(struct fec_bd) is at least 2 *
CONFIG_FEC_DATA_ALIGNMENT in size, see NOTE[11].
3) Once the last RX buffer in the cacheline is processed, mark them all
clean and flush them all, see NOTE[10].
NOTE[10]: This is legal, because the hardware won't use RX descriptors
that it marked dirty (which means not picked up by software yet). We
clean the desciptors in an order the hardware would pick them up again
so there's no problem with race condition either. The only possible
issue here is if there was hardware with cacheline size smaller than
descriptor size (we should add a check for this
[U-Boot] (no subject)
Mike Frysinger vap...@gentoo.org From: Wolfgang Denk w...@denx.de Fcc: +U-Boot Subject: Re: [U-Boot] [PATCH v4 1/8] sandbox: fdt: Add support for CONFIG_OF_CONTROL MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8bit In-reply-to: 1329349878-16664-1-git-send-email-...@chromium.org References: 1329349878-16664-1-git-send-email-...@chromium.org Comments: In-reply-to Simon Glass s...@chromium.org message dated Wed, 15 Feb 2012 15:51:11 -0800. Dear Simon, In message 1329349878-16664-1-git-send-email-...@chromium.org you wrote: This adds support for a controlling fdt, mirroring the ARM implementation. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: - Use #if defined()..#elif defined, instead of #ifdef..#elif defined arch/sandbox/include/asm/global_data.h |1 + arch/sandbox/lib/board.c |8 2 files changed, 9 insertions(+), 0 deletions(-) I have nearly 50 sandbox related patches in my queue, many based on stuff that was posted before close of the merge window, and I have to admit that I lost track which of these are supposed to be applied, which were merely for RFC, or which have abandonded. Could you please summarize what is supposed to go in for this release, and what should go into the next branch? Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When the tide of life turns against you And the current upsets your boat Don't waste tears on what might have been Just lie on your back and float. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] spl: add ymodem support
We have an omap l138 based board without jtag and empty spi flash.
UART is an only way to load something on this board, so we are using
uart to load spl image u-boot and then we are using ymodem to load
the rest part of u-boot.
---
arch/arm/cpu/arm926ejs/davinci/spl.c | 25 +++
common/Makefile |4 ++-
common/xyzModem.c| 55 ++
include/xyzModem.h |5 +++
lib/Makefile |1 +
5 files changed, 89 insertions(+), 1 deletions(-)
Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com
diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c
b/arch/arm/cpu/arm926ejs/davinci/spl.c
index 74632e5..1fedf7d 100644
--- a/arch/arm/cpu/arm926ejs/davinci/spl.c
+++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
@@ -28,6 +28,7 @@
#include ns16550.h
#include malloc.h
#include spi_flash.h
+#include xyzModem.h
#ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
@@ -93,4 +94,28 @@ void board_init_r(gd_t *id, ulong dummy)
puts(SPI boot...\n);
spi_boot();
#endif
+#ifdef CONFIG_SPL_YMODEM_LOAD
+ mem_malloc_init(CONFIG_SYS_TEXT_BASE - CONFIG_SYS_MALLOC_LEN,
+ CONFIG_SYS_MALLOC_LEN);
+
+ gd = gdata;
+ gd-bd = bdata;
+ gd-flags |= GD_FLG_RELOC;
+ gd-baudrate = CONFIG_BAUDRATE;
+ serial_init(); /* serial communications setup */
+ gd-have_console = 1;
+
+ while(1){
+ charch;
+
+ while(!tstc()){
+ puts(Ymodem boot: press Enter to continue...\n);
+ mdelay(1000);
+ }
+ ch = getc();
+ if ((ch == '\r') || (ch == '\n')) break;
+ }
+ puts(Ymodem boot...\n);
+ ymodem_boot();
+#endif
}
diff --git a/common/Makefile b/common/Makefile
index 2a31c62..417a517 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -188,7 +188,9 @@ COBJS-y += console.o
COBJS-y += dlmalloc.o
COBJS-y += memsize.o
COBJS-y += stdio.o
-
+ifdef CONFIG_SPL_BUILD
+COBJS-$(CONFIG_SPL_YMODEM_LOAD) += xyzModem.o
+endif
COBJS := $(sort $(COBJS-y))
XCOBJS := $(sort $(XCOBJS-y))
diff --git a/common/xyzModem.c b/common/xyzModem.c
index a1f955b..8e024d0 100644
--- a/common/xyzModem.c
+++ b/common/xyzModem.c
@@ -847,3 +847,58 @@ GETC_IO_FUNCS (xyzModem_io, xyzModem_stream_open,
xyzModem_stream_close,
RedBoot_load (xmodem, xyzModem_io, false, false, xyzModem_xmodem);
RedBoot_load (ymodem, xyzModem_io, false, false, xyzModem_ymodem);
#endif
+
+
+#ifdef CONFIG_SPL_BUILD
+#ifdef CONFIG_SPL_YMODEM_LOAD
+static int getcxmodem(void) {
+ if (tstc())
+ return (getc());
+ return -1;
+}
+
+/*
+ * The main entry for YMODEM booting. It's necessary that SDRAM is already
+ * configured and available since this code loads the main U-Boot image
+ * from serial line into SDRAM and starts it from there.
+ */
+void ymodem_boot(void)
+{
+ int size;
+ int err;
+ int res;
+ connection_info_t info;
+ void (*uboot)(void) __noreturn;
+ ulong store_addr = ~0;
+
+ /*
+* Load U-Boot image from serial line into RAM
+*/
+ size = 0;
+ info.mode = xyzModem_ymodem;
+ res = xyzModem_stream_open (info, err);
+ if (!res) {
+ store_addr = CONFIG_SYS_TEXT_BASE;
+ while ((res =
+ xyzModem_stream_read (store_addr, 1024, err)) 0) {
+ store_addr += res;
+ size += res;
+ }
+ } else {
+ printf (%s\n, xyzModem_error (err));
+ hang();
+ }
+
+ xyzModem_stream_close (err);
+ xyzModem_stream_terminate (false, getcxmodem);
+
+ printf (## Total Size = 0x%08x = %d Bytes\n, size, size);
+
+ /*
+* Jump to U-Boot image
+*/
+ uboot = (void *) CONFIG_SYS_TEXT_BASE;
+ (*uboot)();
+}
+#endif /* CONFIG_SPL_YMODEM_LOAD */
+#endif /* CONFIG_SPL_BUILD */
diff --git a/include/xyzModem.h b/include/xyzModem.h
index f437bbd..275894c 100644
--- a/include/xyzModem.h
+++ b/include/xyzModem.h
@@ -58,6 +58,9 @@
#ifndef _XYZMODEM_H_
#define _XYZMODEM_H_
+#include linux/types.h
+#include linux/compiler.h
+
#define xyzModem_xmodem 1
#define xyzModem_ymodem 2
/* Don't define this until the protocol support is in place */
@@ -114,4 +117,6 @@ void xyzModem_stream_terminate(bool method, int
(*getc)(void));
int xyzModem_stream_read(char *buf, int size, int *err);
char *xyzModem_error(int err);
+void ymodem_boot(void) __noreturn;
+
#endif /* _XYZMODEM_H_ */
diff --git a/lib/Makefile b/lib/Makefile
index e6e6ec6..2983530 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -52,6 +52,7 @@ COBJS-$(CONFIG_SHA256) += sha256.o
COBJS-y+= strmhz.o
COBJS-$(CONFIG_RBTREE) += rbtree.o
else
+COBJS-$(CONFIG_SPL_YMODEM_LOAD) += crc16.o
COBJS-$(CONFIG_SPL_SPI_FLASH_SUPPORT) +=
[U-Boot] [PATCH 3/3] arm/davinci/da850: add uart0 pinmux
---
arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c |5 +
arch/arm/include/asm/arch-davinci/hardware.h|1 +
arch/arm/include/asm/arch-davinci/pinmux_defs.h |1 +
3 files changed, 7 insertions(+), 0 deletions(-)
Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com
diff --git a/arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c
b/arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c
index fa07fb5..dbae5fa 100644
--- a/arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c
+++ b/arch/arm/cpu/arm926ejs/davinci/da850_pinmux.c
@@ -35,6 +35,11 @@ const struct pinmux_config spi1_pins_scs0[] = {
};
/* UART pin muxer settings */
+const struct pinmux_config uart0_pins_txrx[] = {
+ { pinmux(3), 2, 4 }, /* UART0_RXD */
+ { pinmux(3), 2, 5 }, /* UART0_TXD */
+};
+
const struct pinmux_config uart1_pins_txrx[] = {
{ pinmux(4), 2, 6 }, /* UART1_RXD */
{ pinmux(4), 2, 7 }, /* UART1_TXD */
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h
b/arch/arm/include/asm/arch-davinci/hardware.h
index b145c6e..0a1e2cd 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -447,6 +447,7 @@ struct davinci_pllc_regs {
/* Clock IDs */
enum davinci_clk_ids {
DAVINCI_SPI0_CLKID = 2,
+ DAVINCI_UART0_CLKID = 2,
DAVINCI_UART2_CLKID = 2,
DAVINCI_MMC_CLKID = 2,
DAVINCI_MDIO_CLKID = 4,
diff --git a/arch/arm/include/asm/arch-davinci/pinmux_defs.h
b/arch/arm/include/asm/arch-davinci/pinmux_defs.h
index 07aceaa..eddb3f7 100644
--- a/arch/arm/include/asm/arch-davinci/pinmux_defs.h
+++ b/arch/arm/include/asm/arch-davinci/pinmux_defs.h
@@ -28,6 +28,7 @@ extern const struct pinmux_config spi1_pins_base[3];
extern const struct pinmux_config spi1_pins_scs0[1];
/* UART pin muxer settings */
+extern const struct pinmux_config uart0_pins_txrx[2];
extern const struct pinmux_config uart1_pins_txrx[2];
extern const struct pinmux_config uart2_pins_txrx[2];
extern const struct pinmux_config uart2_pins_rtscts[2];
--
1.7.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] ns16550 has a different register layout on SOC_DA8XX
also fix NS16550_init() as we need 16x divider
---
drivers/serial/ns16550.c |2 +-
include/ns16550.h|9 +
2 files changed, 10 insertions(+), 1 deletions(-)
Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 0c23955..e6dec0c 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -52,7 +52,7 @@ void NS16550_init(NS16550_t com_port, int baud_divisor)
serial_out((baud_divisor 8) 0xff, com_port-dlm);
serial_out(UART_LCRVAL, com_port-lcr);
#if (defined(CONFIG_OMAP) !defined(CONFIG_OMAP3_ZOOM2)) || \
- defined(CONFIG_AM33XX)
+defined(CONFIG_AM33XX) || defined(CONFIG_SOC_DA8XX)
#if defined(CONFIG_APTIX)
/* /13 mode so Aptix 6MHz can hit 115200 */
diff --git a/include/ns16550.h b/include/ns16550.h
index e9d2eda..51cb5b4 100644
--- a/include/ns16550.h
+++ b/include/ns16550.h
@@ -46,6 +46,14 @@ struct NS16550 {
UART_REG(lsr); /* 5 */
UART_REG(msr); /* 6 */
UART_REG(spr); /* 7 */
+#ifdef CONFIG_SOC_DA8XX
+ UART_REG(reg8); /* 8 */
+ UART_REG(reg9); /* 9 */
+ UART_REG(revid1); /* A */
+ UART_REG(revid2); /* B */
+ UART_REG(pwr_mgmt); /* C */
+ UART_REG(mdr1); /* D */
+#else
UART_REG(mdr1); /* 8 */
UART_REG(reg9); /* 9 */
UART_REG(regA); /* A */
@@ -58,6 +66,7 @@ struct NS16550 {
UART_REG(ssr); /* 11*/
UART_REG(reg12);/* 12*/
UART_REG(osc_12m_sel); /* 13*/
+#endif
};
#define thr rbr
--
1.7.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] spl: add ymodem support
On Tue, Mar 6, 2012 at 5:54 PM, Mikhail Kshevetskiy mikhail.kshevets...@gmail.com wrote: We have an omap l138 based board without jtag and empty spi flash. UART is an only way to load something on this board, so we are using uart to load spl image u-boot and then we are using ymodem to load the rest part of u-boot. --- arch/arm/cpu/arm926ejs/davinci/spl.c | 25 +++ common/Makefile | 4 ++- common/xyzModem.c | 55 ++ include/xyzModem.h | 5 +++ lib/Makefile | 1 + 5 files changed, 89 insertions(+), 1 deletions(-) Signed-off-by: Mikhail Kshevetskiy mikhail.kshevets...@gmail.com Your Signed-off-by line should be placed above the --- line. Same applies for the other patches. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] net: fec_mxc: allow use with cache enabled
Dear Eric Nelson,
On 03/06/2012 12:49 PM, Marek Vasut wrote:
Dear Eric Nelson,
On 03/06/2012 10:06 AM, Eric Nelson wrote:
On 03/05/2012 01:06 PM, Marek Vasut wrote:
Dear Eric Nelson,
snip
+ if (!fec-rbd_base) {
+ ret = -ENOMEM;
+ goto err2;
+ }
+ memset(fec-rbd_base, 0, size);
+ }
We might want to flush the descriptors to memory after they have been
inited?
We're also missing a flush after the call to fec_rbd_init().
I think we need only one flush in the whole allocation sequence. But
you're probably right here.
Yeah. There's no point in doing memset() and flush() just to write them
again and not flush the proper values.
I'm inclined to move that call to right after the memset and before
a newly-added flush and do the same with the call to tbd_init().
You mean into fec_rbd_init() ?
fec_tbd_init(). See below.
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 0db5ca9..d5d0d5e 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -544,6 +544,7 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
goto err1;
}
memset(fec-tbd_base, 0, size);
+ fec_tbd_init(fec);
flush_dcache_range((unsigned)fec-tbd_base, size);
}
@@ -560,6 +561,13 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
goto err2;
}
memset(fec-rbd_base, 0, size);
+ /*
+* Initialize RxBD ring
+*/
+ if (fec_rbd_init(fec, FEC_RBD_NUM, FEC_MAX_PKT_SIZE) 0) {
+ ret = -ENOMEM;
+ goto err3;
+ }
flush_dcache_range((unsigned)fec-rbd_base,
(unsigned)fec-rbd_base + size);
}
@@ -619,16 +627,6 @@ static int fec_init(struct eth_device *dev, bd_t* bd)
writel((uint32_t)fec-tbd_base, fec-eth-etdsr);
writel((uint32_t)fec-rbd_base, fec-eth-erdsr);
- /*
-* Initialize RxBD/TxBD rings
-*/
- if (fec_rbd_init(fec, FEC_RBD_NUM, FEC_MAX_PKT_SIZE) 0) {
- ret = -ENOMEM;
- goto err3;
- }
- fec_tbd_init(fec);
-
-
I see, makes sense.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (no subject)
On Tuesday 06 March 2012 16:29:12 Wolfgang Denk wrote: I have nearly 50 sandbox related patches in my queue, many based on stuff that was posted before close of the merge window, and I have to admit that I lost track which of these are supposed to be applied, which were merely for RFC, or which have abandonded. Could you please summarize what is supposed to go in for this release, and what should go into the next branch? i've been maintaining things in my blackfin repo in the sandbox branch. all the patches in patchwork should be labeled appropriately. i don't think there's anything that needs to be merged directly by you as i'll be sending a pull request in the next merge window. where is your queue ? your inbox ? -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] spl: add ymodem support
On Wed, Mar 07, 2012 at 12:54:05AM +0400, Mikhail Kshevetskiy wrote: We have an omap l138 based board without jtag and empty spi flash. UART is an only way to load something on this board, so we are using uart to load spl image u-boot and then we are using ymodem to load the rest part of u-boot. Dear Mikhail, I am asking mainly out of curiousity, rather than giving feedback on the patch, but the OMAP-L138 boot ROM has the capability to load both SPL and U-Boot into empty SPI flash using the UART and sfh program or equivalent. (sfh is serial flash host for those following along, a program to talk to the boot ROM over the UART and download some code that the boot ROM can burn into SPI flash). What is the advantage in allowing the SPL to flash U-Boot also? Many thanks, and bye for now, -- Laurence Withers, lwith...@guralp.comhttp://www.guralp.com/ Direct tel:+447753988197 or tel:+44408643 Software Engineer General support queries: supp...@guralp.com CMG-DCM CMG-EAM CMG-NAM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] main: unify command parsing functions
Hi Wolfgang, Am Dienstag 06 März 2012, 21:39:16 schrieb Wolfgang Denk: In message 1326499314-8121-1-git-send-email-mich...@walle.cc you wrote: Introduce source_commands() which incorporates run_command2() and parts of source(). All command script are now treated the same, that is newlines are accepted within a command script and variable. Please check if this is still needed after applying Simon Glass' Unified command execution in one place series (and if so, please rebase against current master). This patches is superseded by [PATCH 1/2] Add run_command_list() to run a list of commands [PATCH 2/2] Allow newlines within command environment vars by Simon Glass. These patches haven't been merged yet. -- michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8 v3] powerpc/srio: Rewrite the struct ccsr_rio
On Tue, Mar 6, 2012 at 3:45 AM, Liu Gang gang@freescale.com wrote: Rewrite this struct for the support of two ports and two message units registers. Signed-off-by: Liu Gang gang@freescale.com --- Changes in v2: - Change the subject and commit message. - Remove the offsets in the comments. - Rewrite the struct for the support of two ports and two message units registers. Changes in v3: - Move some SRIO macros to the appropriate board configure header files. arch/powerpc/include/asm/immap_85xx.h | 384 +++-- include/configs/MPC8548CDS.h | 5 + include/configs/MPC8568MDS.h | 5 + include/configs/MPC8569MDS.h | 5 + include/configs/P2020DS.h | 5 + include/configs/P2041RDB.h | 3 + include/configs/corenet_ds.h | 7 + It occurs to me that these defines are really better suited for arch/powerpc/include/asm/config_mpc85xx.h. Notice that's where the other SOC-specific configs (like number of devices) are kept. Changing things there will make it easier to support different boards. Andy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] main: unify command parsing functions
Hi, On Tue, Mar 6, 2012 at 2:29 PM, Michael Walle mich...@walle.cc wrote: Hi Wolfgang, Am Dienstag 06 März 2012, 21:39:16 schrieb Wolfgang Denk: In message 1326499314-8121-1-git-send-email-mich...@walle.cc you wrote: Introduce source_commands() which incorporates run_command2() and parts of source(). All command script are now treated the same, that is newlines are accepted within a command script and variable. Please check if this is still needed after applying Simon Glass' Unified command execution in one place series (and if so, please rebase against current master). This patches is superseded by [PATCH 1/2] Add run_command_list() to run a list of commands [PATCH 2/2] Allow newlines within command environment vars by Simon Glass. These patches haven't been merged yet. Yes - in fact these should go into 'next' I think. But first I need to respond to Wolfgang's email on that series. Regards, Simon -- michael ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 0/5] add bootable partition support
From: Rob Herring rob.herr...@calxeda.com The primary goal of this series is to enable using the 1st bootable partition as the default partition for disk boot related commands. Every command that takes a dev[:part] option duplicates the same parsing code, so this series consolidates the parsing code to a single function. There are obviously other block device commands that need to be converted still. I will do these once there is some basic agreement on the initial support. Rob Rob Herring (5): disk/part: check bootable flag for DOS partitions disk/part: introduce get_device_and_partition cmd_ext2: use common get_device_and_partition function cmd_fat: use common get_device_and_partition function cmd_scsi: use common get_device_and_partition function common/cmd_ext2.c | 71 +++ common/cmd_fat.c | 72 +++- common/cmd_scsi.c | 58 -- disk/part.c | 60 disk/part_dos.c | 11 ++- include/part.h|5 +++ 6 files changed, 127 insertions(+), 150 deletions(-) -- 1.7.5.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
