[U-Boot] code looping in_ram in start.S
Hi , I am trying to bring up u-boot1.1.3 on a custom mpc8247 board, having 32MB flash and two 32 M SDRAM . See a problem after the relocation happens. The code gets relocated from Flash to RAM correctly. But when the control goes to in_ram it gets looped there And then gets reset. I have done all the SDRAM tests all are successful. So how to proceed for this issue Below is the SDRAM initialization sequence. ; init SDRAM Init (PPC bus) WM16 0xF0010184 0x1000;MPTPR WM8 0xF001019C 0x18 ;PSRT WM32 0xF001010c 0xFC002d00 ;OR1 WM32 0xF0010108 0x1841 ;BR1 WM32 0xF0010190 0xeb29a4a3 ;PSDMR: Precharge all banks WM8 0x 0x00 ;Access SDRAM WM32 0xF0010190 0xcB29a4a3;PSDMR: CBR Refresh WM8 0x 0xFF ;Access SDRAM WM8 0x 0xFF ;Access SDRAM WM8 0x 0xFF ;Access SDRAM WM8 0x 0xFF ;Access SDRAM WM8 0x 0xFF ;Access SDRAM WM8 0x 0xFF ;Access SDRAM WM8 0x 0xFF ;Access SDRAM WM8 0x 0xFF ;Access SDRAM WM32 0xF0010190 0xdb29a4a3;PSDMR: Mode Set WM8 0x 0x00 ;Access SDRAM WM32 0xF0010190 0xc329a4a3;PSDMR: enable refresh, normal operation Regards, Smitha Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ORIGEN: Add MMC SPL support
Dear Chander Kashyap , On 27 June 2011 17:37, Chander Kashyap chander.kash...@linaro.org wrote: Adds mmc boot support. Signed-off-by: Chander Kashyap chander.kash...@linaro.org --- mmc_spl/board/samsung/origen/Makefile | 105 mmc_spl/board/samsung/origen/mmc_boot.c | 75 +++ mmc_spl/board/samsung/origen/tools/mkv310_image.c | 139 + mmc_spl/board/samsung/origen/u-boot.lds | 86 + 4 files changed, 405 insertions(+), 0 deletions(-) create mode 100644 mmc_spl/board/samsung/origen/Makefile create mode 100644 mmc_spl/board/samsung/origen/mmc_boot.c create mode 100644 mmc_spl/board/samsung/origen/tools/mkv310_image.c create mode 100644 mmc_spl/board/samsung/origen/u-boot.lds diff --git a/mmc_spl/board/samsung/origen/tools/mkv310_image.c b/mmc_spl/board/samsung/origen/tools/mkv310_image.c new file mode 100644 index 000..51f16f2 --- /dev/null +++ b/mmc_spl/board/samsung/origen/tools/mkv310_image.c @@ -0,0 +1,139 @@ +/* + * Copyright (C) 2011 Samsung Electronics + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include stdio.h +#include stdlib.h +#include unistd.h +#include fcntl.h +#include errno.h +#include string.h please apply Dirk Behme's patch here. http://patchwork.ozlabs.org/patch/104270/ + +#define BUFSIZE (16*1024) +#define IMG_SIZE (16*1024) +#define HEADER_SIZE 16 +#define FILE_PERM (S_IRUSR | S_IWUSR | S_IRGRP \ + | S_IWGRP | S_IROTH | S_IWOTH) +/* +* Requirement: +* IROM code reads first 14K bytes from boot device. +* It then calculates the checksum of 14K-4 bytes and compare with data at +* 14K-4 offset. +* +* This function takes two filenames: +* IN u-boot-spl.bin and +* OUT u-boot-mmc-spl.bin as filenames. +* It reads the u-boot-spl.bin in 16K buffer. +* It calculates checksum of 14K-4 Bytes and stores at 14K-4 offset in buffer. +* It writes the buffer to u-boot-mmc-spl.bin file. +*/ + Thanks Minkyu Kang -- from. prom. www.promsoft.net ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] code looping in_ram in start.S
On Tuesday, July 12, 2011 07:42:56 AM smitha.va...@wipro.com wrote: Hi , I am trying to bring up u-boot1.1.3 on a custom mpc8247 board, having 32MB flash and two 32 M SDRAM . Can you please try a newer version (git clone git://git.denx.de/u-boot.git) See a problem after the relocation happens. The code gets relocated from Flash to RAM correctly. But when the control goes to in_ram it gets looped there And then gets reset. I have done all the SDRAM tests all are successful. So how to proceed for this issue Below is the SDRAM initialization sequence. ; init SDRAM Init (PPC bus) WM16 0xF0010184 0x1000;MPTPR WM8 0xF001019C 0x18 ;PSRT WM32 0xF001010c 0xFC002d00 ;OR1 WM32 0xF0010108 0x1841 ;BR1 WM32 0xF0010190 0xeb29a4a3 ;PSDMR: Precharge all banks WM8 0x 0x00 ;Access SDRAM WM32 0xF0010190 0xcB29a4a3;PSDMR: CBR Refresh WM8 0x 0xFF ;Access SDRAM WM8 0x 0xFF ;Access SDRAM WM8 0x 0xFF ;Access SDRAM WM8 0x 0xFF ;Access SDRAM WM8 0x 0xFF ;Access SDRAM WM8 0x 0xFF ;Access SDRAM WM8 0x 0xFF ;Access SDRAM WM8 0x 0xFF ;Access SDRAM WM32 0xF0010190 0xdb29a4a3;PSDMR: Mode Set WM8 0x 0x00 ;Access SDRAM WM32 0xF0010190 0xc329a4a3;PSDMR: enable refresh, normal operation Regards, Smitha Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request u-boot-blackfin.git
The following changes since commit 68d4230c3ccce96a72c5b99e48399bf1796fe3c6:
powerpc/85xx: Add default usb mode and phy type to hwconfig (2011-07-11
13:24:21 -0500)
are available in the git repository at:
git://www.denx.de/git/u-boot-blackfin.git master
Harald Krapfenbauer (2):
Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update network settings
Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: enable mmc_spi support
Mike Frysinger (19):
Blackfin: uart: move debug buffers into local bss
Blackfin: uart: add multiple serial support
Blackfin: adi boards: enable multi serial support by default
Blackfin: dont reset SWRST on newer bf526 parts
Blackfin: add init.elf helper code
Blackfin: uart: fix printf warning
Blackfin: post: setup default CONFIG_SYS_POST_WORD_ADDR
Blackfin: gpio: optimize free path a little
Blackfin: sync MMR read/write helpers with Linux
Blackfin: portmux: allow header to be included in assembly files
Blackfin: drop unused dma.h header from start code
Blackfin: adi boards: enable pretty flash progress output
Blackfin: split out async setup
Blackfin: serial: convert to bfin_{read,write} helpers
Blackfin: update anomaly lists to latest public info
Blackfin: adi boards: also set stderr to nc with helper
Blackfin: serial: move early debug strings into .rodata section
Blackfin: switch to common display_options()
Blackfin: jtag-console: fix timer usage
Makefile |3 +-
arch/blackfin/cpu/.gitignore |3 +
arch/blackfin/cpu/Makefile |7 +-
arch/blackfin/cpu/cpu.c| 16 +-
arch/blackfin/cpu/gpio.c |2 +
arch/blackfin/cpu/init.S |9 +
arch/blackfin/cpu/init.lds.S | 25 +++
arch/blackfin/cpu/initcode.c | 61 ++-
arch/blackfin/cpu/initcode.h | 71 +++
arch/blackfin/cpu/jtag-console.c |4 +-
arch/blackfin/cpu/reset.c |4 +-
arch/blackfin/cpu/serial.c | 234 ++--
arch/blackfin/cpu/serial.h | 70 +---
arch/blackfin/cpu/start.S |1 -
arch/blackfin/include/asm/blackfin_local.h | 88 +-
arch/blackfin/include/asm/config.h |3 +
arch/blackfin/include/asm/gpio.h |3 +-
arch/blackfin/include/asm/mach-bf506/anomaly.h | 25 ++-
arch/blackfin/include/asm/mach-bf518/anomaly.h | 28 ++-
arch/blackfin/include/asm/mach-bf527/anomaly.h | 38 +++--
arch/blackfin/include/asm/mach-bf533/anomaly.h | 23 ++-
arch/blackfin/include/asm/mach-bf537/anomaly.h | 37 +++--
arch/blackfin/include/asm/mach-bf538/anomaly.h | 42 +++--
arch/blackfin/include/asm/mach-bf548/anomaly.h | 227 +--
arch/blackfin/include/asm/mach-bf561/anomaly.h | 136 --
arch/blackfin/include/asm/portmux.h|4 +
arch/blackfin/lib/board.c |6 +-
board/cm-bf537e/cm-bf537e.c| 34 +++--
board/cm-bf537u/cm-bf537u.c| 39 ++--
board/tcm-bf537/tcm-bf537.c| 34 +++--
common/serial.c|3 +
include/configs/bf537-stamp.h |1 -
include/configs/bfin_adi_common.h | 12 +-
include/configs/cm-bf537e.h| 20 ++-
include/configs/cm-bf537u.h| 24 ++-
include/configs/tcm-bf537.h| 20 ++-
include/serial.h |9 +
37 files changed, 904 insertions(+), 462 deletions(-)
create mode 100644 arch/blackfin/cpu/init.S
create mode 100644 arch/blackfin/cpu/init.lds.S
create mode 100644 arch/blackfin/cpu/initcode.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] code looping in_ram in start.S
Dear smitha.va...@wipro.com, In message 07acdfb8eca8ef47863a613bc01bbb2203243...@hyd-mkd-mbx02.wipro.com you wrote: I am trying to bring up u-boot1.1.3 on a custom mpc8247 board, having 32MB flash and two 32 M SDRAM . See a problem after the relocation happens. The code gets relocated from Flash to RAM correctly. But when the control goes to in_ram it gets looped there And then gets reset. I have done all the SDRAM tests all are successful. So how to proceed for this issue First thing you should to is update. Version 1.1.3 is about 6 years old, and for software this means it predates the dinosaurs. Read: this old stuff is completely unsupported. Second: read the FAQ; the problem you are running into is described here: http://www.denx.de/wiki/view/DULG/UBootCrashAfterRelocation 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 mouse is an elephant built by the Japanese. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net/eth.c: make eth_get_dev_by_name(NULL) safe
On Monday, July 11, 2011 05:53:49 Helmut Raiger wrote: On 07/07/2011 07:46 PM, Mike Frysinger wrote: those NULL checks should not be necessary either. a correctly written networking driver should only register itself with the miiphy layer when it has successfully registered itself with the eth layer. thus any of the miiphy callbacks should always come in with a name that is found via eth_get_dev_by_name(). You are right, in a perfect world nobody ever falters. you missed the point. either the driver works, or it doesnt. this func is used in such a way that the behavior is fairly deterministic (as i clearly laid out). it isnt relying on allocated memory that could fall to be allocated for example. checking for NULLs here and gracefully returning is unnecessary overhead imo as you're only catering to broken code. fix the broken drivers instead. I could not find drivers that have the potential of delivering NULLs to the miiphy_read and write functions, I simply refused to test at this level. Either there is a potential of having NULL passed then the test should be in eth_get_dev_by_name() or there is none then we should simply leave it away. i did go through the level of detail and showed the call graphs ... none of which should allow a driver tested as working to even once hit the NULL path. I'm rather indifferent to either solution. And about 'catering to broken code': It must be broken in 2 ways, first it must pass a NULL to the function and second it must ignore the return code. not necessarily. many platforms will abort on NULL pointer accesses. by your logic, why put the NULL check in eth_get_dev_by_name() ? why not handle strcmp(NULL, NULL) too ? then eth_get_dev_by_name() would automatically get fixed as would all other call points. For strcmp() you have several issues at hand: Compatibility, performance and even a logical problem. What should be the result in case one of the arguments is NULL (or both). fair enough on the API, but your performance aspect is kind of hard to swallow when you turn around and say that NULL pointer checking elsewhere is minuscule. And finally we are discussing a few _chararacters_ of code and a probably a single assembly instruction. it's not a single assembly insn. try generating it. it adds like 8 to my platform, mostly because of the increased register pressure. but the point isnt the impact of this single check. it sets the precedence that every function in u-boot that takes a pointer should start over protecting itself against poorly written code originating elsewhere. now your few characters is quite a bit more. what i wouldnt mind is annotating the prototype with gcc attributes saying that the argument is nonnull. ... #define __nonnull(x) __attribute__((__nonnull__ x)) ... extern struct eth_device *eth_get_dev_by_name(const char *devname) __nonnull(1); ... -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 00/18] Blackfin updates for v2011.09
On Tuesday, June 28, 2011 15:36:09 Mike Frysinger wrote: Many of these have been posted already, but some have not. We've pulled some updates from the Linux port, added support for multiple serial devs at the same time, and random tweaks/improvements all over. Harald Krapfenbauer (2): Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: update network settings Blackfin: cm-bf537e/cm-bf537u/tcm-bf537: enable mmc_spi support these are the only ones that have been previously posted. they were part of a diff patchset for merging that was ultimately split up and the other changesets were merged. these two are unmodified from their previous appearance on the list. -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] SMDKV310: Fix host compilation of mkv310_image
On 12 July 2011 00:19, Dirk Behme dirk.be...@googlemail.com wrote: From: Dirk Behme dirk.be...@googlemail.com Fix compilation of mkv310_image host tool tools/mkv310_image.c: In function 'main': tools/mkv310_image.c:67: error: 'S_IRUSR' undeclared (first use in this function) tools/mkv310_image.c:67: error: (Each undeclared identifier is reported only once tools/mkv310_image.c:67: error: for each function it appears in.) tools/mkv310_image.c:67: error: 'S_IWUSR' undeclared (first use in this function) tools/mkv310_image.c:67: error: 'S_IRGRP' undeclared (first use in this function) tools/mkv310_image.c:67: error: 'S_IWGRP' undeclared (first use in this function) tools/mkv310_image.c:67: error: 'S_IROTH' undeclared (first use in this function) tools/mkv310_image.c:67: error: 'S_IWOTH' undeclared (first use in this function) resulting from a 'make smdkv310_config'. Signed-off-by: Dirk Behme dirk.be...@googlemail.com --- Changes in v2: Use sys/stat.h instead of linux/stat.h Note: mkv310_image is compiled for the host by the host's gcc: cd mmc_spl/board/samsung/smdkv310 gcc tools/mkv310_image.c -o tools/mkv310_mmc_spl_exec mmc_spl/board/samsung/smdkv310/tools/mkv310_image.c | 1 + 1 file changed, 1 insertion(+) Index: u-boot.git/mmc_spl/board/samsung/smdkv310/tools/mkv310_image.c === --- u-boot.git.orig/mmc_spl/board/samsung/smdkv310/tools/mkv310_image.c +++ u-boot.git/mmc_spl/board/samsung/smdkv310/tools/mkv310_image.c @@ -26,6 +26,7 @@ #include fcntl.h #include errno.h #include string.h +#include sys/stat.h #define CHECKSUM_OFFSET (14*1024-4) #define BUFSIZE (16*1024) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Ok. Dear Minkyu, Please apply -- with warm regards, Chander Kashyap ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] ORIGEN: Add MMC SPL support
On 12 July 2011 11:37, Minkyu Kang proms...@gmail.com wrote: Dear Chander Kashyap , On 27 June 2011 17:37, Chander Kashyap chander.kash...@linaro.org wrote: Adds mmc boot support. Signed-off-by: Chander Kashyap chander.kash...@linaro.org --- mmc_spl/board/samsung/origen/Makefile | 105 mmc_spl/board/samsung/origen/mmc_boot.c | 75 +++ mmc_spl/board/samsung/origen/tools/mkv310_image.c | 139 + mmc_spl/board/samsung/origen/u-boot.lds | 86 + 4 files changed, 405 insertions(+), 0 deletions(-) create mode 100644 mmc_spl/board/samsung/origen/Makefile create mode 100644 mmc_spl/board/samsung/origen/mmc_boot.c create mode 100644 mmc_spl/board/samsung/origen/tools/mkv310_image.c create mode 100644 mmc_spl/board/samsung/origen/u-boot.lds diff --git a/mmc_spl/board/samsung/origen/tools/mkv310_image.c b/mmc_spl/board/samsung/origen/tools/mkv310_image.c new file mode 100644 index 000..51f16f2 --- /dev/null +++ b/mmc_spl/board/samsung/origen/tools/mkv310_image.c @@ -0,0 +1,139 @@ +/* + * Copyright (C) 2011 Samsung Electronics + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include stdio.h +#include stdlib.h +#include unistd.h +#include fcntl.h +#include errno.h +#include string.h please apply Dirk Behme's patch here. http://patchwork.ozlabs.org/patch/104270/ done + +#define BUFSIZE (16*1024) +#define IMG_SIZE (16*1024) +#define HEADER_SIZE 16 +#define FILE_PERM (S_IRUSR | S_IWUSR | S_IRGRP \ + | S_IWGRP | S_IROTH | S_IWOTH) +/* +* Requirement: +* IROM code reads first 14K bytes from boot device. +* It then calculates the checksum of 14K-4 bytes and compare with data at +* 14K-4 offset. +* +* This function takes two filenames: +* IN u-boot-spl.bin and +* OUT u-boot-mmc-spl.bin as filenames. +* It reads the u-boot-spl.bin in 16K buffer. +* It calculates checksum of 14K-4 Bytes and stores at 14K-4 offset in buffer. +* It writes the buffer to u-boot-mmc-spl.bin file. +*/ + Thanks Minkyu Kang -- from. prom. www.promsoft.net -- with warm regards, Chander Kashyap ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] General gpio interface?
Hi List, am I right that there is no standard gpio interface in u-boot or did I miss it? Regards Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/2] ORIGEN Board Support
Adds support for ORIGEN board with MMC Booting. Chander Kashyap (2): ARMV7: Add support for Samsung ORIGEN board ORIGEN: Add MMC SPL support MAINTAINERS |1 + board/samsung/origen/Makefile | 46 ++ board/samsung/origen/lowlevel_init.S | 468 + board/samsung/origen/mem_setup.S | 392 + board/samsung/origen/origen.c | 103 + boards.cfg|1 + include/configs/origen.h | 167 mmc_spl/board/samsung/origen/Makefile | 105 + mmc_spl/board/samsung/origen/mmc_boot.c | 75 mmc_spl/board/samsung/origen/tools/mkv310_image.c | 140 ++ mmc_spl/board/samsung/origen/u-boot.lds | 86 11 files changed, 1584 insertions(+), 0 deletions(-) create mode 100644 board/samsung/origen/Makefile create mode 100644 board/samsung/origen/lowlevel_init.S create mode 100644 board/samsung/origen/mem_setup.S create mode 100644 board/samsung/origen/origen.c create mode 100644 include/configs/origen.h create mode 100644 mmc_spl/board/samsung/origen/Makefile create mode 100644 mmc_spl/board/samsung/origen/mmc_boot.c create mode 100644 mmc_spl/board/samsung/origen/tools/mkv310_image.c create mode 100644 mmc_spl/board/samsung/origen/u-boot.lds -- 1.7.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] ARMV7: Add support for Samsung ORIGEN board
Origen board is based upon S5PV310 SoC which is similiar to
S5PC210 SoC.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
MAINTAINERS |1 +
board/samsung/origen/Makefile| 46
board/samsung/origen/lowlevel_init.S | 468 ++
board/samsung/origen/mem_setup.S | 392
board/samsung/origen/origen.c| 103
boards.cfg |1 +
include/configs/origen.h | 167
7 files changed, 1178 insertions(+), 0 deletions(-)
create mode 100644 board/samsung/origen/Makefile
create mode 100644 board/samsung/origen/lowlevel_init.S
create mode 100644 board/samsung/origen/mem_setup.S
create mode 100644 board/samsung/origen/origen.c
create mode 100644 include/configs/origen.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 2bba7b4..bb98115 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -704,6 +704,7 @@ Minkyu Kang mk7.k...@samsung.com
Chander Kashyap k.chan...@samsung.com
SMDKV310ARM ARMV7 (S5PC210 SoC)
+ origen ARM ARMV7 (S5PC210 SoC)
Frederik Kriewitz frede...@kriewitz.eu
diff --git a/board/samsung/origen/Makefile b/board/samsung/origen/Makefile
new file mode 100644
index 000..65eff91
--- /dev/null
+++ b/board/samsung/origen/Makefile
@@ -0,0 +1,46 @@
+#
+# Copyright (C) 2011 Samsung Electronics
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+SOBJS := mem_setup.o
+SOBJS += lowlevel_init.o
+COBJS += origen.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS) $(SOBJS))
+
+all:$(obj).depend $(LIB)
+
+$(LIB):$(OBJS)
+ $(AR) $(ARFLAGS) $@ $(OBJS)
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/samsung/origen/lowlevel_init.S
b/board/samsung/origen/lowlevel_init.S
new file mode 100644
index 000..cbb3c45
--- /dev/null
+++ b/board/samsung/origen/lowlevel_init.S
@@ -0,0 +1,468 @@
+/*
+ * Lowlevel setup for ORIGEN board based on S5PV310
+ *
+ * Copyright (C) 2011 Samsung Electronics
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include config.h
+#include version.h
+#include asm/arch/cpu.h
+
+/*
+ * Register usages:
+ *
+ * r5 has zero always
+ * r7 has GPIO part1 base 0x1140
+ * r6 has GPIO part2 base 0x1100
+ */
+
+#define MEM_DLLl_ON
+
+_TEXT_BASE:
+ .word CONFIG_SYS_TEXT_BASE
+
+ .globl lowlevel_init
+lowlevel_init:
+ push{lr}
+
+ /* r5 has always zero */
+ mov r5, #0
+ ldr r7, =S5PC210_GPIO_PART1_BASE
+ ldr r6, =S5PC210_GPIO_PART2_BASE
+
+ /* check reset status */
+ ldr r0, =(S5PC210_POWER_BASE + 0x804) @ INFORM1
+ ldr r1, [r0]
+
+ /* AFTR wakeup reset */
+ ldr r2, =S5P_CHECK_DIDLE
+ cmp r1, r2
+ beq exit_wakeup
+
+ /* Sleep wakeup reset */
+ ldr r2, =S5P_CHECK_SLEEP
+ cmp r1, r2
+ beq wakeup_reset
+
+ /*
+* If U-boot is already running in ram, no need to relocate U-Boot.
+* Memory controller must be configured before relocating U-Boot
+* in ram.
+*/
+
[U-Boot] [PATCH v2 2/2] ORIGEN: Add MMC SPL support
Adds mmc boot support.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
Changes in v2:
Use sys/stat.h for file permission macros in tools/mkv310_image.c
mmc_spl/board/samsung/origen/Makefile | 105 +++
mmc_spl/board/samsung/origen/mmc_boot.c | 75 +++
mmc_spl/board/samsung/origen/tools/mkv310_image.c | 140 +
mmc_spl/board/samsung/origen/u-boot.lds | 86 +
4 files changed, 406 insertions(+), 0 deletions(-)
create mode 100644 mmc_spl/board/samsung/origen/Makefile
create mode 100644 mmc_spl/board/samsung/origen/mmc_boot.c
create mode 100644 mmc_spl/board/samsung/origen/tools/mkv310_image.c
create mode 100644 mmc_spl/board/samsung/origen/u-boot.lds
diff --git a/mmc_spl/board/samsung/origen/Makefile
b/mmc_spl/board/samsung/origen/Makefile
new file mode 100644
index 000..7b62684
--- /dev/null
+++ b/mmc_spl/board/samsung/origen/Makefile
@@ -0,0 +1,105 @@
+#
+# (C) Copyright 2006-2007
+# Stefan Roese, DENX Software Engineering, s...@denx.de.
+#
+# (C) Copyright 2008
+# Guennadi Liakhovetki, DENX Software Engineering, l...@denx.de
+#
+# (C) Copyright 2011
+# Chander Kashyap, Samsung Electronics, k.chan...@samsung.com
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+CONFIG_MMC_SPL = y
+
+include $(TOPDIR)/config.mk
+
+LDSCRIPT= $(TOPDIR)/mmc_spl/board/$(BOARDDIR)/u-boot.lds
+LDFLAGS= -Bstatic -T $(mmcobj)u-boot.lds -Ttext
$(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+AFLAGS += -DCONFIG_MMC_SPL
+CFLAGS += -DCONFIG_MMC_SPL
+CFLAGS += -DCONFIG_PRELOADER
+
+SOBJS = start.o mem_setup.o lowlevel_init.o
+COBJS = mmc_boot.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
+__OBJS := $(SOBJS) $(COBJS)
+LNDIR := $(OBJTREE)/mmc_spl/board/$(BOARDDIR)
+
+mmcobj := $(OBJTREE)/mmc_spl/
+
+
+MKV310_MMC_SPL_EXEC = mkv310_mmc_spl_exec
+MMC_SPL_BIN = u-boot-mmc-spl.bin
+
+ALL = $(mmcobj)u-boot-spl $(mmcobj)u-boot-spl.bin $(mmcobj)$(MMC_SPL_BIN)
+
+all:$(obj).depend $(ALL)
+
+$(mmcobj)$(MMC_SPL_BIN): $(mmcobj)u-boot-spl.bin tools/$(MKV310_MMC_SPL_EXEC)
+ ./tools/$(MKV310_MMC_SPL_EXEC) $(mmcobj)u-boot-spl.bin
$(mmcobj)$(MMC_SPL_BIN)
+ rm -f tools/$(MKV310_MMC_SPL_EXEC)
+
+tools/$(MKV310_MMC_SPL_EXEC): tools/mkv310_image.c
+ $(HOSTCC) tools/mkv310_image.c -o tools/$(MKV310_MMC_SPL_EXEC)
+
+$(mmcobj)u-boot-spl.bin: $(mmcobj)u-boot-spl
+ $(OBJCOPY) ${OBJCFLAGS} -O binary $ $@
+
+$(mmcobj)u-boot-spl: $(OBJS) $(mmcobj)u-boot.lds
+ cd $(LNDIR) $(LD) $(LDFLAGS) $(__OBJS) \
+ -Map $(mmcobj)u-boot-spl.map \
+ -o $(mmcobj)u-boot-spl
+
+$(mmcobj)u-boot.lds: $(LDSCRIPT)
+ $(CPP) $(CPPFLAGS) $(LDPPFLAGS) -ansi -D__ASSEMBLY__ -P - $^ $@
+
+# create symbolic links for common files
+
+# from cpu directory
+start.S:
+ @rm -f $@
+ @ln -s $(TOPDIR)/arch/arm/cpu/armv7/start.S $@
+
+# from board directory
+mem_setup.S:
+ @rm -f $@
+ @ln -s $(TOPDIR)/board/samsung/origen/mem_setup.S $@
+
+lowlevel_init.S:
+ @rm -f $@
+ @ln -s $(TOPDIR)/board/samsung/origen/lowlevel_init.S $@
+
+#
+
+$(obj)%.o: %.S
+ $(CC) $(AFLAGS) -c -o $@ $
+
+$(obj)%.o: %.c
+ $(CC) $(CFLAGS) -c -o $@ $
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/mmc_spl/board/samsung/origen/mmc_boot.c
b/mmc_spl/board/samsung/origen/mmc_boot.c
new file mode 100644
index 000..459d27d
--- /dev/null
+++ b/mmc_spl/board/samsung/origen/mmc_boot.c
@@ -0,0 +1,75 @@
+/*
+ * Copyright (C) 2011 Samsung Electronics
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even
Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
Dear Graeme, I'm trying to summarize your last 3 postings here. In message 4e1b7e0c.8000...@gmail.com you wrote: First, I would very much like to get rid of this _ms thing. We should rather make very clear in the documentation which unit the time services are based on, and use this consequently. Only functions using a different unit should make this clean in their names. Ideally, I think this should be microseconds (a lot happens in a microsecond on modern platforms, and a millisecond can be an eternity) Then we might as well follow the example of the Linux generic TOD framework and use nanoseconds instead - we will need u64 data types anyway when going for microseconds, so we can just follow their example. Third: all this time_*_max(), ..._min() and ...raw() stuff. Aren't we over-engineering here? We have been successfully writing U-Boot code for 11 years now, and never needed these before. Neither does Linux Part of the problem came from the realisation that some architectures have really bad timer resolution (Nios2 in particular). In an ideal world, I think a uniform microsecond timer (millisecond is to coarse to cater for all needs such as udelay and profiling) would be sufficient to not need these functions but while ever we have platforms with 'poor' timers, I think you may find these functions have a place. No, I disagree here. We should not clutter up generic code with things that are only needed for a single (unusually restricted) architecture. Instead, we should try to come up with a design that hides such details in architecture specific code. As stated - This started from a suggestion made by yourself (albeit one you did not think was apparently necessary). The idea of the separate functions (rather than a parameter to a single function) was that if the functions were not used, they would be optimised out. You know how things go: if you offer the users a set of 20 functions so they can chose the one or two that fit their purposes best, they will end up with using all 20 of them, especially when diffferent parts of the code get maintained by different people with different preferences. Approaches like that always get out of hand quickly. We don't have any such stuff now, and U-Boot is working fine. Let's keep it with that, or make it even more simple. But not the other way. What would you like me to do with the clean-up patches that you have already ack'd which do not relate directly to the new API? Should I mark the current series as Rejected in patchwork and create a brand new smaller series which only has those specific patches? I suggest you create a new patch series from the independent clean-up patches and submit this as normal patches (i. e. without the WIP / RFC part). This would already be a great improvement, I think. Thanks a lot for the efforts! In message 4e1b88ee.9040...@gmail.com you wrote: - Looking at the low-level framework described in ols2006-hrtimers.pdf (Linux API), we are looking at implementing the same thing - An architecture specific free running, high speed, high resolution, high accuracy hardware counter/timer and a low speed interrupt which translates the hardware counter/timer to a common API. In this respect, we are not re-inventing that wheel at all Indeed. We should also avoid re-inventing the algorithms, and eventually re-implementing the code. In any case, I think it would be great to use a compatible API so we don;t have to change too many things when adapting code from Linux etc. - The rest of the Linux API is like hitting a thumb-tack with a sledgehammer - Timer Queues, NTP, Callbacks, Scheduling etc, etc, etc. We only want to do two things: Right. Linux is a full-blown OS with a lot of needs we don't have in U-Boot. 1. Monitor timeouts 2. Calculate code execution time (and even then, not everyone all the time) Actrually we need just timestamps. All the rest (like delays, timeouts, executin times etc.) can be derived from that. - The Linux API is nanosecond resolution. We are hard pressed to get the average hardware to support microsecond resolution On the other hand, it makes little difference to the code wether we use microseconds or nanoseconds. It's just slightly different values in the u64 variables. - The Linux API includes usage of 'clock events' - These are timer interrupts driven by programmable hardware and relieve the stress on the timer scheduler keeping track of every single timer - Overkill for a boot loader Agreed. Well, partially. We should still follow the example of keeping the generic code clean of architecture / timer specific code. This should be implemented in the respective arechitecture specific code. - The Linux API includes 'Time of Day' (Wall Time) - Again, I don't think we really need this in a boot loader (we have an RTC API we can use if we want to get the current Date and Time). We could also say this is all we
Re: [U-Boot] [PATCH 1/2] net/eth.c: make eth_get_dev_by_name(NULL) safe
Hi Mike, On Monday, July 11, 2011 05:53:49 Helmut Raiger wrote: On 07/07/2011 07:46 PM, Mike Frysinger wrote: those NULL checks should not be necessary either. a correctly written networking driver should only register itself with the miiphy layer when it has successfully registered itself with the eth layer. thus any of the miiphy callbacks should always come in with a name that is found via eth_get_dev_by_name(). You are right, in a perfect world nobody ever falters. you missed the point. either the driver works, or it doesnt. this func is used in such a way that the behavior is fairly deterministic (as i clearly laid out). it isnt relying on allocated memory that could fall to be allocated for example. I for myself am also thinking of code that will be written in the future, i.e. probably new uses of eth_get_dev_by_name. Saving time in this development because errors are caught early is a good thing IMHO. checking for NULLs here and gracefully returning is unnecessary overhead imo as you're only catering to broken code. fix the broken drivers instead. I could not find drivers that have the potential of delivering NULLs to the miiphy_read and write functions, I simply refused to test at this level. Either there is a potential of having NULL passed then the test should be in eth_get_dev_by_name() or there is none then we should simply leave it away. i did go through the level of detail and showed the call graphs ... none of which should allow a driver tested as working to even once hit the NULL path. As I said, these are tha call graphs currently existing... I'm rather indifferent to either solution. And about 'catering to broken code': It must be broken in 2 ways, first it must pass a NULL to the function and second it must ignore the return code. not necessarily. many platforms will abort on NULL pointer accesses. by your logic, why put the NULL check in eth_get_dev_by_name() ? why not handle strcmp(NULL, NULL) too ? then eth_get_dev_by_name() would automatically get fixed as would all other call points. For strcmp() you have several issues at hand: Compatibility, performance and even a logical problem. What should be the result in case one of the arguments is NULL (or both). fair enough on the API, but your performance aspect is kind of hard to swallow when you turn around and say that NULL pointer checking elsewhere is minuscule. And finally we are discussing a few _chararacters_ of code and a probably a single assembly instruction. it's not a single assembly insn. try generating it. it adds like 8 to my platform, mostly because of the increased register pressure. On PowerPC with ELDK 4.2 this is the difference: before: 0004 g F .text.eth_get_dev_by_name 0080 eth_get_dev_by_name after: 0004 g F .text.eth_get_dev_by_name 0084 eth_get_dev_by_name So at least for this arch it is indeed one word difference. but the point isnt the impact of this single check. it sets the precedence that every function in u-boot that takes a pointer should start over protecting itself against poorly written code originating elsewhere. now your few characters is quite a bit more. I still stand by what I said that if we have functions that can be called from many places (i.e. library-like), then the functions should be conservative in what they expect. Tightly coupled code can be looser in this respect. Maybe our disagreement stems from the fact that you consider this function to be tightly coupled and not really library like? what i wouldnt mind is annotating the prototype with gcc attributes saying that the argument is nonnull. ... #define __nonnull(x) __attribute__((__nonnull__ x)) ... extern struct eth_device *eth_get_dev_by_name(const char *devname) __nonnull(1); ... This can only catch calls the compiler can statically derive, but still I think it is a good thing. Cheers Detlev -- Don't trust everything you read, and don't assume every poster in a thread is actually relevant to the problem. -- Stefan Monnier jwvlj1gk44h.fsf-monnier+em...@gnu.org -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AT91:mmc:fix multiple read/write error
According to datasheet,set block count before multiple read/write.
Signed-off-by: elen.song elen.s...@atmel.com
---
drivers/mmc/atmel_mci.h |9 -
drivers/mmc/gen_atmel_mci.c |4
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/atmel_mci.h b/drivers/mmc/atmel_mci.h
index 90ab6a8..3095d22 100644
--- a/drivers/mmc/atmel_mci.h
+++ b/drivers/mmc/atmel_mci.h
@@ -36,7 +36,7 @@ typedef struct atmel_mci {
u32 sdcr; /* 0x0c */
u32 argr; /* 0x10 */
u32 cmdr; /* 0x14 */
- u32 _18;/* 0x18 */
+ u32 blkr; /* 0x18 */
u32 _1c;/* 0x1c */
u32 rspr; /* 0x20 */
u32 rspr1; /* 0x24 */
@@ -67,6 +67,7 @@ typedef struct atmel_mci {
#define MMCI_SDCR 0x000c
#define MMCI_ARGR 0x0010
#define MMCI_CMDR 0x0014
+#define MMCI_BLKR 0x0018
#define MMCI_RSPR 0x0020
#define MMCI_RSPR1 0x0024
#define MMCI_RSPR2 0x0028
@@ -140,6 +141,12 @@ typedef struct atmel_mci {
#define MMCI_TRTYP_OFFSET 19
#define MMCI_TRTYP_SIZE2
+/* Bitfields in BLKR */
+#define MMCI_BCNT_OFFSET 0
+#define MMCI_BCNT_SIZE 16
+#define MMCI_BLKLEN_OFFSET 16
+#define MMCI_BLKLEN_SIZE 16
+
/* Bitfields in RSPRx */
#define MMCI_RSP_OFFSET0
#define MMCI_RSP_SIZE 32
diff --git a/drivers/mmc/gen_atmel_mci.c b/drivers/mmc/gen_atmel_mci.c
index f346b24..d217574 100644
--- a/drivers/mmc/gen_atmel_mci.c
+++ b/drivers/mmc/gen_atmel_mci.c
@@ -183,6 +183,10 @@ mci_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd, struct
mmc_data *data)
/* Figure out the transfer arguments */
cmdr = mci_encode_cmd(cmd, data, error_flags);
+ if (data)
+ writel(MMCI_BF(BCNT, data-blocks) |
+ MMCI_BF(BLKLEN, mmc-read_bl_len), mci-blkr);
+
/* Send the command */
writel(cmd-cmdarg, mci-argr);
writel(cmdr, mci-cmdr);
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
Hi Wolfgang, Thanks for the renewed feedback On 12/07/11 18:49, Wolfgang Denk wrote: Dear Graeme, I'm trying to summarize your last 3 postings here. In message 4e1b7e0c.8000...@gmail.com you wrote: First, I would very much like to get rid of this _ms thing. We should rather make very clear in the documentation which unit the time services are based on, and use this consequently. Only functions using a different unit should make this clean in their names. Ideally, I think this should be microseconds (a lot happens in a microsecond on modern platforms, and a millisecond can be an eternity) Then we might as well follow the example of the Linux generic TOD framework and use nanoseconds instead - we will need u64 data types anyway when going for microseconds, so we can just follow their example. Yes, I like the idea of using nanoseconds as a raw timebase Third: all this time_*_max(), ..._min() and ...raw() stuff. Aren't we over-engineering here? We have been successfully writing U-Boot code for 11 years now, and never needed these before. Neither does Linux Part of the problem came from the realisation that some architectures have really bad timer resolution (Nios2 in particular). In an ideal world, I think a uniform microsecond timer (millisecond is to coarse to cater for all needs such as udelay and profiling) would be sufficient to not need these functions but while ever we have platforms with 'poor' timers, I think you may find these functions have a place. No, I disagree here. We should not clutter up generic code with things that are only needed for a single (unusually restricted) architecture. Instead, we should try to come up with a design that hides such details in architecture specific code. So how do we deal with Nios2? It is what caused such a deep investigation into the timer API. We have three choices I can think of off the top of my head: 1. Move the whole timer API up to the architecture level and replicate code everywhere 2. Make the whole timer API weak 3. Fundamentally allow the timer API to handle arbitrary timer resolutions 1. Way ugly. We already have this, and that is why we are here today 2. Well, you know what will happen - Someone will be unhappy with the generic API and rewrite a completely different one (timer_masked anyone!) 3. Why is this so evil? I'm open to other options if you have any As stated - This started from a suggestion made by yourself (albeit one you did not think was apparently necessary). The idea of the separate functions (rather than a parameter to a single function) was that if the functions were not used, they would be optimised out. You know how things go: if you offer the users a set of 20 functions so they can chose the one or two that fit their purposes best, they will end up with using all 20 of them, especially when diffferent parts of the code get maintained by different people with different preferences. Approaches like that always get out of hand quickly. We don't have any such stuff now, and U-Boot is working fine. Let's keep it with that, or make it even more simple. But not the other way. Realistically we are looking at the following functionality: 1) Get the current time 2) Report the minimum time elapsed since an arbitrary epoch 3) Report the maximum time elapsed since an arbitrary epoch 4) Delay for an arbitrary period of time 4 is a derivative of 2 - Just loop until at least the required time has elapsed. And you then suggest bringing in no less than 6 functions from Linux What would you like me to do with the clean-up patches that you have already ack'd which do not relate directly to the new API? Should I mark the current series as Rejected in patchwork and create a brand new smaller series which only has those specific patches? I suggest you create a new patch series from the independent clean-up patches and submit this as normal patches (i. e. without the WIP / RFC part). This would already be a great improvement, I think. Thanks a lot for the efforts! Done - I will reject the current series and rebase/repost the patches you have already ack'd and assign them to you in patchwork - I'll leave it up to you to pull them in In message 4e1b88ee.9040...@gmail.com you wrote: - Looking at the low-level framework described in ols2006-hrtimers.pdf (Linux API), we are looking at implementing the same thing - An architecture specific free running, high speed, high resolution, high accuracy hardware counter/timer and a low speed interrupt which translates the hardware counter/timer to a common API. In this respect, we are not re-inventing that wheel at all Indeed. We should also avoid re-inventing the algorithms, and eventually re-implementing the code. In any case, I think it would be great to use a compatible API so we don;t have to change too many things when adapting code from Linux etc. OK, I'll spend some time digging into the Linux
[U-Boot] [PATCH] net/4xx: Install interrupt handler after driver registration
Only install der 4xx-EMAC interrupt handlers *after* the core
network driver is registered.
This problem was noticed on the APM Taishan 440GX board, where
the board hung upon bootup after displaying Net:.
Signed-off-by: Stefan Roese s...@denx.de
---
drivers/net/4xx_enet.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/4xx_enet.c b/drivers/net/4xx_enet.c
index b1763b1..f328574 100644
--- a/drivers/net/4xx_enet.c
+++ b/drivers/net/4xx_enet.c
@@ -2035,6 +2035,13 @@ int ppc_4xx_eth_initialize (bd_t * bis)
dev-send = ppc_4xx_eth_send;
dev-recv = ppc_4xx_eth_rx;
+ eth_register(dev);
+
+#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
+ miiphy_register(dev-name,
+ emac4xx_miiphy_read, emac4xx_miiphy_write);
+#endif
+
if (0 == virgin) {
/* set the MAL IER ??? names may change with new spec
??? */
#if defined(CONFIG_440SPE) || \
@@ -2072,13 +2079,6 @@ int ppc_4xx_eth_initialize (bd_t * bis)
dev);
virgin = 1;
}
-
- eth_register (dev);
-
-#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
- miiphy_register (dev-name,
-emac4xx_miiphy_read, emac4xx_miiphy_write);
-#endif
} /* end for each supported device */
return 0;
--
1.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] integratorap: support relocation
The integrator board was apparently never converted over to support
relocation until now. After this the integrator u-boot both compiles
and boots on the Integrator AP.
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
board/armltd/integrator/integrator.c | 14 --
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/board/armltd/integrator/integrator.c
b/board/armltd/integrator/integrator.c
index 9bb56b5..a0d8de7 100644
--- a/board/armltd/integrator/integrator.c
+++ b/board/armltd/integrator/integrator.c
@@ -86,14 +86,16 @@ int misc_init_r (void)
return (0);
}
-/**
- Routine:
- Description:
-**/
-int dram_init (void)
+void dram_init_banksize(void)
{
gd-bd-bi_dram[0].start = PHYS_SDRAM_1;
- gd-bd-bi_dram[0].size = PHYS_SDRAM_1_SIZE;
+gd-bd-bi_dram[0].size = PHYS_SDRAM_1_SIZE;
+}
+
+int dram_init (void)
+{
+ gd-ram_size = get_ram_size((long *)CONFIG_SYS_SDRAM_BASE,
+ PHYS_SDRAM_1_SIZE);
#ifdef CONFIG_CM_SPD_DETECT
{
--
1.7.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] integrator: support the hush shell
Give us some kind of sane shell environment so the bootloader can be used. Signed-off-by: Linus Walleij linus.wall...@linaro.org --- include/configs/integratorap.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/configs/integratorap.h b/include/configs/integratorap.h index 8b41885..ea6af78 100644 --- a/include/configs/integratorap.h +++ b/include/configs/integratorap.h @@ -94,7 +94,9 @@ * Miscellaneous configurable options */ #define CONFIG_SYS_LONGHELP/* undef to save memory */ +#define CONFIG_SYS_HUSH_PARSER #define CONFIG_SYS_PROMPT Integrator-AP # /* Monitor Command Prompt */ +#define CONFIG_SYS_PROMPT_HUSH_PS2 # #define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */ /* Print Buffer Size */ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE+sizeof(CONFIG_SYS_PROMPT)+16) -- 1.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] integrator: support some rudimentary commands
This adds support for a subset of the default commands for the Integrator, however since the card does not have Ethernet (unless you plug in a PCI card) we can not use the default command set. Signed-off-by: Linus Walleij linus.wall...@linaro.org --- include/configs/integratorap.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/configs/integratorap.h b/include/configs/integratorap.h index ea6af78..26eac8b 100644 --- a/include/configs/integratorap.h +++ b/include/configs/integratorap.h @@ -81,9 +81,15 @@ * Command line configuration. */ + #define CONFIG_CMD_IMI #define CONFIG_CMD_BDI +#define CONFIG_CMD_BOOTD #define CONFIG_CMD_MEMORY +#define CONFIG_CMD_FLASH +#define CONFIG_CMD_IMLS +#define CONFIG_CMD_LOADB +#define CONFIG_CMD_LOADS #define CONFIG_BOOTDELAY 2 -- 1.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] integratorap: make the compile work again
The integratorap/cp config for u-boot was outdated and would not even compile, so fix the obvious missing bits for it to start building. After this make ap920t_config/make all starts working again. Signed-off-by: Linus Walleij linus.wall...@linaro.org --- board/armltd/integrator/lowlevel_init.S |2 +- include/configs/integratorap.h |6 ++ 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/board/armltd/integrator/lowlevel_init.S b/board/armltd/integrator/lowlevel_init.S index ab9589c..6f55bb5 100644 --- a/board/armltd/integrator/lowlevel_init.S +++ b/board/armltd/integrator/lowlevel_init.S @@ -199,7 +199,7 @@ cm_remap: /* Now 0x is writeable, replace the vectors */ ldr r0, =_start /* r0 - start of vectors */ - ldr r2, =_armboot_start /* r2 - past vectors */ + ldr r2, =_TEXT_BASE /* r2 - past vectors */ sub r1,r1,r1/* destination 0x */ copy_vec: diff --git a/include/configs/integratorap.h b/include/configs/integratorap.h index 32ff193..8b41885 100644 --- a/include/configs/integratorap.h +++ b/include/configs/integratorap.h @@ -120,6 +120,12 @@ #define CONFIG_NR_DRAM_BANKS 1 /* we have 1 bank of DRAM */ #define PHYS_SDRAM_1 0x /* SDRAM Bank #1 */ #define PHYS_SDRAM_1_SIZE 0x0200 /* 32 MB */ +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_RAM_SIZE PHYS_SDRAM_1_SIZE +#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_SDRAM_BASE + \ + CONFIG_SYS_INIT_RAM_SIZE - \ + GENERATED_GBL_DATA_SIZE) +#define CONFIG_SYS_INIT_SP_ADDR CONFIG_SYS_GBL_DATA_OFFSET #define CONFIG_SYS_FLASH_BASE 0x2400 -- 1.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] tools: build some commands without -pedantic
On this GCC in Fedora (4.6.0 20110530) the tools gen_eth_addr and img2srec become size zero if compiled with -pedantic (no warnings are emitted however). Marking them _NOPED solves the issue for me. Signed-off-by: Linus Walleij linus.wall...@linaro.org --- tools/Makefile |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index 97f83f8..cc7bc69 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -83,8 +83,8 @@ OBJ_FILES-$(CONFIG_VIDEO_LOGO) += bmp_logo.o NOPED_OBJ_FILES-y += default_image.o OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += envcrc.o NOPED_OBJ_FILES-y += fit_image.o -OBJ_FILES-$(CONFIG_CMD_NET) += gen_eth_addr.o -OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o +NOPED_OBJ_FILES-$(CONFIG_CMD_NET) += gen_eth_addr.o +NOPED_OBJ_FILES-$(CONFIG_CMD_LOADS) += img2srec.o OBJ_FILES-$(CONFIG_INCA_IP) += inca-swap-bytes.o NOPED_OBJ_FILES-y += kwbimage.o NOPED_OBJ_FILES-y += imximage.o @@ -168,7 +168,7 @@ $(obj)envcrc$(SFX): $(obj)crc32.o $(obj)env_embedded.o $(obj)envcrc.o $(obj)sha1 $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^ $(obj)gen_eth_addr$(SFX): $(obj)gen_eth_addr.o - $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^ + $(HOSTCC) $(HOSTCFLAGS_NOPED) $(HOSTLDFLAGS) -o $@ $^ $(HOSTSTRIP) $@ $(obj)img2srec$(SFX): $(obj)img2srec.o -- 1.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: build some commands without -pedantic
Dear Linus Walleij, In message 1310469889-12999-1-git-send-email-linus.wall...@linaro.org you wrote: On this GCC in Fedora (4.6.0 20110530) the tools gen_eth_addr and img2srec become size zero if compiled with -pedantic (no warnings are emitted however). Marking them _NOPED solves the issue for me. Signed-off-by: Linus Walleij linus.wall...@linaro.org --- tools/Makefile |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) NAK. I hate papering over obvious problems. Please let's analyze what's going wrong, and fix the cause instead. This is all the more so, as I'm running Fedora 15 here on our machines [with gcc version 4.6.0 20110530 (Red Hat 4.6.0-9) (GCC)], and I don;t see any such problems. 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 Writing a book is like washing an elephant: there's no good place to begin or end, and it's hard to keep track of what you've already covered. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Setup NS16550 specific parameters from platform code
Hi, For our upcoming SOC, we have a situation where in we need to configure UART console at runtime. Our SOC makes use of NS16550. I looked through the u-boot tree found several references for doing the same. hebbar@linux- server:~/projects/u-boot-git$ gr NS16550_init * board/sheldon/simpc8313/simpc8313.c:145: NS16550_init((NS16550_t)(CONFIG_SYS_IMMR + 0x4500), board/ml2/serial.c:45: (void) NS16550_init (COM_PORTS[0], clock_divisor); board/ml2/serial.c:48: (void) NS16550_init (COM_PORTS[1], clock_divisor); board/MAI/AmigaOneG3SE/serial.c:157:NS16550_init (Com0, clock_divisor); board/MAI/AmigaOneG3SE/serial.c:244:NS16550_init (Com0, clock_divisor); board/freescale/mpc8313erdb/mpc8313erdb.c:138: NS16550_init((NS16550_t)(CONFIG_SYS_IMMR + 0x4500), board/freescale/mpc8315erdb/mpc8315erdb.c:239: NS16550_init((NS16550_t)(CONFIG_SYS_IMMR + 0x4500), board/bmw/serial.c:45: NS16550_init (CONFIG_CONS_INDEX - 1, clock_divisor); board/bmw/ns16550.c:16:volatile struct NS16550 *NS16550_init (int chan, int baud_divisor) board/mvblue/mvblue.c:45: NS16550_init (console, clock_divisor); board/Marvell/common/serial.c:101: (void) NS16550_init (0, clock_divisor); board/Marvell/common/serial.c:104: (void) NS16550_init (1, clock_divisor); board/Marvell/common/ns16550.c:20:volatile struct NS16550 *NS16550_init (int chan, int baud_divisor) board/Marvell/common/ns16550.h:92:volatile struct NS16550 * NS16550_init(int chan, int baud_divisor); board/amirix/ap1000/serial.c:43:(void) NS16550_init (COM_PORTS[0], clock_divisor); board/evb64260/serial.c:103:(void)NS16550_init(COM_PORTS[0], clock_divisor); board/evb64260/serial.c:106:(void)NS16550_init(COM_PORTS[1], clock_divisor); I would like to know whether this approach is correct and whether this approach is still allowed in current u-boot. If not, what is the correct approach? I am also looking at CONFIG_SERIAL_MULTI. Thanks in advance. Regards Gururaja ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
Dear Graeme Russ, In message 4e1c23b8.6020...@gmail.com you wrote: So how do we deal with Nios2? It is what caused such a deep investigation into the timer API. We have three choices I can think of off the top of my head: 1. Move the whole timer API up to the architecture level and replicate code everywhere 2. Make the whole timer API weak 3. Fundamentally allow the timer API to handle arbitrary timer resolutions 1. Way ugly. We already have this, and that is why we are here today 2. Well, you know what will happen - Someone will be unhappy with the generic API and rewrite a completely different one (timer_masked anyone!) 3. Why is this so evil? The big disadvantage of 3) is that you cannot make any reasonable assumptions any more in the code. If I place a udelay(10) in some device driver, I am probably aware that we don't have exact times, and that the actual delay may be 10 or 12 or eventually even 20 micro- seconds. We should make sure that the delay never takes less than 10 us, but we also have to guarantee that it does not take - for example - 10 milliseconds. What exactly is the reason that we cannot have better timer resolutions in NIOS? I'm anything but a NIOS export, but skimming through the Altera Embedded Peripherals IP User Guide, section 28. Interval Timer Core I see that we can have 32-bit and 64-bit counters, Two count modes: count down once and continuous count-down, and the example in section Configuration: Timeout Period on p. 28-3 reads: For example, if the associated system clock has a frequency of 30 ns, and the specified Timeout Period value is 1 µs, the true timeout period will be 1.020 microseconds. Well, if I understand this correctly, we can have a continuously running 64 bit counter with microsecond resolution. There are other sections that describe configurations that might probably be used as well, for example in HAL System Library Support: Timestamp Driver The interval timer core may be used as a timestamp device ... Also, the Nios II Software Developer's Handbook says in Chapter 6: Developing Programs Using the Hardware Abstraction Layer - Using Timer Devices on o. 6-16: The HAL API provides two types of timer device drivers: - System clock driver--Supports alarms, such as you would use in a scheduler. - Timestamp driver--Supports high-resolution time measurement. ... You can obtain the rate at which the timestamp counter increments by calling the function alt_timestamp_freq(). This rate is typically the hardware frequency of the Nios II processor system--usually millions of cycles per second. The timestamp drivers are defined in the alt_timestamp.h header file. High-resolution time measurement? Isn't this what we are looking for? Or am I missing something? Scott, maybe you can comment here? I'm open to other options if you have any At the moment I'm trying to understand if we really have a problem on NIOS2 that cannot be fixed in a way that is compatible with our current plans. 1) Get the current time Agreed. That's time(). 2) Report the minimum time elapsed since an arbitrary epoch 3) Report the maximum time elapsed since an arbitrary epoch I don't understand why we would need this. 4) Delay for an arbitrary period of time 4 is a derivative of 2 - Just loop until at least the required time has elapsed. Right. Both delays and timeouts work like that, the difference being that delays are blocking, i. e. there is no other code running inbetween, and you can just sit in a tight spinning loop. I have not seen any requirement yet for 3. And you then suggest bringing in no less than 6 functions from Linux It's just macros. And we don't need to use them all. Actually time_after() is all that's needed to satisfy our current usage. Done - I will reject the current series and rebase/repost the patches you have already ack'd and assign them to you in patchwork - I'll leave it up to you to pull them in Don't reject them - just mark them as RFC. Provided you have access to an incrementing value which increments at a fixed rate and you know the rate, the rest is architecture independent We also have to deal with decrementing counters, but this is just aan unimportant detail. And it appears that we actually can have this, even on NIOS. We could also say this is all we need. If we have a working high precision TOD timestamp, we can derive all other things we need from that. So you want to look at bringing in the Linux TOD API as well? That means we No, I don't. See my previous comments. And the longer I think about it, the more I think we should just use u64 time(void) as core of this new code. Agreed - As said before (for the time being) the return value of any arbitrary call to time() means nothing. It _may_ mean the number of nanoseconds since
Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
On 7/12/2011 6:10 AM, Wolfgang Denk wrote: Dear Graeme Russ, snip Do we? What exactly is the needed resolution of the underlying hardware timer? So far, it appears sufficient to have it ticking with 1000 Hz or more. Are there really systems that cannot provide that? The only architecture I remember that seemed prolematic was NIOS - but then the NIOS documentation suggests that this might actually be Hi All, The NIOS2 systems are a FPGA based architecture (soft core). They CAN have all different kinds of timers. However, there are many already out in the world that were built (generated) with a timer that has 10 ms resolution. We can't retro-actively change these. We can declare them not supported in future releases, but we can't fix the resolution problem retroactively. I have two comments regarding this discussion so far. First, I think using the time function name at all is a VERY BAD idea. People will confuse it with the normal c library function that returns the time of day since the epoch. One may say that they should RTFM, but it is lots easier to just use another name and avoid all such confusion. Second, I think forcing all systems to use 64 bit time stamps is not a good idea. The main purpose of the timer API is to provide hardware timeouts. 64 bits is vast overkill for such a purpose. Mandating 64 bit capability for all u-boots is I think counter-productive. A 32 bit timestamp in millisecond resolution plus udelay covers all practical cases. The 1 ms resolution is probably inadequate for performance measurement, but for every u-boot system that is sometimes used for performance measurement, there are 100 (probably even more, like 1000, but I don't really have the figures) systems that are just used to boot Linux or another stand alone program. So we may need a different API for performance measurement that uses higher resolution. On most larger CPUs, there are hardware timers that can already do this with minimal work. On some less-capable CPUs, it may be lots harder, but if you aren't doing performance measurement, you don't need it. So I suggest that mandating a 64 bit API for some of the processors (68K comes to mind) is not really a good idea. It seems counter to the elegant simplicity of the rest of u-boot to stick a 64 bit requirement on timestamps used to determine if the boot delay is expired. Best Regards, J. William Campbell 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 5/5] USB: Set portnr so USB1.1 and 1.0 devices work on EHCI controllers
Hello. Marek Vasut wrote: Signed-off-by: Marek Vasut marek.va...@gmail.com Hm... but EHCI controllers only support high speed (USB 2.0) devices... You need a companion controller (UHCI/OHCI) to support the full/low speed devices. WBR, Sergei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] USB: Set portnr so USB1.1 and 1.0 devices work on EHCI controllers
On Tuesday, July 12, 2011 04:56:23 PM Sergei Shtylyov wrote: Hello. Marek Vasut wrote: Signed-off-by: Marek Vasut marek.va...@gmail.com Hm... but EHCI controllers only support high speed (USB 2.0) devices... You need a companion controller (UHCI/OHCI) to support the full/low speed devices. Hi, I have the thing past a hub with TT. So it's not a problem. WBR, Sergei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: build some commands without -pedantic
On Tue, Jul 12, 2011 at 1:58 PM, Wolfgang Denk w...@denx.de wrote: Dear Linus Walleij, In message 1310469889-12999-1-git-send-email-linus.wall...@linaro.org you wrote: On this GCC in Fedora (4.6.0 20110530) the tools gen_eth_addr and img2srec become size zero if compiled with -pedantic (no warnings are emitted however). Marking them _NOPED solves the issue for me. Signed-off-by: Linus Walleij linus.wall...@linaro.org --- tools/Makefile | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) NAK. I hate papering over obvious problems. Please let's analyze what's going wrong, and fix the cause instead. Yes I'm reluctant about the whole thing, doesn't say from the patch it was indeed intended as a discussion item... This is all the more so, as I'm running Fedora 15 here on our machines [with gcc version 4.6.0 20110530 (Red Hat 4.6.0-9) (GCC)], and I don;t see any such problems. Hm! Then I must be doing something wrong... I do this, first I apply the patches I sent for Integrator support, then I apply this patch to test with network support: diff --git a/include/configs/integratorap.h b/include/configs/integratorap.h index 26eac8b..39c84b5 100644 --- a/include/configs/integratorap.h +++ b/include/configs/integratorap.h @@ -80,17 +80,7 @@ /* * Command line configuration. */ - - -#define CONFIG_CMD_IMI -#define CONFIG_CMD_BDI -#define CONFIG_CMD_BOOTD -#define CONFIG_CMD_MEMORY -#define CONFIG_CMD_FLASH -#define CONFIG_CMD_IMLS -#define CONFIG_CMD_LOADB -#define CONFIG_CMD_LOADS - +#include config_cmd_default.h #define CONFIG_BOOTDELAY 2 #define CONFIG_BOOTARGSroot=/dev/mtdblock0 mem=32M console=ttyAM0 console=tty @@ -155,11 +145,14 @@ * PCI definitions */ +#define CONFIG_PCI #ifdef CONFIG_PCI /* pci support */ #undef CONFIG_PCI_PNP #define CONFIG_PCI_SCAN_SHOW 1 /* show pci devices on startup */ #define DEBUG +#define CONFIG_NET_MULTI +#define CONFIG_TULIP #define CONFIG_EEPRO100 #define CONFIG_SYS_RX_ETH_BUFFER 8 /* use 8 rx buffer on eepro100 */ Then I build like this: cd u-boot mkdir build make O=build CROSS_COMPILE=arm-none-eabi- distclean make O=build CROSS_COMPILE=arm-none-eabi- ap920t_config make O=build CROSS_COMPILE=arm-none-eabi- all Then this happens on my side: make -C tools all make[1]: Entering directory `/home/linus/u-boot/tools' gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/linus/u-boot/include -idirafter /home/linus/u-boot/build/include2 -idirafter /home/linus/u-boot/build/include -I /home/linus/u-boot/lib/libfdt -I /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE=0x0100 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o /home/linus/u-boot/build/tools/gen_eth_addr.o gen_eth_addr.c -c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/linus/u-boot/include -idirafter /home/linus/u-boot/build/include2 -idirafter /home/linus/u-boot/build/include -I /home/linus/u-boot/lib/libfdt -I /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE=0x0100 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o /home/linus/u-boot/build/tools/gen_eth_addr /home/linus/u-boot/build/tools/gen_eth_addr.o /home/linus/u-boot/build/tools/gen_eth_addr.o: file not recognized: File truncated collect2: ld returned 1 exit status make[1]: *** [/home/linus/u-boot/build/tools/gen_eth_addr] Error 1 make[1]: Leaving directory `/home/linus/u-boot/tools' make: *** [tools] Error 2 Which is because: ls -al build/tools/gen_eth_addr.o -rw-rw-r--. 1 linus linus 0 Jul 12 17:16 build/tools/gen_eth_addr.o If I copy+paste the buildline and remove -pedantic like this: u-boot]$ cd tools gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/linus/u-boot/include -idirafter /home/linus/u-boot/build/include2 -idirafter /home/linus/u-boot/build/include -I /home/linus/u-boot/lib/libfdt -I /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE=0x0100 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -o /home/linus/u-boot/build/tools/gen_eth_addr.o gen_eth_addr.c -c cd .. ls -al build/tools/gen_eth_addr.o -rw-rw-r--. 1 linus linus 1380 Jul 12 17:21 build/tools/gen_eth_addr.o It's the same effect as if I tag on _NOPED of course. If I repeat it with -pedantic -v to see more what's happening in GCC: cd tools gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/linus/u-boot/include -idirafter /home/linus/u-boot/build/include2 -idirafter /home/linus/u-boot/build/include -I /home/linus/u-boot/lib/libfdt -I /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE=0x0100 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -v -o /home/linus/u-boot/build/tools/gen_eth_addr.o gen_eth_addr.c -c cd .. Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-redhat-linux/4.6.0/lto-wrapper Target: i686-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
Re: [U-Boot] [RESEND PATCH v2 1/5] Tegra2: Add macros to calculate bitfield shifts and masks
Hi Anton, Le 11/07/2011 18:19, Anton Staaf a écrit : I know that this is throwing more fuel on the fire (for which I am sorry), but I don't follow the argument that this is unportable. As far as I can tell, the # : # syntax is not using any special compiler extensions, it is simply substituted into a (boo) ? # : # expression, thus extracting either the first of second number from the definition of the bit field. If I am wrong I would be interested to know what about this is not standard pre-processor usage? For me at least (Wolfgang might have other reasons), the issue is not the use of the pre-processor per se, it is that this syntax breaks the '?:' triadic operator in pieces, one piece in argument value and one in macro body, and neither piece makes sense from a C standpoint: '5:3' represents no meaningful C entity, and 'X ? y' (without the ':' and third argument of the operator) is not a proper C construct. IOW, it is syntactic sugaring done at the expense of code readability. Thanks, Anton Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
Dear Wolfgang Wolfgang Denk wrote: What exactly is the reason that we cannot have better timer resolutions in NIOS? You _can_ have better timer resolutions in Nios. However, there are legacy systems that implement timer(s) with a fixed period of 10 msec. The use of such implementations is very common. How do I know? Because my customers have such implementations. Why not upgrade? Because most sane engineers are loathe to change their rtl just so they can fix a simple software bug or add a simple custom feature. My obvious preference is to continue to use the latest u-boot in such systems ... without having to create a custom branch for customers with older Nios implementations, where I use the old timer interfaces ... simply because we improved the API. Scott, maybe you can comment here? I have only one comment: Out of pure frustration, I have been avoiding any discussions regarding this timer re-write effort. At the moment I'm trying to understand if we really have a problem on NIOS2 that cannot be fixed in a way that is compatible with our current plans. This is where my frustration begins. I've said this several times before, and I don't know how else to say this ... but I'll give it one more try: This is not a Nios problem. If I can't use a 10 msec timer interrupt to detect a simple timeout condition when I'm programming a flash memory, then the timer API design is garbage. And quite frankly, the enormous amount of discussion in this matter reminds me of an undergraduate science project. We also have to deal with decrementing counters, but this is just aan unimportant detail. And it appears that we actually can have this, even on NIOS. Wow! Even on Nios! Arrggghh! The only architecture I remember that seemed prolematic was NIOS Really? There have been occasional issues that have required a patch here and there. But I consider most of them far from problematic. This is exhausting. As I recall, this entire fuss was born out of an issue with nested calls to get_timer() ... and that begat removing reset_timer ... and that begat ... and so on. And we're still spilling lots of intellectual seed here. And now we have what? A jack-of-all-trades API that can do everything with exacting precision ... other than handling a 10 msec interrupt? Best Regards, --Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2][ARM] eb_cpux9k2: add USB host support to board
This is a resend without modifications by mail client Regards Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: build some commands without -pedantic
On Tue, Jul 12, 2011 at 11:24, Linus Walleij wrote: I do this, first I apply the patches I sent for Integrator support, then I apply this patch to test with network support: no changes at all should be necessary to include/configs/. build the tools in an unconfigured tree to avoid any of that cruft. $ git clean -x -d $ make tools $ size tools/gen_eth_addr.o -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2][ARM] eb_cpux9k2: add USB host support to board
Dear Jens Scharsig, This is a resend without modifications by mail client Really? It seems the patch was completely omitted.. :) Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
Dear J. William Campbell, All I have two comments regarding this discussion so far. First, I think using the time function name at all is a VERY BAD idea. People will confuse it with the normal c library function that returns the time of day since the epoch. One may say that they should RTFM, but it is lots easier to just use another name and avoid all such confusion. Second, I think forcing all systems to use 64 bit time stamps is not a good idea. The main purpose of the timer API is to provide hardware timeouts. 64 bits is vast overkill for such a purpose. Mandating 64 bit capability for all u-boots is I think counter-productive. A 32 bit timestamp in millisecond resolution plus udelay covers all practical cases. The 1 ms resolution is probably inadequate for performance measurement, but for every u-boot system that is sometimes used for performance measurement, there are 100 (probably even more, like 1000, but I don't really have the figures) systems that are just used to boot Linux or another stand alone program. So we may need a different API for performance measurement that uses higher resolution. On most larger CPUs, there are hardware timers that can already do this with minimal work. On some less-capable CPUs, it may be lots harder, but if you aren't doing performance measurement, you don't need it. So I suggest that mandating a 64 bit API for some of the processors (68K comes to mind) is not really a good idea. It seems counter to the elegant simplicity of the rest of u-boot to stick a 64 bit requirement on timestamps used to determine if the boot delay is expired. I can only FULLY agree here !!! Lets just keep the current functions udelay(us) and u32 get_timer(), the latter maybe without parameter. Remove all *masked() and *reset() functions and lets change the timeout values used in code that also NIOS uses to be 20ms more than the hardware requires. It does not really matter if a *timeout* of 20ms is blown up to 40ms. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 1/5] Tegra2: Add macros to calculate bitfield shifts and masks
On Tue, Jul 12, 2011 at 8:29 AM, Albert ARIBAUD albert.u.b...@aribaud.netwrote: Hi Anton, Le 11/07/2011 18:19, Anton Staaf a écrit : I know that this is throwing more fuel on the fire (for which I am sorry), but I don't follow the argument that this is unportable. As far as I can tell, the # : # syntax is not using any special compiler extensions, it is simply substituted into a (boo) ? # : # expression, thus extracting either the first of second number from the definition of the bit field. If I am wrong I would be interested to know what about this is not standard pre-processor usage? For me at least (Wolfgang might have other reasons), the issue is not the use of the pre-processor per se, it is that this syntax breaks the '?:' triadic operator in pieces, one piece in argument value and one in macro body, and neither piece makes sense from a C standpoint: '5:3' represents no meaningful C entity, and 'X ? y' (without the ':' and third argument of the operator) is not a proper C construct. Yes, this is absolutely true, and we can argue about readability vs. usability vs. maintainability of such a construct (I like it, but I realize that I might be in a minority here). But it is certainly portable, there is nothing compiler or pre-processor specific here. I just wanted to clarify that so that we could have the correct debate. :) IOW, it is syntactic sugaring done at the expense of code readability. I would disagree here, it is indeed syntactic sugar, but I would assert that it is done exactly to make the code more readable. The one piece of macro magic is in a single file that can be well documented and encapsulated. I find having one #define that specifies the entire range much easier to read and debug than having two #defines, one for each end of the range that you have to make sure are matched. And this simplification can be applied to many many files. But that's what it really boils down to, what we each find easier to read and debug. I'm fine if the decision is that everyone else doesn't like the way this reads, but let's not throw it out based on a compatibility argument that is invalid. Thanks, Anton Thanks, Anton Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2][ARM] eb_cpux9k2: add USB host support to board
Am 2011-07-12 18:00, schrieb Reinhard Meyer: Dear Jens Scharsig, This is a resend without modifications by mail client Should it be better to say: The referenced email is ... ;-) Really? It seems the patch was completely omitted.. :) Reinhard Jens ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
On 7/12/2011 8:23 AM, Scott McNutt wrote: Dear Wolfgang Wolfgang Denk wrote: What exactly is the reason that we cannot have better timer resolutions in NIOS? You _can_ have better timer resolutions in Nios. However, there are legacy systems that implement timer(s) with a fixed period of 10 msec. The use of such implementations is very common. How do I know? Because my customers have such implementations. Why not upgrade? Because most sane engineers are loathe to change their rtl just so they can fix a simple software bug or add a simple custom feature. My obvious preference is to continue to use the latest u-boot in such systems ... without having to create a custom branch for customers with older Nios implementations, where I use the old timer interfaces ... simply because we improved the API. Scott, maybe you can comment here? I have only one comment: Out of pure frustration, I have been avoiding any discussions regarding this timer re-write effort. At the moment I'm trying to understand if we really have a problem on NIOS2 that cannot be fixed in a way that is compatible with our current plans. This is where my frustration begins. I've said this several times before, and I don't know how else to say this ... but I'll give it one more try: This is not a Nios problem. If I can't use a 10 msec timer interrupt to detect a simple timeout condition when I'm programming a flash memory, then the timer API design is garbage. Hi All, I agree with the idea that mandating a particular timer resolution is an un-desired limitation. You may need it for some cases, but not for all. Proof of this concept is the number of legacy UNIX systems running on 10 ms timer ticks, or for that matter the number of systems running on line cycle interrupts (16.666 ms in the US). It is also however true that one cannot ignore the timer resolution. That is what produced the problem in the first place. Asking for a delay that is less than the resolution isn't going to work as expected. This problem can be easily fixed by always adding twice the timer resolution to any requested delay, to ensure you waited at least two ticks , or by having a routine that does this for you (like the suggested API does). Right now, there are many places in the u-boot code that wait a certain small number of milliseconds under the assumption that the timer resolution is either 1) not an issue at all, or 2) is 1 ms. Both cases are wrong, the first case more so than the second. I wonder how many delays in the program that say wait 5 ms are aware that you could exit the loop after 4ms plus epsilon every so often, even with 1 ms resolution? Perhaps the tolerance is built into the number 5, perhaps not. However, it is surely not if the timer resolution is 16.666 ms. And quite frankly, the enormous amount of discussion in this matter reminds me of an undergraduate science project. Or any government project. But when you will effect lots of people, you often must kill a few trees to make sure nobody (such as yourself and other NIOS users) somehow gets a bad deal. I am now returning to real work and will be offline for a while. Good Luck All. Best Regards, Bill Campbell We also have to deal with decrementing counters, but this is just aan unimportant detail. And it appears that we actually can have this, even on NIOS. Wow! Even on Nios! Arrggghh! The only architecture I remember that seemed prolematic was NIOS Really? There have been occasional issues that have required a patch here and there. But I consider most of them far from problematic. This is exhausting. As I recall, this entire fuss was born out of an issue with nested calls to get_timer() ... and that begat removing reset_timer ... and that begat ... and so on. And we're still spilling lots of intellectual seed here. And now we have what? A jack-of-all-trades API that can do everything with exacting precision ... other than handling a 10 msec interrupt? Best Regards, --Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] scb9328: Add ARM relocation support
On 07/09/2011 05:30 PM, Torsten Koschorrek wrote: This patch fixes compiler errors due to missing definitions of CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR. It also does some cleanup: CONFIG_SYS_TEXT_BASE was moved to scb9328.h, obsolete config.mk was removed. The scb9328 board has 1 DRAM bank, so don't ask for more banks. CONFIG_NR_DRAM_BANKS will ever be 1. Signed-off-by: Torsten Koschorrek koschor...@synertronixx.de Hi Torsten, your patch does not apply on the current u-boot maainline. Can you check please and repost ? Applying: scb9328: Add ARM relocation support error: patch failed: board/scb9328/scb9328.c:39 error: board/scb9328/scb9328.c: patch does not apply error: patch failed: include/configs/scb9328.h:126 error: include/configs/scb9328.h: patch does not apply Patch failed at 0001 scb9328: Add ARM relocation support 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] tools: build some commands without -pedantic
On Tue, Jul 12, 2011 at 5:49 PM, Mike Frysinger vap...@gentoo.org wrote: On Tue, Jul 12, 2011 at 11:24, Linus Walleij wrote: I do this, first I apply the patches I sent for Integrator support, then I apply this patch to test with network support: no changes at all should be necessary to include/configs/. build the tools in an unconfigured tree to avoid any of that cruft. $ git clean -x -d $ make tools $ size tools/gen_eth_addr.o If you do this gen_eth_addr.o isn't even built, since it is only built if you first configure a board with CONFIG_CMD_NET of some kind. $ git clean -x -d $ make tools (... some clean build logs ...) $ size tools/gen_eth_addr.o size: 'tools/gen_eth_addr.o': No such file If I do the minimal test case like this: $ make tools CONFIG_CMD_NET=y I indeed get the same error again: make -C tools all make[1]: Entering directory `/home/linus/u-boot/tools' gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/linus/u-boot/include -idirafter /home/linus/u-boot/include2 -idirafter /home/linus/u-boot/include -I /home/linus/u-boot/lib/libfdt -I /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o gen_eth_addr.o gen_eth_addr.c -c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/linus/u-boot/include -idirafter /home/linus/u-boot/include2 -idirafter /home/linus/u-boot/include -I /home/linus/u-boot/lib/libfdt -I /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o gen_eth_addr gen_eth_addr.o gen_eth_addr.o: file not recognized: File truncated collect2: ld returned 1 exit status make[1]: *** [gen_eth_addr] Error 1 make[1]: Leaving directory `/home/linus/u-boot/tools' make: *** [tools] Error 2 So yes, I can positively repeat this on a clean tree. It's still -pendantic that is the culprit, if I copy the above and run manually without -pedantic it compiles fine. Thanks, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: build some commands without -pedantic
On Tue, Jul 12, 2011 at 14:48, Linus Walleij wrote: On Tue, Jul 12, 2011 at 5:49 PM, Mike Frysinger wrote: On Tue, Jul 12, 2011 at 11:24, Linus Walleij wrote: I do this, first I apply the patches I sent for Integrator support, then I apply this patch to test with network support: no changes at all should be necessary to include/configs/. build the tools in an unconfigured tree to avoid any of that cruft. $ git clean -x -d $ make tools $ size tools/gen_eth_addr.o If you do this gen_eth_addr.o isn't even built, since it is only built if you first configure a board with CONFIG_CMD_NET of some kind. not really. either use `make tools-all`, or `make CONFIG_CMD_NET=y tools`. but you figured that out already ... I indeed get the same error again: make -C tools all make[1]: Entering directory `/home/linus/u-boot/tools' gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/linus/u-boot/include -idirafter /home/linus/u-boot/include2 -idirafter /home/linus/u-boot/include -I /home/linus/u-boot/lib/libfdt -I /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o gen_eth_addr.o gen_eth_addr.c -c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/linus/u-boot/include -idirafter /home/linus/u-boot/include2 -idirafter /home/linus/u-boot/include -I /home/linus/u-boot/lib/libfdt -I /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE= -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o gen_eth_addr gen_eth_addr.o gen_eth_addr.o: file not recognized: File truncated collect2: ld returned 1 exit status make[1]: *** [gen_eth_addr] Error 1 make[1]: Leaving directory `/home/linus/u-boot/tools' make: *** [tools] Error 2 So yes, I can positively repeat this on a clean tree. It's still -pendantic that is the culprit, if I copy the above and run manually without -pedantic it compiles fine. are you using ccache ? -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: build some commands without -pedantic
On Tue, Jul 12, 2011 at 8:57 PM, Mike Frysinger vap...@gentoo.org wrote: [Me] So yes, I can positively repeat this on a clean tree. It's still -pendantic that is the culprit, if I copy the above and run manually without -pedantic it compiles fine. are you using ccache ? Yes :-P I didn't think so, but nowadays it's apparently in the Fedora development tools groupinstall. Removing the package and spawning a new shell indeed solves the problem, like I guess deleting the ccache database would. Thanks Mike! I wonder if we could autodetect this so noone else runs into it? Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: build some commands without -pedantic
On Tue, Jul 12, 2011 at 14:59, Linus Walleij wrote: On Tue, Jul 12, 2011 at 8:57 PM, Mike Frysinger wrote: [Me] So yes, I can positively repeat this on a clean tree. It's still -pendantic that is the culprit, if I copy the above and run manually without -pedantic it compiles fine. are you using ccache ? Yes :-P I didn't think so, but nowadays it's apparently in the Fedora development tools groupinstall. Removing the package and spawning a new shell indeed solves the problem, like I guess deleting the ccache database would. Thanks Mike! I wonder if we could autodetect this so noone else runs into it? not really. sounds like ccache db corruption (lose power recently?), and as with any corruption, detecting it in arbitrary build systems isnt exactly a trivial task. if you get back a valid ELF object, but not the right one, how is u-boot to know ? i'd `ccache -C` and forget about the whole thing :P -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] General gpio interface?
On Tue, Jul 12, 2011 at 04:48, Simon Schwarz wrote: am I right that there is no standard gpio interface in u-boot or did I miss it? in general you missed it, but probably not your fault as i dont think it's documented :P. and not everyone supports it (yet). the API being adopted is the same as Linux. asm/gpio.h provides: int gpio_request(unsigned gpio, const char *label) void gpio_free(unsigned gpio) int gpio_direction_input(unsigned gpio) int gpio_direction_output(unsigned gpio, int value) int gpio_get_value(unsigned gpio) void gpio_set_value(unsigned gpio, int value) int gpio_is_valid(int number) it also optionally provides magic defines specific to your CPU so you can do something like gpio_request(GPIO_PF10) rather than gpio_request(14). -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 1/5] Tegra2: Add macros to calculate bitfield shifts and masks
Dear Anton Staaf, In message CAF6FioVs5rsF27Boq9+Bb+3Cgdh2m=jj1c=41a-32mubud9...@mail.gmail.com you wrote: Sorry, but because such code is unportable we do not accept it, as it would lead to driver code that becomes unportable, too. I know that this is throwing more fuel on the fire (for which I am sorry), You don't have to apologize. I think it is important that everybody understands the reasons behind such decisions. but I don't follow the argument that this is unportable. As far as I can tell, the # : # syntax is not using any special compiler extensions, it is simply substituted into a (boo) ? # : # expression, thus extracting either the first of second number from the definition of the bit field. If I am wrong I would be interested to know what about this is not standard pre-processor usage? I did not say anything about preprocessor issues. The use of bit numbers (and ranges of bit numbers) in code is inherently unportable. For example: Bit 10 means 0x0400 on some systems (like, for example, on ARM), but it means 0x0020 on others (like, for example, on PPC). On many systems bit 0 means trhe LSB, but the Power Architecture defines it as the MSB. Thus bit numbers should never be used in any code to access bits or to create masks etc. - they are not generally applicable. 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 In Christianity neither morality nor religion come into contact with reality at any point. - Friedrich Nietzsche ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: build some commands without -pedantic
Dear Linus Walleij, In message CACRpkdaqvK3730mB67C8Bmpfm6fLHb1Tz-Bzr=lhxn1bfw2...@mail.gmail.com you wrote: Yes I'm reluctant about the whole thing, doesn't say from the patch it was indeed intended as a discussion item... You should have marked it as RFC in the subject, then. Then this happens on my side: make -C tools all make[1]: Entering directory `/home/linus/u-boot/tools' gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/linus/u-boot/include -idirafter /home/linus/u-boot/build/include2 -idirafter /home/linus/u-boot/build/include -I /home/linus/u-boot/lib/libfdt -I /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE=0x0100 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o /home/linus/u-boot/build/tools/gen_eth_addr.o gen_eth_addr.c -c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/linus/u-boot/include -idirafter /home/linus/u-boot/build/include2 -idirafter /home/linus/u-boot/build/include -I /home/linus/u-boot/lib/libfdt -I /home/linus/u-boot/tools -DCONFIG_SYS_TEXT_BASE=0x0100 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o /home/linus/u-boot/build/tools/gen_eth_addr /home/linus/u-boot/build/tools/gen_eth_addr.o /home/linus/u-boot/build/tools/gen_eth_addr.o: file not recognized: File truncated collect2: ld returned 1 exit status make[1]: *** [/home/linus/u-boot/build/tools/gen_eth_addr] Error 1 make[1]: Leaving directory `/home/linus/u-boot/tools' make: *** [tools] Error 2 Which is because: ls -al build/tools/gen_eth_addr.o -rw-rw-r--. 1 linus linus 0 Jul 12 17:16 build/tools/gen_eth_addr.o This is what I see: Short: - ./MAKEALL ap920t Configuring for ap920t board... Variant: Core module CM920T with core arm920t pci.c: In function 'pci_init_board': pci.c:392: warning: implicit declaration of function 'pciauto_config_init' textdata bss dec hex filename 1626503236 36260 202146 315a2 ./u-boot - SUMMARY Boards compiled: 1 Boards with warnings or errors: 1 ( ap920t ) -- Long: ... make -C tools all make[1]: Entering directory `/home/wd/git/u-boot/work/tools' gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/wd/git/u-boot/work/include -idirafter /home/wd/git/u-boot/work/include2 -idirafter /home/wd/git/u-boot/work/include -I /home/wd/git/u-boot/work/lib/libfdt -I /home/wd/git/u-boot/work/tools -DCONFIG_SYS_TEXT_BASE=0x0100 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o gen_eth_addr.o gen_eth_addr.c -c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/wd/git/u-boot/work/include -idirafter /home/wd/git/u-boot/work/include2 -idirafter /home/wd/git/u-boot/work/include -I /home/wd/git/u-boot/work/lib/libfdt -I /home/wd/git/u-boot/work/tools -DCONFIG_SYS_TEXT_BASE=0x0100 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o gen_eth_addr gen_eth_addr.o strip gen_eth_addr gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/wd/git/u-boot/work/include -idirafter /home/wd/git/u-boot/work/include2 -idirafter /home/wd/git/u-boot/work/include -I /home/wd/git/u-boot/work/lib/libfdt -I /home/wd/git/u-boot/work/tools -DCONFIG_SYS_TEXT_BASE=0x0100 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o img2srec.o img2srec.c -c gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -idirafter /home/wd/git/u-boot/work/include -idirafter /home/wd/git/u-boot/work/include2 -idirafter /home/wd/git/u-boot/work/include -I /home/wd/git/u-boot/work/lib/libfdt -I /home/wd/git/u-boot/work/tools -DCONFIG_SYS_TEXT_BASE=0x0100 -DUSE_HOSTCC -D__KERNEL_STRICT_NAMES -pedantic -o img2srec img2srec.o strip img2srec ... Not many hints here though :-( Something in your host system appears to be broken. I've tested both on 32 bit (gcc-4.6.0-9.fc15.i686) and 64 bit (gcc-4.6.0-9.fc15.x86_64) systems, without seeing any such problems. Sorry... 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 Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. - Dick Brandon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: build some commands without -pedantic
Dear Linus Walleij, In message cacrpkdadsmrw3uu6q7_mabsb-wpaey-wmkyf7q0waxnby12...@mail.gmail.com you wrote: On Tue, Jul 12, 2011 at 8:57 PM, Mike Frysinger vap...@gentoo.org wrote: [Me] So yes, I can positively repeat this on a clean tree. It's still -pendantic that is the culprit, if I copy the above and run manually without -pedantic it compiles fine. are you using ccache ? Yes :-P I didn't think so, but nowadays it's apparently in the Fedora development tools groupinstall. Removing the package and spawning a new shell indeed solves the problem, like I guess deleting the ccache database would. I'm using ccache as well, and always did. Never saw such an issue before. Did you have any I/O errors (like corrupt data) on your system lately? 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 very few personal problems that cannot be solved through a suitable application of high explosives. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: build some commands without -pedantic
On Tue, Jul 12, 2011 at 16:05, Wolfgang Denk wrote: Linus Walleij wrote: On Tue, Jul 12, 2011 at 8:57 PM, Mike Frysinger wrote: [Me] So yes, I can positively repeat this on a clean tree. It's still -pendantic that is the culprit, if I copy the above and run manually without -pedantic it compiles fine. are you using ccache ? Yes :-P I didn't think so, but nowadays it's apparently in the Fedora development tools groupinstall. Removing the package and spawning a new shell indeed solves the problem, like I guess deleting the ccache database would. I'm using ccache as well, and always did. Never saw such an issue before. Did you have any I/O errors (like corrupt data) on your system lately? with Gentoo, we've often seen unexpected reboots (power loss / oom / oops / etc...) result in zero byte files being left in the cache. comes up semi-frequently for us since so many people are using ccache and building from source. the zero byte aspect makes sense when using ext4 due to the fs design (metadata gets committed, but contents are in transit and lost). perhaps ccache itself should grow a 0 byte file check. i cant imagine any valid compiled object being 0 bytes ... -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net/eth.c: make eth_get_dev_by_name(NULL) safe
On Tue, Jul 12, 2011 at 05:22, Detlev Zundel wrote: Mike Frysinger wrote: but the point isnt the impact of this single check. it sets the precedence that every function in u-boot that takes a pointer should start over protecting itself against poorly written code originating elsewhere. now your few characters is quite a bit more. I still stand by what I said that if we have functions that can be called from many places (i.e. library-like), then the functions should be conservative in what they expect. Tightly coupled code can be looser in this respect. Maybe our disagreement stems from the fact that you consider this function to be tightly coupled and not really library like? not really. i consider this to be garbage-in garbage-out. imo, u-boot isnt a C library that should be padded with garbage checking all over. the result only helps broken systems (edge cases) while hindering the rest. i wouldnt have a problem with adopting an NDEBUG system, or perhaps adding assert()'s to this code. then people can easily opt-out of it all and for the people doing development, can easily turn things on. assert(name != NULL); the current miiphy system needs to be replaced (this runtime string based approach is crazy), but that's a completely different topic :). -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 1/5] Tegra2: Add macros to calculate bitfield shifts and masks
On Tue, Jul 12, 2011 at 12:30 PM, Wolfgang Denk w...@denx.de wrote: Dear Anton Staaf, In message CAF6FioVs5rsF27Boq9+Bb+3Cgdh2m=jj1c= 41a-32mubud9...@mail.gmail.com you wrote: Sorry, but because such code is unportable we do not accept it, as it would lead to driver code that becomes unportable, too. I know that this is throwing more fuel on the fire (for which I am sorry), You don't have to apologize. I think it is important that everybody understands the reasons behind such decisions. Thanks. but I don't follow the argument that this is unportable. As far as I can tell, the # : # syntax is not using any special compiler extensions, it is simply substituted into a (boo) ? # : # expression, thus extracting either the first of second number from the definition of the bit field. If I am wrong I would be interested to know what about this is not standard pre-processor usage? I did not say anything about preprocessor issues. The use of bit numbers (and ranges of bit numbers) in code is inherently unportable. For example: Bit 10 means 0x0400 on some systems (like, for example, on ARM), but it means 0x0020 on others (like, for example, on PPC). On many systems bit 0 means trhe LSB, but the Power Architecture defines it as the MSB. Thus bit numbers should never be used in any code to access bits or to create masks etc. - they are not generally applicable. Ahh, I think I've finally (been lurking on this subject for a while) got the core of this understood. The problem is that if this mechanism (bit numbers of any sort) were allowed in to U-Boot, then common driver code would end up using it and the result would be drivers that specify bit fields using LSB 0 (or MSB 0) notation that would not match a datasheet from an SoC that uses the alternative standard. For example, the ns16550 driver would have to pick one of LSB 0 or MSB 0 in it's header file instead of just specifying a mask value. The result would be that one of the standard bit field numbers would become a second class citizen. The code would still work for them, but the encoding of the masks would be in an alien format. That makes sense to me. Would an alternative that uses the width and size of the field be acceptable? Then there is a well understood (on both types of architectures) mapping from these values to the mask and shift required to access portions of a register and/or variable in memory. Thanks, Anton 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 In Christianity neither morality nor religion come into contact with reality at any point. - Friedrich Nietzsche ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 1/5] Tegra2: Add macros to calculate bitfield shifts and masks
Dear Anton Staaf, In message caf6fiovcfgxzep7dhgxyr+cjaf0nq8lybxkveaqycz8noos...@mail.gmail.com you wrote: That makes sense to me. Would an alternative that uses the width and size of the field be acceptable? Then there is a well understood (on both types of architectures) mapping from these values to the mask and shift required to access portions of a register and/or variable in memory. width and size seem indentical to me here. Do you mean width and offset or so? The problem still remains. People who are used to number bits from left to right will also tend to count bit offsets in the same direction. In the end, the most simple and truly portable way is specifying the masks directly. What's wrong with definitions like #define SCFR1_IPS_DIV_MASK 0x0380 #define SCFR1_PCI_DIV_MASK 0x0070 #define SCFR1_LPC_DIV_MASK 0x3800 etc.? I can actually read these much faster that any of these bit field definitions. --00504502e3b9570ace04a7e593ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please stop posting HTML. 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 News is what a chap who doesn't care much about anything wants to read. And it's only news until he's read it. After that it's dead. - Evelyn Waugh _Scoop_ (1938) bk. 1, ch. 5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tools: build some commands without -pedantic
On Tue, Jul 12, 2011 at 10:05 PM, Wolfgang Denk w...@denx.de wrote: Yes I'm reluctant about the whole thing, doesn't say from the patch it was indeed intended as a discussion item... You should have marked it as RFC in the subject, then. I forgot, mea culpa. I didn't think so, but nowadays it's apparently in the Fedora development tools groupinstall. Removing the package and spawning a new shell indeed solves the problem, like I guess deleting the ccache database would. I'm using ccache as well, and always did. Never saw such an issue before. Did you have any I/O errors (like corrupt data) on your system lately? Yep it's a laptop, it boots from a USB drive, sometimes I even drop the drive and disconnect it in transit so data corruption is happening every day. I removed ccache since I don't trust it anymore, sorry about the fuzz. Thanks Wolfgang, Linus Walleij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v2 1/5] Tegra2: Add macros to calculate bitfield shifts and masks
On Tue, Jul 12, 2011 at 2:18 PM, Wolfgang Denk w...@denx.de wrote: Dear Anton Staaf, In message caf6fiovcfgxzep7dhgxyr+cjaf0nq8lybxkveaqycz8noos...@mail.gmail.com you wrote: That makes sense to me. Would an alternative that uses the width and size of the field be acceptable? Then there is a well understood (on both types of architectures) mapping from these values to the mask and shift required to access portions of a register and/or variable in memory. width and size seem indentical to me here. Do you mean width and offset or so? The problem still remains. People who are used to number bits from left to right will also tend to count bit offsets in the same direction. Yes, I meant shift, not size. While it may be the case that some people count bits from the left, I don't think I've ever seen code that tries to right shift a value into place by that offset, everything seems to use the (value shift) idiom. In which case specifying a shift (offset) value seems pretty safe. In the end, the most simple and truly portable way is specifying the masks directly. What's wrong with definitions like #define SCFR1_IPS_DIV_MASK 0x0380 #define SCFR1_PCI_DIV_MASK 0x0070 #define SCFR1_LPC_DIV_MASK 0x3800 etc.? I can actually read these much faster that any of these bit field definitions. The only problem with this is that there is one piece of missing information, which is how do you get the value of the field that is masked as if it were a 4-bit or 3-bit number. That is, if I want the IPS_DIV value, I probably want: (value SCFR1_IPS_DIV_MASK) 20 Likewise, if I want to set the IPS divisor to 5 say, I would have to do: (value ~SCFR1_IPS_DIV_MASK) | (5 20) In both cases the value 20 needs to come from somewhere. So you would probably end up having: #define SCFR1_IPS_DIV_MASK 0x0380 #define SCFR1_IPS_DIV_SHIFT 20 and (value SCFR1_IPS_DIV_MASK) SCFR1_IPS_DIV_SHIFT (value ~SCFR1_IPS_DIV_MASK) | (5 SCFR1_IPS_DIV_SHIFT) And I think it would be great if these could turn into: field_value = GET_FIELD(register_value, SCFR1_IPS_DIV) register_value = SET_FIELD(register_value, SCFR1_IPS_DIV, 5) The GET and SET macros would in my opinion be more readable than a lot of shifting and oring. And could be used with existing U-Boot register access functions: writel(SET_FIELD(readl(reg), SCFR1_IPS_DIV, 5), reg) Or, and I think this is something you have nacked in that past, but I like it and hope you don't mind me ending with it, this could eventually be: SET_REGISTER_FIELD(reg, SCFR1_IPS_DIV, 5) --00504502e3b9570ace04a7e593ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please stop posting HTML. Ack, sorry about that, it's my least favorite feature of web mail. :( 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 News is what a chap who doesn't care much about anything wants to read. And it's only news until he's read it. After that it's dead. - Evelyn Waugh _Scoop_ (1938) bk. 1, ch. 5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
Hi Wolfgang, On 12/07/11 23:10, Wolfgang Denk wrote: Dear Graeme Russ, In message 4e1c23b8.6020...@gmail.com you wrote: So how do we deal with Nios2? It is what caused such a deep investigation into the timer API. We have three choices I can think of off the top of my head: 1. Move the whole timer API up to the architecture level and replicate code everywhere 2. Make the whole timer API weak 3. Fundamentally allow the timer API to handle arbitrary timer resolutions 1. Way ugly. We already have this, and that is why we are here today 2. Well, you know what will happen - Someone will be unhappy with the generic API and rewrite a completely different one (timer_masked anyone!) 3. Why is this so evil? The big disadvantage of 3) is that you cannot make any reasonable assumptions any more in the code. If I place a udelay(10) in some device driver, I am probably aware that we don't have exact times, and that the actual delay may be 10 or 12 or eventually even 20 micro- seconds. We should make sure that the delay never takes less than 10 us, but we also have to guarantee that it does not take - for example - 10 milliseconds. OK, I will assume you agree with me that #1 and #2 are unacceptable In the case of Nios2 we cannot use the Timer API for udelay since any udelay will blow out to 20ms - Very Bad Indeed. Maybe udelay might need to be defined weak, but I fear this will be the thin end of the wedge... [snip pondering on NIOS] Also remember that if we are looking to inherit nanosecond time base from Linux, it will be extremely unlikely that every board will support a native 1ns clock source. Typical examples would be 33MHz (~30ns) or 66MHz (~15ns). In any case, there will be a lot of variance between boards, so we will still need to cater for arbitrary resolutions 1) Get the current time Agreed. That's time(). 2) Report the minimum time elapsed since an arbitrary epoch 3) Report the maximum time elapsed since an arbitrary epoch I don't understand why we would need this. Profiling - Lets say your hardware counter is ms accurate, if an operation takes 0.5ms then using #2 would give a 50/50 chance of reporting that the elapsed time was 0ms. Using method #3, the 50/50 split would be 1ms/2ms. Now as you low-level hardware clock becomes more accurate, those numbers move down to the real 0.5ms, but will never report that the operation took 0ms. I guess going to nanosecond time base, the need for #3 lessens as the hardware clock gets faster. Also, given that the architecture will need to provide a 'nanoseconds per counter increment', #3 can be easily derived if someone really wants it, but as soon as two people want it, you may as well move it into lib/ as it is a trivial function which is 100% architecture independent. 4) Delay for an arbitrary period of time 4 is a derivative of 2 - Just loop until at least the required time has elapsed. Right. Both delays and timeouts work like that, the difference being that delays are blocking, i. e. there is no other code running inbetween, and you can just sit in a tight spinning loop. I have not seen any requirement yet for 3. See above And you then suggest bringing in no less than 6 functions from Linux It's just macros. And we don't need to use them all. Actually time_after() is all that's needed to satisfy our current usage. Oh please, macro, inline function, function - They are all API 'functions' - As you stated before, the bigger the API, the more people will abuse is by using the wrong functions. You stated that you want to keep the public profile of the API as small and tight as possible by rejecting the additional functions previously proposed. Done - I will reject the current series and rebase/repost the patches you have already ack'd and assign them to you in patchwork - I'll leave it up to you to pull them in Don't reject them - just mark them as RFC. OK Provided you have access to an incrementing value which increments at a fixed rate and you know the rate, the rest is architecture independent We also have to deal with decrementing counters, but this is just aan unimportant detail. And it appears that we actually can have this, even on NIOS. Trivial in the proposed architecture with a #define in the config CONFIG_SYS_HW_COUNTER_DECREMENTS (or similar) We could also say this is all we need. If we have a working high precision TOD timestamp, we can derive all other things we need from that. So you want to look at bringing in the Linux TOD API as well? That means we No, I don't. See my previous comments. And the longer I think about it, the more I think we should just use u64 time(void) as core of this new code. Agreed - As said before (for the time being) the return value of any arbitrary call to time() means nothing. It _may_ mean the number of nanoseconds since power-up, but this is by no means guaranteed. Actually, I do agree will Bill - time() is
Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
Hi Reinhard, On 13/07/11 02:08, Reinhard Meyer wrote: Dear J. William Campbell, All [snip] Lets just keep the current functions udelay(us) and u32 get_timer(), the latter maybe without parameter. Remove all *masked() and *reset() functions This is happening and has Wolfgang's 100% support. Patches are done, just need to be rebased and resent and lets change the timeout values used in code that also NIOS uses to be 20ms more than the hardware requires. It does not really matter if a *timeout* of 20ms is blown up to 40ms. Can't do that - That would mean winding out common code (CFI, Network, Serial, FPGA etc, etc) timeouts to global worst-case scenario unless you want to add a #define and start littering the code with macro's - Urgh! Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1 (WIP) 00/16] [Timer]API Rewrite
On 7/12/2011 5:33 PM, Graeme Russ wrote: Hi Reinhard, On 13/07/11 02:08, Reinhard Meyer wrote: Dear J. William Campbell, All [snip] Lets just keep the current functions udelay(us) and u32 get_timer(), the latter maybe without parameter. Remove all *masked() and *reset() functions This is happening and has Wolfgang's 100% support. Patches are done, just need to be rebased and resent and lets change the timeout values used in code that also NIOS uses to be 20ms more than the hardware requires. It does not really matter if a *timeout* of 20ms is blown up to 40ms. Can't do that - That would mean winding out common code (CFI, Network, Serial, FPGA etc, etc) timeouts to global worst-case scenario unless you want to add a #define and start littering the code with macro's - Urgh! Hi All, Yes, this is true. However, the time_elapsed_since routine can do this dynamically (i.e. add twice the timer resolution) . I think you had another function name (at_least) involved, but you can define time_elapsed_since as always compensating for the resolution. That will fix any resolution questions in a processor-specific way. It is either that or the ifdefs. One way or another, the resolution must be addressed. Up to now, the implicit resolution has been 1 ms, but we now know that is not general enough. Best Regards, Bill Campbell Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 0/2] add sdhci generic framework
Hi Andy, Could this version be accepted to be merged? Thanks, Lei On Wed, Jun 29, 2011 at 3:50 PM, Lei Wen lei...@marvell.com wrote: V1: add sdhci generic framework and with marvell sdhci implementation V2: rename the previous file name from sdhci-mv to mv_sdhci Lei Wen (2): MMC: add sdhci generic framework MMC: add marvell sdhci driver drivers/mmc/Makefile | 2 + drivers/mmc/mv_sdhci.c | 21 +++ drivers/mmc/sdhci.c | 433 include/sdhci.h | 325 4 files changed, 781 insertions(+), 0 deletions(-) create mode 100644 drivers/mmc/mv_sdhci.c create mode 100644 drivers/mmc/sdhci.c create mode 100644 include/sdhci.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] running as stand alone
Hi, My u-boot works when run from the BDI emulator. But when it is programmed in flash and powered on with out connecting the emulator It does not come up . I checked the HRCW its correct. Any suggestions? Regards, Smitha Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm: add CONFIG_MACH_TYPE option and documentation
Hi Albert, On 07/08/11 00:06, Igor Grinberg wrote: On 07/07/11 20:46, Albert ARIBAUD wrote: Le 07/07/2011 18:51, Igor Grinberg a écrit : If we have this option and it is documented, then any new board can use it instead of thinking (although it is simple) where and how to dereference the bi_arch_number. Not sure I get you there. Can you elaborate on a more precise example that would show the benefits of it? For example, if you think of Christopher's patch (ARM: Warn when the machine ID isn't set.), If you need Christopher's patch, then there are cases when the machid is not set, right? When someone gets this warning, he thinks: Ah, I forgot the machid! and then goes to fix the code, but again he thinks, where is the best place to put it? For us, it is trivial, that it should be in board_init() function, but for newbies, it is not that trivial. With this patch, you get the explanation and also a place to put the machid definition. With this patch, you just define the configuration variable and the whole thing will be done for you. Another example would be the board/nvidia/*, the code is shared as much as possible, and the mach_type is set in the common code. That is something I would expect to be done for all ARM boards, not just for nvidia... I see your point. Now the issue I foresee is that this commonalization has benefits only for boards which currently set their bi_arch_number in board_init_f(), Vast majority of boards set their bi_arch_number in board_init(). I went through all the boards and there is only one that set it in board_early_init_f() and several that do this in checkboard(). This makes me think of v2 of this patch which will set the bi_arch_number in board_init_f() just before the init_sequence[] array is run. but has no incentive -- that's a code that will be used only in a few places and could stay that way for quite long, because boards that will not adhere to it will still build unchanged. Well, I don't like to force people do something by breaking their builds... In general, I think that any change should not break any existing code (at least not on purpose). At least, this is how it works in Linux. IOW, there is no benefit for e.g. ED Mini V2, to use CONFIG_MACH_TYPE, so why would it? Thus instead of simplifying and commonalizing, this feature will *add* to the code base complexity. Unless the goal is to add this macro *and* change all related board codes in the same patchset? I don't see it as feasible either. Well, I can do the change board/* wide, but it will take some time to accomplish. Also, we still don't have an exact list of boards for removal, so I'd like to wait until the removal takes place, so there will be less boards to consider. Any suggestion for ensuring adoption of the feature wherever it can be used? Currently, I can think of: 1) Changing all relevant boards to use it - will eliminate bad examples. 2) Pointing to the use of CONFIG_MACH_TYPE during code review. 3) Introduce one more config option, like CONFIG_DYNAMIC_MACH_TYPE and change the patch to something like: #ifndef CONFIG_DYNAMIC_MACH_TYPE bi_arch_number = CONFIG_MACH_TYPE; #endif If we decide to go for 3), it would integrate nicely with Christopher's patch. So, what will it be? If it will be 1 and 2, then I'd like to get this patch in, so I can start working on 1. If it will be 3, then I want to make the change and resubmit, hoping for current merge window... -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
