make PHYS_OFFSET determined at run time (unfinished)

Signed-off-by Uwe Kleine-K?nig <[email protected]>

This was deprecated in 2001 and announced to live on for 5 years.

Hello,

I'm looking into making PHYS_OFFSET determined at run time. I saw a patch for it that already made it a few times on the list[1].

I'm not yet done, but first want to announce that I look into that to prevent duplicate work---so if you intended to do the same let's look together---and to post some clean up patches that are the result up to now of my digging in the boot code.

I will send now three patches in reply to this mail, and later hopefully more.

Best regards
Uwe

[1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/

Quoted 10 lines · Uwe Kleine-K?nig

Hello,

I'm looking into making PHYS_OFFSET determined at run time. I saw a patch for it that already made it a few times on the list[1].

I'm not yet done, but first want to announce that I look into that to prevent duplicate work---so if you intended to do the same let's look together---and to post some clean up patches that are the result up to now of my digging in the boot code.

Quoted 8 lines

I will send now three patches in reply to this mail, and later hopefully more.

Best regards
Uwe

[1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/

One of the problems that got brought up previously was the 'make uImage' can end up generating unbootable images with runtime PHYS_OFFSET. The older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so uImage's need to have a fixed load address encoded.

As I stated in the previous thread, this is _not_ a kernel issue, however it is no good having a kernel which contains support for two boards which boot from different address and then generating a uImage which can only boot on one of them without warning the user about this problem. Otherwise you are going to start getting "I did make uImage and my board won't boot" problems.

There are a few solutions to this problem:
1) Drop uImage make support and require users generate them manually.
2) Have a uImage offset config option to allow uImage users to specify what they want the load address to be. See:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
3) Print an error if "make uImage" is run for a kernel which has more than one boot address (possible?)
4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards, however a number of people are still using older U-Boots.

~Ryan

Signature · 12 lines

Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 32 lines · Ryan Mallon

Quoted 10 lines · Uwe Kleine-K?nig

Hello,

I'm looking into making PHYS_OFFSET determined at run time. I saw a patch for it that already made it a few times on the list[1].

I'm not yet done, but first want to announce that I look into that to prevent duplicate work---so if you intended to do the same let's look together---and to post some clean up patches that are the result up to now of my digging in the boot code.

Quoted 8 lines

I will send now three patches in reply to this mail, and later hopefully more.

Best regards
Uwe

[1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/

One of the problems that got brought up previously was the 'make uImage' can end up generating unbootable images with runtime PHYS_OFFSET. The older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so uImage's need to have a fixed load address encoded.

As I stated in the previous thread, this is _not_ a kernel issue, however it is no good having a kernel which contains support for two boards which boot from different address and then generating a uImage which can only boot on one of them without warning the user about this problem. Otherwise you are going to start getting "I did make uImage and my board won't boot" problems.

Quoted 9 lines

There are a few solutions to this problem:
1) Drop uImage make support and require users generate them manually.
2) Have a uImage offset config option to allow uImage users to specify what they want the load address to be. See:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
3) Print an error if "make uImage" is run for a kernel which has more than one boot address (possible?)
4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards, however a number of people are still using older U-Boots.

Or of course, boot zImages. I belive u-boot has support for zImage.

Quoted 43 lines · Ben Dooks

Quoted 41 lines · Ryan Mallon

Quoted 10 lines · Uwe Kleine-K?nig

Hello,

I'm looking into making PHYS_OFFSET determined at run time. I saw a patch for it that already made it a few times on the list[1].

I'm not yet done, but first want to announce that I look into that to prevent duplicate work---so if you intended to do the same let's look together---and to post some clean up patches that are the result up to now of my digging in the boot code.

Quoted 8 lines

I will send now three patches in reply to this mail, and later hopefully more.

Best regards
Uwe

