Patchwork [U-Boot,v4] AT91SAM9*: Change kernel address in dataflash to match u-boot's size

login
register
mail settings
Submitter Alexandre Belloni
Date April 8, 2012, 6:17 p.m.
Message ID <1333909023-6725-1-git-send-email-alexandre.belloni@piout.net>
Download mbox | patch
Permalink /patch/151367/
State Superseded
Headers show

Comments

Alexandre Belloni - April 8, 2012, 6:17 p.m.
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(-)
Wolfgang Denk - April 8, 2012, 8:06 p.m.
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
Andreas Bießmann - April 9, 2012, 6:36 a.m.
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.
Wolfgang Denk - April 9, 2012, 8:15 a.m.
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
Ulf Samuelsson - April 17, 2012, 11:26 p.m.
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
>
Alexandre Belloni - April 21, 2012, 9:19 p.m.
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,

Patch

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