<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
<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>
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
<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?
<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`
<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]