From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kumar Gala Date: Mon, 10 Aug 2009 15:21:08 -0500 Subject: [U-Boot] 85xx: MPC8536DS board does not build In-Reply-To: <1249934433.11514.633.camel@localhost.localdomain> References: <20090810075631.B68EC833DBD2@gemini.denx.de> <0E1A5EEB-51E5-488D-9457-993F95553506@kernel.crashing.org> <20090810175934.5AB66833DBD2@gemini.denx.de> <0EB7516A-2F14-42F7-A6ED-555ADFAB3105@kernel.crashing.org> <20090810182222.70532833DBD2@gemini.denx.de> <3B2BBF16-F683-4711-9844-FF9D8BBBAEFE@kernel.crashing.org> <7DF0AF56456B8F4081E3C44CCCE311DE4E9B16@zch01exm23.fsl.freescale.net> <4A8074B2.2010403@ge.com> <1249934433.11514.633.camel@localhost.localdomain> Message-ID: <997DCFD8-BBAE-466F-B7C3-C49DA32E8B66@kernel.crashing.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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