Re: [U-Boot-Users] arm SoC code in U-Boot.
Hi I see from http://www.freescale.com/webapp/sps/site/homepage.jsp?nodeId=02XPgQ82172 973 that there are IMX SOCs with three different ARM cores (920, 926, 1136).
Hopefully, there would be some commonality in the u-boot imx code - so repeating it under the individual cpus seems wasteful.
Arguably freescale could produce a SOC with someone else's core
(although I think that would be a silly idea of course ;-> )
I could live with cpu/freescale/imx. Presumably it would be built in via the SOC value?
Regards
Peter
In message 89A528FE6DB0FA44877BB2F05B84671805650CA4@ZIPPY.Emea.Arm.com you wrote:
I could live with cpu/freescale/imx. Presumably it would be built in via the SOC value?
Do we really need the "freescale" subdirectory here? Maybe cpu/arm_imx would be a shorter and more descriptive name?
Best regards,
Wolfgang Denk
link: www.avrfreaks.net ----- Original Message ----- From: "Wolfgang Denk" wd@denx.de To: "Peter Pearse" Peter.Pearse@arm.com Cc: u-boot-users@lists.sourceforge.net; "Ulf Samuelsson" ulf@atmel.com; "Txema Lopez" tlopez@aotek.es; "Grant Likely" grant.likely@secretlab.ca Sent: Tuesday, March 06, 2007 10:36 PM Subject: Re: [U-Boot-Users] arm SoC code in U-Boot.
In message 89A528FE6DB0FA44877BB2F05B84671805650CA4@ZIPPY.Emea.Arm.com you wrote:
I could live with cpu/freescale/imx. Presumably it would be built in via the SOC value?
Do we really need the "freescale" subdirectory here? Maybe cpu/arm_imx would be a shorter and more descriptive name?
Best regards,
Wolfgang Denk
I think it is a matter of taste. You actually do not need to have any subdirectories in U-boot at all. Some people prefer using a directory structure to hide information which is of little interest to them
There seems to be shared code for PowerPCs and NIOS(2). Do we want to create new subdirectories for every share, cluttering up "cpu"?
I think the likelyhood for shared code between different Freescale PPC is higher than shared code between IBM and Freescale PPC. Therefore a "freescale" directory could also contains shared PPC code.
Some people would like to have consistency making it easy to find where things are located.
If you look at what is driving duplication, then you find that the peripherals are either developed inside a semiconductor company, or they are licensed from an IP provider.
It makes a lot of sense therefore to dedicate directories to the providers of IP: ARM is a provider, but so are also Freescale, Atmel and others.
Best Regards Ulf Samuelsson
In message 006701c7603a$95ed3930$01c4af0a@Glamdring you wrote:
----- Original Message -----
Please don't top-post / full quote. Thanks.
Do we really need the "freescale" subdirectory here? Maybe cpu/arm_imx would be a shorter and more descriptive name?
...
I think it is a matter of taste.
Agreed.
Some people would like to have consistency making it easy to find where things are located.
To me making it easy to find where things are located includes not to add unnecessary directory levels.
When adding "cpu/freescale/" I see no clear line what should go in there and what not. Whould we then move all the cpu/mpc???/ directories into cpu/freescale/ ? And then probably create (for consistency) a "cpu/amcc/" directory and mode cpu/ppc4xx into that one? What do we get in addition to another directory level? IMO that would not improve anything, and you still don't see where shared code is located.
If you look at what is driving duplication, then you find that the peripherals are either developed inside a semiconductor company, or they are licensed from an IP provider.
It makes a lot of sense therefore to dedicate directories to the providers of IP: ARM is a provider, but so are also Freescale, Atmel and others.
Well, where did license Freescale the IMX core from? I don't think that we should focus on vendor names here, but instead on content. And the content is "ARM IMX" related code. Assuming that is CPU specific enough to go under "cpu/", I feel we should either add a "cpu/imx" directory or - a little more descriptive - "cpu/arm_imx/" as suggested above. Even "cpu/arm/imx/" seems more natural to me than "cpu/freescale/imx/".
Best regards,
Wolfgang Denk
Do we really need the "freescale" subdirectory here? Maybe cpu/arm_imx would be a shorter and more descriptive name?
...
I think it is a matter of taste.
Agreed.
Some people would like to have consistency making it easy to find where things are located.
To me making it easy to find where things are located includes not to add unnecessary directory levels.
When adding "cpu/freescale/" I see no clear line what should go in there and what not. Whould we then move all the cpu/mpc???/ directories into cpu/freescale/ ? And then probably create (for consistency) a "cpu/amcc/" directory and mode cpu/ppc4xx into that one? What do we get in addition to another directory level? IMO that would not improve anything, and you still don't see where shared code is located.
I think you can still keep the cpu/ppc4xx directory but if you find that cpu/ppcYYY has shared code with the cpu/ppc4xx and you would like to have a common driver, then you put it in "cpu/amcc/ppc.
For freescale you would put shared code in cpu/freescale/imx and cpu/freescale/ppc and maybe cpu/freescale/coldfire
If you look at what is driving duplication, then you find that the peripherals are either developed inside a semiconductor company, or they are licensed from an IP provider.
It makes a lot of sense therefore to dedicate directories to the providers of IP: ARM is a provider, but so are also Freescale, Atmel and others.
Well, where did license Freescale the IMX core from? I don't think that we should focus on vendor names here, but instead on content. And the content is "ARM IMX" related code. Assuming that is CPU specific enough to go under "cpu/", I feel we should either add a "cpu/imx" directory or - a little more descriptive - "cpu/arm_imx/" as suggested above. Even "cpu/arm/imx/" seems more natural to me than "cpu/freescale/imx/".
I might be wrong, but think the issue is that Freescale has some common peripherals which are used both on ARM926EJS and ARM920T chips.
If the peripherals are licensed from ARM, then I think that the peripheral might be in use in other ARM chipa I.E. non-imx chips as well and "cpu/arm" would be OK, but not "cpu/arm/imx" . If the peripherals are developed by Freescale, then if they happen to use the peripheral on a non-ARM chip then the cpu/arm/imx is no good and cpu/arm_imx is also no good. "cpu/freescale" is then much better for generic stuff and "cpu/freescale/imx" for things shared only among imx chips. .
cpu/arm could be a directory, but then it is
Best regards,
Wolfgang Denk
Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57
Technical support when I am not available: AT89 C51 Applications Group: mailto:micro.hotline@nto.atmel.com AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR link: www.avrfreaks.net
Hopefully this is an easy one. At first glance this looks like the FAQ question but there is a difference.
First the background:
I have what I believe is an SDRAM issue. Linux intermittently locks up upon boot and I have verified that when this happens there is bad or invalid instructions at certain memory locations after U-boot uncompresses the image and loads it into RAM. I have a few boards that have never exhibited this problem and some boards that intermittently exhibit this problem. I have written a test that uncompress and loads the image into SDRAM then, rather that booting it, compares the uncompressed image to a copy of the uncompressed image residing in a higher area of flash. This way I can run it in a loop and see the intermittent failures.
The real reason I'm writing here is because to verify that it is an SDRAM issue I wanted to inhibit caching of the SDRAM figuring that this would allow thing to work without all the SDRAM bursting. When I do this however I get a crash at the "U-boot relocating to..." line. I'm using an MPC8245 and have tried the following combination of iBAT and dBAT settings for the SDRAM with the following results:
- iBAT = memory coherence, dBAT = memory coherence, U-boot works - iBAT = cache inhibit, dBAT = memory coherence, U-boot works - iBAT = memory coherence, dBAT = cache inhibit, U-boot fails - iBAT = cache inhibit, dBAT = cache inhibit, U-boot fails
In summary U-boot works with caching but it fails whenever the dBAT is set to cache inhibit for the SDRAM. Is this expected operation or is it further indication of an SDRAM problem?
David Clark Senior Software Engineer C&H Technologies, Inc Web: http:\www.chtech.com Phone: 512-733-2621 Fax: 512-733-2629 Email: dlclark@chtech.com
In message 008001c7604a$661c0ff0$0f01a8c0@longhorn you wrote:
...
using an MPC8245 and have tried the following combination of iBAT and
...
In summary U-boot works with caching but it fails whenever the dBAT is set to cache inhibit for the SDRAM. Is this expected operation or is it further indication of an SDRAM problem?
See the README. "Data cache ... cannot be disabled ..."
Best regards,
Wolfgang Denk
See the README. "Data cache ... cannot be disabled ..."
To be thorough, I am not disabling cache; I am instead marking the SDRAM as cache inhibited via the BAT registers.
It was my understanding (apparently incorrect), from the README that the reason "Data cache ... cannot be disabled ..." was due to the (mis-) use cache for initialization purposes. In my case my data cache is still enabled and my CFG_INIT_RAM_ADDR block is still cacheable.
Is my understanding flawed?
David Clark Senior Software Engineer C&H Technologies, Inc Web: http:\www.chtech.com Phone: 512-733-2621 Fax: 512-733-2629 Email: dlclark@chtech.com
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: Tuesday, March 06, 2007 6:06 PM To: David Clark Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] SDRAM cache inhibit
In message 008001c7604a$661c0ff0$0f01a8c0@longhorn you wrote:
...
using an MPC8245 and have tried the following combination of iBAT and
...
In summary U-boot works with caching but it fails whenever the dBAT is set to cache inhibit for the SDRAM. Is this expected operation or is
it
further indication of an SDRAM problem?
See the README. "Data cache ... cannot be disabled ..."
Best regards,
Wolfgang Denk
On Tuesday 06 March 2007 23:45, Ulf Samuelsson wrote:
When adding "cpu/freescale/" I see no clear line what should go in there and what not. Whould we then move all the cpu/mpc???/ directories into cpu/freescale/ ? And then probably create (for consistency) a "cpu/amcc/" directory and mode cpu/ppc4xx into that one? What do we get in addition to another directory level? IMO that would not improve anything, and you still don't see where shared code is located.
I think you can still keep the cpu/ppc4xx directory but if you find that cpu/ppcYYY has shared code with the cpu/ppc4xx and you would like to have a common driver, then you put it in "cpu/amcc/ppc.
For freescale you would put shared code in cpu/freescale/imx and cpu/freescale/ppc and maybe cpu/freescale/coldfire
I still think that this code we are talking about here, is most likely some driver code for some ethernet controller, or a I2C controller etc. I would like to "collect" this sort of driver code, even if it's SoC driver code, under the "drivers" directory. This is already done for some drivers but it's not done consistently. We already have:
drivers/qe/* drivers/netarm_eth.* drivers/omap1510_i2c.* ...
Why not try to match this a little more to the Linux directory structure:
drivers/net/netarm_eth.* drivers/net/qe/* drivers/i2c/omap1510_i2c.* ...
From my understanding the drivers mentioned above will fit in here much better than in some cpu directories. Just my 0.02$.
BTW: I know it's always a problem to "move" code in a version control system because of the revision history.
Best regards, Stefan
===================================================================== DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany =====================================================================
On 3/7/07, Stefan Roese sr@denx.de wrote:
Why not try to match this a little more to the Linux directory structure:
drivers/net/netarm_eth.* drivers/net/qe/* drivers/i2c/omap1510_i2c.* ...
I think this is a great idea. Grouping drivers together by function makes them much easier to find, and it's also easier to find examples when you're writing a new driver. With the current layout, you have to grep through the drivers, cpu and board hierarchies to find existing drivers similar to the one you're trying to write.
From my understanding the drivers mentioned above will fit in here much better
than in some cpu directories. Just my 0.02$.
BTW: I know it's always a problem to "move" code in a version control system because of the revision history.
git makes it much less of a problem than many other version control systems.
Haavard
On Wed, 2007-03-07 at 13:37 +0100, Haavard Skinnemoen wrote:
On 3/7/07, Stefan Roese sr@denx.de wrote:
Why not try to match this a little more to the Linux directory structure:
drivers/net/netarm_eth.* drivers/net/qe/* drivers/i2c/omap1510_i2c.* ...
I think this is a great idea. Grouping drivers together by function makes them much easier to find, and it's also easier to find examples when you're writing a new driver. With the current layout, you have to grep through the drivers, cpu and board hierarchies to find existing drivers similar to the one you're trying to write.
Stellar idea. The more logically drivers are grouped, the easier it will to transition to a menuconfig-based system, which would be pretty cool, don't you think?
Ben
In message 1defaf580703070437x2d36edd8q52bc86a41d7df2f2@mail.gmail.com you wrote:
On 3/7/07, Stefan Roese sr@denx.de wrote:
Why not try to match this a little more to the Linux directory structure:
drivers/net/netarm_eth.* drivers/net/qe/* drivers/i2c/omap1510_i2c.* ...
I think this is a great idea. Grouping drivers together by function makes them much easier to find, and it's also easier to find examples when you're writing a new driver. With the current layout, you have to grep through the drivers, cpu and board hierarchies to find existing drivers similar to the one you're trying to write.
Seems we have an agreement. Let's do it this way, then. Thanks to all of you.
Best regards,
Wolfgang Denk
participants (7)
-
Ben Warren -
David Clark -
Haavard Skinnemoen -
Peter Pearse -
Stefan Roese -
Ulf Samuelsson -
Wolfgang Denk