[1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/

One of the problems that got brought up previously was the 'make uImage' can end up generating unbootable images with runtime PHYS_OFFSET. The older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so uImage's need to have a fixed load address encoded.

As I stated in the previous thread, this is _not_ a kernel issue, however it is no good having a kernel which contains support for two boards which boot from different address and then generating a uImage which can only boot on one of them without warning the user about this problem. Otherwise you are going to start getting "I did make uImage and my board won't boot" problems.

There are a few solutions to this problem:
1) Drop uImage make support and require users generate them manually.
2) Have a uImage offset config option to allow uImage users to specify what they want the load address to be. See:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
3) Print an error if "make uImage" is run for a kernel which has more than one boot address (possible?)
4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards, however a number of people are still using older U-Boots.

Quoted 1 line

Or of course, boot zImages. I belive u-boot has support for zImage.

Is there a clean way to pass kernel parameters and machine type from u-boot to zImage? Last time I boot zImage in u-boot, some ugly hack was needed in ARM startup code. Just wondering if there is a better way.

Thanks

Steve

Quoted 44 lines · Steve Chen

Quoted 43 lines · Ben Dooks

Quoted 41 lines · Ryan Mallon

Quoted 10 lines · Uwe Kleine-K?nig

Hello,

I'm looking into making PHYS_OFFSET determined at run time. I saw a patch for it that already made it a few times on the list[1].

I'm not yet done, but first want to announce that I look into that to prevent duplicate work---so if you intended to do the same let's look together---and to post some clean up patches that are the result up to now of my digging in the boot code.

Quoted 8 lines

I will send now three patches in reply to this mail, and later hopefully more.

Best regards
Uwe

[1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/

One of the problems that got brought up previously was the 'make uImage' can end up generating unbootable images with runtime PHYS_OFFSET. The older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so uImage's need to have a fixed load address encoded.

As I stated in the previous thread, this is _not_ a kernel issue, however it is no good having a kernel which contains support for two boards which boot from different address and then generating a uImage which can only boot on one of them without warning the user about this problem. Otherwise you are going to start getting "I did make uImage and my board won't boot" problems.

There are a few solutions to this problem:
1) Drop uImage make support and require users generate them manually.
2) Have a uImage offset config option to allow uImage users to specify what they want the load address to be. See:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
3) Print an error if "make uImage" is run for a kernel which has more than one boot address (possible?)
4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards, however a number of people are still using older U-Boots.

Quoted 5 lines

Quoted 1 line

Or of course, boot zImages. I belive u-boot has support for zImage.

Is there a clean way to pass kernel parameters and machine type from u-boot to zImage? Last time I boot zImage in u-boot, some ugly hack was needed in ARM startup code. Just wondering if there is a better way.

u-boot should be doing the right thing, I thought uImage was simply a zImage wrapped in the right uboot descriptors to tell uboot it was a kernel and where to load it.

Certianly uboots i've used can boto zImage just fine.

Quoted 8 lines

Quoted 3 lines

Is there a clean way to pass kernel parameters and machine type from u-boot to zImage? Last time I boot zImage in u-boot, some ugly hack was needed in ARM startup code. Just wondering if there is a better way.

u-boot should be doing the right thing, I thought uImage was simply a zImage wrapped in the right uboot descriptors to tell uboot it was a kernel and where to load it.

Quoted 1 line

Certianly uboots i've used can boto zImage just fine.

I'm also able to boot zImage under u-boot. However, I had to set r1 manually, and I don't know how to pass kernel parameters (stuff passed into kernel uImage via bootargs) to zImage. Any tips will be greatly appreciated.

Quoted 55 lines · Ben Dooks

Quoted 44 lines · Steve Chen

Quoted 43 lines · Ben Dooks

Quoted 41 lines · Ryan Mallon

Quoted 10 lines · Uwe Kleine-K?nig

Hello,

I'm looking into making PHYS_OFFSET determined at run time. ?I saw a patch for it that already made it a few times on the list[1].

I'm not yet done, but first want to announce that I look into that to prevent duplicate work---so if you intended to do the same let's look together---and to post some clean up patches that are the result up to now of my digging in the boot code.

