[U-Boot] 85xx: MPC8536DS board does not build

[U-Boot] 85xx: MPC8536DS board does not build

[Wolfgang Denk]

Dear Kumar,

I cannot build the MPC8536DS board any more using the ELDK 4.2 tool
chain (gcc 4.2.2):

ppc_85xx-ld: section .bootpg [effff000 -> effff1cb] overlaps section .data.rel.local [efffe5d0 -> effff
c7b]
ppc_85xx-ld: section .resetvec [effffffc -> efffffff] overlaps section .u_boot_cmd [effffc9c -> f00003e
b]
ppc_85xx-ld: u-boot: section .bootpg lma 0xeffff000 overlaps previous sections
ppc_85xx-ld: u-boot: section .data.rel.ro lma 0xeffffc7c overlaps previous sections
ppc_85xx-ld: u-boot: section .u_boot_cmd lma 0xeffffc9c overlaps previous sections
ppc_85xx-ld: u-boot: section .resetvec lma 0xeffffffc overlaps previous sections


Could you please have a look?

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: wd at denx.de
"Why waste negative entropy on comments, when you could use the  same
entropy to create bugs instead?"                        - Steve Elias

[U-Boot] 85xx: MPC8536DS board does not build

[Kumar Gala]

On Aug 10, 2009, at 2:56 AM, Wolfgang Denk wrote:

> Dear Kumar,
>
> I cannot build the MPC8536DS board any more using the ELDK 4.2 tool
> chain (gcc 4.2.2):
>
> ppc_85xx-ld: section .bootpg [effff000 -> effff1cb] overlaps  
> section .data.rel.local [efffe5d0 -> effff
> c7b]
> ppc_85xx-ld: section .resetvec [effffffc -> efffffff] overlaps  
> section .u_boot_cmd [effffc9c -> f00003e
> b]
> ppc_85xx-ld: u-boot: section .bootpg lma 0xeffff000 overlaps  
> previous sections
> ppc_85xx-ld: u-boot: section .data.rel.ro lma 0xeffffc7c overlaps  
> previous sections
> ppc_85xx-ld: u-boot: section .u_boot_cmd lma 0xeffffc9c overlaps  
> previous sections
> ppc_85xx-ld: u-boot: section .resetvec lma 0xeffffffc overlaps  
> previous sections
>
>
> Could you please have a look?

The e1000 driver updates seem to contribute a bit to code bloat.

    text	   data	    bss	    dec	    hex	filename
  427664	  52160	 300093	 779917	  be68d	u-boot			new e1000
  417628	  51980	 300093	 769701	  bbea5	u-boot			old e1000

Not sure what we can do about it.

- k

[U-Boot] 85xx: MPC8536DS board does not build

[Ben Warren]

Kumar Gala wrote:
> On Aug 10, 2009, at 2:56 AM, Wolfgang Denk wrote:
>
>   
>> Dear Kumar,
>>
>> I cannot build the MPC8536DS board any more using the ELDK 4.2 tool
>> chain (gcc 4.2.2):
>>
>> ppc_85xx-ld: section .bootpg [effff000 -> effff1cb] overlaps  
>> section .data.rel.local [efffe5d0 -> effff
>> c7b]
>> ppc_85xx-ld: section .resetvec [effffffc -> efffffff] overlaps  
>> section .u_boot_cmd [effffc9c -> f00003e
>> b]
>> ppc_85xx-ld: u-boot: section .bootpg lma 0xeffff000 overlaps  
>> previous sections
>> ppc_85xx-ld: u-boot: section .data.rel.ro lma 0xeffffc7c overlaps  
>> previous sections
>> ppc_85xx-ld: u-boot: section .u_boot_cmd lma 0xeffffc9c overlaps  
>> previous sections
>> ppc_85xx-ld: u-boot: section .resetvec lma 0xeffffffc overlaps  
>> previous sections
>>
>>
>> Could you please have a look?
>>     
>
> The e1000 driver updates seem to contribute a bit to code bloat.
>
>     text	   data	    bss	    dec	    hex	filename
>   427664	  52160	 300093	 779917	  be68d	u-boot			new e1000
>   417628	  51980	 300093	 769701	  bbea5	u-boot			old e1000
>
> Not sure what we can do about it.
>
> - k
>   
Adding PCI-E support to this driver added an astounding 3000+ lines to 
the driver.  I asked Roy to pare it back, but it was still pretty 
huge.   If this size increase is a serious issue, I support backing this 
patch out and refactoring it to include only the features that are 
necessary for a bootloader.

