• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 5425 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Add shell to RamDisk

Erik Duysters
Prodigy 110 points

I'm using an omap3evm board together with the rowboat gingerbread stack. As I read somewhere that rowboat does not support the standard recovery mechanism, I wanted to implement a recovery solution launched from the ramdisk.

At first, boot is done from SD-card. So I have a u-boot.bin, uImage as kernel and now also created a ramdisk called uInitrd.I've created that by the " ./mkimage -A arm -O linux -T ramdisk -d ramdisk.img ..." command. In u-boot, I've loaded both uImage and uInitrd which seems to be ok. So kernel boots up and start the init process from the ramdisk. This seems all working fine. The standard android ramdisk does not contain much, but it contains adb in the sbin directory and also this seems to launch correctly.

To make things easier I wanted to add the shell to the ramdisk, which would make things easier for development. And this is where it goes wrong.I copied sh to the ramdisk from the android_rootfs folder in the out/target/product/[product_name] and added the following lines to the init.rc:

service console /system/bin/sh
    console

When I now boot up, it will launch still the adb but the shell will not be started. Instead it gives the following error:

init: cannot execve('/system/bin/sh'): No such file or directory

This apparently means that the sh binary exist on /system/bin/ (otherwise it should say: init: cannot find '/system/bin/sh') but it looks it cannot start it properly.

Any ideas what could be the issue?

 

  • 0
    TI__Expert 3245 points

    Hi Erik,

    A couple quick questions for you ...

    1. What is the file permissions of the "sh" binary in the ramdisk?
    2. What do you have in your init.rc? By default the ram disk will try to mount the system.img in the /system directory. I am guessing that you have modified the init.rc not to do this, but just checking.

    One suggestion would be to build busybox and stick this in your ramdisk and use this as a shell instead. There is an article here on how to build and use busybox and you could try something similar.

    http://omappedia.org/wiki/Android_Installing_Busybox_Command_Line_Tools

    Jon

  • 0 in reply to Jon Hunter
    Prodigy 110 points

    Hi Jon,

    1) Permissions I checked already. Normally execve would also give an permission error if this was not not ok.

    2) system.img is not mounted in init.rc. But this is also not the case for the normal rootfs. The rowboat stack (at least the one we have to the omap3evm board) works differently then the standard android (where you have several partitions to put e.g. system.img, userdata.img, ...). Boot happens via MMC or eMMC and there are 3 partitions: a FAT32, and EXT3 and again a FAT32. First FAT32 partition contains x-loader, u-boot and kernel and now also the ramdisk. Ext3 partition contains the root file system including system, data, cache, etc. . The last FAT32 is just for some extra storage like media files. We will change eventually change this to our needs. Anyhow it really uses the system directory of the ramdisk (did some checks there to verify it)

    Adding busybox was something I planned to do, but in a first step I taught not to change to much and just add the shell script but that didn't work already.

    I will now add busybox to see if that is failing too. Anyhow I think the cause must be something else.

     

    thanks,

    Erik

  • 0 in reply to Erik Duysters
    TI__Expert 7220 points

    Erik,

    I have seen this error when the binaries does not have sufficient permissions.

    Check the permissions of adbd and apply the same permissions to "sh" to have a try.

     

  • 0 in reply to Arun Joseph
    Prodigy 110 points

    Ok, I've checked it again, just to make sure I did not make a mistake.

    Permissions are the same as adbd. I also verified it the opposite way by removing the execute flag and then the error is as expected "Permission denied".

    So the problem seems not to be related to permissions.

    Best regards,

     

    Erik

  • 0 in reply to Erik Duysters
    Prodigy 110 points

    Ok, apparently the reason why it does not work is because sh has still some library depencies (libc.so, libm.so, libstdc++.so).

    I have added the libraries but it doesn't seem to help (including setting LD_LIBRARY_PATH). Adbd apparently has no dependencies.

    So building busybox as static binary  would be a better way forward.

    But apparently the precompiled toolchain we have is different then in http://omappedia.org/wiki/Android_Installing_Busybox_Command_Line_Tools.

    There are no header files included (e.g limits.h), so I need to check where they are located in the stack.

    Best regards,

    Erik

  • 0 in reply to Erik Duysters
    TI__Expert 3245 points

    Hi Erik,

    I must admit that at TI I work on the standard OMAP Android releases and not the rowboat variant. I did check using ldd on my side for the version of Android I have, if sh had any dependencies and I found that it did not. So must be a difference with rowboat. However, that would make a lot of sense if libraries are missing that it needs.

    I am not sure I followed your comment on the "precompiled toolchain".

    Cheers
    Jon

     

  • 0 in reply to Jon Hunter
    Prodigy 110 points

    Hi Jon,

     

    I've got it working with the standard shell. The rowboat stack indeed does have dependencies . I've changed the Android.mk file with

    LOCAL_FORCE_STATIC_EXECUTABLE := true
    LOCAL_STATIC_LIBRARIES := liblinenoise libc libm libstdc++

    With these changes sh does not have any depencies anymore and it works.

    I agree that it makes a lot of sense if the libraries were missing that it does not work. But the dynamic libraries were copied on the ram disk and the LD_LIBRARY_PATH set (I even tried putting them in the standard /lib or /system/lib or in the same directory as the binary). 

    Regarding busybox, I meant with "precompiled toolchain" that we use the binaries in the prebuilt/linux-x86/toolchain/arm-eabi-4.4.3 and do not compile the toolchain ourselves.

    Best regards,

    Erik