| Message ID | 1333909023-6725-1-git-send-email-alexandre.belloni@piout.net |
|---|---|
| State | Superseded |
| Headers | show |
Dear Alexandre Belloni, In message <1333909023-6725-1-git-send-email-alexandre.belloni@piout.net> you wrote: > On at91sam platforms, u-boot grew larger than the allocated size in > dataflash, the layout was: > bootstrap 0x00000000 > ubootenv 0x00004200 > uboot 0x00008400 > kernel 0x00042000 > > u-boot with the defconfig doesn't seem to fit in 0x42000 - 0x8400 = > 0x39C00 bytes anymore. > > Now, the layout is: > bootstrap 0x00000000 > ubootenv 0x00004200 > uboot 0x00008400 > kernel 0x00084000 Where are these odd sizes like > #define CONFIG_ENV_SIZE 0x4200 coming from? Has a size of 0x4200 any special maning on these systems? Best regards, Wolfgang Denk
Dear Wolfgang, On 08.04.12 22:06, Wolfgang Denk wrote: > Dear Alexandre Belloni, > > In message <1333909023-6725-1-git-send-email-alexandre.belloni@piout.net> you wrote: >> On at91sam platforms, u-boot grew larger than the allocated size in >> dataflash, the layout was: >> bootstrap 0x00000000 >> ubootenv 0x00004200 >> uboot 0x00008400 >> kernel 0x00042000 >> >> u-boot with the defconfig doesn't seem to fit in 0x42000 - 0x8400 = >> 0x39C00 bytes anymore. >> >> Now, the layout is: >> bootstrap 0x00000000 >> ubootenv 0x00004200 >> uboot 0x00008400 >> kernel 0x00084000 > > Where are these odd sizes like > >> #define CONFIG_ENV_SIZE 0x4200 > > coming from? Has a size of 0x4200 any special maning on these > systems? please read Ulfs mail: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/123862/focus=125897 I think it is OK to apply this patch. All these atmel boards need some more attention (lack of maintainer). Reinhard started to migrate a lot of stuff but unfortunately this process is not completely finished. I will not say it is left undone but there is still a lot to do. I think another point is that these Atmel devices became less important than before in U-Boot (I see not really much users here even though a lot of people use it): a) a lot of users favor the at91bootstrap SPL to boot linux (no need for u-boot) b) they have well-hung cores best regards Andreas Bießmann PS: besides a) there was a user in irc around Christmas who count 'the SPL for atmel devices in U-Boot' a good idea. He said he wants to play with it ... I wonder if he does.
Dear Andreas, In message <4F82835F.2030201@googlemail.com> you wrote: > > > Where are these odd sizes like > > > >> #define CONFIG_ENV_SIZE 0x4200 > > > > coming from? Has a size of 0x4200 any special maning on these > > systems? > > please read Ulfs mail: > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/123862/focus=125897 Thanks for the pointer. > I think it is OK to apply this patch. I did not intend to object against this patch; I just wonered about the odd numbers, > I think another point is that these Atmel devices became less important > than before in U-Boot (I see not really much users here even though a > lot of people use it): > a) a lot of users favor the at91bootstrap SPL to boot linux (no need > for u-boot) This could probably be changed if they were converted to using U-Boot's SPL mechanism instead - but then, I also realize that there is only very low interest for them. > b) they have well-hung cores Indeed. Best regards, Wolfgang Denk
On 2012-04-09 10:15, Wolfgang Denk wrote: > Dear Andreas, > > In message<4F82835F.2030201@googlemail.com> you wrote: >>> Where are these odd sizes like >>> >>>> #define CONFIG_ENV_SIZE 0x4200 >>> coming from? Has a size of 0x4200 any special maning on these >>> systems? >> please read Ulfs mail: >> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/123862/focus=125897 > Thanks for the pointer. > >> I think it is OK to apply this patch. > I did not intend to object against this patch; I just wonered about > the odd numbers, > >> I think another point is that these Atmel devices became less important >> than before in U-Boot (I see not really much users here even though a >> lot of people use it): >> a) a lot of users favor the at91bootstrap SPL to boot linux (no need >> for u-boot) While AT91bootstrap supports booting linux, this is real minimal support. Everything is hard-wired so for development it really sucks. It is really only useful for production work. I personally never used this capability. This functionality is pretty new in AT91boostrap, and the Atmel (non) presence in the mailing list is an older problem. While I no longer work for Atmel, I have a feeling that the problem is as follows: Users are using the Atmel version of U-Boot, not mainstream. If not using the Atmel version, then they maybe using a build system like OpenEmbedded where u-boot is built as a part of the build process and people have very little incentive in modifying that part There is very little incentive at Atmel to upgrade because 1. Patches provided by Atmel are ignored. 2. Patches are applied to mainline which keeps breaking the AT91 support. 3. All possible fixes to boot problem are rejected (discussion with Haavard). 4. It is considered more important to have a "clean" implementation, than a working implementation. (Choice of NOR Flash Driver) Atmel does not want to continuously spend effort on unbreaking other peoples work. Problems are not fixed in the mainline due to problem (1). Instead the problems are fixed in the buildsystem and it is not considered worthwhile to submit such fixes to the mailinglist. The action by the project to "solve" the problem by removing the boards from the MAKEALL scripts and also to remove BSPs is not encouraging. There used to be a rule that patches should not break board support, but that rule seems to have gone down the drains. The Atmel code is (IIRC) based on 0.3.4 so it is very old, so an update is really needed but before U-Boot becomes "developer-friendly", I doubt that will happen. If the project wants to have Atmel "on-board", then fixing problem (1) is key. > This could probably be changed if they were converted to using > U-Boot's SPL mechanism instead - but then, I also realize that there > is only very low interest for them. > > I think you are right. Atmel wants control over this part. >> b) they have well-hung cores Still plenty of ARM9 users out there, but a new core would be an obvious way forward for the 2012 model AT91 application processors. Don't see many reasons for updating the current SAM9Gx5 family. "http://www.mscbp.hu/Documents/Atmel Q-Touch.pdf" seems to hint at a Cortex-A5, but this document is from 2010, so plans may have changed. > Indeed. > > Best regards, > > Wolfgang Denk >
Hi, On Wed, Apr 18, 2012 at 01:26:18AM +0200, Ulf Samuelsson wrote : > While AT91bootstrap supports booting linux, this is real minimal support. > Everything is hard-wired so for development it really sucks. > It is really only useful for production work. > I personally never used this capability. > > This functionality is pretty new in AT91boostrap, > and the Atmel (non) presence in the mailing list is an older problem. > > While I no longer work for Atmel, I have a feeling that the problem > is as follows: > > Users are using the Atmel version of U-Boot, not mainstream. > If not using the Atmel version, then they maybe using a build system > like OpenEmbedded where u-boot is built as a part of the build process > and people have very little incentive in modifying that part > > There is very little incentive at Atmel to upgrade because > 1. Patches provided by Atmel are ignored. > 2. Patches are applied to mainline which keeps breaking the AT91 support. > 3. All possible fixes to boot problem are rejected (discussion with > Haavard). > 4. It is considered more important to have a "clean" implementation, > than a working implementation. > (Choice of NOR Flash Driver) > > Atmel does not want to continuously spend effort on unbreaking other > peoples work. > > Problems are not fixed in the mainline due to problem (1). > Instead the problems are fixed in the buildsystem and it is not considered > worthwhile to submit such fixes to the mailinglist. > > The action by the project to "solve" the problem by removing the > boards from > the MAKEALL scripts and also to remove BSPs is not encouraging. > > There used to be a rule that patches should not break board support, but > that rule seems to have gone down the drains. > > The Atmel code is (IIRC) based on 0.3.4 so it is very old, so an > update is really needed > but before U-Boot becomes "developer-friendly", I doubt that will happen. > If the project wants to have Atmel "on-board", then fixing problem > (1) is key. > Would it be possible to get a list of what is not working on mainline but is working in ATMEL's version ? or at least some pointers. It seems to be working well on my board. I'm really interested in getting mainline working well. I know there is not much interest in the AT91 boards now but I would really like to see that issue fixed. Regards,
diff --git a/include/configs/at91sam9260ek.h b/include/configs/at91sam9260ek.h index db52ee6..49b3386 100644 --- a/include/configs/at91sam9260ek.h +++ b/include/configs/at91sam9260ek.h @@ -188,7 +188,7 @@ #define CONFIG_ENV_OFFSET 0x4200 #define CONFIG_ENV_ADDR (CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS0 + CONFIG_ENV_OFFSET) #define CONFIG_ENV_SIZE 0x4200 -#define CONFIG_BOOTCOMMAND "cp.b 0xC0042000 0x22000000 0x210000; bootm" +#define CONFIG_BOOTCOMMAND "cp.b 0xC0084000 0x22000000 0x210000; bootm" #define CONFIG_BOOTARGS "console=ttyS0,115200 " \ "root=/dev/mtdblock0 " \ "mtdparts=atmel_nand:-(root) " \ @@ -202,7 +202,7 @@ #define CONFIG_ENV_OFFSET 0x4200 #define CONFIG_ENV_ADDR (CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS1 + CONFIG_ENV_OFFSET) #define CONFIG_ENV_SIZE 0x4200 -#define CONFIG_BOOTCOMMAND "cp.b 0xD0042000 0x22000000 0x210000; bootm" +#define CONFIG_BOOTCOMMAND "cp.b 0xD0084000 0x22000000 0x210000; bootm" #define CONFIG_BOOTARGS "console=ttyS0,115200 " \ "root=/dev/mtdblock0 " \ "mtdparts=atmel_nand:-(root) " \ @@ -231,6 +231,7 @@ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) #define CONFIG_SYS_LONGHELP 1 #define CONFIG_CMDLINE_EDITING 1 +#define CONFIG_AUTO_COMPLETE /* * Size of malloc() pool diff --git a/include/configs/at91sam9261ek.h b/include/configs/at91sam9261ek.h index 5140b26..967a4c4 100644 --- a/include/configs/at91sam9261ek.h +++ b/include/configs/at91sam9261ek.h @@ -190,7 +190,7 @@ #define CONFIG_ENV_OFFSET 0x4200 #define CONFIG_ENV_ADDR (CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS0 + CONFIG_ENV_OFFSET) #define CONFIG_ENV_SIZE 0x4200 -#define CONFIG_BOOTCOMMAND "cp.b 0xC0042000 0x22000000 0x210000; bootm" +#define CONFIG_BOOTCOMMAND "cp.b 0xC0084000 0x22000000 0x210000; bootm" #define CONFIG_BOOTARGS "console=ttyS0,115200 " \ "root=/dev/mtdblock0 " \ "mtdparts=atmel_nand:-(root) " \ @@ -204,7 +204,7 @@ #define CONFIG_ENV_OFFSET 0x4200 #define CONFIG_ENV_ADDR (CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS3 + CONFIG_ENV_OFFSET) #define CONFIG_ENV_SIZE 0x4200 -#define CONFIG_BOOTCOMMAND "cp.b 0xD0042000 0x22000000 0x210000; bootm" +#define CONFIG_BOOTCOMMAND "cp.b 0xD0084000 0x22000000 0x210000; bootm" #define CONFIG_BOOTARGS "console=ttyS0,115200 " \ "root=/dev/mtdblock0 " \ "mtdparts=atmel_nand:-(root) " \ @@ -233,6 +233,7 @@ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) #define CONFIG_SYS_LONGHELP #define CONFIG_CMDLINE_EDITING +#define CONFIG_AUTO_COMPLETE /* * Size of malloc() pool diff --git a/include/configs/at91sam9263ek.h b/include/configs/at91sam9263ek.h index 8399246..a6fe325 100644 --- a/include/configs/at91sam9263ek.h +++ b/include/configs/at91sam9263ek.h @@ -317,7 +317,7 @@ #define CONFIG_ENV_OFFSET 0x4200 #define CONFIG_ENV_ADDR (CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS0 + CONFIG_ENV_OFFSET) #define CONFIG_ENV_SIZE 0x4200 -#define CONFIG_BOOTCOMMAND "cp.b 0xC0042000 0x22000000 0x210000; bootm" +#define CONFIG_BOOTCOMMAND "cp.b 0xC0084000 0x22000000 0x210000; bootm" #define CONFIG_BOOTARGS "console=ttyS0,115200 " \ "root=/dev/mtdblock0 " \ "mtdparts=atmel_nand:-(root) "\ @@ -347,6 +347,8 @@ #define CONFIG_AUTO_COMPLETE #define CONFIG_SYS_HUSH_PARSER #define CONFIG_SYS_PROMPT_HUSH_PS2 "> " +#define CONFIG_AUTO_COMPLETE + /* * Size of malloc() pool diff --git a/include/configs/at91sam9rlek.h b/include/configs/at91sam9rlek.h index 79ea1f2..6640b06 100644 --- a/include/configs/at91sam9rlek.h +++ b/include/configs/at91sam9rlek.h @@ -156,7 +156,7 @@ #define CONFIG_ENV_OFFSET 0x4200 #define CONFIG_ENV_ADDR (CONFIG_SYS_DATAFLASH_LOGIC_ADDR_CS0 + CONFIG_ENV_OFFSET) #define CONFIG_ENV_SIZE 0x4200 -#define CONFIG_BOOTCOMMAND "cp.b 0xC0042000 0x22000000 0x210000; bootm" +#define CONFIG_BOOTCOMMAND "cp.b 0xC0084000 0x22000000 0x210000; bootm" #define CONFIG_BOOTARGS "console=ttyS0,115200 " \ "root=/dev/mtdblock0 " \ "mtdparts=atmel_nand:-(root) "\ @@ -183,6 +183,7 @@ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + sizeof(CONFIG_SYS_PROMPT) + 16) #define CONFIG_SYS_LONGHELP 1 #define CONFIG_CMDLINE_EDITING 1 +#define CONFIG_AUTO_COMPLETE /* * Size of malloc() pool
On at91sam platforms, u-boot grew larger than the allocated size in dataflash, the layout was: bootstrap 0x00000000 ubootenv 0x00004200 uboot 0x00008400 kernel 0x00042000 u-boot with the defconfig doesn't seem to fit in 0x42000 - 0x8400 = 0x39C00 bytes anymore. Now, the layout is: bootstrap 0x00000000 ubootenv 0x00004200 uboot 0x00008400 kernel 0x00084000 Signed-off-by: Alexandre Belloni <alexandre.belloni@piout.net> --- Changes for v2: - changed the layout as per Marek's recommendation Changes for v3: - prefixed the patch title with AT91SAM9*: Changes for v4: - changed the layout again as per Ulf Samuelsson's request: http://lists.denx.de/pipermail/u-boot/2012-February/118988.html include/configs/at91sam9260ek.h | 5 +++-- include/configs/at91sam9261ek.h | 5 +++-- include/configs/at91sam9263ek.h | 4 +++- include/configs/at91sam9rlek.h | 3 ++- 4 files changed, 11 insertions(+), 6 deletions(-)