regards,
Ben

[U-Boot] 85xx: MPC8536DS board does not build

[Wolfgang Denk]

Dear Kumar Gala,

In message <0E1A5EEB-51E5-488D-9457-993F95553506@kernel.crashing.org> you wrote:
> 
> > Could you please have a look?
> 
> The e1000 driver updates seem to contribute a bit to code bloat.
...
> Not sure what we can do about it.

Allocate more space for U-Boot?

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: wd at denx.de
You Earth people glorified organized violence  for  forty  centuries.
But you imprison those who employ it privately.
	-- Spock, "Dagger of the Mind", stardate 2715.1

[U-Boot] 85xx: MPC8536DS board does not build

[Kumar Gala]

On Aug 10, 2009, at 12:59 PM, Wolfgang Denk wrote:

> Dear Kumar Gala,
>
> In message  
> <0E1A5EEB-51E5-488D-9457-993F95553506@kernel.crashing.org> you wrote:
>>
>>> Could you please have a look?
>>
>> The e1000 driver updates seem to contribute a bit to code bloat.
> ...
>> Not sure what we can do about it.
>
> Allocate more space for U-Boot?

I might turn of BEDBUG as its never been properly enabled on e500/85xx  
platforms.

- k

[U-Boot] 85xx: MPC8536DS board does not build

[Wolfgang Denk]

Dear Kumar Gala,

In message <0EB7516A-2F14-42F7-A6ED-555ADFAB3105@kernel.crashing.org> you wrote:
> 
> > Allocate more space for U-Boot?
> 
> I might turn of BEDBUG as its never been properly enabled on e500/85xx  
> platforms.

Is there any problem with the bigger image which I don't understand
yet? Normally we just move down the TEXT_BASE by a sector, and that's
it.

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: wd at denx.de
The easiest way to figure the cost of living is to take  your  income
and add ten percent.

[U-Boot] 85xx: MPC8536DS board does not build

[Kumar Gala]

On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:

> Dear Kumar Gala,
>
> In message <0EB7516A-2F14-42F7- 
> A6ED-555ADFAB3105 at kernel.crashing.org> you wrote:
>>
>>> Allocate more space for U-Boot?
>>
>> I might turn of BEDBUG as its never been properly enabled on  
>> e500/85xx
>> platforms.
>
> Is there any problem with the bigger image which I don't understand
> yet? Normally we just move down the TEXT_BASE by a sector, and that's
> it.

Not specifically, its just that ever 85xx image to date has been  
512k.  I'm just trying to avoid this being the first one that changes  
that historic fact.  Especially since compilers like gcc-4.3 seem to  
be able to fit the size in 512k.

- k

[U-Boot] 85xx: MPC8536DS board does not build

[Zang Roy-R61911]

 

> -----Original Message-----
> From: Kumar Gala [mailto:galak at kernel.crashing.org] 
> Sent: Monday, August 10, 2009 13:41 PM
> To: Wolfgang Denk
> Cc: U-Boot-Users ML; Zang Roy-R61911
> Subject: Re: 85xx: MPC8536DS board does not build
> 
> 
> On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
> 
> > Dear Kumar Gala,
> >
> > In message <0EB7516A-2F14-42F7- 
> > A6ED-555ADFAB3105 at kernel.crashing.org> you wrote:
> >>
> >>> Allocate more space for U-Boot?
> >>
> >> I might turn of BEDBUG as its never been properly enabled on  
> >> e500/85xx
> >> platforms.
> >
> > Is there any problem with the bigger image which I don't understand
> > yet? Normally we just move down the TEXT_BASE by a sector, 
> and that's
> > it.
> 
> Not specifically, its just that ever 85xx image to date has been  
> 512k.  I'm just trying to avoid this being the first one that 
> changes  
> that historic fact.  Especially since compilers like gcc-4.3 seem to  
> be able to fit the size in 512k.
We may have more requirements to support graphic in u-boot.
Sooner and later, the size will exceed 512K. Should we have some plan
for this?
Roy

[U-Boot] 85xx: MPC8536DS board does not build

[Kumar Gala]

On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote:

