<samueldr>
seems like it's still in the source code on a recent master checkout
<samueldr>
so I guess it's undocumented?
<samueldr>
though, it's part of vgacon (drivers/video/console/vgacon.c)
<samueldr>
don't know if that's generic enough to go to arm too
<alex_giusi_tiri>
thank you. would there be another way to disable it, that you know of? the problem is that I couldn't make neither vga= nor video= work. btw, should kms be enabled or disabled to make vga= or video= work? or, would kms be automatically activated if either is specified? how do they all interact, that you know of?
<samueldr>
I wouldn't know for sure
<samueldr>
first off, is it using KMS? what platform is it for?
<samueldr>
and what part of KMS is causing issue, that you want to disable it?
<alex_giusi_tiri>
I think it is using KMS
<alex_giusi_tiri>
I see the U-Boot menu, and kernel boot messages, but at some point (where I think KMS gets activated), I see some flickering for some seconds, and then there is no more display output
<samueldr>
right, so from simplefb (I presume) to *something else*
<alex_giusi_tiri>
normally, everything works as expected at higher clock rates, but I am running every clock as low as I can
<samueldr>
alex_giusi_tiri: what platform is it?
<alex_giusi_tiri>
sorry, armv7l
<samueldr>
which board, then :)
<alex_giusi_tiri>
:-) raspberrypi 3b (no +)
<samueldr>
right, mainline kernel or not?
<alex_giusi_tiri>
yes
<samueldr>
(yes meaning it is mainline?)
<samueldr>
if it's mainline, yes it's vc4 and it's KMS
<alex_giusi_tiri>
yes, sorry, it's mainline
<samueldr>
good
<samueldr>
do you have serial access?
<samueldr>
right... 3b... why are you running armv7l?
<alex_giusi_tiri>
I have a screen+kb+mouse (+eth)
<samueldr>
(not that there's anything wrong, mostly curious, as armv7l is lesser supported than aarch640
<samueldr>
aarch64*
<alex_giusi_tiri>
I wanted to conserve some ram
<samueldr>
I haven't checked, so I may be wrong, but I'm not sure the host architecture has that much of an impact on ram usage
<alex_giusi_tiri>
As far as I read a 32-bit architecture would use half as much ram as a 64-bit one, and this board only has so much
<samueldr>
additionally, the kernel and userland can't make use of aarch64 specific instructions and specifics
<alex_giusi_tiri>
I wasn't really looking for hardware acceleration. In fact, I was planning to switch it to soft floating point
<alex_giusi_tiri>
if that is what you meant
<alex_giusi_tiri>
:-)
<samueldr>
anything that's not part of armv7, but part of aarch64, so I don't really know :)
<alex_giusi_tiri>
that's ok
<samueldr>
you could try blacklisting the vc4 kernel module, but I'm not sure what's the best approach would be
<samueldr>
and if it even works
<samueldr>
information is hard to come by about the mainline kernel due to search results all being about the foundation's kernel
<alex_giusi_tiri>
the thing is that I am running everything at very low clock speeds; normal rates work
<alex_giusi_tiri>
the linux foundation has its own version?
<samueldr>
the raspberry pi foundation
<alex_giusi_tiri>
:-?
<alex_giusi_tiri>
oh
<samueldr>
what you get on raspbian is not the mainline kernel, but the raspberry pi foundation's own fork
<samueldr>
rephrasing, just in case; the kernel module that ends up managing the display is vc4, so you may want to try blacklisting it
<alex_giusi_tiri>
i just read it as the *linux* foundation
<alex_giusi_tiri>
:-)
<alex_giusi_tiri>
yes, thank you! i will try it
<alex_giusi_tiri>
uh, how?..
<alex_giusi_tiri>
I didn't manage to rebuild since a while
<alex_giusi_tiri>
I think I only managed to add 2 more boot versions
<alex_giusi_tiri>
it always manages to give one error or another
<samueldr>
you could try adding module_blacklist=vc4 to the kernel command line
<alex_giusi_tiri>
yes, that could try
<alex_giusi_tiri>
yes, that *I* could try
<alex_giusi_tiri>
thank you
<samueldr>
as far as ram usage, other than pointer types, most types are not dependent on the architecture; most ram use is not pointers, so AFAIUI ram usage should be in the same ballpark, definitely not 2× more; same as x86_64 vs. i686
<alex_giusi_tiri>
yeah, I think what I was reading was about pointers
<alex_giusi_tiri>
I first tried aarch64, but now, I don't remember the avg ram usage then
<alex_giusi_tiri>
I think it was the same as noe
<alex_giusi_tiri>
now*
<alex_giusi_tiri>
rather, for arm32
<alex_giusi_tiri>
samueldr: it worked. :-) thank you!
<alex_giusi_tiri>
at least, now I have a console!
alex_giusi_tiri has left #nixos-aarch64 [#nixos-aarch64]
zupo has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
t184256 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
jtojnar has quit [Quit: jtojnar]
jtojnar has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
grw has quit [Ping timeout: 245 seconds]
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #nixos-aarch64
grw has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
alex_giusi_tiri has joined #nixos-aarch64
orivej has quit [Ping timeout: 244 seconds]
ryantrinkle has quit [Ping timeout: 244 seconds]
orivej has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
{`-`} has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
wildtrees has joined #nixos-aarch64
THFKA4 has joined #nixos-aarch64
THFKA4 has quit [Changing host]
marek has joined #nixos-aarch64
Thra11 has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 258 seconds]
nixpi has joined #nixos-aarch64
nixpi has left #nixos-aarch64 [#nixos-aarch64]
ryantrinkle has joined #nixos-aarch64
aegre has joined #nixos-aarch64
<aegre>
hello I have a rpi 3 model b and tried to flash/run this image https://hydra.nixos.org/build/98585733 but the green LED is repeatedly blinking twice. What does this mean/how do I recover?
<aegre>
I don't think it's an sd card issue because I just tried to flash raspbian buster and the green LED showed a different pattern
<aegre>
I also enabled "console=ttyS1,115200n8" in extlinux.conf and screen is terminating when I try to connect
<samueldr>
LED patterns, and no serial output, sounds like "something" is wrong with the SD card
<samueldr>
though I wouldn't necessarily think it is, just a thing to try
<aegre>
hmm, yeah might do, however I haven't given up hope for raspbian yet.. the green flashing is just like once every so ofthen, it's mostly off
<aegre>
which might be due to sd card writes
<aegre>
so my plan tonight is to see if I can connect to ssh or something
<aegre>
(don't know how to enable serial in raspbian without a screen.. catch 22)
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<aegre>
can't test it now because no wifi
<aegre>
thanks for your help so far!
ryantrinkle has quit [Ping timeout: 258 seconds]
<Thra11>
Has anyone ever tried using "fdt overlays" (snippets which u-boot loads to extend device tree binaries at boot) with nixos?
<samueldr>
not yet, but it may have issues with how the extlinux config is loaded with u-boot
<samueldr>
it will load a device tree from FDTDIR
<samueldr>
which I don't know if it will completely obliterate overlays loaded beforehand
<Thra11>
ok
<samueldr>
just something to keep in mind
aegre has quit [Ping timeout: 260 seconds]
<samueldr>
if it's for the raspberry pi, also keep in mind that overlays may not work with the mainline kernel
<Thra11>
I'll probably just patch the dts for now
<samueldr>
the device trees on the raspberry pi foundation's kernels are different than on mainline
<Thra11>
(It's my orange pi zero plus 2) Found some dt-overlays (armbian again), one of which should enable spidev.
<samueldr>
I haven't had much success yet with device tree stuff, but that's mainly because I still have tons to learn
<Thra11>
I don't really need the ability to turn it on and off though, so I'll keep things simple and patch the dts instead
<samueldr>
(and am going against the grain with the mainline kernel)
<samueldr>
I should maybe just make it work with the foundation's kernel, to at least know the approach is right, then fix the dtbo for mainline afterwards
<Thra11>
In theory, NixOS might be able to install a bunch of fdt overlays, and write whatever file it is which tells u-boot which overlays to load.
<samueldr>
I'm pretty sure you're interested in those changes
<samueldr>
like... you want to use those already, but just didn't know it
<Thra11>
:)
<samueldr>
I should just merge it (once I re-read it since it was updated)
<samueldr>
it all worked, the only reason I didn't merge it was because I couldn't get the thing working... but the dtb was properly merged and everything
<samueldr>
(and a good improvement following that PR could be to have a generic config for u-boot to expose the most recent dtbs dir in the /boot partition for better EFI support, e.g. on the pinebook)
<Thra11>
I'll try it out tomorrow. See if it works for me.