- aakast (QUIT: Ping timeout: 276 seconds) (~aakast@net-93-65-57-194.cust.vodafonedsl.it) | 00:30 | |
minute | bkeys: i think you can copy the file using uefi shell | 00:58 |
---|---|---|
bkeys | minute: I'll try that | 00:58 |
minute | it has copy command, and text editor, everything | 00:58 |
kfx | is 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 | |
bkeys | minute: For some reason it "failed to open with create." whatever that means | 01:21 |
bkeys | Heaven forbid a cp command work | 01:21 |
minute | kfx: yes. can your uart adapter do that? some can't | 01:23 |
kfx | ah, the cp2102 can't go that fast. guess I'll find something else to order | 01:25 |
kfx | looks 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 | |
minute | bkeys: 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 | |
bkeys | minute: I copied it in Linux, the dtb file is physically there but I'm not sure the Fedora kernel is picking itu p | 02:29 |
bkeys | I 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 there | 02: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_ -> arminweigl | 03:35 | |
- exark (QUIT: Quit: quit) (~exark@user/exark) | 03:37 | |
+ exark (~exark@user/exark) | 03:39 | |
bkeys | Hmm, 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 dies | 03:47 |
bkeys | I'll have to ask the guys in #fedora-arm what's up, but this can wait for tomorrow | 03: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 | |
gsora | iirc there’s a way to fix the baud rate weirdness on rk3588 | 09:31 |
gsora | like, setting it to 115200, I have notes at home, will share later | 09:32 |
+ Ar|stote|is (~linx@149.210.5.33) | 09:35 | |
josch | on 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 | |
gsora | surely it’s faster :D | 09:50 |
josch | minute: 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 | |
minute | josch: any discernible pattern? | 10:05 |
josch | minute: i wish. My next test will be with ssd and wifi disconnected and just idling from a fresh sd-card image. | 10:10 |
josch | the only correlation i have that this started happening after i switched the battery cells | 10:11 |
josch | but since it also happens without the battery board connected, that's probably just correclation and not causation | 10:11 |
josch | and 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 | |
minute | josch: 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_ -> arminweigl | 10:46 | |
gsora | re: waybar battery monitor, using upower matches 1:1 what the oled display reports | 11:21 |
josch | minute: okay, i'll try that thank you | 11:26 |
josch | meanwhile, when the pocket is not switching off, I finally finished my Factorio playthrough: https://floss.social/@josch/114675335029233627 | 11:27 |
josch | box64 is really amazing -- it boggles my mind how a x86_64 game can run this well on arm64 and not even max out the processor | 11:27 |
minute | josch: what's the average time until this unintended shutdown? i guess upower/battery percentage is ruled out? | 11:28 |
josch | minute: i just ran it 1.5 hours without issues -- it is unfortunately very random :( | 11:28 |
josch | earlier i had it happen without batteries attached but pins 2&3 bridged, so maybe we can rule out the batteries | 11:29 |
josch | i'll re-seat the rcore module as you suggested and perform more tests | 11:29 |
minute | josch: yes, sounds more isolated to the cpu or motherboard then | 11:30 |
josch | thank 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 :D | 11:31 |
josch | the sudden power loss only ate two Factorio safegames which was the only really frustrating moment XD | 11:32 |
minute | josch: argh | 11:37 |
josch | i'm now upgrading my pocket to the latest reform-tools and lpc driver and kernel | 11:40 |
josch | reform-debian-packages pipeline finished an hour ago and the new versions are now in the MNT repository | 11: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 | |
minute | josch: nice | 12:13 |
minute | i'm back at a place with amd64 processor, can finally try that image | 12:14 |
minute | bkeys: how exactly did you pass the dtb to fedora, can you give the exact command? (or screen photo thereof) | 12:14 |
josch | awesome, 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 :D | 12:17 |
minute | josch: haha well i know even less | 12: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 | |
bkeys | minute: I went into UEFI shell and ran basically FS2:\vmlinuz-yadayada dtb=dtb\rockchip\rk3588-mnt-reform2.dtb | 13:31 |
* Guest448 -> mjw | 13:36 | |
bkeys | Fedora uses initramfs not initrd | 13:47 |
josch | minute: also, pocket reform does still not reliably switch off even though lpc and sysctl are latest | 13: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 | |
Zaba | bkeys: the efi stub parameter name is still “initrd” even if it’s technically an initramfs | 14:18 |
bkeys | So 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.img | 14:32 |
bkeys | In UEFI shell | 14: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 | |
bkeys | Same result, going to shop | 14: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 | |
bkeys | josch: I will try out your EFI image | 14: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 -> bkeys | 15: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 -> bkeys | 15:27 | |
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 15:28 | |
+ bkeys (~Thunderbi@66.110.201.50) | 15:29 | |
bkeys | josch: EDK2 won't boot it | 15:31 |
- bkeys (QUIT: Quit: With every step we take, danger will follow closely) (~Thunderbi@66.110.201.50) | 15:37 | |
minute | bkeys: 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 | |
minute | josch: that's very strange @ doesn't turn off | 15: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 | |
bkeys | josch: 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 -> bkeys | 15:57 | |
minute | bkeys: that is an amd64 image. x86_64. not for reform | 15:57 |
minute | bkeys: it's supposed to be used in QEMU on a pc | 15:57 |
minute | josch: the amd64 image works great here in qemu-kvm! very fast | 15:58 |
bkeys | Ah that explains it | 15:58 |
- bkeys (QUIT: Read error: Connection reset by peer) (~Thunderbi@66.110.201.50) | 15:58 | |
+ bkeys1 (~Thunderbi@66.110.201.50) | 15:58 | |
bkeys1 | I'm as american as it gets and I hate cars | 15:58 |
bkeys1 | minute: Is there an arm64 image of this somewhere? | 15:58 |
minute | bkeys1: no | 15:58 |
minute | josch: also already found the first bug, setup wizard fails because there's no /proc/device-tree/model :D | 15:59 |
* bkeys1 -> bkeys | 16:00 | |
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 16:03 | |
+ bkeys (~Thunderbi@66.110.201.50) | 16:03 | |
bkeys | josch: I'll be afk but if you would be willing to do an arm64 build of that image I'd love to try it | 16: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 | |
josch | minute: 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 |
minute | josch: alright! | 16:19 |
minute | gotta catch them all | 16:19 |
josch | minute: 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 |
josch | We 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 something | 16:25 |
minute | josch: reform-hw-setup failing on amd64 is fine for now | 16: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 -> bkeys | 16: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 -> bkeys | 17: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 | |
minute | josch: totally by chance find, maybe interesting for you https://github.com/infused-kim/kb_keycaps_trackpoint | 17:35 |
josch | minute: this *is* interesting for me! :D | 17:40 |
josch | thank you! | 17:40 |
josch | wow, even with jlcpcb ordering instructions o0 | 17:40 |
josch | and implemented in openscad! | 17:40 |
minute | noice | 17:41 |
josch | what a great find! :D | 17:41 |
minute | happy to inspire :D | 17:41 |
josch | minute: 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 |
josch | and now switched off and booted again after 1.5 hours of playing a 1080p video in clapper | 17:49 |
josch | another theory: could the random power off be connected with me having upgraded the sysctl recently? | 17:50 |
minute | josch: sure, i was thinking earlier that maybe it's the watchdog | 17:51 |
minute | josch: 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 | |
josch | minute: https://paste.debian.net/1379554/ | 17:55 |
minute | josch: 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 | |
minute | josch: 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 |
josch | i 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 | |
josch | spi1.0/firmware: PREF1SYS R1 20250609 | 18:03 |
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 18:04 | |
josch | status: 7.650V 1.187A 40% [status=0] [API=2] | 18:04 |
+ bkeys (~Thunderbi@66.110.201.50) | 18:04 | |
minute | josch: aha, API=2 | 18:06 |
minute | josch: 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 | |
josch | i did a for i in $(seq 1000); do cat /sys/...; done | sort -u | 18:09 |
+ bkeys (~Thunderbi@66.110.201.50) | 18:09 | |
josch | and 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 | |
minute | josch: interesting, but histogram would be more useful :D | 18:25 |
+ bkeys (~Thunderbi@66.110.201.50) | 18:25 | |
minute | josch: in any case, delays are maybe too tight | 18:25 |
josch | minute: histogram was just done, sec | 18:26 |
josch | minute: https://paste.debian.net/1379556 | 18:27 |
josch | sometimes, running it 1000 times was fine so this one runs it 10000 times | 18:28 |
josch | and 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 -n | 18:28 |
- bkeys (QUIT: Client Quit) (~Thunderbi@66.110.201.50) | 18:28 | |
+ bkeys (~Thunderbi@66.110.201.50) | 18:28 | |
minute | josch: ok nice, so we are at 99.8% integrity :D | 18:31 |
minute | josch: if you add 1 ms to the delays in the lpc driver, reload the driver and run this again, does it change! | 18:32 |
minute | s/!/? | 18:32 |
- bkeys (QUIT: Ping timeout: 252 seconds) (~Thunderbi@66.110.201.50) | 18:35 | |
josch | the 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 | |
minute | josch: yep, that array, api 2 version | 18:43 |
+ bkeys (~Thunderbi@66.110.201.50) | 18:43 | |
josch | ah shoot i now see the if(data->api_version == 2) thank you -- i would've missed that | 18: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 | |
bremner | progress: connecting from the pocket reform, after a detour involving gpg and emacs; | 19:27 |
josch | minute: 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 |
minute | josch: interesting, same amount huh | 19:38 |
minute | josch: what if 555? | 19:39 |
minute | josch: 5,5,5 i mean | 19: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 | |
josch | minute: essentially same result: 9982/10000 successes | 20:00 |
minute | josch: hrmpf | 20:02 |
minute | josch: thanks in any case, then i need to look into that more soon | 20:03 |
bkeys | josch: 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 |
josch | bkeys: not hard at all, one sec... | 20:14 |
josch | bkeys: you just run ./mkimage --arch=arm64 --boot=efi reform-system-any | 20:14 |
josch | bkeys: i can let the CI do that for you if you prefer? | 20:15 |
bkeys | Yeah let CI do it pls | 20:15 |
bkeys | What 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 refined | 20:15 |
bkeys | I just want to use the rk3588 right now | 20:15 |
josch | bkeys: this job should produce an arm64 efi image: https://source.mnt.re/reform/reform-system-image/-/jobs/10904 | 20:21 |
bkeys | Thanks man I'll keep an eye on it and let you know | 20:21 |
* mjw -> Guest1551 | 20:29 | |
- Guest1551 (QUIT: Killed (calcium.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 20:29 | |
* mark_ -> mjw | 20:29 | |
+ Guest1551 (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 20:30 | |
minute | josch: bkeys: and how will this image know the dtb to load? | 20:31 |
bkeys | That's a josch question | 20:31 |
josch | minute: 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 |
minute | josch: wow ok | 20:37 |
bkeys | josch: I tried to boot it via edk2 and it didn't work until I went to UEFI shell and manually specify DTB and initrd | 21: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_ -> arminweigl | 22:36 | |
- arminweigl (QUIT: Ping timeout: 252 seconds) (~arminweig@sourcehut/user/arminweigl) | 22:54 | |
bkeys | josch: 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_ -> funderscore | 23: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/!