| + ggoes (~gregf@fsf/staff/ggoes) | 00:08 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 00:30 | |
| - chomwitt (QUIT: Ping timeout: 264 seconds) (~chomwitt@2a02:587:dc0c:c200:b8b0:dc:a578:bfaa) | 01:09 | |
| - mtm (QUIT: Ping timeout: 264 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 02:02 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:20) | 03:24 | |
| - ajr (QUIT: Quit: WeeChat 3.6) (~ajr@user/ajr) | 03:28 | |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 04:09 | |
| + chomwitt (~chomwitt@2a02:587:dc0c:c200:9e04:2be9:6643:df78) | 07:32 | |
| - bgs (QUIT: Remote host closed the connection) (~bgs@212-85-160-171.dynamic.telemach.net) | 08:01 | |
| + MajorBiscuit (~MajorBisc@c-001-009-031.client.tudelft.eduvpn.nl) | 09:05 | |
| + robin_ (~robin@user/terpri) | 09:51 | |
| * robin_ -> robin | 09:53 | |
| * yankcrim- -> yankcrime | 10:17 | |
| minute | josch: do you know if there's a flag/method to get an early console on the initramfs before modules are loaded? | 13:13 |
|---|---|---|
| minute | or do i have to unpack + patch the initramfs? | 13:13 |
| minute | perhaps i could pass init=/bin/sh to the kernel? | 13:14 |
| josch | minute: you can also dump scripts into the directories in /etc/initramfs-tools/scripts and then rebuild the initramfs. Depending on the directory, your script will then get executed at a certain point during the very early init. | 13:15 |
| minute | josch: that sounds like a great option, thanks | 13:16 |
| josch | minute: in the initramfs-tools man page it also says that you can use the break=XXX option to get a shell at the point you like | 13:18 |
| minute | oh nice :3 | 13:19 |
| minute | josch: do we have a variable i can set in uboot to add extra kernel options? i.e. bootargs? | 13:24 |
| minute | `setenv bootargs break=modules` appears to work | 13:26 |
| minute | that breaks _after_ modules are loaded though | 13:26 |
| josch | yes, bootargs is honored by the boot.scr: https://salsa.debian.org/installer-team/flash-kernel/-/blob/master/bootscript/all/bootscr.uboot-generic | 13:26 |
| minute | thanks | 13:27 |
| josch | minute: maybe some modules get loaded via udev and not by the initramfs with modprobe? | 13:27 |
| minute | hmm i don't think that udev loads the display modules | 13:27 |
| josch | according to the "init" script inside the initramfs, "maybe_break modules" definitely comes right before "load_modules" | 13:30 |
| josch | okay, "udev" is part of "init-top" which is the step before "load_modules" | 13:31 |
| josch | maybe try with break=top | 13:31 |
| josch | that will give you a shell before "udevadm trigger" | 13:31 |
| minute | yeah, with break=top modules are not loaded, but it is ignoring console=/dev/ttymxc0,115200 | 13:31 |
| minute | i.e. i don't get a console on serial | 13:31 |
| josch | do we need a module loaded for the serial device? | 13:32 |
| minute | no, the serial ports are there | 13:32 |
| minute | ah, there seems to be an extra `console` variable | 13:32 |
| minute | https://salsa.debian.org/installer-team/flash-kernel/-/blob/master/bootscript/all/bootscr.uboot-generic#L24 | 13:32 |
| minute | weird > [ 0.000000] Kernel command line: ro no_console_suspend cma=512M pci=nomsi break=top console=/dev/ttymxc0,115200 console=ttymxc0,115200 console=tty1 | 13:34 |
| minute | looks like it gets overridden by @@LINUX_KERNEL_CMDLINE@@ | 13:35 |
| minute | ok, looks like i need to edit boot.scr, no idea where @@LINUX_KERNEL_CMDLINE@@ comes from | 13:38 |
| minute | oh i see | 13:39 |
| josch | minute: /etc/default/flash-kernel | 13:40 |
| minute | this is baked in during the build | 13:40 |
| - mjw (QUIT: Killed (NickServ (GHOST command used by wielaard!~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440))) (~mark@gnu.wildebeest.org) | 13:40 | |
| * wielaard -> mjw | 13:40 | |
| + mark_ (~mark@gnu.wildebeest.org) | 13:40 | |
| minute | ok, finally have a serial early console in initramfs. | 13:42 |
| minute | a few modules are loaded, usb related. i guess that's fine | 13:42 |
| - MajorBiscuit (QUIT: Quit: WeeChat 3.5) (~MajorBisc@c-001-009-031.client.tudelft.eduvpn.nl) | 13:46 | |
| - GNUmoon (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 14:03 | |
| - mtm (QUIT: Ping timeout: 260 seconds) (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 14:04 | |
| + GNUmoon (~GNUmoon@gateway/tor-sasl/gnumoon) | 14:04 | |
| minute | this seems to be a minimal command to get a mxsfb display in initramfs before loading other modules: modprobe reset_imx7;modprobe mux_mmio;modprobe fixed;modprobe i2c-imx;modprobe fan53555;modprobe i2c_mux_pca954x;modprobe pwm_imx27;modprobe pwm_bl;modprobe panel_edp;modprobe ti_sn65dsi86;modprobe phy-fsl-imx8-mipi-dphy;modprobe nwl-dsi;modprobe mxsfb | 14:22 |
| minute | for m in reset_imx7 mux_mmio fixed i2c-imx fan53555 i2c_mux_pca954x pwm_imx27 pwm_bl panel_edp ti_sn65dsi86 phy-fsl-imx8-mipi-dphy nwl-dsi mxsfb; do modprobe $m; done | 14:25 |
| - fsx (QUIT: Quit: fsx) (~fsx@durian.61924.nl) | 14:27 | |
| minute | this works reliably, so the module load order seems relevant | 14:28 |
| josch | wow | 14:30 |
| minute | now i can try to figure out which "bad" order doesn't work | 14:31 |
| josch | minute: if you think that the correct fix might take another while, I can add this workaround to the initramfs in reform-system-image until then | 14:32 |
| minute | josch: ok, i will try futzing with this for half an hour and if i can't figure it out, we should add the workaround | 14:33 |
| josch | sure! | 14:33 |
| josch | i'll be afk in half an hour but i'll read the backlog :) | 14:33 |
| minute | sure! | 14:34 |
| minute | josch: another thing, i'm not sure if reset_imx7 should really be a module. if i load it, all the pcie stuff is probed... so it's a dependency for pcie that's not satisfied by default. | 14:36 |
| minute | i'm unhappy that ti_sn65dsi86 can't be rmmodded cleanly, always oopses | 14:41 |
| minute | in _regulator_put.part.0+0x170/0x180 | 14:41 |
| minute | i wonder how that happens hmm | 14:41 |
| josch | I do not see reset_imx7 being explicitly built as a module anywhere. If that's the right thing to do, we can definitely add it as a =y to the config. | 14:42 |
| josch | before sysimage-v3, the kernel config also didn't include reset_imx7 and also was implicitly built -- probably as a dependency of something else | 14:44 |
| minute | josch: CONFIG_RESET_IMX7=y wasn't there? | 14:51 |
| josch | ah no, sorry I failed at grep | 14:52 |
| josch | it is set but by the Debian default | 14:52 |
| josch | https://sources.debian.org/src/linux/5.19.11-1/debian/config/arm64/config/?hl=1345#L1345 | 14:52 |
| + fsx (~fsx@durian.61924.nl) | 14:53 | |
| minute | josch: i guess all platform specific drivers are modules there? | 14:53 |
| minute | i mean, most SoC specific drivers | 14:53 |
| josch | hrm... I see a lot of =y in that file | 14:53 |
| minute | true, it seems a bit random | 14:54 |
| minute | i think ti_sn65dsi86 has the same bug as https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1232787.html | 14:54 |
| josch | again, vagrantc knows more on that topic :) | 14:54 |
| minute | it uses devm_regulator_bulk_get() | 14:55 |
| minute | but it could fail to init after that (DEFER?) | 14:55 |
| minute | and the kernel tries some double free when rmmodding | 14:55 |
| minute | at least that's my naive understanding so far | 14:55 |
| minute | but not sure if related to my problem at all. just something i noticed | 14:55 |
| minute | ah, i was able to trigger my error manually at least once | 14:57 |
| minute | yeah, i have a reproducer | 14:58 |
| minute | this order gives me a lit, but blank display: | 14:59 |
| minute | for m in mux_mmio i2c-imx fixed fan53555 i2c_mux_pca954x pwm_imx27 pwm_bl panel_edp phy-fsl-imx8-mipi-dphy nwl-dsi mxsfb ti_sn65dsi86 reset_imx7; do modprobe $m; done | 14:59 |
| minute | this also fails: | 15:00 |
| minute | for m in mux_mmio i2c-imx fixed fan53555 i2c_mux_pca954x pwm_imx27 pwm_bl panel_edp ti_sn65dsi86 phy-fsl-imx8-mipi-dphy nwl-dsi mxsfb reset_imx7; do modprobe $m; done | 15:00 |
| minute | this works: | 15:04 |
| minute | for m in mux_mmio i2c-imx fixed fan53555 i2c_mux_pca954x pwm_imx27 pwm_bl panel_edp ti_sn65dsi86 phy-fsl-imx8-mipi-dphy reset_imx7 nwl-dsi mxsfb; do modprobe $m; done | 15:04 |
| minute | i will try just loading reset_imx7 at initramfs top and then continuing the boot | 15:05 |
| minute | yeah, this works | 15:05 |
| minute | no, that's not reliable | 15:08 |
| minute | actually it is | 15:28 |
| minute | trying to put `modprobe reset_imx7` into a script in /etc/initramfs-tools/scripts/init-top | 15:30 |
| minute | ok, that doesn't appear to work/be honored | 15:32 |
| minute | ah, i have to handle `prereqs` probably | 15:37 |
| minute | nope, the script is just not executed, don't understand why | 15:50 |
| - fsx (QUIT: Quit: fsx) (~fsx@durian.61924.nl) | 15:50 | |
| + fsx (~fsx@durian.61924.nl) | 15:51 | |
| minute | i guess log_begin_msg just doesn't work by default? | 15:53 |
| minute | yeah, `sleep` definitely works in the script, so the logging is just not working as advertised | 15:56 |
| minute | josch: can you include this in the build, in `/etc/initramfs-tools/scripts/init-top`? http://dump.mntmn.com/reform-modules-fix.sh.txt | 16:06 |
| + mtm (~mtm@c-71-228-84-213.hsd1.fl.comcast.net) | 16:09 | |
| q66 | minute: i wonder if my image has the same problem and if that's what vkoskiv was encountering maybe | 16:09 |
| q66 | lemme know when you get to testing it | 16:10 |
| minute | q66: i don't think so, but i'm dding it right now | 16:10 |
| + MajorBiscuit (~MajorBisc@c-001-009-031.client.tudelft.eduvpn.nl) | 16:10 | |
| q66 | well they were getting blank screen with nothing seemingly happening | 16:10 |
| q66 | but it could also be u-boot or anything else | 16:10 |
| minute | hangs at memory training already | 16:12 |
| q66 | so u-boot starts loading but it hangs there? | 16:12 |
| minute | i guess our uboot master is broken | 16:12 |
| q66 | should i switch to the git tag then? | 16:12 |
| minute | this is the output i get: | 16:12 |
| minute | U-Boot SPL 2018.07-0 (Oct 10 2022 - 18:31:58 +0000) | 16:12 |
| minute | Setting voltages | 16:13 |
| minute | config to do 3200 1d training. | 16:13 |
| minute | and that's it | 16:13 |
| q66 | i see | 16:13 |
| q66 | i wonder if switching to the git tag would help ten | 16:13 |
| q66 | *then | 16:13 |
| q66 | the issue could be https://source.mnt.re/reform/reform-boundary-uboot/-/commit/749874eebf7a3ad3687a452e1189fc0190f71a7d | 16:13 |
| q66 | could you try overwriting the u-boot with your own flash.bin and see if it goes any further? | 16:14 |
| q66 | maybe if it's not too much of a bother, test git master and the tag | 16:14 |
| q66 | to confirm that it's really those updates | 16:14 |
| minute | yeah, i'll check | 16:16 |
| q66 | that said the tag will probably not work as is even if the memory training stuff works | 16:18 |
| q66 | because https://source.mnt.re/reform/reform-boundary-uboot/-/commit/2dd6c0e7e2ee54784169d68933ab5b2e44881585 is needed to get extlinux.conf compatibility | 16:18 |
| q66 | and that was committed right after the tag | 16:18 |
| minute | i'll try just reverting the memory blob stuff | 16:18 |
| q66 | alright | 16:18 |
| q66 | there is also a chance that it's my u-boot compiler toolchain that's not working right, but that should not be the case | 16:19 |
| q66 | we have bare metal gcc in there specifically for u-boots because u-boot does not and will not build/work with clang | 16:19 |
| minute | just copying over the old memory .bins made it work | 16:19 |
| q66 | interesting | 16:19 |
| minute | so i get to a login, but no display | 16:19 |
| minute | (serial login) | 16:19 |
| minute | i get a lot of > [ 2.961039] [drm:ti_sn_bridge_probe [ti_sn65dsi86]] *ERROR* failed to create panel bridge | 16:20 |
| minute | q66: what's the root login? | 16:20 |
| q66 | root, password chimera | 16:20 |
| q66 | i wonder if some kernel config adjustment is necessary for the display | 16:21 |
| minute | mxsfb is not loaded | 16:21 |
| minute | ah wait, which kernel is it? mainline or ours? | 16:21 |
| q66 | mainline | 16:21 |
| minute | ok mainline should use mxsfb / lcdif | 16:21 |
| q66 | this is just our generic arm64 kernel | 16:21 |
| minute | > modprobe: FATAL: Module mxsfb not found in directory /lib/modules/5.19.8-0-generic | 16:22 |
| q66 | well that's probably the reason :) | 16:22 |
| minute | yeah | 16:22 |
| minute | the panel and the edp bridge are there and loaded | 16:22 |
| q66 | q66@chimerarm:~/cports$ grep MXS main/linux/files/config-aarch64.generic | 16:22 |
| q66 | # CONFIG_DRM_MXSFB is not set | 16:22 |
| minute | i think pwm_imx27 is also missing | 16:23 |
| q66 | yeah it is | 16:23 |
| q66 | anything else i should enable? | 16:23 |
| minute | well, coincidentally i just made a list of modules that are required for display | 16:23 |
| minute | reset_imx7 mux_mmio fixed i2c-imx fan53555 i2c_mux_pca954x pwm_imx27 pwm_bl panel_edp ti_sn65dsi86 phy-fsl-imx8-mipi-dphy nwl-dsi mxsfb | 16:23 |
| q66 | alright | 16:23 |
| minute | i think you probably have reset_imx7 as =y | 16:24 |
| q66 | i'll mess around with the config when i bump the kernel (which will be tonight) | 16:24 |
| minute | because pcie is in dmesg | 16:24 |
| q66 | yeah | 16:24 |
| q66 | is that okay? | 16:24 |
| minute | yes | 16:24 |
| minute | i prefer it that way ^^ | 16:25 |
| q66 | cool | 16:25 |
| minute | so you're only missing pwm_imx27 and mxsfb for display i think | 16:25 |
| q66 | i will probably be updatng the kernel to 6.0, so hopefully that does not break anything | 16:25 |
| q66 | if you could fix up u-boot in master, i'll then update that too | 16:25 |
| minute | ok, i'll just push the old blobs again for now | 16:25 |
| minute | actually i did not try with just flashing my own uboot build | 16:26 |
| minute | so let me cross check that | 16:26 |
| minute | so i'm trying once more with the updated bins | 16:27 |
| minute | to see if it fails again | 16:27 |
| q66 | ok, once things are fixed up i'll generate a new testing image and we can get that re-tested | 16:27 |
| q66 | i'll be making a new image set soon and it'd be nice if i could include an actual working reform image among those | 16:27 |
| minute | oh, it works | 16:27 |
| q66 | hrm | 16:28 |
| minute | so there might be something wrong with your uboot build process after all hmm | 16:28 |
| q66 | i wonder what could that be | 16:28 |
| minute | to make double sure i will flash the beginning of your image again | 16:28 |
| minute | maybe it was a fluke | 16:28 |
| q66 | my u-boot buildis basically: make -jN CROSS_COMPILE=aarch64-non-elf- CC=aarch64-none-elf-gcc flash.bin | 16:30 |
| q66 | nothing much else to it | 16:30 |
| minute | q66: ok, i do CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm make -j8 flash.bin | 16:30 |
| q66 | is the ARCH important? | 16:31 |
| minute | not sure | 16:31 |
| q66 | what compiler version are you using? | 16:31 |
| q66 | this one is 12.2.0 | 16:31 |
| minute | 10.2.1 | 16:32 |
| minute | but maybe something else in our CI | 16:32 |
| minute | q66: yeah, with the uboot from your image it hangs | 16:32 |
| minute | hmm | 16:32 |
| q66 | well that's a pain | 16:36 |
| q66 | i wonder if there is something i could do | 16:36 |
| minute | did a make clean, rebuilt, `sudo dd if=flash.bin of=/dev/sdb bs=1024 seek=33`, and it makes your image work for me | 16:36 |
| q66 | from master? | 16:37 |
| minute | yeah | 16:37 |
| q66 | yeah that means something's gotta be wrong with the u-boot | 16:37 |
| q66 | i just dunno how i'm gonna find out what that is | 16:37 |
| q66 | do you perhaps have gcc 12 available | 16:37 |
| minute | also, you're using none-elf while i'm using linux-gnu- | 16:38 |
| q66 | the only difference in my flashing is that i leave bs as it is and use seek=66 | 16:38 |
| q66 | but that should be identical | 16:38 |
| minute | yeah your u-boot is loading. it just crashes | 16:38 |
| q66 | yeah i use none-elf but for u-boot it should not matter | 16:39 |
| minute | installing gcc-12-aarch64-linux-gnu | 16:40 |
| q66 | the reason i use none-elf is that if i make a "regular" non-baremetal gcc build, it'll only really be usable for baremetal things anyway because our system runtime for regular userland is compiler-rt and gcc is not compatible with that | 16:40 |
| q66 | so gcc is only really used strictly for u-boot | 16:40 |
| q66 | so far that has made me working u-boot for pinebook pro and for hifive unmatched so it does not seem to be a problem by itself | 16:41 |
| minute | built with gcc-12-aarch64-linux-gnu, works fine | 16:42 |
| q66 | :/ i wonder what is different then | 16:43 |
| minute | i don't know i'm afraid | 16:44 |
| minute | except linux-gnu vs none | 16:44 |
| q66 | https://ftp.octaforge.org/q66/random/imx8mq_reform2/ these are my u-boot files | 16:44 |
| minute | i'm doing a fresh clone and trying again | 16:44 |
| minute | works | 16:45 |
| minute | another difference is that i get something like > U-Boot 2018.07-00014-gc3da64bdd2 | 16:45 |
| minute | whereas for you it's > U-Boot SPL 2018.07-0 | 16:45 |
| minute | your flash.bin is 80 bytes smaller than mine | 16:47 |
| minute | and there's quite a bunch of differences in the binaries of spl | 16:51 |
| q66 | interesting, there seems to be a build race in the u-boot | 16:58 |
| q66 | if i build with -j16 i get like https://gist.github.com/q66/7597511e510db2cfee97dbd0b6a68d02 | 16:58 |
| q66 | while without, i get a much different output | 16:58 |
| minute | wow | 16:59 |
| q66 | i get the same size flash.bin though | 16:59 |
| q66 | but just out of curiosity, can you try this flash.bin https://ftp.octaforge.org/q66/random/flash.bin | 17:00 |
| q66 | what i get with -j1 and with -j16 has different sha256sums | 17:01 |
| minute | q66: same problem | 17:01 |
| minute | also still: U-Boot SPL 2018.07-0 (Oct 11 2022 - 14:55:05 +0000) | 17:01 |
| minute | why is the git version missing i wonde | 17:01 |
| minute | r | 17:01 |
| q66 | probably the build env on my side does not have git | 17:02 |
| q66 | and i set EXTRAVERSION= in the build | 17:02 |
| minute | ok | 17:02 |
| q66 | i just wonder why i get U-Boot SPL and you get just U-Boot | 17:02 |
| minute | might there be other subtle difference in the environment breaking scripts? | 17:02 |
| minute | q66: ah yeah, i didn't notice SPL vs no SPL | 17:04 |
| minute | q66: maybe you can build in a GNU container? | 17:04 |
| minute | to see if that makes the difference | 17:04 |
| minute | i.e., minimal debian or ubuntu or something | 17:05 |
| q66 | i think if i did that it would probably work but it would not show what the problem with my env is | 17:05 |
| minute | ok | 17:05 |
| q66 | i'm trying removing some more differences from your build and mine to see what happens | 17:06 |
| q66 | minute: i refreshed the flash.bin on the above url, can you try it again just to see what happens | 17:08 |
| minute | i'm on a lunch break now | 17:09 |
| q66 | ok | 17:10 |
| q66 | https://ftp.octaforge.org/q66/random/flash.bin is with my toolchain | 17:18 |
| q66 | https://ftp.octaforge.org/q66/random/flash2.bin is same process but from git tree on ubuntu | 17:18 |
| q66 | https://ftp.octaforge.org/q66/random/flash3.bin is same process but without git tree on ubuntu | 17:18 |
| q66 | fwiw i get the commit hash in the boot string if building from a git repo | 17:34 |
| q66 | though as far as i can tell it's "U-Boot SPL" regardless of the environment | 17:34 |
| + jcs (~jcs@user/jcs) | 17:35 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 17:46 | |
| minute | q66: flash2.bin works | 17:56 |
| minute | q66: flash.bin does not work | 17:57 |
| minute | q66: flash2.bin starts with > U-Boot SPL 2018.07-00014-gc3da64bdd2 (Oct 11 2022 - 15:16:29 +0000) | 17:58 |
| minute | q66: flash3.bin also works. | 17:58 |
| minute | q66: it has an even different version string: > U-Boot SPL 2018.07 (Oct 11 2022 - 15:15:34 +0000) | 17:58 |
| minute | q66: ah, but flash.bin also yields > U-Boot SPL 2018.07 (Oct 11 2022 - 15:04:54 +0000) | 17:59 |
| minute | q66: anyway, seems to be toolchain related. | 18:00 |
| q66 | minute: yeah i've been comparing the binaries | 18:07 |
| q66 | and it seems that "full" toolchain has stuff like GOT in it | 18:07 |
| q66 | while the baremetal toolchain ones do not | 18:07 |
| q66 | minute: can you try this one? https://ftp.octaforge.org/q66/random/flash-pic.bin | 18:08 |
| q66 | that's baremetal toolchain but with a bunch of flags manually added to mimic the full toolchain | 18:08 |
| minute | q66: no dice | 18:09 |
| q66 | aw | 18:09 |
| q66 | minute: how well does the upstream u-boot patchset work at the moment? | 18:13 |
| minute | q66: i don't know, i'm not really interested in futzing with it | 18:13 |
| minute | q66: i'm very focused on linux desktop experience atm and also need to do a ton of hardware work | 18:13 |
| q66 | alright, just figured you might know | 18:13 |
| q66 | what i'll do for now is just ship a binary u-boot until mainline is there | 18:14 |
| q66 | or until somebody with hardware figures it out | 18:14 |
| - MajorBiscuit (QUIT: Ping timeout: 260 seconds) (~MajorBisc@c-001-009-031.client.tudelft.eduvpn.nl) | 18:16 | |
| + MajorBiscuit (~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) | 18:18 | |
| minute | q66: sounds good | 18:18 |
| q66 | minute: just in case, can you do one last test on this one https://ftp.octaforge.org/q66/random/flash-bin.bin | 18:23 |
| q66 | just so i am sure it works before i push it out | 18:23 |
| minute | q66: this one works | 18:23 |
| q66 | ok, good | 18:24 |
| q66 | ok, done | 18:34 |
| q66 | maybe i'll just get the hardware to try this out myself in the end | 18:35 |
| q66 | i've spent worse $1000 | 18:35 |
| q66 | but it currently takes ages to ship them out, right | 18:35 |
| q66 | at least that is what the orders page says | 18:35 |
| - MajorBiscuit (QUIT: Ping timeout: 268 seconds) (~MajorBisc@2a02-a461-129d-1-193d-75d8-745d-e91e.fixed6.kpn.net) | 18:35 | |
| minute | q66: yeah, we're kind of running out of stock atm | 18:45 |
| minute | q66: i have to do a new motherboard rev (planned to kick off this week) | 18:45 |
| q66 | yeah, so not something i could actually test out myself in near future i guess | 18:50 |
| - mjw (QUIT: Killed (NickServ (GHOST command used by mark_!~mark@gnu.wildebeest.org))) (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 19:43 | |
| * mark_ -> mjw | 19:43 | |
| + wielaard (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 19:44 | |
| minute | there will be a MNT Reform meetup in Seattle in nov: https://community.mnt.re/t/seattle-mnt-reform-meetup-hands-on-event-on-november-6th/1225 | 20:23 |
| vagrantc | huh. that's not *too* far from portland | 20:45 |
| vagrantc | though a ~3hour commute each way for a 2.5 hour event is a little silly :/ | 20:48 |
| vagrantc | hrm. | 20:48 |
| q66 | minute: currently tracking down the drivers to be enabled :p | 21:14 |
| q66 | navigating menuconfig is something | 21:15 |
| minute | q66: protip: make xconfig | 21:20 |
| minute | vagrantc: see also https://emacsen.net/@emacsen/109151213134010364 | 21:21 |
| minute | q66: then you can use ctrl+f to pop up a search window also | 21:23 |
| josch | vagrantc: hardcoreufo from the forums might also come there from portland | 21:23 |
| q66 | well | 21:24 |
| q66 | i think i am done | 21:24 |
| q66 | time to compile this thing | 21:24 |
| q66 | i'm updating to linux 6.0 so i'm updating all the archs | 21:24 |
| q66 | ppc64le, ppc64, aarch64, riscv64, x86_64 | 21:25 |
| minute | good luck! | 21:25 |
| vagrantc | looks like the train might get me there, but would have to catch it back the next day (or make a slightly longer trip out of it) | 21:25 |
| q66 | so far ppc64le, aarch64 and riscv64 done | 21:25 |
| vagrantc | but making an excuse for spending more time working on the mnt/reform with people in person would be interesting :) | 21:28 |
| minute | why are all the cool meetups in the US ^^ | 21:32 |
| vagrantc | cause we're so far from the center of all the amazing action? :) | 21:33 |
| minute | hehehe | 21:36 |
| vkoskiv | I'd host a more official meetup in Helsinki but I'm currently not aware of anyone else in Finland owning one | 21:37 |
| vkoskiv | I'm sure there are some, I just don't know of them. | 21:37 |
| josch | minute: I tried out the init-top script just now. Should I see any difference to without it? | 21:47 |
| minute | josch: not really | 21:52 |
| minute | josch: did you ever try reform-display-config dual and rebooted a few times? (without this workaround) | 21:53 |
| josch | out of six reboots, one came up with the display on but no text scrolling by | 21:53 |
| josch | i'm only on single display here | 21:53 |
| josch | i don't have a hdmi monitor | 21:53 |
| minute | josch: you don't need another monitor. dual uses a different display engine for the internal display | 21:54 |
| josch | yes, but that's why i never ran "reform-display-config dual" :) | 21:54 |
| josch | will run that now | 21:54 |
| minute | josch: sooo you're saying *with* the workaround and in single display config you had the situation of no text appearing? | 21:54 |
| josch | yes | 21:55 |
| josch | but only once so far | 21:55 |
| minute | josch: then probably we should also add imx_dcss to the workaround | 21:55 |
| josch | oh no... wait, something is not right | 21:55 |
| josch | i just noticed that my sdcard mounted emmc as /boot | 21:56 |
| josch | so maybe my changes didn't take any effect | 21:56 |
| minute | oh | 21:56 |
| josch | let me flash a fresh sysimage-v3 to be sure | 21:56 |
| josch | vkoskiv: I found some 5.18 dtbs in my /boot partition on emmc if you are interested ;) | 21:57 |
| josch | I only noticed my wrong /boot because reform-display-config told me "Assuming boot files are on SD card, but your system doesn't have it mounted." | 21:59 |
| vkoskiv | Ooh! Can you drop me a tarball? | 21:59 |
| josch | I knew all that improved error handling would come in handy one day. :D | 21:59 |
| minute | josch: nice | 22:00 |
| josch | vkoskiv: password xFrJP5fxQA https://oc.informatik.uni-wuerzburg.de/s/WT99jCxtAsdMA92 | 22:01 |
| vkoskiv | Downloaded, I'll give this a go a bit later. Can then verify if the SSD malarkey is indeed a regression. | 22:02 |
| sknebel | minute: have you heard anything if xhain is doing their hardware hacking meetups again? | 22:13 |
| minute | sknebel: idk, but there were some events there | 22:17 |
| josch | minute: so I put the script into /etc/initramfs-tools/scripts/init-top, marked it as executable and am rebooting with "reform-display-config dual". Everything works but I'm unsure whether I'm not missing something. Any debugging printfs I put in the script do not show up on the screen or on serial. How did you make sure that it got executed? | 22:40 |
| + ajr (~ajr@user/ajr) | 23:35 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!