Configuring load address and entry point address of OS image

[Swapnil Ashok Narkhede]

Hi,

I am working on porting U-boot on pxa255.
I have ported u-boot sucessfully and now
i have to get the OS runing on the board.

I am loading the U-Image at 0xa0800000
and then i execute command
bootm 0xa0800000.
After this i get the following output
o/p>>>
SWAP$ bootm 0xa0800000
## Booting image at a0800000 ...
Image Name: Linux Kernel Image
Image Type: ARM Linux Kernel Image (gzip compressed)
Data Size: 771905 Bytes = 753.8 kB
Load Address: a0800000
Entry Point: a0800000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK

Starting kernel ...
o/p<<

As per the feedback from u-boot mailing list
i understand that the load address and entry point address
are not specified properly.
As per the information i gathered

So how do i look up for the proper load address and entry point
address.

You cannot "look it up". You define a memory map for your system. You
configure the Linux kernel according to this memory map. You enter
the corresponding values for load address and antry point when
running the mkimage tool. Then you add at least 2 MB (better a bit
more) to your load address and use this as download address in
U-Boot.

How do i define a memory map and configure the linux kernel to use it.
How do i understand what should be the load address and entry point address
for the OS(U-IMAGE).

Help me resolve this error.



Regards,
Swapnil Narkhede
Mob:- 0432025023
Email:- ***@student.rmit.edu.au
School of Computer Science and Information Technology
RMIT University, Melbourne


-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

[Wolfgang Denk]

Post by Swapnil Ashok Narkhede
I am loading the U-Image at 0xa0800000

...

Post by Swapnil Ashok Narkhede
Load Address: a0800000
Entry Point: a0800000

...

Post by Swapnil Ashok Narkhede
As per the feedback from u-boot mailing list
i understand that the load address and entry point address
are not specified properly.

As you have been told before, at leas the download address must be
sufficiently different (2 or more MB apart) from the Load and Entry
Point addresses. That does not necessarily mean that your load
address or entry point is wrong. It means that the _combination_ is
bound to fail (as it does).

Best regards,

Wolfgang Denk

[alfred hitch]

Hi Wolfgang,

I am also trying something on similar lines and would appreciate your help
..

We were running on IXP425 u-boot with snapgear arm linux distro. 64MB of RAM
.

The uImage for board was built using load and entry point address both set
to 0x01600000. (Uncompressed image from u-boot perspective, as in -C none
was given).

So, if I understand it correctly the uImage header info is applied on top of
zImage passed to u-boot-mkimage command line.
u-boot will download the kernel image from flash address to configured
download and entry point address.
and execute starting at the entry point.

If the kernel at this stage is a compressed one (zImage), setup function
from kernel code will call inflate function which shall download the
uncompressed image to say HIGH ram area of 1MB ..
Am I correct in guessing this so far ..

Now, I am facing an intriguing issue, board designer changed something on
board layout (excluding DRAM), memory size and chip's also infact remain
same ..
but while booting kernel,
we get :
Uncompressing Linux ......................
crc error.
-- System halted ..


What this tells me is that kernel image crc calculated by setup function and
what was stored / found in decompressed image isnt matching ?

I have been trying to figure out what could be happening here ..
as everything here seems to be fine, if on same problematic board we change
configuration for memory passed in kernel args to 32, everything is fine !!

This baffles me,
Everything at this stage is apparently in less than 32 MB for sure, the
download address i s 22 MB at max and image size is 700K
Any corrections / comments / ideas ?

1) where in kernel can I be sure of the place where decompression scratch
pad is ??
2) where is final uncompressed kernel image being downloaded declaration in
kernel code to be very sure ..

Alfred

Post by Swapnil Ashok Narkhede
I am loading the U-Image at 0xa0800000

...

Post by Swapnil Ashok Narkhede
Load Address: a0800000
Entry Point: a0800000

...

Post by Swapnil Ashok Narkhede
As per the feedback from u-boot mailing list
i understand that the load address and entry point address
are not specified properly.

