XIP kernel questions

Has anyone ever tried to compile & setup and XIP kernel that loads straight from flash?
Im currently trying to build an XIP kernel using the 3.1 uclinux kernel + BSP.
However, Im running into the following errors during the linkage:

Code: [Select]

arm-linux-ld.real: section .notes [00023c80 -> 00023ca3] overlaps section .text [00020080 -> 001a9747]
arm-linux-ld.real: vmlinux: section .notes lma 0x23c80 overlaps previous sections
arm-linux-ld.real: vmlinux: section .bss lma 0x23cc0 overlaps previous sections
haven't managed to find anything useful on google so far, so I was wondering if perhaps someone here on the forum might have some advice...

Did you make sure to disable compression on the kernel?  Obviously you can't XIP a compressed kernel, as all you will be executing in place is the tiny decompression routine, expanding the kernel into RAM.

You will also probably have to manually specify the start address somewhere in the kernel config.

As a suggestion for testing (to avoid flashing a possibly broken kernel) you could try setting the start address to be the standard (0x8000) and then use the bootloader "mt" command to download the kernel image to RAM, then try booting it from there.  If that works, then changing the start address and flashing it to ROM should work too.  Note however if you try this, you might have to tell the bootloader to store its data out the of way, as it stores it at about 2MB by default, so it will get overwritten and crash if the kernel is larger than 2MB.  If you tell the bootloader to move its data to 8MB, then you will be able to load a kernel just under 8MB in size.

Of course this could all be a moot point.  The cameras only have 4MB of flash, and an uncompressed kernel comes in at about 6MB.  So you would have to cut out a lot of features to get the kernel to fit in flash, and then you might not have enough space left over for any actual programs...

I think you'd get more benefit by leaving the kernel as is, and using the extra flash space for a filesystem like cramfs or jffs2 that can run directly from flash and be compressed at the same time.

The only other option would be to mount the root filesystem over the network from another PC, but then you might as well configure it to boot the kernel over the network too, and not bother using the flash at all!

good points. thanks for the feedback.
here are some questions/comments...

I might be wrong about this, but I *believe* that the built-in 'make xipImage' build/config option automatically takes care of creating an uncompressed kernel image. is this true, or am I off? Besides, I couldnt find a way to disable the kernel compression through 'make menuconfig', it only allows me to select gzip lma or lzo...

6MB for the kernel size, are you 100% sure about this? is there anyway around this? couldnt it be cut down to under 2-3 MB? I've seen some random stuff while googling around for info on XIP regarding kernel images being down below the 2MB mark. would this be feasible? or would it mean having a severely limited & crippled kernel?

The base address option: this one has been a source of confusion for me. I assumed that this should be the actual physical offset in flash of the kernel image, which in my case would be 0x7F020000. I tried setting this option in the config, and the build succeeded, however the xipImage file ended up being around 2GB in size! Plus, doing a hexdump of that file shows that most of the file is full of empty/null values. So Im assuming that build process takes that large start offset value and, for some reason, tries to zero-fill the output image file until reaching the offset?

anyway, trying to use a value of 0x20000 (the actual offset from the base flash address of 0x7F000000) produces the build error, so Im not sure what's going wrong, or what value its expecting for the start address.

I'll try again and see how it goes...

Ah right - yes if there is a specific 'make xipImage' command then I would imagine that takes care of making an uncompressed image.  Otherwise you should still be able to find the uncompressed one somewhere in arch/arm/boot/

6MB is just the size of the kernel I was building, which didn't have a whole lot of drivers in it, but had a fair bit of everything else.  If you take out things you won't need (iptables firewall, IPv6, FAT filesystem for SD cards, etc.) then you can of course shrink it down further.  I'm not sure what the minimum size would be.  Also I think I may have been including a BusyBox binary in the initramfs, which would also make the kernel a bit larger but is kind of a requirement, unless you are using root-over-NFS.

It sounds like the start address is not the one you should be changing, given the effect it has had.  Which option are you actually setting?  Looking at the kernel config, under "Boot options", selecting "Kernel Execute-In-Place from ROM" reveals an option just below it called "XIP Kernel Physical Location".  I would think this is the place to set it?

