HowTo XIP on arm?

[Konstantin Kletschke]

Hi people!

At the moment I am trying to get some visible output from my serial
console from an XIP booted kernel.

I wonder what the exact requirements for that are.

I use 2.6.10-rc2 kernel tree and have a motorola i-MX ARM9 processor on
my desk so I use the i.MX architecture of the kernel. The i.MX
architecture is implemented in these recent kernels for the motorola
eval board mx1ads and I adapted it to my (mostly similair) scb9328
board.

When I use XIP do I have to tace care of that in my board setup and .c
.h files and Makefiles? Or is the arm XIP implementation generic for all
arm architectures? I think so but please advise me if not.

I wonder how in general a xipImage is started, I put it in flash at
specified adress and if I understood correct, the bootloader does not
start a kernel image, instead a "go 0xXXXXxxxx" should be sufficient.
I have bootloader from 0x10000000 to 0x10020000 and put the xipImage to
0x10040000. But this gives "## Starting application at 0x10048000 ..."
only, hence my stupid questions.

May be I did not understand yet, what correct boundary adresses for a
xipImage are.

Has xipaddr-y ?= 0xbf000000 to be adjusted to something architecture
specific?

Well, I will be very happy to get some tips on how to implement that
thing...

Kind regards, Konsti

[Nicolas Pitre]

Post by Konstantin Kletschke
Hi people!
At the moment I am trying to get some visible output from my serial
console from an XIP booted kernel.

First, does your kernel work when CONFIG_XIP_KERNEL is turned off and
zImage booted from ram, while still keeping all the other config
settings?

Post by Konstantin Kletschke
When I use XIP do I have to tace care of that in my board setup and .c
.h files and Makefiles? Or is the arm XIP implementation generic for all
arm architectures? I think so but please advise me if not.

It is generic.

Post by Konstantin Kletschke
I wonder how in general a xipImage is started, I put it in flash at
specified adress and if I understood correct, the bootloader does not
start a kernel image, instead a "go 0xXXXXxxxx" should be sufficient.

You still have the same requirements as with a standard kernel image for
the values in r0, r1 and r2 upon jumping to the XIP kernel image (see
linux/Documentation/arm/Booting for details).

Post by Konstantin Kletschke
I have bootloader from 0x10000000 to 0x10020000 and put the xipImage to
0x10040000. But this gives "## Starting application at 0x10048000 ..."
only, hence my stupid questions.

This message isn't from the kernel itself so it's probably your
bootloader who thinks it knows better than you. 0x10040000 is a
perfectly fine physical address for your XIP kernel image, given it
doesn't conflict with other things in flash.

Post by Konstantin Kletschke
May be I did not understand yet, what correct boundary adresses for a
xipImage are.

A 4 byte boundary for proper alignment is sufficient.

Post by Konstantin Kletschke
Has xipaddr-y ?= 0xbf000000 to be adjusted to something architecture
specific?

Only if you intend to change the default 3GB user vs 1GB kernel
address split.

Post by Konstantin Kletschke
Well, I will be very happy to get some tips on how to implement that
thing...

Make sure you have CONFIG_DEBUG_LL=y and that your bootloader is doing
the right thing.


Nicolas

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Konstantin Kletschke]

Post by Nicolas Pitre
First, does your kernel work when CONFIG_XIP_KERNEL is turned off and
zImage booted from ram, while still keeping all the other config
settings?

Yes :) I do make uImage though, does that matter?

Post by Nicolas Pitre
You still have the same requirements as with a standard kernel image for
the values in r0, r1 and r2 upon jumping to the XIP kernel image (see
linux/Documentation/arm/Booting for details).

Well, if the uImage runs and all other settings are similair this should
be fullfilled...

Post by Nicolas Pitre

Post by Konstantin Kletschke
0x10040000. But this gives "## Starting application at 0x10048000 ..."
only, hence my stupid questions.