Quoted 8 lines

I will send now three patches in reply to this mail, and later hopefully more.

Best regards
Uwe

[1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/

One of the problems that got brought up previously was the 'make uImage' can end up generating unbootable images with runtime PHYS_OFFSET. The older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so uImage's need to have a fixed load address encoded.

As I stated in the previous thread, this is _not_ a kernel issue, however it is no good having a kernel which contains support for two boards which boot from different address and then generating a uImage which can only boot on one of them without warning the user about this problem. Otherwise you are going to start getting "I did make uImage and my board won't boot" problems.

There are a few solutions to this problem:
1) Drop uImage make support and require users generate them manually.
2) Have a uImage offset config option to allow uImage users to specify what they want the load address to be. See:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
3) Print an error if "make uImage" is run for a kernel which has more than one boot address (possible?)
4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards, however a number of people are still using older U-Boots.

Quoted 5 lines

Quoted 1 line

Or of course, boot zImages. I belive u-boot has support for zImage.

Is there a clean way to pass kernel parameters and machine type from u-boot to zImage? ?Last time I boot zImage in u-boot, some ugly hack was needed in ARM startup code. ?Just wondering if there is a better way.

u-boot should be doing the right thing, I thought uImage was simply a zImage wrapped in the right uboot descriptors to tell uboot it was a kernel and where to load it.

Quoted 1 line

Certianly uboots i've used can boto zImage just fine.

I'm also able to boot zImage under u-boot. ?However, I had to set r1 manually, and I don't know how to pass kernel parameters (stuff passed into kernel uImage via bootargs) to zImage. ?Any tips will be greatly appreciated.

Quoted 52 lines · Steve Chen

Quoted 51 lines · Ben Dooks

Quoted 42 lines · Steve Chen

Quoted 41 lines · Ben Dooks

Quoted 40 lines · Ryan Mallon

Quoted 10 lines · Uwe Kleine-K?nig

Hello,

I'm looking into making PHYS_OFFSET determined at run time. I saw a patch for it that already made it a few times on the list[1].

I'm not yet done, but first want to announce that I look into that to prevent duplicate work---so if you intended to do the same let's look together---and to post some clean up patches that are the result up to now of my digging in the boot code.

Quoted 8 lines

I will send now three patches in reply to this mail, and later hopefully more.

Best regards
Uwe

[1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/

One of the problems that got brought up previously was the 'make uImage' can end up generating unbootable images with runtime PHYS_OFFSET. The older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so uImage's need to have a fixed load address encoded.

As I stated in the previous thread, this is _not_ a kernel issue, however it is no good having a kernel which contains support for two boards which boot from different address and then generating a uImage which can only boot on one of them without warning the user about this problem. Otherwise you are going to start getting "I did make uImage and my board won't boot" problems.

There are a few solutions to this problem:
1) Drop uImage make support and require users generate them manually.
2) Have a uImage offset config option to allow uImage users to specify what they want the load address to be. See:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
3) Print an error if "make uImage" is run for a kernel which has more than one boot address (possible?)
4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards, however a number of people are still using older U-Boots.

Quoted 4 lines

Quoted 1 line

Or of course, boot zImages. I belive u-boot has support for zImage.

Is there a clean way to pass kernel parameters and machine type from u-boot to zImage? Last time I boot zImage in u-boot, some ugly hack was needed in ARM startup code. Just wondering if there is a better way.

u-boot should be doing the right thing, I thought uImage was simply a zImage wrapped in the right uboot descriptors to tell uboot it was a kernel and where to load it.

Quoted 5 lines

Quoted 1 line

Certianly uboots i've used can boto zImage just fine.

I'm also able to boot zImage under u-boot. However, I had to set r1 manually, and I don't know how to pass kernel parameters (stuff passed into kernel uImage via bootargs) to zImage. Any tips will be greatly appreciated.

Perhaps you use 'go' instead of 'bootm' command in u-boot? How about:-

u-boot # <load zImage@_addr_ by some means>

