ChanServ changed the topic of #msm8937-mainline to: Boot Linux on your MSM8917/37/40 and QM215 mobile! | GitHub: https://github.com/msm89x7-mainline | Logs: https://oftc.irclog.whitequark.org/msm8937-mainline | Bridged to #msm8937-mainline:kde.org on Matrix
FieryFlames[m] has joined #msm8937-mainline
<FieryFlames[m]> anyone able to test a lk2nd image on Cedric?
<hacker420[m]> your image or lk2nd in general
<FieryFlames[m]> well I was gonna make a image but I can let you know what I'd like tested
<hacker420[m]> I can test your image if you want
<FieryFlames[m]> awesome gimme a sec
<Andr[m]> What's the problem with lk2nd for cedric? Upstream has support for it https://github.com/msm8916-mainline/lk2nd/pull/359
<hacker420[m]> yeah it does
<FieryFlames[m]> you have to make a specific build or it boot loops
<FieryFlames[m]> unless the comment's outdated
<hacker420[m]> FieryFlames[m]: yes
<hacker420[m]> that's not outdated
<FieryFlames[m]> I determined on the moto g6 (ali) the reason it bootloops unless it's the only dtb is that moto's dtb selection logic fails if any dtb doesn't have a root model property
<hacker420[m]> thank motorola for that one
<FieryFlames[m]> wondering if it's the same situation on cedric
<Andr[m]> > To build for motorola-cedric, add LK2ND_DTBS="msm8937-motorola-cedric.dtb" to your make cmdline.
<Andr[m]> > cedric does not work with all dtbs enabled; the bootloader gets upset and goes into bootloop.
<hacker420[m]> FieryFlames[m]: your image boots fine
<FieryFlames[m]> lmao so it is the same situation then
<hacker420[m]> *slow clap
<hacker420[m]> *
<hacker420[m]> slow clap
<FieryFlames[m]> I just shoved model = "test" in every dtb
<FieryFlames[m]> btw, why are the msm8952 dts all laid out in multi-device form when they're for one device?
<hacker420[m]> <FieryFlames[m]> "btw, why are the msm8952 dts all..." <- that'
<hacker420[m]> *
<barni2000[m]> <FieryFlames[m]> "I determined on the moto g6 (ali..." <- Ali have same issue check msm8953-mainline/lk2nd
<FieryFlames[m]> barni2000[m]: that's the device I fixed it originally on xd
<FieryFlames[m]> like 20 mins ago
<barni2000[m]> I have made a separate project for it
<FieryFlames[m]> I know why it dies and how to fix it
<barni2000[m]> Ik
<hacker420[m]> well
<hacker420[m]> the question is if that is the proper fix though
<hacker420[m]> do we just slap a model property in every dts
<barni2000[m]> cedric, ali, land needs individual build because of sh**y vendor bootloader
<hacker420[m]> wait
<hacker420[m]> aren't the images built for a specific device anyway?
<FieryFlames[m]> no
<barni2000[m]> If you find some security hole and you can disable secure boot then you can replace the bootloader
<hacker420[m]> ah wait no
<hacker420[m]> hm
<hacker420[m]> I am really thinking what the proper solution is here
<FieryFlames[m]> hacker420[m]: we could put it in skeleton64 probably
<FieryFlames[m]> hacker420[m]: considering there's apparently multiple devices expecting model prop...
<barni2000[m]> Btw for ali pmos wiki is outdated
<FieryFlames[m]> aka_ says deen also requires being the only dtb (which only works because lk assumes a single dtb will be correct)
<FieryFlames[m]> how so
<FieryFlames[m]> barni2000[m]: how so
<hacker420[m]> FieryFlames[m]: yes but you'd have to make sure it doesn't cause some weird ass behavior down the line
<hacker420[m]> on other devices
<barni2000[m]> I have created lk2nd package for it so the installation guide is not correct
<hacker420[m]> I'd say open an issue or PR on the repo
<hacker420[m]> or ask in msm8916-mainline
<FieryFlames[m]> hacker420[m]: of course, but consider that legacy lk2nd (and msm8953-mainline/lk2nd) have root model properties
<FieryFlames[m]> hacker420[m]: I pinged travmurav in msm8953 mainlining where I first figured it out
<FieryFlames[m]> barni2000[m]: cool but hopefully we can get rid of this
<hacker420[m]> FieryFlames[m]: and?
<FieryFlames[m]> hacker420[m]: no reply yet xd
<hacker420[m]> honestly
<hacker420[m]> toss a draft PR on the repo
<hacker420[m]> and see what others think
<FieryFlames[m]> I'm going to wait for travmurav to let me know what he thinks first
<FieryFlames[m]> partly because it's 4 am
<FieryFlames[m]> and by the time I'll do a pr I'll prob have a reply
<barni2000[m]> I have asked people to test my changes for ali months ago but no one was help me so. Modem will need some quirk from lk2nd afsik
<barni2000[m]> FieryFlames[m]: No because the bl only can handle 1 dt
<FieryFlames[m]> barni2000[m]: I have the fix for this dude
<FieryFlames[m]> I know why the bl can "only handle" 1 dt
<FieryFlames[m]> Ali/cedric/deen(?) require every appended dt to have model property
<FieryFlames[m]> otherwise crash
<FieryFlames[m]> if every dt has model prop then it selects fine
<barni2000[m]> I guess same needed for land than
<FieryFlames[m]> idk what device land is
<barni2000[m]> Redmi 3s
<FieryFlames[m]> you can try it, but I wouldn't be surprised if it's a different bug
<FieryFlames[m]> I'm assuming the model requirement is in moto's selection code
<barni2000[m]> So cedric, momtana, ali, deen fortunately potter (g5 plus) is fine
<hacker420[m]> goddamn clowns
<barni2000[m]> s/momtana/montana/
<hacker420[m]> if someone were to find an exploit to disable secure boot we are golden
<FieryFlames[m]> btw, only reason 1 dt works is because lk assumes that if there's only 1 dt then it's correct: https://github.com/msm8916-mainline/lk2nd/blob/main/platform/msm_shared/dev_tree.c#L1357-L1362
<FieryFlames[m]> hacker420[m]: replacing bl would be cool but it's not like this fix isn't unattainable
<hacker420[m]> yeah
<hacker420[m]> but at least if we could replace bl that workaround wouldn't be needed
<hacker420[m]> since we could just directly boot lk2nd
<barni2000[m]> ok so we have a fix now cool lets apply it
<FieryFlames[m]> barni2000[m]: if you want to do this for msm8953-mainline/lk2nd go right ahead but I'm waiting for travmurav's thoughts before I do anything with msm8916/lk2nd
<FieryFlames[m]> I personally would like to use msm8916 lk2nd
<hacker420[m]> yeah I'
<hacker420[m]> yeah I'd wait too
<hacker420[m]> to not split efforts too much
<FieryFlames[m]> fixing it in msm8953 lk2nd would be easy as heck, just add model to the Samsung dts iirc
<barni2000[m]> FieryFlames[m]: It is planned to switch i have added the last bricks to be able to switch
<barni2000[m]> Couple of dts left
<FieryFlames[m]> it's kinda funny how long this fix has been in front of my face I remember building msm8953/lk2nd without Samsung dts and it working
angeryboi[m] has joined #msm8937-mainline
<angeryboi[m]> once switch to msm8916 lk2nd is complete, then I could start bringup on FIH nokia 5?
<FieryFlames[m]> barni2000[m]: you pushed Ali in msm8916 lk2nd anywhere? I have my own work in progress version
<FieryFlames[m]> dunno if it's a bug with my version or pmOS but when I booted pmOS I had no display
<barni2000[m]> aka_ was ported the dts idk if ali was pushed there let me check
<FieryFlames[m]> Ali wasn't no
<FieryFlames[m]> not in msm8916 atleast
<barni2000[m]> Only deen is there
<FieryFlames[m]> and ocean
<barni2000[m]> I was pushed to msm8953 after that ig
<barni2000[m]> FieryFlames[m]: Ocean needs dtbo anyway
<barni2000[m]> I think msm8916 variant is not working
<FieryFlames[m]> ah
<barni2000[m]> No one was tested
<FieryFlames[m]> ^anyways, if you want to try Ali on msm8916 lk2nd with all dtbs:
<FieryFlames[m]> works on my ali
<FieryFlames[m]> I haven't done panel stuff
<barni2000[m]> Btw i think this will needed to ali also #include <motorola-carrier-channel-ids.dtsi> for make modem to work, i have just cannot test it because i dont have ali
<FieryFlames[m]> I thought u had ali
<FieryFlames[m]> okay then
<barni2000[m]> FieryFlames[m]: Why it will be totally same like in msm8953 variant
<barni2000[m]> Almost
<barni2000[m]> FieryFlames[m]: No i have just added panel and battery support for it and someone was tested for me
<FieryFlames[m]> I removed it to check if it was the reason stuff broke
<FieryFlames[m]> and never added back
<barni2000[m]> If you not added you wil have not got working display unless you replace the compatible in the kernel
<FieryFlames[m]> I'm gonna test
<FieryFlames[m]> I just added back
<FieryFlames[m]> cool yeah disp works now
<hacker420[m]> ok so debug shell works well
<hacker420[m]> rootfs doesn't
<FieryFlames[m]> hm? in what context
<FieryFlames[m]> I noticed roots boot on Ali wasn't working too
<FieryFlames[m]> s/roots/rootfs/
<hacker420[m]> FieryFlames[m]: does debug shell work?
<FieryFlames[m]> yeah
<FieryFlames[m]> but that wouldn't really be affected by lk
<hacker420[m]> yes
<hacker420[m]> that's some kernel thing
<barni2000[m]> FieryFlames[m]: Enable extlinux config in deviceinfo
<hacker420[m]> hm?
<FieryFlames[m]> not doing that at nearly 5am xd
<barni2000[m]> Is it booting with msm8953 lk2nd
<FieryFlames[m]> no I'm booting with msm8916 lk2nd
<hacker420[m]> also was poking around in debug shell and this happened
<barni2000[m]> I dont asked what you booting for i have asked was it worked with msm8953-mainline/lk2nd?
<barni2000[m]> The two lk2nd has different fsboot implementation
<FieryFlames[m]> I am lost what do you want to know worked in msm8953 lk2nd
<FieryFlames[m]> fsboot? no idea, never tested
<FieryFlames[m]> I got Ali going on msm8916 lk2nd and then installed the existing pmOS port
<barni2000[m]> Then install lk2nd build from pmos with flasher flash_lk2nd and check if it can reach userspace
<FieryFlames[m]> I already turned off my desktop
<barni2000[m]> Ok than next time
<FieryFlames[m]> I don't really care if it works in msm8953 lk2nd xd, I want to use msm8916 lk2nd
<barni2000[m]> It is just help debugging it but it will work with msm8916 lk2nd
<hacker420[m]> I could try with 8953 lk2nd
<hacker420[m]> but what would it change
<barni2000[m]> It has different fsboot implementation but with cedric it will not work because of missing cpufreq support
<FieryFlames[m]> why does fsboot rely on cpufreq...
<hacker420[m]> shouldn't pmos handle the rootfs booting'
<hacker420[m]> via initramfs
<barni2000[m]> Not fsboot rely on it
<hacker420[m]> it sounds like you are describing directly booting into the rootfs
<barni2000[m]> Just it will be painfuly slow or it will crashing
<barni2000[m]> msm8937 is working with msm8916-mainline/lk2nd+my PRs for the soc
<barni2000[m]> msm8853-mainline only have basic support for it
<FieryFlames[m]> basic support for what??
<barni2000[m]> For the soc it csn boot lk2nd and that is all
<FieryFlames[m]> oh
<FieryFlames[m]> msm8953-mainline lk2nd only has basic support for msm8937 is what you're saying
<barni2000[m]> similar commit is missing for msm8952 platform to make second cluster boot https://github.com/msm8953-mainline/lk2nd/commit/b8f0b9d321ba60c0010473f0a82f0a2140b3b1b3
<barni2000[m]> i have sent it to msm8916-mainline
<hacker420[m]> I wonder why in debug shell it boots yet if I remove the parameter I get nothing'
<hacker420[m]> not even boot logs
<hacker420[m]> the booting just feels flaky in general
<hacker420[m]> probably kernel bugs
<hacker420[m]> and I still wonder why the continue boot command doesn't work
<hacker420[m]> msm also doesn't probe every time
<hacker420[m]> it works if I manually probe msm and panel
<hacker420[m]> <hacker420[m]> "and I still wonder why the..." <- it just dumps me back to debug shell
<hacker420[m]> it doesn't even look like it sees the partitions properly
<hacker420[m]> it does see the partitions
<barni2000[m]> It is the same bug what i have with land
<hacker420[m]> you got any fix for it?
<barni2000[m]> Not yet
<barni2000[m]> Reboots atm
<hacker420[m]> guess I wait then
<barni2000[m]> maybe you will wait for forevert :D
<barni2000[m]> s/forevert/forever/
<barni2000[m]> i don't have any idea yet
<hacker420[m]> hm
<hacker420[m]> does it happen on other msm8937 devices?
<barni2000[m]> land
<barni2000[m]> montana is fine
<barni2000[m]> i only have those two
<barni2000[m]> msm8940 also fine
<barni2000[m]> but i have only tested with santoni so maybe ugg can have this issue
<hacker420[m]> barni2000[m]: strange
<hacker420[m]> you'd think if montana is fine then cedric would work too
<hacker420[m]> maybe it's some dts/config thing?
<barni2000[m]> i have not got installed rootfs yet
<hacker420[m]> ah
<hacker420[m]> getting uart would be good
<hacker420[m]> since we could see where it locks up
<hacker420[m]> you could check if montana sees storage properly and rootfs
<barni2000[m]> i will
<hacker420[m]> btw, for this I'd just need to toss in --dumb-dcs in the options menu?
<hacker420[m]> btw, for this I'd just need to toss in --dumb-dcs in the options field?
<barni2000[m]> yes
<hacker420[m]> gonna remove the other panel for now as I have no way of testing it
<hacker420[m]> OPTIONS=(--dumb-dcs)
<barni2000[m]> hacker420[m]: leave it
<hacker420[m]> I'd need to add it
<hacker420[m]> pr opened
<hacker420[m]> so now to figure out that weirdness with the boot process
<hacker420[m]> like where is it even getting stuck is the question
<hacker420[m]> it clearly has to go into initramfs fine
<hacker420[m]> to go to debug-shell
<hacker420[m]> I suppose no one has uart to check/
<hacker420[m]> the problem is that if I remove the debug shell param it does actually seem to boot to something
<hacker420[m]> because I get a usb device
<hacker420[m]> but it's neither ssh nor telnet
<hacker420[m]> so probably stuck on splash
<hacker420[m]> hmmmmm
<hacker420[m]> maybe usb serial gadget could work?
<barni2000[m]> it was added to debug-shell
<barni2000[m]> the serial
<barni2000[m]> but it is not working after :(
<hacker420[m]> the config didn't have this enabled
<hacker420[m]> CONFIG_USB_G_SERIAL=y
<hacker420[m]> I'll see what it does
<hacker420[m]> it does work
<hacker420[m]> will need to capture the rest
<barni2000[m]> same stuff
<hacker420[m]> yeah
<hacker420[m]> that's what locks it up
<hacker420[m]> cmdline
<hacker420[m]> `--cmdline "console=ttyGS0,115200 fw_devlink=permissive earlycon PMOS_NOSPLASH"`\
<hacker420[m]> let me try to see what removing devlink=permissive does
<hacker420[m]> https://bpa.st/34WQ
<barni2000[m]> wait something is killing udev
<barni2000[m]> maybe it can be fixed with some kernel param idk
<barni2000[m]> * some kernel config param idk
<hacker420[m]> <barni2000[m]> "wait something is killing udev" <- yeah
<hacker420[m]> some undefined instruction
<hacker420[m]> but from where
<barni2000[m]> the greate question why I don't have this on msm8940
<barni2000[m]> only 8937 has this issue
<hacker420[m]> 🤔
<hacker420[m]> btw don't we want the interconnect enabled?
<hacker420[m]> or is that not necessary
<barni2000[m]> not necessary
<barni2000[m]> but we will enable it later aka_ sent it upstream
<barni2000[m]> it was useless without cpufreq
<hacker420[m]> so then we need to track down what kills udev
<hacker420[m]> and why doesn't it happen under debug-shell
<barni2000[m]> debug-shell not starting udev
<hacker420[m]> wait
<hacker420[m]> shouldn't it start udev to mount the boot partition if you wanted initramfs-extra?
<hacker420[m]> because it runs the device mapper
<hacker420[m]> ugh where do we even report this
<hacker420[m]> or how do we even debug it
<barni2000[m]> sdcard support is merged in lk2nd
<barni2000[m]> i need to do some clean ups and cluster init support also will be merged soon
<barni2000[m]> this means i will prepare a some device PR today for lk2nd
<hacker420[m]> <barni2000[m]> "debug-shell not starting udev" <- it still starts udev
<hacker420[m]> [ 3.271366] udevd[165]: starting eudev-3.2.14
<hacker420[m]> this just hangs so far
<hacker420[m]> gonna wait for a bit more
<hacker420[m]> ok let me reboot
<hacker420[m]> next reboot worked
<hacker420[m]> this is just weird
<hacker420[m]> now this
<hacker420[m]> https://bpa.st/7X2A
<hacker420[m]> [ 3.475857] udevd[159]: worker [166] failed while handling '/devices/platform/soc@0/7824900.mmc/mmc_host/mmc0/mmc0:0001/block/mmcblk0/mmcblk0p28'
<hacker420[m]> that's all with debug shell param
<hacker420[m]> ` "fw_devlink=permissive pmos.debug-shell PMOS_NOSPLASH console=ttyGS0,115200`
<hacker420[m]> think this serial gadget shell is broken in some way
<hacker420[m]> another oops
<hacker420[m]> undefined instruction
<hacker420[m]> I wonder if gimping this to 4 cores would help
<hacker420[m]> it's just strange
<hacker420[m]> why doesn't this happen on msm8940
<barni2000[m]> newer stuff idk
<barni2000[m]> 1.34 ghz works fine on msm 8940
<barni2000[m]> 8937 is rebooting from it
<barni2000[m]> Danct12: why santoni needs this ```lk2nd,match-cmdline = "* board_id=S88536*";``` when it have custom ```qcom,board-id```?
<Danct12[m]> barni2000[m]: there's three variants of redmi 4x
<barni2000[m]> still not an issue
<Danct12[m]> and qcom,board-id isnt a good way to identify a device
<Danct12[m]> s/good/reliable/
<barni2000[m]> msm8940+board-id will identify it
<barni2000[m]> land has same board-id but it has different msm-id
<barni2000[m]> qcom,msm-id = <QCOM_ID_MSM8937 0x0>;
<barni2000[m]> qcom,board-id = <0x1000b 1>, <0x2000b 1>
<barni2000[m]> Danct12[m]: until there is no other device with the same id it is fine
<barni2000[m]> panel match also will define it
<hacker420[m]> so how do I limit cores?
<barni2000[m]> maxcpus=4
<hacker420[m]> ok
<hacker420[m]> so when I tried this
<hacker420[m]> it dumped me to debug shell without the debug shell param
<hacker420[m]> udev can't find rng-core.ko
<hacker420[m]> then it just dumps itself to debug shell
<hacker420[m]> let me try to remove the hook
<hacker420[m]> nope
<hacker420[m]> still dumps itself to debug shell
<hacker420[m]> bunch of udev fails
<hacker420[m]> then it makes a log disk
<hacker420[m]> and then it enters debug shell
<hacker420[m]> do I need to reinstall rootfs or something?
<hacker420[m]> or does it just auto start itself even without a hook
semfault[m] has joined #msm8937-mainline
<barni2000[m]> there are couple udev fails what is not cause harm
<barni2000[m]> the main issue the unexpected ops
<hacker420[m]> yeah
<hacker420[m]> and the question is why it doesn't go through to rootfs
<hacker420[m]> doesn't even try to mount it
<hacker420[m]> ok so
<hacker420[m]> when I limit cpus I can get it to boot consistently
<hacker420[m]> and bring up panel
<hacker420[m]> still doesn'g mount rootfs though
<hacker420[m]> https://bpa.st/KNYA
<hacker420[m]> [ 3.643899] udevd[148]: ctx=0xffffae4e09a0 path=/lib/modules/6.10.0-msm8917/kernel/drivers/char/hw_random/rng-core.ko error=No such file or directory
<hacker420[m]> which would be weird...
<hacker420[m]> unless I need to either add it to initfs or try as built in
<hacker420[m]> let's try to build it in
<hacker420[m]> unless the other SoC packages pull in some crucial modules in initfs
<hacker420[m]> this got rid of that error
<hacker420[m]> doesn't change the fact it's still dumping itself into debug shell
<hacker420[m]> device mapper is enabled...
<hacker420[m]> it sees emmc
<hacker420[m]> hm
<hacker420[m]> can I somehow try to manually mount this?
<barni2000[m]> kpartx -a
<barni2000[m]> and after you can mount it from /dev/mapper
<hacker420[m]> barni2000[m]: do I point it to the whole partition?
<barni2000[m]> on the userdata yes
<hacker420[m]> ok so rootfs is there
<hacker420[m]> why doesn't it then run that automatically
<hacker420[m]> what would I do to try and boot it more then
<hacker420[m]> pmos_continue_boot?
<hacker420[m]> kpartx clearly mounts it fien
<hacker420[m]> *fine
<hacker420[m]> hacker420[m]: nope
<hacker420[m]> failed to remove acm.usb0
<hacker420[m]> then looping forever
<barni2000[m]> i will add ugg, ugglite later
<FieryFlames[m]> barni2000: you should try this on Montana and land ig https://github.com/msm8916-mainline/lk2nd/pull/412/commits/79463c2d1e1d5c258bc8f93e6c96430d98b8521d
<barni2000[m]> #ifdef TARGET_MSM8953? msm8953
<FieryFlames[m]> (add msm8952 to that ifdef)
<FieryFlames[m]> I didn't so msm8952 support in that pr because it's specifically for ali, but it should be simple to do on msm8952
<barni2000[m]> but enabling for every msm8953 device?
<FieryFlames[m]> yes.. this is the fix for ali
<barni2000[m]> btw msm8937 devices more sensitive
<FieryFlames[m]> every dts in affected device platform needs to have model
<FieryFlames[m]> barni2000[m]: give it a try, cuz it worked on cedric
<barni2000[m]> i think it will work but what about devices what does not need model
<FieryFlames[m]> barni2000[m]: irrelevant
<FieryFlames[m]> adding model shouldn't break other devices
<FieryFlames[m]> but it fixes devices that expect every dts to have model
<barni2000[m]> FieryFlames[m]: until we find one :D
<FieryFlames[m]> yes, until then it's fine
<FieryFlames[m]> consider that model is a required property per dt spec and legacy lk2nd set root model prop.. I would be surprised if we ever find one
<FieryFlames[m]> see if it fixes Montana and/or land. if so woohoo
<barni2000[m]> it breaks the matching
<FieryFlames[m]> how so, what device
<barni2000[m]> montana
<FieryFlames[m]> does it get to lk2nd at all?
<FieryFlames[m]> try setting model to "montana" in Montana's dts
<FieryFlames[m]> so it's selecting the wrong dtb
<FieryFlames[m]> but at least it's not crashing with multiple dtbs
<FieryFlames[m]> try model = "montana" like I said
<FieryFlames[m]> like how deen and ali do
<barni2000[m]> i have tried
<FieryFlames[m]> weird
<FieryFlames[m]> can you pull logs?
<barni2000[m]> ofc
<barni2000[m]> i can enable debug also
<barni2000[m]> I wonder which one is it [140] Found valid DTB with 3723 bytes total
<FieryFlames[m]> I wonder if it's cedric
<FieryFlames[m]> shrug
<barni2000[m]> i have commented out
<barni2000[m]> btw montana bootloader logs in pstore
<barni2000[m]> * btw montana's bootloader
<barni2000[m]> sadly now it is empty
<barni2000[m]> but annotate-ramoops-0 relates to bl
<FieryFlames[m]> fastboot oem log && fastboot get_staged /dev/stdout (or a file)
<barni2000[m]> i am not talking about lk2nd
<FieryFlames[m]> oh
<FieryFlames[m]> those are the logs I'd like to look at
<barni2000[m]> i have checked lk2nd log but nothing useful in it
<FieryFlames[m]> add some then xd
<barni2000[m]> i have enabled debug logging
<barni2000[m]> i have compiled it with DEBUG=2