As you have been told before, at leas the download address must be
sufficiently different (2 or more MB apart) from the Load and Entry
Point addresses. That does not necessarily mean that your load
address or entry point is wrong. It means that the _combination_ is
bound to fail (as it does).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
The software required `Windows 95 or better', so I installed Linux.
-------------------------------------------------------------------
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

[Russell King - ARM Linux]

Post by alfred hitch
Now, I am facing an intriguing issue, board designer changed something on
board layout (excluding DRAM), memory size and chip's also infact remain
same ..
but while booting kernel,
Uncompressing Linux ......................
crc error.
-- System halted ..

That means you're seeing memory corruption.

Post by alfred hitch
What this tells me is that kernel image crc calculated by setup function and
what was stored / found in decompressed image isnt matching ?

No. This CRC is calculated by the gzip step in the kernel build. It is
checked during decompression, as each byte of the kernel is decompressed,
and found to not match.

This means that either the decompression functions or the compressed
kernel image data is corrupt.

(The decompression functions do _not_ check the integrity of the
decompressed kernel image read back from RAM, so if the kernel image
is written to an area of bad memory, the CRC will not find it.)

So, if uboot decided that the image it placed into memory was correct,
but on decompression is found to be incorrect, I suggest you have bad
memory.

Try running it on an identical board.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

[Wolfgang Denk]

Post by Russell King - ARM Linux

Post by alfred hitch
but while booting kernel,
Uncompressing Linux ......................
crc error.

It would have been interesting to see how exactly the original poster
booted the image.

Post by Russell King - ARM Linux
That means you're seeing memory corruption.

Yes, but the reason is usually simply a pilot error.

Post by Russell King - ARM Linux
So, if uboot decided that the image it placed into memory was correct,
but on decompression is found to be incorrect, I suggest you have bad
memory.

In most cases it's just a user error. Actually it's a FAQ:
http://www.denx.de/twiki/bin/view/DULG/LinuxUncompressingError

People just tend to ignore the available documentation.

Best regards,

Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: [phone] Fax: [phone] Email: ***@denx.de
SW engineering is a race between programmers trying to make better
idiot-proof programs and the universe producing greater idiots.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

[Russell King - ARM Linux]

Post by Russell King - ARM Linux
So, if uboot decided that the image it placed into memory was correct,
but on decompression is found to be incorrect, I suggest you have bad
memory.

http://www.denx.de/twiki/bin/view/DULG/LinuxUncompressingError

That FAQ entry is actually wrong for ARM - we go to great extremes in
the decompressor to avoid overwriting ourselves.

Maybe PPC is less careful than ARM in this respect.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

[alfred hitch]

Hi Russel, Wolfgang,

thanks for your replies ..

yea (ofcourse) russel is right that the image being zImage has to still be
expanded by kernel code ..and thats where the cribbing is ..
infact as I had mentioned in original post also image is not gzip'ed from
u-boot perspective.

well as I said whats intriguing to me is that same software (kernel + u-boot
for discussion sake) is running fine on earlier boards, and even on same
board if I change kernel MEM passed to 32MB .. things are ok, its 2 chips of
32 MB each ..
thats why I am clueless as to why when all this is happening in less than
32MB space, is the problem coming ..
there has been some hardware change in PCB layout (h/w engg is swearing to
god he didnt look at dram side even for changes) ..

I did a memory pattern filling test yesterday from u-boot and it did report
errors in above memory > 32 MB area ..
but I am still not being able to understand why would cause kernel loading
to fail .

2) Can some one please correct me as to if u-boot load address is 0x01600000
(= entry addres)
then this is the address at which u-boot offloads the kernel (after its
decompression had that been the case)
and that where life begins for kernel setup function .. rite ?
then the kernel code for say ixdp425 plattform (again asking which file has
this ?) will inflate code to 1MB physical area ..

Alfred

Alfred

Post by Russell King - ARM Linux

Post by alfred hitch
Now, I am facing an intriguing issue, board designer changed something

on

Post by alfred hitch
board layout (excluding DRAM), memory size and chip's also infact remain
same ..
but while booting kernel,
Uncompressing Linux ......................
crc error.
-- System halted ..

That means you're seeing memory corruption.

Post by alfred hitch
What this tells me is that kernel image crc calculated by setup function

and

Post by alfred hitch
what was stored / found in decompressed image isnt matching ?

No. This CRC is calculated by the gzip step in the kernel build. It is
checked during decompression, as each byte of the kernel is decompressed,
and found to not match

This means that either the decompression functions or the compressed

Post by Russell King - ARM Linux
kernel image data is corrupt.
(The decompression functions do _not_ check the integrity of the
decompressed kernel image read back from RAM, so if the kernel image
is written to an area of bad memory, the CRC will not find it.)
So, if uboot decided that the image it placed into memory was correct,
but on decompression is found to be incorrect, I suggest you have bad
memory.
Try running it on an identical board.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

[Wolfgang Denk]

Post by alfred hitch
The uImage for board was built using load and entry point address both set
to 0x01600000. (Uncompressed image from u-boot perspective, as in -C none
was given).
So, if I understand it correctly the uImage header info is applied on top of
zImage passed to u-boot-mkimage command line.

Yes, but you don't have to care about this.

Post by alfred hitch
u-boot will download the kernel image from flash address to configured
download and entry point address.
and execute starting at the entry point.

No. The *download* will be done to the download address you pass on
the command line for the TFTP or NFS or whatever download coimmand
you use, or the configured default value. Thsi has NOTHING to do with
the kernel's load address. The load address is where the image will
be stored when uncompressing the image.

Post by alfred hitch
If the kernel at this stage is a compressed one (zImage), setup function

With U-Boot, you don't use zImage files, you use uImages.

Post by alfred hitch
from kernel code will call inflate function which shall download the
uncompressed image to say HIGH ram area of 1MB ..

No. Uncompression is done by U-Boot. A properly built uImage file
does not need to contain any code for uncompression - this is already
done in the boot loader.

You just have to remember that the area from <load address> to <load
address + size of uncompressed kernel image> will be needed to store
the uncompressed kernel image. So youu must not place any data you
may need in this area. Especially, you must not store the downloaded
(compressed) image there, because then unt uncompressed code will
overwrite the not-yet-processed parts of your compressed image, which
will cause exactly the type of error messages you see.


All this is a FAQ! Please *read* the documentation.

Best regards,

Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: [phone] Fax: [phone] Email: ***@denx.de
"An open mind has but one disadvantage: it collects dirt."
- a saying at RPI

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

[Wolfgang Denk]

http://www.denx.de/twiki/bin/view/DULG/LinuxUncompressingError

That FAQ entry is actually wrong for ARM - we go to great extremes in
the decompressor to avoid overwriting ourselves.

Maybe. But U-Boot does not use the kernel's uncompressing code.
[There is no need to duplicate the same function again and again.]
The uncompressing of the gzipped image is done withing U-Boot, and
U-Boot gives you the freedom to shoot yourself.

Best regards,

Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: [phone] Fax: [phone] Email: ***@denx.de
As long as we're going to reinvent the wheel again, we might as well
try making it round this time. - Mike Dennison

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

[Russell King - ARM Linux]

Post by Wolfgang Denk

http://www.denx.de/twiki/bin/view/DULG/LinuxUncompressingError

That FAQ entry is actually wrong for ARM - we go to great extremes in
the decompressor to avoid overwriting ourselves.

Maybe. But U-Boot does not use the kernel's uncompressing code.

Wrong. If you wrap a zImage inside a uImage, it _will_ use the kernels
decompressing code. If you read the original posting, you'll notice
that this is what has been done.

Post by Wolfgang Denk
[There is no need to duplicate the same function again and again.]

Precisely, which is why I fundamentally don't like uboot. It's over
complex for the needs of ARM.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

[Wolfgang Denk]

Post by Russell King - ARM Linux

Post by Wolfgang Denk
Maybe. But U-Boot does not use the kernel's uncompressing code.

Wrong. If you wrap a zImage inside a uImage, it _will_ use the kernels
decompressing code. If you read the original posting, you'll notice
that this is what has been done.

Then this was another pilot error.

Post by Russell King - ARM Linux

Post by Wolfgang Denk
[There is no need to duplicate the same function again and again.]

Precisely, which is why I fundamentally don't like uboot. It's over
complex for the needs of ARM.

Well, not all the world's an ARM. And even on ARM it is IMHO
beneficial to have such a feature in one central place; for example
it can reduce the flash memory footprint in case you have to store
more than one kernel image. But YMMV, and if you don't like U-Boot
you don't have to use it as there is a plethora of other, dumber boot
loaders.

Best regards,

Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: [phone] Fax: [phone] Email: ***@denx.de
Peace was the way.
-- Kirk, "The City on the Edge of Forever", stardate unknown

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

[Russell King - ARM Linux]

Post by Wolfgang Denk

Post by Russell King - ARM Linux

Post by Wolfgang Denk
Maybe. But U-Boot does not use the kernel's uncompressing code.

Wrong. If you wrap a zImage inside a uImage, it _will_ use the kernels
decompressing code. If you read the original posting, you'll notice
that this is what has been done.

Then this was another pilot error.

No. An uncompressed ARM image has more strict entry requirements than
a compressed ARM image. What this means is that a compressed ARM image
is actually safer, and can be used where ever an uncompressed ARM image
has been used.

Therefore, this is not pilot error, but a case of someone wanting to take
advantage of the kernels own in-built protection against problems caused
by poor hardware design. The fact that uboot developers inherently dislike
it is precisely the same as me disliking uboot.

_And_ the kernels own decompressor does catch a lot of hardware problems
as has been proven by experience (read this list archives.)

Therefore, I still say your FAQ entry in the case of ARM is wrong, and
pointing someone using ARM to such an entry is worse than wrong - it's
deliberately misleading.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

[alfred hitch]

the bootm command in u-boot by the way (for working and not working both) is
:

bootm 0x50040000

This is the flash partition directly..
so its picking from flash and so if I understand it correctly
the kernel very initial code will be executed from flash directly, and will
directly decompress image into RAM ..
compressed image never gets to (be played with electrons and) pushed into
DRAM.

If above was true, I am really hungry now to know how come I am see'ing this
error image in flash is ofcourse ok as 32 MB same board (_as_passed RAM from
bootloader_) no issues ..

Alfred

http://www.denx.de/twiki/bin/view/DULG/LinuxUncompressingError

That FAQ entry is actually wrong for ARM - we go to great extremes in
the decompressor to avoid overwriting ourselves.

Maybe. But U-Boot does not use the kernel's uncompressing code.

Wrong. If you wrap a zImage inside a uImage, it _will_ use the kernels
decompressing code. If you read the original posting, you'll notice
that this is what has been done.

[There is no need to duplicate the same function again and again.]

Precisely, which is why I fundamentally don't like uboot. It's over
complex for the needs of ARM.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

[Russell King - ARM Linux]

Post by alfred hitch
the bootm command in u-boot by the way (for working and not working both) is
bootm 0x50040000
This is the flash partition directly..
so its picking from flash and so if I understand it correctly
the kernel very initial code will be executed from flash directly, and will
directly decompress image into RAM ..
compressed image never gets to (be played with electrons and) pushed into
DRAM.
If above was true, I am really hungry now to know how come I am see'ing this
error image in flash is ofcourse ok as 32 MB same board (_as_passed RAM from
bootloader_) no issues ..

The CRC error all points towards the source image becoming corrupted
in some way between the point when the zImage was created, and the
point it has been read from flash by the CPU. That could mean:

1. it wasn't correctly programmed into flash from the start.
2. the compressed image is being overwritten during decompression.
3. you didn't set the appropriate configuration options (for the
decompressor to run from flash)
4. it isn't being correctly read from flash during the decompression
stage due to a hardware problem.

(1) is unlikely since I would think uboot would catch it. (2) won't
happen if you're using zImage from flash. This leaves (3) and (4).


-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

[Wolfgang Denk]

Post by alfred hitch
bootm 0x50040000
This is the flash partition directly..
so its picking from flash and so if I understand it correctly
the kernel very initial code will be executed from flash directly, and will

No. U-Boot will copy (and uncompress on the fly, if told so) your
code to the memory range starting at "load address", and then jumpt
to "entry point address". IIRC these addresses were in RAM in your
case, so U-Boot will perform the copy, and then pass control to the
Linux kernel, which then is running from RAM.

Post by alfred hitch
directly decompress image into RAM ..
compressed image never gets to (be played with electrons and) pushed into>
DRAM.

Yes, it does. If you use a "zImage" file and tell U-Boot it's a not
compressed then U-Boot will copy the (compressed) zImage to the load
address (in RAM). See above.


Best regards,

Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: [phone] Fax: [phone] Email: ***@denx.de
The human mind treats a new idea the way the body treats a strange
protein - it rejects it. - P. Medawar

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php

[Kenneth Crudup]

Hey! Some of us *like* U-Boot!

-Kenny, who will usually wipe whatever I was handed before, and
port u-boot in its place

[Holger Schurig]

Post by Russell King - ARM Linux
Precisely, which is why I fundamentally don't like uboot. It's over
complex for the needs of ARM.

And that's why I wrote my own patch for u-boot to let it simply call the
zImage-uncompressor of Linux. I don't need/use any of the uImage features
(like the uImage-embedded initial ramdisk). For me, it was just another layer
of indirection. Which I got rid with this patch.