But remember that at the end of the day, the only benefit of using a XIP kernel is to free up more RAM, so are you short of RAM to begin with?  If your running system has plenty of free memory, then all a XIP kernel is going to do is give you even more unused memory, at the expense of making the kernel less functional.

It sounds like the start address is not the one you should be changing, given the effect it has had.  Which option are you actually setting?  Looking at the kernel config, under "Boot options", selecting "Kernel Execute-In-Place from ROM" reveals an option just below it called "XIP Kernel Physical Location".  I would think this is the place to set it?

yes, this is precisely where Im setting it...tried 0x20000, which would make sense in my case (loading the image to flash at offset 0x7F020000), but the build errors out complaining about overlapping sections.

But remember that at the end of the day, the only benefit of using a XIP kernel is to free up more RAM, so are you short of RAM to begin with?  If your running system has plenty of free memory, then all a XIP kernel is going to do is give you even more unused memory, at the expense of making the kernel less functional.

this is exactly what Im curious about: freeing up & having more RAM available...

I've been playing with the 3.1 kernel that's listed at the top of this forum (it looks like the repos are functional again after having been down for awhile, so I was able to successfully clone & build).

However, on that kernel, some of the busybox apps have been giving me strange kernel panics due mainly to "failed page/memory alloc's". Im not sure if this is a bug/problem with busybox, or with that specific kernel version, or if there's a configuration option somewhere that needs to be tweaked in order to eliminate the problem. Still, I figured that its always best to try to have all the RAM you can possibly get, with the hopes that the kernel panics due to insufficient memory will go away.

So, I guess the idea/goal is to see if it would be feasible to possibly create a lightweight xip kernel in order to free up all of the ram, and then maybe load the filesystem off of NFS or an http/tftp download or by some other means (obviously, all of this could be like an 'advanced user configuration option' for setting up these ip cameras with a small kernel and remote filesystem image, since I'm guessing that this might be too complicated for regular users that just want to flash a kernel and be done with it).

feedback is welcome...

I very much doubt the errors you are seeing are due to insufficient memory.  If this were the case you would see log messages about the kernel OOM (out-of-memory) handler killing random processes.

It is *much* more likely that the errors you are seeing are due to the CPU not having an MMU.  This means certain multitasking functions like fork() are unavailable, and AFAIK it is not possible to use the mmap() function either.  It is odd that you are getting a kernel panic though - normally it's just a userspace segfault when a program tries to use one of these functions (if that program can even be compiled in the first place.)

Have you tried compiling the git repo of my kernel port?  That might give you another data point as to whether it is the kernel or busybox at fault.  On that note, is there any chance you can post the BFLT BusyBox binary you are using? (maybe over in the other thread.)  I can't finish porting the rest of the kernel until I can boot it to userspace, and I can't do that because I'm still unable to produce any BFLT binaries.  Perhaps if I can run yours I will be able to finish the port.

is there any chance you can post the BFLT BusyBox binary you are using? (maybe over in the other thread.)  I can't finish porting the rest of the kernel until I can boot it to userspace, and I can't do that because I'm still unable to produce any BFLT binaries.  Perhaps if I can run yours I will be able to finish the port.

ok, I'm attaching the busybox binary from my build. please test it out when you get a chance, and let me know if it works for you, or if you get any strange errors. Most of the time, I could cause a panic by simply running the 'ls' command multiple times; after around the 4th or 5th time running ls in a row, I'd get a panic.

Have you tried compiling the git repo of my kernel port?  That might give you another data point as to whether it is the kernel or busybox at fault.

Which repo are you referring to? the buildroot repo, or some other repo? If you have another repo in addition to the buildroot one, please let me know so that I can give it a try...

Thanks for the BusyBox binary.  The kernel gets further than before - it actually recognises it as BFLT and downloads the whole file and tries to run it, but then it can't run it and I get a kernel panic "not syncing: Attempted to kill init! exitcode=0x00000004"

It may have been compiled with the old ARM ABI as I think I am using the new one with this kernel.

Yes there is another repo for just the Linux kernel.  It's in the other thread, it was the first one I posted: https://github.com/Malvineous/linux-nuc700  The buildroot repo downloads this one when the time comes to compile the kernel.