This message isn't from the kernel itself so it's probably your
bootloader who thinks it knows better than you.

Yes, thats clear :) I only wanted to point out that the booted kernel
itself does print out nothing :(

Post by Nicolas Pitre
0x10040000 is a
perfectly fine physical address for your XIP kernel image, given it
doesn't conflict with other things in flash.

But what are othe conflicting things in flash?
The bootloader from 0x10000000 to 0x1001FFFF?
The bootloader environment from 0x1002000 to 0x1003FFFF?
The (currently not mounted or used or everything else) rootfs from
0x10140000 to 0x101FFFFF?

Post by Nicolas Pitre

Post by Konstantin Kletschke
May be I did not understand yet, what correct boundary adresses for a
xipImage are.

A 4 byte boundary for proper alignment is sufficient.

OK.

Post by Nicolas Pitre

Post by Konstantin Kletschke
Has xipaddr-y ?= 0xbf000000 to be adjusted to something architecture
specific?

Only if you intend to change the default 3GB user vs 1GB kernel
address split.

OK, I don't want do that :)

Post by Nicolas Pitre

Post by Konstantin Kletschke
Well, I will be very happy to get some tips on how to implement that
thing...

Make sure you have CONFIG_DEBUG_LL=y and that your bootloader is doing
the right thing.

I do have to find this CONFIG_DEBUG_LL=y, ok.
But what has the bootloader to do? Is he actually booting something like
an uImage? Or do I have to make my bootloader to boot an zImage and the
xipImage is the same to the bootloader then?
Or appears the xipImage to the bootloader as an application, since the
kernel executes itself and is not compressed?

Many questions, I am sorry, but I am really curious to get this run,
and these questions reflect exact that, what I have not understoodd yet.

Regards, Konsti

[Nicolas Pitre]

Post by Konstantin Kletschke

Post by Nicolas Pitre
You still have the same requirements as with a standard kernel image for
the values in r0, r1 and r2 upon jumping to the XIP kernel image (see
linux/Documentation/arm/Booting for details).

Well, if the uImage runs and all other settings are similair this should
be fullfilled...

Are you absolutely positively sure?

If you try to instruct your bootloader to simply branch to some location
in flash, I doubt it'll currently take the path of adding proper values
in r0, r1 and r2 since it certainly didn't expect to boot Linux that way
before.

Please tripple check the code for your bootloader.


Nicolas

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Russell King - ARM Linux]

Post by Nicolas Pitre

Post by Konstantin Kletschke

Post by Nicolas Pitre
You still have the same requirements as with a standard kernel image for
the values in r0, r1 and r2 upon jumping to the XIP kernel image (see
linux/Documentation/arm/Booting for details).

Well, if the uImage runs and all other settings are similair this should
be fullfilled...

Are you absolutely positively sure?
If you try to instruct your bootloader to simply branch to some location
in flash, I doubt it'll currently take the path of adding proper values
in r0, r1 and r2 since it certainly didn't expect to boot Linux that way
before.
Please tripple check the code for your bootloader.

Aren't uImage's compressed and checksummed things with a header on the
front? If so, it would be rather incompatible with XIP.

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Robert Schwebel]

Post by Russell King - ARM Linux
Aren't uImage's compressed and checksummed things with a header on the
front? If so, it would be rather incompatible with XIP.

Not necessarily compressed but always with a header.

Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hornemannstraße 12, 31137 Hildesheim, Germany
Phone: [phone] | Fax: [phone]

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Wolfgang Denk]

Post by Russell King - ARM Linux
Aren't uImage's compressed and checksummed things with a header on the
front? If so, it would be rather incompatible with XIP.

Not necessarily compressed, and if built with the correct options
(-x) then even XIP compatible:

