Saturday, 2024-11-09

rinigus@b100dian: morning! we are missing few techpack kernel modules as it is. for jolla devices, they added them as submodules. I think I will try to add them into local manifest instead, as it is done with sony aosp.09:03
riniguswe may end up using slightly different android manifests, so it is ok to try.09:04
T42<b100dian> interesting. This is needed even for AOSP build right? Still haven't updated my build to r67, maybe I'll do that now10:32
T42<b100dian> rinigus: so after checking out https://github.com/sonyxperiadev/local_manifests I just fetch that kernel-extras.xml between them 🤔?10:36
rinigus@b100dian: I have added local manifests step to https://github.com/sailfishos-sony-nagara/main/wiki/HADK-for-Sony-Nagara-devices10:38
rinigusslowly writing it as I am progressing10:38
rinigusbut that local_maniufests would be used with regular repo sync, after you cloned into empty directory droid-hal-sony-nagara10:38
riniguswhich has kernel as submodule10:39
rinigusas mal warned about r67, I am using older aosp14 (r34) - default for hybris and others.10:40
rinigusright now its mainly to get boot images. was updating hadk using your kernel howto description and just adding the env vars that we use10:41
T42<b100dian> rinigus: thanks for documenting the steps, I will probably follow along tonight and edit as neccesary - for now I have only started an unattended r67 build because curiosity13:03
T42<b100dian> I would also like to clean up the hybris-boot diff a bit more (rndis.usb0 stuff), I will just push a cleanup commit now instead of re-writing history13:04
rinigus@b100dian: these docs are gonna save us in future :) . good idea, let's keep history now13:09
rinigusI am going to setup env at obs - for now in my own repo. later, when it works, we can copy it to regular devel/testing13:10
rinigusgood idea to try r67!13:10
malI should try booting that r67 android15:54
rinigusI have some weird error at OBS, probably just missing some typo in packaging. I am adding nagara config in the same way as it was for tama. config repo for nagara at https://github.com/sailfishos-sony-nagara/droid-config-sony-nagara16:40
rinigusOBS error for package https://build.sailfishos.org/package/show/home:rinigus:nagara/droid-config-xqct5416:41
riniguspasted at: https://paste.mozilla.org/vKSgZzcT/raw16:41
riniguspatterns package works: https://build.sailfishos.org/package/show/home:rinigus:nagara/patterns-sailfish-device-configuration-xqct5416:41
rinigussimilar conf for tama works: https://build.sailfishos.org/package/show/nemo:devel:hw:sony:tama:aosp10/droid-config-h821616:42
rinigussurely something trivial, just getting blind over here16:42
rinigushmm, maybe found something while building locally. no newline at the end of one file. checking ...16:47
T42<b100dian> maybe _just service file missing branch or revision?16:47
T42<b100dian> that sounds more like it16:48
rinigusnope - was a missing new line at the end of included file. fix: https://github.com/sailfishos-sony-nagara/droid-config-sony-nagara/commit/54c98038d73bde762c44aaa5e26373b4ae89aca316:50
riniguswe are building :)16:51
rinigus... and failing somewhere else16:51
T42<b100dian> Why am I so tempted to just build the mic image and start debugging booting after you've made obs build pass :D16:59
malwhat header*.inc stuff seems odd, just makes things more complicated imo17:17
malrinigus: also is that missing something? you can see here the patterns being included https://github.com/mer-hybris/droid-config-sony-murray/blob/master/rpm/droid-config-xqcc54.spec but I can't see that being done in your repo17:19
malor am I missing something17:20
malwait, you have those patterns as specs here https://github.com/sailfishos-sony-nagara/droid-config-sony-nagara/tree/main/rpm which is very odd17:21
malit seems the whole thing is for some reason done in totally different way that usually so difficult to debug17:22
rinigusmal: I'll simplify it a bit and then see if I can find the error. It's coming from 6 tama devices.17:35
rinigusmal: streamlined the config and made it close to zambezi. almost there, just issue is at obs since  repo location is not common18:53
riniguswould it be possible to get nemo:devel:hw:sony:nagara?18:54
rinigusand set us with b100dian as maintainers?18:54
rinigusalso, later issue was due to absence of repo / device definitions in ssu. that had to be added for KS18:55
rinigus@b100dian: mic image will be close. but we need your device hal images, at least that I had for different tama devices18:58
riniguslet's also see what will happen without system images. currently I hope that we can just flash boot and few more to get it working and keeping system / vendor other images the same18:59
T42<b100dian> rinigus: I was thinking to flash boot and untar .stowaways inside recovery and go from there.19:07
T42<b100dian> Even with your hals, like an upside down HADK guide19:07
T42<b100dian> Twisted HADK19:07
rinigusmaybe it work. I'll be finishing soon for today, just want to add version packages as well19:08
T42<b100dian> that is, I would not go to lvm build just yet, I know this is probably the end goal19:12
T42<b100dian> and something like a github action as used here https://github.com/sailfishos-on-sake/Release/blob/main/.github/workflows/build.yml19:14
rinigus@b100dian: sounds good!19:16
rinigus@b100dian: version packaged and we are now missing boot images. and for that, parameters like these are needed: https://github.com/mer-hybris/droid-hal-img-boot-sony-zambezi/blob/master/rpm/droid-hal-pdx235-img-boot.spec#L519:23
rinigustemporarily we can probably comment out droid-system* as a requirement19:25
T42<b100dian> I don't _think_ we need to build vendor_boot19:25
T42<b100dian> I can look up the parameters from my unpacking last week, but I am surprised that this is needed in spec files19:26
rinigus@b100dian: hmm, it could be related to aosp packaging. but I don't know for sure. as for system, that is actually required by hal packages. so maybe that's needed19:28
rinigusas for vendor_boot, I guess it is built at obs from the same boot img package19:29
T42<b100dian> no, it is another image, the vendor_boot (as is vendor_dklm) - but regarding aosp packaging I think you're right19:30
T42<b100dian> it is the first time I see a repo called hybris-initrd :)19:30
T42<b100dian> mal: can you shed some light? Those mkbootimg parameters can come just by echoing the mkbootimg command while building, right? say, wrapping it in .. $(warning ...)19:31
rinigus@b100dian: when everything will be resolved, it could be easier to do lvm in the end :)19:35
T42<b100dian> rinigus: agreed. But curious, do you use lvm when debugging ?19:38
rinigusdon't remember anymore :)19:38
rinigusthat's where we can drop droid-system requirement: https://github.com/sailfishos-sony-nagara/droid-hal-sony-nagara/blob/main/rpm/droid-hal-common.inc#L2319:47
malrinigus: https://build.sailfishos.org/project/show/nemo:devel:hw:sony:nagara20:03
malrinigus: for obs you can use project config to ignore dependencies, no need to comment them out20:03
rinigusmal: thank you very much! I will look into it tomorrow20:06
mal@b100dian easiest way to get mkbootimg params is to grab the android boot.img from the adaptation build and unpack it with https://android.googlesource.com/platform/system/tools/mkbootimg/+/refs/heads/main (clone the whole repo or just grab the .py files and gki folder) then run unpack_bootimg.py --boot_img boot.img --format=mkbootimg20:06
malrinigus: something like this in project config should work: Ignore: package_you_are_building:dependency_to_ignore20:09
T42<b100dian> mal: thanks20:23
T42<b100dian> mal: but this have_custom_vendor_boot and other have_custom defines are needed because you're also patching those images for e.g. zambezi?  https://github.com/mer-hybris/droid-hal-sony-zambezi/blob/master/rpm/droid-hal-common.inc21:04
malcustom_vendor_boot is for making images smaller i.e. only having needed things in vendor_boot.img21:17
maland there is plan to include recovery in vendor_boot at some point21:18
T42<b100dian> ah, that is a great plan indeed :)21:29
T42<b100dian> but my question is - do we need it today for nagara (1/5 IV) or we can just set those have_custom to false/0?21:29
T42<b100dian> wait, isn't recovery just one byte (or even bit) different from boot init?21:30
T42<b100dian> I seem to remember that there's a kernel cmdline parameter when you enter recovery on these newer bootloaders21:30
T42<b100dian> (I'm not seeing this now on 5IV though)21:33

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!