u-boot # setenv machid <your machine ID in hex without the '0x'> u-boot # saveenv //persistently save the machid

             // now you don't need to set machid even after cold reset

u-boot # bootm _addr_

hth.

Quoted 69 lines · jassi brar

Quoted 52 lines · Steve Chen

Quoted 51 lines · Ben Dooks

Quoted 42 lines · Steve Chen

Quoted 41 lines · Ben Dooks

Quoted 40 lines · Ryan Mallon

Quoted 10 lines · Uwe Kleine-K?nig

Hello,

I'm looking into making PHYS_OFFSET determined at run time. I saw a patch for it that already made it a few times on the list[1].

I'm not yet done, but first want to announce that I look into that to prevent duplicate work---so if you intended to do the same let's look together---and to post some clean up patches that are the result up to now of my digging in the boot code.

Quoted 8 lines

I will send now three patches in reply to this mail, and later hopefully more.

Best regards
Uwe

[1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/

One of the problems that got brought up previously was the 'make uImage' can end up generating unbootable images with runtime PHYS_OFFSET. The older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so uImage's need to have a fixed load address encoded.

As I stated in the previous thread, this is _not_ a kernel issue, however it is no good having a kernel which contains support for two boards which boot from different address and then generating a uImage which can only boot on one of them without warning the user about this problem. Otherwise you are going to start getting "I did make uImage and my board won't boot" problems.

There are a few solutions to this problem:
1) Drop uImage make support and require users generate them manually.
2) Have a uImage offset config option to allow uImage users to specify what they want the load address to be. See:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
3) Print an error if "make uImage" is run for a kernel which has more than one boot address (possible?)
4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards, however a number of people are still using older U-Boots.

Quoted 4 lines

Quoted 1 line

Or of course, boot zImages. I belive u-boot has support for zImage.

Is there a clean way to pass kernel parameters and machine type from u-boot to zImage? Last time I boot zImage in u-boot, some ugly hack was needed in ARM startup code. Just wondering if there is a better way.

u-boot should be doing the right thing, I thought uImage was simply a zImage wrapped in the right uboot descriptors to tell uboot it was a kernel and where to load it.

Quoted 5 lines

Quoted 1 line

Certianly uboots i've used can boto zImage just fine.

I'm also able to boot zImage under u-boot. However, I had to set r1 manually, and I don't know how to pass kernel parameters (stuff passed into kernel uImage via bootargs) to zImage. Any tips will be greatly appreciated.

Perhaps you use 'go' instead of 'bootm' command in u-boot? How about:-

u-boot # <load zImage@_addr_ by some means>

u-boot # setenv machid <your machine ID in hex without the '0x'> u-boot # saveenv //persistently save the machid

             // now you don't need to set machid even after cold reset

u-boot # bootm _addr_

Quoted 1 line

hth.

The problem is not having something I can boot in U-Boot since users can always generate their own uImages from an image/zImage. The problem is that uImages have a fixed load address, so generating a uImage which contains support for several boards with different load addresses will be non-bootable on some of those boards.

IMHO, the kernel build scripts shouldn't make it easy to build broken images. So, either remove the 'make uImage' support (and let users generate the uImages themselves) or have the build system print a warning stating that the image will only boot on boards with PHYS_OFFSET=0xsomething.

~Ryan

Quoted 70 lines · Ryan Mallon

Quoted 69 lines · jassi brar

Quoted 52 lines · Steve Chen

Quoted 51 lines · Ben Dooks

Quoted 42 lines · Steve Chen

Quoted 41 lines · Ben Dooks

Quoted 40 lines · Ryan Mallon

Quoted 10 lines · Uwe Kleine-K?nig

Hello,

I'm looking into making PHYS_OFFSET determined at run time. I saw a patch for it that already made it a few times on the list[1].

I'm not yet done, but first want to announce that I look into that to prevent duplicate work---so if you intended to do the same let's look together---and to post some clean up patches that are the result up to now of my digging in the boot code.