bash$ mkimage -?
Usage: mkimage -l image
-l ==> list image header information
mkimage -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image
-A ==> set architecture to 'arch'
-O ==> set operating system to 'os'
-T ==> set image type to 'type'
-C ==> set compression type 'comp'
-a ==> set load address to 'addr' (hex)
-e ==> set entry point to 'ep' (hex)
-n ==> set image name to 'name'
-d ==> use image data from 'datafile'
===>> -x ==> set XIP (execute in place)


Best regards,

Wolfgang Denk

[Nicolas Pitre]

Post by Wolfgang Denk

Post by Russell King - ARM Linux
Aren't uImage's compressed and checksummed things with a header on the
front? If so, it would be rather incompatible with XIP.

Not necessarily compressed, and if built with the correct options
bash$ mkimage -?
Usage: mkimage -l image
-l ==> list image header information
mkimage -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image
-A ==> set architecture to 'arch'
-O ==> set operating system to 'os'
-T ==> set image type to 'type'
-C ==> set compression type 'comp'
-a ==> set load address to 'addr' (hex)
-e ==> set entry point to 'ep' (hex)
-n ==> set image name to 'name'
-d ==> use image data from 'datafile'
===>> -x ==> set XIP (execute in place)

And how do you ensure that the very start of the original kernel image
will be located at the precise physical flash address it was configured
for?


Nicolas

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Wolfgang Denk]

Post by Nicolas Pitre

Post by Wolfgang Denk
Not necessarily compressed, and if built with the correct options

...

Post by Nicolas Pitre
And how do you ensure that the very start of the original kernel image
will be located at the precise physical flash address it was configured
for?

We don't ensure it. The user is responsible to copy the resulting
uImage file to CONFIG_XIP_PHYS_ADDR in flash memory and boot it from
CONFIG_XIP_PHYS_ADDR as usual.

Best regards,

Wolfgang Denk

[Nicolas Pitre]

Post by Wolfgang Denk

Post by Nicolas Pitre

Post by Wolfgang Denk
Not necessarily compressed, and if built with the correct options

...

Post by Nicolas Pitre
And how do you ensure that the very start of the original kernel image
will be located at the precise physical flash address it was configured
for?

We don't ensure it. The user is responsible to copy the resulting
uImage file to CONFIG_XIP_PHYS_ADDR in flash memory and boot it from
CONFIG_XIP_PHYS_ADDR as usual.

Then, can you tell me what's the purpose of mkimage? Isn't its added
header taking up some space before the kernel binary which would
effectively store the kernel with a certain offset from the targetted
flash location?


Nicolas

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Robert Schwebel]

Post by Konstantin Kletschke
Yes :) I do make uImage though, does that matter?

Without having experience with XIP I would suspect that you have to
'make image'. An uImage is the image plus a header which tells u-boot
where to extract the image to and where the entry point is. Try an Image
and jump directly into it's base address in flash.

Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hornemannstraße 12, 31137 Hildesheim, Germany
Phone: [phone] | Fax: [phone]

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Nicolas Pitre]

Post by Robert Schwebel

Post by Konstantin Kletschke
Yes :) I do make uImage though, does that matter?

Without having experience with XIP I would suspect that you have to
'make image'. An uImage is the image plus a header which tells u-boot
where to extract the image to and where the entry point is. Try an Image
and jump directly into it's base address in flash.

Here's a hint:

|Kernel Execute-In-Place from ROM (XIP_KERNEL) [N/y/?] (NEW) ?
|
|Execute-In-Place allows the kernel to run from non-volatile storage
|directly addressable by the CPU, such as NOR flash. This saves RAM
|space since the text section of the kernel is not loaded from flash
|to RAM. Read-write sections, such as the data section and stack,
|are still copied to RAM. The XIP kernel is not compressed since
|it has to run directly from flash, so it will take more space to
|store it. The flash address used to link the kernel object files,
|and for storing it, is configuration dependent. Therefore, if you
|say Y here, you must know the proper physical address where to
|store the kernel image depending on your own flash memory usage.
|
|Also note that the make target becomes "make xipImage" rather than
|"make zImage" or "make Image". The final kernel binary to put in
|ROM memory will be arch/arm/boot/xipImage.