>
>
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak at kernel.crashing.org]
>> Sent: Monday, August 10, 2009 13:41 PM
>> To: Wolfgang Denk
>> Cc: U-Boot-Users ML; Zang Roy-R61911
>> Subject: Re: 85xx: MPC8536DS board does not build
>>
>>
>> On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
>>
>>> Dear Kumar Gala,
>>>
>>> In message <0EB7516A-2F14-42F7-
>>> A6ED-555ADFAB3105 at kernel.crashing.org> you wrote:
>>>>
>>>>> Allocate more space for U-Boot?
>>>>
>>>> I might turn of BEDBUG as its never been properly enabled on
>>>> e500/85xx
>>>> platforms.
>>>
>>> Is there any problem with the bigger image which I don't understand
>>> yet? Normally we just move down the TEXT_BASE by a sector,
>> and that's
>>> it.
>>
>> Not specifically, its just that ever 85xx image to date has been
>> 512k.  I'm just trying to avoid this being the first one that
>> changes
>> that historic fact.  Especially since compilers like gcc-4.3 seem to
>> be able to fit the size in 512k.
> We may have more requirements to support graphic in u-boot.
> Sooner and later, the size will exceed 512K. Should we have some plan
> for this?

So if we are going to increase the limit from 512k do we go to 768k or  
1M?  (Sector size on the board appears to 128k)

I would also like to know how big the flashes are on some of the other  
85xx boards that u-boot supports.

- k

[U-Boot] 85xx: MPC8536DS board does not build

[Jerry Van Baren]

Kumar Gala wrote:
> On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote:
> 
>>
>>> -----Original Message-----
>>> From: Kumar Gala [mailto:galak at kernel.crashing.org]
>>> Sent: Monday, August 10, 2009 13:41 PM
>>> To: Wolfgang Denk
>>> Cc: U-Boot-Users ML; Zang Roy-R61911
>>> Subject: Re: 85xx: MPC8536DS board does not build
>>>
>>>
>>> On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
>>>
>>>> Dear Kumar Gala,
>>>>
>>>> In message <0EB7516A-2F14-42F7-
>>>> A6ED-555ADFAB3105 at kernel.crashing.org> you wrote:
>>>>>> Allocate more space for U-Boot?
>>>>> I might turn of BEDBUG as its never been properly enabled on
>>>>> e500/85xx
>>>>> platforms.
>>>> Is there any problem with the bigger image which I don't understand
>>>> yet? Normally we just move down the TEXT_BASE by a sector,
>>> and that's
>>>> it.
>>> Not specifically, its just that ever 85xx image to date has been
>>> 512k.  I'm just trying to avoid this being the first one that
>>> changes
>>> that historic fact.  Especially since compilers like gcc-4.3 seem to
>>> be able to fit the size in 512k.
>> We may have more requirements to support graphic in u-boot.
>> Sooner and later, the size will exceed 512K. Should we have some plan
>> for this?
> 
> So if we are going to increase the limit from 512k do we go to 768k or  
> 1M?  (Sector size on the board appears to 128k)
> 
> I would also like to know how big the flashes are on some of the other  
> 85xx boards that u-boot supports.
> 
> - k

Hi Kumar, Roy,

512K is pretty big for u-boot (not unheard of, but still...).  Is it 
really 512K or is it using a full page to hold the boot page (top 4K of 
memory) and one page for the env (unavoidable):

+-------------------------------------------------------- 0x1_0000_0000
| One sector dedicated for the power up page (only using 4K)
+-------------------------------------------------------- 0x0_F800_0000
| One sector dedicated for the env
+-------------------------------------------------------- 0x0_F000_0000
| Two sectors of u-boot
+----                                                     0x0_E800_0000
|
+-------------------------------------------------------- 0x0_E000_0000


If that is the case, you can gain a sector (less 4K) by rearranging your 
memory map:
+-------------------------------------------------------- 0x1_0000_0000
| One page (4K) of power up vector, the rest is u-boot
+----                                                     0x0_F800_0000
|
+----                                                     0x0_F000_0000
| Three sectors (less 4K) of u-boot
+-------------------------------------------------------- 0x0_E800_0000
| One sector dedicated for the env
+-------------------------------------------------------- 0x0_E000_0000

This also makes reprogramming u-boot nicer because your power up vector 
and u-boot itself are contiguous.

Best regards,
gvb

[U-Boot] 85xx: MPC8536DS board does not build

[Zang Roy-R61911]

 

