tilpner_ has joined #nixos-aarch64
tilpner has quit [Ping timeout: 244 seconds]
ryantrinkle has quit [Ping timeout: 272 seconds]
mog has quit [Ping timeout: 276 seconds]
mog has joined #nixos-aarch64
<alex_giusi_tiri> Hi! I can't seem to disable Kernel Mode Setting with v4.19.26 on an armv7l. I cannot find "nomodeset" in the kernel parameter list (https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt or https://www.kernel.org/doc/html/v4.19/search.html?q=nomodeset&check_keywords=yes&area=default). Has it been removed since a certain kernel version?
<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
<samueldr> hm
<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> two sounds like the card cannot be read
<samueldr> what (full) command did you use to flash the .img file to the sd card?
aegre has quit [Ping timeout: 260 seconds]
zupo has joined #nixos-aarch64
ris has joined #nixos-aarch64
aegre has joined #nixos-aarch64
<aegre> sorry disconnected, but thanks to your logs I got the history
<aegre> sudo dd if=nixos-sd-image-19.03.173251.56d94c8c69f-aarch64-linux.img of=/dev/mmcblk0
<aegre> was the flashing command
<aegre> I can mount the partitions on my PC fine though
<aegre> is there maybe some setting the card is missing?
<aegre> https://pastebin.com/hpN50zjq fdisk output
aegre has quit [Ping timeout: 260 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
dispanser has joined #nixos-aarch64
aegre has joined #nixos-aarch64
jtojnar has quit [Ping timeout: 272 seconds]
<aegre> uh oh I think it's a hardware issue .. Q5 is missing and Q2 is disconnected :(
<aegre> but, with the raspbian image (the one that showed less/different flashing) the partition layout is different https://pastebin.com/dmCbugwE
<aegre> it still does even with those hardware pieces missing (which I guess is related to HDMI output)
<samueldr> q2/q5 on the raspberry pi? though I guess it would also make raspbian fail, not only nixos
<samueldr> the layout is different, and that should be fine
<aegre> yeah, do you know what q2/q5 control?
<samueldr> no idea
<samueldr> the raspberry pi does not look for a particular offset, but looks for files on the first FAT32 partition it finds
<samueldr> (or was it the first it finds having the right files? I could lookup the fine manual)
<samueldr> anyway, when it finds a partition, the flashing pattern is different if it cannot read the files it needs from it
<samueldr> so, from the earlier link, 2 flashes seem like it can't read the sd card :/
<samueldr> I would try using f3 to test the whole card in case it somehow is defective
<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> ...
<samueldr> wait a minute Thra11
<Thra11> waiting...
<{^_^}> #60422 (by kwohlfahrt, 14 weeks ago, open): nixos/hardware.deviceTree: new module
<samueldr> I said "a minute", on the nose :)
<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.
wildtrees has quit [Quit: Leaving]
Thra11 has quit [Quit: WeeChat 2.5]
orivej has quit [Ping timeout: 245 seconds]
ryantrinkle has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 258 seconds]
Acou_Bass has joined #nixos-aarch64