[Gen9 Android Development] trevd:
Problems and Solutions!

Hi Folks,

Okay, using a persistent property like does not work although the concept is still sound the application is shi*te :) , basically persistent properties are saved by creating a file in /data/property/<persistent property name> and writing the property value to that file.

/data and persistent property changes are actioned long after the *.rc files have been parsed. This means that init.${persist.sys.bootmode}.rc will only every be set to recovery as set by default.prop ( which is parsed before any rc file by the init process ) .

There are a lot of wrong ways to solve this issue, I could hack away at the init code and get it to mount the data partition early but I don't really do not want to change the platform code as that ties this whole process into a specific code base for the android platform and would mean each "distro" ( e.g CM , AOKP ) would have to have these patches applied.

The Ideal Solution IMHO is for the bootmode to be known before init has even started and managed and persisted by the kernel, In the course of researching this I read that OMAP4 SoC's do have area of ram that does not get cleared at reboot. Given the work arounds and hacks I could see ahead using the persist property methods I decided to have a look at this again.

So.......... I did some digging and I've had a fun old time elbow deep in kernel code, It's been an education but has also proved very fruitful. :D

looking at the kernel sources the "omap4-reboot-reason" functionality stuck out the most and looking at the sources it seemed to be writing to the "scratch" ram on reboot and already storing any paramter passed into the reboot commands. Now I don't know ( and I will check ) if archos have disabled this functionality on purpose because although it stores this reboot command on reset , it did nothing with it when the device comes back up.

Well It does now! :)

After much hacking around and printk debugging ( who needs gdb ;) ( me! when I learn how to work it LOL ) ) I've got a solution, a simple patch to the omap_reboot_reason_init. Setting the kernel command line argument androidboot.mode to the value of the reboot reason means init will automatically process it and create android system property calll ro.bootmode We can then simply change the init.rc to use init.${ro.bootmode.rc. instead of init.${persist.sys.bootmode}.rc when loading the mode specific files. :victory:

This also means we don't need the persist proprty at all or the previous patch I made to the android reboot code in libcutils. Given how this all fits together with no modification to the android platform code I'd say that It's hopefully got this ""problem" "boxed" off :) This functions quite independently of archos' reboot_into setting. and also allows you to choose what "mode" of sde you want to boot into when rebooting from stock. You've gotta wonder why archos didn't make use of this functionality themselves?

Here's the change I made to <kernel path>/arch/arm/mach-omap2/omap4-reboot-reason.c

static int __init omap_reboot_reason_init(void)
{
void __iomem *sar_base = omap4_get_sar_ram_base();
if (sar_base){
char android_reboot_reason[256] ;
strncpy(android_reboot_reason,sar_base + OMAP_REBOOT_REASON_OFFSET, OMAP_REBOOT_REASON_SIZE);
if(strlen(android_reboot_reason)){
strlcat(saved_command_line," androidboot.mode=",256);
strlcat(saved_command_line,android_reboot_reason,256);
}
}
return register_reboot_notifier(&omap_reboot_notifier);
}

easy when you know how!!! I'll commit all this to my github shortly and upload a ramdisk and jellybean enabled kernel. I'm just fixing up the checkfs to be a little more robust so it doesn't wipe anyones data partitions out :D

I think that's a win then, :cool: Hack On People, More soon!