[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