Quoted 8 lines

I will send now three patches in reply to this mail, and later hopefully more.

Best regards
Uwe

[1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/

One of the problems that got brought up previously was the 'make uImage' can end up generating unbootable images with runtime PHYS_OFFSET. The older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so uImage's need to have a fixed load address encoded.

As I stated in the previous thread, this is _not_ a kernel issue, however it is no good having a kernel which contains support for two boards which boot from different address and then generating a uImage which can only boot on one of them without warning the user about this problem. Otherwise you are going to start getting "I did make uImage and my board won't boot" problems.

There are a few solutions to this problem:
1) Drop uImage make support and require users generate them manually.
2) Have a uImage offset config option to allow uImage users to specify what they want the load address to be. See:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
3) Print an error if "make uImage" is run for a kernel which has more than one boot address (possible?)
4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards, however a number of people are still using older U-Boots.

Quoted 4 lines

Quoted 1 line

Or of course, boot zImages. I belive u-boot has support for zImage.

Is there a clean way to pass kernel parameters and machine type from u-boot to zImage? Last time I boot zImage in u-boot, some ugly hack was needed in ARM startup code. Just wondering if there is a better way.

u-boot should be doing the right thing, I thought uImage was simply a zImage wrapped in the right uboot descriptors to tell uboot it was a kernel and where to load it.

Quoted 5 lines

Quoted 1 line

Certianly uboots i've used can boto zImage just fine.

I'm also able to boot zImage under u-boot. However, I had to set r1 manually, and I don't know how to pass kernel parameters (stuff passed into kernel uImage via bootargs) to zImage. Any tips will be greatly appreciated.

Perhaps you use 'go' instead of 'bootm' command in u-boot? How about:-

u-boot # <load zImage@_addr_ by some means>

u-boot # setenv machid <your machine ID in hex without the '0x'> u-boot # saveenv //persistently save the machid

             // now you don't need to set machid even after cold reset

u-boot # bootm _addr_

Quoted 7 lines

Quoted 1 line

hth.

The problem is not having something I can boot in U-Boot since users can always generate their own uImages from an image/zImage. The problem is that uImages have a fixed load address, so generating a uImage which contains support for several boards with different load addresses will be non-bootable on some of those boards.

I think that much everyone agrees. One of the proposals is to use zImage instead of uImage which eliminates the fixed load address issue. In summary, the advantage is that there are already code out there that supports zImage that boots multiple boards. The disadvantage is that a u-boot version 2.0 or later is required, so many released products won't

be able to take advantage of this feature.

Quoted 5 lines

I'm also able to boot zImage under u-boot. However, I had to set r1 manually, and I don't know how to pass kernel parameters (stuff passed into kernel uImage via bootargs) to zImage. Any tips will be greatly appreciated.

Perhaps you use 'go' instead of 'bootm' command in u-boot? How about:-

u-boot # <load zImage@_addr_ by some means>

u-boot # setenv machid <your machine ID in hex without the '0x'> u-boot # saveenv //persistently save the machid

             // now you don't need to set machid even after cold reset

u-boot # bootm _addr_

hth.

Yes, I did use go instead of bootm. I'll give this a try. I'm using u-boot version 1.3.3. Based on Uwe's comment, there is a good chance that I'll need to upgrade my u-boot. Thank you all for the feedback.

Quoted 14 lines · jassi brar

Quoted 5 lines

I'm also able to boot zImage under u-boot. However, I had to set r1 manually, and I don't know how to pass kernel parameters (stuff passed into kernel uImage via bootargs) to zImage. Any tips will be greatly appreciated.

Perhaps you use 'go' instead of 'bootm' command in u-boot? How about:-

u-boot # <load zImage@_addr_ by some means>

u-boot # setenv machid <your machine ID in hex without the '0x'> u-boot # saveenv //persistently save the machid

             // now you don't need to set machid even after cold reset

Quoted 3 lines

u-boot # bootm _addr_

hth.