> -----Original Message-----
> From: Kumar Gala [mailto:galak at kernel.crashing.org] 
> Sent: Monday, August 10, 2009 14:06 PM
> To: Zang Roy-R61911
> Cc: Wolfgang Denk; U-Boot-Users ML
> Subject: Re: 85xx: MPC8536DS board does not build
> 
> 
> On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak at kernel.crashing.org]
> >> Sent: Monday, August 10, 2009 13:41 PM
> >> To: Wolfgang Denk
> >> Cc: U-Boot-Users ML; Zang Roy-R61911
> >> Subject: Re: 85xx: MPC8536DS board does not build
> >>
> >>
> >> On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
> >>
> >>> Dear Kumar Gala,
> >>>
> >>> In message <0EB7516A-2F14-42F7-
> >>> A6ED-555ADFAB3105 at kernel.crashing.org> you wrote:
> >>>>
> >>>>> Allocate more space for U-Boot?
> >>>>
> >>>> I might turn of BEDBUG as its never been properly enabled on
> >>>> e500/85xx
> >>>> platforms.
> >>>
> >>> Is there any problem with the bigger image which I don't 
> understand
> >>> yet? Normally we just move down the TEXT_BASE by a sector,
> >> and that's
> >>> it.
> >>
> >> Not specifically, its just that ever 85xx image to date has been
> >> 512k.  I'm just trying to avoid this being the first one that
> >> changes
> >> that historic fact.  Especially since compilers like 
> gcc-4.3 seem to
> >> be able to fit the size in 512k.
> > We may have more requirements to support graphic in u-boot.
> > Sooner and later, the size will exceed 512K. Should we have 
> some plan
> > for this?
> 
> So if we are going to increase the limit from 512k do we go 
> to 768k or  
> 1M?  (Sector size on the board appears to 128k)
If there is no special reason, I'd like to expand it to 768K.
But my concern here is that it is better to limit 8536DS image to 512K.
For SD/NAND boot code, the u-boot will be copy to L2 cache. It is only
512K.

> 
> I would also like to know how big the flashes are on some of 
> the other  
> 85xx boards that u-boot supports.

[U-Boot] 85xx: MPC8536DS board does not build

[Peter Tyser]

On Mon, 2009-08-10 at 15:27 -0400, Jerry Van Baren wrote:
> Kumar Gala wrote:
> > On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote:
> > 
> >>
> >>> -----Original Message-----
> >>> From: Kumar Gala [mailto:galak at kernel.crashing.org]
> >>> Sent: Monday, August 10, 2009 13:41 PM
> >>> To: Wolfgang Denk
> >>> Cc: U-Boot-Users ML; Zang Roy-R61911
> >>> Subject: Re: 85xx: MPC8536DS board does not build
> >>>
> >>>
> >>> On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
> >>>
> >>>> Dear Kumar Gala,
> >>>>
> >>>> In message <0EB7516A-2F14-42F7-
> >>>> A6ED-555ADFAB3105 at kernel.crashing.org> you wrote:
> >>>>>> Allocate more space for U-Boot?
> >>>>> I might turn of BEDBUG as its never been properly enabled on
> >>>>> e500/85xx
> >>>>> platforms.
> >>>> Is there any problem with the bigger image which I don't understand
> >>>> yet? Normally we just move down the TEXT_BASE by a sector,
> >>> and that's
> >>>> it.
> >>> Not specifically, its just that ever 85xx image to date has been
> >>> 512k.  I'm just trying to avoid this being the first one that
> >>> changes
> >>> that historic fact.  Especially since compilers like gcc-4.3 seem to
> >>> be able to fit the size in 512k.
> >> We may have more requirements to support graphic in u-boot.
> >> Sooner and later, the size will exceed 512K. Should we have some plan
> >> for this?
> > 
> > So if we are going to increase the limit from 512k do we go to 768k or  
> > 1M?  (Sector size on the board appears to 128k)
> > 
> > I would also like to know how big the flashes are on some of the other  
> > 85xx boards that u-boot supports.
> > 
> > - k
> 
> Hi Kumar, Roy,
> 
> 512K is pretty big for u-boot (not unheard of, but still...).  Is it 
> really 512K or is it using a full page to hold the boot page (top 4K of 
> memory) and one page for the env (unavoidable):
> 
> +-------------------------------------------------------- 0x1_0000_0000
> | One sector dedicated for the power up page (only using 4K)
> +-------------------------------------------------------- 0x0_F800_0000
> | One sector dedicated for the env
> +-------------------------------------------------------- 0x0_F000_0000
> | Two sectors of u-boot
> +----                                                     0x0_E800_0000
> |
> +-------------------------------------------------------- 0x0_E000_0000
> 
> 
> If that is the case, you can gain a sector (less 4K) by rearranging your 
> memory map:
> +-------------------------------------------------------- 0x1_0000_0000
> | One page (4K) of power up vector, the rest is u-boot
> +----                                                     0x0_F800_0000
> |
> +----                                                     0x0_F000_0000
> | Three sectors (less 4K) of u-boot
> +-------------------------------------------------------- 0x0_E800_0000
> | One sector dedicated for the env
> +-------------------------------------------------------- 0x0_E000_0000
> 
> This also makes reprogramming u-boot nicer because your power up vector 
> and u-boot itself are contiguous.

