| + vkoskiv (~vkoskiv@109-204-186-7.cust.valoonet.fi) | 00:11 | |
| - mjw (QUIT: Quit: zzz) (~mjw@gnu.wildebeest.org) | 00:16 | |
| + gachikuku (~gachikuku@kamil.gr) | 00:24 | |
| - chomwitt (QUIT: Quit: WeeChat 3.8) (~chomwitt@2a02:85f:9a08:a800:1ac0:4dff:fedb:a3f1) | 01:07 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 01:27 | |
| + potash5 (~potash@user/foghorn) | 01:33 | |
| - potash (QUIT: Ping timeout: 248 seconds) (~potash@user/foghorn) | 01:33 | |
| * potash5 -> potash | 01:37 | |
| - potash (QUIT: Quit: Ping timeout (120 seconds)) (~potash@user/foghorn) | 01:42 | |
| + potash (~potash@user/foghorn) | 01:42 | |
| josch | bkeys: you can list the blobs in the efi file using: objdump -h /boot/EFI/BOOT/bootaa64.efi | 02:12 |
|---|---|---|
| josch | bkeys: you can extract sections using: objcopy -O binary -j.cmdline /boot/EFI/BOOT/bootaa64.efi /tmp/outfile | 02:12 |
| josch | the section for the device tree is called .dtb | 02:13 |
| josch | it should look like this: https://paste.debian.net/1379605/ | 02:13 |
| - Gooberpatrol66 (QUIT: Quit: Konversation terminated!) (~Gooberpat@user/gooberpatrol66) | 02:41 | |
| bkeys | josch: Yeah, but what I'm finding now is that Fedora Rawhide actually has the reform device tree files in it; but it still doesn't boot for some mysterious reason | 03:02 |
| - nsc (QUIT: Ping timeout: 265 seconds) (~nicolas@43-98-142-46.pool.kielnet.net) | 03:12 | |
| + nsc (~nicolas@i5C74DCC1.versanet.de) | 03:14 | |
| josch | bkeys: i'll have something new for you to try tomorrow | 03:16 |
| josch | it's 3:00 AM over here so in around 6 hours :) | 03:16 |
| bkeys | Alright no problem, I know Fedora isn't your issue, but it'd be nice for me to have it | 03:16 |
| josch | for me, this is not about fedora at all | 03:16 |
| josch | but to create an image that edk2 can boot :) | 03:17 |
| bkeys | Yes I'm totally fine with testing that, I'm trying to get the Fedora ARM maintainer to debug this with me but he's an australian I'm pretty sure | 03:17 |
| bkeys | I'm fine to test for you tomorrow though | 03:17 |
| josch | nice, thank you! | 03:18 |
| - paperManu_ (QUIT: Ping timeout: 244 seconds) (~paperManu@72.10.128.164) | 03:39 | |
| + Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 04:24 | |
| - nsc (QUIT: Ping timeout: 244 seconds) (~nicolas@i5C74DCC1.versanet.de) | 05:02 | |
| + nsc (~nicolas@19-96-142-46.pool.kielnet.net) | 05:04 | |
| - wiedi (QUIT: Read error: Connection reset by peer) (~wiedi@ip5f581498.dynamic.kabel-deutschland.de) | 05:06 | |
| - RandyK (QUIT: Remote host closed the connection) (~RandyK@user/randyk) | 06:12 | |
| + RandyK (~RandyK@user/randyk) | 06:13 | |
| - aloo_shu (QUIT: Ping timeout: 272 seconds) (~aloo_shu@90.166.193.10) | 07:06 | |
| + aloo_shu (~aloo_shu@90.166.98.218) | 07:09 | |
| + gustav28 (~gustav@c-78-82-55-148.bbcust.telenor.se) | 08:22 | |
| josch | bkeys: new day new image: https://source.mnt.re/reform/reform-system-image/-/jobs/10908/artifacts/raw/pocket-reform-system-rk3588.img.gz | 08:48 |
| josch | i verified that this one has the rk3588 pocket reform device tree in the .dtb section of /boot/EFI/BOOT/bootaa64.efi | 08:49 |
| + wiedi (~wiedi@95.88.20.152) | 09:31 | |
| minute | josch: bkeys has a classic reform i think | 10:16 |
| minute | (or am i mistaken?) | 10:16 |
| + robin_ (~robin@user/terpri) | 10:24 | |
| + cobra_ (~cobra@user/Cobra) | 10:25 | |
| + Gooberpatrol_66 (~Gooberpat@user/gooberpatrol66) | 10:26 | |
| - aakast (QUIT: Ping timeout: 260 seconds) (~aakast@87-49-44-126-mobile.dk.customer.tdc.net) | 10:27 | |
| - BoostisBetter (QUIT: Ping timeout: 260 seconds) (4a410829d7@irc.cheogram.com) | 10:27 | |
| - cobra (QUIT: Ping timeout: 260 seconds) (~cobra@user/Cobra) | 10:27 | |
| - SavagePeanut (QUIT: Ping timeout: 260 seconds) (59eaa45ac7@irc.cheogram.com) | 10:27 | |
| - wiedi (QUIT: Ping timeout: 260 seconds) (~wiedi@95.88.20.152) | 10:27 | |
| - Gooberpatrol66 (QUIT: Ping timeout: 260 seconds) (~Gooberpat@user/gooberpatrol66) | 10:27 | |
| - vkoskiv (QUIT: Ping timeout: 260 seconds) (~vkoskiv@109-204-186-7.cust.valoonet.fi) | 10:27 | |
| - xha (QUIT: Ping timeout: 260 seconds) (~xha@user/xha) | 10:27 | |
| - Ar|stote|is (QUIT: Ping timeout: 260 seconds) (~linx@149.210.5.33) | 10:27 | |
| - chrcav (QUIT: Ping timeout: 260 seconds) (~chrcav@user/chrcav) | 10:27 | |
| - lanodan (QUIT: Ping timeout: 260 seconds) (~lanodan@2a01:e0a:d6:9930::35) | 10:27 | |
| - robin (QUIT: Ping timeout: 260 seconds) (~robin@user/terpri) | 10:27 | |
| + chrcav (~chrcav@user/chrcav) | 10:28 | |
| + lanodan (~lanodan@2a01:e0a:d6:9930::35) | 10:28 | |
| + vkoskiv (~vkoskiv@109-204-186-7.cust.valoonet.fi) | 10:28 | |
| + xha (~xha@user/xha) | 10:29 | |
| + Ar|stote|is (~linx@149.210.5.33) | 10:31 | |
| + wiedi (~wiedi@ip5f581498.dynamic.kabel-deutschland.de) | 10:34 | |
| + BoostisBetter (4a410829d7@irc.cheogram.com) | 10:45 | |
| - BoostisBetter (QUIT: Ping timeout: 260 seconds) (4a410829d7@irc.cheogram.com) | 11:00 | |
| - vkoskiv (QUIT: Ping timeout: 260 seconds) (~vkoskiv@109-204-186-7.cust.valoonet.fi) | 11:00 | |
| + vkoskiv (~vkoskiv@109-204-186-7.cust.valoonet.fi) | 11:00 | |
| + BoostisBetter (4a410829d7@irc.cheogram.com) | 11:15 | |
| + mjw (~mjw@gnu.wildebeest.org) | 11:29 | |
| - gustav28 (QUIT: Quit: Quit) (~gustav@c-78-82-55-148.bbcust.telenor.se) | 11:35 | |
| + aakast (~aakast@80-62-116-40-mobile.dk.customer.tdc.net) | 12:00 | |
| josch | minute: sorry you are right! I am maintaining a list of which IRC user has which device because I regularly get confused and I still had bkeys listed with A311D classic reform but irc history indeed says rk3588 classic reform. | 12:03 |
| josch | bkeys: then it's this one: https://source.mnt.re/reform/reform-system-image/-/jobs/10908/artifacts/raw/reform-system-rk3588.img.gz | 12:04 |
| josch | unless you need the dsi variant XD | 12:04 |
| + Core1951 (~aakast@80-62-116-34-mobile.dk.customer.tdc.net) | 12:16 | |
| + chomwitt (~chomwitt@2a02:85f:9a08:a800:1ac0:4dff:fedb:a3f1) | 12:16 | |
| - aakast (QUIT: Ping timeout: 248 seconds) (~aakast@80-62-116-40-mobile.dk.customer.tdc.net) | 12:17 | |
| minute | josch: i think bkeys needs this hdmi variant because edk2 isn't visible yet on dsi | 12:40 |
| - Ar|stote|is (QUIT: Quit: No Ping reply in 180 seconds.) (~linx@149.210.5.33) | 12:46 | |
| + Ar|stote|is (~linx@149.210.5.33) | 12:46 | |
| + paperManu (~paperManu@72.10.128.164) | 12:52 | |
| - Ar|stote|is (QUIT: Quit: No Ping reply in 180 seconds.) (~linx@149.210.5.33) | 13:16 | |
| + Ar|stote|is (~linx@149.210.5.33) | 13:21 | |
| grimmware | I wonder if we could maintain a community spreadsheet where people can add their setups along with software and hardware mods they’ve done, what issues they’re facing and what they’re working on | 13:44 |
| grimmware | By we I mean the community, not MNT | 13:44 |
| - chomwitt (QUIT: Ping timeout: 268 seconds) (~chomwitt@2a02:85f:9a08:a800:1ac0:4dff:fedb:a3f1) | 14:46 | |
| bkeys | minute, josch: I don't think I need hdmi variant because edk2 is visible on the internal display? | 14:57 |
| bkeys | Unless I'm misunderstanding | 14:57 |
| minute | bkeys: in your laptop, the internal display runs via hdmi converter | 14:58 |
| minute | bkeys: that's why you can see anything on screen with edk2. | 14:58 |
| bkeys | But yes for the record I have classic reform with rk3588 and edk2 on the emmc | 14:59 |
| bkeys | minute: So will josch's image work? | 15:00 |
| minute | bkeys: i don't know, but reform-system-rk3588 is the correct variant for your system. | 15:01 |
| bkeys | https://source.mnt.re/reform/reform-system-image/-/jobs/10908/artifacts/raw/reform-system-rk3588.img.gz | 15:01 |
| bkeys | Alright I'm downloading this one | 15:02 |
| josch | nice! | 15:02 |
| bkeys | josch: That image booted flawlessly I didn't have to go into EFI shell or anything | 15:49 |
| bkeys | josch: So since this boots, Fedora doesn't so it's not edk2's fault. I have to run my bike shop for just 2 hours today since it's Saturday. Can you show me what all you do to the kernel to make it work on the Reform2? Because the Rawhide kernel already has the proper reform2 .dtb files with it; so it must be something else | 15:51 |
| bkeys | When I get home I will do a serial connection to see if I can read further into this | 15:51 |
| josch | YEEEEES!!! \o/ | 15:52 |
| josch | magic? :D | 15:52 |
| + chomwitt (~chomwitt@2a02:85f:9a08:a800:1ac0:4dff:fedb:a3f1) | 15:54 | |
| bkeys | josch: Are there any reform2 patches that would interfere with the boot process? | 15:54 |
| bkeys | I'm at a sunk cost with this, I have waited to run Fedora on this thing for so long and spent so much time I will do whatever it takes at this point | 15:55 |
| josch | sunk cost fallacy? :D | 15:55 |
| bkeys | Yes | 15:55 |
| josch | bkeys: i hope i can be of help with respect to the efi thing | 15:55 |
| josch | bear in mind, that most magic comes from scripts and tools not written by me | 15:55 |
| josch | would it maybe help you to see the diff for reform-system-image which enables efi booting? | 15:56 |
| bkeys | Well, if I just boot Rawhide which has the DTB it will unpack the kernel then hang, the LED on the USB disk even turns off | 15:56 |
| bkeys | Sure? | 15:56 |
| bkeys | Well Fedora kernel already boots from EFI that's the default | 15:56 |
| josch | bkeys: you have the collabora patch stack with your kernel as well, right? | 15:56 |
| bkeys | But if I go into EFI shell and specify both DTB and the initramfs the LED doesn't die but the boot still hangs | 15:56 |
| bkeys | josch: I'm assuming Fedora does not have said patches? | 15:57 |
| josch | debian has neither | 15:57 |
| bkeys | I assume Reform kernel does? | 15:57 |
| josch | we apply the rk3588 patch stack from collabora to the debian linux kernel | 15:57 |
| bkeys | Link to said patches? | 15:57 |
| josch | and then enable some config options | 15:57 |
| bkeys | Link the info, I gotta go to the bike shop then I'll be back on (although I got a vintage adult trike I gotta start restoring) | 15:57 |
| josch | bkeys: here is the full patch stack we add on top of debian's: https://source.mnt.re/reform/reform-debian-packages/-/tree/main/linux/patches6.14 | 15:58 |
| josch | the rk3588 specific patches are in the rk3588-mnt-reform2 folder | 15:58 |
| josch | and then you need some config options which are at the bottom here: https://source.mnt.re/reform/reform-debian-packages/-/blob/main/linux/config | 15:59 |
| josch | some of these only make sense with the collabora patches | 15:59 |
| josch | bkeys: i would suspect that you can boot fedora successfully once you patch the fedora kernel to support rk3588 | 15:59 |
| josch | bkeys: note also, that the rk3588-mnt-reform2 dtb in vanilla linux is *not* the same that we use in Debian | 16:00 |
| josch | bkeys: the dtb in upstream linux is the subset which was required for u-boot. I think it was contributed to linux upstream by bluerise aka Patrick Wildt (u-boot & bsd developer i think) | 16:02 |
| josch | i am maintaining the diff from upstream linux rk3588 dtb to the one used by MNT repos here: https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/89/diffs | 16:03 |
| - bkeys (QUIT: Ping timeout: 272 seconds) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 16:05 | |
| josch | minute: so... efi boot via edk2 works now apparently -- does that mean anything for the system images? Since efi needs a fat32 partition and since fat32 cannot do symlinks this unfortunately is incompatible with flash-kernel and the symlinks it creates in /boot -- is efi booting any important to you or do we stick with u-boot and extlinux.conf? | 16:05 |
| josch | minute: i'm also in karlsruhe next saturday, so we might run into each other maybe :) | 16:06 |
| + bkeys (~Thunderbi@66.110.201.50) | 16:19 | |
| - bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@66.110.201.50) | 16:26 | |
| Zaba | I’d say trying to support efi boot officially would just further complicate the already pretty expansive testing matrix, even though in theory it is kind of neat to be able to do it | 16:27 |
| Zaba | if all supported variants could consistently use uboot with bootstd/extlinux.conf that would already be a massive win - and a more robust starting point for perhaps adding efi support in the future | 16:28 |
| josch | Zaba: extlinux.conf everywhere is where we are right now | 16:29 |
| + bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 16:31 | |
| Zaba | only if people go through the process of updating their device and making sure there’s no stray boot.scr around, right? | 16:32 |
| josch | Zaba: no, upgrading will not switch your boot method -- i'm talking about fresh installations from the system images provided by MNT and on reform.d.n | 16:32 |
| Zaba | right, which means you can’t really say that is where you’re at right now, unless you discount the actual devices in the field, i.e., the important ones :) | 16:34 |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@38-146-94-247.echocast.zone) | 16:39 | |
| + bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 16:39 | |
| josch | Zaba: okay, but if you define "where we are right now" like that then we will always be stuck with boot.scr because we are not going to automatically convert users away from that via an apt upgrade | 16:42 |
| - bkeys (QUIT: Ping timeout: 248 seconds) (~Thunderbi@38-146-94-247.echocast.zone) | 16:44 | |
| - Ar|stote|is (QUIT: Ping timeout: 248 seconds) (~linx@149.210.5.33) | 16:49 | |
| + Ar|stote|is (~linx@149.210.5.33) | 16:54 | |
| + bkeys (~Thunderbi@66.110.201.50) | 16:54 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 17:04 | |
| + bkeys (~Thunderbi@66.110.201.50) | 17:05 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50) | 17:07 | |
| + bkeys (~Thunderbi@66.110.201.50) | 17:07 | |
| - bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@66.110.201.50) | 17:12 | |
| + aakast (~aakast@87-49-43-63-mobile.dk.customer.tdc.net) | 17:20 | |
| - Core1951 (QUIT: Ping timeout: 268 seconds) (~aakast@80-62-116-34-mobile.dk.customer.tdc.net) | 17:24 | |
| + bkeys (~Thunderbi@66.110.201.50) | 17:44 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 17:51 | |
| + bkeys (~Thunderbi@66.110.201.50) | 17:51 | |
| + bkeys1 (~Thunderbi@38-146-94-247.echocast.zone) | 17:56 | |
| - bkeys (QUIT: Ping timeout: 265 seconds) (~Thunderbi@66.110.201.50) | 18:00 | |
| - bkeys1 (QUIT: Ping timeout: 265 seconds) (~Thunderbi@38-146-94-247.echocast.zone) | 18:04 | |
| + bkeys (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 18:09 | |
| bkeys | Alright I am back | 18:11 |
| bkeys | josch: Do I blindly apply all patches? | 18:30 |
| josch | bkeys: "blindly"? | 18:30 |
| bkeys | Is there any patch in your link that I don't apply? | 18:30 |
| bkeys | Some say MERGED | 18:30 |
| bkeys | Do I omit those? | 18:30 |
| bkeys | https://source.mnt.re/reform/reform-debian-packages/-/tree/main/linux/patches6.14/rk3588-mnt-reform2 | 18:31 |
| josch | bkeys: MERGED means that they are merged with linux upstream but those patches are for kernel 6.14 and we are already beyond 6.15, so 6.14 is already "old news" :) | 18:31 |
| bkeys | Yeah I was thinking I wanted to do at least 6.15 because then the reform2 .dtb was included, but you said they don't match anyway | 18:32 |
| bkeys | So I can get rid of any patch that says MERGED? | 18:32 |
| josch | bkeys: if you checked that they are actually applied in your tree, sure | 18:34 |
| josch | bkeys: for the dtb, you can just grab the one from the source.mnt.re git | 18:35 |
| bkeys | I will | 18:35 |
| josch | if you want to use 6.15 you will have to rebase the patches first | 18:35 |
| josch | and then instead of rebasing the 6.14 patches you might want to grab the latest stack from collabora git instead | 18:36 |
| bkeys | I'll just stick with 6.14 I have to mess with the .dtb files anyway | 18:36 |
| bkeys | Are these patches identical to collabara's patches? | 18:37 |
| josch | bkeys: most of them are. We named them so that you can easily identify them with the collabora git next to it. | 18:38 |
| josch | The patches that start with 00 are those from collabora and those that sort after are from MNT | 18:38 |
| bkeys | Alright let me sit here and think about what version I want exactly | 18:38 |
| bkeys | Preferably I could pick an LTS kernel and just worry about that version of it | 18:38 |
| josch | in that case, 6.12 is lts and we have a patch stack for that as well | 18:39 |
| josch | i am building that one for reform.debian.net and can verify whether it indeed works with rk3588 classic reform tomorrow | 18:40 |
| bkeys | I can't really make a decision, ideally it'd be nice and integrated and I can have whatever kernel version I want but I don't know packaging on that level | 18:53 |
| bkeys | As cool as maintaining it sounds, I really want to just get on with using Fedora on my Reform, I don't want maintaining it to be a huge burden | 18:55 |
| bkeys | I think for now I will do 6.14 because that's what Fedora 42 uses, and I will branch out from there once that's verified to work and solve the problem | 18:58 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 19:00 | |
| - Ar|stote|is (QUIT: Quit: No Ping reply in 180 seconds.) (~linx@149.210.5.33) | 19:10 | |
| + Ar|stote|is (~linx@149.210.5.33) | 19:15 | |
| - vkoskiv (QUIT: Ping timeout: 244 seconds) (~vkoskiv@109-204-186-7.cust.valoonet.fi) | 19:23 | |
| - Ar|stote|is (QUIT: Quit: No Ping reply in 180 seconds.) (~linx@149.210.5.33) | 19:29 | |
| + Ar|stote|is (~linx@149.210.5.33) | 19:34 | |
| - Ar|stote|is (QUIT: Quit: No Ping reply in 180 seconds.) (~linx@149.210.5.33) | 20:02 | |
| + Ar|stote|is (~linx@149.210.5.33) | 20:08 | |
| + Core1951 (~aakast@net-93-65-57-194.cust.vodafonedsl.it) | 20:35 | |
| - aakast (QUIT: Read error: Connection reset by peer) (~aakast@87-49-43-63-mobile.dk.customer.tdc.net) | 20:35 | |
| + bkeys (~Thunderbi@134.22.115.162) | 20:48 | |
| + SavagePeanut (59eaa45ac7@irc.cheogram.com) | 20:56 | |
| + aakast (~aakast@87-49-43-63-mobile.dk.customer.tdc.net) | 21:25 | |
| - Core1951 (QUIT: Ping timeout: 252 seconds) (~aakast@net-93-65-57-194.cust.vodafonedsl.it) | 21:28 | |
| josch | bkeys: i'm afraid that maintaining this patch stack is quite a bit of time investment at least for debian -- i would imagine it to be similar for fedora | 21:43 |
| bkeys | Well if I get a working system I don't really care if the kernel updates beyond LTS ones | 21:44 |
| bkeys | I'm gonna document all my steps of doing this by having it done via script | 21:57 |
| josch | nice, i like having my documentation be a script :) | 21:59 |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 22:18 | |
| vagrantc | josch: so, reform-debian-packages contains more linux/patches6.12/ that are not git am-able ... i do not know appropriate authorship, but could list the files ... or i could propose a pull request with just dummy authorship info | 22:25 |
| vagrantc | some of them are easy enough | 22:25 |
| vagrantc | working on trying to get the patches to work on 6.12.31+ (an old version worked fine up until 6.12.30) | 22:26 |
| vagrantc | upstream backported changes to drivers/gpu/drm/rockchip/rockchip_drm_vop2.c that seem to be different/partial implementations of similar things | 22:28 |
| vagrantc | 6.14 reached EOL already ... | 22:29 |
| kfx | I don't know why they even bother with 'stable' releases | 22:31 |
| vagrantc | rk3588-mnt-reform2/0029-WIP-drm-rockchip-vop2... might just require dropping the parts that dont apply | 22:31 |
| kfx | three-month eol does nobody any good | 22:31 |
| bkeys | Ugh, I hate adding the config file | 22:31 |
| bkeys | Fedora doesn't like me just adding the config | 22:31 |
| vagrantc | rk3588-mnt-reform2/4001-mnt-rk35880dyal-hdmi-vop2-pll needs some work | 22:32 |
| vagrantc | there's a reason i tend to go for LTS releases ... although even those tend to get some surprises | 22:34 |
| vagrantc | rk3588-mnt-reform2/0016-vop2-Add-clock-resets-support.patch also needs a fairly trivial rebase | 22:35 |
| vagrantc | but other than that ... but for the most part they apply to 6.12.33 | 22:35 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@134.22.115.162) | 22:40 | |
| - aakast (QUIT: Read error: Connection reset by peer) (~aakast@87-49-43-63-mobile.dk.customer.tdc.net) | 22:53 | |
| + aakast (~aakast@net-93-65-57-194.cust.vodafonedsl.it) | 22:53 | |
| josch | vagrantc: if you have a list, then i can add some dummy headers listing minute as author | 23:00 |
| josch | vagrantc: alternatively, if you have git format-patch files i also take those via email or pastebin :) | 23:00 |
| josch | vagrantc: you read my u-boot-menu community forum post from a few days ago? The problem is that if u-boot-menu is run via a trigger on a system that does not have the dtb symlink yet, then it will not add the fdtfile entry to extlinux.conf because the flash-kernel trigger which creates the dtb files is ordered *after* the u-boot-menu trigger | 23:01 |
| + bkeys (~Thunderbi@134.22.115.162) | 23:07 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@134.22.115.162) | 23:07 | |
| vagrantc | josch: hah. just went through and added some headers | 23:07 |
| + bkeys (~Thunderbi@134.22.115.162) | 23:07 | |
| josch | vagrantc: if you have a diff of that, i take it :) | 23:07 |
| vagrantc | josch: yeah, sounds like similar symptoms ... could be different cause | 23:07 |
| josch | yes, for example i don't understand how this situation occurred for abortretryfail who had an existing install | 23:08 |
| vagrantc | josch: would you prefer a pastebin or a proper pull request? i'm nearly to the pull request already... | 23:08 |
| josch | and in that case, the dtb symlink should never disappear, no? | 23:08 |
| josch | vagrantc: whatever you prefer :) | 23:08 |
| vagrantc | josch: well, in the case of mobian, the dtb was not a symlink but a directory ... | 23:08 |
| josch | oh how can that happen? | 23:08 |
| josch | vagrantc: i also wish that u-boot-menu would print more on stderr so that it would be easier to see what is going on just from reading /var/log/apt/term.log | 23:09 |
| - bkeys (QUIT: Remote host closed the connection) (~Thunderbi@134.22.115.162) | 23:09 | |
| vagrantc | josch: because mobian ... did something that *looked* similar, but was actually different | 23:10 |
| vagrantc | josch: i am surprised to see it outside of mobian, though | 23:10 |
| josch | vagrantc: you heard that MNT wants to produce a tablet thing? We need to get mobian with its touch interface running on that one. :) | 23:11 |
| vagrantc | current mobian works fine ... they've fixed it | 23:12 |
| vagrantc | but yeah, curious how the tablet will pan out | 23:12 |
| vagrantc | honestly, there is probably not anything left in mobian you couldn't just do in mnt reform repositories ... nearly everything is in debian | 23:12 |
| josch | vagrantc: i'm not touching mobian yet because i think it would not make much sense on devices without a touch screen, right? | 23:13 |
| vagrantc | josch: at this point it is mostly just cutom kernels and a few metapackages ... maybe a few configuration packages ... nothing really different from what mnt/reform is doing | 23:13 |
| vagrantc | oh, looks like i am not set up to push to source.mnt.re repositories ... sounds like i send you a diff for this one :) | 23:15 |
| josch | okay! :) | 23:15 |
| vagrantc | josch: https://paste.debian.net/plain/1379690 | 23:18 |
| vagrantc | josch: some i just used the attribution information from when they were added ... which is probably wrong as we all know these were probably added by minute :) | 23:18 |
| josch | vagrantc: haha yes, but i can easily just s/josch/minute/ in your diff no problem :) | 23:19 |
| vagrantc | i swear i've done merge requests or whatever before on source.mnt.re... will see if i can set this up for when i *hopefully* get it rebased against 6.12.33 | 23:20 |
| josch | vagrantc: https://source.mnt.re/reform/reform-debian-packages/-/commit/0bfb985268e89f85deea384cd264b4787a0ea856 thank you! | 23:21 |
| josch | i'll create a follow-up commit for 6.14 in a similar way | 23:21 |
| vagrantc | cool | 23:22 |
| vagrantc | i swear we have done this dance at least once before :) | 23:22 |
| josch | vagrantc: wow look, magic: https://source.mnt.re/reform/reform-debian-packages/-/commit/4dfa8c1d3b3339738ec55dd19a5c07f305c696b1 :D | 23:22 |
| josch | vagrantc: we did! | 23:23 |
| vagrantc | :) | 23:23 |
| josch | my hope is that by adding it to 6.14 as well at least most of these changes will survive the next rebase of the patch stack (to 6.15) | 23:23 |
| vagrantc | teaching minute about git format-patch might help too :) | 23:24 |
| josch | nah if it just takes a few drive-by commits from us to fix issues like this, i'm 100% fine with minute spending their time on all the other todo things of the day :D | 23:25 |
| vagrantc | true enough :) ... all the same, it is a small change probably | 23:26 |
| josch | yup | 23:26 |
| josch | i should do the 6.15 rebase... i didn't yet because there is no linux6.15 branch from collabora | 23:27 |
| josch | i pinged sebastian reichel about this without effect | 23:27 |
| vagrantc | oh, wonder if they have rebased against more recent 6.12.x ? | 23:27 |
| josch | i think i'll just use the rockchip-devel branch | 23:28 |
| josch | vagrantc: nope | 23:28 |
| vagrantc | rather than me clumsily trying to do this :) | 23:28 |
| josch | i'm also interested in 6.12 because it's the trixie kernel | 23:28 |
| vagrantc | right ... at least in git debian is already up to 6.12.33 for trixie | 23:28 |
| vagrantc | pretty sure the thing that is breaking it was done by collabora upstream | 23:29 |
| josch | yes and that will kept being bumped during the trixie lifetime | 23:29 |
| vagrantc | everything was fine up till 6.12.31 ... pesky backports | 23:29 |
| josch | upstream is already at 6.16 rc1... | 23:31 |
| vagrantc | got tired of reverting the updates in Guix back to 6.12.30 ... | 23:31 |
| vagrantc | and they are about to drop 6.14.x and switch to 6.15... so ... here goes! | 23:31 |
| josch | XD | 23:31 |
| - RandyK (QUIT: Remote host closed the connection) (~RandyK@user/randyk) | 23:38 | |
| + RandyK (~RandyK@user/randyk) | 23:39 | |
| josch | hehe "Initial support Cadence MHDP8501(HDMI/DP) for i.MX8MQ" is going to get a v21 :) | 23:39 |
| vagrantc | well ... i made all the patches apply ... but partly just by removing parts of the patches :/ ... it did look like the problem was something was backported that might actually fix the issue | 23:45 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!