[U-Boot-Users] newbie: How to avoid memory area overlapping?

[Detlev Zundel]

Hi 甜瓜,

> Howdy,
>     I use uboot + linux kernel + ramdisk to start the board. The
> kernel and ramdisk (say uImage and Ramdisk)
> are stored on my PC. Each time, by typing:
>     tftp 200000 uImage
>     tftp 600000 Ramdisk
> these two files are loaded to memory. Then enter "bootm 200000 600000"
> to real boot. Well, I am a little
> confused about the booting.
> 1. There are only 32MB memory on board. As documented, uboot will copy
> itself from flash to the tail of
>     memory address. That means, if flash_size=512KB, the memory image
> of uboot would located at
>     0x01F80000. Am I right? 

Not quite. CFG_FLASH_SIZE is only used for initial mappings of flash and
is thus connected to the actual flash chip, whereas the relocation
really uses a symbol to find the size of U-Boot text segment (check
board_init_f in lib_ppc/board.c for ppc systems).

> But "md 0x01F80000" does not show data
> pattern similar to uboot itself.
>     Why? Is this address assigned to other purpose?

U-Boot in your case will likely be somewhat higher as U-Boot seldomly
exactly uses the flash sectors.  An easy way is to enable DEBUG in
board.c and study U-Boots output on booting.

> 2. uImage and Ramdisk are gzipped files. uboot should decompress them
> first. Which address will uboot
>     store decompress data? Since uboot didn't know the file size of
> uImage and Ramdisk, how does uboot
>     arrange memory areas to avoid overlapping? I mean decompressed
> data might overwrite each other or
>     overwrite the original gzipped data.

You can find answers to all these questions by studying code.  If you
start looking into common/cmd_bootm.c, especially do_bootm you'll see
what is actually happening.  Even better, step through that code on your
platform and check all the calculated values...

Furthermore simply reading U-Boots outputs can help enormously - for
example from my sample session:

  => run flash_self
  ## Booting kernel from Legacy Image at fc000000 ...
     Image Name:   Linux-2.6.17-g0cae0ffb-dirty
     Image Type:   PowerPC Linux Kernel Image (gzip compressed)
     Data Size:    1335525 Bytes =  1.3 MB
     Load Address: 00000000
     Entry Point:  00000000

We really load the kernel to address 0.

     Verifying Checksum ... OK
     Uncompressing Kernel Image ... OK
  ## Loading init Ramdisk from Legacy Image at fc180000 ...
     Image Name:   Simple Embedded Linux Framework
     Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
     Data Size:    1386357 Bytes =  1.3 MB
     Load Address: 00000000
     Entry Point:  00000000

Ok, load and entry point are moot for ramdisks, but

     Verifying Checksum ... OK
     Loading Ramdisk to 0fdd9000, end 0ff2b775 ... OK

U-Boot is friendly enough to tell us where the ramdisk ends up (my
system has 256MB of RAM).
  
> 3. When the control goes to linux, linux will manage whole memory. But
> it does not know anything about
>     uboot arrangement. How does linux avoid occasionally damaging the
> decompressed data of
>     uImage/Ramdisk which hosted by uboot?

The pointer to the ramdisk is a parameter to Linux so it knows how to
avoid damaging it...

Cheers
  Detlev

-- 
Ftpd never switches uid and euid, it uses setfsuid(2) instead. The
main reason is that uid switching has been exploited in several
breakins, but the sheer ugliness of uid switching counts too.
                                     -- pure-ftpd(8)
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de