<samueldr>
the only other relevant~ish report I found at first also is for a sandisk drive
<samueldr>
:/ my test case isn't conducive to reproduction as it is
<samueldr>
shelving this to tomorrow, will need to disassemble the pinebook I think
<samueldr>
I thought the pine a64-lts would be close enough, but it doesn't use the same interface for the mmc
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
samrose has quit [Ping timeout: 240 seconds]
samrose has joined #nixos-aarch64
vika_nezrimaya has joined #nixos-aarch64
<sphalerite>
I'm tempted to try and get my chromebook in such a state that I can take only it to nixcon
<sphalerite>
samueldr: I think the sound problems all boil down to the hardware not supporting 44100Hz
<sphalerite>
samueldr: go figure, this time I tried to boot it failed
<sphalerite>
repeatedly
<sphalerite>
samueldr: I suspect it may work consistently per power-on (i.e. if it worked, rebooting will work), but is uncertain to succeed when cold-booting
chiefgoat has quit [Ping timeout: 240 seconds]
samrose has quit [Remote host closed the connection]
vika_nezrimaya has quit [Ping timeout: 265 seconds]
samrose has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
marek has joined #nixos-aarch64
marek has quit [Changing host]
<marek>
folks, I have a rPi 3, running nixos and I see a strange thing - when it reboots (due to power outage), it hangs until I plugin in HDMI and only then starts to booting process, any idea why?
<sphalerite>
marek: I have this problem too, u-boot wants to init the video console and resets the board if it fails
<sphalerite>
marek: if you find a fix I'd be very glad to know about it!
<sphalerite>
marek: a serial console is very helpful for debugging — I managed to at least get a u-boot shell by booting once with a display connected then setting stdout=serial and stderr=serial (disabling vidconsole), but it still then tries to init the monitor when booting linux
orivej has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 265 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jtojnar has quit [Read error: Connection reset by peer]
<sphalerite>
marek: does the green LED blink repeatedly while it's failing to boot?
<samueldr>
sphalerite: cold boot vs. "hot" boot is somehitn I saw in the commit logs around mmc in the chromeos kernel
<samueldr>
so it makes sense
<samueldr>
though in my case the hardware supports hs400es, it's seven specced to support it
<samueldr>
it's even specced*
<samueldr>
what I think is happening is either the sandisk emmcs or the kernel are juuuuust out of spec in a non-obvious way
<sphalerite>
well in mine it certainly should be specced to support it considering it's the built-in emmc?
<samueldr>
same for mine
<samueldr>
and it works with the chromeos kernel
<sphalerite>
or am I confusing things in what you're saying?
<samueldr>
not sure
<samueldr>
>> I think the sound problems all boil down to the hardware not supporting 44100Hz
<samueldr>
was that about emmc or audio?
<samueldr>
I think I saw the 4 and assumed hs400
<sphalerite>
oh, no that was about audio
<samueldr>
right
<samueldr>
then I started confused in what I was saying
<sphalerite>
:D
<samueldr>
to the TLDR of what I'm thinking is: hs400 is supported by all eMMC concerned here, though *something* makes the current mainline code not work
<samueldr>
or not work reliably
<samueldr>
and it might not be rockchip-specific or chromebook-specific
<samueldr>
though it'd be nice to know the manufacturer of your eMMC
<samueldr>
not sure how to, I only found out mine by what was in the dmesg, and yours don't return useful info
<samueldr>
other than it's in use in wyse thin clients
FRidh has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 246 seconds]
zupo_ has quit [Ping timeout: 245 seconds]
chiefgoat has joined #nixos-aarch64
wildtrees has joined #nixos-aarch64
wildtrees has quit [Remote host closed the connection]
wildtrees has joined #nixos-aarch64
_ris has joined #nixos-aarch64
<samueldr>
whew, the yak shaving seems strong
<samueldr>
had to make a more permanent serial cable for the pinebook before trying the next thing
<samueldr>
(which incidentally will be useful for the pro variant
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
<MichaelEden[m]>
I "cross-compiled" with `nix --option system armv7l-linux build -f '<nixpkgs>' hello` and my mind is blown, thanks everyone!
<clever>
MichaelEden[m]: --option system is the wrong way to do it most of the time, that tricks nix into thinking the host is arm, and then it will fail to execute arm binaries
<clever>
MichaelEden[m]: you want `--argstr system` instead
<samueldr>
clever: when using your qemu user thing, which one should be used?
<clever>
samueldr: thats a grey zone where both will work, but --argstr would probably give better performance
<samueldr>
:) good to know
<clever>
for example, i sometimes write exprs, that use builtins.currentSystem for heavy computation that doesnt care about platform (like squashfs)
<samueldr>
I was asking since I believe the quotes in "cross-compiled" are because it used the qemu user thing
<clever>
and then { system ? buitlins.currentSystem }: for the target
<clever>
if you use --argstr, then it will be a mix of arm and x86 builds, and wont emulate the mksquashfs
<clever>
but --option changes what builtins.currentSystem claims, so there is no way to do a "native" computation, and performance will suffer
<MichaelEden[m]>
clever: so using --argstr might result in x86 artifacts if the derivation is poorly formed, but --option is safer but slower?
<clever>
MichaelEden[m]: yeah
<clever>
ive also seen similar problems with nixops on darwin
<clever>
some people do `import <nixpkgs> {}` and dont set system=
<MichaelEden[m]>
oh interesting
<clever>
so it winds up putting darwin binaries into a systemd unit
<clever>
you have to use `import <nixpkgs> { system = "x86_64-linux"; }` to force it to be a x86 linux build
<clever>
or it falls back to the builtins.currentSystem
<clever>
and if you use --option system in such a case, it tries to run linux binaries on the darwin kernel, and everything fails
<MichaelEden[m]>
how should I write my derivations to follow this?
<MichaelEden[m]>
{ system ? buitlins.currentSystem }:
<MichaelEden[m]>
what does the `system` part do? does it just set which gcc to use or something?
<clever>
it tells nixpkgs what both the host and target are
<clever>
so it will use a gcc meant to both run, and target, that system
<clever>
so its a "native" build
<clever>
nix will then farm it out to a slave from /etc/nix/machines, that can run that platform
<clever>
$ nix show-config | grep platform
<clever>
extra-platforms = i686-linux
<clever>
but you can use this config entry in nix.conf, to trick nix into thinking the local machine can run non-standard things
<clever>
by default, it just says that a 64bit x86 cpu, can also do 32bit x86
<MichaelEden[m]>
but if i'm using qemu and running on my x86 machine, does --argstr still have benefits? (like maybe it will pick an arm gcc but an x86 bash)
<clever>
for a single derivation, its difficult to tell nixpkgs to do that
<clever>
so a given derivation will be entirely one arch
<clever>
but you can then import 2 copies of nixpkgs, let me get an example
<clever>
MichaelEden[m]: line 2 will get a 64bit x86 linux nixpkgs, and line 3 will get a "host" nixpkgs
<clever>
it will then build a nixos image that targets linux
<clever>
then build a qemu + #!/bin/bash, that targets the "host"
<MichaelEden[m]>
i think i understand, so using --argstr nix will build arm stuff in qemu and packages that are marked as "all-architectures" will be build without emulation?
<clever>
so you can nix-build this on any platform (raspberry pi, or a mac), and it will create a native qemu, that launches 64bit linux
<clever>
you need to manually cherry-pick the "all-arch" stuff from a 2nd nixpkgs yourself
<MichaelEden[m]>
ahh
<clever>
in the above example, host_pkgs.qemu vs linux_pkgs.hello
MichaelEden[m] has quit [Remote host closed the connection]
atopuzov[m] has quit [Read error: Connection reset by peer]
Ericson2314 has quit [Read error: Connection reset by peer]
bennofs[m] has quit [Write error: Connection reset by peer]
dtz has quit [Write error: Connection reset by peer]
sphalerit has quit [Write error: Connection reset by peer]
timclassic has quit [Remote host closed the connection]
marius851000[m] has quit [Write error: Connection reset by peer]
thefloweringash has quit [Write error: Connection reset by peer]
NickHu has quit [Read error: Connection reset by peer]
timokau[m] has quit [Read error: Connection reset by peer]
contrun[m] has quit [Read error: Connection reset by peer]
worldofpeace has quit [Read error: Connection reset by peer]
Ox4A6F has quit [Write error: Connection reset by peer]
codyopel has quit [Write error: Connection reset by peer]
balsoft has quit [Remote host closed the connection]
cornu has quit [Write error: Connection reset by peer]
alj[m] has quit [Write error: Connection reset by peer]
danielrf[m] has quit [Write error: Connection reset by peer]
alienpirate5 has quit [Write error: Connection reset by peer]
nocent has quit [Read error: Connection reset by peer]
<clever>
also, in this case, i'm forcing linux_pkgs to be 64bit x86 linux
<clever>
and now we are getting matrixed again
<clever>
rather then accepting a system param you could change with --argstr
MichaelEden[m] has joined #nixos-aarch64
<MichaelEden[m]>
OK cool, so do you think building hello will have a perfomance impact if I use --option vs. --argstr
<clever>
no performance difference if your only building hello
<clever>
but when you start to write more complex things, and expect it to work without qemu-user, --argstr helps
<MichaelEden[m]>
makes sense, thank you for the explanation!