Tartarus changed the topic of #u-boot to: SOURCE MOVED TO https://source.denx.de/u-boot/u-boot.git / U-Boot v2022.04, v2022.07-rc2 are OUT / Merge Window is CLOSED / Release v2022.07 is scheduled for 4 July 2022 / http://www.denx.de/wiki/U-Boot / Channel archives at https://libera.irclog.whitequark.org/u-boot
GNUtoo has joined #u-boot
<NonaSuomy> epdc_progress_work_func start progress.
<NonaSuomy> mxc_epdc_fb mxc_epdc_fb: Unable to enable DISPLAY regulator.err = 0xffffffff
<NonaSuomy> tps65180_display_enable fail to read vcom from eMMC. -1
<NonaSuomy> WARNING: at drivers/regulator/core.c:1423 _regulator_disable+0x30/0x118()
<NonaSuomy> ------------[ cut here ]------------
<NonaSuomy> unbalanced disables for DISPLAY
<NonaSuomy> got my custom kernel to load but gets stuck here
<NonaSuomy> not sure where the location for the vcom is read from
<NonaSuomy> (I'm not loading from the eMMC so that is probably why)
<NonaSuomy> Loading from SDCard
<NonaSuomy> any idea where to look for something like that?
<NonaSuomy> would that location be compiled into the kernel or some file it's grabbing from another place?
<rfs613> NonaSuomy: at this point you're booting linux kernel and trying to transition to usespace, so #u-boot is increasingly not the best place ;-0
<NonaSuomy> where's the best place?
<NonaSuomy> Wouldn't think maybe spaces would know much about embedded platforms besides here :P
<NonaSuomy> *many
<rfs613> maybe #armlinux channel?
<NonaSuomy> thank you.
<rfs613> anyhow I don't know much about the regulator framework, but it seems it is leaving things enabled, which is probably fine
<rfs613> you probably don't want to enter low-power mode necessarily
<rfs613> i'd be more concerned about the unable to open initial console
<rfs613> and the real question is why is init failing?
<NonaSuomy> I tried your suggestion with init /system/bin/sh
<NonaSuomy> on the stock kernel
<rfs613> no luck?
<NonaSuomy> didn't seem to care
<NonaSuomy> just booted like normal with no console from uart
<rfs613> were you using an initramfs at the time?
<NonaSuomy> how do I find that out?
<NonaSuomy> bootargs=root=/dev/mmcblk0p1 rootfstype=ext4 rw rootwait init=/linuxrc console=ttymxc4,115200 bootdev=0 rawtable=0xF40000
<NonaSuomy> bootcmd=mmc read 0 ${loadaddr} 0x800 0x1400;mmc read 0 ${loadaddr_ramdisk} 0x2800 0x258;bootm ${loadaddr} ${loadaddr_ramdisk} bootdev=0
<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.
vagrantc has quit [Quit: leaving]
<rfs613> actually look at like 840 first, thats for ramdisk
<rfs613> and line 915 says for ramdisk the default is "/init"
<rfs613> so in your boot log, the panic right at the end (not syncing: Attempted to kill init!) is when it tries to run this program.
<NonaSuomy> line 926 here if (!ramdisk_execute_command)
<NonaSuomy> ramdisk_execute_command = "/init";
<rfs613> yup
<rfs613> also line 906 is showing up in your log, so you are missign /dev/console in the ramdisk, and so there is no stdout for /init
<rfs613> (this is probably normal in android, nobody ever sees linux console there, it's all java guis)
mmu_man has quit [Ping timeout: 260 seconds]
<NonaSuomy> here is the stock boot process
<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> this is part of the android boot process, /init executable reads the init.rc config file
<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]
Zapy has joined #u-boot
akaWolf has quit [Ping timeout: 240 seconds]
akaWolf has joined #u-boot