2025-06-13.log

- aakast (QUIT: Ping timeout: 276 seconds) (~aakast@net-93-65-57-194.cust.vodafonedsl.it)00:30
minutebkeys: i think you can copy the file using uefi shell00:58
bkeysminute: I'll try that00:58
minuteit has copy command, and text editor, everything 00:58
kfxis 1500000 the right baud rate for rk3588?  getting a lot of gibberish out of tio...00:59
- vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:50)01:20
bkeysminute: For some reason it "failed to open with create." whatever that means01:21
bkeysHeaven forbid a cp command work01:21
minutekfx: yes. can your uart adapter do that? some can't01:23
kfxah, the cp2102 can't go that fast.  guess I'll find something else to order01:25
kfxlooks like the FT232RNL can handle it...01:26
- chomwitt (QUIT: Ping timeout: 260 seconds) (~chomwitt@2a02:85f:9a08:a800:1ac0:4dff:fedb:a3f1)01:28
minutebkeys: in uefi shell?01:34
- jn (QUIT: Ping timeout: 252 seconds) (~quassel@user/jn/x-3390946)01:36
- lanodan (QUIT: Ping timeout: 252 seconds) (~lanodan@2a01:e0a:d6:9930::35)01:51
+ lanodan (~lanodan@2a01:e0a:d6:9930::35)01:53
- AnimaInvicta (PART: !!unknown attribute: msg!!) (~AnimaInvi@88-120-179-216.subs.proxad.net)01:55
bkeysminute: I copied it in Linux, the dtb file is physically there but I'm not sure the Fedora kernel is picking itu p02:29
bkeysI don't know if it's as simple as dropping the file there, or if there is something I have to do after putting the file there02:29
- nsc (QUIT: Ping timeout: 276 seconds) (~nicolas@66-99-142-46.pool.kielnet.net)03:13
+ nsc (~nicolas@43-98-142-46.pool.kielnet.net)03:15
- chrcav (QUIT: Quit: leaving) (~chrcav@user/chrcav)03:20
+ arminweigl_ (~arminweig@sourcehut/user/arminweigl)03:34
- arminweigl (QUIT: Ping timeout: 260 seconds) (~arminweig@sourcehut/user/arminweigl)03:34
* arminweigl_ -> arminweigl03:35
- exark (QUIT: Quit: quit) (~exark@user/exark)03:37
+ exark (~exark@user/exark)03:39
bkeysHmm, I select the rk3588-mnt-reform2.dtb file directly from the UEFI shell and it did look like it was working for a split second then it dies03:47
bkeysI'll have to ask the guys in #fedora-arm what's up, but this can wait for tomorrow03:47
+ chrcav (~chrcav@user/chrcav)03:57
- mjw (QUIT: Ping timeout: 260 seconds) (~mjw@gnu.wildebeest.org)03:57
+ ZylonMaster (~hjcs@syn-098-015-248-249.res.spectrum.com)04:58
- ZylonMaster (PART: !!unknown attribute: msg!!) (~hjcs@syn-098-015-248-249.res.spectrum.com)04:58
+ reform26147 (~matt@pool-108-17-91-250.pitbpa.fios.verizon.net)06:48
- reform26147 (QUIT: Client Quit) (~matt@pool-108-17-91-250.pitbpa.fios.verizon.net)06:52
+ murph__ (~murph@pool-108-35-93-154.nwrknj.fios.verizon.net)07:07
- murph_nj (QUIT: Read error: Connection reset by peer) (~murph@pool-108-35-93-154.nwrknj.fios.verizon.net)07:08
+ chomwitt (~chomwitt@2a02:85f:9a08:a800:1ac0:4dff:fedb:a3f1)07:28
- chomwitt (QUIT: Ping timeout: 265 seconds) (~chomwitt@2a02:85f:9a08:a800:1ac0:4dff:fedb:a3f1)08:23
- Ar|stote|is (QUIT: Ping timeout: 268 seconds) (~linx@149.210.5.33)09:31
gsoraiirc there’s a way to fix the baud rate weirdness on rk358809:31
gsoralike, setting it to 115200, I have notes at home, will share later09:32
+ Ar|stote|is (~linx@149.210.5.33)09:35
joschon the other hand, 1500000 baud *are* a bit nicer for some use-cases :)09:37
+ andreas-e (~Andreas@2001:861:c4:f2f0::c64)09:44
gsorasurely it’s faster :D09:50
joschminute: i now have bridged pin 2&3 of J1 and have the pocket running from usb-pd and it still switches off -- theories?09:51
+ chomwitt (~chomwitt@2a02:85f:9a08:a800:1ac0:4dff:fedb:a3f1)10:01
minutejosch: any discernible pattern?10:05
joschminute: i wish. My next test will be with ssd and wifi disconnected and just idling from a fresh sd-card image.10:10
joschthe only correlation i have that this started happening after i switched the battery cells10:11
joschbut since it also happens without the battery board connected, that's probably just correclation and not causation10:11
joschand i wish i could reliably reproduce it :)10:11
- chomwitt (QUIT: Ping timeout: 248 seconds) (~chomwitt@2a02:85f:9a08:a800:1ac0:4dff:fedb:a3f1)10:19
minutejosch: everything connected and seated well? maybe reinsert the rcore? (not the som, just in the motherboard slot)10:36
+ arminweigl_ (~arminweig@sourcehut/user/arminweigl)10:45
- arminweigl (QUIT: Ping timeout: 260 seconds) (~arminweig@sourcehut/user/arminweigl)10:46
* arminweigl_ -> arminweigl10:46
gsorare: waybar battery monitor, using upower matches 1:1 what the oled display reports11:21
joschminute: okay, i'll try that thank you11:26
joschmeanwhile, when the pocket is not switching off, I finally finished my Factorio playthrough: https://floss.social/@josch/11467533502923362711:27
joschbox64 is really amazing -- it boggles my mind how a x86_64 game can run this well on arm64 and not even max out the processor11:27
minutejosch: what's the average time until this unintended shutdown? i guess upower/battery percentage is ruled out?11:28
joschminute: i just ran it 1.5 hours without issues -- it is unfortunately very random :(11:28
joschearlier i had it happen without batteries attached but pins 2&3 bridged, so maybe we can rule out the batteries11:29
joschi'll re-seat the rcore module as you suggested and perform more tests11:29
minutejosch: yes, sounds more isolated to the cpu or motherboard then11:30
joschthank you for your input -- luckily the pocket is "just" my experimenting/development device with no sensitive data on it. It would be a much, much bigger deal if my trusted A311D classic reform had such issues :D11:31
joschthe sudden power loss only ate two Factorio safegames which was the only really frustrating moment XD11:32
minutejosch: argh11:37
joschi'm now upgrading my pocket to the latest reform-tools and lpc driver and kernel11:40
joschreform-debian-packages pipeline finished an hour ago and the new versions are now in the MNT repository11:40
+ xha (~xha@user/xha)11:41
+ aakast (~aakast@87-49-44-126-mobile.dk.customer.tdc.net)11:45
+ mjw (~mjw@gnu.wildebeest.org)12:13
minutejosch: nice12:13
minutei'm back at a place with amd64 processor, can finally try that image12:14
minutebkeys: how exactly did you pass the dtb to fedora, can you give the exact command? (or screen photo thereof)12:14
joschawesome, let me know how your amd64 efi qemu experience goes -- but please remember that half the things i know about efi i only learned while implementing efi boot for the sysimages :D12:17
minutejosch: haha well i know even less12:22
+ paperManu (~paperManu@142.169.16.99)12:28
+ gustav28 (~gustav@c-78-82-55-148.bbcust.telenor.se)13:02
- arminweigl (QUIT: Ping timeout: 245 seconds) (~arminweig@sourcehut/user/arminweigl)13:06
- andreas-e (QUIT: Quit: Leaving) (~Andreas@2001:861:c4:f2f0::c64)13:10
+ arminweigl (~arminweig@sourcehut/user/arminweigl)13:16
- mjw (QUIT: Ping timeout: 244 seconds) (~mjw@gnu.wildebeest.org)13:23
bkeysminute: I went into UEFI shell and ran basically FS2:\vmlinuz-yadayada dtb=dtb\rockchip\rk3588-mnt-reform2.dtb13:31
* Guest448 -> mjw13:36
bkeysFedora uses initramfs not initrd13:47
joschminute: also, pocket reform does still not reliably switch off even though lpc and sysctl are latest13:53
+ jn (~quassel@2a0a-a54a-a3a6-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de)14:02
- jn (QUIT: Changing host) (~quassel@2a0a-a54a-a3a6-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de)14:02
+ jn (~quassel@user/jn/x-3390946)14:02
- paperManu (QUIT: Ping timeout: 248 seconds) (~paperManu@142.169.16.99)14:10
+ paperManu (~paperManu@2001:56b:9fe6:acf4:9411:af27:e377:a54)14:12
Zababkeys: the efi stub parameter name is still “initrd” even if it’s technically an initramfs 14:18
bkeysSo my exact command is FS1:\vmlinuz-6.14.0-63.fc42.aarch64 dtb=dtb\rockchip\rk3588-mnt-reform2.dtb initrd=initramfs-6.14.0-63.fc42.aarch64.img14:32
bkeysIn UEFI shell14:32
- paperManu (QUIT: Ping timeout: 272 seconds) (~paperManu@2001:56b:9fe6:acf4:9411:af27:e377:a54)14:37
+ chomwitt (~chomwitt@2a02:85f:9a08:a800:1ac0:4dff:fedb:a3f1)14:40
bkeysSame result, going to shop14:43
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net)14:49
+ bkeys (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net)14:49
bkeysjosch: I will try out your EFI image14:52
- bkeys (QUIT: Ping timeout: 260 seconds) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net)14:57
+ ericsfraga (~user@2a00:23cc:b45c:9001::99e)14:57
- ericsfraga (QUIT: Client Quit) (~user@2a00:23cc:b45c:9001::99e)15:01
+ andreas-e (~Andreas@2001:861:c4:f2f0::c64)15:02
+ ericsfraga (~user@2a00:23cc:b45c:9001::99e)15:03
+ bkeys (~Thunderbi@66.110.201.50)15:11
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)15:13
+ bkeys1 (~Thunderbi@66.110.201.50)15:13
* bkeys1 -> bkeys15:15
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50)15:18
+ bkeys (~Thunderbi@66.110.201.50)15:18
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)15:20
+ bkeys (~Thunderbi@66.110.201.50)15:21
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50)15:25
+ bkeys1 (~Thunderbi@66.110.201.50)15:25
* bkeys1 -> bkeys15:27
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)15:28
+ bkeys (~Thunderbi@66.110.201.50)15:29
bkeysjosch: EDK2 won't boot it15:31
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50)15:37
minutebkeys: the efi image is for amd64 only so far (or you mean a different one?)15:37
+ bkeys (~Thunderbi@66.110.201.50)15:38
minutejosch: that's very strange @ doesn't turn off15:38
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50)15:43
+ bkeys (~Thunderbi@66.110.201.50)15:44
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)15:44
+ bkeys (~Thunderbi@66.110.201.50)15:45
bkeysjosch: So just so I got this right, with this image https://source.mnt.re/reform/reform-system-image/-/jobs/10868/artifacts/raw/reform-system-any.img.gz?inline=false I should be able to write to a disk, boot from edk2 and it start up?15:45
- bkeys (QUIT: Ping timeout: 276 seconds) (~Thunderbi@66.110.201.50)15:50
+ bkeys (~Thunderbi@66.110.201.50)15:52
+ Core1951 (~aakast@net-93-65-57-194.cust.vodafonedsl.it)15:55
- aakast (QUIT: Read error: Connection reset by peer) (~aakast@87-49-44-126-mobile.dk.customer.tdc.net)15:55
+ bkeys1 (~Thunderbi@66.110.201.50)15:56
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50)15:57
* bkeys1 -> bkeys15:57
minutebkeys: that is an amd64 image. x86_64. not for reform15:57
minutebkeys: it's supposed to be used in QEMU on a pc15:57
minutejosch: the amd64 image works great here in qemu-kvm! very fast15:58
bkeysAh that explains it15:58
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50)15:58
+ bkeys1 (~Thunderbi@66.110.201.50)15:58
bkeys1I'm as american as it gets and I hate cars15:58
bkeys1minute: Is there an arm64 image of this somewhere?15:58
minutebkeys1: no15:58
minutejosch: also already found the first bug, setup wizard fails because there's no /proc/device-tree/model :D15:59
* bkeys1 -> bkeys16:00
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)16:03
+ bkeys (~Thunderbi@66.110.201.50)16:03
bkeysjosch: I'll be afk but if you would be willing to do an arm64 build of that image I'd love to try it16:11
- bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@66.110.201.50)16:15
- ericsfraga (QUIT: Read error: Connection reset by peer) (~user@2a00:23cc:b45c:9001::99e)16:15
+ mark_ (~mjw@gnu.wildebeest.org)16:15
+ ericsfraga (~user@2a00:23cc:b45c:9001::99e)16:16
joschminute: that's not the only thing that breaks. Turns out a lot of our stuff conditionalizes on /proc/device-tree/model. For example, the reform-hw-setup systemd service also fails for the same reason.16:18
minutejosch: alright!16:19
minutegotta catch them all16:19
joschminute: i'm not sure though -- i actually had a reason for make it fail in that case. In the past we had situations where there was an error in reform-hw-setup but the script was made *not* to fail so users were never told that something was wrong. So the question is: is reform-hw-setup running on amd64 something that is an "error" or not?16:24
joschWe could also special-case the architecture itself and let a bunch of these scripts error out right at the beginning if "$(dpkg --print-architecture)" = "amd64" or something16:25
minutejosch: reform-hw-setup failing on amd64 is fine for now16:40
+ bkeys (~Thunderbi@38-146-94-247.echocast.zone)16:40
- mark_ (QUIT: Ping timeout: 248 seconds) (~mjw@gnu.wildebeest.org)16:41
- bkeys (QUIT: Client Quit) (~Thunderbi@38-146-94-247.echocast.zone)16:42
+ bkeys (~Thunderbi@38-146-94-247.echocast.zone)16:42
+ bkeys1 (~Thunderbi@66.110.201.50)16:45
- bkeys (QUIT: Ping timeout: 260 seconds) (~Thunderbi@38-146-94-247.echocast.zone)16:46
* bkeys1 -> bkeys16:46
+ vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50)16:47
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50)16:50
+ bkeys (~Thunderbi@66.110.201.50)16:51
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)16:55
+ bkeys (~Thunderbi@66.110.201.50)16:56
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50)17:02
- b0 (QUIT: Read error: Connection reset by peer) (~b0@user/b0)17:02
+ paperManu_ (~paperManu@72.10.128.164)17:02
+ bkeys (~Thunderbi@66.110.201.50)17:02
+ b0 (~b0@user/b0)17:04
- ericsfraga (QUIT: Read error: Connection reset by peer) (~user@2a00:23cc:b45c:9001::99e)17:06
+ ericsfraga (~user@2a00:23cc:b45c:9001::99e)17:06
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50)17:11
+ bkeys (~Thunderbi@66.110.201.50)17:11
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)17:15
+ bkeys (~Thunderbi@66.110.201.50)17:15
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)17:18
+ bkeys1 (~Thunderbi@66.110.201.50)17:18
* bkeys1 -> bkeys17:20
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)17:22
+ bkeys (~Thunderbi@66.110.201.50)17:22
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50)17:24
+ bkeys (~Thunderbi@66.110.201.50)17:24
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50)17:31
+ bkeys (~Thunderbi@66.110.201.50)17:31
minutejosch: totally by chance find, maybe interesting for you https://github.com/infused-kim/kb_keycaps_trackpoint17:35
joschminute: this *is* interesting for me! :D17:40
joschthank you!17:40
joschwow, even with jlcpcb ordering instructions o017:40
joschand implemented in openscad!17:40
minutenoice17:41
joschwhat a great find! :D17:41
minutehappy to inspire :D17:41
joschminute: so, even with latest sysctl and lpc dkms firmware i do not get a clean power off with my rk3588 pocket. And I also regularly (every few minutes) get the click-click notification of gnome telling me that the power adapter was plugged in and out. I assume it works for you though?17:48
joschand now switched off and booted again after 1.5 hours of playing a 1080p video in clapper17:49
joschanother theory: could the random power off be connected with me having upgraded the sysctl recently?17:50
minutejosch: sure, i was thinking earlier that maybe it's the watchdog17:51
minutejosch: can you give me dmesg output of reloading the reform2-lpc module?17:51
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50)17:52
+ bkeys (~Thunderbi@66.110.201.50)17:52
joschminute: https://paste.debian.net/1379554/17:55
minutejosch: thanks!17:58
- ericsfraga (QUIT: Quit: ERC 5.6.1-git (IRC client for GNU Emacs 31.0.50)) (~user@2a00:23cc:b45c:9001::99e)17:58
minutejosch: so if you go to /sys and find . -name "firmware", there is one path that goes into spi1.1 or so, can you cat that and then also the other file "status" that is in the same dir?17:58
joschi already did that in the past -- this sounds like something reform-check could do automatically or do you think that would be too verbose?18:00
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50)18:01
+ bkeys (~Thunderbi@66.110.201.50)18:02
joschspi1.0/firmware: PREF1SYS R1 2025060918:03
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)18:04
joschstatus: 7.650V 1.187A 40% [status=0] [API=2]18:04
+ bkeys (~Thunderbi@66.110.201.50)18:04
minutejosch: aha, API=218:06
minutejosch: so this all looks good. can you make a bash loop to cat the firmware file 100 times? any issues?18:07
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)18:08
+ bkeys (~Thunderbi@66.110.201.50)18:08
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)18:09
joschi did a for i in $(seq 1000); do cat /sys/...; done | sort -u18:09
+ bkeys (~Thunderbi@66.110.201.50)18:09
joschand i get this: https://paste.debian.net/1379555/18:10
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50)18:25
minutejosch: interesting, but histogram would be more useful :D18:25
+ bkeys (~Thunderbi@66.110.201.50)18:25
minutejosch: in any case, delays are maybe too tight 18:25
joschminute: histogram was just done, sec18:26
joschminute: https://paste.debian.net/137955618:27
joschsometimes, running it 1000 times was fine so this one runs it 10000 times18:28
joschand for me searching the irc history later: for i in $(seq 10000); do cat /sys/devices/platform/feb10000.spi/spi_master/spi1/spi1.0/firmware; done | sort | uniq -c | sort -n18:28
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)18:28
+ bkeys (~Thunderbi@66.110.201.50)18:28
minutejosch: ok nice, so we are at 99.8% integrity :D18:31
minutejosch: if you add 1 ms to the delays in the lpc driver, reload the driver and run this again, does it change!18:32
minutes/!/?18:32
- bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@66.110.201.50)18:35
joschthe int delays[3] array? I can test in ~2 hours :)18:36
josch(this is all with oled off btw)18:37
+ bkeys (~Thunderbi@66.110.201.50)18:42
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50)18:43
minutejosch: yep, that array, api 2 version18:43
+ bkeys (~Thunderbi@66.110.201.50)18:43
joschah shoot i now see the if(data->api_version == 2) thank you -- i would've missed that18:45
- andreas-e (QUIT: Quit: Leaving) (~Andreas@2001:861:c4:f2f0::c64)18:55
- bkeys (QUIT: Ping timeout: 260 seconds) (~Thunderbi@66.110.201.50)19:02
+ bkeys (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net)19:12
+ aakast (~aakast@87-49-44-126-mobile.dk.customer.tdc.net)19:18
- chomwitt (QUIT: Ping timeout: 260 seconds) (~chomwitt@2a02:85f:9a08:a800:1ac0:4dff:fedb:a3f1)19:20
- Core1951 (QUIT: Ping timeout: 260 seconds) (~aakast@net-93-65-57-194.cust.vodafonedsl.it)19:20
bremnerprogress: connecting from the pocket reform, after a detour involving gpg and emacs;19:27
joschminute: still 99.89% success rate. Here is a copypaste of my terminal actions including a diff at the end in case i did something wrong: https://paste.debian.net/1379562/19:29
minutejosch: interesting, same amount huh19:38
minutejosch: what if 555?19:39
minutejosch: 5,5,5 i mean19:39
+ mark_ (~mjw@gnu.wildebeest.org)19:39
+ helgoman_ (~helgoman@178.38.121.62)19:49
+ chomwitt (~chomwitt@2a02:85f:9a08:a800:1ac0:4dff:fedb:a3f1)19:50
joschminute: essentially same result: 9982/10000 successes20:00
minutejosch: hrmpf20:02
minutejosch: thanks in any case, then i need to look into that more soon20:03
bkeysjosch: Sorry if you already responded, but how hard would it be for you to build a system image that doesn't have uboot at the front so I can test it on edk2?20:14
joschbkeys: not hard at all, one sec...20:14
joschbkeys: you just run ./mkimage --arch=arm64 --boot=efi reform-system-any20:14
joschbkeys: i can let the CI do that for you if you prefer?20:15
bkeysYeah let CI do it pls20:15
bkeysWhat I'll do for now is just use the system image on my NVME and I'll do fedora on an external drive until I have it refined20:15
bkeysI just want to use the rk3588 right now20:15
joschbkeys: this job should produce an arm64 efi image: https://source.mnt.re/reform/reform-system-image/-/jobs/1090420:21
bkeysThanks man I'll keep an eye on it and let you know20:21
* mjw -> Guest155120:29
- Guest1551 (QUIT: Killed (calcium.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c)20:29
* mark_ -> mjw20:29
+ Guest1551 (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c)20:30
minutejosch: bkeys: and how will this image know the dtb to load?20:31
bkeysThat's a josch question20:31
joschminute: the image contains /boot/EFI/BOOT/bootaa64.efi which was created using objcopy with a bunch of --add-section entries, most importantly /usr/lib/systemd/boot/efi, the kernel, initrd and the device tree all in one big executable blob (around 80 MB)20:35
minutejosch: wow ok20:37
bkeysjosch: I tried to boot it via edk2 and it didn't work until I went to UEFI shell and manually specify DTB and initrd21:11
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net)21:51
+ bkeys (~Thunderbi@173.186.16.211)21:52
- gustav28 (QUIT: Quit: Quit) (~gustav@c-78-82-55-148.bbcust.telenor.se)22:15
+ gustav28 (~gustav@c-78-82-55-148.bbcust.telenor.se)22:20
+ arminweigl_ (~arminweig@sourcehut/user/arminweigl)22:35
- arminweigl (QUIT: Ping timeout: 276 seconds) (~arminweig@sourcehut/user/arminweigl)22:36
* arminweigl_ -> arminweigl22:36
- arminweigl (QUIT: Ping timeout: 252 seconds) (~arminweig@sourcehut/user/arminweigl)22:54
bkeysjosch: Do you know how to print out the used device tree from the command line?23:01
+ arminweigl (~arminweig@sourcehut/user/arminweigl)23:06
* f_ -> funderscore23:12
- bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@173.186.16.211)23:18
- gustav28 (QUIT: Quit: Quit) (~gustav@c-78-82-55-148.bbcust.telenor.se)23:24
+ bkeys (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net)23:26

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!