| + mlarkin (~mlarkin@047-036-115-056.res.spectrum.com) | 00:33 | |
| bkeys | jfred: A fellow ebike enjoyer I see | 01:01 |
|---|---|---|
| - minute (QUIT: Server closed connection) (~mntirc@softboy.mntmn.com) | 01:55 | |
| + minute (~mntirc@softboy.mntmn.com) | 01:55 | |
| - mtm (QUIT: Ping timeout: 246 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 02:04 | |
| jfred | bkeys: that's right :P | 02:05 |
| jfred | Though I don't like that they tend to be very proprietary | 02:05 |
| jfred | (We need someone like MNT for e-bikes haha) | 02:06 |
| - XYZ (QUIT: Ping timeout: 246 seconds) (~XYZ@78-80-114-131.customers.tmcz.cz) | 02:25 | |
| - scops (QUIT: Server closed connection) (~scopstchn@2001:470:69fc:105::8da) | 03:01 | |
| + scops (~scopstchn@2001:470:69fc:105::8da) | 03:01 | |
| - robin (QUIT: Ping timeout: 246 seconds) (~robin@user/terpri) | 03:06 | |
| violet | ugh for real i got an e-bike once with an awful charge controller that deep discharged the battery while i had it in storage for like half a year or a year | 03:18 |
| violet | and then the battery was dead dead | 03:18 |
| violet | and they dont sell that battery anymore on their website they were like "email us if you need the old battery model" | 03:18 |
| violet | i did not email them and decided to get a different bike | 03:19 |
| - nsc (QUIT: Ping timeout: 250 seconds) (~nicolas@193-97-142-46.pool.kielnet.net) | 03:25 | |
| + bluerise_ (~bluerise@pc19f889e.dip0.t-ipconnect.de) | 03:25 | |
| - bluerise (QUIT: Ping timeout: 260 seconds) (~bluerise@p5b0acd89.dip0.t-ipconnect.de) | 03:27 | |
| + nsc (~nicolas@200-98-142-46.pool.kielnet.net) | 03:27 | |
| noam | sigrid: silly question, how hot does your Reform get under 9front usually? e.g. cputemp | 03:35 |
| noam | I'm seeing e.g. CPU temp of 72 whilst idling, and the thing is _hot_ | 03:36 |
| sigrid | 56C iirc | 03:53 |
| sigrid | maybe your heatsink is a bit off | 03:54 |
| sigrid | is that plain 9front or your mod? | 03:54 |
| noam | the latter | 03:58 |
| noam | CPU base load is ~zero, but there's ~500 context switches / sysclals per second | 03:59 |
| sigrid | maybe see what that is | 04:03 |
| sigrid | although why would it be that high (temp) anyway | 04:03 |
| noam | If it's constantly waking up / going to sleep / waking up? | 04:09 |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 04:10 | |
| noam | ...I have absolutely no idea what's causing those. Disconnected ethernet, killed bar+riow+reform/shortcuts, no impact | 04:12 |
| sigrid | i don't think that's often enough | 04:12 |
| sigrid | see running time in ps or something | 04:12 |
| noam | I am, there's nothing there other than paqfs, usbd, kb, cwfs, rio, and stats | 04:12 |
| sigrid | which one is highest? | 04:14 |
| noam | kb | 04:14 |
| sigrid | ok | 04:14 |
| noam | 0:29 0:26; nothing else is even at 0:10 | 04:14 |
| sigrid | which chip is your trackball? | 04:14 |
| noam | That's... also odd, I haven't exactly typed much into it, and IIRC that's minutes of CPU time... | 04:14 |
| noam | No idea, I can check | 04:14 |
| sigrid | or was it the keyboard... lemme remember | 04:15 |
| noam | I know nusb/kb's the HID driver, so... one of the two :P | 04:16 |
| noam | Trackball's an AVR chip, dunno which one | 04:17 |
| sigrid | ok, it was trackball, i remembered | 04:17 |
| sigrid | ok, you need to update its fw | 04:17 |
| noam | Ah, okay, I've been meaning to do that anyways | 04:17 |
| noam | ThanK! | 04:17 |
| sigrid | just do it for all devices there | 04:18 |
| sigrid | the bug was the fw would continuously send the same reports over and over | 04:19 |
| noam | ahhh | 04:19 |
| noam | I need to do this so pmctl will work anyways :P | 04:19 |
| noam | didn't realize there was a more urgent reason to do so | 04:19 |
| noam | Cells are a bit warm, but they *were* just charging, sooooo probably fine? | 04:22 |
| noam | I flipped the LPCP switch on and plugged a microUSB cable into the board and it's not showing up :/ | 04:56 |
| noam | Hopefully it's just a bad cable | 04:57 |
| noam | yep! :) | 04:58 |
| noam | aannnnnnd now the LPC won't respond. Yikes | 05:13 |
| noam | neat, prebuilt 20_R3.bin works | 05:20 |
| josch | noam: thank you for your feedback! You were faster than me in trying those. :D | 05:22 |
| noam | ? | 05:23 |
| noam | josch: whatcha talking about? :) | 05:23 |
| josch | noam: when you do circle, s on your keyboard -- does it show the correct version in the OLD screen? | 05:25 |
| noam | sigrid: Also, hm, how do I update the trackball firmware? | 05:25 |
| noam | silly me, there's probably a port if I just take the trackball out | 05:26 |
| noam | josch: not going to check until after I've flashed the other firmwares | 05:27 |
| noam | the handbook website is 404ing :/ | 05:28 |
| noam | Anyone have a mirror? | 05:28 |
| josch | https://mntre.com/reform2/handbook/parts.html#trackball-firmware works for me? | 05:28 |
| josch | which url is 404 for you? | 05:28 |
| noam | Ah, ddg gives shit results, noted. | 05:30 |
| noam | also: I'm an idiot, the trackball is a USB DEVICE | 05:30 |
| noam | I don't need to disconnect it to flash it lol, glad I actually RTFMed first | 05:30 |
| - jomo (QUIT: Server closed connection) (~jomo@user/jomo) | 05:31 | |
| + jomo (~jomo@user/jomo) | 05:31 | |
| noam | wait, do I have to press the reset button on the trackball WHILE THE REFORM IS RUNNING to falsh it?? | 05:39 |
| josch | yes | 05:43 |
| josch | if you don't reset it, it will keep being a usb mouse | 05:43 |
| josch | but you want it to be a "Atmel DFU bootloader" | 05:43 |
| noam | I didn't realize turning on the reform would reset the trackball, but of course it does, that's what powers it | 05:45 |
| noam | it wasn't on to *notice* the button press before | 05:45 |
| noam | fuck | 05:45 |
| + XYZ (~XYZ@37-48-50-214.nat.epc.tmcz.cz) | 05:55 | |
| noam | josch: nah, I don't want it to be an Atmel DFU bootloader :P | 06:00 |
| noam | I want it to be an ATmega32U2 DFU :P | 06:01 |
| noam | more seriously: dagnabbit, endpoint isn't showing up??? | 06:02 |
| noam | Oh, I need to boot linux to do this don't I | 06:04 |
| noam | fudge | 06:04 |
| noam | That means no trackball updates for m | 06:04 |
| noam | e | 06:04 |
| noam | Guess I have to implement nusb/dfu first :/ | 06:05 |
| - c-keen[m] (QUIT: Server closed connection) (~c-keenner@2001:470:69fc:105::2:8760) | 06:44 | |
| + c-keen[m] (~c-keenner@2001:470:69fc:105::2:8760) | 06:44 | |
| + robin (~robin@user/terpri) | 06:50 | |
| + bgs (~bgs@212-85-160-171.dynamic.telemach.net) | 07:13 | |
| noam | josch: firmware version is indeed 20230703 :) | 07:32 |
| josch | awesome, thanks! | 07:38 |
| - ec0 (QUIT: Ping timeout: 246 seconds) (~ec0@vps-446f4f39.vps.ovh.ca) | 07:58 | |
| - murph[m] (QUIT: Server closed connection) (~murphhope@2001:470:69fc:105::d564) | 09:22 | |
| + murph[m] (~murphhope@2001:470:69fc:105::d564) | 09:22 | |
| - klardotsh (QUIT: Ping timeout: 246 seconds) (~klardotsh@98.97.35.74) | 09:31 | |
| - XYZ (QUIT: Ping timeout: 250 seconds) (~XYZ@37-48-50-214.nat.epc.tmcz.cz) | 09:33 | |
| + MajorBiscuit (~MajorBisc@2001:1c00:31c:8400:f184:4168:559b:d91b) | 09:43 | |
| + XYZ (~XYZ@78-80-113-63.customers.tmcz.cz) | 09:45 | |
| + ec0 (~ec0@vps-446f4f39.vps.ovh.ca) | 10:12 | |
| - XYZ (QUIT: Remote host closed the connection) (~XYZ@78-80-113-63.customers.tmcz.cz) | 10:25 | |
| + XYZ (~XYZ@78-80-113-63.customers.tmcz.cz) | 10:38 | |
| josch | Boostisbetter: did you already flash your lpc? | 12:12 |
| josch | Boostisbetter: I created a script which helps you do that by giving you step by step instructions about what to do and also automatically chooses the right device, mounts and flashes it without you having to manually edit /dev/sdX in flash.sh: https://source.mnt.re/reform/reform/-/merge_requests/45 | 12:12 |
| - mjw (QUIT: Killed (NickServ (GHOST command used by mark_!~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae))) (~mjw@gnu.wildebeest.org) | 12:23 | |
| * mark_ -> mjw | 12:23 | |
| - MajorBiscuit (QUIT: Ping timeout: 240 seconds) (~MajorBisc@2001:1c00:31c:8400:f184:4168:559b:d91b) | 12:37 | |
| + MajorBiscuit (~MajorBisc@c-001-005-040.client.tudelft.eduvpn.nl) | 12:39 | |
| josch | minute: I forgot what we agreed on for reform-boundary-uboot. Would you like me to send all my changes via MR or just the important ones and I do commits related to the buildsystem or CI for example directly to the main branch? | 12:52 |
| josch | Since the old artifacts are gone we need another tag and I could take care of that. | 12:53 |
| josch | bluerise_: the only thing still missing from mainline uboot is display support, right? | 12:54 |
| minute | josch: for me it's fine if you send me only important changes via MR and otherwise commit directly | 12:55 |
| josch | okay! | 12:56 |
| Boostisbetter | Josch: thanks! I haven done it yet! Got busy last night! | 13:26 |
| bluerise_ | josch: yes, and my PCIe patch which depends on the power domain fixup that I didn't yet finish up because someone needs to do refcounting | 13:58 |
| * bluerise_ -> bluerise | 13:58 | |
| bluerise | https://github.com/bluerise/u-boot/commits/mnt | 13:59 |
| bluerise | https://github.com/bluerise/u-boot/commit/1b1e651e84321519fb703aaeda8f79f664ac5ceb | 13:59 |
| bluerise | technically that diff isn't great because a lot is hardcoded that should be done in proper drivers | 14:00 |
| - mtm (QUIT: Ping timeout: 240 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 14:02 | |
| Ar|stote|is | minute: will I get another email when items have shipped? will it have a tracking number? how much is ~2weeks most of the time? | 14:04 |
| josch | huh... so I updated my LPC today with the binary from source.mnt.re and since then I get random bursts like this my dmesg | 14:33 |
| josch | https://paste.debian.net/1284910/ | 14:33 |
| josch | and during those 2 minutes my internal reform keyboard stops working | 14:33 |
| josch | has anybody seen this effect? | 14:34 |
| + mark_ (~mjw@gnu.wildebeest.org) | 14:37 | |
| minute | josch: huuuh... so sounds like a hiccup of the UART connection between keyboard and lpc | 14:45 |
| minute | Ar|stote|is: hmm, AFAIK we shipped your order and you should have gotten a tracking code a while ago | 14:45 |
| minute | Ar|stote|is: yeah, your order should arrive tomorrow | 14:46 |
| josch | hrm... maybe my variable renaming broke something because i failed to find+replace properly in 064b49c2c34076cfa2f5ffe99a26559471b9d934 | 14:55 |
| josch | i shall observe this further and go back to before that commit if this behaviour continues | 14:55 |
| + sva (~sva@vm-187.askja.de) | 15:00 | |
| - bgs (QUIT: Remote host closed the connection) (~bgs@212-85-160-171.dynamic.telemach.net) | 15:25 | |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 16:02 | |
| - Boostisbetter (QUIT: Ping timeout: 246 seconds) (4a410829d7@irc.cheogram.com) | 16:06 | |
| josch | minute: i noticed that your gitlab is configured to create merge commits when merging merge requests. Is that behaviour intended by you in favor of fast-forward merges without additional merge commits? It can be changed under "Settings -> Merge requests -> Merge method" for each project. | 16:32 |
| - [tj] (QUIT: Server closed connection) (~tj]@188.166.156.159) | 16:55 | |
| + [tj] (~tj]@188.166.156.159) | 16:55 | |
| + Boostisbetter (4a410829d7@irc.cheogram.com) | 17:24 | |
| minute | josch: would this make things easier? | 17:49 |
| minute | now gonna continue working on a311d integration | 17:52 |
| Boostisbetter | minute: did you notice that Purism's Librem 5 was upgraded and is now using the 4gb variant of the SoC the Reform has been using all along. Feels like an Apple upgrade move to me. Surely it was possible to go with this chip out of the game, instead of the 3gb variant. | 18:04 |
| c-keen[m] | How do I boot without using the boot script in U-Boot? | 18:07 |
| c-keen[m] | The boot script contains the wrong dtb filename which is missing a hdmi part in it's name | 18:07 |
| c-keen[m] | I don't have a MMC card at my disposal atm otherwise I would boot from there | 18:07 |
| minute | Boostisbetter: i noticed that it was upgraded to a very interesting price and also USA flags :D | 18:08 |
| minute | meanwhile, our products have always been assembled in our studio... | 18:08 |
| minute | c-keen[m]: how about using `sudo reform-display-config dual`? | 18:09 |
| minute | c-keen[m]: (with --emmc probably?) | 18:09 |
| c-keen[m] | How when I cannot get into Linux? | 18:10 |
| minute | c-keen[m]: ah, you mean it doesn't boot | 18:10 |
| minute | c-keen[m]: you can do `setenv fdtfile ...` | 18:10 |
| c-keen[m] | Yes | 18:10 |
| minute | c-keen[m]: and then `boot` | 18:10 |
| minute | c-keen[m]: where `...` would be the .dtb that you want | 18:11 |
| c-keen[m] | The first message has been lost I think | 18:11 |
| minute | c-keen[m]: my first message? it was > you can do `setenv fdtfile ... | 18:11 |
| c-keen[m] | What's before 'and then boot' ? | 18:11 |
| minute | c-keen[m]: setenv fdtfile my-favorite-dtb-file.dtb | 18:12 |
| c-keen[m] | Ah it is confusing as there is fdtfile, fdt_file and fdtpath in the environment | 18:13 |
| c-keen[m] | Yes that works | 18:13 |
| minute | cool | 18:13 |
| minute | Boostisbetter: also yes. the 3gb was just the nxp reference design i think | 18:15 |
| minute | at least the nxp imx8mq evk also had 3gb | 18:15 |
| minute | the 4th GB was past the 32-bit address space. maybe they had problems with that at first | 18:16 |
| minute | this was also the first 64-bit i.mx if i'm not mistaken | 18:16 |
| minute | i.mx8qm was arguably first, but had a lot of technical issues, so i.mx8mq was made as a stopgap | 18:17 |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 18:19 | |
| c-keen[m] | minute so to remedy the situation I should rerun he reform-display-config script? | 18:24 |
| minute | c-keen[m]: yep | 18:27 |
| c-keen[m] | ok, thanks for your patience | 18:27 |
| minute | no problem! | 18:36 |
| minute | josch: vagrantc: if i am in the process of building a new kernel package for debian, and testing it on the target... how can i also cross-rebuild the corresponding initramfs? for example, i might need it to load more modules than just those for imx8mq | 18:37 |
| minute | now i have to compile in at least the MMC drivers to get a bootable system | 18:37 |
| minute | hmm, very strange failure when building the kernel package one more time, maybe i have to delete and remake the unshare-root-fs? | 18:41 |
| minute | Exception: ('python3.11', '-c', 'import importlib; print(importlib.util.MAGIC_NUMBER)') failed with status code 1 | 18:41 |
| minute | dpkg: error processing package python3-minimal (--configure): | 18:41 |
| c-keen[m] | also something I noticed: In uboot the right shift key does not seem to work, it repeats keystrokes... | 19:02 |
| minute | c-keen[m]: funny | 19:04 |
| c-keen[m] | also: the reform-check script says, that it cannot download the raw/flash.bin from a u-boot pipeline due to hash mismatches | 19:06 |
| minute | c-keen[m]: yeah, i have to do some tag shenanigans on the gitlab | 19:07 |
| c-keen[m] | I see | 19:07 |
| minute | ah, we have to update these https://source.mnt.re/reform/reform-tools/-/blob/main/bin/reform-check#L102 | 19:10 |
| minute | c-keen[m]: hmm, perhaps you need to update reform-tools? can you try that? | 19:12 |
| josch | minute: re git merge: which strategy to pick is personal preference i think. Personally, I see little point in cluttering the "git log" output with merge commits if though the commit applies directly on top of HEAD. | 19:12 |
| c-keen[m] | minute manually? | 19:12 |
| josch | c-keen[m]: there was a problem when source.mnt.re got moved to a different servers and some artifacts are now 404. I already created a new git tag for reform-boundary u-boot and now only need to make a new upload of reform-tools. | 19:13 |
| josch | c-keen[m]: i can ping you once i'm done -- maybe in a few hours? | 19:13 |
| c-keen[m] | sure! I am not going anywhere | 19:14 |
| josch | minute: the initramfs is built as part of reform-system-image. To build the initramfs you need a chroot environment that matches the final system (that's what the reform-debian-packages script does). So you can either do this natively on the reform (but i guess it doesn't even boot to a serial console?) or you have a chroot directory on your machine and (assuming that machine is not arm64) you use | 19:15 |
| josch | qemu-user binfmt to emulate arm64 transparently. | 19:15 |
| - MajorBiscuit (QUIT: Quit: WeeChat 3.6) (~MajorBisc@c-001-005-040.client.tudelft.eduvpn.nl) | 19:19 | |
| josch | c-keen[m]: this should fix your problem https://source.mnt.re/reform/reform-tools/-/merge_requests/40 | 19:20 |
| josch | c-keen[m]: once minute merges that, the reform-debian-packages pipeline has to get triggered by minute, then the pipeline has to pass and then the cronjob uploading the result to the mirror has to run | 19:21 |
| c-keen[m] | understood | 19:23 |
| minute | josch: gotcha. glad you're back! maybe you have an idea why sbuild is broken right now (with unshare) | 19:28 |
| minute | josch: it fails when it wants to setup python3-minimal | 19:28 |
| minute | i've tried to inspect this by extracting the mmdebstrap-made tarball, but when entering the chroot iwth mmdebstrap --unshare-helper, something is wrong with the permissions | 19:29 |
| minute | i.e. the root user in the chroot can't do root things (like apt update) | 19:29 |
| josch | minute: did you extract the tarball as root? | 19:30 |
| minute | josch: tried that as well | 19:30 |
| josch | minute: is the error this: result = self._execute('import importlib; print(importlib.util.MAGIC_NUMBER)', version) | 19:31 |
| minute | josch: yes | 19:31 |
| josch | minute: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040316 | 19:31 |
| josch | minute: python in unstable is broken right now | 19:31 |
| minute | ah weird, i was looking in the wrong package's or suites bug tracker i guess | 19:32 |
| minute | josch: is there anything i can do to continue working on the kernel stuff or do i have to work on another project today until it is fixed? | 19:33 |
| josch | minute: other than waiting for this to be fixed you could do s/unstable/testing/ everywhere | 19:34 |
| josch | it's a very common problem that anybody doing stuff with unstable has their stuff broken for multiple days sometimes | 19:34 |
| minute | josch: ok, this selects another kernel version though, right? | 19:34 |
| minute | so i have to be lucky that the patches work? | 19:34 |
| josch | yes | 19:35 |
| minute | ok, will try | 19:35 |
| josch | testing has 6.3.7-1 and unstable has 6.3.11-1 | 19:35 |
| minute | ah, that's not so bad | 19:35 |
| josch | yes, it might just work :) | 19:35 |
| josch | (but i had the patches fail to apply even with just the minor version changing in the past) | 19:35 |
| minute | :0 | 19:36 |
| minute | looks like i'm lucky with the patches | 19:40 |
| minute | ok, looks like the build process is working now, phew | 19:42 |
| minute | josch: regarding the mmdebstrap chroot extraction, my guess is i'm missing some tar options like --owner, --numeric-owner or sth like that | 19:43 |
| minute | when extracting just like that, everything is owned by my normal user | 19:43 |
| josch | minute: yes, when you have a tarball with files owned by user X and you extract is as the non-root user, the files end up owned by your user | 19:46 |
| vagrantc | minute: regarding the initramfs ... unless the initramfs configuration has been tweaked, it should install most kernel modules out of the box ... | 19:46 |
| josch | but you also likely never want to extract that tarball (i'm the author of both mmdebstrap and sbuild and never saw a need to extract it) | 19:46 |
| josch | minute: for the imx8mq we had to add several modules on top | 19:47 |
| vagrantc | minute: you can add more by adding some scripts in various places under /etc/initramfs-tools or /usr/share/initramfs-tools/ | 19:47 |
| josch | it's /etc/initramfs-tools/modules | 19:49 |
| josch | that's what mkuserland.sh in reform-system-image does | 19:49 |
| - cmahns (QUIT: Changing host) (8fe824803c@2604:bf00:561:2000::10cd) | 19:55 | |
| + cmahns (8fe824803c@user/cmahns) | 19:55 | |
| minute | ok, i'm still trying to wrap my head around the moving parts. my development process is like this: 1. i'm rebuilding the kernel package. 2. i'm manually grafting the kernel package on top of an sd card with a release version of reform-system-image. (i.e. i am using dpkg -x on the root partition) | 19:56 |
| minute | probably i should rather somehow find a clean way to chroot into the sd card but also mount the /boot partition into it | 19:56 |
| minute | and then dpkg -i the kernel package and then rebuild the initramfs somehow? (update-initramfs?) | 19:57 |
| minute | always recreating the whole reform-system-image and reflashing it would take too long for my dev process | 19:57 |
| minute | rebuilding the debian kernel also already takes much much longer than just rebuilding my development kernel. probably because it always have to start from zero | 19:58 |
| josch | minute: dpkg -x is not enough. That just extracts the kernel. What you want is to "dpkg -i linux-image*.deb" which installs the kernel *and* will rebuild your initramfs. | 20:07 |
| josch | ah i should read the whole backlog :) | 20:07 |
| josch | so, you don't need "dpkg -x" but just "dpkg -i" | 20:08 |
| josch | if what you have is the sd-card with the arm64 system on it, don't forget to mount /boot into it before chrooting into it | 20:08 |
| josch | if you don't mount /boot, then the initramfs doesn't get placed into the correct location | 20:09 |
| josch | minute: when i bisected the kernel i did something similar and i also did not re-run the reform-system-image script as that would naturally take too long | 20:09 |
| josch | yes, rebuilding the debian kernel takes longer because it starts from zero, because it needs to install all dependencies first, because it builds way more modules than needed and because it builds more than the kernel itself (docs, tools etc...) | 20:10 |
| minute | josch: ok, so we are on the same page regarding the kernel testing procedure. now for the rebuilding: it's not possible to cache a build step there, yes? | 20:18 |
| josch | minute: there are two main ways to speed up the build process | 20:23 |
| josch | minute: either, if you want to continue building in an isolated environment like sbuild to minimize interference from the outside there is ccache (but i've never used it when cross-building) | 20:23 |
| josch | minute: or you ditch sbuild and cross-build it straight from an unpacked source directory by invoking debian/rules targets manually | 20:24 |
| josch | but the second option is highly depending on what source package you are building and i'm not familiar enough with the linux packaging to tell you what to run | 20:24 |
| minute | hmmm ok, so maybe ccache is an option for later | 20:26 |
| minute | now trying to install the kernel package on chrooted sdcard | 20:26 |
| josch | i've often found answers to my Debian kernel building related questions here: https://kernel-team.pages.debian.net/kernel-handbook/index.html | 20:26 |
| josch | but i didn't read the whole thing yet so i cannot tell you whether that document contains the answer to your questions | 20:27 |
| minute | josch: this seems applicable https://wiki.debian.org/sbuild#Using_.22ccache.22_with_sbuild | 20:28 |
| minute | another little challenge: we'll need to adjust "bootargs" (kernel command line) for quirks of the different socs. for example, on a311d, the serial console is ttyAML0, not ttymxc0, and we need pci=pci_bus_perf. (this one might actually be interesting for imx as well) | 20:29 |
| josch | minute: the bootargs are set in /etc/default/flash-kernel | 20:35 |
| josch | this is something that the reform-system-image script will have to do different depending on the SoM | 20:35 |
| minute | ok | 20:36 |
| josch | it already supplies the special values for imx8mq | 20:36 |
| josch | minute: until reform-system-image does the right thing, just edit your /etc/default/flash-kernel and the next time you install a kernel, flash-kernel will write out boot.scr with the updated bootargs | 20:38 |
| minute | josch: cool, thanks | 20:48 |
| minute | > A start job is running for /dev/mmcblk1p1 | 20:48 |
| minute | ok, fstab will need to be tuned as well i think (?) | 20:49 |
| josch | if you are running from sd-card then no | 20:50 |
| minute | josch: well, on a311d, sd card is /dev/mmcblk0 :D | 20:50 |
| josch | ah then yes :) | 20:52 |
| minute | it boots and i can log in, so progress | 20:53 |
| josch | \o/ | 20:53 |
| josch | it's on my todo list to use a UUID in /etc/fstab instead of a path like /dev/mmcblk1p1 -- that way this will work independen on how the kernel names the sd-card or emmc | 20:54 |
| minute | ah nice | 20:54 |
| - jacobk (QUIT: Ping timeout: 264 seconds) (~quassel@47-186-122-163.dlls.tx.frontiernet.net) | 20:54 | |
| minute | josch: is the fstab managed by a reform-tool nowadays? just wondering where i should patch when shipping this | 20:55 |
| minute | or is it just created once during reform-system-image build? | 20:56 |
| josch | minute: nothing in /etc should be managed by reform-tools as everything in /etc should be admin maintained and not package maintained | 20:56 |
| minute | ah! interesting | 20:56 |
| josch | minute: the reform-system-image script fills /etc/fstab | 20:56 |
| minute | ok cool, so for now i can patch that for an initial a311d-reform-system-image | 20:57 |
| - mjw (QUIT: Killed (NickServ (GHOST command used by mark_!~mjw@gnu.wildebeest.org))) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 21:00 | |
| * mark_ -> mjw | 21:00 | |
| + mark_ (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 21:00 | |
| minute | on a311d, emmc and sd card device name are exactly swapped vs imx... whyyy | 21:05 |
| minute | emmc is mmcblk1 | 21:05 |
| josch | maybe a udev rule can be used to turn those around again? | 21:07 |
| josch | this might also be a lesson to stop relying on /dev/sd* naming and to use /dev/disk/by-id/* instead | 21:08 |
| josch | (see my latest merge request for lpc flash.sh) | 21:08 |
| josch | or by using the filesystem UUID instead | 21:09 |
| + jacobk (~quassel@2600:100c:b25f:3b8a:42c5:a261:b8c5:2121) | 22:55 | |
| - jacobk (QUIT: Ping timeout: 246 seconds) (~quassel@2600:100c:b25f:3b8a:42c5:a261:b8c5:2121) | 23:13 | |
| + jacobk (~quassel@52.128.53.110) | 23:16 | |
| - XYZ (QUIT: Ping timeout: 246 seconds) (~XYZ@78-80-113-63.customers.tmcz.cz) | 23:36 | |
| - jacobk (QUIT: Ping timeout: 264 seconds) (~quassel@52.128.53.110) | 23:56 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!