[...]

|$ make Image
| CHK include/linux/version.h
|make[1]: `arch/arm/kernel/asm-offsets.s' is up to date.
| CHK include/asm-arm/constants.h
|make[1]: `include/asm-arm/mach-types.h' is up to date.
| CHK include/linux/compile.h
| CHK usr/initramfs_list
|Kernel configured for XIP (CONFIG_XIP_KERNEL=y)
|Only the xipImage target is available in this case
|make[1]: *** [arch/arm/boot/Image] Error 1
|make: *** [Image] Error 2


Nicolas

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Konstantin Kletschke]

Hmm...

Post by Wolfgang Denk
We don't ensure it. The user is responsible to copy the resulting
uImage file to CONFIG_XIP_PHYS_ADDR in flash memory and boot it from
CONFIG_XIP_PHYS_ADDR as usual.

So, but... I don't get it.
When the Kernel supposes its first instruction is on 0x1004000, why can
the mkimage -x u-boot image be flashed to the same address?

I have

CONFIG_XIP_PHYS_ADDR=0x10040000

and

scb9328> boot
## Booting image at 10040000 ...
Image Name: /tftpboot/uxipImage
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1460956 Bytes = 1.4 MB
Load Address: 10040000
Entry Point: 10040000
Verifying Checksum ... OK
XIP Kernel Image ... OK

Starting kernel ...

undefined instruction
pc : [<10040010>] lr : [<08f10dd4>]
sp : 08ebfa24 ip : 00000001 fp : 08ebfab8
r10: 08ebffb8 r9 : 08ef4a37 r8 : 08ebffdc
r7 : 08f18698 r6 : 00000000 r5 : 00000000 r4 : 00000000
r3 : 10040000 r2 : 08000100 r1 : 000001fc r0 : 56190527
Flags: nZCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...

So is it generally correct to do CONFIG_XIP_PHYS_ADDR=0x10040000,
mkimage -A arm -O linux -T kernel -C none -a 0x10040000 -e 010040000 -d
/tftpboot/xipImage /tftpboot/uxipImage
and flash the resulting uxipImage?

Regards, stupid, puzzled Konsti :)

[Russell King - ARM Linux]

Post by Konstantin Kletschke

Post by Wolfgang Denk
We don't ensure it. The user is responsible to copy the resulting
uImage file to CONFIG_XIP_PHYS_ADDR in flash memory and boot it from
CONFIG_XIP_PHYS_ADDR as usual.

So, but... I don't get it.
When the Kernel supposes its first instruction is on 0x1004000, why can
the mkimage -x u-boot image be flashed to the same address?

Take a moment think about it.

* You've built the kernel to run from flash at address 0x10004000.
* You then add the uboot header on the front of it.
* You program the resulting image at 0x10004000.

What is programmed at 0x10004000 ? The xipImage code or the uboot header?

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Konstantin Kletschke]

Post by Russell King - ARM Linux
* You've built the kernel to run from flash at address 0x10004000.

Yes

Post by Russell King - ARM Linux
* You then add the uboot header on the front of it.

Yes. But... _Does_ mkimage -x put header on the front of it?

Post by Russell King - ARM Linux
* You program the resulting image at 0x10004000.
What is programmed at 0x10004000 ? The xipImage code or the uboot header?

The u-boot headers, yes. Thats wrong. But how to use mkimage -x then?
Is the header-caused offset known?

Or, more general, How do I boot a xipImage, when I don't use u-boot for
example?

K

[Nicolas Pitre]

Post by Konstantin Kletschke

Post by Russell King - ARM Linux
* You've built the kernel to run from flash at address 0x10004000.

Yes

Post by Russell King - ARM Linux
* You then add the uboot header on the front of it.

