<lopsided98> the wiki is up to date for unstable
<lopsided98> There is enough space in the beginning of the aarch64 image to put the bootloader. It will overwrite the firmware partition, but you don't need it for the RockPro64
<lopsided98> I haven't tested the mainline kernel recently, but it should at least boot. I would recommend using the new-kernel variant of the aarch64 image.
<samueldr> (you can and probably should delete the first partition rather than keep a dangerous block in the middle of maybe the bootloader)
<samueldr> and yeah, the first partition (FIRMWARE) is designed to be treated as an opaque blob
lovesegfault has quit [Remote host closed the connection]
lovesegfault has joined #nixos-aarch64
<ryantrinkle> samueldr: the cross build finished :)
<ryantrinkle> when i'm installing this img, how does it relate to the uboot stuff?
<samueldr> ryantrinkle: now do it for unstable (or maybe best staging)
<samueldr> ryantrinkle: same as the default image
<samueldr> the only difference with that cross-built image and a native-built image is the inputs being different compilers
<samueldr> (and some stuff disabled for the cross-built one due to issues)
<samueldr> otherwise they're both the same for how they boot
<ryantrinkle> got it
<ryantrinkle> i'm a little confused about the general install procedure: do i dd this image only, or do i also have to dd u-boot separately?
<samueldr> that image is generic~ish, it's pre-bundled with the raspberry-pi3-ready u-boot
<ryantrinkle> ah ok, cool
<samueldr> for other SBCs they need to be able to use u-boot somehow
<samueldr> you could burn u-boot to the SPI flash of your pine a64-lts
<ryantrinkle> right, this is gonna go on a pine64 A64-LTS
<samueldr> and there, no need to burn it to the drive
<samueldr> but if you don't have it in the SPI, you're likely going to need to burn it to the image
<clever> samueldr: i might also be able to burn uboot to the rpi4's SPI, when i'm done with my experimentation
<samueldr> well, to the drive
<ryantrinkle> ah yeah, i'm a bit concerned that i won't know how to recover if i screw up the SPI though
<ryantrinkle> whereas with the emmc/SD, i can pop it into another machine
<samueldr> ryantrinkle: the a64-lts prefers sd images, then emmc, then spi, in that order
<samueldr> so it's pretty fail-safe
<clever> ryantrinkle: at least in the case of the rpi4, it will run a recovery.bin from the SD, if found, and ignore the SPI chip
<ryantrinkle> ahhh ok
<ryantrinkle> good point
<clever> ryantrinkle: and there is a recovery.bin provided by the foundation, to re-flash the SPI
<samueldr> clever: between SoCs there's no comparison to do
<samueldr> Rockchip generally go the other way
<samueldr> SPI, then eMMC, then SD
<clever> so you would have to brick the SPI before it obeys SD
<samueldr> generally there's a button for that :)
<samueldr> or two
<clever> the rpi compute module had similar
<ryantrinkle> so if i wanted to make an image with the correct u-boot preloaded, is there somewhere I can change that?
<clever> a button to disable the SD card, to force it to fail
<samueldr> one that boots in rkloader mode, which is a usb programming mode for rockchip that's on the CPU die
<samueldr> one that simply deasserts the read pin of the SPI
<clever> samueldr: yep, same with the compute module, it has a custom usb device thing
<samueldr> ryantrinkle: nothing pre-made
<clever> ive heard reports that the usb thing only activates if the SPI is bricked
<samueldr> ryantrinkle: dd u-boot to the image you made, or dd u-boot to the sd card
<clever> but other evidence, that it can run in other cases, not sure
<samueldr> the main issue with making multiple images pre-burned is that it'd make "n" images to host that are (compressed) 6xxMiB
<samueldr> meanwhile, shipping u-boot separately is almost free
<mla> lopsided: thanks for the info will try unstable, had been trying stable unsuccessfully
<mla> lopsided98*
<ryantrinkle> samueldr: yeah, that makes sense
<samueldr> though I was thinking it would be helpful for new users, and lazy users especially, to produce an installer script
<ryantrinkle> but if i'm building the image locally, it seems like it might be nice to be able to do the whole thing in one shot
<ryantrinkle> is that where I would start pulling things out into arguments, if we wanted this to be configurable?
<samueldr> you would, let's say, run result/install /dev/sdd and it would do the dirty work
<ryantrinkle> i'm thinking maybe I could do something like yank the rpi-specific stuff into a record that gets passed in
<ryantrinkle> leave rpi as the default
<clever> one idea i had, was to make a derivation using pkgs.runCommand
<samueldr> ryantrinkle: yeah, and its sibling sd-image.nix
<clever> which will copy the entire image, then mutate the copy to have the right u-boot at the right offset
<ryantrinkle> but then system images could set something like uboot.package = whateverBoard;
<clever> so you nix-build that version, to make a variant of the image
<samueldr> clever: yeah, that's the one that needlessly duplicates the big images in the store
<clever> samueldr: yeah, but then you have the choice to produce a pure image, though...
<clever> samueldr: what if i just had a runCommand, that did "${install}/bin/install $out"
<clever> then i could use your script, in another derivation
<clever> if i wanted my hydra to produce finished images
<samueldr> clever: not a bad idea
<clever> so your idea works for both of us
<samueldr> yeah
<clever> as long as the install script can work on raw files
<samueldr> ryantrinkle: an annoying truth is that not all boards require u-boot to be installed the same way, which is why I had installer script in mind
<samueldr> clever: it likely would
<ryantrinkle> samueldr: ah yeah, that's annoying
<clever> ryantrinkle: have you been paying much attention to the rpi4 and whats changed with it?
<ryantrinkle> clever: no, i only recently started learning about SBCs and ARM and such in desperation to get a phone that isn't horrible to manage
<ryantrinkle> so i only really have read up on the pine64 stuff
<ryantrinkle> (and even that, only a little bit :P)
<clever> ryantrinkle: the rpi4 now has proper gigabit ethernet, and usb3.0 via a pcie controller
<ryantrinkle> nice :)
<clever> there is also a 512kbyte boot rom, that contains some of the board firmware
<clever> currently, the official firmware doesnt fit fully, so it has to load some from a fat32 partition on SD
<clever> but, i have a toolchain that can create custom firmware
<ryantrinkle> that sounds really cool
<clever> in theory, i could flash custom 100% open firmware to the SPI chip (lets ignore the dram firmware, lol) and include u-boot on that
<clever> then, on powerup, the pi will just look for a uboot config on the SD card
<samueldr> my yak is so tall, yet still so furry :(
<ryantrinkle> there's a lot of potential with all this stuff; having good nix tooling will really help me, at least, get into it
<clever> samueldr: oh, doesnt u-boot have a config it can save/load from local flash?
<samueldr> clever: likely it does
<clever> samueldr: u-boot could support that on the pi4
<samueldr> yeah
<samueldr> and "look for a uboot config" is not entirely truthful either
<samueldr> it can
<samueldr> but it can also just load uefi programs
<clever> ryantrinkle: ive forked the existing open firmware, and modified it to the point that you can `nix-build -A vc4.firmware` and it spits out a bootcode.bin
<samueldr> off usb!
<clever> samueldr: assuming it has the pcie and vl805 drivers, yeah
<samueldr> or you use the type-c port
<clever> samueldr: does uboot have any options to decompress itself?
<samueldr> tianocore is getting USB drivers
<samueldr> clever: no idea, maybe
<samueldr> it does have the concept of SBL (secondary boot loader)
<clever> i need to fit everything within 512kbyte if i want to use an unmodified pi4
<samueldr> yeah
<samueldr> and not only that, but *also* enough initialization code for the pi
<clever> and the ddr4 controller
<clever> -rw-r--r-- 1 clever users 21K Dec 3 21:24 memsys00.bin
<samueldr> here I assume all hardware needed is "the pi"
<ryantrinkle> clever: nice! one of the hard requirements with projects at obsidian is that they have to build in one shot with nix
<ryantrinkle> none of this "do some setup, then build, then do some more setup, then build other stuff"
<ryantrinkle> it makes a huge difference with onboarding, CI, QA, etc.
<samueldr> understandably!
<clever> ryantrinkle: i also added proper cross-compile support for vc4 to nixpkgs, it should already be in nixos-unstable
<clever> ryantrinkle: this is enough to compile a basic rpi firmware, that is confirmed to work on rpi2 and rpi3
<clever> it lacks the ability to initialize dram and adjust its own clock, but its enough to printf out a uart
lovesegfault has quit [Ping timeout: 265 seconds]
<ryantrinkle> nice; hopefully nix will give us enough of an advantage as a community to make good headway on the open firmware stuff
<ryantrinkle> i certainly have a far easier time contributing to nixos than when I was on ubuntu
<clever> ive also been re-structing the open firmware in my fork
<ryantrinkle> it was totally unapproachable there
<samueldr> is it even possible to contribute to ubuntu?
<clever> there are chunks of code shared between arm and vc4
<ryantrinkle> samueldr: haha i don't know! i never figured it out
<clever> and the original makefile just did ../foo/bar.c
<clever> and when src = ./.; cuts things short, ../foo doesnt exist anymore
<ryantrinkle> but now i just always run a small fork of nixpkgs with my own little changes, most of which I'm waiting for merge or whatever
<clever> so, i made foo into its own self-contained nix package
<clever> which can build on both arm and vc4
<ryantrinkle> git-based workflow + ability to rollback
<ryantrinkle> now i want that for my phone, too :)
<clever> ryantrinkle: oh, another reason nix is great
<clever> ryantrinkle: the readme on this firmware, claims it can boot linux
<clever> ryantrinkle: but, they dont supply a device-tree file, or kernel build instructions
<clever> ryantrinkle: after a week of testing various things, i still dont have it booting linux
lovesegfault has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 240 seconds]
ryantrinkle has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 250 seconds]
ryantrinkle has joined #nixos-aarch64
wavirc22 has joined #nixos-aarch64
<ryantrinkle> samueldr: thanks for the help! just `dd`ed it overit and it worked on the first try :)
<ryantrinkle> now to figure out how to enable the MIPI-DSI screen :P
<samueldr> I don't know about that, mine runs plain and simple :)
<ryantrinkle> with a DSI screen or without?
<ryantrinkle> i haven't yet validated whether this screen works at all
<samueldr> without
<clever> ryantrinkle: start by finding the official intructions, and try to modify them to nixos
<samueldr> most likely try to find instructions for mainline allwinner/sunxi
<samueldr> allwinner BSP kernels differ greatly from mainline
h0m1 has quit [Ping timeout: 252 seconds]
orivej has joined #nixos-aarch64
h0m1 has joined #nixos-aarch64
wavirc22 has quit [Read error: Connection reset by peer]
orivej has quit [Ping timeout: 268 seconds]
<ryantrinkle> samueldr: error: cannot open connection to remote store 'daemon': '/nix/var/nix/db/schema' is corrupt
<ryantrinkle> have you seen that one?
<samueldr> no
<ryantrinkle> this is when trying to do nix-env -iA something
<clever> ryantrinkle: `export NIX_REMOTE=daemon`
<clever> ryantrinkle: oh wait corrupt, what are the contents of schema?
<ryantrinkle> fixed with this: echo -n 10 > /nix/var/nix/db/schema
<ryantrinkle> i saw something in the irc logs where someone else had the same issue
<clever> ryantrinkle: but that indicates your fs is getting corrupted
<ryantrinkle> hmm
<ryantrinkle> well, this machine isn't intended to store anything important, probably ever, but definitely for a while
<ryantrinkle> i'll keep my eyes open
<samueldr> just have to love software where you explicitely --enable-feature and feature detects that $dep isn't available so it turns itself off without failing the build
<ryantrinkle> hahahaha
<ryantrinkle> samueldr: nix-store --verify --check-contents did find two files that look truncated
andi- has quit [Remote host closed the connection]
wavirc22 has joined #nixos-aarch64
andi- has joined #nixos-aarch64
wavirc22 has quit [Read error: Connection reset by peer]
wavirc22 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 250 seconds]
wavirc22 has quit [Quit: wavirc22]
wavirc22 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
wavirc22 has quit [Read error: Connection reset by peer]
orivej has joined #nixos-aarch64
h0m1 has quit [Quit: WeeChat 2.6]
h0m1 has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
vika_nezrimaya has joined #nixos-aarch64
orivej has joined #nixos-aarch64
evils has joined #nixos-aarch64
vika_nezrimaya has quit [Ping timeout: 268 seconds]
<evils> hi, i recently fixed kicad so it'd build for aarch64, i'm running into problems testing it on my pi, anyone with X11 care to give it a go? https://github.com/NixOS/nixpkgs/pull/74259
<{^_^}> #74259 (by Evils-Devils, 2 weeks ago, open): Kicad cleanup, fix and update
<thefloweringash> I went to take a look, what's the attribute path to build? `nix-build -A kicad` errors out with `kicad/base.nix:1:1 called with unexpected argument 'with3d'`
<evils> woeps, just removed that because base doesn't need it, still passing it in xD
<evils> force pushed the fix
<evils> thefloweringash: kicad is the right one, kicad-unstable has the latest sources and does a debug build, kicad-small is stable without several GB of 3D models (though i'd like the 3D viewer tested)
<evils> damn, i got the logic wrong again xD
<evils> thefloweringash: i logic'd as fast and hard as i could, it should work now
pbb has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
pbb has joined #nixos-aarch64
<thefloweringash> it's taking a minute to build, but it is building
<evils> thefloweringash: it took a few days on my rpi3b+...
<evils> maybe i should ask about x11 on nixos on aarch64...
<ryantrinkle> any idea how i can cross-compile a standalone kernel module?
<thefloweringash> I have a laptop here running nixos/aarch64/x11/i3, what kind of question did you have?
<evils> thefloweringash: i got some error like "driver unavailable" when i tried to build with xserver enabled
<thefloweringash> haven't seen that one, maybe start by cutting down the drivers in `services.xserver.videoDrivers` to just `[ "modesetting" ]` ?
<thefloweringash> or pastebin more of the error message
<evils> thefloweringash: yea, going to try and recreate it
<grw> i have seen this, forcing videoDrivers is the fix iirc
<evils> grw: forcing to "modesetting"?
<grw> evils: yes
<grw> it is xf86-video-intel (which is set by default) unable to build on non-x86
<evils> that seems to ring a bell, i'm currently waiting for my pi to respond to the rebuild command :P
<evils> Package ‘xf86-video-vmware-13.3.0’ ... is not supported on 'aarch64-linux', refusing to evaluate
<grw> ah, close :)
<ryantrinkle> found a few things that seem to work :)
<thefloweringash> evils: the build succeeded, anything in particular I should test?
<evils> thefloweringash: see if you can create a project, save it somewhere (test the file chooser), open the pcb layout editor, press o, click workspace, search dip 14, choose first result and place in the workspace, go to view -> 3D viewer, see if you get a 3D view
<evils> you should get a popup on opening the editor to configure global footprint library table, the recommended/default action shouldn't be greyed out, and you should be able to just click ok, after that you should get a graphics accelleration popup, choose "enable acceleration"
<evils> grw++ thefloweringash++ it built with xserver
<{^_^}> grw's karma got increased to 1, thefloweringash's karma got increased to 5
<evils> oh yea, another quirk of my pi, it doesn't boot unless a screen is connected
<thefloweringash> fell back to software rendering and then crashed. don't know if I expect my graphics to be supported on aarch64
<evils> any output?
<thefloweringash> the fallback message was "Could not use OpenGL, falling back to software rendering" where the details were "Cannot create more framebuffers, OpenGL rendering backend requires at least 3 framebuffers..."
<thefloweringash> I don't think my graphics stack has any opengl hardware support
<thefloweringash> relaunching, sticking with software rendering, I have a pretty blob of 3d plastic
<evils> what happens if you select "No Thanks" on the "Enable Graphics Acceleration" popup?
<evils> ah
<evils> the blob is black with 7 grep things on 2 sides?
<evils> s/grep/grey/
<thefloweringash> yep
<evils> ok, so aside from opengl it sounds like it's all good?
<thefloweringash> not a kicad user, but on the surface it seems to be functioning as expected
<evils> sounds about right, try clicking the cube thingy next to the gear in the 3D viewer :P
<thefloweringash> you've got all night right? ;-)
<evils> sure
<evils> you can stop it if it started though
<thefloweringash> hasn't moved off 1%
<evils> another thing to maybe try is in pcbnew, click the icon to the top right, should open a python shell
<evils> though that's all very platform independent i think
<thefloweringash> Seems to be some kind of rendering bug in the text editor, it clears everything but only paints the current line.
<thefloweringash> it did manage to launch the python shell
<evils> text editor?
<evils> i've never used that feature :P
<evils> this is from the kicad main window?
<thefloweringash> uh, by text editor I mean repl line editor + history
<evils> ah, the python shell thing then?
<evils> any idea why it worked on the second screenshot?
<thefloweringash> At this point I'm more supsicious of my graphics stack than anything else, mainline linux/mesa support for Mali-T864 is still new-ish
<evils> i think they only recently switched to pyalamode as well, this seems mostly a kicad issue
<thefloweringash> It flickers in and out. Selecting all causes a repaint so everything's visible. Typing seems to keep only the current line. Switching desktops causes a few paints in various states
<evils> maybe check if the other options on the kicad main window launch
<thefloweringash> they all seemed to open
<evils> good enough i suppose :D
<thefloweringash> Language selector doesn't want to switch back to english after switching to japanese. :D
<evils> oh?
<evils> works here...
<evils> any output on the console?
<thefloweringash> works after restart, shrug
<evils> well, thanks a lot for giving it a go, you may want to `rm -rf ~/.config/kicad ~/.cache/kicad fp-info-cache`
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
pbb has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
pbb has joined #nixos-aarch64
pbb has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
pbb has joined #nixos-aarch64
pbb has quit [Client Quit]
pbb has joined #nixos-aarch64
pbb has joined #nixos-aarch64
<mla> lopsided98: so i tried the new-kernel variant on the rockpro64 and it just hangs on 'Starting Linux'; while the normal kernel is missing the rockpro64-rk3399.dts file so that won't work either
<mla> so i guess custom kernel is only way to go, though building is pretty slow
<lopsided98> mla: are you sure it hangs? Are you looking at the serial console or HDMI?
<mla> waited about 5 minutes at serial console w/o new msgs
<mla> ill try plugging into hdmi now to see what comes up
<mla> doh uart wasnt enabled in nix cfg; it boots fine
<mla> thanks for the help
Irenes[m] has joined #nixos-aarch64
<mla> lopsided98: what do you use for the kernel line on rockpro64 for serial, trying console=ttyS1,1500000n8 with no dice
<lopsided98> mla: earlycon=uart8250,mmio32,0xff1a0000 will allow you to see early boot messages
<lopsided98> I also set 'services.mingetty.serialSpeed = [ 1500000 ];' so that the console uses the same baud rate as the bootloader and earlycon
<mla> lopsided98: thanks, working for me now
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64