Hi Jerry,
Currently a sector shouldn't be wasted just for the 4K boot page.  Your
second diagram above is similar to current operation - a chunk of the 4k
bootpage is wasted/unused, but other u-boot code shares the same flash
sector with the 4K boot page.  So a little space may be wasted, but not
too much (ie less than 4K).

Best,
Peter

[U-Boot] 85xx: MPC8536DS board does not build

[Kumar Gala]

On Aug 10, 2009, at 3:00 PM, Peter Tyser wrote:

> On Mon, 2009-08-10 at 15:27 -0400, Jerry Van Baren wrote:
>> Kumar Gala wrote:
>>> On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote:
>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Kumar Gala [mailto:galak at kernel.crashing.org]
>>>>> Sent: Monday, August 10, 2009 13:41 PM
>>>>> To: Wolfgang Denk
>>>>> Cc: U-Boot-Users ML; Zang Roy-R61911
>>>>> Subject: Re: 85xx: MPC8536DS board does not build
>>>>>
>>>>>
>>>>> On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
>>>>>
>>>>>> Dear Kumar Gala,
>>>>>>
>>>>>> In message <0EB7516A-2F14-42F7-
>>>>>> A6ED-555ADFAB3105 at kernel.crashing.org> you wrote:
>>>>>>>> Allocate more space for U-Boot?
>>>>>>> I might turn of BEDBUG as its never been properly enabled on
>>>>>>> e500/85xx
>>>>>>> platforms.
>>>>>> Is there any problem with the bigger image which I don't  
>>>>>> understand
>>>>>> yet? Normally we just move down the TEXT_BASE by a sector,
>>>>> and that's
>>>>>> it.
>>>>> Not specifically, its just that ever 85xx image to date has been
>>>>> 512k.  I'm just trying to avoid this being the first one that
>>>>> changes
>>>>> that historic fact.  Especially since compilers like gcc-4.3  
>>>>> seem to
>>>>> be able to fit the size in 512k.
>>>> We may have more requirements to support graphic in u-boot.
>>>> Sooner and later, the size will exceed 512K. Should we have some  
>>>> plan
>>>> for this?
>>>
>>> So if we are going to increase the limit from 512k do we go to  
>>> 768k or
>>> 1M?  (Sector size on the board appears to 128k)
>>>
>>> I would also like to know how big the flashes are on some of the  
>>> other
>>> 85xx boards that u-boot supports.
>>>
>>> - k
>>
>> Hi Kumar, Roy,
>>
>> 512K is pretty big for u-boot (not unheard of, but still...).  Is it
>> really 512K or is it using a full page to hold the boot page (top  
>> 4K of
>> memory) and one page for the env (unavoidable):
>>
>> +--------------------------------------------------------  
>> 0x1_0000_0000
>> | One sector dedicated for the power up page (only using 4K)
>> +--------------------------------------------------------  
>> 0x0_F800_0000
>> | One sector dedicated for the env
>> +--------------------------------------------------------  
>> 0x0_F000_0000
>> | Two sectors of u-boot
>> +----                                                      
>> 0x0_E800_0000
>> |
>> +--------------------------------------------------------  
>> 0x0_E000_0000
>>
>>
>> If that is the case, you can gain a sector (less 4K) by rearranging  
>> your
>> memory map:
>> +--------------------------------------------------------  
>> 0x1_0000_0000
>> | One page (4K) of power up vector, the rest is u-boot
>> +----                                                      
>> 0x0_F800_0000
>> |
>> +----                                                      
>> 0x0_F000_0000
>> | Three sectors (less 4K) of u-boot
>> +--------------------------------------------------------  
>> 0x0_E800_0000
>> | One sector dedicated for the env
>> +--------------------------------------------------------  
>> 0x0_E000_0000
>>
>> This also makes reprogramming u-boot nicer because your power up  
>> vector
>> and u-boot itself are contiguous.
>
> Hi Jerry,
> Currently a sector shouldn't be wasted just for the 4K boot page.   
> Your
> second diagram above is similar to current operation - a chunk of  
> the 4k
> bootpage is wasted/unused, but other u-boot code shares the same flash
> sector with the 4K boot page.  So a little space may be wasted, but  
> not
> too much (ie less than 4K).