Yes. But... _Does_ mkimage -x put header on the front of it?

Post by Russell King - ARM Linux
* You program the resulting image at 0x10004000.
What is programmed at 0x10004000 ? The xipImage code or the uboot header?

The u-boot headers, yes. Thats wrong. But how to use mkimage -x then?
Is the header-caused offset known?

You probably should ask on the uboot mailing list for that.

Post by Konstantin Kletschke
Or, more general, How do I boot a xipImage, when I don't use u-boot for
example?

You hack your bootloader source code so it puts proper values in r0, r1
and r2 then, with MMU off, branch directly to the physical address in
flash where the xipImage
was stored.

Don't just trust that the bootloader will magically do it all right,
especially not if using special tools mangling the original xipImage
binary like mkimage does.


Nicolas

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Wolfgang Denk]

Post by Konstantin Kletschke

Post by Russell King - ARM Linux
* You then add the uboot header on the front of it.

Yes. But... _Does_ mkimage -x put header on the front of it?

Yes, it does.

Post by Konstantin Kletschke

Post by Russell King - ARM Linux
* You program the resulting image at 0x10004000.
What is programmed at 0x10004000 ? The xipImage code or the uboot header?

The u-boot headers, yes. Thats wrong. But how to use mkimage -x then?
Is the header-caused offset known?

Yes. The U-Boot header is 64 bytes.

U-Boot expects (and verifies) that the entry point is equal to the
load address plus the size of the U-Boot header.


Best regards,

Wolfgang Denk

[Todd Poynor]

Post by Wolfgang Denk
U-Boot expects (and verifies) that the entry point is equal to the
load address plus the size of the U-Boot header.

If I've followed this correctly then U-Boot currently does not boot a
ARM XIP Linux kernel built using Nicolas' code in kernel.org. If so,
I've heard that U-Boot patches are floating about to setup the ARM Linux
calling sequence for arbitrary images without a U-Boot header and perhaps
that's a good way to handle it.

Another option is to add a kernel make target that creates a uImage with
the needed entry-load==64. Doing the math automatically would be nice
but I haven't so far found a pretty way of producing the needed result
(and doubt the portability of each method I've tried). One try appears
below, comments appreciated. If we assume the U-Boot header will always
be on a page boundary and the entry point will be +0x40 from that then
even a simple text substitution via sed will get the job done...

Thanks -- Todd

diff -ruN linux-2.6.10-rc2-orig/arch/arm/boot/Makefile linux-2.6.10-rc2-xip/arch/arm/boot/Makefile
--- linux-2.6.10-rc2-orig/arch/arm/boot/Makefile 2004-11-17 14:02:00.000000000 -0800
+++ linux-2.6.10-rc2-xip/arch/arm/boot/Makefile 2004-11-30 13:36:05.666740952 -0800
@@ -24,7 +24,7 @@

export ZRELADDR INITRD_PHYS PARAMS_PHYS

-targets := Image zImage xipImage bootpImage uImage
+targets := Image zImage xipImage bootpImage uImage xipuImage

ifeq ($(CONFIG_XIP_KERNEL),y)

@@ -32,9 +32,21 @@
$(call if_changed,objcopy)
@echo ' Kernel: $@ is ready (physical address: $(CONFIG_XIP_PHYS_ADDR))'

+quiet_cmd_xipmkimage = XIPUIMAGE $@
+ cmd_xipmkimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \
+ -C none -a $(XIPUIMAGE_LOAD_ADDR) \
+ -e $(CONFIG_XIP_PHYS_ADDR) -n 'Linux-$(KERNELRELEASE)' \
+ -d $< $@
+
+XIPUIMAGE_LOAD_ADDR = "$(shell let x=$(CONFIG_XIP_PHYS_ADDR)-64; echo "obase=16;$$x" | bc)"
+
+$(obj)/xipuImage: $(obj)/xipImage FORCE
+ $(call if_changed,xipmkimage)
+ @echo ' Image $@ is ready'
+
$(obj)/Image $(obj)/zImage: FORCE
@echo 'Kernel configured for XIP (CONFIG_XIP_KERNEL=y)'
- @echo 'Only the xipImage target is available in this case'
+ @echo 'Only XIP image targets are available in this case'
@false

else
diff -ruN linux-2.6.10-rc2-orig/arch/arm/Makefile linux-2.6.10-rc2-xip/arch/arm/Makefile
--- linux-2.6.10-rc2-orig/arch/arm/Makefile 2004-11-17 14:02:00.000000000 -0800
+++ linux-2.6.10-rc2-xip/arch/arm/Makefile 2004-11-30 11:33:41.768183232 -0800
@@ -181,7 +181,7 @@
# Convert bzImage to zImage
bzImage: zImage

-zImage Image xipImage bootpImage uImage: vmlinux
+zImage Image xipImage bootpImage uImage xipuImage: vmlinux
$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@

zinstall install: vmlinux
@@ -208,6 +208,7 @@
echo '* zImage - Compressed kernel image (arch/$(ARCH)/boot/zImage)'
echo ' Image - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
echo '* xipImage - XIP kernel image, if configured (arch/$(ARCH)/boot/xipImage)'
+ echo ' xipuImage - XIP kernel image for U-Boot, if configured (arch/$(ARCH)/boot/xipuImage)'
echo ' bootpImage - Combined zImage and initial RAM disk'
echo ' (supply initrd image via make variable INITRD=<path>)'
echo ' install - Install uncompressed kernel'


-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Nicolas Pitre]

