- GNUmoon (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 00:05 | |
+ GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 00:05 | |
+ S0rin (~S0rin@user/s0rin) | 00:24 | |
- S0rin (QUIT: Ping timeout: 256 seconds) (~S0rin@user/s0rin) | 00:33 | |
- Christoph_ (QUIT: Remote host closed the connection) (~Christoph@p54bf6eb5.dip0.t-ipconnect.de) | 00:44 | |
+ S0rin (~S0rin@user/s0rin) | 00:46 | |
+ MajorBiscuit (~MajorBisc@2a02:a461:129d:1:193d:75d8:745d:e91e) | 01:18 | |
- sl (QUIT: Quit: Lost terminal) (~sl@beastie.sdf.org) | 01:20 | |
- mtm (QUIT: Ping timeout: 268 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 02:03 | |
- MajorBiscuit (QUIT: Ping timeout: 240 seconds) (~MajorBisc@2a02:a461:129d:1:193d:75d8:745d:e91e) | 02:30 | |
+ mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 04:09 | |
- xktr (QUIT: Ping timeout: 256 seconds) (~xktr@37.120.147.5) | 04:52 | |
+ xktr (~xktr@37.120.147.5) | 04:53 | |
+ sl (~sl@beastie.sdf.org) | 05:53 | |
- xktr (QUIT: Ping timeout: 240 seconds) (~xktr@37.120.147.5) | 06:03 | |
+ xktr (~xktr@37.120.147.6) | 06:05 | |
- sbp (QUIT: *.net *.split) (~sbp@tea.infomesh.net) | 06:35 | |
- joeyh (QUIT: *.net *.split) (~joeyh@kitenet.net) | 06:35 | |
- flowy (QUIT: *.net *.split) (~flowy@2a01:4f8:c0c:1a8f::1) | 06:35 | |
- skalk_ (QUIT: *.net *.split) (~skalk@vond.sysret.de) | 06:35 | |
+ sbp (~sbp@tea.infomesh.net) | 06:35 | |
+ joeyh (joeyh@kitenet.net) | 06:35 | |
+ skalk (~skalk@vond.sysret.de) | 06:36 | |
+ flowy (~flowy@2a01:4f8:c0c:1a8f::1) | 06:36 | |
- xktr (QUIT: Ping timeout: 260 seconds) (~xktr@37.120.147.6) | 08:04 | |
+ xktr (~xktr@37.120.147.5) | 08:11 | |
- mrus (QUIT: Ping timeout: 240 seconds) (~mrus@gateway/tor-sasl/mrus) | 08:12 | |
+ mrus (~mrus@gateway/tor-sasl/mrus) | 08:15 | |
- mrus (QUIT: Remote host closed the connection) (~mrus@gateway/tor-sasl/mrus) | 08:25 | |
+ mrus (~mrus@gateway/tor-sasl/mrus) | 08:26 | |
- GNUmoon (QUIT: Ping timeout: 240 seconds) (~GNUmoon@gateway/tor-sasl/gnumoon) | 08:53 | |
- xktr (QUIT: Ping timeout: 246 seconds) (~xktr@37.120.147.5) | 09:03 | |
- Lewis[m] (QUIT: Quit: Bridge terminating on SIGTERM) (~lewislewi@2001:470:69fc:105::e363) | 09:19 | |
- scops (QUIT: Quit: Bridge terminating on SIGTERM) (~scopstchn@2001:470:69fc:105::8da) | 09:19 | |
- indefini[m] (QUIT: Quit: Bridge terminating on SIGTERM) (~indefinim@2001:470:69fc:105::1e2a) | 09:19 | |
+ xktr (~xktr@37.120.147.5) | 09:20 | |
+ scops (~scopstchn@2001:470:69fc:105::8da) | 09:23 | |
+ Lewis[m] (~lewislewi@2001:470:69fc:105::e363) | 09:26 | |
+ indefini[m] (~indefinim@2001:470:69fc:105::1e2a) | 09:26 | |
+ leonardo (~leonardo@user/leonardo) | 09:28 | |
- sbp (QUIT: Changing host) (~sbp@tea.infomesh.net) | 09:43 | |
+ sbp (~sbp@apache/doge/sbp) | 09:43 | |
+ oomono (uid328183@id-328183.tinside.irccloud.com) | 10:01 | |
- xktr (QUIT: Ping timeout: 260 seconds) (~xktr@37.120.147.5) | 10:04 | |
+ xktr (~xktr@37.120.147.6) | 10:05 | |
+ MajorBiscuit (~MajorBisc@86.88.79.148) | 10:45 | |
- dj-death (QUIT: Ping timeout: 240 seconds) (~djdeath@vps-8659ed31.vps.ovh.net) | 10:49 | |
- xktr (QUIT: Ping timeout: 246 seconds) (~xktr@37.120.147.6) | 11:23 | |
+ mjw (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 11:24 | |
+ xktr (~xktr@37.120.147.5) | 11:40 | |
- mjw (QUIT: Quit: Leaving) (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 12:00 | |
+ mjw (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 12:28 | |
+ Christoph_ (~Christoph@p54bf6380.dip0.t-ipconnect.de) | 13:02 | |
- scops (QUIT: Quit: User was banned) (~scopstchn@2001:470:69fc:105::8da) | 13:05 | |
- Lewis[m] (QUIT: Quit: User was banned) (~lewislewi@2001:470:69fc:105::e363) | 13:05 | |
- indefini[m] (QUIT: Quit: User was banned) (~indefinim@2001:470:69fc:105::1e2a) | 13:05 | |
- xktr (QUIT: Ping timeout: 260 seconds) (~xktr@37.120.147.5) | 13:43 | |
- mtm (QUIT: Ping timeout: 272 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 14:04 | |
+ adjtm (~adjtm@4.red-83-52-193.dynamicip.rima-tde.net) | 14:05 | |
+ xktr (~xktr@37.120.147.6) | 14:15 | |
- xktr (QUIT: Quit: leaving) (~xktr@37.120.147.6) | 14:39 | |
+ scops (~scopstchn@2001:470:69fc:105::8da) | 14:48 | |
+ indefini[m] (~indefinim@2001:470:69fc:105::1e2a) | 14:51 | |
+ Lewis[m] (~lewislewi@2001:470:69fc:105::e363) | 14:51 | |
- chomwitt (QUIT: Ping timeout: 256 seconds) (~chomwitt@2a02:587:dc18:da00:e2ec:eb52:4039:9bfe) | 14:55 | |
+ chomwitt (~chomwitt@athedsl-352218.home.otenet.gr) | 14:56 | |
+ xktr (~xktr@37.120.147.6) | 15:04 | |
- chomwitt (QUIT: Read error: Connection reset by peer) (~chomwitt@athedsl-352218.home.otenet.gr) | 15:12 | |
- MajorBiscuit (QUIT: Ping timeout: 260 seconds) (~MajorBisc@86.88.79.148) | 15:23 | |
+ MajorBiscuit (~MajorBisc@86-88-79-148.fixed.kpn.net) | 15:24 | |
- adjtm (QUIT: Ping timeout: 256 seconds) (~adjtm@4.red-83-52-193.dynamicip.rima-tde.net) | 15:32 | |
- xktr (QUIT: Ping timeout: 256 seconds) (~xktr@37.120.147.6) | 15:44 | |
+ xktr (~xktr@37.120.147.186) | 15:51 | |
+ mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 16:09 | |
- qbit (QUIT: Quit: WeeChat 3.3) (~qbit@h.suah.dev) | 16:14 | |
- xktr (QUIT: Ping timeout: 260 seconds) (~xktr@37.120.147.186) | 16:44 | |
+ qbit (~qbit@h.suah.dev) | 16:54 | |
+ xktr (~xktr@37.120.147.186) | 17:11 | |
- xktr (QUIT: Quit: leaving) (~xktr@37.120.147.186) | 17:23 | |
- MajorBiscuit (QUIT: Ping timeout: 246 seconds) (~MajorBisc@86-88-79-148.fixed.kpn.net) | 17:24 | |
- Ar|stote|is (QUIT: Ping timeout: 272 seconds) (~linx@149-210-29-113.mobile.nym.cosmote.net) | 17:52 | |
- mjw (QUIT: Quit: Leaving) (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 18:43 | |
+ xktr (~xktr@37.120.147.186) | 19:16 | |
+ adjtm (~adjtm@2a0c:5a80:1c01:3a00:b499:a8d6:4d3e:78e8) | 19:25 | |
+ vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 20:23 | |
+ buckket (~buckket@pdp8.buckket.org) | 21:08 | |
josch | minute: my current patch to flash-kernel calls the imx8mq based reform "MNT Reform 2" is that okay? Does that make sense with having future alternative CPU modules in mind? What will the naming scheme be? | 21:41 |
---|---|---|
josch | Context: I'm preparing a merge request with "MNT Reform 2" and "MNT Reform 2 HDMI" for the flash-kernel package and it would be nice if that naming was final and we don't have to change it later when more CPU board options for the reform become available. | 21:44 |
minute | josch: that's a very good question | 21:47 |
minute | maybe you could call it "MNT Reform (i.MX8MQ)" and "MNT Reform (i.MX8MQ) HDMI" | 21:48 |
minute | the 2 is more like an internal thing that end users don't really see | 21:48 |
vagrantc | it should generally be whatever is in the upstream device tree, no? | 21:48 |
josch | Yes. The dtb is called freescale/imx8mq-mnt-reform2.dtb | 21:49 |
vagrantc | the "model" property in the devicetree itself | 21:50 |
josch | That would be "MNT Reform 2" | 21:51 |
vagrantc | that's what flash-kernel uses to distinguish between different boards | 21:51 |
josch | I thought it uses the value of the Machine: field? | 21:51 |
vagrantc | it compares the device-tree model property with the Machine: field in flash-kernel's database ... so ... yes? :) | 21:52 |
vagrantc | at least, that's what it uses to detect which Machine entry to use ... | 21:52 |
vagrantc | if you're forcing which machine entry, of course it doesn't matter | 21:53 |
josch | Hrm... I'm not quite sure I fully understand yet. Currently we are using this patch: https://source.mnt.re/reform/reform-debian-packages/-/blob/main/patches/flash-kernel | 21:54 |
josch | And then write the desired Machine (HDMI or not) into /etc/flash-kernel/machine | 21:55 |
josch | vagrantc: does that look correct? | 21:55 |
vagrantc | i see. yeah, that works also, though it detects the default from the running device-tree if you don't force it through /etc/flash-kernel/machine | 21:55 |
vagrantc | i *think* some of those values are extraneous, but it's been a while since i've paid too much attention to flash-kernel | 21:56 |
josch | vagrantc: I think we want to force it because the user needs to be able to switch between normal and HDMI, no? | 21:56 |
vagrantc | sure | 21:57 |
vagrantc | I don't think you need Boot-Kernel-Path Boot-Initrd-Path U-Boot-Kernel-Address U-Boot-Initrd-Address | 22:00 |
vagrantc | since you're using bootscr.uboot-generic | 22:00 |
vagrantc | unless your u-boot doesn't support raw initrd ... | 22:01 |
josch | vagrantc: Thanks, good to know! I'll test it once the world isn't broken anymore due to the recent upload of python3-defaults :) | 22:07 |
vagrantc | i've mostly moved away from flash-kernel to using u-boot-menu generated "extlinux.conf" instead, as it presents a simple boot menu and is a little simpler to set up, but has a little less flexibility | 22:11 |
vagrantc | e.g. most of the arm64 debian-installer hooks are either EFI or extlinux.conf ... don't think we have any boot scripts there anymore | 22:12 |
josch | vagrantc: extlinux works on architectures other than amd64, i386 and x32? | 22:13 |
vagrantc | wish i could figure out why i can't get mainline u-boot to work anymore... | 22:14 |
vagrantc | josch: it's stupidly named extlinux.conf .... it's actually just a boot configuration file format that u-boot knows how to read | 22:14 |
josch | ah okay | 22:14 |
vagrantc | i saw some patches for u-boot to support yet another newer even better bestesteverever format for booting ... it did in fact sound better. | 22:16 |
vagrantc | though, typically on newish boards u-boot supports boot scripts, the syslinux-style configuration and using it's EFI implementation ... so a whole new format ... well ... hrm. | 22:17 |
josch | The u-boot-menu package description suggests that flash-kernel is still needed to prepare the correct dtb. | 22:18 |
vagrantc | only if you have a split /boot partition | 22:20 |
josch | We do. | 22:20 |
vagrantc | well then :) | 22:20 |
vagrantc | there's also an example in u-boot-menu to copy the .dtb files into /boot | 22:21 |
vagrantc | which is helpful if you might boot a given image on different hardware | 22:21 |
vagrantc | but if you know what hardware you're running on, then it's not needed | 22:22 |
vagrantc | or rather, flash-kernel is fine | 22:22 |
josch | I forgot why we need a separate /boot partition but found the reason in the chat logs. Phew... Now documented so that future-me doesn't have to grep chat logs again. :) | 22:29 |
sigrid | was it "filesystems not supported by u-boot"? :) | 22:32 |
sigrid | fde? | 22:32 |
vagrantc | nvme? | 22:32 |
josch | Full disk encryption is one reason. The other is, that when the root filesystem is on another partition than the boot medium, then we need to mount the partition containing the kernel to /boot or otherwise upgrades to the kernel will take no effect. But if we don't have a separate /boot partition, then mounting the SD-Card partition to /boot will result in /boot/boot placing kernel, initramfs and dtb at | 22:36 |
josch | the wrong location. | 22:36 |
vagrantc | ACTION squints | 22:37 |
josch | vagrantc: do you see a problem? | 23:52 |
vagrantc | what's placing the kernel/dtb/initrd at the /boot/boot/ location ... sounds buggy | 23:55 |
vagrantc | oh, is it flash-kernel? are you creating a vmlinuz and initrd.img with u-boot headers (often called uImage or uInitrd) ? | 23:57 |
josch | vagrantc: If I don't have a separate /boot partition, then the files u-boot needs will be in a subdirectory of / called boot. If I mount that partition at /boot then I will now have /boot/boot | 23:57 |
josch | But I need to be able to modify those files or otherwise kernel upgrades will be without effect. | 23:58 |
vagrantc | why can't you just rely on your kernel packages to install kernel updates? | 23:59 |
josch | they do | 23:59 |
josch | But they have to install those updates onto the SD-Card | 23:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!