Yes, I did use go instead of bootm. I'll give this a try. I'm using u-boot version 1.3.3. Based on Uwe's comment, there is a good chance that I'll need to upgrade my u-boot. Thank you all for the feedback.

Quoted 15 lines · Steve Chen

Quoted 14 lines · jassi brar

Quoted 5 lines

I'm also able to boot zImage under u-boot. ?However, I had to set r1 manually, and I don't know how to pass kernel parameters (stuff passed into kernel uImage via bootargs) to zImage. ?Any tips will be greatly appreciated.

Perhaps you use 'go' instead of 'bootm' command in u-boot? How about:-

?u-boot # <load zImage@_addr_ by some means>

?u-boot # setenv machid <your machine ID in hex without the '0x'> ?u-boot # saveenv //persistently save the machid
? ? ? ? ? ? ?// now you don't need to set machid even after cold reset

Quoted 8 lines

Quoted 3 lines

?u-boot # bootm _addr_

hth.

Yes, I did use go instead of bootm. ?I'll give this a try. ?I'm using u-boot version 1.3.3. ?Based on Uwe's comment, there is a good chance that I'll need to upgrade my u-boot. ?Thank you all for the feedback.

I did a quick test, and I got

U-Boot > bootm 0xc0700000
Wrong Image Format for bootm command
ERROR: can't get kernel image!

It appears that I need a newer u-boot.

Quoted 1 line · Ben Dooks

Or of course, boot zImages. I belive u-boot has support for zImage.

Is there a clean way to pass kernel parameters and machine type from u-boot to zImage? Last time I boot zImage in u-boot, some ugly hack was needed in ARM startup code. Just wondering if there is a better way.

Quoted 10 lines · Uwe Kleine-K?nig

Hello,

I'm looking into making PHYS_OFFSET determined at run time. I saw a patch for it that already made it a few times on the list[1].

I'm not yet done, but first want to announce that I look into that to prevent duplicate work---so if you intended to do the same let's look together---and to post some clean up patches that are the result up to now of my digging in the boot code.

Quoted 8 lines

I will send now three patches in reply to this mail, and later hopefully more.

Best regards
Uwe

[1] e.g. http://thread.gmane.org/gmane.linux.ports.arm.kernel/53793/

One of the problems that got brought up previously was the 'make uImage' can end up generating unbootable images with runtime PHYS_OFFSET. The older format uImage's (pre 1.3.3) encode a load address (zrealaddr), so uImage's need to have a fixed load address encoded.

As I stated in the previous thread, this is _not_ a kernel issue, however it is no good having a kernel which contains support for two boards which boot from different address and then generating a uImage which can only boot on one of them without warning the user about this problem. Otherwise you are going to start getting "I did make uImage and my board won't boot" problems.

There are a few solutions to this problem:
1) Drop uImage make support and require users generate them manually.
2) Have a uImage offset config option to allow uImage users to specify what they want the load address to be. See:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/53151/focus=53230
3) Print an error if "make uImage" is run for a kernel which has more than one boot address (possible?)
4) Use FIT U-Boot images. This is supported from U-Boot 1.3.3 onwards, however a number of people are still using older U-Boots.

just a short status report: The code seems to work OK if PHYS_OFFSET is determined correctly.

The problem is when it does not. Currently I place arch/arm/boot/Image at 0xa1008000[1] with PHYS_OFFSET being 0xa0000000. Then arch/arm/boot/head.S guesses PHYS_OFFSET to be 0xa1000000 resulting __va(bank->start) of my only bank to be 0xbf000000. And so this bank is discarded by sanity_check_meminfo as 0xbf000000 overlaps the vmalloc region.

So how to proceed? These possiblities come to (my) mind:

- parse the atag list to better guess phys_offset
(both zImage and Image would need to do that)
- require that zImage and Image are placed such that the guess is done right (which is stupid for zImage as then the decompressor needs to move the decompressed image)
- require the bootloader to pass phys_offset (r3?)
- make the ram mapping non-linear
- don't discard the whole bank, only the addresses overlaping the vmalloc region

