Re: [U-Boot] [ANNOUNCE] Kconfig support
On Mon, Apr 20, 2009 at 02:29:32PM -0400, Mike Frysinger wrote: [stupid attempt of a flame war deleted] For the audience which is wondering about what's going on here, I have no idea. The idea behind B-Boot-v2 is: U-Boot itself is a *great* bootloader from the user's poing of view. It is the best thing we have in the open source market place, and it is especially *much* better than all the redboots, grubs whatever. When we started the v2 effort, we saw that U-Boot has a problem with it's inner design. It was great when the U-Boot project started, but it has (successfully) grown over the years, and as with every project that has not been reworked over more than a decade, it is almost impossible to fix design decisions without breaking all the boards out there. Yes, it works with the Linux kernel, but compare the size of the communities. So our intention was and is: 1. Wolfgang has a focus on stability and gradual changes. We respect this political position because it is a *good* one. 2. We need something else four our ARM, PowerPC, Blackfin and x86 projects. The technical features I'm talking about are in the README document. The focus is on a modern design, extensability and testability, not on feature completeness. 3. It was an active decision from our team *not* to fork and call it something else than U-Boot(-v2) when we started. We see that the U-Boot community is strong, it has long term aims and last but not least, it has a *great* bootloader. We talked to Wolfgang before doing so, and Wolfgang's position was in the spirit of go ahead, here is a git tree, and let the community decide. 4. v2 has been designed with much of the technical ideas of modern Linux kernels in mind; most probably v1 would have done the same if it had started 10 years later. So we think our work fits perfectly into the spirit of the U-Boot project. 4. Yes, community splitup is bad. But if one community has overlapping aims which can be worked on under the same roof - why on earth should we not do this? 5. It may happen that the v1 people take features from v2 and bring them into v1 over the time. Great than - v2 would have done it's job then. 6. It may happen that the v2 community grows over the time and more and more boards will be added. Great then - users would have a choice *within* the U-Boot community, up to a gradual change to the new code base. What ever will happen - I don't see *any* reason for whatever Mike is trying to enforce here. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANNOUNCE] Kconfig support
On Tue, 21 Apr 2009, Robert Schwebel wrote: What ever will happen - I don't see *any* reason for whatever Mike is trying to enforce here. I don't see how Mike is trying to nor can enforce anything like that. He's a single person expressing his views. But I do second the notion that good ideas could (and should?) be copied from v2 to v1 since v2 isn't an available option for lots of u-booters (yeah that's the name of users using u-boot! ;-). -- / daniel.haxx.se ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] environment variables crc
Mike Frysinger wrote: On Monday 20 April 2009 11:46:22 Gerrit Van Damme wrote: I've copied a flash image of one board to another one and changed the ethaddr (environment variable) of course when I start Uboot now the system says: CRC bad, using default environment variables. Now what I would like to do is recalculate that CRC, change it in the image and then copy it to the second board. Can anyone tell me how I can calculate the CRC and where it is located. I already understood that it's a CRC32. saveenv. the CRC is the first 4 bytes of the environment and is calculated using the environment. -mike Hey Mike, Thanks for your answer. The saveenv command doesn't work for me because then the default env variables are stored and this is what I want to avoid. It's already a good thing that I can see that the first 4 bytes really look like the CRC of the environment. So this was really helpfull info. Now you tell me it's calculated using the environment. In the source code I found the env variables crc calculated for a size of ENV_SIZE, but I was unable to see how it was defined. Do you have more info on this? Is the environment data (for crc calculation) terminated by a certain char (or sequence of chars) ? Thanks and regards, Gerrit ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Data cache breaks U-Boot on ARM
Hello Drasko, Great. Maybe you want to post your patches so others can benefit from that acchievement, too? It will be my pleasure, so I will take a look how can I make a usefull patch as soon as I clean the code. I am very interested in your work on this subject. If you want, I can help you cleaning it up for mainline. So, I would even be interested in the raw code as well. I can also take a look at the USB code to get that working... Kind Regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Urgent Order
Dear Sir/Madam My regard to you, Well am Larry Bills and i will like to know if you do have plywood box in stock for sale or may i know if i can place and order for me newly company in Ghana which is Macdan wood shop 0233 Nima Ghana and also i will like to know the method of payment that you do accept. Thanks for your kind perusal and hope to here from you soon Regard Larry Bills ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] standalone application for ppc internal registers access
Hi eija_flight, I am using GCC inline assembly in standalone applications to access my cpu (ppc) internal registers. And it seems some of the registers were needed by U-boot to run, because when I am accessing some of these registers via standalone applications, the board will go reset or hangs. Is there any method to avoid this reset/hangs matter and peacefully back to U-boot after exiting the standalone applications? because I need to use each of registers, respectively. There once was the extraordinary idea of saving registers before usage and restoring them on exit. Cheers Detlev -- Oh, didn't you know, the Lord did the original programming of the universe in COBOL. - That's why the world is the evil work of Satan. A true divine being would have used Scheme. - And, if so, Jesus would have been crucified on a big lambda symbol. -- K. Chafin, K. Schilling D. Hanley, on comp.lang.lisp -- 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
Re: [U-Boot] [PATCH 1/3] smc911x: write back the manually set MAC address
On Wed, Apr 08, 2009 at 01:23:37PM +0200, Daniel Mack wrote:
Signed-off-by: Daniel Mack dan...@caiaq.de
Cc: Sascha Hauer s.ha...@pengutronix.de
ping.
---
drivers/net/smc911x.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 30f2dc2..8c9a2a8 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -41,8 +41,13 @@ static int smx911x_handle_mac_address(bd_t *bd)
unsigned long addrh, addrl;
uchar m[6];
- /* if the environment has a valid mac address then use it */
- if (!eth_getenv_enetaddr(ethaddr, m)) {
+ if (eth_getenv_enetaddr(ethaddr, m)) {
+ /* if the environment has a valid mac address then use it */
+ addrl = m[0] | (m[1] 8) | (m[2] 16) | (m[3] 24);
+ addrh = m[4] | (m[5] 8);
+ smc911x_set_mac_csr(ADDRL, addrl);
+ smc911x_set_mac_csr(ADDRH, addrh);
+ } else {
/* if not, try to get one from the eeprom */
addrh = smc911x_get_mac_csr(ADDRH);
addrl = smc911x_get_mac_csr(ADDRL);
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] smc911x: do net reset the chip if no EEPROM is connected
On Wed, Apr 08, 2009 at 11:57:37PM -0400, Mike Frysinger wrote: Not if the MAC is stored in the volatile smc911x registers. Issuing a soft reset flushes these values - if U-Boot does that, the OS has no change getting them. then either your u-boot or your OS is misconfigured and you need to fix that. as clearly stated in docs/README.enetaddr, the environment is the place where mac addresses live when there is no dedicated storage (like an eeprom). ignoring that, the mac address doesnt magically get programmed. if no network operation was initiated, then the part wouldnt have been programmed anyways, so you're still left with an OS that cant get itself functional. Ok, true. Thanks for pointing this out. Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] smc911x: write back the manually set MAC address
Hi Sascha, On Tue, Apr 21, 2009 at 01:38:23PM +0200, Sascha Hauer wrote: On Wed, Apr 08, 2009 at 01:23:37PM +0200, Daniel Mack wrote: If the MAX address is given by the environment, write it back to the hardware. Signed-off-by: Daniel Mack dan...@caiaq.de Cc: Sascha Hauer s.ha...@pengutronix.de Acked-by: Sascha Hauer s.ha...@pengutronix.de Anyway, you shouldn't rely on this. I'm the original author of this driver, but I do not use U-Boot-v1 anymore, so I can't tell if this breaks something or not. No problem. I just Cc'ed all email addresses I could find in the code. Who will pick that one and the one regarding support for the 9220 controller for mainline? Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
Jon Smirl wrote: On Mon, Apr 20, 2009 at 8:06 PM, Jon Smirl jonsm...@gmail.com wrote: On Mon, Apr 20, 2009 at 7:57 PM, Kumar Gala ga...@kernel.crashing.org wrote: On Apr 20, 2009, at 5:01 PM, Jon Smirl wrote: On Mon, Apr 20, 2009 at 5:11 PM, Kumar Gala ga...@kernel.crashing.org wrote: In chatting w/Wolfgang on IRC he felt that we should maintain the highlevel picking a board implies ARCH and other settings. However this seems like a lot of boards in one list.. To get a rough order of magnitude MAKEALL is ~880 lines. How can we reduce this to make it a bit more manageable? I'd arrange them by vendor. The vendor kconfig variable doesn't need to be used in code generation. Assuming boards/ is grouped by vendor today: $ ls -1 board/ | wc -l 269 still seems like a long list. Everyone will know the vendor of their board. You could alphabetize and break the list into groups. I think there are some entries in board/ that should be combined and moved into vendor subdirs. There are a lot of boards that could be moved into a vendor subdirs. I suspect we have less than 100 vendors. Maybe as few as 60. Don't some of these ads board belong in the freescale dir? jonsm...@terra:/home/apps/u-boot/board$ ls *ads* -d ads5121 adsvix fads mpc8260ads mpc8266ads mpc8540ads mpc8560ads mx1ads mx31ads I suspect there are also quite a few boards that don't have a vendor attached to them or the vendor only has one or two boards in u-boot. I would create a vendor named other to lump the miscellaneous boards into. $ ls -1 board/*/*.mk | wc -l 211 OK, that says that, of the 269 directories, 58 are vendor subdirectories and 211 are boards that should be stuffed into either an existing vendor subdirectory, a new vendor subdirectory, or other. (Interesting... vendors appear to have 202 boards, so we have almost as many vendor subdirectory boards as top level boards.) $ ls -1 board/*/*/*.mk | wc -l 202 Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] smc911x: write back the manually set MAC address
On Wed, Apr 08, 2009 at 01:23:37PM +0200, Daniel Mack wrote:
If the MAX address is given by the environment, write it back to the
hardware.
Signed-off-by: Daniel Mack dan...@caiaq.de
Cc: Sascha Hauer s.ha...@pengutronix.de
Acked-by: Sascha Hauer s.ha...@pengutronix.de
Anyway, you shouldn't rely on this. I'm the original author of this
driver, but I do not use U-Boot-v1 anymore, so I can't tell if this
breaks something or not.
Sascha
---
drivers/net/smc911x.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 30f2dc2..8c9a2a8 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -41,8 +41,13 @@ static int smx911x_handle_mac_address(bd_t *bd)
unsigned long addrh, addrl;
uchar m[6];
- /* if the environment has a valid mac address then use it */
- if (!eth_getenv_enetaddr(ethaddr, m)) {
+ if (eth_getenv_enetaddr(ethaddr, m)) {
+ /* if the environment has a valid mac address then use it */
+ addrl = m[0] | (m[1] 8) | (m[2] 16) | (m[3] 24);
+ addrh = m[4] | (m[5] 8);
+ smc911x_set_mac_csr(ADDRL, addrl);
+ smc911x_set_mac_csr(ADDRH, addrh);
+ } else {
/* if not, try to get one from the eeprom */
addrh = smc911x_get_mac_csr(ADDRH);
addrl = smc911x_get_mac_csr(ADDRL);
--
1.6.2.1
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] USB key not recognized
Hi I am using Atmel AT91SAM9263-EK and running u-boot 1.1.5, it fails to recognize a USB key of size 1GB and formatted in FAT. This is what is happening: U-boot usb start (Re)start USB... USB: scanning bus for devices... USB device not responding, giving up (status=20) 2 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found I have tried U-boot version 1.3.4 and see the same issue. I am using U-boot from the linux demo that came with the atmel kit. Thanks for helping. Aman. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc83xx: MPC8360ERDK: fix environment offset configuration bug
The size of U-Boot binary for MPC8360ERDK increased ( 2 flash sectors now), so 'saveenv' will partially overwrite U-Boot in flash and will brick the board. This patch moves environment offset to fourth flash sector. Signed-off-by: Anatolij Gustschin ag...@denx.de --- include/configs/MPC8360ERDK.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/configs/MPC8360ERDK.h b/include/configs/MPC8360ERDK.h index f7ebdaa..1670809 100644 --- a/include/configs/MPC8360ERDK.h +++ b/include/configs/MPC8360ERDK.h @@ -339,7 +339,7 @@ #ifndef CONFIG_SYS_RAMBOOT #define CONFIG_ENV_IS_IN_FLASH 1 -#define CONFIG_ENV_ADDR(CONFIG_SYS_MONITOR_BASE + 0x4) +#define CONFIG_ENV_ADDR(CONFIG_SYS_MONITOR_BASE + 0x6) #define CONFIG_ENV_SECT_SIZE 0x2 /* 128K(one sector) for env */ #define CONFIG_ENV_SIZE0x2 #else /* CONFIG_SYS_RAMBOOT */ -- 1.5.3.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] smc911x: write back the manually set MAC address
Hi Daniel, On Tue, Apr 21, 2009 at 4:44 AM, Daniel Mack dan...@caiaq.de wrote: Hi Sascha, On Tue, Apr 21, 2009 at 01:38:23PM +0200, Sascha Hauer wrote: On Wed, Apr 08, 2009 at 01:23:37PM +0200, Daniel Mack wrote: If the MAX address is given by the environment, write it back to the hardware. Signed-off-by: Daniel Mack dan...@caiaq.de Cc: Sascha Hauer s.ha...@pengutronix.de Acked-by: Sascha Hauer s.ha...@pengutronix.de Anyway, you shouldn't rely on this. I'm the original author of this driver, but I do not use U-Boot-v1 anymore, so I can't tell if this breaks something or not. No problem. I just Cc'ed all email addresses I could find in the code. Who will pick that one and the one regarding support for the 9220 controller for mainline? Network drivers are my responsibility. Please CC me in the future as it stands out more clearly. I guess I was waiting on you to resolve 3/3, but instead can pick up parts 1 and 2 if you like. Thanks, Daniel regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] smc911x: write back the manually set MAC address
On Tue, Apr 21, 2009 at 06:28:34AM -0700, Ben Warren wrote: Anyway, you shouldn't rely on this. I'm the original author of this driver, but I do not use U-Boot-v1 anymore, so I can't tell if this breaks something or not. No problem. I just Cc'ed all email addresses I could find in the code. Who will pick that one and the one regarding support for the 9220 controller for mainline? Network drivers are my responsibility. Please CC me in the future as it stands out more clearly. I guess I was waiting on you to resolve 3/3, but instead can pick up parts 1 and 2 if you like. I'll try to solve 3/3 in another fashion, so feel free to merge the other two. Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
Dear Jon Smirl, In message 9e4733910904201706u58387d5fod231dd4b8ac88...@mail.gmail.com you wrote: Everyone will know the vendor of their board. You could alphabetize Really? So who is the board vendor for the MPC8360 board? Freescale or Logic PD? And who is the vendor for the ADS5121? Freescale or STX? Board names are much better, IMO. 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 We shall reach greater and greater platitudes of achievement. - Richard J. Daley ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
Dear Jon Smirl, In message 9e4733910904201712x68658ddfk3c18298deb82b...@mail.gmail.com you wrote: There are a lot of boards that could be moved into a vendor subdirs. I suspect we have less than 100 vendors. Maybe as few as 60. There is many vendors which have just a single board; also, there are vendors who prefer to remain anonymous for some reason. Just adding an additional directory level for a single entry does not make much sense to me. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de When the ax entered the forest, the trees said, The handle is one of us! -- Turkish proverb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build errors u-boot-v2 iMX27
-Original Message- From: saschaha...@web.de [mailto:saschaha...@web.de]on Behalf Of Sascha Hauer Sent: Monday, April 20, 2009 12:57 PM To: Bill Cook Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build errors u-boot-v2 iMX27 Hi Bill, On Mon, Apr 20, 2009 at 10:57:49AM -0400, Bill Cook wrote: Dear ML, I'm trying to build u-boot-v2 for an iMX27 based board. I'm getting a HW/SW floating point mismatch error and hope someone will point me to a solution. Building with: snip Error is: arm-eabi-ld: ERROR: arch/arm/lib/_ashldi3.o uses hardware FP, whereas arch/arm/lib/built-in.o uses software FP arm-eabi-ld: failed to merge target specific data of file arch/arm/lib/_ashldi3.o The source files are assembly, any C files have the -msoft-float compile option. What gives? All our toolchains produce soft float by default, so this does not show up here. U-Boot does not use floating point, so I think we do not have to care what the compiler produces. Does it help to remove the -msoft-float from arch/arm/Makefile? Yes, this did the trick, I knew it had to be something simple... Thanks. Bill Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANNOUNCE] Kconfig support
Dear Robert, just to put a few points right: In message 20090421070431.gx5...@pengutronix.de you wrote: So our intention was and is: 1. Wolfgang has a focus on stability and gradual changes. We respect this political position because it is a *good* one. This is not quite correct. What I consider important is an evo- lutionary path - this may include bigger changes and reorganizations, but I consider it a bad idea to not provide a reasonable migration path for larger parts of the existing community. 3. It was an active decision from our team *not* to fork and call it something else than U-Boot(-v2) when we started. We see that the U-Boot community is strong, it has long term aims and last but not least, it has a *great* bootloader. We talked to Wolfgang before doing so, and Wolfgang's position was in the spirit of go ahead, here is a git tree, and let the community decide. This is actually wrong. When we talked about these things, you had already performed a split, and had a up-and-running implementation behind your (kind of closed) doors. It was me who asked you to make this existing code openly available. What I missed, and what I still consider a big chance that was missed, is any public discussion about such a new design - before the actual work was started, or at least before such irrevocable decisions were made as not to consider any form of an upgrade path. 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 Anything free is worth what you pay for it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] environment variables crc
Dear Gerrit Van Damme, In message 49ed809d.5030...@mgb-tech.com you wrote: The saveenv command doesn't work for me because then the default env variables are stored and this is what I want to avoid. Then change the environment before running saveenv? Or even better - adjust the default environment so it matches your needs. What's the problem? It's already a good thing that I can see that the first 4 bytes really look like the CRC of the environment. So this was really helpfull info. Now you tell me it's calculated using the environment. In the source code I found the env variables crc calculated for a size of ENV_SIZE, but I was unable to see how it was defined. Do you have more info on this? Hmmm... grep is your friend. Is the environment data (for crc calculation) terminated by a certain char (or sequence of chars) ? No. Not for CRC calculation. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you want to eat hippopatomus, you've got to pay the freight. - attributed to an IBM guy, about why IBM software uses so much memory ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
There is many vendors which have just a single board; Like the ST nomadik8815 I maintain. Just adding an additional directory level for a single entry does not make much sense to me. So should we leave the nomadik as a single-entry vendor board or leave it as is? (more nomadik boards will be added over time, but none of them is in the queue nor will be in the foreseeable months) /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANNOUNCE] Kconfig support
On Tue, Apr 21, 2009 at 04:40:04PM +0200, Wolfgang Denk wrote: 1. Wolfgang has a focus on stability and gradual changes. We respect this political position because it is a *good* one. This is not quite correct. What I consider important is an evo- lutionary path - this may include bigger changes and reorganizations, but I consider it a bad idea to not provide a reasonable migration path for larger parts of the existing community. An evolutionary path in limited time is not possible when you want to change fundamental design issues. This is our oppinion, feel free to proove us wrong. 3. It was an active decision from our team *not* to fork and call it something else than U-Boot(-v2) when we started. We see that the U-Boot community is strong, it has long term aims and last but not least, it has a *great* bootloader. We talked to Wolfgang before doing so, and Wolfgang's position was in the spirit of go ahead, here is a git tree, and let the community decide. This is actually wrong. When we talked about these things, you had already performed a split, and had a up-and-running implementation behind your (kind of closed) doors. It was me who asked you to make this existing code openly available. Well, how do you think such things are going to happen? By starting with a big vapourware discussion? Come on. Someone has to show some code, and that's what we did. It is all GPL, so it is as much open or closed doors as anything else. What I missed, and what I still consider a big chance that was missed, is any public discussion about such a new design - before the actual work was started, or at least before such irrevocable decisions were made as not to consider any form of an upgrade path. Until now all we hear is whining about the design, while almost nobody has ever looked into the code. Could you elaborate? What would you like to see? What is there that you don't like? Please feel free to send patches if you have other ideas for v2. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] environment variables crc
Dear Wolgang Denk, Wolfgang Denk wrote: Dear Gerrit Van Damme, In message 49ed809d.5030...@mgb-tech.com you wrote: The saveenv command doesn't work for me because then the default env variables are stored and this is what I want to avoid. Then change the environment before running saveenv? Or even better - adjust the default environment so it matches your needs. What's the problem? Thing is I would like to bypass the Uboot commands. Maybe I'll explain my problem a little more detailed. We're using a taskit panelcard based on the Atmel at91sam9261. Atmel provides some boot assistant software (SAM-BA) which allows you to create images and clone them. Now we set up a complete system on the taskit and now we want to start cloning. We were succesfull on this part the only thing is the MAC address sits also in this flash image. We created a script which gets the original MAC address from the board. Inserts it in the flash image file and then writes it to the board. And then we got the CRC error because we didn't recalculate the CRC. We want to include the CRC calculation in our SAM-BA script so that everything is already set and we can skip the Uboot part. This is why I needed some specific info on the CRC calculation. But if I'm unable to calculate the CRC I'll have to go for a second (Uboot) script to set up the environment. But it wont be highly appreciated by our production team :-) It's already a good thing that I can see that the first 4 bytes really look like the CRC of the environment. So this was really helpfull info. Now you tell me it's calculated using the environment. In the source code I found the env variables crc calculated for a size of ENV_SIZE, but I was unable to see how it was defined. Do you have more info on this? Hmmm... grep is your friend. Indeed that's true... but only if you're already friends with Linux Is the environment data (for crc calculation) terminated by a certain char (or sequence of chars) ? No. Not for CRC calculation. Best regards, Wolfgang Denk Thanks for your answer Wolfgang Regards, Gerrit ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Enabling smc911x driver
I'm attempting to enable the smc911x driver for the overo omap3 board. Looking at the README and a couple of board config files, it seems that defining CONFIG_DRIVER_SMC911X, CONFIG_DRIVER_SMC911X_16_BIT (or 32_BIT), and CONFIG_DRIVER_SMC911X_BASE is all that is required. I have also enabled CONFIG_CMD_NET, CONFIG_CMD_DHCP and CONFIG_CMD_PING. The build completes successfully, but it seems that the driver init is never called, so I assume I am missing something. Do I need to add an explicit init call to my board or cpu file? At first glance I don't see that other boards are doing this. Thanks! Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
So should we leave the nomadik as a single-entry vendor board or leave it as is? Argh! I mean: leave it alone in its own vendor-dir or move it up one level? I got the idea vendor dirs were preferred anyway (as suggested by JC), but Wolfgang's last message suggests the opposite. Sorry for mistyping /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] OMAP3: Fix timer handling to 1ms and CONFIG_SYS_HZ to 1000
From: Manikandan Pillai mani.pil...@ti.com
Signed-off-by: Dirk Behme dirk.be...@googlemail.com
Signed-off-by: Manikandan Pillai mani.pil...@ti.com
---
Changes in v3 which replaces previous version [3]:
* Fix udelay(), too
* Fix and use TIMER_LOAD_VAL macro
* Rebase against mainline 7ee38c044ca5041d3378d6507580ea4ec344af96
'fix DaVinci NS16550_REG_SIZE regression'
Changes from Dirk's patch which is replaced by this [2]:
* Fix conflicts after commit 81472d893fa565c9d300928a40e504a689bde131
Changes from Mani's original patch which is replaced by this [1]:
* Don't remove overflow handling in get_timer_masked()
* Update omap3_zoom1.h, too.
* Clean up timer related comments and macros in config files
* Don't touch reset_timer_masked()
* Switch divider clock divider from 256 to 8 to be able to get 1000Hz
* Remove unused udelay_masked()
* Minor clean up of get_tbclk()
[1] http://lists.denx.de/pipermail/u-boot/2009-March/049012.html
[2] http://lists.denx.de/pipermail/u-boot/2009-March/049146.html
[3] http://lists.denx.de/pipermail/u-boot/2009-April/050170.html
---
cpu/arm_cortexa8/omap3/interrupts.c | 85 +++-
include/configs/omap3_beagle.h |9 ++-
include/configs/omap3_evm.h |9 ++-
include/configs/omap3_overo.h | 12 ++---
include/configs/omap3_pandora.h | 11 ++--
include/configs/omap3_zoom1.h | 11 ++--
6 files changed, 55 insertions(+), 82 deletions(-)
Index: u-boot-main/cpu/arm_cortexa8/omap3/interrupts.c
===
--- u-boot-main.orig/cpu/arm_cortexa8/omap3/interrupts.c
+++ u-boot-main/cpu/arm_cortexa8/omap3/interrupts.c
@@ -36,8 +36,6 @@
#include asm/io.h
#include asm/proc-armv/ptrace.h
-#define TIMER_LOAD_VAL 0
-
#ifdef CONFIG_USE_IRQ
/* enable IRQ interrupts */
void enable_interrupts(void)
@@ -169,7 +167,17 @@ static ulong timestamp;
static ulong lastinc;
static gptimer_t *timer_base = (gptimer_t *)CONFIG_SYS_TIMERBASE;
-/* nothing really to do with interrupts, just starts up a counter. */
+/*
+ * Nothing really to do with interrupts, just starts up a counter.
+ * We run the counter with 13MHz, divided by 8, resulting in timer
+ * frequency of 1.625MHz. With 32bit counter register, counter
+ * overflows in ~44min
+ */
+
+/* 13MHz / 8 = 1.625MHz */
+#define TIMER_CLOCK(V_SCLK / (2 CONFIG_SYS_PTV))
+#define TIMER_LOAD_VAL 0x
+
int interrupt_init(void)
{
/* start the counter ticking up, reload value on overflow */
@@ -201,81 +209,44 @@ void set_timer(ulong t)
timestamp = t;
}
-/* delay x useconds AND perserve advance timstamp value */
+/* delay x useconds */
void udelay(unsigned long usec)
{
- ulong tmo, tmp;
+ long tmo = usec * (TIMER_CLOCK / 1000) / 1000;
+ unsigned long now, last = readl(timer_base-tcrr);
- /* if big number, spread normalization to seconds */
- if (usec = 1000) {
- /* if big number, spread normalization to seconds */
- tmo = usec / 1000;
- /* find number of ticks to wait to achieve target */
- tmo *= CONFIG_SYS_HZ;
- tmo /= 1000;/* finish normalize. */
- } else {/* else small number, don't kill it prior to HZ multiply */
- tmo = usec * CONFIG_SYS_HZ;
- tmo /= (1000 * 1000);
+ while (tmo 0) {
+ now = readl(timer_base-tcrr);
+ if (last now) /* count up timer overflow */
+ tmo -= TIMER_LOAD_VAL - last + now;
+ else
+ tmo -= now - last;
+ last = now;
}
-
- tmp = get_timer(0); /* get current timestamp */
- /* if setting this forward will roll time stamp */
- if ((tmo + tmp + 1) tmp)
- /* reset advancing timestamp to 0, set lastinc value */
- reset_timer_masked();
- else
- tmo += tmp; /* else, set advancing stamp wake up time */
- while (get_timer_masked() tmo)/* loop till event */
-/*NOP*/;
}
void reset_timer_masked(void)
{
/* reset time, capture current incrementer value time */
- lastinc = readl(timer_base-tcrr);
+ lastinc = readl(timer_base-tcrr) / (TIMER_CLOCK / CONFIG_SYS_HZ);
timestamp = 0; /* start advancing time stamp from 0 */
}
ulong get_timer_masked(void)
{
- ulong now = readl(timer_base-tcrr); /* current tick value */
+ /* current tick value */
+ ulong now = readl(timer_base-tcrr) / (TIMER_CLOCK / CONFIG_SYS_HZ);
if (now = lastinc) /* normal mode (non roll) */
/* move stamp fordward with absoulte diff ticks */
timestamp += (now - lastinc);
else/* we have rollover of incrementer */
- timestamp += (0x - lastinc) + now;
+ timestamp += ((TIMER_LOAD_VAL / (TIMER_CLOCK / CONFIG_SYS_HZ))
[U-Boot] [PATCH] OMAP3: Fix changed mmc init command
In recent U-Boot mmcinit changed to mmc init.
Signed-off-by: Steve Sakoman st...@sakoman.com
Signed-off-by: Dirk Behme dirk.be...@googlemail.com
---
include/configs/omap3_beagle.h |2 +-
include/configs/omap3_evm.h |2 +-
include/configs/omap3_overo.h |2 +-
include/configs/omap3_pandora.h |2 +-
include/configs/omap3_zoom1.h |2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
Index: u-boot-main/include/configs/omap3_beagle.h
===
--- u-boot-main.orig/include/configs/omap3_beagle.h
+++ u-boot-main/include/configs/omap3_beagle.h
@@ -185,7 +185,7 @@
bootm ${loadaddr}\0 \
#define CONFIG_BOOTCOMMAND \
- if mmcinit; then \
+ if mmc init; then \
if run loadbootscript; then \
run bootscript; \
else \
Index: u-boot-main/include/configs/omap3_evm.h
===
--- u-boot-main.orig/include/configs/omap3_evm.h
+++ u-boot-main/include/configs/omap3_evm.h
@@ -178,7 +178,7 @@
bootm ${loadaddr}\0 \
#define CONFIG_BOOTCOMMAND \
- if mmcinit; then \
+ if mmc init; then \
if run loadbootscript; then \
run bootscript; \
else \
Index: u-boot-main/include/configs/omap3_overo.h
===
--- u-boot-main.orig/include/configs/omap3_overo.h
+++ u-boot-main/include/configs/omap3_overo.h
@@ -172,7 +172,7 @@
bootm ${loadaddr}\0 \
#define CONFIG_BOOTCOMMAND \
- if mmcinit; then \
+ if mmc init; then \
if run loadbootscript; then \
run bootscript; \
else \
Index: u-boot-main/include/configs/omap3_pandora.h
===
--- u-boot-main.orig/include/configs/omap3_pandora.h
+++ u-boot-main/include/configs/omap3_pandora.h
@@ -174,7 +174,7 @@
bootm ${loadaddr}\0 \
#define CONFIG_BOOTCOMMAND \
- if mmcinit; then \
+ if mmc init; then \
if run loadbootscript; then \
run bootscript; \
else \
Index: u-boot-main/include/configs/omap3_zoom1.h
===
--- u-boot-main.orig/include/configs/omap3_zoom1.h
+++ u-boot-main/include/configs/omap3_zoom1.h
@@ -182,7 +182,7 @@
bootm ${loadaddr}\0 \
#define CONFIG_BOOTCOMMAND \
- if mmcinit; then \
+ if mmc init; then \
if run loadbootscript; then \
run bootscript; \
else \
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
On Tue, Apr 21, 2009 at 10:25 AM, Wolfgang Denk w...@denx.de wrote: Dear Jon Smirl, In message 9e4733910904201706u58387d5fod231dd4b8ac88...@mail.gmail.com you wrote: Everyone will know the vendor of their board. You could alphabetize Really? So who is the board vendor for the MPC8360 board? Freescale or Logic PD? And who is the vendor for the ADS5121? Freescale or STX? Read the box when you take the board out. -- Jon Smirl jonsm...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm925t: Fix CONFIG_SYS_HZ to 1000
Dear Ladis,
Ladislav Michl wrote:
On Mon, Apr 20, 2009 at 08:27:34PM +0200, Dirk Behme wrote:
Dear Ladis,
ah, and some remarks on the patch itself ;)
Thanks, I'm glad someone still cares about ancient stuff.
Ladislav Michl wrote:
Let CONFIG_SYS_HZ to have value of 1000 effectively fixing all users of
get_timer.
Signed-off-by: Ladislav Michl la...@linux-mips.org
diff --git a/cpu/arm925t/interrupts.c b/cpu/arm925t/interrupts.c
index e5c77f7..a22be66 100644
--- a/cpu/arm925t/interrupts.c
+++ b/cpu/arm925t/interrupts.c
...
-#define TIMER_LOAD_VAL 0x
+#define TIMER_LOAD_VAL 0x
+#define TIMER_CLOCK(CONFIG_SYS_CLK_FREQ / (2 CONFIG_SYS_PTV))
Just to get an idea of the math:
CONFIG_SYS_CLK_FREQ is 1200 (12MHz)? This is divided by 256, so
TIMER_CLOCK is 46875Hz? A free running 32-bit count down timer is used
starting at 0x? Underflow (0) is reached after ~91626s ==
~25hours with this?
Please correct if something is wrong ;)
Math is perfectly correct, except in my case CONFIG_SYS_CLK_FREQ is 150MHz,
so resolution is actually 12.5 times better.
Ok. Is this 150MHz defined in one of the configs you modify with this
patch or do you use a custom config? Just curious ;)
Perhaps I should modify those
boards wich uses 12MHz clock to use smaller divisor,
Yes, this should be easily doable by changing CONFIG_SYS_PTV.
but let's wait for more
comments first.
I hope there will be some ;)
-/* delay x useconds AND preserve advance timestamp value */
+/* delay usec microseconds preserving timestamp value */
Hmm, 'usec microseconds' sounds somehow confusing?
It depends. 'usec' is obviously variable name and 'microsecond' is a time
unit, while 'x' is unreferenced variable and 'usec' is abbreviation.
And I prefer former (or deleting that part of comment entirely).
void udelay (unsigned long usec)
{
...
+ int32_t tmo = usec * (TIMER_CLOCK / 1000) / 1000;
+ uint32_t now, last = __raw_readl(CONFIG_SYS_TIMERBASE + READ_TIM);
The first '1000' should be CONFIG_SYS_HZ? I.e.
No. Actually it should read 'usec * (TIMER_CLOCK / (1000 * 1000))', where
one '1000' is to get miliseconds and other brings you to microseconds
digit place. But integer math needs former writing.
Ok, understood. Thanks for the hint!
(TIMER_CLOCK / CONFIG_SYS_HZ) / 1000;
?
In my udelay patch, I use
+tmo = usec * (TIMER_CLOCK / CONFIG_SYS_HZ);
+tmo /= 1000;
From some printf debugging, for OMAP3 there was a difference doing it in
one or two lines. If I remember correctly due to integer vs floating
point math and rounding. What do you think?
I think all that udelay code is pointless once CONFIG_SYS_HZ always
_have_ to be 1000 and can be simplyfied.
Running OMAP3 counter with 1.625MHz, max udelay resolution is ~1.62us.
If you run with 46875Hz, you have max udelay resolution of ~22us?
See above, it is ~1.7us.
+ while (tmo 0) {
+ now = __raw_readl(CONFIG_SYS_TIMERBASE + READ_TIM);
+ if (last now) /* count down timer underflow */
+ tmo -= TIMER_LOAD_VAL - now + last;
+ else
+ tmo -= last - now;
+ last = now;
I will think about this, I always need some time for this clock math ;)
In contrast to OMAP3 your timer here counts down, right? So while OMAP1
has to deal with underflow, OMAP3 will need overflow handling, right?
Right, but the key point here is to unbind udelay from get_timer as now
get_timer works with miliseconds resolution.
I hope I got it right with the updated patch sent some minutes ago.
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
Jon Smirl wrote: My vote would be to require all boards in the board/ directory to be in a vendor directory. When you buy the board it is pretty obvious from the accompanying packaging/manuals who the vendor is. Companies and product lines get bought, names change... IMHO, architecture (selected by kconfig, not ARCH=) and CPU family are a more robust and managable way of sorting the menu -- and would be familiar to those used to configuring Linux. We could still pull in a defconfig from the command line based on a board name alone (in addition to the search functionality you mention). This would also assign some responsibility to the vendor to maintain the subdirectory for their products. Assuming the vendor cares. :-) -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] OMAP3: Print correct silicon revision
The function display_board_info() displays the silicon
revision as 2 - based on the return value from get_cpu_rev().
This is incorrect as the current Si version is 3.1
This patch displays the correct version; but does not
change get_cpu_rev() to minimize the code impact.
Signed-off-by: Sanjeev Premi pr...@ti.com
---
cpu/arm_cortexa8/omap3/sys_info.c | 37 +++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index b385b91..8c6a4d6 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -36,6 +36,8 @@ static gpmc_csx_t *gpmc_cs_base = (gpmc_csx_t
*)GPMC_CONFIG_CS0_BASE;
static sdrc_t *sdrc_base = (sdrc_t *)OMAP34XX_SDRC_BASE;
static ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
+static char omap_revision[8] = ;
+
/*
* dieid_num_r(void) - read and set die ID
*/
@@ -90,6 +92,36 @@ u32 get_cpu_rev(void)
}
+/**
+ * Converts cpu revision into a string
+ */
+void set_omap_revision(void)
+{
+ u32 idcode;
+ ctrl_id_t *id_base;
+ char *str_rev = omap_revision[0];
+
+ if (get_cpu_rev() == CPU_3430_ES1) {
+ strcat (str_rev, ES1.0);
+ }
+ else {
+ id_base = (ctrl_id_t *)OMAP34XX_ID_L4_IO_BASE;
+
+ idcode = readl(id_base-idcode);
+
+ if (idcode == 0x1B7AE02F)
+ strcat (str_rev, ES2.0);
+ else if (idcode == 0x2B7AE02F)
+ strcat (str_rev, ES2.1);
+ else if (idcode == 0x3B7AE02F)
+ strcat (str_rev, ES3.0);
+ else if (idcode == 0x4B7AE02F)
+ strcat (str_rev, ES3.1);
+ else
+ strcat (str_rev, ES??);
+ }
+}
+
/
* is_mem_sdr() - return 1 if mem type in use is SDR
/
@@ -232,9 +264,10 @@ void display_board_info(u32 btype)
sec_s = ?;
}
+ set_omap_revision();
- printf(OMAP%s-%s rev %d, CPU-OPP2 L3-165MHz\n, cpu_s,
- sec_s, get_cpu_rev());
+ printf(OMAP%s-%s (%s), CPU-OPP2 L3-165MHz\n, cpu_s,
+ sec_s, omap_revision);
printf(%s + %s/%s\n, sysinfo.board_string,
mem_s, sysinfo.nand_string);
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Enabling smc911x driver
Steve, Steve Sakoman wrote: I'm attempting to enable the smc911x driver for the overo omap3 board. Looking at the README and a couple of board config files, it seems that defining CONFIG_DRIVER_SMC911X, CONFIG_DRIVER_SMC911X_16_BIT (or 32_BIT), and CONFIG_DRIVER_SMC911X_BASE is all that is required. I have also enabled CONFIG_CMD_NET, CONFIG_CMD_DHCP and CONFIG_CMD_PING. The build completes successfully, but it seems that the driver init is never called, so I assume I am missing something. Do I need to add an explicit init call to my board or cpu file? At first glance I don't see that other boards are doing this. This driver uses the old-style API and so requires board/cpu init code to call eth_init(). I'm not familiar with your architecture, so don't know how or if this is implemented, but it should be easy to find another example that does this. Thanks! Steve regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
Dear Premi,
Sanjeev Premi wrote:
The function display_board_info() displays the silicon
revision as 2 - based on the return value from get_cpu_rev().
This is incorrect as the current Si version is 3.1
Thanks for the patch and fixing this!
This patch displays the correct version; but does not
change get_cpu_rev() to minimize the code impact.
I wonder if it wouldn't be better (and cleaner) to fix get_cpu_rev()?
A quick grep resulted in 5 (?) locations which might be affected:
./cpu/arm_cortexa8/cpu.c:104: if (get_cpu_rev() == CPU_3430_ES2) {
./cpu/arm_cortexa8/cpu.c:134: if (get_cpu_rev() == CPU_3430_ES2) {
./cpu/arm_cortexa8/omap3/clock.c:173: sil_index = get_cpu_rev() - 1;
./cpu/arm_cortexa8/omap3/sys_info.c:144:if (get_cpu_rev() ==
CPU_3430_ES2)
./cpu/arm_cortexa8/omap3/sys_info.c:237: sec_s,
get_cpu_rev());
If we extend the existing macros
#define CPU_3430_ES11
#define CPU_3430_ES22
to e.g.
#define CPU_3430_ES10 1
#define CPU_3430_ES20 2
#define CPU_3430_ES21 3
#define CPU_3430_ES30 4
#define CPU_3430_ES31 5
then the three
== CPU_3430_ES2
will simply become
= CPU_3430_ES20
The sil_index = get_cpu_rev() - 1; needs a deeper look, though.
Regarding the ASCII strings: With the numbers get_cpu_rev() returns
we then could index a const struct with the ASCII strings for the
revision print. E.g.
printf( ... %s ..., ... omap_revision[get_cpu_rev()] ...);
What do you think?
Signed-off-by: Sanjeev Premi pr...@ti.com
---
cpu/arm_cortexa8/omap3/sys_info.c | 37
+++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index b385b91..8c6a4d6 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -36,6 +36,8 @@ static gpmc_csx_t *gpmc_cs_base = (gpmc_csx_t
*)GPMC_CONFIG_CS0_BASE;
static sdrc_t *sdrc_base = (sdrc_t *)OMAP34XX_SDRC_BASE;
static ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
+static char omap_revision[8] = ;
+
/*
* dieid_num_r(void) - read and set die ID
*/
@@ -90,6 +92,36 @@ u32 get_cpu_rev(void)
}
+/**
+ * Converts cpu revision into a string
+ */
+void set_omap_revision(void)
+{
+ u32 idcode;
+ ctrl_id_t *id_base;
+ char *str_rev = omap_revision[0];
+
+ if (get_cpu_rev() == CPU_3430_ES1) {
+ strcat (str_rev, ES1.0);
+ }
+ else {
+ id_base = (ctrl_id_t *)OMAP34XX_ID_L4_IO_BASE;
+
+ idcode = readl(id_base-idcode);
+
+ if (idcode == 0x1B7AE02F)
+ strcat (str_rev, ES2.0);
+ else if (idcode == 0x2B7AE02F)
+ strcat (str_rev, ES2.1);
+ else if (idcode == 0x3B7AE02F)
+ strcat (str_rev, ES3.0);
+ else if (idcode == 0x4B7AE02F)
It looks to me that only the highest nibble of idcode changes here?
Maybe we could better mask shift it a little and create a nice macro
for it?
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Tuesday, April 21, 2009 10:26 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
Dear Premi,
Sanjeev Premi wrote:
The function display_board_info() displays the silicon
revision as 2 - based on the return value from get_cpu_rev().
This is incorrect as the current Si version is 3.1
Thanks for the patch and fixing this!
This patch displays the correct version; but does not
change get_cpu_rev() to minimize the code impact.
I wonder if it wouldn't be better (and cleaner) to fix get_cpu_rev()?
Yes. This is what I started with; but then this is where I felt that
fix may run 'deeper
u32 get_board_type(void)
{
if (get_cpu_rev() == CPU_3430_ES2)
return sysinfo.board_type_v2;
else
return sysinfo.board_type_v1;
}
I couldn't figure out how this impacts boards other than the EVM.
A quick grep resulted in 5 (?) locations which might be affected:
./cpu/arm_cortexa8/cpu.c:104: if (get_cpu_rev() == CPU_3430_ES2) {
./cpu/arm_cortexa8/cpu.c:134: if (get_cpu_rev() == CPU_3430_ES2) {
./cpu/arm_cortexa8/omap3/clock.c:173: sil_index =
get_cpu_rev() - 1;
./cpu/arm_cortexa8/omap3/sys_info.c:144:if (get_cpu_rev() ==
CPU_3430_ES2)
./cpu/arm_cortexa8/omap3/sys_info.c:237: sec_s,
get_cpu_rev());
If we extend the existing macros
#define CPU_3430_ES1 1
#define CPU_3430_ES2 2
to e.g.
#define CPU_3430_ES10 1
#define CPU_3430_ES20 2
#define CPU_3430_ES21 3
#define CPU_3430_ES30 4
#define CPU_3430_ES31 5
then the three
== CPU_3430_ES2
will simply become
= CPU_3430_ES20
The sil_index = get_cpu_rev() - 1; needs a deeper look, though.
Regarding the ASCII strings: With the numbers get_cpu_rev() returns
we then could index a const struct with the ASCII strings for the
revision print. E.g.
printf( ... %s ..., ... omap_revision[get_cpu_rev()] ...);
What do you think?
Signed-off-by: Sanjeev Premi pr...@ti.com
---
cpu/arm_cortexa8/omap3/sys_info.c | 37
+++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index b385b91..8c6a4d6 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -36,6 +36,8 @@ static gpmc_csx_t *gpmc_cs_base =
(gpmc_csx_t *)GPMC_CONFIG_CS0_BASE;
static sdrc_t *sdrc_base = (sdrc_t *)OMAP34XX_SDRC_BASE;
static ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
+static char omap_revision[8] = ;
+
/*
* dieid_num_r(void) - read and set die ID
*/
@@ -90,6 +92,36 @@ u32 get_cpu_rev(void)
}
+/**
+ * Converts cpu revision into a string
+ */
+void set_omap_revision(void)
+{
+ u32 idcode;
+ ctrl_id_t *id_base;
+ char *str_rev = omap_revision[0];
+
+ if (get_cpu_rev() == CPU_3430_ES1) {
+ strcat (str_rev, ES1.0);
+ }
+ else {
+ id_base = (ctrl_id_t *)OMAP34XX_ID_L4_IO_BASE;
+
+ idcode = readl(id_base-idcode);
+
+ if (idcode == 0x1B7AE02F)
+ strcat (str_rev, ES2.0);
+ else if (idcode == 0x2B7AE02F)
+ strcat (str_rev, ES2.1);
+ else if (idcode == 0x3B7AE02F)
+ strcat (str_rev, ES3.0);
+ else if (idcode == 0x4B7AE02F)
It looks to me that only the highest nibble of idcode changes here?
Maybe we could better mask shift it a little and create a
nice macro
for it?
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANNOUNCE] Kconfig support
On Tue, Apr 21, 2009 at 04:40:04PM +0200, Wolfgang Denk wrote: Dear Robert, just to put a few points right: In message 20090421070431.gx5...@pengutronix.de you wrote: So our intention was and is: 1. Wolfgang has a focus on stability and gradual changes. We respect this political position because it is a *good* one. This is not quite correct. What I consider important is an evo- lutionary path - this may include bigger changes and reorganizations, but I consider it a bad idea to not provide a reasonable migration path for larger parts of the existing community. Then start proving your point by removing CONFIG_NET_MULTI. U-Boot carries two incompatible network driver APIs for at least the last seven years and still 19 drivers have not switched to the new API. It was exactly this kind of stagnation that made me fork U-Boot. I was really tired of this ongoing no, please don't break existing code. And honestly, I was so blinded by ifdefs that I couldn't even see what the existing code was. So I started hacking on U-Boot in my spare time, not knowing where this would lead, but I must admit that it was really fun to remove everything which I didn't know for what it was good for. You'd be surprised to see how much dead code hides in U-Boot. Additionally I wanted to see what's possible. Is it possible to integrate a driver model without adding much binary space? Is it possible to create a filesystem layer in this limited space? You see I was in a hacking mood and not in a discuss-on-mailing-lists mood. What would have happened if I posted a I want a driver model mail on the list? Probably one of the first answers would have been U-Boot is about size and simplicity. Some mails later I probably would have gone back to business as usual. Even if I tried to integrate a driver model into current U-Boot, how long would it take till all drivers make use of it given the fact that a simple thing like CONFIG_NET_MULTI stays for seven years? I started this for fun, but I think integrating a driver model into U-Boot without breaking existing stuff is no fun at all and I'm pretty sure none of our customers would have payed us for working on this topic. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
Premi, Sanjeev wrote:
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Tuesday, April 21, 2009 10:26 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
Dear Premi,
Sanjeev Premi wrote:
The function display_board_info() displays the silicon
revision as 2 - based on the return value from get_cpu_rev().
This is incorrect as the current Si version is 3.1
Thanks for the patch and fixing this!
This patch displays the correct version; but does not
change get_cpu_rev() to minimize the code impact.
I wonder if it wouldn't be better (and cleaner) to fix get_cpu_rev()?
Yes. This is what I started with; but then this is where I felt that
fix may run 'deeper
u32 get_board_type(void)
{
if (get_cpu_rev() == CPU_3430_ES2)
return sysinfo.board_type_v2;
else
return sysinfo.board_type_v1;
}
I couldn't figure out how this impacts boards other than the EVM.
Maybe I missed something, but independent of what this function does,
if we replace
if (get_cpu_rev() == CPU_3430_ES2)
with
if (get_cpu_rev() = CPU_3430_ES20)
the functionality of this function (i.e. the value returned) wouldn't
change compared to what it actually returns?
Best regards
Dirk
A quick grep resulted in 5 (?) locations which might be affected:
./cpu/arm_cortexa8/cpu.c:104: if (get_cpu_rev() == CPU_3430_ES2) {
./cpu/arm_cortexa8/cpu.c:134: if (get_cpu_rev() == CPU_3430_ES2) {
./cpu/arm_cortexa8/omap3/clock.c:173: sil_index =
get_cpu_rev() - 1;
./cpu/arm_cortexa8/omap3/sys_info.c:144:if (get_cpu_rev() ==
CPU_3430_ES2)
./cpu/arm_cortexa8/omap3/sys_info.c:237: sec_s,
get_cpu_rev());
If we extend the existing macros
#define CPU_3430_ES1 1
#define CPU_3430_ES2 2
to e.g.
#define CPU_3430_ES101
#define CPU_3430_ES202
#define CPU_3430_ES213
#define CPU_3430_ES304
#define CPU_3430_ES315
then the three
== CPU_3430_ES2
will simply become
= CPU_3430_ES20
The sil_index = get_cpu_rev() - 1; needs a deeper look, though.
Regarding the ASCII strings: With the numbers get_cpu_rev() returns
we then could index a const struct with the ASCII strings for the
revision print. E.g.
printf( ... %s ..., ... omap_revision[get_cpu_rev()] ...);
What do you think?
Signed-off-by: Sanjeev Premi pr...@ti.com
---
cpu/arm_cortexa8/omap3/sys_info.c | 37
+++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index b385b91..8c6a4d6 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -36,6 +36,8 @@ static gpmc_csx_t *gpmc_cs_base =
(gpmc_csx_t *)GPMC_CONFIG_CS0_BASE;
static sdrc_t *sdrc_base = (sdrc_t *)OMAP34XX_SDRC_BASE;
static ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
+static char omap_revision[8] = ;
+
/*
* dieid_num_r(void) - read and set die ID
*/
@@ -90,6 +92,36 @@ u32 get_cpu_rev(void)
}
+/**
+ * Converts cpu revision into a string
+ */
+void set_omap_revision(void)
+{
+ u32 idcode;
+ ctrl_id_t *id_base;
+ char *str_rev = omap_revision[0];
+
+ if (get_cpu_rev() == CPU_3430_ES1) {
+ strcat (str_rev, ES1.0);
+ }
+ else {
+ id_base = (ctrl_id_t *)OMAP34XX_ID_L4_IO_BASE;
+
+ idcode = readl(id_base-idcode);
+
+ if (idcode == 0x1B7AE02F)
+ strcat (str_rev, ES2.0);
+ else if (idcode == 0x2B7AE02F)
+ strcat (str_rev, ES2.1);
+ else if (idcode == 0x3B7AE02F)
+ strcat (str_rev, ES3.0);
+ else if (idcode == 0x4B7AE02F)
It looks to me that only the highest nibble of idcode changes here?
Maybe we could better mask shift it a little and create a
nice macro
for it?
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB key not recognized
Hello, I am using Atmel AT91SAM9263-EK and running u-boot 1.1.5, it fails to recognize a USB key of size 1GB and formatted in FAT. Yep, known problem. This is what is happening: U-boot usb start (Re)start USB... USB: scanning bus for devices... USB device not responding, giving up (status=20) 2 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found I have tried U-boot version 1.3.4 and see the same issue. I am using U-boot from the linux demo that came with the atmel kit. Please, move to the latest release (e.g. 2009.03), it has a lot of problems solved with USB and sam926x. (Notice also that the Atmel kit provides bootstrap code with a PLLB configured wrong for sam9263, which is solved in latest U-boot releases as well) Kind Regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
-Original Message-
From: Premi, Sanjeev
Sent: Tuesday, April 21, 2009 11:37 PM
To: 'Dirk Behme'
Cc: u-boot@lists.denx.de
Subject: RE: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Tuesday, April 21, 2009 10:26 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
Dear Premi,
Sanjeev Premi wrote:
The function display_board_info() displays the silicon
revision as 2 - based on the return value from get_cpu_rev().
This is incorrect as the current Si version is 3.1
Thanks for the patch and fixing this!
This patch displays the correct version; but does not
change get_cpu_rev() to minimize the code impact.
I wonder if it wouldn't be better (and cleaner) to fix
get_cpu_rev()?
Yes. This is what I started with; but then this is where I felt that
fix may run 'deeper
u32 get_board_type(void)
{
if (get_cpu_rev() == CPU_3430_ES2)
return sysinfo.board_type_v2;
else
return sysinfo.board_type_v1;
}
...sorry, mail 'went' before I wanted to!
I couldn't figure out how this impacts boards other than the EVM.
Though I admit not having much time looking for the impact. Beyond
this, I believe the fix could be straight forward.
A quick grep resulted in 5 (?) locations which might be affected:
./cpu/arm_cortexa8/cpu.c:104: if (get_cpu_rev() ==
CPU_3430_ES2) {
./cpu/arm_cortexa8/cpu.c:134: if (get_cpu_rev() ==
CPU_3430_ES2) {
./cpu/arm_cortexa8/omap3/clock.c:173: sil_index =
get_cpu_rev() - 1;
./cpu/arm_cortexa8/omap3/sys_info.c:144:if
(get_cpu_rev() ==
CPU_3430_ES2)
./cpu/arm_cortexa8/omap3/sys_info.c:237: sec_s,
get_cpu_rev());
If we extend the existing macros
#define CPU_3430_ES11
#define CPU_3430_ES22
to e.g.
#define CPU_3430_ES10 1
#define CPU_3430_ES20 2
#define CPU_3430_ES21 3
#define CPU_3430_ES30 4
#define CPU_3430_ES31 5
then the three
== CPU_3430_ES2
will simply become
= CPU_3430_ES20
There seems to be a slight differene between the silicon
revision between 34x and 35x for the highest nibble value
for early si revs - ES 1.0 and ES2.0.
The sil_index = get_cpu_rev() - 1; needs a deeper look, though.
Regarding the ASCII strings: With the numbers get_cpu_rev()
returns
we then could index a const struct with the ASCII strings for the
revision print. E.g.
printf( ... %s ..., ... omap_revision[get_cpu_rev()] ...);
What do you think?
Signed-off-by: Sanjeev Premi pr...@ti.com
---
cpu/arm_cortexa8/omap3/sys_info.c | 37
+++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index b385b91..8c6a4d6 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -36,6 +36,8 @@ static gpmc_csx_t *gpmc_cs_base =
(gpmc_csx_t *)GPMC_CONFIG_CS0_BASE;
static sdrc_t *sdrc_base = (sdrc_t *)OMAP34XX_SDRC_BASE;
static ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
+static char omap_revision[8] = ;
+
/*
* dieid_num_r(void) - read and set die ID
*/
@@ -90,6 +92,36 @@ u32 get_cpu_rev(void)
}
+/**
+ * Converts cpu revision into a string
+ */
+void set_omap_revision(void)
+{
+ u32 idcode;
+ ctrl_id_t *id_base;
+ char *str_rev = omap_revision[0];
+
+ if (get_cpu_rev() == CPU_3430_ES1) {
+ strcat (str_rev, ES1.0);
+ }
+ else {
+ id_base = (ctrl_id_t *)OMAP34XX_ID_L4_IO_BASE;
+
+ idcode = readl(id_base-idcode);
+
+ if (idcode == 0x1B7AE02F)
+ strcat (str_rev, ES2.0);
+ else if (idcode == 0x2B7AE02F)
+ strcat (str_rev, ES2.1);
+ else if (idcode == 0x3B7AE02F)
+ strcat (str_rev, ES3.0);
+ else if (idcode == 0x4B7AE02F)
It looks to me that only the highest nibble of idcode changes here?
Maybe we could better mask shift it a little and create a
nice macro
for it?
It is already done in the kernel; but I am not sure if we could save
much - unless we use the index as you suggest above.
Best regards
Dirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB key not recognized
Thanks for replying, Remy. I appreciate it. I just downloaded, built and used U-boot version 2009.03. It does see the USB key now. U-Boot usb start (Re)start USB... USB: scanning bus for devices... 2 USB Device(s) found scanning bus for storage devices... 1 Storage Device(s) found Another question - How can I boot from this USB key. Can I put Debian 5.0 Lenny image on USB key and boot AT91SAM9263-EK from there? If yes, how would I do it? I am new to Linux. Many thanks for your help. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
Dear Premi,
Premi, Sanjeev wrote:
-Original Message-
From: Premi, Sanjeev
Sent: Tuesday, April 21, 2009 11:37 PM
To: 'Dirk Behme'
Cc: u-boot@lists.denx.de
Subject: RE: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Tuesday, April 21, 2009 10:26 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
Dear Premi,
Sanjeev Premi wrote:
The function display_board_info() displays the silicon
revision as 2 - based on the return value from get_cpu_rev().
This is incorrect as the current Si version is 3.1
Thanks for the patch and fixing this!
This patch displays the correct version; but does not
change get_cpu_rev() to minimize the code impact.
I wonder if it wouldn't be better (and cleaner) to fix
get_cpu_rev()?
Yes. This is what I started with; but then this is where I felt that
fix may run 'deeper
u32 get_board_type(void)
{
if (get_cpu_rev() == CPU_3430_ES2)
return sysinfo.board_type_v2;
else
return sysinfo.board_type_v1;
}
...sorry, mail 'went' before I wanted to!
I couldn't figure out how this impacts boards other than the EVM.
Though I admit not having much time looking for the impact. Beyond
this, I believe the fix could be straight forward.
What's about something like in the attachment? Compile tested only. Do
you like to test it?
Best regards
Dirk
A quick grep resulted in 5 (?) locations which might be affected:
./cpu/arm_cortexa8/cpu.c:104: if (get_cpu_rev() ==
CPU_3430_ES2) {
./cpu/arm_cortexa8/cpu.c:134: if (get_cpu_rev() ==
CPU_3430_ES2) {
./cpu/arm_cortexa8/omap3/clock.c:173: sil_index =
get_cpu_rev() - 1;
./cpu/arm_cortexa8/omap3/sys_info.c:144:if
(get_cpu_rev() ==
CPU_3430_ES2)
./cpu/arm_cortexa8/omap3/sys_info.c:237: sec_s,
get_cpu_rev());
If we extend the existing macros
#define CPU_3430_ES11
#define CPU_3430_ES22
to e.g.
#define CPU_3430_ES10 1
#define CPU_3430_ES20 2
#define CPU_3430_ES21 3
#define CPU_3430_ES30 4
#define CPU_3430_ES31 5
then the three
== CPU_3430_ES2
will simply become
= CPU_3430_ES20
There seems to be a slight differene between the silicon
revision between 34x and 35x for the highest nibble value
for early si revs - ES 1.0 and ES2.0.
The sil_index = get_cpu_rev() - 1; needs a deeper look, though.
Regarding the ASCII strings: With the numbers get_cpu_rev()
returns
we then could index a const struct with the ASCII strings for the
revision print. E.g.
printf( ... %s ..., ... omap_revision[get_cpu_rev()] ...);
What do you think?
Signed-off-by: Sanjeev Premi pr...@ti.com
---
cpu/arm_cortexa8/omap3/sys_info.c | 37
+++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index b385b91..8c6a4d6 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -36,6 +36,8 @@ static gpmc_csx_t *gpmc_cs_base =
(gpmc_csx_t *)GPMC_CONFIG_CS0_BASE;
static sdrc_t *sdrc_base = (sdrc_t *)OMAP34XX_SDRC_BASE;
static ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
+static char omap_revision[8] = ;
+
/*
* dieid_num_r(void) - read and set die ID
*/
@@ -90,6 +92,36 @@ u32 get_cpu_rev(void)
}
+/**
+ * Converts cpu revision into a string
+ */
+void set_omap_revision(void)
+{
+ u32 idcode;
+ ctrl_id_t *id_base;
+ char *str_rev = omap_revision[0];
+
+ if (get_cpu_rev() == CPU_3430_ES1) {
+ strcat (str_rev, ES1.0);
+ }
+ else {
+ id_base = (ctrl_id_t *)OMAP34XX_ID_L4_IO_BASE;
+
+ idcode = readl(id_base-idcode);
+
+ if (idcode == 0x1B7AE02F)
+ strcat (str_rev, ES2.0);
+ else if (idcode == 0x2B7AE02F)
+ strcat (str_rev, ES2.1);
+ else if (idcode == 0x3B7AE02F)
+ strcat (str_rev, ES3.0);
+ else if (idcode == 0x4B7AE02F)
It looks to me that only the highest nibble of idcode changes here?
Maybe we could better mask shift it a little and create a
nice macro
for it?
It is already done in the kernel; but I am not sure if we could save
much - unless we use the index as you suggest above.
Best regards
Dirk
Signed-off-by: Dirk Behme dirk.be...@googlemail.com
---
cpu/arm_cortexa8/cpu.c |4 ++--
cpu/arm_cortexa8/omap3/clock.c |5 +++--
cpu/arm_cortexa8/omap3/sys_info.c | 31 +++
include/asm-arm/arch-omap3/omap3.h | 10 --
4 files changed, 36 insertions(+), 14
Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Wednesday, April 22, 2009 1:04 AM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
Dear Premi,
Premi, Sanjeev wrote:
-Original Message-
From: Premi, Sanjeev
Sent: Tuesday, April 21, 2009 11:37 PM
To: 'Dirk Behme'
Cc: u-boot@lists.denx.de
Subject: RE: [U-Boot] [PATCH] OMAP3: Print correct silicon revision
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Tuesday, April 21, 2009 10:26 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] OMAP3: Print correct
silicon revision
Dear Premi,
Sanjeev Premi wrote:
The function display_board_info() displays the silicon
revision as 2 - based on the return value from get_cpu_rev().
This is incorrect as the current Si version is 3.1
Thanks for the patch and fixing this!
This patch displays the correct version; but does not
change get_cpu_rev() to minimize the code impact.
I wonder if it wouldn't be better (and cleaner) to fix
get_cpu_rev()?
Yes. This is what I started with; but then this is where I
felt that
fix may run 'deeper
u32 get_board_type(void)
{
if (get_cpu_rev() == CPU_3430_ES2)
return sysinfo.board_type_v2;
else
return sysinfo.board_type_v1;
}
...sorry, mail 'went' before I wanted to!
I couldn't figure out how this impacts boards other than the EVM.
Though I admit not having much time looking for the impact. Beyond
this, I believe the fix could be straight forward.
What's about something like in the attachment? Compile tested
only. Do
you like to test it?
Sure. Will do it in the morning...
I did make few changes since your last mail as well.
Will post the updates later in the day.
~sanjeev
Best regards
Dirk
A quick grep resulted in 5 (?) locations which might be affected:
./cpu/arm_cortexa8/cpu.c:104: if (get_cpu_rev() ==
CPU_3430_ES2) {
./cpu/arm_cortexa8/cpu.c:134: if (get_cpu_rev() ==
CPU_3430_ES2) {
./cpu/arm_cortexa8/omap3/clock.c:173: sil_index =
get_cpu_rev() - 1;
./cpu/arm_cortexa8/omap3/sys_info.c:144:if
(get_cpu_rev() ==
CPU_3430_ES2)
./cpu/arm_cortexa8/omap3/sys_info.c:237: sec_s,
get_cpu_rev());
If we extend the existing macros
#define CPU_3430_ES1 1
#define CPU_3430_ES2 2
to e.g.
#define CPU_3430_ES10 1
#define CPU_3430_ES20 2
#define CPU_3430_ES21 3
#define CPU_3430_ES30 4
#define CPU_3430_ES31 5
then the three
== CPU_3430_ES2
will simply become
= CPU_3430_ES20
There seems to be a slight differene between the silicon
revision between 34x and 35x for the highest nibble value
for early si revs - ES 1.0 and ES2.0.
The sil_index = get_cpu_rev() - 1; needs a deeper look, though.
Regarding the ASCII strings: With the numbers get_cpu_rev()
returns
we then could index a const struct with the ASCII strings for the
revision print. E.g.
printf( ... %s ..., ... omap_revision[get_cpu_rev()] ...);
What do you think?
Signed-off-by: Sanjeev Premi pr...@ti.com
---
cpu/arm_cortexa8/omap3/sys_info.c | 37
+++--
1 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/cpu/arm_cortexa8/omap3/sys_info.c
b/cpu/arm_cortexa8/omap3/sys_info.c
index b385b91..8c6a4d6 100644
--- a/cpu/arm_cortexa8/omap3/sys_info.c
+++ b/cpu/arm_cortexa8/omap3/sys_info.c
@@ -36,6 +36,8 @@ static gpmc_csx_t *gpmc_cs_base =
(gpmc_csx_t *)GPMC_CONFIG_CS0_BASE;
static sdrc_t *sdrc_base = (sdrc_t *)OMAP34XX_SDRC_BASE;
static ctrl_t *ctrl_base = (ctrl_t *)OMAP34XX_CTRL_BASE;
+static char omap_revision[8] = ;
+
/*
* dieid_num_r(void) - read and set die ID
*/
@@ -90,6 +92,36 @@ u32 get_cpu_rev(void)
}
+/**
+ * Converts cpu revision into a string
+ */
+void set_omap_revision(void)
+{
+u32 idcode;
+ctrl_id_t *id_base;
+char *str_rev = omap_revision[0];
+
+if (get_cpu_rev() == CPU_3430_ES1) {
+strcat (str_rev, ES1.0);
+}
+else {
+id_base = (ctrl_id_t *)OMAP34XX_ID_L4_IO_BASE;
+
+idcode = readl(id_base-idcode);
+
+if (idcode == 0x1B7AE02F)
+strcat (str_rev, ES2.0);
+else if (idcode == 0x2B7AE02F)
+strcat (str_rev, ES2.1);
+else if (idcode == 0x3B7AE02F)
+strcat (str_rev, ES3.0);
+else if
Re: [U-Boot] Kconfig menu layout
Dear Jon Smirl, In message 9e4733910904210833u79f3d4dfv2db7449162462...@mail.gmail.com you wrote: On Tue, Apr 21, 2009 at 10:25 AM, Wolfgang Denk w...@denx.de wrote: Dear Jon Smirl, In message 9e4733910904201706u58387d5fod231dd4b8ac88...@mail.gmail.com you wrote: Everyone will know the vendor of their board. You could alphabetize Really? So who is the board vendor for the MPC8360 board? Freescale or Logic PD? And who is the vendor for the ADS5121? Freescale or STX? Read the box when you take the board out. That doesn't help you. The boards are manufactured by Logic PD resp. STX, but they are the official Freescale eval boards. You can buy them here or there, or through an unrelated distributor - so who is the vendor? Or should the ebvbeagle board I buy from EBV go under env or under ti - or, hey, is omap3 the vendor? The vendor concept is helpful sometimes, but generally useful here. 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 Another dream that failed. There's nothing sadder. -- Kirk, This side of Paradise, stardate 3417.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
Dear Jon Smirl, In message 9e4733910904210841n6c7f0db5s57eee23520dc...@mail.gmail.com you wrote: My vote would be to require all boards in the board/ directory to be in a vendor directory. When you buy the board it is pretty obvious from the accompanying packaging/manuals who the vendor is. This would also assign some responsibility to the vendor to maintain the subdirectory for their products. No, this is NOT the case. See the examples I quoted, and this is just a few of them. In my experience, I tend to search for board names first. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is easier to write an incorrect program than understand a correct one. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANNOUNCE] Kconfig support
Dear Sascha, In message 20090421182102.gz21...@pengutronix.de you wrote: This is not quite correct. What I consider important is an evo- lutionary path - this may include bigger changes and reorganizations, but I consider it a bad idea to not provide a reasonable migration path for larger parts of the existing community. Then start proving your point by removing CONFIG_NET_MULTI. U-Boot carries two incompatible network driver APIs for at least the last seven years and still 19 drivers have not switched to the new API. What exactly do you complain about? Have there been any such patches posted that I 9or anybody else) rejected? It was exactly this kind of stagnation that made me fork U-Boot. I was You did not even attempt to fix this, or did you, and I repressed the memory of this? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de If you think the problem is bad now, just wait until we've solved it. Epstein's Law ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
On Apr 21, 2009, at 3:02 PM, Wolfgang Denk wrote: Dear Jon Smirl, In message 9e4733910904210841n6c7f0db5s57eee23520dc...@mail.gmail.com you wrote: My vote would be to require all boards in the board/ directory to be in a vendor directory. When you buy the board it is pretty obvious from the accompanying packaging/manuals who the vendor is. This would also assign some responsibility to the vendor to maintain the subdirectory for their products. No, this is NOT the case. See the examples I quoted, and this is just a few of them. In my experience, I tend to search for board names first. So back to the root of my question, do we just have one really long list of board names? - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB key not recognized
Hello, 2009/4/21 Amandeep Bhullar arm.deb...@gmail.com: Thanks for replying, Remy. I appreciate it. I just downloaded, built and used U-boot version 2009.03. It does see the USB key now. as expected ;-) U-Boot usb start (Re)start USB... USB: scanning bus for devices... 2 USB Device(s) found scanning bus for storage devices... 1 Storage Device(s) found Another question - How can I boot from this USB key. Can I put Debian 5.0 Lenny image on USB key and boot AT91SAM9263-EK from there? Never tried it... At least it depends on if this distro is compiled for ARM-v5 (or v4), and if the (debian)kernel has sam9263-ek board support enabled. If yes, how would I do it? I am new to Linux. Many thanks for your help. You ask me here to mail you the entire manual? For starters, you might take a look at: * http://www.linux4sam.org/twiki/bin/view/Linux4SAM/ * http://www.denx.de/wiki/DULG/Manual * And of course the Debian manuals. Kind Regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] UBOOT relocation question on Atmel arm926ejs
Hi, I am having a hard time understanding how the uboot relocation from flash to RAM happens. I'm trying to follow the code flow. I think I understand it, but wanted to run it by you experts to confirm. The flow starts in cpu/arm926ejs/start.s. In the reset function, after cpu_init_crit, u_boot is relocated to RAM. At the end of the reset function, we jump to start_armboot which is in lib_arm/board.c. At this point, we are already executing out or RAM. Do I have it correct? The reason I'm confused is that in start_armboot we call several functions via an init_sequence table with functions with names that end in _f (meaning in flash). Am I missing something? Thanks in advance, Steve -- View this message in context: http://www.nabble.com/UBOOT-relocation-question-on-Atmel-arm926ejs-tp23164136p23164136.html Sent from the Uboot - Users mailing list archive at Nabble.com. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
Dear Kumar Gala, In message 93a8f58d-8c13-4f72-aff3-cf4fdf9a3...@kernel.crashing.org you wrote: In my experience, I tend to search for board names first. So back to the root of my question, do we just have one really long list of board names? I'm not an expert for the capabilities of Kconfig, but one looong list with hundrets of entries clearly makes no sense. We obviously need sum grouping / structuring. IMHO there should be several options: - for those who look for a board name, we should support this, probably wih an initial selection by the first letter (case insensitive) of the board name. like this:= board name = M = MPC837XERDB - alternatively, it should be possible to restrict the choice by selecting first processor architecture (ARM, PowerPC, MIPS, ...), then CPU (family) name, then board names. like this:= Architecture = PPC = MPC83xx = MPC837XERDB 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 Severe culture shock results when experts from another protocol suite [...] try to read OSI documents. The term osified is used to refer to such documents. [...] Any relationship to the word ossified is purely intentional.- Marshall T. Rose ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] USB key not recognized
Dear Amandeep, In message 3d083b80904211200h413b85dfv253e4990b9456...@mail.gmail.com you wrote: Another question - How can I boot from this USB key. Can I put Debian 5.0 Lenny image on USB key and boot AT91SAM9263-EK from there? If yes, how would I do it? I am new to Linux. Many thanks for your help. You can do this but you better try to understand what you are doing first. A USB stick is not a harddisk drive, and a standard distribution like Debian Lenny is NOT made for use on devices (like USB sticks) that have only a limited number of write cycles per block. At least you should study carefully what others are doing and tweak system behaviour to minimize the number of write operations to the root file system (start looking at things like the noatime mount options, etc.). Then you will notice that you have to make the kernel wait for the root device (the USB stick) to become ready - normally the kernel will try to mount the root file system long before the USB mass storage devices have been initialized. There are several ways around to acchive this - look around. Note that all these things are (1) advanced topics for embedded systems [so you probably want to consult an expert], and they are (2) completely off topic on this U-Boot mailing list. 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 Life would be so much easier if we could just look at the source code. -- Dave Olson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] arm925t: Fix CONFIG_SYS_HZ to 1000
Let CONFIG_SYS_HZ to have value of 1000 effectively fixing all users of
get_timer.
Changes since original version:
* Set PTV=2 (divisor 8) for boards using 12MHz timer clock source to
improve timer resolution.
Signed-off-by: Ladislav Michl la...@linux-mips.org
diff --git a/cpu/arm925t/interrupts.c b/cpu/arm925t/interrupts.c
index e5c77f7..ec2a978 100644
--- a/cpu/arm925t/interrupts.c
+++ b/cpu/arm925t/interrupts.c
@@ -1,4 +1,7 @@
/*
+ * (C) Copyright 2009
+ * 2N Telekomunikace, www.2n.cz
+ *
* (C) Copyright 2003
* Texas Instruments, www.ti.com
*
@@ -37,7 +40,8 @@
#include configs/omap1510.h
#include asm/io.h
-#define TIMER_LOAD_VAL 0x
+#define TIMER_LOAD_VAL 0x
+#define TIMER_CLOCK(CONFIG_SYS_CLK_FREQ / (2 CONFIG_SYS_PTV))
static uint32_t timestamp;
static uint32_t lastdec;
@@ -79,85 +83,41 @@ void set_timer (ulong t)
/* delay x useconds AND preserve advance timestamp value */
void udelay (unsigned long usec)
{
- ulong tmo, tmp;
-
- if (usec = 1000) { /* if big number, spread
normalization to seconds */
- tmo = usec / 1000; /* start to normalize for usec to ticks
per sec */
- tmo *= CONFIG_SYS_HZ; /* find number of ticks to wait to
achieve target */
- tmo /= 1000;/* finish normalize. */
- } else {/* else small number, don't kill it
prior to HZ multiply */
- tmo = usec * CONFIG_SYS_HZ;
- tmo /= (1000*1000);
+ int32_t tmo = usec * (TIMER_CLOCK / 1000) / 1000;
+ uint32_t now, last = __raw_readl(CONFIG_SYS_TIMERBASE + READ_TIM);
+
+ while (tmo 0) {
+ now = __raw_readl(CONFIG_SYS_TIMERBASE + READ_TIM);
+ if (last now) /* count down timer underflow */
+ tmo -= TIMER_LOAD_VAL - now + last;
+ else
+ tmo -= last - now;
+ last = now;
}
-
- tmp = get_timer (0);/* get current timestamp */
- if ((tmo + tmp + 1) tmp) /* if setting this fordward will roll
time stamp */
- reset_timer_masked (); /* reset advancing timestamp to 0,
set lastdec value */
- else
- tmo += tmp; /* else, set advancing stamp wake up
time */
-
- while (get_timer_masked () tmo) /* loop till event */
- /*NOP*/;
}
void reset_timer_masked (void)
{
/* reset time */
- lastdec = __raw_readl(CONFIG_SYS_TIMERBASE + READ_TIM);
+ lastdec = __raw_readl(CONFIG_SYS_TIMERBASE + READ_TIM) /
+ (TIMER_CLOCK / CONFIG_SYS_HZ);
timestamp = 0; /* start advancing time stamp from 0 */
}
ulong get_timer_masked (void)
{
- uint32_t now = __raw_readl(CONFIG_SYS_TIMERBASE + READ_TIM);
-
- if (lastdec = now) { /* normal mode (non roll) */
- /* normal mode */
- timestamp += lastdec - now; /* move stamp fordward with
absoulte diff ticks */
- } else {/* we have overflow of the count down
timer */
- /* nts = ts + ld + (TLV - now)
-* ts=old stamp, ld=time that passed before passing through -1
-* (TLV-now) amount of time after passing though -1
-* nts = new advancing time stamp...it could also roll and
cause problems.
-*/
- timestamp += lastdec + TIMER_LOAD_VAL - now;
- }
+ uint32_t now = __raw_readl(CONFIG_SYS_TIMERBASE + READ_TIM) /
+ (TIMER_CLOCK / CONFIG_SYS_HZ);
+ if (lastdec now) /* count down timer underflow */
+ timestamp += TIMER_LOAD_VAL / (TIMER_CLOCK / CONFIG_SYS_HZ) -
+ now + lastdec;
+ else
+ timestamp += lastdec - now;
lastdec = now;
return timestamp;
}
-/* waits specified delay value and resets timestamp */
-void udelay_masked (unsigned long usec)
-{
-#ifdef CONFIG_INNOVATOROMAP1510
- #define LOOPS_PER_MSEC 60 /* tuned on omap1510 */
- volatile int i, time_remaining = LOOPS_PER_MSEC*usec;
- for (i=time_remaining; i0; i--) { }
-#else
-
- ulong tmo;
- ulong endtime;
- signed long diff;
-
- if (usec = 1000) { /* if big number, spread
normalization to seconds */
- tmo = usec / 1000; /* start to normalize for usec to ticks
per sec */
- tmo *= CONFIG_SYS_HZ; /* find number of ticks to wait to
achieve target */
- tmo /= 1000;/* finish normalize. */
- } else {/* else small number, don't kill it
prior to HZ multiply */
- tmo = usec * CONFIG_SYS_HZ;
- tmo /= (1000*1000);
- }
-
- endtime = get_timer_masked () + tmo;
-
- do {
- ulong now = get_timer_masked ();
- diff = endtime -
Re: [U-Boot] [PATCH] arm925t: Fix CONFIG_SYS_HZ to 1000
On Tue, Apr 21, 2009 at 05:38:21PM +0200, Dirk Behme wrote: Ladislav Michl wrote: On Mon, Apr 20, 2009 at 08:27:34PM +0200, Dirk Behme wrote: Just to get an idea of the math: CONFIG_SYS_CLK_FREQ is 1200 (12MHz)? This is divided by 256, so TIMER_CLOCK is 46875Hz? A free running 32-bit count down timer is used starting at 0x? Underflow (0) is reached after ~91626s == ~25hours with this? Please correct if something is wrong ;) Math is perfectly correct, except in my case CONFIG_SYS_CLK_FREQ is 150MHz, so resolution is actually 12.5 times better. Ok. Is this 150MHz defined in one of the configs you modify with this patch or do you use a custom config? Just curious ;) All three 32-bit counters receive a dedicated clock from clock generator module 1 (either CLKIN or DPLL1 output). You will find CONFIG_SYS_CLK_FREQ defined to be 15000 in include/configs/netstar.h and code in board/netstar/setup.S selects DPLL1 as a clock source (and you'll probably notice that netstar's lowlevel_init code looks different from all others just because it was not copied, but written from scratch long before its author even explored u-boot's existence, so take care when copying anything from netstar's config file as it handles low level init different way). Perhaps I should modify those boards wich uses 12MHz clock to use smaller divisor, Yes, this should be easily doable by changing CONFIG_SYS_PTV. Yes, I'll send updated patch. [snip] Right, but the key point here is to unbind udelay from get_timer as now get_timer works with miliseconds resolution. I hope I got it right with the updated patch sent some minutes ago. Yes, that one looks definitely better (although I have no way to test it). ladis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANNOUNCE] Kconfig support
On Tue, Apr 21, 2009 at 10:08:38PM +0200, Wolfgang Denk wrote: Dear Sascha, In message 20090421182102.gz21...@pengutronix.de you wrote: This is not quite correct. What I consider important is an evo- lutionary path - this may include bigger changes and reorganizations, but I consider it a bad idea to not provide a reasonable migration path for larger parts of the existing community. Then start proving your point by removing CONFIG_NET_MULTI. U-Boot carries two incompatible network driver APIs for at least the last seven years and still 19 drivers have not switched to the new API. What exactly do you complain about? Have there been any such patches posted that I 9or anybody else) rejected? I wouldn't read this as a complain, it is just a statement of fact that design flaws in v2 got fixed several orders of magnitude faster than in v1. It was exactly this kind of stagnation that made me fork U-Boot. I was You did not even attempt to fix this, or did you, and I repressed the memory of this? The point probably is that is was easier to design it right from scratch and then add support for needed cpus and devices. And looking at v2 I have to admit that investing the same time I spent fixing v1 for nestar board into v2 I'd be already done (minus i2c stuff) and could enjoy tons of spare time otherwise consumed by evolutionary fixing v1 (yes, evolution works quite well, but neither easy nor the best way things could be done). Just my two cents... Best regards, ladis ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANNOUNCE] Kconfig support
On Tue, Apr 21, 2009 at 10:08:38PM +0200, Wolfgang Denk wrote: Dear Sascha, In message 20090421182102.gz21...@pengutronix.de you wrote: This is not quite correct. What I consider important is an evo- lutionary path - this may include bigger changes and reorganizations, but I consider it a bad idea to not provide a reasonable migration path for larger parts of the existing community. Then start proving your point by removing CONFIG_NET_MULTI. U-Boot carries two incompatible network driver APIs for at least the last seven years and still 19 drivers have not switched to the new API. What exactly do you complain about? Have there been any such patches posted that I 9or anybody else) rejected? It was exactly this kind of stagnation that made me fork U-Boot. I was You did not even attempt to fix this, or did you, and I repressed the memory of this? No, neither I tried to fix it nor did anybody else. Probably because noone wants to dig through numerous drivers for which he most likely does not even have the hardware. The solution is to mark them as broken and you'll get the relevant patches within a week. The drivers which are still not fixed after some months can be removed as nobody seems to have interest in them. I know this is a strong weapon which should be handled with care, but I think sometimes it's necessary to use it. s...@octopus:~/octopus/u-boot/u-boot find board -name flash.c | wc -l 201 s...@octopus:~/octopus/u-boot/u-boot find board -name config.mk| wc -l 411 So nearly half of the boards in U-Boot seem to be unmaintained since the advent of the generic flash driver five years ago. How can you possibly ever change the API for the flash driver with 201 different flash drivers in the tree without marking something as broken? One of these boards is the Auerswald Innokom, a board Robert once ported. We probably still have it somewhere @Pengutronix, but nobody in the world has any interest in running a top of tree U-Boot on it. Still it is in the tree and by policy it has to be supported for all eternity. Mark the boards as broken, remove them and give the others some air to breeze to actually change something without drowning in legacy code. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
On Tue, Apr 21, 2009 at 5:05 PM, Kumar Gala ga...@kernel.crashing.org wrote: On Apr 21, 2009, at 3:52 PM, Wolfgang Denk wrote: Dear Kumar Gala, In message 93a8f58d-8c13-4f72-aff3-cf4fdf9a3...@kernel.crashing.org you wrote: In my experience, I tend to search for board names first. So back to the root of my question, do we just have one really long list of board names? I'm not an expert for the capabilities of Kconfig, but one looong list with hundrets of entries clearly makes no sense. We obviously need sum grouping / structuring. IMHO there should be several options: - for those who look for a board name, we should support this, probably wih an initial selection by the first letter (case insensitive) of the board name. like this: = board name = M = MPC837XERDB You can search for the board name in Kconfig using Ctrl-F and then put in a string This works on the kernel too. - alternatively, it should be possible to restrict the choice by selecting first processor architecture (ARM, PowerPC, MIPS, ...), then CPU (family) name, then board names. like this: = Architecture = PPC = MPC83xx = MPC837XERDB I vote for the second one. Now I'll ask what the location of defconfigs should be? - k -- Jon Smirl jonsm...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
Dear Kumar, In message aea791b2-2bc0-49f7-9152-acf6ca567...@kernel.crashing.org you wrote: I'm not an expert for the capabilities of Kconfig, but one looong list with hundrets of entries clearly makes no sense. We obviously need sum grouping / structuring. IMHO there should be several options: - for those who look for a board name, we should support this, probably wih an initial selection by the first letter (case insensitive) of the board name. like this: = board name = M = MPC837XERDB - alternatively, it should be possible to restrict the choice by selecting first processor architecture (ARM, PowerPC, MIPS, ...), then CPU (family) name, then board names. like this: = Architecture = PPC = MPC83xx = MPC837XERDB I vote for the second one. You misunderstant what I meant. I don't think of havon one or the other of these options, but of offering *both* of them, so the user can chose one of the ways, whatever suits best for his current situation. 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 SW engineering is a race between programmers trying to make better idiot-proof programs and the universe producing greater idiots. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
On Apr 21, 2009, at 5:59 PM, Wolfgang Denk wrote: Dear Kumar, In message AEA791B2-2BC0-49F7-9152- acf6ca567...@kernel.crashing.org you wrote: I'm not an expert for the capabilities of Kconfig, but one looong list with hundrets of entries clearly makes no sense. We obviously need sum grouping / structuring. IMHO there should be several options: - for those who look for a board name, we should support this, probably wih an initial selection by the first letter (case insensitive) of the board name. like this: = board name = M = MPC837XERDB - alternatively, it should be possible to restrict the choice by selecting first processor architecture (ARM, PowerPC, MIPS, ...), then CPU (family) name, then board names. like this: = Architecture = PPC = MPC83xx = MPC837XERDB I vote for the second one. You misunderstant what I meant. I don't think of havon one or the other of these options, but of offering *both* of them, so the user can chose one of the ways, whatever suits best for his current situation. Oh, I dont know if we can do that in Kconfig w/o duplicating the option which I think Kconfig would get unhappy about. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ANNOUNCE] Kconfig support
Dear Sascha, In message 20090421223025.ga21...@pengutronix.de you wrote: s...@octopus:~/octopus/u-boot/u-boot find board -name flash.c | wc -l 201 s...@octopus:~/octopus/u-boot/u-boot find board -name config.mk| wc -l 411 So nearly half of the boards in U-Boot seem to be unmaintained since the advent of the generic flash driver five years ago. I disagree with your interpretation. Why should aboard maintainer change running code without need? We never asked to change the flash driver of existing boards because there was no need for doing this. So why should anybody spend efforts to change these? How can you possibly ever change the API for the flash driver with 201 different flash drivers in the tree without marking something as broken? Well, *if* we wanted to change the API, that would be a reason to get rid of the old legacy flash drivers. But so far no such API change has been necessary. And here and there the old drivers are even necessary due to restrictions of the CFI driver that are not too easy to fix. So what exactly is it you are critizising? That we don't abondon working code just because it is old? Hm... One of these boards is the Auerswald Innokom, a board Robert once ported. We probably still have it somewhere @Pengutronix, but nobody in the world has any interest in running a top of tree U-Boot on it. Still it is in the tree and by policy it has to be supported for all eternity. Feel free to submit patches to remove it from the tree if you care. On the other hand - how much effort was actually spent on keeping this board alive? Obviously not much, because so far nobody com- plained about it. Actually that's the whole idea about having a board in mainline. If you look at the changes that were applied to the related files, it's all stuff that was done 99% automatically with some scripts - and I don't really care if these are applied to 20 boards or to 200. I fail to understand what you are trying to tell us. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I can call spirits from the vasty deep. Why so can I, or so can any man; but will they come when you do call for them? - Shakespeare, 1 King Henry IV, Act III, Scene I. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
Dear Jon Smirl, In message 9e4733910904211533s58df5764na715986b36824...@mail.gmail.com you wrote: - for those who look for a board name, we should support this, probably wih an initial selection by the first letter (case insensitive) of the board name. like this: = board name = M = MPC837XERDB You can search for the board name in Kconfig using Ctrl-F and then put in a string This works on the kernel too. Ctrl-F? In which exact envrionment does this work? With make config? make menuconfig ? 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 CONSUMER NOTICE: Because of the Uncertainty Principle, It Is Impossible for the Consumer to Find Out at the Same Time Both Precisely Where This Product Is and How Fast It Is Moving. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
On Tue, Apr 21, 2009 at 7:14 PM, Wolfgang Denk w...@denx.de wrote: Dear Jon Smirl, In message 9e4733910904211533s58df5764na715986b36824...@mail.gmail.com you wrote: - for those who look for a board name, we should support this, probably wih an initial selection by the first letter (case insensitive) of the board name. like this: = board name = M = MPC837XERDB You can search for the board name in Kconfig using Ctrl-F and then put in a string This works on the kernel too. Ctrl-F? In which exact envrionment does this work? With make config? make menuconfig ? I see now that Ctrl-F doesn't work everywhere. Try it in 'make xconfig' -- Jon Smirl jonsm...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Kconfig menu layout
Jon Smirl wrote: On Tue, Apr 21, 2009 at 7:14 PM, Wolfgang Denk w...@denx.de wrote: Dear Jon Smirl, In message 9e4733910904211533s58df5764na715986b36824...@mail.gmail.com you wrote: - for those who look for a board name, we should support this, probably wih an initial selection by the first letter (case insensitive) of the board name. like this: = board name = M = MPC837XERDB You can search for the board name in Kconfig using Ctrl-F and then put in a string This works on the kernel too. Ctrl-F? In which exact envrionment does this work? With make config? make menuconfig ? I see now that Ctrl-F doesn't work everywhere. Try it in 'make xconfig' I don't want to ignite a flame war, but IMHO 'make menuconfig' is the one we should be optimizing towards. What's the objection again to having the user set ARCH before running this, or at least to using ARCH as the first sort key? regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] nand biterr ... got an implementation?
I was hoping that I could use that to test some NAND code, but then I noticed it wasn't implemented. I would have expected that U-Boot command wouldn't exist until they're implemented... I'm hoping someone has an implementation. With at least these characteristics: - Doesn't toggle the same bit each time - Repeating N times on a block introduces N distinct 1-bit errors - Normally affects only the data area, not spare/OOB * although forcing bit errors in ECC would be valuable too * ditto the rest of the OOB ... though likely they'd be ignored Am I hoping in vain? ;) - Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] implement usb gadget ethernet in uboot
hi remy with your help, i have add my code to uboot and the probe can work. but i still have some questions. 1. After probe, in kernel, i will wait the interrupt generated by insert usb cable , but in uboot, we don`t have interrupt, so how do you deal with it. 2009/4/18 Remy Bohmer li...@bohmer.net Hello, I have implement gadget ethernet in kernel(cdc_subset). But the uboot don`t have gadget framework.how can i implement this feature?Does anyone has this experience? Please take a look at the CDC branch in u-boot-usb. http://git.denx.de/?p=u-boot/u-boot-usb.git;a=shortlog;h=refs/heads/cdc I guess that has everything you are searching for ;-) Patches to add more boards/devices or other improvements are welcome. Kind Regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Marvell MV88F6281GTW_GE Board support
+#define CONFIG_IPADDR192.168.5.44 +#define CONFIG_SERVERIP 192.168.5.30 +#define CONFIG_NETMASK 255.255.255.0 please remove the IP params Why ? Because these values are only relevant to your lab network, not anybody else who's going to use your boards. Boards should start with a clean slate. This is a hard rule that we've been enforcing for a while now - no address or network parameter initializations in config files. Thanks Ben for clarification. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
