Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
Hello.
As a current user of Atmel's AT91SAM9260, I encourage the effort to get at91sam926x inserted into the main u-boot branch. I'm willing help test u-boot on the at91sam9260ek board.
Michel
On 2/10/07, u-boot-users-request@lists.sourceforge.net u-boot-users-request@lists.sourceforge.net wrote:
Send U-Boot-Users mailing list submissions to u-boot-users@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/u-boot-users or, via email, send a message with subject or body 'help' to u-boot-users-request@lists.sourceforge.net
You can reach the person managing the list at u-boot-users-owner@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific than "Re: Contents of U-Boot-Users digest..."
Today's Topics:
- Re: BDI2000 config for MPC8360rev2 with DDR2 memory? (Medve Emilian-EMMEDVE1)
- Re: AT91 NAND om AT91SAM9260EK (Haavard Skinnemoen)
- Re: AT91 NAND om AT91SAM9260EK (Ulf Samuelsson)
- Re: AT91 NAND om AT91SAM9260EK (Haavard Skinnemoen)
- Re: AT91 NAND om AT91SAM9260EK (Ulf Samuelsson)
- 1 digital camera manufacturer. (Goldberg Rachel)
Message: 1 Date: Fri, 9 Feb 2007 15:22:55 -0700 From: "Medve Emilian-EMMEDVE1" Emilian.Medve@freescale.com Subject: Re: [U-Boot-Users] BDI2000 config for MPC8360rev2 with DDR2 memory? To: u-boot-users@lists.sourceforge.net Message-ID: 598D5675D34BE349929AF5EDE9B03E27C181C6@az33exm24.fsl.freescale.net Content-Type: text/plain; charset="us-ascii"
Hi Steve,
You could get the configuration files from Abatron (ftp://83.125.32.26/bdigdb/config/powerpc/mpc83xx/). That should be enough to just flash the board.
Cheers, Emil.
This e-mail, and any associated attachments have been classified as:
[x] Public [ ] Freescale Semiconductor Internal Use Only [ ] Freescale Semiconductor Confidential Proprietary
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Steven Hein Sent: Friday, February 09, 2007 4:06 PM To: u-boot-users@lists.sourceforge.net Subject: [U-Boot-Users] BDI2000 config for MPC8360rev2 with DDR2 memory?
Hi all--
I just received a new custom board with an MPC8360r2 with 128MB DDR2 memory on the board. My 8360EMDS board has a rev 1.2 part with DDR, so I know I need a different set of init registers in my BDI2000 config. If anyone has a similar config and could send me a BDI2000 config file for it, that would be AWESOME! In the mean time, I'm trying to flash u-boot directly into my flash part using the BDI2000 and let it initialize my memory for me. But this is all fairly uncharted territory for me, so a BDI config would be helpful.
Thanks! Steve
--
Steve Hein (ssh@sgi.com) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&da... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Message: 2 Date: Fri, 9 Feb 2007 23:58:16 +0100 From: "Haavard Skinnemoen" hskinnemoen@gmail.com Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK To: "Ulf Samuelsson" ulf@atmel.com Cc: u-boot-users@lists.sourceforge.net, Wolfgang Denk wd@denx.de, Haavard Skinnemoen hskinnemoen@atmel.com Message-ID: 1defaf580702091458p564ba747qc235ebe3601df497@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 2/9/07, Ulf Samuelsson ulf@atmel.com wrote:
The only thimg I'm not really happy with (whithout having any better suggestion) is to move this into drivers - drivers is intended for general, CPU and board independent code, where this is obviously specific to a certain class of processors.
It's somewhat cpu- and board-independent. at32 and at91 are based on two different architectures, so they don't have any directories in common apart from the ones common to everyone.
We could perhaps create a drivers/atmel subdirectory or, as Ulf suggests, boards/atmel/drivers or cpu/atmel/drivers.
I think at45.c is CPU independent, but spi.c is closely tied to Atmel processors. spi.c consist of:
SpiInit - Clearly CPU dependent due to pin mux. Only reason that sam926x chips can use a common file is the #ifdefs...
Hmm...how about moving the cpu-dependent bits into inline functions somewhere under asm/arch? For example
static inline void portmux_enable_spi(unsigned int id) { /* do chip-dependent PIO stuff here */ }
asm/arch is chip-specific so there shouldn't be any need for #ifdefs there.
While the functions in at45.c are called AT91xxx they really do not depend on any specific SPI H/W and it can thus be used with any chip which implements the SPI API defined by cpu/arm920t/at91rm9200/spi.c
Yeah, that's why the AT91 prefixing should be dropped. But that's for much later.
Btw, looks like there's another SPI API in u-boot as well. Probably a good idea to convert the at91/atmel spi stuff over to implementing that one. No point in having several APIs doing the same thing, and the other API uses the much more sensible function name spi_xfer for doing SPI transfers, as opposed to AT91F_SpiWrite which is totally misleading since it's being used for reading as well.
If you let it remain in the board directories as is, then you duplicate this for each board.
I don't think anyone wants that. Although you're the one suggesting we add a _third_ identical driver ;-)
I think a good place for any driver stuff which is useable both by at91 and ap7xxx chips could be an board/atmel/drivers directory. An alternative would be a cpu/atmel/drivers directory.
Are any other drivers organized this way?
I do not think it belongs inside the drivers directory.
I'm sorry but I fail to see why not. There are several other platform-specific drivers in there. And I don't really see the big advantage of spreading drivers around all over the place...
By putting spi.c in drivers you have to be really careful not to compile this for chips which does not have this SPI macro.
Yeah, but if it's protected by an easy-to-understand #ifdef that shouldn't be a problem. Although I don't think we should call it spi.c then. It should be atmel_spi.c or something.
The cpu/arm920t/at91rm9200/spi.c should at least contain the spi init.
Or do it in a chip-specific header file.
I still would like to have the complete sam926x patch set implemented before we start to "play" with it
Yeah, but I still think some preparatory patches are a good thing in order to make things easier later on.
Haavard
Message: 3 Date: Sat, 10 Feb 2007 00:20:21 +0100 From: "Ulf Samuelsson" ulf@atmel.com Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK To: "Haavard Skinnemoen" hskinnemoen@gmail.com Cc: u-boot-users@lists.sourceforge.net, Wolfgang Denk wd@denx.de, Haavard Skinnemoen hskinnemoen@atmel.com Message-ID: 012b01c74ca1$8ee35fe0$01c4af0a@Glamdring Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
I still would like to have the complete sam926x patch set implemented before we start to "play" with it
Yeah, but I still think some preparatory patches are a good thing in order to make things easier later on.
I only see two things as a result of those prepatory patches.
- Bugs
- Delays in availability
I am not questioning anything you want to do, just the timing. If we follow your recommendation you will have a bunch of untested board patches in the mainstream u-boot, for the sam926x.
I do not have the time to thoroughly test any changes you do (I dont even have an at91sam9263 board).
If we go my way, then we should be able to have *tested* sam926x support inside U-boot very soon, and while this results in duplication of a small part of the spi code on the source level (no addition to the binary) I believe that the benefit to the community of at91sam926x users of having native support in U-Boot outweighs this duplication a lot.
The number of users far outweisghs the number of implementers and I think that we need to look at it from their point of view.
We are not introducing any new interfaces here, just using the existing interfaces. This means that it will not be harder to do any modifications *after* the sam926x patches are applied. It will be easier since you have better overview.
The only alternative I can see is that you take over the responsibility for both AVR32 and AT91 U-boot and test all modifications on all boards before submission
- Still with availability of working solution as the highest priority.
Haavard
Best Regards Ulf Samuelsson
Message: 4 Date: Sat, 10 Feb 2007 00:42:27 +0100 From: "Haavard Skinnemoen" hskinnemoen@gmail.com Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK To: "Ulf Samuelsson" ulf@atmel.com Cc: u-boot-users@lists.sourceforge.net, Wolfgang Denk wd@denx.de, Haavard Skinnemoen hskinnemoen@atmel.com Message-ID: 1defaf580702091542m19034fddu9e1d3eb4fccf0d64@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 2/10/07, Ulf Samuelsson ulf@atmel.com wrote:
The number of users far outweisghs the number of implementers and I think that we need to look at it from their point of view.
Would help a lot to have some of those users help with testing though.
We are not introducing any new interfaces here, just using the existing interfaces. This means that it will not be harder to do any modifications *after* the sam926x patches are applied. It will be easier since you have better overview.
Whatever. Please let me know when you're ready to continue.
The only alternative I can see is that you take over the responsibility for both AVR32 and AT91 U-boot and test all modifications on all boards before submission
- Still with availability of working solution as the highest priority.
I don't think that's going to happen. Besides, having the same person implement and test the code usually doesn't work very well anyway, so if we're going to do this we need people willing to test probably-working-but-still-experimental stuff.
I'm of course not saying that I can't be bothered to test my modifications before submitting, but relying on me to implement _and_ test everything on all configurations is just insane.
Haavard
Message: 5 Date: Sat, 10 Feb 2007 01:10:55 +0100 From: "Ulf Samuelsson" ulf@atmel.com Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK To: "Haavard Skinnemoen" hskinnemoen@gmail.com Cc: u-boot-users@lists.sourceforge.net, Wolfgang Denk wd@denx.de, Haavard Skinnemoen hskinnemoen@atmel.com Message-ID: 014701c74ca8$920caf30$01c4af0a@Glamdring Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
On 2/10/07, Ulf Samuelsson ulf@atmel.com wrote:
The number of users far outweisghs the number of implementers and I think that we need to look at it from their point of view.
Would help a lot to have some of those users help with testing though.
We are not introducing any new interfaces here, just using the existing interfaces. This means that it will not be harder to do any modifications *after* the sam926x patches are applied. It will be easier since you have better overview.
Whatever. Please let me know when you're ready to continue.
I am ready to continue as soon as at45_split is applied. It is a real simple patch, it divides one more or less duplicated file into two files.
If I try to apply any sam926x patches without that, then It will crash the at91rm9200dk and cmc_pu2 board support.
Once this patch is applied, I can submit the at91sam926x patches and if/when they are accepted, then we have accomplished the most important goal to Atmel customers, which is that *tested* sam926x support is available from the primary U-Boot location and that you can build both at91 and avr32 from the same source code.
I consider all other activities secondary.
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
Message: 6 Date: Sat, 10 Feb 2007 02:27:15 +0200 From: Goldberg Rachel krihl@canpub.fr Subject: [U-Boot-Users] 1 digital camera manufacturer. To: u-boot-users@lists.sourceforge.net Message-ID: 45CD1163.1090109@canpub.fr Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
link: www.avrfreaks.net ----- Original Message ----- From: "Michel Benoit" murpme@gmail.com To: u-boot-users@lists.sourceforge.net Sent: Sunday, February 11, 2007 12:49 PM Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK
Hello.
As a current user of Atmel's AT91SAM9260, I encourage the effort to get at91sam926x inserted into the main u-boot branch. I'm willing help test u-boot on the at91sam9260ek board.
Michel
I expect that we should have it merged somewhere late this century since even after 50-100 emails there is no agreement how to take two almost identical files and merge into one and then split the single file into a cpu dependent and a cpu independent file.
Best Regards Ulf Samuelsson
On 2/10/07, u-boot-users-request@lists.sourceforge.net u-boot-users-request@lists.sourceforge.net wrote:
Send U-Boot-Users mailing list submissions to u-boot-users@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/u-boot-users or, via email, send a message with subject or body 'help' to u-boot-users-request@lists.sourceforge.net
You can reach the person managing the list at u-boot-users-owner@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific than "Re: Contents of U-Boot-Users digest..."
Today's Topics:
- Re: BDI2000 config for MPC8360rev2 with DDR2 memory? (Medve Emilian-EMMEDVE1)
- Re: AT91 NAND om AT91SAM9260EK (Haavard Skinnemoen)
- Re: AT91 NAND om AT91SAM9260EK (Ulf Samuelsson)
- Re: AT91 NAND om AT91SAM9260EK (Haavard Skinnemoen)
- Re: AT91 NAND om AT91SAM9260EK (Ulf Samuelsson)
- 1 digital camera manufacturer. (Goldberg Rachel)
Message: 1 Date: Fri, 9 Feb 2007 15:22:55 -0700 From: "Medve Emilian-EMMEDVE1" Emilian.Medve@freescale.com Subject: Re: [U-Boot-Users] BDI2000 config for MPC8360rev2 with DDR2 memory? To: u-boot-users@lists.sourceforge.net Message-ID:
598D5675D34BE349929AF5EDE9B03E27C181C6@az33exm24.fsl.freescale.net Content-Type: text/plain; charset="us-ascii"
Hi Steve,
You could get the configuration files from Abatron (ftp://83.125.32.26/bdigdb/config/powerpc/mpc83xx/). That should be enough to just flash the board.
Cheers, Emil.
This e-mail, and any associated attachments have been classified as:
[x] Public [ ] Freescale Semiconductor Internal Use Only [ ] Freescale Semiconductor Confidential Proprietary
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Steven Hein Sent: Friday, February 09, 2007 4:06 PM To: u-boot-users@lists.sourceforge.net Subject: [U-Boot-Users] BDI2000 config for MPC8360rev2 with DDR2 memory?
Hi all--
I just received a new custom board with an MPC8360r2 with 128MB DDR2 memory on the board. My 8360EMDS board has a rev 1.2 part with DDR, so I know I need a different set of init registers in my BDI2000 config. If anyone has a similar config and could send me a BDI2000 config file for it, that would be AWESOME! In the mean time, I'm trying to flash u-boot directly into my flash part using the BDI2000 and let it initialize my memory for me. But this is all fairly uncharted territory for me, so a BDI config would be helpful.
Thanks! Steve
--
Steve Hein (ssh@sgi.com) Engineering Diagnostics/Software Silicon Graphics, Inc. 1168 Industrial Blvd. Phone: (715) 726-8410 Chippewa Falls, WI 54729 Fax: (715) 726-6715
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&da... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Message: 2 Date: Fri, 9 Feb 2007 23:58:16 +0100 From: "Haavard Skinnemoen" hskinnemoen@gmail.com Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK To: "Ulf Samuelsson" ulf@atmel.com Cc: u-boot-users@lists.sourceforge.net, Wolfgang Denk wd@denx.de, Haavard Skinnemoen hskinnemoen@atmel.com Message-ID: 1defaf580702091458p564ba747qc235ebe3601df497@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 2/9/07, Ulf Samuelsson ulf@atmel.com wrote:
The only thimg I'm not really happy with (whithout having any better suggestion) is to move this into drivers - drivers is intended for general, CPU and board independent code, where this is obviously specific to a certain class of processors.
It's somewhat cpu- and board-independent. at32 and at91 are based on two different architectures, so they don't have any directories in common apart from the ones common to everyone.
We could perhaps create a drivers/atmel subdirectory or, as Ulf suggests, boards/atmel/drivers or cpu/atmel/drivers.
I think at45.c is CPU independent, but spi.c is closely tied to Atmel processors. spi.c consist of:
SpiInit - Clearly CPU dependent due to pin mux. Only reason that sam926x chips can use a common file is the #ifdefs...
Hmm...how about moving the cpu-dependent bits into inline functions somewhere under asm/arch? For example
static inline void portmux_enable_spi(unsigned int id) { /* do chip-dependent PIO stuff here */ }
asm/arch is chip-specific so there shouldn't be any need for #ifdefs there.
While the functions in at45.c are called AT91xxx they really do not depend on any specific SPI H/W and it can thus be used with any chip which implements the SPI API defined by cpu/arm920t/at91rm9200/spi.c
Yeah, that's why the AT91 prefixing should be dropped. But that's for much later.
Btw, looks like there's another SPI API in u-boot as well. Probably a good idea to convert the at91/atmel spi stuff over to implementing that one. No point in having several APIs doing the same thing, and the other API uses the much more sensible function name spi_xfer for doing SPI transfers, as opposed to AT91F_SpiWrite which is totally misleading since it's being used for reading as well.
If you let it remain in the board directories as is, then you duplicate this for each board.
I don't think anyone wants that. Although you're the one suggesting we add a _third_ identical driver ;-)
I think a good place for any driver stuff which is useable both by at91 and ap7xxx chips could be an board/atmel/drivers directory. An alternative would be a cpu/atmel/drivers directory.
Are any other drivers organized this way?
I do not think it belongs inside the drivers directory.
I'm sorry but I fail to see why not. There are several other platform-specific drivers in there. And I don't really see the big advantage of spreading drivers around all over the place...
By putting spi.c in drivers you have to be really careful not to compile this for chips which does not have this SPI macro.
Yeah, but if it's protected by an easy-to-understand #ifdef that shouldn't be a problem. Although I don't think we should call it spi.c then. It should be atmel_spi.c or something.
The cpu/arm920t/at91rm9200/spi.c should at least contain the spi init.
Or do it in a chip-specific header file.
I still would like to have the complete sam926x patch set implemented before we start to "play" with it
Yeah, but I still think some preparatory patches are a good thing in order to make things easier later on.
Haavard
Message: 3 Date: Sat, 10 Feb 2007 00:20:21 +0100 From: "Ulf Samuelsson" ulf@atmel.com Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK To: "Haavard Skinnemoen" hskinnemoen@gmail.com Cc: u-boot-users@lists.sourceforge.net, Wolfgang Denk wd@denx.de, Haavard Skinnemoen hskinnemoen@atmel.com Message-ID: 012b01c74ca1$8ee35fe0$01c4af0a@Glamdring Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
I still would like to have the complete sam926x patch set implemented before we start to "play" with it
Yeah, but I still think some preparatory patches are a good thing in order to make things easier later on.
I only see two things as a result of those prepatory patches.
- Bugs
- Delays in availability
I am not questioning anything you want to do, just the timing. If we follow your recommendation you will have a bunch of untested board patches in the mainstream u-boot, for the sam926x.
I do not have the time to thoroughly test any changes you do (I dont even have an at91sam9263 board).
If we go my way, then we should be able to have *tested* sam926x support inside U-boot very soon, and while this results in duplication of a small part of the spi code on the source level (no addition to the binary) I believe that the benefit to the community of at91sam926x users of having native support in U-Boot outweighs this duplication a lot.
The number of users far outweisghs the number of implementers and I think that we need to look at it from their point of view.
We are not introducing any new interfaces here, just using the existing interfaces. This means that it will not be harder to do any modifications *after* the sam926x patches are applied. It will be easier since you have better overview.
The only alternative I can see is that you take over the responsibility for both AVR32 and AT91 U-boot and test all modifications on all boards before submission
- Still with availability of working solution as the highest priority.
Haavard
Best Regards Ulf Samuelsson
Message: 4 Date: Sat, 10 Feb 2007 00:42:27 +0100 From: "Haavard Skinnemoen" hskinnemoen@gmail.com Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK To: "Ulf Samuelsson" ulf@atmel.com Cc: u-boot-users@lists.sourceforge.net, Wolfgang Denk wd@denx.de, Haavard Skinnemoen hskinnemoen@atmel.com Message-ID: 1defaf580702091542m19034fddu9e1d3eb4fccf0d64@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 2/10/07, Ulf Samuelsson ulf@atmel.com wrote:
The number of users far outweisghs the number of implementers and I think that we need to look at it from their point of view.
Would help a lot to have some of those users help with testing though.
We are not introducing any new interfaces here, just using the existing interfaces. This means that it will not be harder to do any modifications *after* the sam926x patches are applied. It will be easier since you have better overview.
Whatever. Please let me know when you're ready to continue.
The only alternative I can see is that you take over the responsibility for both AVR32 and AT91 U-boot and test all modifications on all boards before submission
- Still with availability of working solution as the highest priority.
I don't think that's going to happen. Besides, having the same person implement and test the code usually doesn't work very well anyway, so if we're going to do this we need people willing to test probably-working-but-still-experimental stuff.
I'm of course not saying that I can't be bothered to test my modifications before submitting, but relying on me to implement _and_ test everything on all configurations is just insane.
Haavard
Message: 5 Date: Sat, 10 Feb 2007 01:10:55 +0100 From: "Ulf Samuelsson" ulf@atmel.com Subject: Re: [U-Boot-Users] AT91 NAND om AT91SAM9260EK To: "Haavard Skinnemoen" hskinnemoen@gmail.com Cc: u-boot-users@lists.sourceforge.net, Wolfgang Denk wd@denx.de, Haavard Skinnemoen hskinnemoen@atmel.com Message-ID: 014701c74ca8$920caf30$01c4af0a@Glamdring Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
On 2/10/07, Ulf Samuelsson ulf@atmel.com wrote:
The number of users far outweisghs the number of implementers and I think that we need to look at it from their point of view.
Would help a lot to have some of those users help with testing though.
We are not introducing any new interfaces here, just using the existing interfaces. This means that it will not be harder to do any modifications *after* the sam926x patches are applied. It will be easier since you have better overview.
Whatever. Please let me know when you're ready to continue.
I am ready to continue as soon as at45_split is applied. It is a real simple patch, it divides one more or less duplicated file into two files.
If I try to apply any sam926x patches without that, then It will crash the at91rm9200dk and cmc_pu2 board support.
Once this patch is applied, I can submit the at91sam926x patches and if/when they are accepted, then we have accomplished the most important goal to Atmel customers, which is that *tested* sam926x support is available from the primary U-Boot location and that you can build both at91 and avr32 from the same source code.
I consider all other activities secondary.
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
Message: 6 Date: Sat, 10 Feb 2007 02:27:15 +0200 From: Goldberg Rachel krihl@canpub.fr Subject: [U-Boot-Users] 1 digital camera manufacturer. To: u-boot-users@lists.sourceforge.net Message-ID: 45CD1163.1090109@canpub.fr Content-Type: text/plain; charset="us-ascii"
An HTML attachment was scrubbed...
participants (2)
-
Michel Benoit -
Ulf Samuelsson