Here's a readelf dump for the MPC8536DS built w/gcc 4.3.2:

Section Headers:
   [Nr] Name              Type            Addr     Off    Size   ES  
Flg Lk Inf Al
   [ 0]                   NULL            00000000 000000 000000  
00      0   0  0
   [ 1] .text             PROGBITS        eff80000 000080 0596f0 00   
AX  0   0 16
   [ 2] .rodata           PROGBITS        effd96f0 059770 00f158 00    
A  0   0  4
   [ 3] .reloc            PROGBITS        effe8900 068980 002d24 00   
WA  0   0  4
   [ 4] .data             PROGBITS        effeb628 06b6a8 004d84 00   
WA  0   0  8
   [ 5] .data.rel.ro.loca PROGBITS        efff03ac 07042c 00003c 00   
WA  0   0  4
   [ 6] .data.rel         PROGBITS        efff03e8 070468 003378 00   
WA  0   0  4
   [ 7] .data.rel.local   PROGBITS        efff3760 0737e0 0016ac 00   
WA  0   0  4
   [ 8] .data.rel.ro      PROGBITS        efff4e0c 074e8c 000020 00   
WA  0   0  4
   [ 9] .u_boot_cmd       PROGBITS        efff4e2c 074eac 000750 00   
WA  0   0  4
   [10] .bootpg           PROGBITS        effff000 07f080 0001cc 00   
AX  0   0  1
   [11] .resetvec         PROGBITS        effffffc 08007c 000004 00   
AX  0   0  1

We do waste a bit of space in the bootpg (~3.5k). Here's an idea on  
where space is being used:

u-boot:0000053c T radeon_setmode_9200
u-boot:00000568 T ft_cpu_setup
u-boot:0000058c T compute_lowest_common_dimm_parameters
u-boot:000005ac t ehci_submit_async
u-boot:000005b8 T nand_scan_ident
u-boot:000005c8 T ext2fs_read_file
u-boot:000005e4 t huft_build
u-boot:00000620 D spr_map
u-boot:00000640 T malloc
u-boot:00000644 T ehci_submit_root
u-boot:00000668 t write_bbt
u-boot:0000068c t fsl_ata_exec_ata_cmd
u-boot:000006dc t parse_stream_outer
u-boot:00000780 T do_nand
u-boot:00000810 T fsl_pci_init
u-boot:0000081c T flash_get_size
u-boot:00000834 T pci_header_show
u-boot:00000834 t run_list_real
u-boot:000008d8 T readline_into_buffer
u-boot:000008f8 T compute_fsl_memctl_config_regs
u-boot:00000900 T vsprintf
u-boot:000009c0 T do_fat_read
u-boot:00000b30 T do_fdt
u-boot:00001000 d video_fontdata
u-boot:00001900 D linux_logo
u-boot:00001aa8 T inflate
u-boot:00001d48 t e1000_init_hw
u-boot:000029d8 D opcodes

- k

[U-Boot] 85xx: MPC8536DS board does not build

[ksi at koi8.net]

On Mon, 10 Aug 2009, Kumar Gala wrote:

> 
> On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
> 
> > Dear Kumar Gala,
> >
> > In message <0EB7516A-2F14-42F7- 
> > A6ED-555ADFAB3105 at kernel.crashing.org> you wrote:
> >>
> >>> Allocate more space for U-Boot?
> >>
> >> I might turn of BEDBUG as its never been properly enabled on  
> >> e500/85xx
> >> platforms.
> >
> > Is there any problem with the bigger image which I don't understand
> > yet? Normally we just move down the TEXT_BASE by a sector, and that's
> > it.
> 
> Not specifically, its just that ever 85xx image to date has been  
> 512k.  I'm just trying to avoid this being the first one that changes  
> that historic fact.  Especially since compilers like gcc-4.3 seem to  
> be able to fit the size in 512k.