Anything else? Preferences? Thoughts?

Hello,

Quoted 22 lines · Uwe Kleine-K?nig

just a short status report: The code seems to work OK if PHYS_OFFSET is determined correctly.

The problem is when it does not. Currently I place arch/arm/boot/Image at 0xa1008000[1] with PHYS_OFFSET being 0xa0000000. Then arch/arm/boot/head.S guesses PHYS_OFFSET to be 0xa1000000 resulting __va(bank->start) of my only bank to be 0xbf000000. And so this bank is discarded by sanity_check_meminfo as 0xbf000000 overlaps the vmalloc region.

So how to proceed? These possiblities come to (my) mind:

- parse the atag list to better guess phys_offset
(both zImage and Image would need to do that)
- require that zImage and Image are placed such that the guess is done right (which is stupid for zImage as then the decompressor needs to move the decompressed image)
- require the bootloader to pass phys_offset (r3?)
- make the ram mapping non-linear
- don't discard the whole bank, only the addresses overlaping the vmalloc region

Quoted 1 line

Anything else? Preferences? Thoughts?

I'd like to go forward here and if I don't hear anything here I'll start requiring that the bootloader sets r3=PHYS_OFFSET as this seems the most robust solution to me.

Quoted 23 lines · Uwe Kleine-K?nig

Quoted 22 lines · Uwe Kleine-K?nig

just a short status report: The code seems to work OK if PHYS_OFFSET is determined correctly.

The problem is when it does not. Currently I place arch/arm/boot/Image at 0xa1008000[1] with PHYS_OFFSET being 0xa0000000. Then arch/arm/boot/head.S guesses PHYS_OFFSET to be 0xa1000000 resulting __va(bank->start) of my only bank to be 0xbf000000. And so this bank is discarded by sanity_check_meminfo as 0xbf000000 overlaps the vmalloc region.

So how to proceed? These possiblities come to (my) mind:

- parse the atag list to better guess phys_offset
(both zImage and Image would need to do that)
- require that zImage and Image are placed such that the guess is done right (which is stupid for zImage as then the decompressor needs to move the decompressed image)
- require the bootloader to pass phys_offset (r3?)
- make the ram mapping non-linear
- don't discard the whole bank, only the addresses overlaping the vmalloc region

Quoted 4 lines

Quoted 1 line

Anything else? Preferences? Thoughts?

I'd like to go forward here and if I don't hear anything here I'll start requiring that the bootloader sets r3=PHYS_OFFSET as this seems the most robust solution to me.

The following changes since commit 499a2673713c85734a54c37dd90b4b729de399c4:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input

are available in the git repository at:

git://git.pengutronix.de/git/ukl/linux-2.6.git arm/booting

Quoted 7 lines

The following changes since commit 499a2673713c85734a54c37dd90b4b729de399c4:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input

are available in the git repository at:

git://git.pengutronix.de/git/ukl/linux-2.6.git arm/booting

Can you please pull this branch for the .34 merge window? Since the last post one new patch was added to that branch. I'll send it in reply to this mail.

The following changes since commit 499a2673713c85734a54c37dd90b4b729de399c4:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input

are available in the git repository at:

git://git.pengutronix.de/git/ukl/linux-2.6.git arm/booting

