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

Kumar Gala galak at kernel.crashing.org
Mon Aug 10 22:21:08 CEST 2009


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


More information about the U-Boot mailing list