Off of 512K something like 1/3 is empty in e.g. MPC8548CDS. The very last
sector contains fixed location power-on boot vector, the beginning of those
512K has actual U-Boot code and the hole between them is big enough to fit
an entire sector for environment.

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************

[U-Boot] 85xx: MPC8536DS board does not build

[ksi at koi8.net]

On Mon, 10 Aug 2009, Peter Tyser wrote:

> On Mon, 2009-08-10 at 15:27 -0400, Jerry Van Baren wrote:
> > Kumar Gala wrote:
> > > On Aug 10, 2009, at 1:59 PM, Zang Roy-R61911 wrote:
> > > 
> > >>
> > >>> -----Original Message-----
> > >>> From: Kumar Gala [mailto:galak at kernel.crashing.org]
> > >>> Sent: Monday, August 10, 2009 13:41 PM
> > >>> To: Wolfgang Denk
> > >>> Cc: U-Boot-Users ML; Zang Roy-R61911
> > >>> Subject: Re: 85xx: MPC8536DS board does not build
> > >>>
> > >>>
> > >>> On Aug 10, 2009, at 1:22 PM, Wolfgang Denk wrote:
> > >>>
> > >>>> Dear Kumar Gala,
> > >>>>
> > >>>> In message <0EB7516A-2F14-42F7-
> > >>>> A6ED-555ADFAB3105 at kernel.crashing.org> you wrote:
> > >>>>>> Allocate more space for U-Boot?
> > >>>>> I might turn of BEDBUG as its never been properly enabled on
> > >>>>> e500/85xx
> > >>>>> platforms.
> > >>>> Is there any problem with the bigger image which I don't
> understand
> > >>>> yet? Normally we just move down the TEXT_BASE by a sector,
> > >>> and that's
> > >>>> it.
> > >>> Not specifically, its just that ever 85xx image to date has been
> > >>> 512k.  I'm just trying to avoid this being the first one that
> > >>> changes
> > >>> that historic fact.  Especially since compilers like gcc-4.3 seem
> to
> > >>> be able to fit the size in 512k.
> > >> We may have more requirements to support graphic in u-boot.
> > >> Sooner and later, the size will exceed 512K. Should we have some
> plan
> > >> for this?
> > > 
> > > So if we are going to increase the limit from 512k do we go to 768k
> or  
> > > 1M?  (Sector size on the board appears to 128k)
> > > 
> > > I would also like to know how big the flashes are on some of the
> other  
> > > 85xx boards that u-boot supports.
> > > 
> > > - k
> > 
> > Hi Kumar, Roy,
> > 
> > 512K is pretty big for u-boot (not unheard of, but still...).  Is it 
> > really 512K or is it using a full page to hold the boot page (top 4K
> of 
> > memory) and one page for the env (unavoidable):
> > 
> > +--------------------------------------------------------
> 0x1_0000_0000
> > | One sector dedicated for the power up page (only using 4K)
> > +--------------------------------------------------------
> 0x0_F800_0000
> > | One sector dedicated for the env
> > +--------------------------------------------------------
> 0x0_F000_0000
> > | Two sectors of u-boot
> > +----
> 0x0_E800_0000
> > |
> > +--------------------------------------------------------
> 0x0_E000_0000
> > 
> > 
> > If that is the case, you can gain a sector (less 4K) by rearranging
> your 
> > memory map:
> > +--------------------------------------------------------
> 0x1_0000_0000
> > | One page (4K) of power up vector, the rest is u-boot
> > +----
> 0x0_F800_0000
> > |
> > +----
> 0x0_F000_0000
> > | Three sectors (less 4K) of u-boot
> > +--------------------------------------------------------
> 0x0_E800_0000
> > | One sector dedicated for the env
> > +--------------------------------------------------------
> 0x0_E000_0000
> > 
> > This also makes reprogramming u-boot nicer because your power up
> vector 
> > and u-boot itself are contiguous.
> 
> Hi Jerry,
> Currently a sector shouldn't be wasted just for the 4K boot page.  Your
> second diagram above is similar to current operation - a chunk of the 4k
> bootpage is wasted/unused, but other u-boot code shares the same flash
> sector with the 4K boot page.  So a little space may be wasted, but not
> too much (ie less than 4K).

That is where top boot block flashes come handy... It is not just that 128K
sector is a huge waste for 4K boot block, the same is true for
environment...

---
******************************************************************
*  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
*  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
******************************************************************