I've been working on a demo of the AIOS (AlwaysInnovating) kernel for an -xM Rev C Beagleboard.
Following instructions here,
http://www.alwaysinnovating.com/wiki/index.php/Kernel_compilation
I downloaded the mentioned 2.6.32 kernel and applied all the patches from OE here:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-psp-2.6.32/beagleboard-xmc?h=2011.03-maintenance
I however didn't find any patch in the OE tree for the new changes we made to 2.6.39, such as for the DVI reset GPIO and DVI power enable, so I pulled these out from my own git tree. Why isn't this patch included?
The kernel builds fine but even with the patches for -xM Rev C support, it hangs. Here is a bootlog:
OMAP3 beagleboard.org # boot
mmc1 is available
The user button is currently NOT pressed.
reading boot.scr
** Unable to read "boot.scr" from mmc 1:1 **
reading uImage2
6396352 bytes read
Booting from mmc ...
## Booting kernel from Legacy Image at 80200000 ...
Image Name: Linux-2.6.32-joelv1
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 6396288 Bytes = 6.1 MB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux........................................................................................................................................................................................................................................................................................................ done, booting the kernel.
[ 0.000000] Unable to get DVI reset GPIO=-22
[ 0.000000] omap_init_mbox: platform not supported
[ 30.796112] mmci-omap-hs mmci-omap-hs.1: err -16 configuring card detect
[ 30.897552] Unable to set L3 frequency (400000000)
[ 31.210296] sil9022 3-0039: <sil9022_write_reg> ERROR: i2c write at=c7 val=0 flags=0 err=-121
[ 31.241455] sil9022 3-0039: <sil9022_write_reg> ERROR: i2c write at=c7 val=0 flags=0 err=-121
[ 31.272979] sil9022 3-0039: <sil9022_write_reg> ERROR: i2c write at=c7 val=0 flags=0 err=-121
[ 31.303894] sil9022 3-0039: <sil9022_write_reg> ERROR: i2c write at=c7 val=0 flags=0 err=-121
[ 31.335113] sil9022 3-0039: <sil9022_write_reg> ERROR: i2c write at=c7 val=0 flags=0 err=-121
[ 31.366485] sil9022 3-0039: <sil9022_write_reg> ERROR: i2c write at=c7 val=0 flags=0 err=-121
[ 31.397613] sil9022 3-0039: <sil9022_write_reg> ERROR: i2c write at=c7 val=0 flags=0 err=-121
[ 31.406219] sil9022 3-0039: <sil9022_set_cm_clkout_ctrl> ERROR: Writing HDMI configuration to reg - SI9022_REG_TPI_RQB
WARNING: Couldn't open directory /lib/modules/2.6.32-joelv1: No such file or directory
FATAL: Could not open /lib/modules/2.6.32-joelv1/modules.dep.temp for writing: No such file or directory
[ 56.538787] init: cannot find '/system/etc/install-recovery.sh', disabling 'flash_recovery'
[ 397.569427] binder: 1222: binder_alloc_buf, no vma
The kernel modules are in the rootfs, not the initramfs. Everything
needed at the initramfs level (such as SMSC95xx and similar) is built
inside the kernel, so no module needed at this stage.
And to be clear, the kernel modules are in each squashfs which are
mounted through aufs. And depmod has been run the first time so the
kernel modules are inserted when needed.
Tthe patches to be applied for XM-revC are not for sure on the git tree
but I know that they have been applied internally. I need to check the
exact status. Actually, one of the problems is that we don't have an
XM-revC 
Grégoire Gentil
Founder Always Innovating
Hi Gregoire,
Thanks.
The kernel modules are in the rootfs, not the initramfs. Everything
needed at the initramfs level (such as SMSC95xx and similar) is built
inside the kernel, so no module needed at this stage.
And to be clear, the kernel modules are in each squashfs which are
mounted through aufs. And depmod has been run the first time so the
kernel modules are inserted when needed.
Is this magic done by the init script in the initramfs? Also, would
unpacking the cpio archive from the kernel into / work just as well?
I replaced the U-boot in the boot partition and set some bootargs, and
I now can I see this in my ttyS2:
[ 63.850830] warning: `zygote' uses 32-bit capabilities (legacy
support in use)
[ 64.425964] init: starting 'bootanim'
[ 75.263122] init: starting 'dhcpcd'
[ 76.941925] usb0: link up, 100Mbps, full-duplex, lpa 0xCDE1
[ 81.336730] binder: release 391:411 transaction 1761 out, still active
[ 83.600097] init: service 'bootanim' is being killed
[ 83.621612] init: waitpid returned pid 213, status = 0000000f
[ 83.627441] init: process 'bootanim', pid 213 exited
.....
[ 121.309173] init: starting 'dhcpcd'
[ 155.360870] binder: release 661:661 transaction 3207 out, still active
[ 156.279876] init: waitpid returned pid 613, status = 00000000
[ 156.285949] init: process 'dhcpcd', pid 613 exited
[ 169.191589] binder: release 772:772 transaction 3689 out, still active
[ 381.550964] binder: 199:206 transaction failed 29189, size 4-0
[ 381.556854] binder: send failed reply for transaction 1761, target dead
[ 385.163238] binder: 199:389 transaction failed 29189, size 8-0
[ 385.171112] binder: send failed reply for transaction 1892, target dead
So atleast we're in userspace, 
Do you have any thoughts about what could be causing this? Thanks.
Regards,
Joel
Wouldn't it be cleaner to have a common set of modules, than having
install them in eacg squash fs?
Regards,
Joel
Hi Gregoire,
I have applied all xM Rev C patches to the AIOS kernel from the
linux-omap-psp 2.6.32 recipe and it boots just fine.
However I now notice the following problems:
* The user button double tap for switching an OS doesn't work. This is
not a problem with the kernel however as the userbutton does work
during the initial OS selection screen.
Could you give some pointers to where/how is the user button double
tap functionality handled?
* Android applications keep crashing with a error similar to
"com.google.process... has crashed unexpectedly"
I am using the exact same image that is available for download (with
same u-boot, bootargs etc). The only difference is the kernel.
Thanks in advance,
Regards,
Joel
Please send me the revC patches and I will take a look and give it a try
if I have time.
Double user button does this:
/usr/bin/ai-multipleos &
sleep 1s
/usr/share/ai-multipleos/switch.sh -i &
Grégoire Gentil
Founder Always Innovating
I'm not sure to understand your point. You mean that you would prefer to
have the modules in the initramfs? There is an option - but not for
Beagleboard - to avoid the initramfs, so it's the reason why the modules
are in the rootfs through the squashfs,
Grégoire Gentil
Founder Always Innovating
[sorry I dropped the CC list]
> > The kernel modules are in the rootfs, not the initramfs. Everything
> > needed at the initramfs level (such as SMSC95xx and similar) is built
> > inside the kernel, so no module needed at this stage.
> >
> > And to be clear, the kernel modules are in each squashfs which are
> > mounted through aufs. And depmod has been run the first time so the
> > kernel modules are inserted when needed.
> [Joel]
> Wouldn't it be cleaner to have a common set of modules, than having
> install them in eacg squash fs?
I'm not sure to understand your point. You mean that you would prefer to
have the modules in the initramfs? There is an option - but not for
Beagleboard - to avoid the initramfs, so it's the reason why the modules
are in the rootfs through the squashfs,
[Joel]
Since the initramfs scripts are mounting the SD Card anyway, why not
get rid of initramfs and just have the kernel mount the SD card as
root file system, which can contain all the common modules + init
scripts + the aios magic scripts :))
Regards,
Joel
Hi Gregoire,
Please send me the revC patches and I will take a look and give it a try
if I have time.
I am happy to be getting to demo the wonderful work Always Innovating
has been doing!
The set of patches I applied can be downloaded here:
http://www.utdallas.edu/~joel.fernandes/aios-xmc-patchset.tar.gz
My git tree is located at:
https://github.com/joelagnel/linux-omap-2.6/tree/aios-2.6.32
This is the same 2011-03.a AIOS version + xM Rev C patches.
Thanks,
Joel
[sorry I dropped the CC list]
>
> > > The kernel modules are in the rootfs, not the initramfs. Everything
> > > needed at the initramfs level (such as SMSC95xx and similar) is built
> > > inside the kernel, so no module needed at this stage.
> > >
> > > And to be clear, the kernel modules are in each squashfs which are
> > > mounted through aufs. And depmod has been run the first time so the
> > > kernel modules are inserted when needed.
> > [Joel]
> > Wouldn't it be cleaner to have a common set of modules, than having
> > install them in eacg squash fs?
> I'm not sure to understand your point. You mean that you would prefer to
> have the modules in the initramfs? There is an option - but not for
> Beagleboard - to avoid the initramfs, so it's the reason why the modules
> are in the rootfs through the squashfs,
[Joel]
Since the initramfs scripts are mounting the SD Card anyway, why not
get rid of initramfs and just have the kernel mount the SD card as
root file system, which can contain all the common modules + init
scripts + the aios magic scripts :))
Because then you can't really select which OS you want to un as you have
already pivot_root,
Grégoire
I have patched and compiled the kernel:
http://git.alwaysinnovating.com/cgit.cgi/ai.openembedded.dev/commit/?id=6f962e9e0f5494bda3191edefcf824dedae6ecc0
The binaries are here:
http://www.alwaysinnovating.com/download/uImage2-xm-revc.zip
It's working on XM revA/B but I don't have a XM revC.
Note that the user button is working but I had to modify the original
patch, especially the last hunk. I had to transform this:
into this:
if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XMC) {
gpio_buttons[0].gpio = 4;
}
On rev A/B, R148 is not DNI and to make work the user button, it needs
to go through gpio 4 I don't know why. Perhaps my kernel is too patched
somewhere else.
Somebody (Joel???) needs to test the mentioned binaries and see if the
user button is working at the multiple OS screen. On rev C, R148 is DNI
should it should go through gpio 7,
Grégoire
The User-button doesn't seem work on the multiple-os selection screen
with the kernel binary you upload, for -xM C.
But, I fixed an error in my latest patch and user-button is working
fine now on the OS selection screen.
https://github.com/joelagnel/linux-omap-2.6/commit/cd02b0954e008ab7a84d11c565a02f2c034d949e
However once an OS is selected and running, it is not possible for
user button to switch to a different OS.
Do you anticipate any kernel modules to be rebuilt and installed into
the individual squash FS's? This seems to be more of a user-space
issue and/or the GPIO being exported incorrectly from userspace. Any
user-button scripts in the individual OS's need to be edited?
Thanks!
Joel
I have updated the binaries here:
http://www.alwaysinnovating.com/download/uImage2-xm-revc.zip
Can you please try?
Grégoire
The switch feature occurs only from AIOS,
Grégoire
But, I fixed an error in my latest patch and user-button is working
fine now on the OS selection screen.
https://github.com/joelagnel/linux-omap-2.6/commit/cd02b0954e008ab7a84d11c565a02f2c034d949e
I have updated the binaries here:
http://www.alwaysinnovating.com/download/uImage2-xm-revc.zip
Can you please try?
The User-button is working in the OS-select screen. However android
applications keep crashing, and USB devices including networking don't
come up.
I don't know if I changed anything on the root filesystem that is
causing this. So I'm going to burn a fresh image and copy your kernel
binaries to see if I still see any issues.
Could you confirm that there are no kernel modules that need to be
reinstalled to squash after new kernel builds?
Regards,
Joel
Correct if you are using my kernel,
Grégoire
Hi Gregoire,
I can confirm that the AIOS image that's on the website will not boot
on an -xMC.
I have tried it on 2 -xM Rev C boards here.
X-loader will not come up but as spent a few hours fighting it, I will
just use my
own SD Card image and just contents of the filesystem of the AIOS
image that didn't work.
It might worth investigating why this is so though, as a next step.
Regards,
Joel
Hi Gregoire,
Just if it helps, I found that the reason was the MLO that comes with
the image I downloaded from the AI beagleboard page. The same MLO
works on -xM Rev A but not on an -xM Rev C.
Replacing the MLO with my own allows it to boot on an -xM Rev C.
Thanks,
Joel
Hi Gregoire,
Another thing I notice is that with the U-boot that ships with your
image, USB devices don't work with the kernel, so you can't use the
keyboard to select the OS in the OS select screen. LED D14 is on.
My U-boot tree works, so you can check and see how it is different from yours.
It it located at: https://github.com/joelagnel/u-boot
With my U-boot, MLO and applying patches to the kernel, it works so
far on the -xM Rev C. so, looks like I am ready to demo. 
Thanks.
Regards,
Joel