Post by Todd Poynor

Post by Wolfgang Denk
U-Boot expects (and verifies) that the entry point is equal to the
load address plus the size of the U-Boot header.

If I've followed this correctly then U-Boot currently does not boot a
ARM XIP Linux kernel built using Nicolas' code in kernel.org. If so,
I've heard that U-Boot patches are floating about to setup the ARM Linux
calling sequence for arbitrary images without a U-Boot header and perhaps
that's a good way to handle it.

That would be nice indeed.

Post by Todd Poynor
Another option is to add a kernel make target that creates a uImage with
the needed entry-load==64. Doing the math automatically would be nice
but I haven't so far found a pretty way of producing the needed result
(and doubt the portability of each method I've tried). One try appears
below, comments appreciated.

You have:

XIPUIMAGE_LOAD_ADDR = "$(shell let x=$(CONFIG_XIP_PHYS_ADDR)-64; echo "obase=16;$$x" | bc)"

Instead of relying on bc, you probably should use awk since the generic
XIP address processing already uses it so it makes for one less
dependency on external tools:

XIPUIMAGE_LOAD_ADDR := $(shell echo $(CONFIG_XIP_PHYS_ADDR) | \
awk --non-decimal-data '/[:xdigit:]/ \
{ printf("0x%x\n", $$1 - 0x40) }' )

Post by Todd Poynor
If we assume the U-Boot header will always
be on a page boundary and the entry point will be +0x40 from that then
even a simple text substitution via sed will get the job done...

You cannot assume that everybody will set the kernel XIP address right
though (and there _will_ be people to set it wrong). So if you want to
add such a restriction you need to also add a test in your xipuImage
target to error out if CONFIG_XIP_PHYS_ADDR doesn't include the
necessary offset.


Nicolas

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Wolfgang Denk]

Post by Nicolas Pitre

Post by Todd Poynor
If I've followed this correctly then U-Boot currently does not boot a
ARM XIP Linux kernel built using Nicolas' code in kernel.org. If so,
I've heard that U-Boot patches are floating about to setup the ARM Linux
calling sequence for arbitrary images without a U-Boot header and perhaps
that's a good way to handle it.

That would be nice indeed.

It would be even better if it was possible to use standard U-Boot
images for XIP, too.

Post by Nicolas Pitre

