+ chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 00:39 | |
chartreuse | Is there a more updated version of the system image repo? I was just rebuilding the kernel cause I wanted to enable zram and it wasn't included. Noticed that the mkkernel grabs a specific 5.11rc7 patch | 00:52 |
---|---|---|
chartreuse | I did manually change that and make a 5.13 kernel just fine after adjusting the one clock patch since that file had changed | 00:52 |
chartreuse | But my reform shipped with a 5.12.0 kernel on it and not the one the repo builds | 00:53 |
chartreuse | Did also notice the kernel options had initrd enabled, though there doesn't seem to be any provision for that in the system otherwise, so everything is compiled in | 00:54 |
mntmn | chartreuse: when did you pull? | 01:26 |
- V (QUIT: Ping timeout: 256 seconds) (~v@anomalous.eu) | 01:28 | |
chartreuse | I think I pulled last week, but it was still showing that last I checked on the source section, last updated 5mo ago or such | 01:28 |
chartreuse | Oh merged 10 hours ago XD. I started the compilation before that so even if I did grab it I would have missed that | 01:29 |
chartreuse | Started looking at it maybe 16hr ago, and probably started the compile around 13 | 01:30 |
mntmn | chartreuse: check today's log, i just merged to main from sysimage-v2 | 01:31 |
chartreuse | Yeah noticed that, that wasn't there last night when I started. I'll do that and recompile with that before changing my kernel over | 01:32 |
chartreuse | Anything preventing a 5.13 kernel from working? With the old version it compiled just fine after adjusting the patch that adds the PHY 27MHz clock | 01:33 |
chartreuse | Not that I really need any of the changes | 01:33 |
mntmn | haven't tested, 5.13 didn't exist then | 01:38 |
mntmn | but if you find it works, we can upgrade on a sysimage-v3 branch. | 01:38 |
chartreuse | Sure thing, I'll give it a try and see if there's any need to adjust the patches. | 01:39 |
mntmn | at some point basic mnt reform dts will come in, it's already in linux-next | 01:39 |
mntmn | but without display support yet | 01:39 |
chartreuse | For instaling the kernel all I need to do is change out Image in / and presumably I need to put the DTS's somewhere | 01:39 |
mntmn | yes, the dtbs also go into / | 01:39 |
chartreuse | Ah missed that they were also there | 01:40 |
chartreuse | At least if I mess up I can just change the system to boot back off the SD and restore the old ones | 01:40 |
mntmn | i was thinking for v3 to move them into /boot perhaps and make a .deb for em | 01:40 |
mntmn | yes | 01:40 |
mntmn | if we can move most things to debs then upgrading will be very easy | 01:41 |
chartreuse | Feels kinda weird not having a boot manager like grub to select different kernels | 01:41 |
mntmn | well, possible as soon as someone brings up the display in uboot | 01:41 |
chartreuse | Yeah having a deb package for a new kernel would be nice, just a quick distupgrade to get a new one | 01:41 |
chartreuse | I guess ideally everything reform specific should be in deb packages, so they get automatically upgraded | 01:42 |
mntmn | yes | 01:43 |
mntmn | so far we mostly have reform-tools and some custom builds of applications | 01:43 |
chartreuse | alright `rm -r linux/` | 01:44 |
chartreuse | Time to start afresh again | 01:44 |
chartreuse | Looking at also grabbing the ath9k user regd patch and seeing if that still works, would be nice to be on the correct power limits for my country rather than the world ones | 01:45 |
chartreuse | Wouldn't be a good idea to enable in an official image, but nice to have personally | 01:46 |
mntmn | interesting! | 01:51 |
chartreuse | Well at least one patch doesn't like 5.13 the swiotbl one won't work as swiotlb_tbl_sync_single() no longer is a function | 01:55 |
chartreuse | There's now swiotlb_sync_single_for_device and swiotlb_sync_single_for_cpu with similar names | 01:56 |
chartreuse | But I don't believe either are related as they don't contain orig_addr | 01:56 |
chartreuse | So something's been changed around with how that works | 01:57 |
chartreuse | Okay found the patch where that was changed. Happened on march 16th https://github.com/torvalds/linux/commit/80808d273a3f075196d1a26463f65d4c9d2891c8#diff-8c612e37360795f240753e57797e289274c8506a4c5ad7622faff6166a8e05aa | 02:01 |
chartreuse | Though there's a recent commit to the kernel that seems to restore the desired behaviour that your patch is reverting : https://github.com/torvalds/linux/commit/5f89468e2f060031cd89fd4287298e0eaf246bf6#diff-8c612e37360795f240753e57797e289274c8506a4c5ad7622faff6166a8e05aa | 02:02 |
chartreuse | Which appears to be in 5.13 if I'm reading the tags right on github | 02:03 |
chartreuse | So that patch shouldn't be needed then for 5.13 | 02:03 |
mntmn | yeah hopefully the original bug was fixed | 02:39 |
ex-parrot | If you want to do eg a fat32 /boot on SD card or whatever the Debian “flash-kernel” package can be useful | 04:17 |
chartreuse | uboot can already understand ext4 presumably so why bother making it fat32 | 04:36 |
chartreuse | Though having a seperate boot partition would be nice | 04:37 |
ex-parrot | Yeah preferably don’t make it fat32 | 05:27 |
ex-parrot | :O | 05:27 |
ex-parrot | I mean “:P” | 05:27 |
chartreuse | mntmn: The mkkernel script builds two dtb's the main one and a -hdmi one. While the system image has the main and a -dual-display and -single-display | 06:37 |
chartreuse | Is the correct or is there supposed to be different dts files for the two display configurations? | 06:39 |
+ Asmadeus_ (~asmadeus@240b:13:8c80:d300:e:98c:8000:d300) | 06:45 | |
- Asmadeus (QUIT: *.net *.split) (~asmadeus@240b:13:8c80:d300:e:98c:8000:d300) | 06:45 | |
- doppler (QUIT: *.net *.split) (~doppler@user/doppler) | 06:45 | |
+ doppler (~doppler@user/doppler) | 06:45 | |
- hl (QUIT: *.net *.split) (~hl@user/hl) | 06:48 | |
- skalk_ (QUIT: *.net *.split) (~skalk@vond.sysret.de) | 06:48 | |
- _Bnu (QUIT: *.net *.split) (~beeanyew@89-160-120-72.cust.bredband2.com) | 06:48 | |
- mrus (QUIT: *.net *.split) (~mrus@2001:19f0:5:1535:5400:3ff:fe7d:10ae) | 06:48 | |
+ skalk (~skalk@vond.sysret.de) | 06:49 | |
+ _Bnu (~beeanyew@89-160-120-72.cust.bredband2.com) | 06:49 | |
+ mrus (~mrus@2001:19f0:5:1535:5400:3ff:fe7d:10ae) | 06:49 | |
+ hl (~hl@user/hl) | 06:49 | |
+ rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 07:18 | |
- rasmus (PART: Disconnected: closed) (~rasmus@c80-217-132-63.bredband.tele2.se) | 07:26 | |
- mjw (QUIT: Quit: Leaving) (~mark@herd.wildebeest.org) | 09:34 | |
+ mjw (~mjw_@2001:1c06:2487:f800:9e5c:8eff:fe8f:a440) | 09:46 | |
- mjw (QUIT: Quit: Leaving) (~mjw_@2001:1c06:2487:f800:9e5c:8eff:fe8f:a440) | 10:46 | |
mntmn | chartreuse: dual and single are the correct final names that the reform-display-config script expects | 10:48 |
mntmn | chartreuse: the main dtb = single and hdmi = dual | 10:48 |
ex-parrot | https://img.hotplate.co.nz/4aMqfVIp decided to do a Linux from Scratch for my reform | 10:48 |
ex-parrot | so far so good but there is a lot of compiling in my future | 10:49 |
mntmn | ex-parrot: oh cool :D quite the trip | 11:14 |
ex-parrot | yeah. We are currently “sheltering in place” | 11:15 |
ex-parrot | Due to COVID so it’s a race to see if we can get back to 0 cases before compilation finishes | 11:15 |
mntmn | :O | 11:16 |
ex-parrot | NZ had had zero COVID for most of a year | 11:17 |
ex-parrot | So it’s a bit of a change | 11:17 |
ex-parrot | And this seemed like a good project for being stuck at hone | 11:19 |
ex-parrot | Home | 11:19 |
mntmn | absolutely | 11:19 |
+ mjw (~mjw_@2001:1c06:2487:f800:9e5c:8eff:fe8f:a440) | 11:24 | |
bluerise | Sigh, would love to be in NZ | 11:34 |
bluerise | on the other hand, I NZ people complaining about housing prices | 11:35 |
bluerise | and complaining about people wanting to move to NZ :P | 11:35 |
+ rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 12:10 | |
+ fsx (~fsx@durian.61924.nl) | 12:12 | |
* Asmadeus_ -> Asmadeus | 12:22 | |
- rasmus (PART: Disconnected: closed) (~rasmus@c80-217-132-63.bredband.tele2.se) | 12:30 | |
- Kooda (QUIT: Remote host closed the connection) (~kooda@natsu.upyum.com) | 13:01 | |
+ reform19451 (~stoege@145.40.206.190) | 13:48 | |
reform19451 | exit | 13:54 |
reform19451 | exit | 13:54 |
reform19451 | quit | 13:54 |
reform19451 | :q | 13:55 |
reform19451 | EXIT | 13:55 |
- reform19451 (QUIT: Quit: Leaving) (~stoege@145.40.206.190) | 13:59 | |
doppler | haha | 16:36 |
mntmn | someone tried reform-chat. | 16:40 |
+ alexande1 (~alexander@wsip-24-252-227-101.sb.sd.cox.net) | 17:33 | |
* alexande1 -> alex4nder | 17:33 | |
- mjw (QUIT: Quit: Leaving) (~mjw_@2001:1c06:2487:f800:9e5c:8eff:fe8f:a440) | 18:28 | |
bluerise | https://www.solid-run.com/embedded-networking/nxp-lx2160a-family/lx2162a-som/ | 19:02 |
bluerise | HOLY SCHMOLY | 19:02 |
bluerise | that one element there seems to be quite high | 19:03 |
bluerise | mntmn: I think we need an adapter for the SoM :D | 19:04 |
bluerise | on the other hand, I think you already had one in progress? | 19:04 |
bluerise | Ah, that was LS1028A | 19:05 |
mntmn | yeah but i know about this chip ;) | 19:10 |
mntmn | ah solidrun announced the module now | 19:10 |
mntmn | cool cool | 19:10 |
mntmn | i had gotten a preview render of this... | 19:10 |
mntmn | bluerise: no idea about how to do graphics though, except 2d with a fpga (and maybe llvmpipe for 3d) | 19:12 |
bluerise | heh | 19:12 |
bluerise | yeah, I know | 19:13 |
bluerise | and there's no AMD GPU chip one can buy | 19:13 |
bluerise | too bad | 19:13 |
bluerise | There are USB adapters, but,... | 19:13 |
bluerise | it's USB after all... | 19:13 |
bluerise | yes, not 3D, I know | 19:14 |
mntmn | there are some pci based 2d chips | 19:14 |
mntmn | siliconmotion i think | 19:14 |
mntmn | or one could use some MXM stuff. | 19:15 |
mntmn | don't know about TDP/thermals though. | 19:15 |
bluerise | https://www.siliconmotion.com/download/3PT/a/SM768_WP_4K_High_Definition_EN_201910.pdf | 19:15 |
bluerise | that one? | 19:15 |
mntmn | yeah | 19:16 |
mntmn | not sure if there's a driver for 768 yet | 19:16 |
mntmn | there's a new zynq zu1 that has mali | 19:17 |
mntmn | could be added as pci endpoint device | 19:17 |
mntmn | that could surely be wrestled into acting as a mini gpu | 19:17 |
bluerise | heh | 19:18 |
mntmn | and it's supposed to be "cost optimized"... | 19:18 |
- alex4nder (QUIT: Ping timeout: 252 seconds) (~alexander@wsip-24-252-227-101.sb.sd.cox.net) | 19:51 | |
- S0rin (QUIT: Ping timeout: 268 seconds) (~S0rin@user/s0rin) | 20:09 | |
+ S0rin (~S0rin@user/s0rin) | 20:13 | |
+ rasmus (~rasmus@c80-217-132-63.bredband.tele2.se) | 20:28 | |
- sknebel (QUIT: Remote host closed the connection) (~quassel@v22016013254630973.happysrv.de) | 20:58 | |
+ sknebel (~quassel@v22016013254630973.happysrv.de) | 20:59 | |
+ mjw (~mark@herd.wildebeest.org) | 21:05 | |
+ mark__ (~mark@herd.wildebeest.org) | 21:48 | |
chartreuse | I wonder if something could be done where basically you use a second SoM in a system as a gpu, somehow have both cpus talking to each other and passing on the rendering | 21:51 |
- mjw (QUIT: Ping timeout: 252 seconds) (~mark@herd.wildebeest.org) | 21:51 | |
chartreuse | Would be a bit of a power waste. | 21:51 |
chartreuse | I'm guessing though these SoM's have no way to do multi-chip multiprocessing though. That'd be neat | 21:52 |
- rasmus (PART: Disconnected: closed) (~rasmus@c80-217-132-63.bredband.tele2.se) | 22:02 | |
+ alex4nder (~alexander@ip98-182-18-230.sb.sd.cox.net) | 22:24 | |
mntmn | chartreuse: i think zynq ZU1 could be a good candidate for a gpu. | 22:32 |
chartreuse | Sure, though I imagine it'd be a lot of work to develop a 3d core for that, as well as adding stuff like h264 and h265 decompression (or something like VP9) | 23:01 |
chartreuse | A 2d framebuffer would work, though that'd put much more load on the CPU, and even then you'd still want some accelerations for moving regions are the screen or such | 23:02 |
mntmn | it has mali | 23:02 |
mntmn | so you don't need to make another 3d core | 23:02 |
chartreuse | Oh I missed that part, that's handy | 23:02 |
mntmn | and with 2ghz a72 you don't necessarily need hw video decode... depending on the target resolution | 23:03 |
chartreuse | Though is a more closed GPU, but seems like someone recently got a reverse engineered driver for it | 23:03 |
chartreuse | Doesn't need it sure, but it's handy at reducing the load so the CPU is free to do other things | 23:04 |
chartreuse | Like on the reform I can play 1080p video fine in VLC (which should be using software decoding), but it would be nice to offload that | 23:04 |
mntmn | yeah | 23:04 |
chartreuse | Haven't gotten around to recompling ffmpeg like your own forum post | 23:04 |
chartreuse | Think one of the options listed there no longer exists | 23:05 |
chartreuse | Since I did start but never finished due to some ./configure error | 23:05 |
chartreuse | Oh I was meaning to ask, right now the system image ships with dual-display and single-display dtb's in root, but the mkkernel setup only produces a -hdmi one, is that intended? | 23:06 |
chartreuse | I can't see how the dual-display and single-display ones are made as there's no dts files for that | 23:06 |
mntmn | chartreuse: hdmi = dual | 23:11 |
mntmn | chartreuse: non-hdmi = single | 23:11 |
mntmn | they're just renamed. | 23:11 |
mntmn | and single is the default. | 23:11 |
chartreuse | Alright but there's only two dtb files now rather than 3 before? | 23:11 |
ex-parrot | bluerise: I can confirm houses are too expensive | 23:12 |
mntmn | that's how it works | 23:12 |
chartreuse | Alright | 23:12 |
mntmn | chartreuse: reform-display-config just copies either -single or -dual to the one with no extension. | 23:12 |
chartreuse | Ah okay, that makes sense. Thanks | 23:13 |
chartreuse | Was confused at imx8mq-mnt-reform2.dtb, imx8mq-mnt-reform2-dual-display.dtb, imx8mq-mnt-reform2-single-display.dtb | 23:13 |
mntmn | yes, imx8mq-mnt-reform2.dtb is the one that is loaded always. | 23:13 |
mntmn | it's a copy of either of the two others | 23:13 |
chartreuse | Good to learn. Not the most familiar with dtb's and the arm boot process so it's new to me | 23:14 |
mntmn | u-boot loads the kernel and that dtb and hands the address of the dtb to the kernel. | 23:15 |
mntmn | (address in memory) | 23:15 |
chartreuse | Sorry for all the questions, but is there a config file for uboot to set kernel options somewhere? | 23:15 |
chartreuse | Or does that require flashing uboot to do so? | 23:16 |
mntmn | no, it is currently just compiled in https://source.mnt.re/reform/reform-boundary-uboot/-/blob/27c95cc64f43ed032a54b88f74089aaf319dcbc4/board/boundary/nitrogen8m_som/nitrogen8m_som.c#L334 | 23:16 |
chartreuse | Ah okay, just would be nice to have something like that to change kernel module options since they're all compiled in without initramfs | 23:16 |
mntmn | yes | 23:17 |
mntmn | i agree. i just didn't find a comfy way to do that yet | 23:17 |
mntmn | imho best would be just a text file | 23:17 |
chartreuse | Since it's reading the sd card/emmc for the boot device file, should be possible to read another for kernel parameters | 23:17 |
mntmn | there is u-boot scripts (.scr) but they are kind of binary / need a tool to create them | 23:17 |
mntmn | yes | 23:17 |
chartreuse | Maybe I'll take a look into that as well | 23:17 |
mntmn | yeah, would be cool. as long as it's plain text without signatures and stuff | 23:18 |
chartreuse | Yeah that'd be what I want too, just something like /reform-cmdline on the sd card or such | 23:18 |
mntmn | i mean, u-boot is easily extensible if there is no text file loading mechanism yet | 23:18 |
mntmn | yes, agreed | 23:18 |
chartreuse | Well somehow it's reading /reform-boot-medium so that should be possible | 23:19 |
chartreuse | Or is that some weird init hack that changes out the kernel for one on the nvme? | 23:20 |
mntmn | reform-boot-medium is read by reform-init | 23:21 |
mntmn | which is run by the kernel | 23:21 |
mntmn | so, that's long after u-boot | 23:21 |
mntmn | it does not change out the kernel. | 23:21 |
chartreuse | Huh alright, so is the kernel on the nvme drive never touched then? Only the SD card | 23:21 |
mntmn | it does change out the / directory | 23:21 |
mntmn | correct | 23:21 |
chartreuse | Ah okay, I was about to be quite confused when I swapped out image and nothing changed XD | 23:22 |
mntmn | haha sorry | 23:22 |
chartreuse | Just a lot of stuff not quite documented enough for me being unfamiliar with ARM booting | 23:22 |
chartreuse | Never did much hacking around with the Pi's kernel either | 23:23 |
- mark__ (QUIT: Quit: Leaving) (~mark@herd.wildebeest.org) | 23:36 | |
chartreuse | Looks like it's possible to read a text file into memory in uboot. Then it'd be a matter of reading that back to get the value with `mm` | 23:36 |
+ mjw (~mark@herd.wildebeest.org) | 23:36 | |
chartreuse | ext4load | 23:37 |
chartreuse | So should be possible from the source to do it, then sprintf it into a string or such for the bootargs string | 23:42 |
mntmn | hmm > env import -t $loadaddr $filesize | 23:44 |
mntmn | > You need to enable CONFIG_CMD_IMPORTENV | 23:44 |
mntmn | not sure if we have that atm | 23:44 |
chartreuse | Yeah I've seen some mention of people loading env from a uEnv.txt file | 23:45 |
chartreuse | But considering in the source at least you should have access to whatever routines that ext4load is making use of to read in a file | 23:45 |
chartreuse | https://www.linuxjournal.com/content/handy-u-boot-trick | 23:47 |
chartreuse | Though from a mailinglist post I saw kinda sounds like the default filesystem is fat | 23:47 |
chartreuse | https://linux-sunxi.org/UEnv.txt | 23:49 |
chartreuse | Seems kinda the idea without any extra custom implementations if it can work of ext4 | 23:49 |
chartreuse | https://lists.denx.de/pipermail/u-boot/2013-February/147740.html | 23:49 |
chartreuse | Though there's this single mailinglist post from 2013 with no replies where it seems to try and only get it from fat | 23:50 |
mntmn | what's the problem with env import then? | 23:50 |
mntmn | ext4load + env import | 23:50 |
chartreuse | Seems like it's probably fine https://e2e.ti.com/support/processors-group/processors/f/processors-forum/766818/linux-beaglebk-u-boot-env-import-export | 23:51 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!