Re: [U-Boot] [patch] rm9200 ethernet driver: board-specific quirk (csb337)
On Wednesday 17 June 2009, Ben Warren wrote: Applied to net repo. Thanks. Random question: is that driver going to move into drivers/net or will it stay in cpu/arm920t? I thought I saw you moving things out of cpu/* a while back. - Dave ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [patch] rm9200 ethernet driver: board-specific quirk (csb337)
David Brownell wrote: On Wednesday 17 June 2009, Ben Warren wrote: Applied to net repo. Thanks. Random question: is that driver going to move into drivers/net or will it stay in cpu/arm920t? I thought I saw you moving things out of cpu/* a while back. - Dave Good question. I'd like to move it to drivers/net, as well as modify it to use the newer API. Time willing... :) regards, Ben ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PATCH: bugfix for nand erase failure with bad blocks
Scott Wood wrote: Wolfgang Denk wrote: Dear Scott, In message 4a39685f.6030...@freescale.com you wrote: Hmm... perhaps check the alignment? If end is supposed to be the last to-be-erased byte, not the first not-to-be-erased byte, then if the low bits are 0 it's a size (and gets a warning) and if they're 1 it's an end? Stop here. Don't add fancy stuf that nobody expects. Nobody expects the semantics to silently change... I'm not particularly advocating this approach, just throwing out alternatives. Leaving it alone is probably best. Ask yourself what the end user expects - we all think of erase preparing the grounds for write, right? Sometimes. Other times, it could be preparing for use by a filesystem (which may not use the same bad block handling scheme), to reset the environment, for testing, etc. We have the plus syntax specifically for the use case of erase+write of a specific number of bytes; IMO that's the place for this kind of interpretation. So both should work oin the same NAND flash region when given the same arguments (offset and seze, So then there would be no reliable way of erasing a specific range of flash. To properly use the block-skipping approach, the user needs to have in mind a range of actual blocks that the data can take up (i.e. a maximum number of bad blocks to expect), so that they can avoid locating the next partition within that range. I don't think it makes sense to try to completely hide this. Perhaps write should accept an optional limit argument, returning an error if enough bad blocks were encountered to bust the limit. no matter how these are specified). If the syntax were changed to start/end, but the erase could go beyond end anyway, that would be extremely confusing. -Scott Summarizing, there are two alternatives: - change 'erase' command aligning it with 'write' and 'read' command (what the patch does); - add a third field to the 'erase' command, maybe called 'limit', over which erasing can't be done: 'nand erase start offset limit' In this case, I think that 'write' command may be aligned with this new syntax too. It's up to you. Regards, Michele ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] sf: sst: add sst25vf###b ids
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
drivers/mtd/spi/sst.c | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/sst.c b/drivers/mtd/spi/sst.c
index cf7bce8..50e9299 100644
--- a/drivers/mtd/spi/sst.c
+++ b/drivers/mtd/spi/sst.c
@@ -55,6 +55,22 @@ static inline struct sst_spi_flash *to_sst_spi_flash(struct
spi_flash *flash)
#define SST_SECTOR_SIZE (4 * 1024)
static const struct sst_spi_flash_params sst_spi_flash_table[] = {
{
+ .idcode1 = 0x8d,
+ .nr_sectors = 128,
+ .name = SST25VF040B,
+ },{
+ .idcode1 = 0x8e,
+ .nr_sectors = 256,
+ .name = SST25VF080B,
+ },{
+ .idcode1 = 0x41,
+ .nr_sectors = 512,
+ .name = SST25VF016B,
+ },{
+ .idcode1 = 0x4a,
+ .nr_sectors = 1024,
+ .name = SST25VF032B,
+ },{
.idcode1 = 0x01,
.nr_sectors = 16,
.name = SST25WF512,
--
1.6.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] sf: sst: fix sector size
Looks like when I was encoding the sector sizes, I forgot to divide by 8
(due to the stupid marketing driven process that declares all sizes in
useless megabits and not megabytes).
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
drivers/mtd/spi/sst.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/spi/sst.c b/drivers/mtd/spi/sst.c
index 62236d4..cf7bce8 100644
--- a/drivers/mtd/spi/sst.c
+++ b/drivers/mtd/spi/sst.c
@@ -56,19 +56,19 @@ static inline struct sst_spi_flash *to_sst_spi_flash(struct
spi_flash *flash)
static const struct sst_spi_flash_params sst_spi_flash_table[] = {
{
.idcode1 = 0x01,
- .nr_sectors = 128,
+ .nr_sectors = 16,
.name = SST25WF512,
},{
.idcode1 = 0x02,
- .nr_sectors = 256,
+ .nr_sectors = 32,
.name = SST25WF010,
},{
.idcode1 = 0x03,
- .nr_sectors = 512,
+ .nr_sectors = 64,
.name = SST25WF020,
},{
.idcode1 = 0x04,
- .nr_sectors = 1024,
+ .nr_sectors = 128,
.name = SST25WF040,
},
};
--
1.6.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [patch] rm9200 ethernet driver: board-specific quirk (csb337)
On 00:01 Fri 19 Jun , Ben Warren wrote: David Brownell wrote: On Wednesday 17 June 2009, Ben Warren wrote: Applied to net repo. Thanks. Random question: is that driver going to move into drivers/net or will it stay in cpu/arm920t? I thought I saw you moving things out of cpu/* a while back. - Dave Good question. I'd like to move it to drivers/net, as well as modify it to use the newer API. Time willing... :) I'll prefer you do not move it as it's plan to drop it soon and swithc the rm9200 to the at91 api and now stop to double implement the driver as serial, spi as example Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to port uboot Marvell PXA320 Zylonite board
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of sadanand.tavad...@wipro.com Sent: Thursday, June 18, 2009 1:42 PM To: u-boot@lists.denx.de Subject: [U-Boot] How to port uboot Marvell PXA320 Zylonite board Hi Please let me know anybody ported uboot on Marvell PXA320 Zylonite board. Hi, Not for PXA, but I have done it for Marvell Kirkwood SoCs Any way, how I can help you? Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Marvell Kirkwood newbie question GPIO functions
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Dieter Kiermaier Sent: Thursday, June 18, 2009 1:35 PM To: u-boot@lists.denx.de Subject: [U-Boot] Marvell Kirkwood newbie question GPIO functions Hello everybody out there, first off all - thanks to everyone from the u-boot community for this helpful piece of code :) Could somebody give me a short overview of the plans regarding the u-boot port of the Kirkwood arch (e.g. Sheevaplug board)? It's my pleasure to reply you :-) Basic Kirkwood Soc Support patches are available on the u-boot-arm.git/next (will be mainlined soon) Sheevaplug board support patches are also submitted those are under review, you can find them here... http://lists.denx.de/pipermail/u-boot/2009-June/054313.html http://lists.denx.de/pipermail/u-boot/2009-June/054314.html http://lists.denx.de/pipermail/u-boot/2009-June/054316.html Some other board patches are in pipeline Currently I'm using the u-boot from git.marvell.com which has first board support for sheevaplug. I'm working on a custom hardware design but as a starting point the sheevaplug seems to work well. Objective for U-boot at git.marvell.com is to maintain a usable copy of u-boot with all accepted/unaccepted patches at one place to support Kirkwood developers, but once all these patches are mainlined, this repository will be removed. Sadly there is no generic gpio support - at least I couldn't find it. Are there any plans to support a driver for this feature? BTW: what you want to do at u-boot level with GPIOs? Current Kirkwood drivers and board support does not need any specific GPIO driver, you can access registers directly to read/write GPIOs. But I think if this is a need in future, I will add gpio driver support. You can provide me your requirements too. I'm willing to contribute some code if someone guides me a bit? You are most welcomed Pls feel free to raise your queries... Regards.. Prafulla . . Thanks in advance, Dieter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PATCH add rgb555 for at91
Hi Giulio, Detlev Zundel wrote: Hi Giulio, Signed-off-by: giulio.bene...@micronovasrl.com Can you please provide a somewhat more descriptive description? It may be obvious for you what this does (or what new features can now be used), but it isn't for me. [...] You're right, sorry. This patch add support for Rgb 555 bits following a precise hardware wiring that should be more correct respect the at91sam9263ek. I mean LCD2 - LCD7 are RED0 - RED4, LCD10 - LCD15 are GREEN0 - GREEN4, LCD18 - LCD23 are BLUE0 - BLUE4 Hm, I still don't get what your patch does. Is this the wiring which is actually used on the at91sam9263ek? If so, then why does your patch not add this symbol in include/configs/at91sam9263ek.h? In there I see the said CONFIG_ATMEL_LCD_BGR555. That symbol is also defined for the at91cap9adk, at91sam9261ek and pm9263.h. So what I would really like to know - is the interpretation of CONFIG_ATMEL_LCD_BGR555 correct in U-Boot and only the at91sam9263ek is wired up differently? Or should rather the interpretation of CONFIG_ATMEL_LCD_BGR555 be fixed? Regarding LCD_BGR555, it is correct only because at91sam9263ek was wired swapped between red and blue. It should be in that way but I'm not sure. Anyway I think the wiring should be done better before, instead of create a new standard. Fortunately with software you can change more than something, but not everything. Ah, so this means that the at91sam9263ek is special compared to the other boards listed above and should be treated differently, right? Well in this case, your patch certainly needs to change include/configs/at91sam9263ek.h. Cheers Detlev -- Peace of mind isn't at all superficial to technical work. It's the whole thing. That which produces it is good work and that which destroys it is bad work. -- Robert M. Pirsig -- 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] U-book and GPLv3? (fwd)
Hi Jon, On Thu, Jun 18, 2009 at 11:46 AM, Jean-Christophe PLAGNIOL-VILLARDplagn...@jcrosoft.com wrote: On 16:51 Thu 18 Jun , Wolfgang Denk wrote: Hello, I was asked about relicensing U-Boot as GPLv3: I'm not for the GPLv3 I've the same opinion as Linus Torvald And as we share a lot's of code with Linux we should continue and not use the GPLv3 at all Isn't there a practical consideration too? Since copyright assignment isn't required on u-boot contributions, you would have to track down all of the contributors and get their permission for the licensing change. Mozilla had to do this when they changed their license and it took them two years to find everyone. Linus has stated that tracking down all of the contributors to the kernel is virtually impossible. If code is licensed under the GPLv2 or later clause, it can be moved without permission from the author. It's really GPLv2 only which needs confirmation. Cheers Detlev -- #define KSAMTIB_CIGAM_2SFFJ 0x8519 /* For detecting wrong-endian fs */ -- include/linux/jffs2.h -- 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] U-book and GPLv3? (fwd)
Hi Wolfgang, I was asked about relicensing U-Boot as GPLv3: From:Richard Stallman r...@gnu.org Subject: U-book and GPLv3? To: Wolfgang Denk w...@denx.de Date:Thu, 18 Jun 2009 09:17:28 -0400 I really enjoy the name U-boot. What are the advantages of U-boot over PMON? Have you considered moving U-boot to GPLv3-or-later? -- I know that we have had similar discussions before (see for example http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/24029), but I would like to take the chance and re-poll what the community's opinion about this is. For what it's worth, I would appreciate moving to GPLv3. Sparing details, my reasoning is the following. Basically I think most people appreciate the GPL for what it means in pratical terms: * the freedom to use the software for any purpose, * the freedom to change the software to suit your needs, * the freedom to share the software with your friends and neighbors, * and * the freedom to share the changes you make. Obviously the second item here will become void if vendor lockout of updates becomes common. So what will be left of the essential freedoms? I can study the code, I can modify it, but I am not allowed to run it. Excellent. I think it is not a coincidence that devices which can be updated with arbitrary firmware sells pretty good in the meantime. Who buys routers capable of running OpenWRT because of their original firmware? Of course vendors do still have the possibility to reject any form of warranty or liability once a firmware not provided by them is applied, but still the choice should be made by the person who owns the device. Just think about the owns in the previous sentence. Do you really own a device anymore if you cannot fix it? Would you buy a car that you are not allowed to change the tires by yourselves? Well I get carried away, so I'd rather stop ;) Cheers Detlev -- I propose that each copy of the OS should ship with an orange jumpsuit and sensory deprivation goggles, since all Vista users have been unilaterally declared 'enemy combatants' by the content apparatchiki - Daniel Nevin. -- 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] Marvell Kirkwood newbie question GPIO functions
Hi Prafulla, It's my pleasure to reply you :-) Basic Kirkwood Soc Support patches are available on the u-boot-arm.git/next (will be mainlined soon) Sheevaplug board support patches are also submitted those are under review, you can find them here... http://lists.denx.de/pipermail/u-boot/2009-June/054313.html http://lists.denx.de/pipermail/u-boot/2009-June/054314.html http://lists.denx.de/pipermail/u-boot/2009-June/054316.html Some other board patches are in pipeline thanks very much for your help. So far I have seen that marvell git u-boot is used to push it to mainline. Great job! What patches are in the pipeline? Currently I'm using the u-boot from git.marvell.com which has first board support for sheevaplug. I'm working on a custom hardware design but as a starting point the sheevaplug seems to work well. Objective for U-boot at git.marvell.com is to maintain a usable copy of u-boot with all accepted/unaccepted patches at one place to support Kirkwood developers, but once all these patches are mainlined, this repository will be removed. Sadly there is no generic gpio support - at least I couldn't find it. Are there any plans to support a driver for this feature? BTW: what you want to do at u-boot level with GPIOs? Current Kirkwood drivers and board support does not need any specific GPIO driver, you can access registers directly to read/write GPIOs. But I think if this is a need in future, I will add gpio driver support. You can provide me your requirements too. I'm working on a custom hardware using the sheevaplug as a starting point. Hopefully end of summer I finish the hardware work and have my own board. But I have some additional requirements. For example control some power supplies for LCD, boot an FPGA, program a clock chip device and so on. So my demands are: - GPIO support (for programming the clock generator which has a simple serial interface to clock in the configuration data) Yeah, I know that I can setup the GPIOs by writing directly to the registers, but a gpio frameworks would be much nicer ;) - SPI (from the TDM module) support which works independet from NAND flash and SD-Card I have allready posted a query to arm-linux kernel mailing list and yesterday evening I have talked with Lennert on IRC regarding SPI and linux . The SPI interface is needed in u-boot to boot my lattice FPGA which is configured as slave serial device (and later on in linux to drive a touch controller). There is allready a FPGA configuration framework inside u-boot and I would like to integrate also a lattice FPGA into that. But to do this I need SPI support. I'm willing to contribute some code if someone guides me a bit? You are most welcomed Pls feel free to raise your queries... Here they are :) Thanks, Dieter Regards.. Prafulla . . Thanks in advance, Dieter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Marvell Kirkwood newbie question GPIO functions
Hi again, Hi Prafulla, It's my pleasure to reply you :-) Basic Kirkwood Soc Support patches are available on the u-boot-arm.git/next (will be mainlined soon) Sheevaplug board support patches are also submitted those are under review, you can find them here... http://lists.denx.de/pipermail/u-boot/2009-June/054313.html http://lists.denx.de/pipermail/u-boot/2009-June/054314.html http://lists.denx.de/pipermail/u-boot/2009-June/054316.html Some other board patches are in pipeline thanks very much for your help. So far I have seen that marvell git u-boot is used to push it to mainline. Great job! What patches are in the pipeline? Currently I'm using the u-boot from git.marvell.com which has first board support for sheevaplug. I'm working on a custom hardware design but as a starting point the sheevaplug seems to work well. Objective for U-boot at git.marvell.com is to maintain a usable copy of u-boot with all accepted/unaccepted patches at one place to support Kirkwood developers, but once all these patches are mainlined, this repository will be removed. Sadly there is no generic gpio support - at least I couldn't find it. Are there any plans to support a driver for this feature? BTW: what you want to do at u-boot level with GPIOs? Current Kirkwood drivers and board support does not need any specific GPIO driver, you can access registers directly to read/write GPIOs. But I think if this is a need in future, I will add gpio driver support. You can provide me your requirements too. I'm working on a custom hardware using the sheevaplug as a starting point. Hopefully end of summer I finish the hardware work and have my own board. But I have some additional requirements. For example control some power supplies for LCD, boot an FPGA, program a clock chip device and so on. So my demands are: - GPIO support (for programming the clock generator which has a simple serial interface to clock in the configuration data) Yeah, I know that I can setup the GPIOs by writing directly to the registers, but a gpio frameworks would be much nicer ;) - SPI (from the TDM module) support which works independet from NAND flash and SD-Card I have allready posted a query to arm-linux kernel mailing list and yesterday evening I have talked with Lennert on IRC regarding SPI and linux . The SPI interface is needed in u-boot to boot my lattice FPGA which is configured as slave serial device (and later on in linux to drive a touch controller). There is allready a FPGA configuration framework inside u-boot and I would like to integrate also a lattice FPGA into that. But to do this I need SPI support. What I forgot to mention is the i2c driver inside u-boot. I need this to read the mac address from an additional eeprom. This makes mass production more ease and doesn't produce hight costs :) Dieter I'm willing to contribute some code if someone guides me a bit? You are most welcomed Pls feel free to raise your queries... Here they are :) Thanks, Dieter Regards.. Prafulla . . Thanks in advance, Dieter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] how to build a U-Boot forU-boot for STR710FZ2T6
Hi, I have a ARM board STR710FZ2T6, and I want to build u-boot for it, so I downloaded the latest u-boot source,but it has not included STR710FZ2T6.So can anyone tell me how to modify u-boot for STR710FZ2T6. -- View this message in context: http://www.nabble.com/how-to-build-a-U-Boot-forU-boot-for-STR710FZ2T6-tp24107715p24107715.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] How to port uboot Marvell PXA320 Zylonite board
-Original Message- From: sadanand.tavad...@wipro.com [mailto:sadanand.tavad...@wipro.com] Sent: Friday, June 19, 2009 2:02 PM To: Prafulla Wadaskar Subject: RE: How to port uboot Marvell PXA320 Zylonite board Hi Prafulla We did make zylonite_config and generated .bin file for uboot. Is it Ok to download this .bin file into PXA Zylonite board directly On kirkwood platform, it is NOT, the u-boot.bin needs further processing to create flashable bin for NANDF or SF This code is not currently part of u-boot Similarly, I don't think you can use the same binary to flash on the on-board flash? the board maintainer can answer this better way :-) Regards.. Prafulla . . Thanks Sada -Original Message- From: Prafulla Wadaskar [mailto:prafu...@marvell.com] Sent: Friday, June 19, 2009 1:32 PM To: Sadanand Tavadare (WT01 - PES-Medical-HealthCare); u-boot@lists.denx.de Subject: RE: How to port uboot Marvell PXA320 Zylonite board -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of sadanand.tavad...@wipro.com Sent: Thursday, June 18, 2009 1:42 PM To: u-boot@lists.denx.de Subject: [U-Boot] How to port uboot Marvell PXA320 Zylonite board Hi Please let me know anybody ported uboot on Marvell PXA320 Zylonite board. Hi, Not for PXA, but I have done it for Marvell Kirkwood SoCs Any way, how I can help you? Regards.. Prafulla . . Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/6] MX31: NAND boot for PDK boards.
Hi everybody and especially developers of i.MX31 NAND boot patches, I wrote an e-mail yesterday asking about the need of the mx31_nand.c file in drivers/mtd/nand/ folder. Since nobody answerd I tried to review the development of the latest patch [PATCH v4 0/6] MX31: NAND boot for PDK boards. historically. It's probably a stupid question but for me as a u-boot newbe it would be very helpful. I started in August 2008 where I found the first patch called [PATCH RFC 0/5] Add NAND Support... and later two patches with the same title and the prefix [PATCH v2 0/6] and [PATCH v3 0/6] from Magnus Lilja. In October Mr. Assis posted a patch regarding to this topic aswell. In December and January Maxim Artamonov postet a patches to introduce NAND SPL support. In April then another series of patches from Magnus Lilja were posted with the title [RFC 0/5] MX31: NAND boot for phyCORE and PDK boards. I think based on this in April version 2 and and in June now version 3 and 4 were posted by Magnus Lilja. As I can see the latest patch includes all the necessary code from the previous patches. So no other patch has to be applied to boot u-boot from a NAND Flash on a board with the i.MX31 ? But I had a very hard time doing this review and I'm not 100% sure if I'm correct Would be very nice if someone could tell me if I'm right and if not tell me what I need more to boot from a NAND flash. Thank you very mutch, Ulrich Gerster ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/6] MX31: NAND boot for PDK boards.
Hi 2009/6/19 Ulrich Gerster gerst...@dhbw-loerrach.de: Hi everybody and especially developers of i.MX31 NAND boot patches, I wrote an e-mail yesterday asking about the need of the mx31_nand.c file in drivers/mtd/nand/ folder. Since nobody answerd I tried to review the development of the latest patch [PATCH v4 0/6] MX31: NAND boot for PDK boards. historically. It's probably a stupid question but for me as a u-boot newbe it would be very helpful. I started in August 2008 where I found the first patch called [PATCH RFC 0/5] Add NAND Support... and later two patches with the same title and the prefix [PATCH v2 0/6] and [PATCH v3 0/6] from Magnus Lilja. In October Mr. Assis posted a patch regarding to this topic aswell. In December and January Maxim Artamonov postet a patches to introduce NAND SPL support. In April then another series of patches from Magnus Lilja were posted with the title [RFC 0/5] MX31: NAND boot for phyCORE and PDK boards. I think based on this in April version 2 and and in June now version 3 and 4 were posted by Magnus Lilja. As I can see the latest patch includes all the necessary code from the previous patches. So no other patch has to be applied to boot u-boot from a NAND Flash on a board with the i.MX31 ? That's correct. But I had a very hard time doing this review and I'm not 100% sure if I'm correct Would be very nice if someone could tell me if I'm right and if not tell me what I need more to boot from a NAND flash. Booting U-Boot from NAND Flash on i.MX31 PDK requires nothing else. However, the current U-Boot does not have support to have the U-Boot environment or kernel in NAND since the mx31_nand.c driver is missing. There have been a number of patches containing such a driver but so far no one has been accepted. Regards, Magnus ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] V3 Zoom hw reset
Hello Tom, Tom Rix wrote: The i2c patch is a cleaned up version of the one I RFC-ed to the list earlier. It addresses Nishanth's concerns by using the kernel's algorithm and by making the major parameters overridable by a board config. Jean's request for no weak function is addressed by this being done only with #defines. I have reverified on the hw listed in the commit. The twl4030 patch I don't think anyone had a problem with. The twl4030 hw reset has been generalized. After analyzing beagle schematics, I believe this can be used by anyone with supporting hw. So the function stays in power.c and the #ifdef's are removed. I think your 3 patches are OK, and if Jean-Christophe give his Acked-by, I can add this to the i2c tree and send a pull request to Wolfgang, or if Jean-Christophe wants to add this to the arm tree I give my Acked-by to your patches. bye heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Marvell Kirkwood newbie question GPIO functions
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Dieter Kiermaier Sent: Friday, June 19, 2009 2:23 PM To: u-boot@lists.denx.de Subject: Re: [U-Boot] Marvell Kirkwood newbie question GPIO functions Hi again, Hi Prafulla, It's my pleasure to reply you :-) Basic Kirkwood Soc Support patches are available on the u-boot-arm.git/next (will be mainlined soon) Sheevaplug board support patches are also submitted those are under review, you can find them here... http://lists.denx.de/pipermail/u-boot/2009-June/054313.html http://lists.denx.de/pipermail/u-boot/2009-June/054314.html http://lists.denx.de/pipermail/u-boot/2009-June/054316.html Some other board patches are in pipeline thanks very much for your help. So far I have seen that marvell git u-boot is used to push it to mainline. Great job! What patches are in the pipeline? Some other board supports (MV88F6281GTW_GE) and Kirkwood SPI driver support Kirkwood USB support (at this moment) Currently I'm using the u-boot from git.marvell.com which has first board support for sheevaplug. I'm working on a custom hardware design but as a starting point the sheevaplug seems to work well. Objective for U-boot at git.marvell.com is to maintain a usable copy of u-boot with all accepted/unaccepted patches at one place to support Kirkwood developers, but once all these patches are mainlined, this repository will be removed. Sadly there is no generic gpio support - at least I couldn't find it. Are there any plans to support a driver for this feature? BTW: what you want to do at u-boot level with GPIOs? Current Kirkwood drivers and board support does not need any specific GPIO driver, you can access registers directly to read/write GPIOs. But I think if this is a need in future, I will add gpio driver support. You can provide me your requirements too. I'm working on a custom hardware using the sheevaplug as a starting point. Hopefully end of summer I finish the hardware work and have my own board. But I have some additional requirements. For example control some power supplies for LCD, boot an FPGA, program a clock chip device and so on. So my demands are: - GPIO support (for programming the clock generator which has a simple serial interface to clock in the configuration data) Yeah, I know that I can setup the GPIOs by writing directly to the registers, but a gpio frameworks would be much nicer ;) - SPI (from the TDM module) support which works independet from NAND flash and SD-Card I have allready posted a query to arm-linux kernel mailing list and yesterday evening I have talked with Lennert on IRC regarding SPI and linux . The SPI interface is needed in u-boot to boot my lattice FPGA which is configured as slave serial device (and later on in linux to drive a touch controller). There is allready a FPGA configuration framework inside u-boot and I would like to integrate also a lattice FPGA into that. But to do this I need SPI support. What I forgot to mention is the i2c driver inside u-boot. I need this to read the mac address from an additional eeprom. This makes mass production more ease and doesn't produce hight costs :) Kirkwood has in-built i2c(TWSI) controller, well.. the plans are in place enable driver for it, but this is not blocking issue right now hence pending ;-) Just FYI: you can protect some flash sector and use it in place of eeprom, this will lower the board cost and complexity too. But if you are planning to use some different GPIOs for i2c and bit-banged driver on the top of it, then you will need gpio control, so you can do it by using simple readl/writel calls meanwhile driver to come in :-) The best way I will suggest you is: Put pre-programmed eeprom around Kirkwood TWSI interface and enable TWSI serial ROM initialization you don't need anything else for this. (I hope you are having enough kirkwood documentation) Ref: table 32: http://www.marvell.com/files/products/embedded_processors/kirkwood/HW_88F6281_OpenSource.pdf Regards.. Prafulla . . Dieter I'm willing to contribute some code if someone guides me a bit? You are most welcomed Pls feel free to raise your queries... Here they are :) Thanks, Dieter Regards.. Prafulla . . Thanks in advance, Dieter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver
-Original Message- From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] Sent: Saturday, June 13, 2009 7:32 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Manas Saksena; Ronen Shitrit; Nicolas Pitre; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek; Scott Wood Subject: Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver On 17:34 Mon 08 Jun , Prafulla Wadaskar wrote: This patch adds a NAND driver for the Marvell Kirkwood SoC's. Acked-by: Stefan Roese s...@denx.de Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log: v2: updated as per feedback for v1 (cosmetic change) Scott what is status for you? Hi Scott, I have re-posted this driver twice.. Any updates on this? Regards.. Prafulla . . Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/3] Marvell Sheevaplug Board support
-Original Message- From: Prafulla Wadaskar [mailto:prafu...@marvell.com] Sent: Monday, June 08, 2009 5:35 PM To: u-boot@lists.denx.de Cc: Nicolas Pitre; Manas Saksena; Lennert Buijtenhek; Prabhanjan Sarnaik; Ronen Shitrit; Ashish Karkare; Prafulla Wadaskar Subject: [PATCH v4 3/3] Marvell Sheevaplug Board support Reference: http://plugcomputer.org/ http://openplug.org/plugwiki/index.php/Das_U-boot_plug_support This patch is tested for- 1. Boot from DRAM/NAND flash 2. File transfer using tftp 3. NAND flash read/write/erase 4. Linux kernel and RFS Boot from NAND Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log: v2: updated as per feedback for v1 v3: updated as per feedback for v2 v4: removed PHY driver dependency, coded in sheevaplug.c Hi Jean, Network driver dependency (2/3) in this patch series is accepted by Ben Anther dependency (1/3), the nand driver is all done, waiting for reply from scott. Since this is arm board- who will be custodian to accept this patch? are you? :-) Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] envcrc: extract default environment from target ELF files
On Tuesday 16 June 2009 14:02:16 Wolfgang Denk wrote: Mike Frysinger wrote: Rather than rely on dirty hacks to compile the environment on the host and extract the CRC from that, have envcrc extract the environment straight from the ELF object that will be linked into u-boot itself. This makes the envcrc code a bit more complicated, but it simplifies the build process and host requirements because we don't have to try and recreate the environment that the target will be seeing on the host. This avoids some issues that crop up from time to time where the preprocessor defines on the host don't expand in the same way as for the target -- in case the target uses those defines to customize the environment, or the host defines conflicts with some of the target values. Can you please be a bit more specific about which sort of problems you are talking here? sure ... i'll be verbose so hopefully you can see what i see We've been using this code for many years now, but I cannot remember any problems with it. that's because the code paths have slowly acquired platform-specific hacks so that it kept working :) at any rate, here's a longer problem description and surrounding issues ... if the default environment utilizes defines that come from the toolchain in any level of indirection, the environment that is built into the target u-boot will not match the environment that is compiled on the host for crc generation. a real world example is the unified ADI config header. it generates a default environment based on functionality actually available. the BF537 family has networking hardware in some parts, but not all (BF534 does not). so we key off of the variant to determine whether to enable networking by default. or we determine that some on-chip rom functions are available for certain variants and enable only those functions. so the CPP dependency chain looks something like: - Blackfin toolchain sets up variant defines - ADI board headers set up capabilities based on variant defines - common ADI board header enables some commands based on variant defines - common ADI board header sets up default environment based on capabilities and commands available since the host toolchain does not set up the same CPP dependencies as the Blackfin toolchain, this tree falls apart and the resulting environment string that envcrc operates on differs, so the CRCs differ. i can understand your position of setting up board configs this way is wrong, but i've structured it this way because it greatly reduces my maintenance burden while increasing regression capabilities. for example, i have a Blackfin-specific patch to the MAKEALL script that allows me to regression test not only the board-specific configuration, but also uncommon or otherwise untested cpu and boot mode configurations. for example, the bf537-stamp defaults to the BF537 cpu and BYPASS boot mode. but now my regression builds can automatically verify BF534/BF536 cpu code paths as well as PARALLEL/SPI/NAND/UART code paths. previously, some changes would accidentally break these uncommon edge cases and wouldnt be noticed until someone else happened to build. to say that these code paths were horribly broken most of the time is an understatement :). i have also seen a case or two where the host toolchain inadvertently expanded things that ended up in the environment because they were not declared as strings. for example, many defines are not: #define CONFIG_FOO foo but rather they are: #define CONFIG_FOO foo just grep common/env_*.c for MKSTR() to see just how many things are affected in this way. having to worry about values here which may be arbitrarily expanded across host toolchains is a bad design practice imo. if the environment is only ever compiled by one toolchain, the target one, then it significantly reduces the chance for unexpected and unwelcomed surprises. after all, the only way to notice something has gone wrong is to build the source with a specific host toolchain, burn the image, reset, and see the dreaded CRC mismatch, using default environment error from u-boot. unless you're familiar with this problem and/or have seen/root caused this before, attempting to track down the source of this problem can be very time consuming (as it was the first time i hit this problem). common/Makefile |4 +- common/env_embedded.c | 30 +- tools/Makefile|3 +- tools/envcrc.c| 156 ++--- The diffstat indicates that the new solution is more complicated than the old one, so I'd like to understand why this is needed (or if). if LoC are the metric, then yes, but conceptually this change is simpler. the current behavior requires mixing target u-boot environment headers with the host toolchain, and a whole bunch of hacks to make sure things actually compile, produce the same end environment with
Re: [U-Boot] Marvell Kirkwood newbie question GPIO functions
Prafulla, (...deleted some stuff...) What patches are in the pipeline? Some other board supports (MV88F6281GTW_GE) and Kirkwood SPI driver support Kirkwood USB support (at this moment) Also very interesting :) (...deleted, too...) What I forgot to mention is the i2c driver inside u-boot. I need this to read the mac address from an additional eeprom. This makes mass production more ease and doesn't produce hight costs :) Kirkwood has in-built i2c(TWSI) controller, well.. the plans are in place enable driver for it, but this is not blocking issue right now hence pending ;-) Just FYI: you can protect some flash sector and use it in place of eeprom, this will lower the board cost and complexity too. But if you are planning to use some different GPIOs for i2c and bit-banged driver on the top of it, then you will need gpio control, so you can do it by using simple readl/writel calls meanwhile driver to come in :-) Yes, I thought about that, too. GPIO support will also be helpful for doing this! Do you have some snippets how to readl/writel by hand? The best way I will suggest you is: Put pre-programmed eeprom around Kirkwood TWSI interface and enable TWSI serial ROM initialization you don't need anything else for this. (I hope you are having enough kirkwood documentation) Ref: table 32: http://www.marvell.com/files/products/embedded_processors/kirkwood/HW_88F62 81_OpenSource.pdf Good idea - I will read about that. I've got access to all documents - including an marvell web account for internal documents. Regards, Dieter Regards.. Prafulla . . Dieter I'm willing to contribute some code if someone guides me a bit? You are most welcomed Pls feel free to raise your queries... Here they are :) Thanks, Dieter Regards.. Prafulla . . Thanks in advance, Dieter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ENV_IS_EMBEDDED vs CONFIG_ENV_IS_EMBEDDED
On Monday 15 June 2009 05:02:42 Wolfgang Denk wrote: Mike Frysinger wrote: is there a reason to keep ENV_IS_EMBEDDED around ? i see a few places that use CONFIG_ENV_IS_EMBEDDED, but it seems to be largely useless at the moment as the define doesn't really do anything without ENV_IS_EMBEDDED. I'm not sure where CONFIG_ENV_IS_EMBEDDED (resp. CFG_ENV_IS_EMBEDDED) coming from. I guess from some comments (short-cut compile-time test) that it was intended to enable using something like COBJS-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o Unfortunately it was not even documented in the README so we can only guess what it is supposed to mean :-( From original the software design point of view, CONFIG_ENV_IS_EMBEDDED is redundant at best, and usally just bogus, as the actual location of the environment sectors (as determined by CONFIG_ENV_OFFSET or CONFIG_ENV_ADDR combined with CONFIG_ENV_SECT_SIZE, plus eventually the definition of the corresponding *_REDUND settings) automatically determine if the environment is embedded or not - there is no need for such a variable. i would actually prefer CONFIG_ENV_IS_EMBEDDED. otherwise we have to write the makefiles to account for all CONFIG_ENV_IS_IN_XXX variants. you can see the common/Makefile and tools/Makefile already suffer from this, and the recent patch i had to post to add missing config lines for some env sources. so it would make life easier if these things bubbled up into just one config value -- easier for existing maintenance and easier for people adding new environment sources (like the newly added mgdisk, whatever that is). in other words, i'd like to just do a sed on the tree to convert all ENV_IS_EMBEDDED instances to CONFIG_ENV_IS_EMBEDDED. That whould IMHO be wrong. We should rather check if there was a way to get rid of CONFIG_ENV_IS_EMBEDDED (which is probably hard because of it's use in the Makefile). well, is there a downside from moving from ENV_IS_EMBEDDED to CONFIG_ENV_IS_EMBEDDED ? we could at least make sure it is kept in sync in common headers by doing something like: #if defined(CONFIG_ENV_IS_EMBEDDED) !defined(ENV_IS_EMBEDDED) # error you should not define CONFIG_ENV_IS_EMBEDDED yourself #endif #ifdef ENV_IS_EMBEDDED # define CONFIG_ENV_IS_EMBEDDED #endif -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Marvell Kirkwood newbie question GPIO functions
-Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Friday, June 19, 2009 3:17 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Marvell Kirkwood newbie question GPIO functions Prafulla, (...deleted some stuff...) What patches are in the pipeline? Some other board supports (MV88F6281GTW_GE) and Kirkwood SPI driver support Kirkwood USB support (at this moment) Also very interesting :) (...deleted, too...) What I forgot to mention is the i2c driver inside u-boot. I need this to read the mac address from an additional eeprom. This makes mass production more ease and doesn't produce hight costs :) Kirkwood has in-built i2c(TWSI) controller, well.. the plans are in place enable driver for it, but this is not blocking issue right now hence pending ;-) Just FYI: you can protect some flash sector and use it in place of eeprom, this will lower the board cost and complexity too. But if you are planning to use some different GPIOs for i2c and bit-banged driver on the top of it, then you will need gpio control, so you can do it by using simple readl/writel calls meanwhile driver to come in :-) Yes, I thought about that, too. GPIO support will also be helpful for doing this! Do you have some snippets how to readl/writel by hand? You can refer kw_config_gpio function in cpu/arm926ejs/kirkwood/cpu.c The best way I will suggest you is: Put pre-programmed eeprom around Kirkwood TWSI interface and enable TWSI serial ROM initialization you don't need anything else for this. (I hope you are having enough kirkwood documentation) Ref: table 32: http://www.marvell.com/files/products/embedded_processors/kir kwood/HW_8 8F62 81_OpenSource.pdf Good idea - I will read about that. I've got access to all documents - including an marvell web account for internal documents. That's very good... Regards.. Prafulla . . Regards, Dieter Regards.. Prafulla . . Dieter I'm willing to contribute some code if someone guides me a bit? You are most welcomed Pls feel free to raise your queries... Here they are :) Thanks, Dieter Regards.. Prafulla . . Thanks in advance, Dieter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Marvell Kirkwood newbie question GPIO functions
-Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Friday, June 19, 2009 3:17 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Marvell Kirkwood newbie question GPIO functions Prafulla, (...deleted some stuff...) What patches are in the pipeline? Some other board supports (MV88F6281GTW_GE) and Kirkwood SPI driver support Kirkwood USB support (at this moment) Also very interesting :) (...deleted, too...) What I forgot to mention is the i2c driver inside u-boot. I need this to read the mac address from an additional eeprom. This makes mass production more ease and doesn't produce hight costs :) Kirkwood has in-built i2c(TWSI) controller, well.. the plans are in place enable driver for it, but this is not blocking issue right now hence pending ;-) Just FYI: you can protect some flash sector and use it in place of eeprom, this will lower the board cost and complexity too. But if you are planning to use some different GPIOs for i2c and bit-banged driver on the top of it, then you will need gpio control, so you can do it by using simple readl/writel calls meanwhile driver to come in :-) Yes, I thought about that, too. GPIO support will also be helpful for doing this! Do you have some snippets how to readl/writel by hand? You can refer kw_config_gpio function in cpu/arm926ejs/kirkwood/cpu.c I will have a look and try this, thanks for the hint! The best way I will suggest you is: Put pre-programmed eeprom around Kirkwood TWSI interface and enable TWSI serial ROM initialization you don't need anything else for this. (I hope you are having enough kirkwood documentation) Ref: table 32: http://www.marvell.com/files/products/embedded_processors/kir kwood/HW_8 8F62 81_OpenSource.pdf Good idea - I will read about that. I've got access to all documents - including an marvell web account for internal documents. That's very good... Regards.. Prafulla . . Regards, Dieter Regards.. Prafulla . . Dieter I'm willing to contribute some code if someone guides me a bit? You are most welcomed Pls feel free to raise your queries... Here they are :) Thanks, Dieter Regards.. Prafulla . . Thanks in advance, Dieter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] PATCH add rgb555 for at91
Hi Detlev, RGB555 is a wiring with blue and red swapped, nothing more. Maybe I've made too much confusion before. And in the at91 eks there's nothing to change, because they're wired as BGR555. Best regards -- Giulio Benetti RD Micronova srl ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How to add new files in uboot
Hi Please let me know how to add new files in u boot. Thanks Sada Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl: remove _IO_BASE and KSEG1ADDR from board configuration files
On Tue, 2009-06-16 at 13:31 -0500, Timur Tabi wrote: Kim Phillips wrote: it's missing other boards like the MVBLM7, mpc7448hpc2... I'm not familiar with those boards, so I didn't touch them. If you give me a list of which boards I should add, I can post an updated version of the patch. MVBLM7 is mpc8343 ... please apply your patch. Thanks, André MATRIX VISION GmbH, Talstra�e 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Gesch�ftsf�hrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mpc8xxx: USB: fix: access of ehci struct elements
This patch fixes the access to the 'ehci' struct elements which should have been taken care off in 4ef01010aa4799c759d75e67007fdd3a38c88c8a Sorry about that. Signed-off-by: Vivek Mahajan vivek.maha...@freescale.com --- drivers/usb/host/ehci-fsl.c | 18 +- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c index bf148c4..c674929 100644 --- a/drivers/usb/host/ehci-fsl.c +++ b/drivers/usb/host/ehci-fsl.c @@ -41,15 +41,15 @@ int ehci_hcd_init(void) struct usb_ehci *ehci; ehci = (struct usb_ehci *)CONFIG_SYS_MPC8xxx_USB_ADDR; - hccr = (struct ehci_hccr *)((uint32_t)ehci-caplength); + hccr = (struct ehci_hccr *)((uint32_t)ehci-caplength); hcor = (struct ehci_hcor *)((uint32_t) hccr + HC_LENGTH(ehci_readl(hccr-cr_capbase))); /* Set to Host mode */ - setbits_le32((void *)ehci-usbmode, CM_HOST); + setbits_le32(ehci-usbmode, CM_HOST); - out_be32((void *)ehci-snoop1, SNOOP_SIZE_2GB); - out_be32((void *)ehci-snoop2, 0x8000 | SNOOP_SIZE_2GB); + out_be32(ehci-snoop1, SNOOP_SIZE_2GB); + out_be32(ehci-snoop2, 0x8000 | SNOOP_SIZE_2GB); /* Init phy */ if (!strcmp(getenv(usb_phy_type), utmi)) @@ -58,13 +58,13 @@ int ehci_hcd_init(void) out_le32((hcor-or_portsc[0]), PORT_PTS_ULPI); /* Enable interface. */ - setbits_be32((void *)ehci-control, USB_EN); + setbits_be32(ehci-control, USB_EN); - out_be32((void *)ehci-prictrl, 0x000c); - out_be32((void *)ehci-age_cnt_limit, 0x0040); - out_be32((void *)ehci-sictrl, 0x0001); + out_be32(ehci-prictrl, 0x000c); + out_be32(ehci-age_cnt_limit, 0x0040); + out_be32(ehci-sictrl, 0x0001); - in_le32((void *)ehci-usbmode); + in_le32(ehci-usbmode); return 0; } -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fsl: remove _IO_BASE and KSEG1ADDR from board configuration files
2009/6/19 André Schwarz andre.schw...@matrix-vision.de: MVBLM7 is mpc8343 ... please apply your patch. I posted another version of my patch that include MVBLM7. Please ACK that patch. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3][repost] nand: Add Marvell Kirkwood NAND driver
Prafulla Wadaskar wrote: Scott what is status for you? Hi Scott, I have re-posted this driver twice.. Any updates on this? Sorry, I was out the previous week and have been busy catching up this past week. I'll try to get to the stack of pending NAND stuff soon. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [PATCH v2] remove _IO_BASE and KSEG1ADDR from board configuration files
On Thu, 2009-06-18 at 17:17 -0500, Andy Fleming wrote: On Wed, Jun 17, 2009 at 4:22 PM, Nobuhiro Iwamatsu iwama...@nigauri.orgwrote: On Wed, 17 Jun 2009 10:34:55 -0500 Timur Tabi ti...@freescale.com wrote: The KSEG1ADDR macro used to be necessary for the RTL8139 Ethernet driver, but the code that used that macro was removed over a year ago, so board configuration files no longer need to define it. The _IO_BASE macro is also automatically defined to 0 if it isn't already set, so there's no need to define that macro either in the board configuration files. Signed-off-by: Timur Tabi ti...@freescale.com Acked-by: Nobuhiro Iwamatsu iwama...@nigauri.org Acked-by: Andy Fleming aflem...@freescale.com Acked-by: Andre Schwarz andre.schw...@matrix-vision.de MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Question regarding FPGA firmware load in u-boot
Hello List, I want to boot a (Lattice) FPGA from u-boot by using Slave Serial configuration on a Marvell Kirkwood device. As seen there is an (Xilinx and Altera) FPGA loader driver allready available in u-boot. Please can somebody explain how I have to provide a FPGA bitstream image to u-boot? It seems I have to create a image with mkimage? This image have to be loaded into ram and the address has to be provided to the load command? Is there a maintainer for the FPGA code inside u-boot? I'm willing to contribute some extensions for Lattice FPGAs if I'm successful! Thanks to all, Dieter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH-ARM 1/2] Add support for the Embest SBC2440-II Board
This is the first of two patches that will add support for the Embest
SBC2440-II Board. This one adds generic support for the S3C2440 CPU. Tested by
running MAKEALL for ARM9 boards - no new warnings or errors were found.
This patch set assumes that the following patches have already been applied:
- Clean-up of ARM920T S3C24x0 code, submitted on 5th June
- Clean-up of ARM920T S3C24x0 drivers code, submitted on 5th June
- Bug-fix in drivers mtd nand Makefile, submitted on 18th June
Signed-off-by: Kevin Morfitt kevin.morf...@fearnside-systems.co.uk
---
common/serial.c |4 +-
cpu/arm920t/s3c24x0/speed.c | 38 ++-
cpu/arm920t/s3c24x0/timer.c |8 +-
cpu/arm920t/s3c24x0/usb.c |9 +-
cpu/arm920t/start.S | 29 -
drivers/i2c/s3c24x0_i2c.c | 12 +-
drivers/mtd/nand/Makefile |1 +
drivers/mtd/nand/s3c2410_nand.c |8 +-
drivers/mtd/nand/s3c2440_nand.c | 241 +++
drivers/rtc/s3c24x0_rtc.c |2 +
drivers/serial/serial_s3c24x0.c |2 +
include/common.h|3 +-
include/s3c2440.h | 232 +
include/s3c24x0.h | 186 +-
14 files changed, 745 insertions(+), 30 deletions(-)
create mode 100644 drivers/mtd/nand/s3c2440_nand.c
create mode 100644 include/s3c2440.h
diff --git a/common/serial.c b/common/serial.c
index dd80e7c..6548b8b 100644
--- a/common/serial.c
+++ b/common/serial.c
@@ -58,7 +58,7 @@ struct serial_device *__default_serial_console (void)
#else
return serial0_device;
#endif
-#elif defined(CONFIG_S3C2410)
+#elif defined(CONFIG_S3C2410) || defined(CONFIG_S3C2440)
#if defined(CONFIG_SERIAL1)
return s3c24xx_serial0_device;
#elif defined(CONFIG_SERIAL2)
@@ -133,7 +133,7 @@ void serial_initialize (void)
#if defined (CONFIG_STUART)
serial_register(serial_stuart_device);
#endif
-#if defined(CONFIG_S3C2410)
+#if defined(CONFIG_S3C2410) || defined(CONFIG_S3C2440)
serial_register(s3c24xx_serial0_device);
serial_register(s3c24xx_serial1_device);
serial_register(s3c24xx_serial2_device);
diff --git a/cpu/arm920t/s3c24x0/speed.c b/cpu/arm920t/s3c24x0/speed.c
index 3d7c8cf..b8b183e 100644
--- a/cpu/arm920t/s3c24x0/speed.c
+++ b/cpu/arm920t/s3c24x0/speed.c
@@ -30,7 +30,8 @@
*/
#include common.h
-#if defined(CONFIG_S3C2400) || defined (CONFIG_S3C2410) || defined
(CONFIG_TRAB)
+#if defined(CONFIG_S3C2400) || defined(CONFIG_S3C2410) || \
+defined(CONFIG_S3C2440) || defined(CONFIG_TRAB)
#include asm/io.h
@@ -38,6 +39,8 @@
#include s3c2400.h
#elif defined(CONFIG_S3C2410)
#include s3c2410.h
+#elif defined(CONFIG_S3C2440)
+#include s3c2440.h
#endif
#define MPLL 0
@@ -69,6 +72,11 @@ static ulong get_PLLCLK(int pllreg)
p = ((r 0x003F0) 4) + 2;
s = r 0x3;
+#ifdef CONFIG_S3C2440
+ if (pllreg == MPLL)
+ return (2 * CONFIG_SYS_CLK_FREQ * m) / (p s);
+ else
+#endif
return (CONFIG_SYS_CLK_FREQ * m) / (p s);
}
@@ -83,7 +91,23 @@ ulong get_HCLK(void)
{
S3C24X0_CLOCK_POWER * const clk_power = S3C24X0_GetBase_CLOCK_POWER();
+#ifdef CONFIG_S3C2440
+ switch (clk_power-CLKDIVN 0x6) {
+ default:
+ case 0:
+ return get_FCLK();
+ case 2:
+ return get_FCLK() / 2;
+ case 4:
+ return (readl(clk_power-CAMDIVN) (1 9)) ?
+ get_FCLK() / 8 : get_FCLK() / 4;
+ case 6:
+ return (readl(clk_power-CAMDIVN) (1 8)) ?
+ get_FCLK() / 6 : get_FCLK() / 3;
+ }
+#else
return (readl(clk_power-CLKDIVN) 2) ? get_FCLK() / 2 : get_FCLK();
+#endif
}
/* return PCLK frequency */
@@ -97,9 +121,17 @@ ulong get_PCLK(void)
/* return UCLK frequency */
ulong get_UCLK(void)
{
+#ifdef CONFIG_S3C2440
+ S3C24X0_CLOCK_POWER * const clk_power = S3C24X0_GetBase_CLOCK_POWER();
+
+ return (readl(clk_power-CLKDIVN) (1 3)) ?
+ get_PLLCLK(UPLL) / 2 : get_PLLCLK(UPLL);
+#else
return get_PLLCLK(UPLL);
+#endif
}
#endif /* defined(CONFIG_S3C2400) ||
- defined (CONFIG_S3C2410) ||
- defined (CONFIG_TRAB) */
+ defined (CONFIG_S3C2410) ||
+ defined (CONFIG_S3C2440) ||
+ defined (CONFIG_TRAB) */
diff --git a/cpu/arm920t/s3c24x0/timer.c b/cpu/arm920t/s3c24x0/timer.c
index a5a784c..0f6b580 100644
--- a/cpu/arm920t/s3c24x0/timer.c
+++ b/cpu/arm920t/s3c24x0/timer.c
@@ -32,6 +32,7 @@
#include common.h
#if defined(CONFIG_S3C2400) || \
defined(CONFIG_S3C2410) || \
+defined(CONFIG_S3C2440) || \
defined(CONFIG_TRAB)
#include asm/io.h
@@ -40,6 +41,8 @@
#include s3c2400.h
#elif defined(CONFIG_S3C2410)
#include s3c2410.h
+#elif defined(CONFIG_S3C2440)
+#include s3c2440.h
#endif
int timer_load_val = 0;
@@ -230,5 +233,6 @@
[U-Boot] [PATCH-ARM 2/2] Add support for the Embest SBC2440-II Board
This is the second of two patches that will add support for the Embest SBC2440-II Board. This one adds the new code for the Embest SBC2440-II Board. Tested on an Embest SBC2440-II Board with u-boot in NOR flash, using tftp to copy kernel and root file system images from a tftp server, programming them into NAND flash and ensuring the kernel boots correctly at re-start. Also, MAKEALL was run for all ARM9 boards and no new warnings or errors were found. Signed-off-by: Kevin Morfitt kevin.morf...@fearnside-systems.co.uk --- MAINTAINERS|4 + MAKEALL|1 + Makefile |3 + board/embest/sbc2440ii/Makefile| 55 ++ board/embest/sbc2440ii/config.mk | 25 +++ board/embest/sbc2440ii/lowlevel_init.S | 219 +++ board/embest/sbc2440ii/sbc2440ii.c | 109 cpu/arm920t/s3c24x0/timer.c|1 + drivers/mtd/nand/s3c2440_nand.c|9 +- include/configs/sbc2440ii.h| 299 10 files changed, 722 insertions(+), 3 deletions(-) create mode 100644 board/embest/sbc2440ii/Makefile create mode 100644 board/embest/sbc2440ii/config.mk create mode 100644 board/embest/sbc2440ii/lowlevel_init.S create mode 100644 board/embest/sbc2440ii/sbc2440ii.c create mode 100644 include/configs/sbc2440ii.h diff --git a/MAINTAINERS b/MAINTAINERS index 9379c7e..39c938e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -578,6 +578,10 @@ Nishanth Menon n...@ti.com omap3_zoom1 ARM CORTEX-A8 (OMAP3xx SoC) +Kevin Morfitt kevin.morf...@fearnside-systems.co.uk + + sbc2440ii ARM920T + David Müller d.muel...@elsoft.ch smdk2410ARM920T diff --git a/MAKEALL b/MAKEALL index f4599d6..ae95ffa 100755 --- a/MAKEALL +++ b/MAKEALL @@ -519,6 +519,7 @@ LIST_ARM9= \ omap5912osk \ omap730p2 \ sbc2410x\ + sbc2440ii \ scb9328 \ smdk2400\ smdk2410\ diff --git a/Makefile b/Makefile index acec1a0..ddcb1cc 100644 --- a/Makefile +++ b/Makefile @@ -2900,6 +2900,9 @@ omap730p2_cs3boot_config :unconfig sbc2410x_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm920t sbc2410x NULL s3c24x0 +sbc2440ii_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm920t sbc2440ii embest s3c24x0 + scb9328_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm920t scb9328 NULL imx diff --git a/board/embest/sbc2440ii/Makefile b/board/embest/sbc2440ii/Makefile new file mode 100644 index 000..f791f39 --- /dev/null +++ b/board/embest/sbc2440ii/Makefile @@ -0,0 +1,55 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# Modified for EMBEST SBC2440-II board with S3C2440 (ARM920T) cpu by: +# (C) Copyright 2009 +# Kevin Morfitt, Fearnside Systems Ltd, kevin.morf...@fearnside-systems.co.uk +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).a + +COBJS := sbc2440ii.o +SOBJS := lowlevel_init.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB): $(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/embest/sbc2440ii/config.mk b/board/embest/sbc2440ii/config.mk new file mode 100644 index 000..def11d8 --- /dev/null +++ b/board/embest/sbc2440ii/config.mk @@ -0,0 +1,25 @@ +# +# (C) Copyright 2002 +# Gary Jennejohn, DENX Software Engineering, g...@denx.de +# David Mueller, ELSOFT AG, d.muel...@elsoft.ch +# +# SAMSUNG SMDK2410 board with S3C2410X (ARM920T) cpu +# +# see http://www.samsung.com/ for more information on SAMSUNG +# +#
[U-Boot] u-boot gdb
I've been using gdb with u-boot via openocd. I'm sure others are doing something similar, but I did a quick entry on what I'm doing. Maybe someone else will find it usefull. http://openhardware.wordpress.com/2009/06/19/u-boot-gdb/ thanks, Paul ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [PATCH v2] remove _IO_BASE and KSEG1ADDR from board configuration files
On Wed, 17 Jun 2009 10:34:55 -0500 Timur Tabi ti...@freescale.com wrote: The _IO_BASE macro is also automatically defined to 0 if it isn't already set, so there's no need to define that macro either in the board configuration files. ... +++ b/include/configs/PN62.h @@ -133,8 +133,6 @@ #define CONFIG_PCNET /* there are 2 AMD PCnet 79C973 */ #define CONFIG_PCNET_79C973 -#define _IO_BASE 0xfe00 /* points to PCI I/O space */ - but the PN62 doesn't set it to 0! Kim Cc: Wolfgang Grandegger (PN62 maintainer) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [PATCH v2] remove _IO_BASE and KSEG1ADDR from board configuration files
Kim Phillips wrote: -#define _IO_BASE0xfe00 /* points to PCI I/O space */ - but the PN62 doesn't set it to 0! Doh! I don't know how I missed that. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] remove _IO_BASE and KSEG1ADDR from board configuration files
The KSEG1ADDR macro used to be necessary for the RTL8139 Ethernet driver, but
the code that used that macro was removed over a year ago, so board
configuration files no longer need to define it.
The _IO_BASE macro is also automatically defined to 0 if it isn't already set,
so there's no need to define that macro either in the board configuration files.
Signed-off-by: Timur Tabi ti...@freescale.com
Acked-by: Nobuhiro Iwamatsu iwama...@nigauri.org
Acked-by: Andy Fleming aflem...@freescale.com
Acked-by: Andre Schwarz andre.schw...@matrix-vision.de
---
v3: removed the change for PN62.h, which does not have _IO_BASE at 0
include/configs/HIDDEN_DRAGON.h |4 +---
include/configs/M5253DEMO.h |1 -
include/configs/M5253EVBE.h |1 -
include/configs/M54455EVB.h |1 -
include/configs/MPC8349ITX.h|7 ---
include/configs/MPC8536DS.h |6 --
include/configs/MPC8544DS.h |6 --
include/configs/MPC8572DS.h |6 --
include/configs/MPC8610HPCD.h |4
include/configs/MPC8641HPCN.h |4
include/configs/MVBLM7.h|2 --
include/configs/P2020DS.h |6 --
include/configs/mpc7448hpc2.h |4
include/configs/r2dplus.h |2 --
14 files changed, 1 insertions(+), 53 deletions(-)
diff --git a/include/configs/HIDDEN_DRAGON.h b/include/configs/HIDDEN_DRAGON.h
index f6777b9..251fe67 100644
--- a/include/configs/HIDDEN_DRAGON.h
+++ b/include/configs/HIDDEN_DRAGON.h
@@ -103,9 +103,7 @@
#define PCI_ENET1_MEMADDR 0x8100
#define CONFIG_RTL8139
-#define _IO_BASE 0x
-/* This macro is used by RTL8139 but not defined in PPC architecture */
-#define KSEG1ADDR(x) (x)
+
/* Make sure the ethaddr can be overwritten
TODO: Remove this on final product
*/
diff --git a/include/configs/M5253DEMO.h b/include/configs/M5253DEMO.h
index 50b3a03..5e86e4c 100644
--- a/include/configs/M5253DEMO.h
+++ b/include/configs/M5253DEMO.h
@@ -85,7 +85,6 @@
# define CONFIG_SYS_ATA_REG_OFFSET0xA0/* Offset for normal
register accesses */
# define CONFIG_SYS_ATA_ALT_OFFSET0xC0/* Offset for alternate
registers */
# define CONFIG_SYS_ATA_STRIDE4 /* Interval between
registers */
-# define _IO_BASE 0
#endif
#define CONFIG_NET_MULTI 1
diff --git a/include/configs/M5253EVBE.h b/include/configs/M5253EVBE.h
index cf8b773..df6970c 100644
--- a/include/configs/M5253EVBE.h
+++ b/include/configs/M5253EVBE.h
@@ -91,7 +91,6 @@
#define CONFIG_SYS_ATA_REG_OFFSET 0xA0/* Offset for normal register
accesses */
#define CONFIG_SYS_ATA_ALT_OFFSET 0xC0/* Offset for alternate
registers */
#define CONFIG_SYS_ATA_STRIDE 4 /* Interval between registers */
-#define _IO_BASE 0
#define CONFIG_SYS_PROMPT =
#define CONFIG_SYS_LONGHELP/* undef to save memory */
diff --git a/include/configs/M54455EVB.h b/include/configs/M54455EVB.h
index 101dced..87f3a73 100644
--- a/include/configs/M54455EVB.h
+++ b/include/configs/M54455EVB.h
@@ -180,7 +180,6 @@
#define CONFIG_SYS_ATA_REG_OFFSET 0xA0/* Offset for normal register
accesses */
#define CONFIG_SYS_ATA_ALT_OFFSET 0xC0/* Offset for alternate
registers */
#define CONFIG_SYS_ATA_STRIDE 4 /* Interval between registers
*/
-#define _IO_BASE 0
/* Realtime clock */
#define CONFIG_MCFRTC
diff --git a/include/configs/MPC8349ITX.h b/include/configs/MPC8349ITX.h
index f2e574b..d4d3256 100644
--- a/include/configs/MPC8349ITX.h
+++ b/include/configs/MPC8349ITX.h
@@ -360,16 +360,9 @@ boards, we say we have two, but don't display a message if
we find only one. */
#define CONFIG_SYS_PCI2_IO_SIZE0x0100 /* 16M */
#endif
-#define _IO_BASE 0x /* points to PCI I/O space */
-
#define CONFIG_NET_MULTI
#define CONFIG_PCI_PNP /* do pci plug-and-play */
-#ifdef CONFIG_RTL8139
-/* This macro is used by RTL8139 but not defined in PPC architecture */
-#define KSEG1ADDR(x) (x)
-#endif
-
#ifndef CONFIG_PCI_PNP
#define PCI_ENET0_IOADDR 0x
#define PCI_ENET0_MEMADDR CONFIG_SYS_PCI2_MEM_BASE
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index 9e00b89..7085d28 100644
--- a/include/configs/MPC8536DS.h
+++ b/include/configs/MPC8536DS.h
@@ -427,12 +427,6 @@ extern unsigned long get_board_ddr_clk(unsigned long
dummy);
#undef CONFIG_TULIP
#undef CONFIG_RTL8139
-#ifdef CONFIG_RTL8139
-/* This macro is used by RTL8139 but not defined in PPC architecture */
-#define KSEG1ADDR(x) ({u32 _x=le32_to_cpu(*(u32 *)(x)); (_x);})
-#define _IO_BASE 0x
-#endif
-
#ifndef CONFIG_PCI_PNP
#define PCI_ENET0_IOADDRCONFIG_SYS_PCI1_IO_BUS
#define PCI_ENET0_MEMADDR CONFIG_SYS_PCI1_IO_BUS
diff --git
Re: [U-Boot] [PATCH v3] remove _IO_BASE and KSEG1ADDR from board configuration files
On Fri, 19 Jun 2009 14:10:52 -0500 Timur Tabi ti...@freescale.com wrote: The KSEG1ADDR macro used to be necessary for the RTL8139 Ethernet driver, but the code that used that macro was removed over a year ago, so board configuration files no longer need to define it. The _IO_BASE macro is also automatically defined to 0 if it isn't already set, so there's no need to define that macro either in the board configuration files. Signed-off-by: Timur Tabi ti...@freescale.com Acked-by: Nobuhiro Iwamatsu iwama...@nigauri.org Acked-by: Andy Fleming aflem...@freescale.com Acked-by: Andre Schwarz andre.schw...@matrix-vision.de --- ack Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM 1/2] Add support for the Embest SBC2440-II Board
Dear kevin.morf...@fearnside-systems.co.uk, In message 4a3bc001.3010...@fearnside-systems.co.uk you wrote: This is the first of two patches that will add support for the Embest SBC2440-II Board. This one adds generic support for the S3C2440 CPU. Tested by running MAKEALL for ARM9 boards - no new warnings or errors were found. This patch set assumes that the following patches have already been applied: - Clean-up of ARM920T S3C24x0 code, submitted on 5th June - Clean-up of ARM920T S3C24x0 drivers code, submitted on 5th June - Bug-fix in drivers mtd nand Makefile, submitted on 18th June Signed-off-by: Kevin Morfitt kevin.morf...@fearnside-systems.co.uk Reviewed-by: Wolfgang Denk w...@denx.de 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 Monday is an awful way to spend one seventh of your life. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH-ARM 2/2] Add support for the Embest SBC2440-II Board
Dear kevin.morf...@fearnside-systems.co.uk, In message 4a3bc007.4060...@fearnside-systems.co.uk you wrote: This is the second of two patches that will add support for the Embest SBC2440-II Board. This one adds the new code for the Embest SBC2440-II Board. Tested on an Embest SBC2440-II Board with u-boot in NOR flash, using tftp to copy kernel and root file system images from a tftp server, programming them into NAND flash and ensuring the kernel boots correctly at re-start. Also, MAKEALL was run for all ARM9 boards and no new warnings or errors were found. Signed-off-by: Kevin Morfitt kevin.morf...@fearnside-systems.co.uk ... diff --git a/board/embest/sbc2440ii/lowlevel_init.S b/board/embest/sbc2440ii/lowlevel_init.S new file mode 100644 index 000..697c2a2 --- /dev/null +++ b/board/embest/sbc2440ii/lowlevel_init.S @@ -0,0 +1,219 @@ ... +_TEXT_BASE: + .word TEXT_BASE + +.globl lowlevel_init +lowlevel_init: + /* memory control configuration */ + /* make r0 relative the current location so that it */ + /* reads SMRDATA out of FLASH rather than memory ! */ + ldr r0, =SMRDATA + ldr r1, _TEXT_BASE + sub r0, r0, r1 + ldr r1, =BWSCON /* Bus Width Status Controller */ + add r2, r0, #13*4 +0: + ldr r3, [r0], #4 + str r3, [r1], #4 + cmp r2, r0 + bne 0b + + /* everything is fine now */ + mov pc, lr Indentation by TAB, please. diff --git a/include/configs/sbc2440ii.h b/include/configs/sbc2440ii.h new file mode 100644 index 000..26ad15d --- /dev/null +++ b/include/configs/sbc2440ii.h ... +/* + * select serial console configuration + */ +#define CONFIG_S3C24X0_SERIAL +#define CONFIG_SERIAL1 1 /* we use SERIAL 1 on SBC2440-II */ + +/ + * RTC + / +#define CONFIG_RTC_S3C24X0 1 + +/* allow to overwrite serial and ethaddr */ +#define CONFIG_ENV_OVERWRITE + +#define CONFIG_BAUDRATE 115200 + + You may want to sort this file a bit; I wouyld expect to find CONFIG_BAUDRATE in the serial console configuration section, not in RTC, etc. Also, please avoid these multiple empty lines when they don't really make sense (like here). +/* + * BOOTP options + */ +#define CONFIG_BOOTP_BOOTFILESIZE +#define CONFIG_BOOTP_BOOTPATH +#define CONFIG_BOOTP_GATEWAY +#define CONFIG_BOOTP_HOSTNAME + + +/* ... or here. +#define CONFIG_LOADADDR 30008000 +/*#define CONFIG_BOOTFILEelinos-lart */ Please do not add dead code. +#define CONFIG_BOOTCOMMAND nboot 30008000 0 0 +/*#define CONFIG_NFSBOOTCOMMAND NFS_BOOTARGS*/ Please do not add dead code. +/* the PWM TImer 4 uses a counter of 15625 for 10 ms, so we need */ +/* it to wrap 100 times (total 1562500) to get 1 sec. */ +#define CONFIG_SYS_HZ1562500 CONFIG_SYS_HZ *must* be set to 1000. Full NAK because of that. Please fix and resubmit. 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 Wenn Du ein' weise Antwort verlangst, Mußt Du vernünftig fragen. -- Goethe, Invektiven ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-book and GPLv3? (fwd)
There's only one thing about U-Boot that doesn't seem so good: U-Boot is GPLv2 (sometimes or later). To have some parts which are GPLv2 only is unfortunate. Is there any chance of convincing those authors to change that? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] iMX27 PDK board support
We have support for the MX35-3-Stack, you might want to have a look at that code if you are working into that direction. Where can i find the MX35-3-Stack patches? Does it support boot from NAND and does it have the NAND flash driver already? Thanks, Alfred ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] iMX27 PDK board support
Where can i find the MX35-3-Stack patches? Does it support boot from NAND and does it have the NAND flash driver already? Are you talking about this in the GIT? http://git.denx.de/?p=u-boot/u-boot-v2.git;a=tree;f=board;h=1b079f6910333c85920da3331cc93675447695d7;hb=aec91d05374bd4a0babc0d6ad2e4e78252304cd0 Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] fec_imx27: driver for FEC ethernet controller on i.MX27
Dear Johan, In message de9b121e0906160012q5975b23cnd320908aee6cd...@mail.gmail.com you wrote: Seems like that was the trick. After removing the breakout board it works much better. I still got some problems which I don't know if its software related. Sometimes when I power on the board the ethernet LEDs does not turn green and the network does not work. If I power cycle the board a number of times the LEDs turn green I can can use the network. Do you know if that might be hw related or may it be something with the initialization? This is most likely a hardware problem. Please contach Logic for information about the required changes on the board. 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 May the forces of evil become confused on the way to your house. - George Carlin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm nomadik: rename board and cleanup config
On 22:54 Thu 18 Jun , Alessandro Rubini wrote: From: Alessandro Rubini rub...@unipv.it This patch cleans up some glitches in the initial submission: - nobody calls it nmdk8815: the board is nhk8815, so rename - nand and onenand can coexist, so fix config file accordingly - configure the chip select for OneNand, so it works properly - removed a pair of unused defines and reordered the jffs defs - add some comments and an explanation of the two configs Signed-off-by: Alessandro Rubini rub...@unipv.it Acked-by: Andrea Gallo andrea.ga...@stericsson.com --- If needed I can split this, but I think it's trivial enough. Over this I'll send a few additions in the next days. yes please split it as this PATCH 1 the rename patch 2 the board cleanup patch 3 reset cleanup patch 4 the nand , onenand or something similar please we need to be able to bisect each change otherwise fine Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mtd: Update MTD infrastructure to support 64bit device size
Dear Stefan,
having this patch in mainline [1] now, I have some issues with it. I
use omap3_beagle_config (ARM). There was already a short discussion
with Wolfgang on IRC regarding this, he directed my to you ;) I
identified three topics, two minor and one major one:
Stefan Roese wrote:
This patch brings the U-Boot MTD infrastructure in sync with the current
Linux MTD version (2.6.30-rc3). Biggest change is the 64bit device size
support and a resync of the mtdpart.c file which has seen multiple fixes
meanwhile.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Scott Wood scottw...@freescale.com
Cc: Kyungmin Park kmp...@infradead.org
---
common/cmd_onenand.c |6 +-
common/env_onenand.c |2 +-
drivers/mtd/cfi_mtd.c|4 +-
drivers/mtd/mtdpart.c| 488
+++---
drivers/mtd/nand/nand_util.c | 11 +-
include/linux/mtd/mtd.h | 29 ++-
6 files changed, 256 insertions(+), 284 deletions(-)
diff --git a/common/cmd_onenand.c b/common/cmd_onenand.c
index 5832ff8..e8f06d7 100644
--- a/common/cmd_onenand.c
+++ b/common/cmd_onenand.c
@@ -19,6 +19,10 @@
#include asm/io.h
+#if !defined(CONFIG_SYS_64BIT_VSPRINTF)
+#warning Please define CONFIG_SYS_64BIT_VSPRINTF for correct output!
+#endif
+
1. This preprocessor warning is annoying. Why not enable it in all
configs where needed and then remove this warning here?
diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h
index 354e3a0..c884567 100644
--- a/include/linux/mtd/mtd.h
+++ b/include/linux/mtd/mtd.h
@@ -8,6 +8,7 @@
#define __MTD_MTD_H__
#include linux/types.h
+#include div64.h
#include linux/mtd/mtd-abi.h
#define MTD_CHAR_MAJOR 90
@@ -20,6 +21,8 @@
#define MTD_ERASE_DONE 0x08
#define MTD_ERASE_FAILED0x10
+#define MTD_FAIL_ADDR_UNKNOWN-1LL
+
/*
* Enumeration for NAND/OneNAND flash chip state
*/
@@ -37,13 +40,13 @@ enum {
};
/* If the erase fails, fail_addr might indicate exactly which block failed.
If
- fail_addr = 0x, the failure was not at the device level or was not
+ fail_addr = MTD_FAIL_ADDR_UNKNOWN, the failure was not at the device
level or was not
specific to any particular block. */
struct erase_info {
struct mtd_info *mtd;
- u_int32_t addr;
- u_int32_t len;
- u_int32_t fail_addr;
+ uint64_t addr;
+ uint64_t len;
+ uint64_t fail_addr;
u_long time;
u_long retries;
u_int dev;
@@ -55,7 +58,7 @@ struct erase_info {
};
struct mtd_erase_region_info {
- u_int32_t offset; /* At which this region starts,
from the beginning of the MTD */
+ uint64_t offset;/* At which this region starts,
from the beginning of the MTD */
u_int32_t erasesize;/* For this region */
u_int32_t numblocks;/* Number of blocks of erasesize in
this region */
unsigned long *lockmap; /* If keeping bitmap of locks */
@@ -110,7 +113,7 @@ struct mtd_oob_ops {
struct mtd_info {
u_char type;
u_int32_t flags;
- u_int32_t size; /* Total size of the MTD */
+ uint64_t size; // Total size of the MTD
2. C++ style comment. Found by Wolfgang ;)
3. The major one: By the new 64bit variables, depending on tool chain,
there are now calls to libgcc introduced. Depending on tool chain,
this might work, or fail. As it does with one of my tool chains, which
worked totally fine until here. It was my understanding that U-Boot
shall not rely on libgcc, i.e. proper tool chain libraries.
Having CONFIG_SYS_64BIT_VSPRINTF not defined, the linker needs
_lshrdi3, which comes from nand_base.o and nand_bbt.o. E.g. from
len = mtd-size (this-bbt_erase_shift + 2); from nand_bbt.c.
Having CONFIG_SYS_64BIT_VSPRINTF enabled, the linker requests
_lshrdi3, _udivdi3, _umoddi3 and _clz from libgcc.
Looking into U-Boot's lib_arm/ directory, we have already some low
level math functions there to avoid libgcc. E.g. nand_bbt.c has
references to _ashrdi3, too, but this is resolved by lib_arm's version
what is fine.
I'd like that NAND code is modified that only math is used which
U-Boot provides and no libgcc is needed.
Best regards
Dirk
[1]
http://git.denx.de/?p=u-boot.git;a=commit;h=8d2effea23e938631126a7888008a0637e13b389
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