Post by Todd Poynor
If we assume the U-Boot header will always
be on a page boundary and the entry point will be +0x40 from that then
even a simple text substitution via sed will get the job done...

You cannot assume that everybody will set the kernel XIP address right
though (and there _will_ be people to set it wrong). So if you want to
add such a restriction you need to also add a test in your xipuImage
target to error out if CONFIG_XIP_PHYS_ADDR doesn't include the
necessary offset.

If there should be such a requirement for succesfully booting XIP
images for ARM under U-Boot, I'll be happy to add such a test in
U-Boot (or, even better, accept patches to implement this).

Best regards,

Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: [phone] Fax: [phone] Email: ***@denx.de
The first thing we do is kill all the lawyers.
(Shakespeare. II Henry VI, Act IV, scene ii)

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Wolfgang Denk]

Post by Todd Poynor

Post by Wolfgang Denk
U-Boot expects (and verifies) that the entry point is equal to the
load address plus the size of the U-Boot header.

If I've followed this correctly then U-Boot currently does not boot a
ARM XIP Linux kernel built using Nicolas' code in kernel.org. If so,
I've heard that U-Boot patches are floating about to setup the ARM Linux
calling sequence for arbitrary images without a U-Boot header and perhaps
that's a good way to handle it.

I'm not sure if patches are needed to do this. You can use the "go"
command which just jumps to the given address; of course this will
not pass arguments to the kernel.

Also, the U-Boot header can be pretty useful. IMHO it would be a good
idea if we could continue to use it even with XIP on ARM.

