nicoo has quit [Remote host closed the connection]
bennofs_ has joined #nixos-aarch64
nicoo has joined #nixos-aarch64
{`-`} has joined #nixos-aarch64
bennofs__ has quit [Ping timeout: 265 seconds]
{`-`} has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
apache8080 has joined #nixos-aarch64
superherointj has quit [Quit: Leaving]
<samueldr>
clever: can you confirm that gpu_mem is not needed when vc4 fkms?
<apache8080>
When I use buildLinux to build my kernel it adds additional configs and removes certain configs from the vendor defconfig and that is causing compile errors that don't happen with the vendor defconfig
<samueldr>
because AFAIUI gpu_mem is memory reserved for gpu usage, unable to be used by the linux side of things, but with fkms, the rendering happens on the linux side of things
<samueldr>
apache8080: most likely the vendor's defconfig "is fake", in that if you were to open it in make menuconfig, and save it without updating it it would do the same changes, I would bet
<samueldr>
I think that because of how you said there were two Kconfig files setting the same option
<apache8080>
yeah, so the vendor says just run make their_defconfig and then make to build the image, if menuconfig never gets run is there a way I can figure out the config that actually gets used by the vendor
<samueldr>
(I could still be wrong)
<apache8080>
I think the issue is on the modules, running generate config adds a bunch modules with the m option since CONFIG_MODULES=y and that causes things to build that shouldn't build
<apache8080>
but could be wrong
<samueldr>
oh, depends on if the default config thing for NixOS answers "default answer" for everything, which ends up often being =m
<apache8080>
we have a way of doing things on our other boards but we wanted to move to the way upstream builds the kernel so we don't have to hack around so much
<samueldr>
but I also do "bad" things :)
<samueldr>
where I force the kernel config given to be identical
<samueldr>
(except some hand-picked options that conflict when compiler version changes)
<samueldr>
so if you were to give a defconfig it surely would fail
<apache8080>
yeah we do some sketchy stuff like that, we get a pre built kernel from the vendor and then extract the config, then have some custom python script that add our own config on top
<samueldr>
BUT, this ensures the kernel config is always completely honest!
<apache8080>
ok looks like setting autoModules to false solved some of it
<apache8080>
lets see if it builds
patagonicus18 has joined #nixos-aarch64
<samueldr>
there's still the make oldconfig that could be causing troubles
<samueldr>
*could* :)
<samueldr>
but yeah, if the config was going through the "answer machinery" there, that's even "worse" (better?)
patagonicus1 has quit [Ping timeout: 240 seconds]
patagonicus18 is now known as patagonicus1
<apache8080>
looks like it built
<apache8080>
autoModules = false, for certain vendors does the trick lol
h0m1 has quit [Ping timeout: 260 seconds]
orivej has quit [Ping timeout: 268 seconds]
h0m1 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
apache8080 has quit [Ping timeout: 240 seconds]
<clever>
samueldr: now that i think about it, i dont know where fkms gets its framebuffer from....
<clever>
but i can find out!
<samueldr>
the great framebuffer tree
<samueldr>
(I'm not serious)
<clever>
i wrote custom utils to dump the HVS config
<clever>
that will tell me exactly what address the framebuffer is at, no matter what driver stack is in use
<clever>
flake 'git+file:///home/clever/apps/rpi/rpi-tools' does not provide attribute 'packages.x86_64-linux.utils.armv6l-linux', 'legacyPackages.x86_64-linux.utils.armv6l-linux' or 'utils.armv6l-linux'
<clever>
samueldr: how do i make flakes do what i want again? lol
<clever>
aha, bcm_host_is_model_pi4 is broken once again
<clever>
so it did support pi4, but didnt know it was on a pi4! lol
<clever>
pointer word: 0xdf500000
<clever>
samueldr: my framebuffer is at this location in ram
<samueldr>
if you say so!
* clever
checks nots
<clever>
notes*
<clever>
1101 13 d
<clever>
the 11 at the start, tells the gpu to ignore all caches, so we have to strip that off first
<clever>
0001 01 1
<clever>
which means the actual address is 0x1f500000
<clever>
501mb from the start of ram
<clever>
root@pi400:~# vcgencmd get_mem arm
<clever>
arm=948M
<clever>
arm memory spans 0-948mb
<clever>
samueldr: TLDR, the fkms framebuffer is held in the linux half of ram
<clever>
[ 0.000000] Reserved memory: created CMA memory pool at 0x000000001ec00000, size 256 MiB
<clever>
9mb from the start of the CMA pool
<clever>
boom, problem answered!
<samueldr>
so gpu_mem can be at a minimal size with fkms-3d and things still work fine I presume
<clever>
yeah
<clever>
i think the only thing using gpu_mem then, is the camera and maybe video encode/decode
justanotheruser has quit [Ping timeout: 250 seconds]
justanotheruser has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
hexa- has quit [Read error: Connection reset by peer]
hexa- has joined #nixos-aarch64
hexa- has quit [Quit: WeeChat 2.9]
hexa- has joined #nixos-aarch64
cole-h has quit [Ping timeout: 252 seconds]
bennofs_ has quit [Read error: Connection reset by peer]
bennofs_ has joined #nixos-aarch64
ehmry has quit [Ping timeout: 260 seconds]
Adluc has quit [Ping timeout: 258 seconds]
ehmry has joined #nixos-aarch64
Adluc has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
mschwaig has quit [Ping timeout: 268 seconds]
orivej has quit [Ping timeout: 246 seconds]
HenrikK has joined #nixos-aarch64
zupo has joined #nixos-aarch64
HenrikK has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
mschwaig has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
Batty is now known as Church-
dev_mohe has quit [Quit: dev_mohe]
HenrikK has joined #nixos-aarch64
rajivr has quit [Quit: Connection closed for inactivity]
orivej has joined #nixos-aarch64
<FantasyCookie17[>
My Rock64 seems to fail to boot from eMMC. microSD works though… Note: This isn't a RockPro64; I'm aware of the issue there where you have to press `r` every time you boot until you change something about the config.
<FantasyCookie17[>
Why could that be?
<samueldr>
FantasyCookie17[: do you have some more info, e.g. logs
<FantasyCookie17[>
<samueldr "FantasyCookie17 🏳️🌈🏳️⚧️: do"> No, it doesn't display anything on HDMI, and it doesn't assign itself an IP address.
<FantasyCookie17[>
* > <@freenode_samueldr:matrix.org> FantasyCookie17 🏳️🌈🏳️⚧️: do you have some more info, e.g. logs
<FantasyCookie17[>
No, it doesn't display anything on HDMI, and it doesn't assign itself an IP address via DHCP.
<samueldr>
right, no serial access I suppose then :)
<samueldr>
but since you say pressing R helps I assume it's that issue
<FantasyCookie17[>
<samueldr "right, no serial access I suppos"> Well… I do have serial access, it's just a bit complicated to set up (my main machine is on macOS, not sure how to access serial there, if it's even possible, and the NixOS machine I have for setting up the images is just a live USB), that's why I was asking…
<FantasyCookie17[>
<samueldr "but since you say pressing R hel"> No, pressing r doesn't help.
<FantasyCookie17[>
<samueldr "it might be the same issue than "> I don't think so, as the RockPro64 gives me HDMI output…
bennofs_ has quit [Read error: Connection reset by peer]
bennofs_ has joined #nixos-aarch64
zupo_ has quit [Ping timeout: 246 seconds]
zupo has joined #nixos-aarch64
NekomimiScience has quit [*.net *.split]
c00w has quit [*.net *.split]
KalBot has quit [*.net *.split]
KalBot has joined #nixos-aarch64
c00w has joined #nixos-aarch64
NekomimiScience has joined #nixos-aarch64
<FantasyCookie17[>
So, I tried serial now, with 1500000 baud rate, and don't seem to be getting any output…
<samueldr>
it is a valid way to do this temporarily by somehow editing the /boot/extlinux.conf file once
<samueldr>
e.g. you said you can boot from SD
<samueldr>
you could mount the eMMC from the booted system from SD to edit the cmdline
<samueldr>
another option would be, if you have the adapter, to mount the eMMC on your computer
<FantasyCookie17[>
I do have the adapter, so that's what I did…
<samueldr>
note that the change would be temporary if you do so
<samueldr>
e.g. a nixos-rebuild will re-generate the file as it should
<samueldr>
and the init logs are (for now) only on the last console= parameter given
<samueldr>
oh, that's what I could do today, fix up the consoles issue
<FantasyCookie17[>
<samueldr "and the init logs are (for now) "> Oh. I'll try again with that… I had it at the first console parameter and only got kernel logs, which stopped at `EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null)`
<FantasyCookie17[>
Strange. Now it stopped to give me anything after `Starting kernel ...`.
<samueldr>
hmm, odd, I might have been mistaken somehwere, or maybe the console is different if you're not using the same kernel?
<samueldr>
making it the only console= parameter could help
<FantasyCookie17[>
That's what I did.
<FantasyCookie17[>
I tried just making it the last at first, which gave me that behaviour. Then I removed all other consoles, which still gave me the same behaviour.
<samueldr>
you used `console=ttyS2,115200n8`, right?
orivej has quit [Ping timeout: 240 seconds]
<FantasyCookie17[>
No. That one was already there. I used console=uart8250,mmio32,0xff130000
<samueldr>
right
<samueldr>
that might be the issue
<FantasyCookie17[>
I can readd it, I guess.
<samueldr>
the "uart8250" argument really shouldn't be needed, even for early debugging, in newer kernels
<samueldr>
they changed things in a way that the kernel just knows how to get the right console even for early debugging, I'm not sure the details how
justanotheruser has quit [Quit: WeeChat 3.1]
<FantasyCookie17[>
`rockchip-drm display-subsystem: [drm] Cannot find any ctrc or sizes` is an error I'm getting. Could that be related?
<samueldr>
indeed it's not an issue about the eMMC not being available
<samueldr>
any crtc or sizes *could* be something along the lines of unable to get display information, e.g. from EDID
<samueldr>
I don't know for sure
<samueldr>
FantasyCookie17[: once you stop seeing things from the log, switch to 115200 baud speed
<samueldr>
getty by default (IIRC) in NixOS will start at 115200
<FantasyCookie17[>
Huh. Now that's strange. Suddenly, I am getting display output.
<samueldr>
it could be that the message is for the other display output
<samueldr>
iirc there's support for two on the SoC
<FantasyCookie17[>
But why didn't I get display output before?
<samueldr>
¯\_(ツ)_/¯
<samueldr>
sometimes hardware is fussy
<FantasyCookie17[>
I have a second Rock64 with eMMC where I had the same issue, maybe it's the `console=` parameters… I'll try booting that one with the default ones.
<samueldr>
it could also be that you had the eMMC issues, and that this time it booted fine
<samueldr>
since, annoyingly enough, that issue is not trivially reproducible
<FantasyCookie17[>
🤷🏻♀️ Possible. It works on the other one as well now. I assume I should just set the config recommended for the RockPro64 for both my RockPro64 and the Rock64s, even though I have not seen the error appearing on any of them?
orivej has joined #nixos-aarch64
<samueldr>
at worst it'll do nothing
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
monk has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]