| bkeys | josch: Do you have any clue what partition I should write the image to on the emmc? I tried the boot0 and boot1 devices and that seemed to do nothing | 00:04 |
|---|---|---|
| josch | bkeys: boot0 and boot1 only contain u-boot on some soms | 00:10 |
| josch | they do not contain a mbr or gpt or filesystem | 00:10 |
| bkeys | Yeah but isn't my goal to replace uboot with edk2? | 00:10 |
| bkeys | So it would make sense to dd edk2 over where uboot is stored | 00:10 |
| zeha | iirc edk2 is a payload for uboot | 00:11 |
| josch | bkeys: you are on rk3588, right? that one does not read from boot0 or boot1 | 00:11 |
| bkeys | Well my uboot must not have been touched because my reform is booting and such just as it did before | 00:11 |
| josch | rk3588 reads u-boot from the normal partition at a specfic offset | 00:11 |
| bkeys | So do I dd edk2 over /dev/mmcblk0? | 00:11 |
| josch | probably, yes | 00:12 |
| bkeys | ACTION waits for his stuff to get bricked | 00:12 |
| bkeys | Hey!!! | 00:13 |
| bkeys | It worked! | 00:13 |
| bkeys | Just like that | 00:13 |
| bkeys | I got built in UEFI | 00:13 |
| josch | haha nice! | 00:13 |
| bkeys | Now it's like a normal laptop | 00:13 |
| bkeys | This is great | 00:13 |
| josch | awesome :) | 00:13 |
| bkeys | Now to put the nvme in here | 00:14 |
| bkeys | But I gotta pick up a pizza for the family | 00:14 |
| josch | i'd be interested in hearing what blobs are needed to build it -- for u-boot we are using a bunch of proprietary blobs | 00:14 |
| josch | enjoy your meal! | 00:14 |
| bkeys | Whatd be nice is if I could put the OS on the emmc and my home partition on the nvme | 00:15 |
| minute | bkeys: how fast does it boot to edk2 from emmc? | 00:20 |
| bkeys | It takes ~5-10 seconds | 00:20 |
| minute | alright | 00:20 |
| bkeys | ACTION dances at his empty SD card slot | 00:20 |
| minute | bkeys: thanks for trying this extremely risky thing:D | 00:20 |
| bkeys | Yeah so for reference I did | 00:21 |
| bkeys | $ sudo dd if=aio-edk2-image.img of=/dev/mmcblk0 bs=4M conv=fsync | 00:21 |
| bkeys | I mean the main motivator of me to pay that much for the rk3588 was edk2 | 00:21 |
| - mjw (QUIT: Ping timeout: 252 seconds) (~mjw@gnu.wildebeest.org) | 00:30 | |
| - L29Ah (QUIT: Read error: Connection reset by peer) (~L29Ah@wikipedia/L29Ah) | 01:35 | |
| + L29Ah (~L29Ah@wikipedia/L29Ah) | 01:37 | |
| minute | bkeys: got it | 01:38 |
| - chomwitt (QUIT: Ping timeout: 248 seconds) (~chomwitt@2a02:85f:9a8c:7600:1ac0:4dff:fedb:a3f1) | 01:48 | |
| bkeys | I can't boot Fedora or CentOS Stream on there, Stream somehow gets closer. I do have device tree enabled | 02:45 |
| bkeys | I'm gonna try a second ISO image and see if that one works better | 02:45 |
| - paperManu (QUIT: Ping timeout: 260 seconds) (~paperManu@107.159.213.145) | 03:22 | |
| - nsc (QUIT: Ping timeout: 252 seconds) (~nicolas@i5C74DD1A.versanet.de) | 03:23 | |
| bkeys | f41 doesn't seem to work, it does the same thing as f42 did. | 03:24 |
| + nsc (~nicolas@i5C74DE0E.versanet.de) | 03:24 | |
| + arminweigl_ (~arminweig@sourcehut/user/arminweigl) | 03:57 | |
| - arminweigl (QUIT: Ping timeout: 245 seconds) (~arminweig@sourcehut/user/arminweigl) | 03:57 | |
| * arminweigl_ -> arminweigl | 03:58 | |
| bkeys | minute: Did you have to do any overrides or dtb files to boot Fedora? What version of Fedora did you manage to boot? | 04:02 |
| + kfx (~kfx@wopr.sciops.net) | 05:22 | |
| kfx | I got my rk3588! should I use the hdmi-rdp adapter or the dsi connection? | 05:28 |
| - aloo_shu (QUIT: Ping timeout: 252 seconds) (~aloo_shu@90.166.99.87) | 05:28 | |
| kfx | ok, install went well. it boots to the Debian announcement and then immediately reboots | 05:59 |
| kfx | ah, it wants batteries. | 06:17 |
| + Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 06:42 | |
| - cow321 (QUIT: Ping timeout: 252 seconds) (~deflated8@user/meow/deflated8837) | 06:42 | |
| + cow321 (~deflated8@user/meow/deflated8837) | 06:43 | |
| - Gooberpatrol_66 (QUIT: Ping timeout: 276 seconds) (~Gooberpat@user/gooberpatrol66) | 06:43 | |
| - akadom (QUIT: Quit: Lost terminal) (~em@user/akadom) | 08:21 | |
| - xha (QUIT: Quit: WeeChat 4.6.2) (~xha@user/xha) | 09:50 | |
| + mjw (~mjw@gnu.wildebeest.org) | 09:50 | |
| gsora | does running edk2 have any real upside? even if you could boot live environments from USB, wouldn't installing an OS be a mess due to all the weird rk3588 partitioning requirements? | 10:06 |
| - mjw (QUIT: Ping timeout: 276 seconds) (~mjw@gnu.wildebeest.org) | 10:19 | |
| * Guest74 -> mjw | 11:41 | |
| - GNUmoon (QUIT: *.net *.split) (~GNUmoon@gateway/tor-sasl/gnumoon) | 12:00 | |
| - RandyK (QUIT: *.net *.split) (~RandyK@user/randyk) | 12:00 | |
| svp | nice! i'm all for anything that makes booting an sbc the least painful possible :p damn non-built-in device trees and dodgy vendor kernels and all that jazz... | 12:04 |
| + paperManu (~paperManu@107.159.213.145) | 12:08 | |
| sad_plan | gsora: what partition requirements for the rk are you refering to? cant you just use /boot and / like everything else? | 12:08 |
| gsora | sad_plan: iirc rk chips need ram training + bootloader to be written in the first few sectors of the boot device | 12:16 |
| gsora | if you wipe those, you have to restore from maskrom, which isn't a pleasant experience | 12:17 |
| gsora | i imagine a generic installer system if instructed to use the entire disk will just wipe everything, including that code | 12:17 |
| Zaba | I mean, the SoC is done with all that by the time edk2 is running | 12:18 |
| gsora | sure, but i'm most worried about OS installers | 12:18 |
| Zaba | and edk2 can just boot a normal OS through ordinary UEFI means | 12:18 |
| Zaba | what do they have to do with this? | 12:19 |
| gsora | an installer that doesn't know it should not alter the first X sectors of the install target might overwrite code needed by the cpu to boot | 12:19 |
| Zaba | well firstly you don’t need to install the OS on the same device the SoC boots from | 12:19 |
| Zaba | if you have an eMMC you can just dedicate that to uboot or edk2 and install the OS on NVMe | 12:20 |
| sad_plan | gsora: that doesnt sound too bad. reminds me of mbr kinda | 12:20 |
| Zaba | and secondly, you can actually just create GPT partitions for all those special offsets (the SoC won’t *use* the partition data, they’ll be descriptive rather than prescriptive, but still useful) to make those “special offsets” less magical and special | 12:21 |
| Zaba | the offsets usually don’t start at 0 precisely so you have room for a partition table | 12:21 |
| gsora | admittedly I didn't think about installing the OS on a different device! | 12:23 |
| gsora | as for creating special GPT partitions, that's smart, but that requires users to know what they're doing, i.e. creating the partition table before running the OS installer | 12:24 |
| gsora | all i'm saying is OS installers _might_ pose an issue | 12:28 |
| - elb (QUIT: Remote host closed the connection) (~elb@2600:4041:6671:1300:4e33:9196:e71c:f78e) | 12:47 | |
| + elb (~elb@2600:4041:6671:1300:7794:459e:1a97:3187) | 12:47 | |
| + gustav28 (~gustav@c-78-82-52-94.bbcust.telenor.se) | 13:02 | |
| + antti (~antti@user/antti) | 13:36 | |
| abortretryfail | Oh are we doing alternative firmware/bootloaders now? | 13:40 |
| bkeys | I hope so | 13:57 |
| josch | gsora: yes, OS installers might wipe the first few megabytes of your eMMC if you tell them to do so. But Zaba is also correct when they say that a GPT partition is used to prevent this from happening. So for example what Debian installer does is to create an empty dummy partition at the start of the device to prevent anything from altering the first few megabytes. | 14:06 |
| josch | But yes, I would also just not touch eMMC anymore and use nvme instead for everything :) | 14:07 |
| Zaba | you don’t have to create a “dummy” partition, you could just use the partition table to describe the special offsets used by the SoC | 14:10 |
| Zaba | also theoretically it would probably be possible to integrate that into the installer properly, so it would just know to automatically make those partitions too by default | 14:11 |
| josch | yes, you could -- unfortunately an implementation detail in how the partitioner in debian installer works makes doing so very, very tricky which is why it is not done like that right now | 14:12 |
| Zaba | one advantage of just having partitions at the right offsets and sizes would be that updating the boot firmware would be as easy as overwriting those partitions instead of juggling magic offset values every time | 14:13 |
| + aloo_shu (~aloo_shu@90.166.99.98) | 14:15 | |
| - L29Ah (PART: !!unknown attribute: msg!!) (~L29Ah@wikipedia/L29Ah) | 14:15 | |
| bkeys | minute: What version of Fedora did you use when you tested EDK2? I can't get it to boot, the I/O LED on my USB disk just dies after the kernel is decompressed | 14:23 |
| gsora | josch: interesting! was the debian installer updated to special case this situation or it's a common practice? | 14:26 |
| minute | josch: how hard would it be to generate the system image for amd64? the use case is to be able to do quick testing with kvm on a intel machine | 14:31 |
| bkeys | I use ACPI mode and all problems seem to go away (at least when it comes to booting an installer | 14:50 |
| - paperManu (QUIT: Quit: WeeChat 4.1.1) (~paperManu@107.159.213.145) | 14:59 | |
| - bkeys (QUIT: Ping timeout: 248 seconds) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 15:11 | |
| josch | minute: you mean to test the things in the layer above the bootloader and kernel? Might be really trivial, lets see... | 15:21 |
| minute | josch: yes, the setup wizard and initial desktop etc | 15:22 |
| josch | gsora: debian installer was updated specifically to support the 16MBit empty space at the beginning of the disk for rk3588 | 15:22 |
| josch | minute: makes sense -- i'm installing the setup wizard on amd64 in the Debian CI systems | 15:22 |
| minute | bkeys: yeah we just need an updated acpi/dt model for reform, right now it's too generic | 15:22 |
| josch | minute: another thing that i was evaluating for automated testing was to use OpenQA on the reform. OpenQA works by automating clicking and keyboard input and then takes screenshots and compares them to what is expected for them to look like. | 15:26 |
| josch | I was talking to phil hands about this at minidebconf hamburg as he is the maintainer of the Debian openqa setup which is our CI testing for debian-installer, gnome, kde and other stuff | 15:26 |
| josch | in the debian CI for reform-setup-wizard i essentially re-implemented what openqa does (i didn't know about it at that point) and wrote scripts which start a virtual machine under kvm and then take screenshots and perform mouse and keyboard input via VNC | 15:27 |
| + bkeys (~Thunderbi@66.110.201.50) | 15:30 | |
| josch | minute: this is for example how the tests for Debian Live and Gnome+Firefox look like: https://openqa.debian.net/tests/400643 | 15:30 |
| josch | I wanted to create some sort of testsuite like this for the MNT Debian derivative | 15:30 |
| - bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 15:32 | |
| + bkeys (~Thunderbi@66.110.201.50) | 15:32 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 15:37 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 15:37 | |
| * bkeys1 -> bkeys | 15:40 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50) | 15:44 | |
| + bkeys (~Thunderbi@66.110.201.50) | 15:44 | |
| minute | josch: that would be cool yeah | 15:45 |
| josch | minute: i also told phil that the really interesting things to test would be stuff like "does the display turn on" or "does sound work" etc and you cannot do that in qemu | 15:45 |
| josch | and he told me that openqa does not care where the input comes from | 15:46 |
| josch | instead of a screenshot one could as well direct a webcam at the screen and openqa could use that | 15:46 |
| josch | and i never thought about this possibility and it got me to re-evaluate what i thought was possible | 15:46 |
| bkeys | So I turned on ACPI mode on edk2 and that solved the issue of stuff not booting, I'm running the Fedora installer now but I'm stuck with llvmpipe in ACPI it seems | 15:47 |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50) | 15:47 | |
| + bkeys (~Thunderbi@66.110.201.50) | 15:47 | |
| josch | minute: so i have this device on order: https://shop.linux-automation.com/index.php?route=product/product&product_id=72 | 15:48 |
| josch | now that i have a few Reforms at home, i could set something up which automatically flashes a system image to an sd-card and "inserts" it via the USB-SD-Mux and then boots from it | 15:49 |
| josch | this would make it possible to test the complete boot process | 15:49 |
| - bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 15:52 | |
| grimmware | that's very cool | 15:52 |
| + bkeys1 (~Thunderbi@66.110.201.50) | 15:52 | |
| - bkeys1 (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50) | 15:55 | |
| + bkeys (~Thunderbi@66.110.201.50) | 15:55 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 15:59 | |
| + bkeys (~Thunderbi@66.110.201.50) | 16:00 | |
| gsora | omg i need one of those | 16:01 |
| [tj] | josch: I might have killed the sd card slot in one of my imx8mp boards with an sd mux | 16:02 |
| bkeys | Gah I'm worried I'll have to go back to uboot cause edk2 is not really able to boot any Fedora/CentOS based distros | 16:02 |
| [tj] | josch: you should get micro sd card extension ribbon cables to use with them | 16:02 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 16:10 | |
| + bkeys (~Thunderbi@66.110.201.50) | 16:10 | |
| josch | [tj]: you mean you mechanically killed it? | 16:12 |
| [tj] | yeah, olimex charged me for a replacement | 16:13 |
| josch | oh wow, thank you for the heads-up! | 16:13 |
| + paperManu (~paperManu@107.159.213.145) | 16:15 | |
| bkeys | Is there any known issues with nvme drives on rk3588? | 16:15 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 16:20 | |
| + bkeys (~Thunderbi@66.110.201.50) | 16:20 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 16:23 | |
| + bkeys (~Thunderbi@66.110.201.50) | 16:23 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 16:29 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 16:30 | |
| - bkeys1 (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 16:32 | |
| + bkeys (~Thunderbi@66.110.201.50) | 16:32 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 16:36 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 16:36 | |
| * bkeys1 -> bkeys | 16:38 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 16:48 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 16:48 | |
| * bkeys1 -> bkeys | 16:50 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 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) | 16:59 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 16:59 | |
| * bkeys1 -> bkeys | 17:02 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 17:03 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 17:03 | |
| - bkeys1 (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 17:04 | |
| + bkeys (~Thunderbi@66.110.201.50) | 17:04 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 17:20 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 17:20 | |
| - bkeys1 (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50) | 17:22 | |
| + bkeys (~Thunderbi@66.110.201.50) | 17:23 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 17:33 | |
| + bkeys (~Thunderbi@66.110.201.50) | 17:33 | |
| spew | my reform shipped I am so happy | 17:37 |
| spew | thank you minute, thank you everyone else whose nicks I might not know who worked on this | 17:38 |
| gordon1 | spew: when did you order it roughly, if not a secret? | 17:40 |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 17:41 | |
| spew | 2024-10-03 | 17:41 |
| gordon1 | cool, so mine probably is not too deep in the queue then | 17:42 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 17:43 | |
| + bkeys (~Thunderbi@66.110.201.50) | 17:43 | |
| + xha (~xha@user/xha) | 17:46 | |
| + bkeys1 (~Thunderbi@38-146-94-247.echocast.zone) | 17:59 | |
| - bkeys (QUIT: Ping timeout: 260 seconds) (~Thunderbi@66.110.201.50) | 18:02 | |
| * bkeys1 -> bkeys | 18:03 | |
| - xktr (QUIT: Ping timeout: 268 seconds) (~xktr@user/xktr) | 18:38 | |
| - bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@38-146-94-247.echocast.zone) | 18:38 | |
| + bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 18:38 | |
| + xktr (~xktr@user/xktr) | 18:44 | |
| - bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@38-146-94-247.echocast.zone) | 18:54 | |
| + bkeys1 (~Thunderbi@173.186.16.211) | 18:54 | |
| * bkeys1 -> bkeys | 18:56 | |
| kfx | ok, I've installed the rcore and the keyboard 4.0 ... and I can't read LPC data from software. just zeros everywhere. how do I debug this? | 19:03 |
| + L29Ah (~L29Ah@wikipedia/L29Ah) | 19:15 | |
| bkeys | josch: Does the uboot that comes with the system image have any support for uboot menus at all? | 19:42 |
| josch | bkeys: yes, but it does not have support for the display so the menu is shown but you cannot see it (unless you observe u-boot via serial) | 19:48 |
| josch | also, because this is like that on all platforms (except imx8mq) the time the menu is shown was set to 0.1 seconds to not waste boot time on a menu that nobody can reasonably interact with anyway... | 19:53 |
| + mark_ (~mjw@gnu.wildebeest.org) | 20:01 | |
| - bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@173.186.16.211) | 20:21 | |
| + bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 20:24 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@38-146-94-247.echocast.zone) | 20:41 | |
| + bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 20:41 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@38-146-94-247.echocast.zone) | 20:43 | |
| + bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 20:44 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@38-146-94-247.echocast.zone) | 20:46 | |
| + bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 20:46 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@38-146-94-247.echocast.zone) | 20:47 | |
| + bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 20:48 | |
| - xktr (QUIT: Read error: Connection reset by peer) (~xktr@user/xktr) | 20:48 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@38-146-94-247.echocast.zone) | 20:51 | |
| + bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 20:51 | |
| + xktr (~xktr@user/xktr) | 20:54 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 20:59 | |
| - bkeys (QUIT: Ping timeout: 276 seconds) (~Thunderbi@38-146-94-247.echocast.zone) | 21:03 | |
| * bkeys1 -> bkeys | 21:03 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 21:28 | |
| + bkeys (~Thunderbi@66.110.201.50) | 21:28 | |
| - bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 21:32 | |
| + bkeys1 (~Thunderbi@66.110.201.50) | 21:33 | |
| * bkeys1 -> bkeys | 21:35 | |
| + chomwitt (~chomwitt@2a02:85f:9ace:3000:1ac0:4dff:fedb:a3f1) | 21:42 | |
| + bkeys1 (~Thunderbi@38-146-94-247.echocast.zone) | 21:43 | |
| - bkeys (QUIT: Ping timeout: 276 seconds) (~Thunderbi@66.110.201.50) | 21:46 | |
| * bkeys1 -> bkeys | 21:46 | |
| - gustav28 (QUIT: Quit: Quit) (~gustav@c-78-82-52-94.bbcust.telenor.se) | 22:15 | |
| abortretryfail | why's the display work for imx8mq but none of the others? | 22:30 |
| josch | abortretryfail: because cinap_lenrek did the work and added an lcdif to u-boot | 22:32 |
| josch | *driver | 22:32 |
| minute | kfx: maybe upgrade the lpc firmware and try the latest lpc driver from my pending reform-tools MR | 23:06 |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@38-146-94-247.echocast.zone) | 23:09 | |
| + bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 23:09 | |
| - Ar|stote|is (QUIT: Ping timeout: 252 seconds) (~linx@149.210.2.131) | 23:21 | |
| - bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@38-146-94-247.echocast.zone) | 23:22 | |
| + bkeys (~Thunderbi@38-146-94-247.echocast.zone) | 23:22 | |
| - bkeys (QUIT: Ping timeout: 260 seconds) (~Thunderbi@38-146-94-247.echocast.zone) | 23:27 | |
| - potash (QUIT: Quit: The Lounge - https://thelounge.chat) (~potash@user/foghorn) | 23:40 | |
| + potash (~potash@user/foghorn) | 23:44 | |
| kfx | minute: got a link? or is the mr not made yet | 23:48 |
| wickedshell | Any perferred antenna spots for the second antenna with the add on wifi module for the pocket? (I now have the one that came with the replacement backplate, as well as the one with the module) | 23:52 |
| wickedshell | Also any preference between the onboard bluetooth and presumably the one on the wifi one? | 23:53 |
| wickedshell | (imx8mp) | 23:54 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!