bennofs has joined #nixos-aarch64
<bennofs> How hardware-specific is stuff like serial out is on ttyS2? For my rock64 board, I needed to edit the extlinux.conf to console=ttyS2, will this be the same for all rock64 boards?
<bennofs> btw, who decides what ttyS2 is? is it dependent on the device tree?
<samueldr> specific often to the range of hardware
<samueldr> so like everything with that rockchip are likely to use that ttyS* for serial
<samueldr> (in my experience)
<bennofs> so I think it makes sense to mention that you need ttyS2 in the NixOS rock64 wiki article?
<samueldr> I think so too
<samueldr> though for some boards it's been known to change, I guess due to how the kernel names them and order of allocation
<samueldr> mainly, the raspberry pi 3 family
<bennofs> i would guess it changes if you change the device tree
<bennofs> is there a way to pass the serial console from uboot to the linux kernel?
<bennofs> because uboot already knows where the serial console is that it currently uses, should be possible to just use that
<samueldr> not that I know of
<samueldr> but that is an interesting thought
<bennofs> the console=uart8250,mmio32,0xff130000 setting might work if uboot can give use the address of the mmio mapping
<bennofs> has the added benefit of providing early uart
<samueldr> yeah, that's what I was thinking, though not looking into anything
<bennofs> but it might be hard to pass kernel options from uboot through extlinux?
<samueldr> though it would be good if the kernel also added predictable naming for serial interfaces
<samueldr> might be, not sure
* samueldr checks
<samueldr> though u-boot's source is relatively straightforward
<bennofs> wait, extlinux also knows the console. because the extlinux menu works, even if the console= setting is wrong
<samueldr> it's u-boot
<samueldr> not extlinux
<samueldr> it's simply the file format of
<bennofs> ah, I always forget. you are right of course
<samueldr> I try to be :)
* samueldr is tracking down the source bits
<samueldr> while straightforward, woof sometimes it's ugly
<samueldr> interesting, it should be able to handle "bmp" backgrounds
<samueldr> (likely not only bmp)
<samueldr> looking at the source, it would be relatively trivial to add something that does an env_get() on a given environment variable to append to the extlinux bootargs
<samueldr> this is where APPEND is being consumed
<samueldr> it always overwrites the contents of bootargs
<bennofs> samueldr: it calls cli_simple_process_macros before that though
<samueldr> ooh, only quickly looked
<bennofs> and macros can be like ${uboot_var} if I understand correctly
<samueldr> that looks about right
<samueldr> oooooh
<samueldr> tilpner: I don't remember, do you have your pinebook a64 config up somewhere?
<samueldr> I'm about to publish mine, and wanted to compare notes
<samueldr> though I already am using your wifi driver derivation
h0m1 has quit [Ping timeout: 245 seconds]
h0m1 has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 250 seconds]
Acou_Bass has joined #nixos-aarch64
zupo has joined #nixos-aarch64
THFKA4 has quit [Ping timeout: 276 seconds]
zupo has quit [Ping timeout: 240 seconds]
THFKA4 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
v0|d has quit [Ping timeout: 250 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Acou_Bass has quit [Quit: ZNC 1.7.4 - https://znc.in]
Acou_Bass has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
bennofs has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
bennofs has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
DigitalKiwi has quit [Quit: quite.]
DigitalKiwi has joined #nixos-aarch64
<tilpner> samueldr: Sorry, no, I never got it working perfectly :(
Piece_Maker has joined #nixos-aarch64
Acou_Bass has quit [Quit: ZNC 1.7.4 - https://znc.in]
Piece_Maker is now known as Acou_Bass
orivej has quit [Ping timeout: 245 seconds]
ryantrinkle has quit [Ping timeout: 265 seconds]
<bennofs> does anyone know if SBC usually have hardware watchdogs?
<gchristensen> I know they often do
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 245 seconds]
zupo has joined #nixos-aarch64
<bennofs> gchristensen: do you have some pointers how to enable them? I'd guess uboot needs support for that?
<gchristensen> not sure exactly, I know systemd supports using a watchdog
<gchristensen> it'd be specific to your board
<clever> bennofs: i know the rpi has a watchdog, and there is full linux support, and the daemon will only prod it when certain conditions are met
<andi-> systemd has some interface or watchdogs as long as they are "uniform" in terms of some kernel API IIRC
andi- has quit [Ping timeout: 276 seconds]
LnL has quit [Ping timeout: 240 seconds]
LnL has joined #nixos-aarch64
LnL has quit [Changing host]
LnL has joined #nixos-aarch64
andi- has joined #nixos-aarch64
orivej has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 250 seconds]
ryantrinkle has quit [Ping timeout: 240 seconds]
ryantrinkle has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
THFKA4 has joined #nixos-aarch64
THFKA4 has quit [Changing host]
zupo has joined #nixos-aarch64
<samueldr> tilpner: no worries, I was just hoping for additional tricks I could have missed :)
<tilpner> samueldr: Did you push it yet?
<samueldr> soon will, dealing with Multi_Key → Super in a reproducible manner
orivej has joined #nixos-aarch64
<DigitalKiwi> so opencascade fails to build is it possible to fix you think?
<DigitalKiwi> (it's a dependency of at the least kicad)
<samueldr> dunno, depends on what the failure is
<DigitalKiwi> /nix/store/w2dbyz9m2dnk2x3hrf48y9hbmmn7hxg6-binutils-2.31.1/bin/ld: /nix/store/vqjhbbhr8kndl42k91fmxmqid6g1van9-freeimage-3.18.0/lib/libfreeimage.so: undefined reference to `png_init_filter_functions_neon'
<samueldr> a list of things I like to do when there is a failure on aarch64
<samueldr> 0. check on x86_64
<samueldr> (last two rows show the right package)
<samueldr> [relatedly, it'd be nice to have more linkable pages in hydra, rather than use the xhr endpoints]
<samueldr> here it is limited to the proper job with an ending dot https://hydra.nixos.org/jobset/nixpkgs/trunk/jobs-tab?filter=opencascade.
<samueldr> next step I do generally is look at if it passed previously
<samueldr> so I follow the link, use the More... link on the resulting page, and page through a couple pages
<samueldr> it did pass at some point
<samueldr> then, I choose the first failing build
<samueldr> check if it's the same issue
<samueldr> >> /nix/store/7k79xbwi86nidycbqk921xff5ff2yh7d-binutils-2.31.1/bin/ld: /nix/store/fhz7s8x7hmiqlcc9vza4ir9rxm679gsg-freeimage-3.17.0/lib/libfreeimage.so: undefined reference to `png_init_filter_functions_neon'
<samueldr> great, we have a range of Changes, right there on that build page!
<samueldr> within those commits, there's this PR merge... without even bisecting sometimes intuition is strong
<samueldr> let's revert to see if it's a red herring or not
* samueldr waits on a build
<DigitalKiwi> see this is why i ask you i'd have taken much longer to figure it out :P
<DigitalKiwi> in fact i'd already spent much longer failing to ;(
<samueldr> whew! finally got that key wrangled up
<samueldr> btw
<samueldr> I already have a strong intuition that it's an ARM specific bug
<samueldr> not only due to it failing on ARM only :)
<samueldr> but the fact that it refers to a *_neon function
<samueldr> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0002a/BABIIFHA.html
<DigitalKiwi> yeah the research i did turned up a bunch of other projects that had to patch stuff
<samueldr> though it may be that the failure is in one of the new dependency from that PR
<samueldr> with the imported overlay for the kernel
<samueldr> the only issue I'm having with it is that *sometimes* the display doesn't init on boot
<samueldr> that needs a reboot
<samueldr> (u-boot inited it, but the kernel could not)
<samueldr> and *sometimes* it fails to wake the display, but having it go back to sleep, then try to wake it back will work
<tilpner> Aww, no graphics black-magic >.>
<samueldr> ?
<samueldr> ah, LIMA doesn't work yet for me
<samueldr> but that might be due to me not knowing something to make it work fine
<samueldr> that's something to fix still
<tilpner> That, or the bootlin blobs, or video decoding
<samueldr> bootlin blobs?
<tilpner> The proprietary drivers
<tilpner> But don't waste your time on that
orivej has quit [Ping timeout: 240 seconds]
lopsided98 has quit [Remote host closed the connection]
lopsided98 has joined #nixos-aarch64
<samueldr> yeah, I really need to find some *up to date* info about Lima and mainline
<samueldr> reading about it it may be that mesa needs to be updated?
<samueldr> after all, linux-side everything seemed fine, VTs worked with DRM_LIMA
<samueldr> only X11 (that I tried) failed
<samueldr> DigitalKiwi: building with that PR reverted builds
<samueldr> so there you have a starting point for intestigation
<samueldr> 1. who uses that _neon function? opencascade or a dependency that was added with that PR
<samueldr> 2. is it something that's been fixed upstream through detection? are we missing a feature flag?
<DigitalKiwi> the other bug reports i saw were related to libpng and stuff
<DigitalKiwi> which i guess is part of libfreeimage?
<samueldr> libfreeimage is likely to be using libpng
<samueldr> or not
<samueldr> oof oof oof oof
<samueldr> no
<samueldr> it's seemingly embedding _a_ libpng
<samueldr> at least it looks like they keep it updated
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 276 seconds]
tilpner has quit [Ping timeout: 252 seconds]
tilpner has joined #nixos-aarch64