Uwe Kleine-K?nig (10):
zImage: fix comments for cache_on, cache_off and cache_clean_flush
zImage: some comments for __armv3_mpu_cache_on
zImage: __armv3_mpu_cache_flush: respect should-be-zero specification
zImage: annotate debug functions about corrupted registers
zImage: don't define unused symbol initrd_phys
arm: deprecate support for old way to pass kernel parameters
zImage: don't hard code the stack size twice
uImage: require passing a LOADADDR when building with RUNTIME_PHYSOFFSET Allow PHYS_OFFSET to be runtime determined
arm: remove bit-rotten STANDALONE_DEBUG for decompressor

 Documentation/arm/Booting               |    1 +
 arch/arm/Kconfig                        |    9 ++++
 arch/arm/boot/Makefile                  |    6 ++-
 arch/arm/boot/compressed/Makefile       |   10 ++---
 arch/arm/boot/compressed/Makefile.debug |   23 ---------
 arch/arm/boot/compressed/head.S         |   76 +++++++++++++++++++++++++++---
 arch/arm/boot/compressed/misc.c         |   27 -----------
 arch/arm/include/asm/memory.h           |    5 ++
 arch/arm/kernel/Makefile                |    4 +-
 arch/arm/kernel/compat.c                |    7 ---
 arch/arm/kernel/compat.h                |    2 -
 arch/arm/kernel/head.S                  |   31 +++++++++---
 arch/arm/kernel/setup.c                 |   21 ++++++++-
 13 files changed, 138 insertions(+), 84 deletions(-)
 delete mode 100644 arch/arm/boot/compressed/Makefile.debug

Hello Russell,

Quoted 8 lines · Uwe Kleine-K?nig

Quoted 7 lines

The following changes since commit 499a2673713c85734a54c37dd90b4b729de399c4:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input

are available in the git repository at:

git://git.pengutronix.de/git/ukl/linux-2.6.git arm/booting

Quoted 3 lines

Can you please pull this branch for the .34 merge window? Since the last post one new patch was added to that branch. I'll send it in reply to this mail.

Do you consider pulling? If not, can you please say why?

Best regards
Uwe

Quoted 35 lines

The following changes since commit 499a2673713c85734a54c37dd90b4b729de399c4:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input

are available in the git repository at:

git://git.pengutronix.de/git/ukl/linux-2.6.git arm/booting

Uwe Kleine-K?nig (10):
zImage: fix comments for cache_on, cache_off and cache_clean_flush
zImage: some comments for __armv3_mpu_cache_on
zImage: __armv3_mpu_cache_flush: respect should-be-zero specification
zImage: annotate debug functions about corrupted registers
zImage: don't define unused symbol initrd_phys
arm: deprecate support for old way to pass kernel parameters
zImage: don't hard code the stack size twice
uImage: require passing a LOADADDR when building with RUNTIME_PHYSOFFSET Allow PHYS_OFFSET to be runtime determined
arm: remove bit-rotten STANDALONE_DEBUG for decompressor

 Documentation/arm/Booting               |    1 +
 arch/arm/Kconfig                        |    9 ++++
 arch/arm/boot/Makefile                  |    6 ++-
 arch/arm/boot/compressed/Makefile       |   10 ++---
 arch/arm/boot/compressed/Makefile.debug |   23 ---------
 arch/arm/boot/compressed/head.S         |   76 +++++++++++++++++++++++++++---
 arch/arm/boot/compressed/misc.c         |   27 -----------
 arch/arm/include/asm/memory.h           |    5 ++
 arch/arm/kernel/Makefile                |    4 +-
 arch/arm/kernel/compat.c                |    7 ---
 arch/arm/kernel/compat.h                |    2 -
 arch/arm/kernel/head.S                  |   31 +++++++++---
 arch/arm/kernel/setup.c                 |   21 ++++++++-
 13 files changed, 138 insertions(+), 84 deletions(-)
 delete mode 100644 arch/arm/boot/compressed/Makefile.debug

Signature · 7 lines

Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 14 lines · Uwe Kleine-K?nig

Hello Russell,

Quoted 11 lines · Uwe Kleine-K?nig

Quoted 7 lines

The following changes since commit 499a2673713c85734a54c37dd90b4b729de399c4:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../dtor/input

are available in the git repository at:

git://git.pengutronix.de/git/ukl/linux-2.6.git arm/booting

Can you please pull this branch for the .34 merge window? Since the last post one new patch was added to that branch. I'll send it in reply to this mail.

Quoted 4 lines

Do you consider pulling? If not, can you please say why?

Best regards
Uwe

Bumping up this thread since these patches are necessary to reach our eventual goal of a common kernel.