<NonaSuomy>
I just change init=/system/bin/sh there.
<rfs613>
looks like you loaded a ramdisk
<rfs613>
(two calls to "mmc read", one for kernel, one for ramdisk)
<rfs613>
so in this case, try rdinit=/bin/sh instead of init=/bin/sh
<NonaSuomy>
when I look at the data on the card there is no bin folder in root but there is one in /system does that matter?
<rfs613>
that's likely because its an android rootfs
<NonaSuomy>
correct
<rfs613>
but the ramdisk is a different story
<rfs613>
you could try to extract that and take a peek inside
<NonaSuomy>
ok so I'm removing init=/linuxrc and replacing that with rdinit=/bin/sh
<rfs613>
yep, worth a quick try if it's easy for you
<NonaSuomy>
Ok one sec
<rfs613>
based on the bootargs, we know for sure that the ramdisk contains "/linuxrc". It is either an executable, a symlink to something else, or a shell script.
<rfs613>
wait, sorry, I got that wrong... init=/linuxrc applies to the real rootfs, not the ramdisk
<rfs613>
(or possibly back in 2.6 kernel days, this was different... memory is a bit foggy...)
<NonaSuomy>
hmm the ramdisk doesn't seem to contain very much binary wise
<NonaSuomy>
no /bin no /system/bin
<rfs613>
how about /init ?
<NonaSuomy>
yes /init is there
<rfs613>
and /linuxrc ?
<NonaSuomy>
nope
<NonaSuomy>
init.rc
<NonaSuomy>
init.goldfish.rc
<rfs613>
oh those are android things, they are not executables
* rfs613
has forgotten all about android details too
<rfs613>
if you look at init/main.c in the linux kernel, you can see which executables it tries to run.
<rfs613>
hmm, so in the stock one, line 239 is where it launches /init ... and there seems to be some output from init (complains about not finding initlogo.rle)
<rfs613>
point is, stock one seems to be able to run /init, while yours is failing.
<rfs613>
so something's different ;-)
<NonaSuomy>
initlogo.rle doesn't seem to exist in the stock ramdisk
<rfs613>
so, there may not be a /bin/sh in there at all
<rfs613>
in the init.rc there are some commend out lines for starging a service console
stefanro has quit [Ping timeout: 248 seconds]
<rfs613>
i don't know how this works, but i'd be tempted to try uncommenting those two lines (make it look like the "switcher daemon" which follows)
stefanro has joined #u-boot
<NonaSuomy>
Ok thank you for your further assistance I'll go check and see if anyone can help with this vcom reading in android then all else fails I see what that does. If you think of anything else let me know :D
<NonaSuomy>
*in armlinux
hanetzer has quit [Quit: WeeChat 3.5]
sobkas has quit [Quit: sobkas]
thopiekar has quit [Ping timeout: 248 seconds]
thopiekar has joined #u-boot
alpernebbi has quit [Ping timeout: 250 seconds]
alpernebbi has joined #u-boot
prabhakarlad has quit [Ping timeout: 252 seconds]
mrnuke has quit [Ping timeout: 240 seconds]
mrnuke has joined #u-boot
mrnuke has quit [Ping timeout: 240 seconds]
mrnuke has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #u-boot
hanetzer has joined #u-boot
<hanetzer>
can one include kernel cmdline in a FIT image? if so, how?
mrnuke has quit [Ping timeout: 240 seconds]
mrnuke has joined #u-boot
NonaSuomy has quit [Ping timeout: 248 seconds]
littlebobeep has quit [Remote host closed the connection]
littlebobeep has joined #u-boot
ilunev has joined #u-boot
ilunev has quit [Client Quit]
NonaSuomy has joined #u-boot
NonaSuomy has quit [Quit: Lost terminal]
redbrain has quit [Read error: Connection reset by peer]
redbrain has joined #u-boot
littlebobeep has quit [Remote host closed the connection]
littlebobeep has joined #u-boot
mmu_man has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
littlebo1eep has joined #u-boot
littlebo1eep is now known as littlebobeep
sobkas has joined #u-boot
crb has quit [Read error: Connection reset by peer]
akaWolf has quit [Ping timeout: 276 seconds]
akaWolf has joined #u-boot
littlebobeep has quit [Ping timeout: 240 seconds]
littlebobeep has joined #u-boot
apritzel has joined #u-boot
GNUtoo has quit [Ping timeout: 240 seconds]
GNUtoo has joined #u-boot
crb has joined #u-boot
vagrantc has joined #u-boot
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
<crb>
in efi_disk_read_blocks in lib/efi_loader/efi_disk.c how is media->io_align determined for my platform? I am trying to figure out what alignment I need to meet when calling efi_disk_read_blocks
Zapy has quit [Read error: Connection reset by peer]