Post by Todd Poynor
Another option is to add a kernel make target that creates a uImage with
the needed entry-load==64. Doing the math automatically would be nice
but I haven't so far found a pretty way of producing the needed result
(and doubt the portability of each method I've tried). One try appears
below, comments appreciated. If we assume the U-Boot header will always
be on a page boundary and the entry point will be +0x40 from that then
even a simple text substitution via sed will get the job done...

I think the assumption is valid, at least it is pretty natural to put
the images at the beginning of flash sectors, and usually this
automatically makes them page aligned.

Best regards,

Wolfgang Denk

[Todd Poynor]

Post by Wolfgang Denk

Post by Todd Poynor
If I've followed this correctly then U-Boot currently does not boot a
ARM XIP Linux kernel built using Nicolas' code in kernel.org. If so,
I've heard that U-Boot patches are floating about to setup the ARM Linux
calling sequence for arbitrary images without a U-Boot header and perhaps
that's a good way to handle it.

I'm not sure if patches are needed to do this. You can use the "go"
command which just jumps to the given address; of course this will
not pass arguments to the kernel.

When I tried this the r0 = 0, r1 = machine-id values weren't passed,
leading to an early-stage halt, but I am using a U-Boot from a couple of
revs back. A quick look at the 1.1.1 sources seems to show a
non-ARM-linux calling sequence for "go", but if there's a way to do it
that would be welcome news.

Post by Wolfgang Denk
I think the assumption is valid, at least it is pretty natural to put
the images at the beginning of flash sectors, and usually this
automatically makes them page aligned.

This is partly why I wanted to inquire about support for header-less
XIP: configuring the kernel for an XIP physical address equal to the
flash bank start address + 0x40 is a little awkward. Perhaps it's
possible to go the other direction and add the 0x40 to the entry address
at load time if an xipuImage target is being made, but that sounds a
little ugly as well.

Either way, here's an updated patch for XIP'able uImages with Nicolas'
suggestion of awk for the conversion back to hex, comments appreciated,
thanks -- Todd

diff -ruN linux-2.6.10-rc2-orig/arch/arm/boot/Makefile linux-2.6.10-rc2-xip/arch/arm/boot/Makefile
--- linux-2.6.10-rc2-orig/arch/arm/boot/Makefile 2004-11-17 14:02:00.000000000 -0800
+++ linux-2.6.10-rc2-xip/arch/arm/boot/Makefile 2004-12-01 12:15:44.939307168 -0800
@@ -24,7 +24,7 @@

export ZRELADDR INITRD_PHYS PARAMS_PHYS

-targets := Image zImage xipImage bootpImage uImage
+targets := Image zImage xipImage bootpImage uImage xipuImage

ifeq ($(CONFIG_XIP_KERNEL),y)

@@ -32,9 +32,23 @@
$(call if_changed,objcopy)
@echo ' Kernel: $@ is ready (physical address: $(CONFIG_XIP_PHYS_ADDR))'

+quiet_cmd_xipmkimage = XIPUIMAGE $@
+ cmd_xipmkimage = $(CONFIG_SHELL) $(MKIMAGE) -A arm -O linux -T kernel \
+ -C none -a $(XIPUIMAGE_LOAD_ADDR) \
+ -e $(CONFIG_XIP_PHYS_ADDR) -n 'Linux-$(KERNELRELEASE)' \
+ -d $< $@
+
+XIPUIMAGE_LOAD_ADDR := $(shell echo $(CONFIG_XIP_PHYS_ADDR) | \
+ awk --non-decimal-data '/[:xdigit:]/ \
+ { printf("0x%x\n", $$1 - 0x40) }' )
+
+$(obj)/xipuImage: $(obj)/xipImage FORCE
+ $(call if_changed,xipmkimage)
+ @echo ' Image $@ is ready'
+
$(obj)/Image $(obj)/zImage: FORCE
@echo 'Kernel configured for XIP (CONFIG_XIP_KERNEL=y)'
- @echo 'Only the xipImage target is available in this case'
+ @echo 'Only XIP image targets are available in this case'
@false

else
diff -ruN linux-2.6.10-rc2-orig/arch/arm/Makefile linux-2.6.10-rc2-xip/arch/arm/Makefile
--- linux-2.6.10-rc2-orig/arch/arm/Makefile 2004-11-17 14:02:00.000000000 -0800
+++ linux-2.6.10-rc2-xip/arch/arm/Makefile 2004-11-30 11:33:41.000000000 -0800
@@ -181,7 +181,7 @@
# Convert bzImage to zImage
bzImage: zImage

-zImage Image xipImage bootpImage uImage: vmlinux
+zImage Image xipImage bootpImage uImage xipuImage: vmlinux
$(Q)$(MAKE) $(build)=$(boot) MACHINE=$(MACHINE) $(boot)/$@

zinstall install: vmlinux
@@ -208,6 +208,7 @@
echo '* zImage - Compressed kernel image (arch/$(ARCH)/boot/zImage)'
echo ' Image - Uncompressed kernel image (arch/$(ARCH)/boot/Image)'
echo '* xipImage - XIP kernel image, if configured (arch/$(ARCH)/boot/xipImage)'
+ echo ' xipuImage - XIP kernel image for U-Boot, if configured (arch/$(ARCH)/boot/xipuImage)'
echo ' bootpImage - Combined zImage and initial RAM disk'
echo ' (supply initrd image via make variable INITRD=<path>)'
echo ' install - Install uncompressed kernel'


-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

[Konstantin Kletschke]

Post by Konstantin Kletschke
mkimage -A arm -O linux -T kernel -C none -a 0x10040000 -e 010040000 -d
/tftpboot/xipImage /tftpboot/uxipImage

As said, stupid me.

mkimage -A arm -O linux -T kernel -C none -a 0x10040000 -e 010040000 -d
vmlinux /tftpboot/uxipImage

Looks better to me, but:

scb9328> boot
## Booting image at 10040000 ...
Image Name:
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1931242 Bytes = 1.8 MB
Load Address: 10040000
Entry Point: 10040000
Verifying Checksum ... OK
XIP Kernel Image ... OK

Starting kernel ...

Well, after lunch I try to look whats going on with the debugger...

Konsti