<samueldr>
the ROC-RK3399-PC has an issue with TYPE_C, deleting type-c.ko may be enough not to rebuild everything
<samueldr>
(I set it to =n)
<bennofs>
in that case, wouldn't blacklisting be enough?
<samueldr>
turns out it's not enough
<samueldr>
I think it's something about blacklisting blacklisting the module from being loaded by the hardware prober
<samueldr>
I figure *something else* is loading the module
<samueldr>
it may as well fail in a horrible firey ball by deleting type-c.ko :)
<bennofs>
you could also remove it from the device tree maybe?
<samueldr>
I don't know, maybe
<samueldr>
still, deleting the .ko is trivial to test
<samueldr>
simply didn't get to it, at the time I didn't know if other issues existed in the kernel
orivej has quit [Ping timeout: 272 seconds]
wavirc22 has quit [Ping timeout: 260 seconds]
mDuff has joined #nixos-aarch64
lovesegfault has quit [Quit: WeeChat 2.7]
h0m1 has quit [Ping timeout: 272 seconds]
h0m1 has joined #nixos-aarch64
orivej has joined #nixos-aarch64
<clever>
samueldr: i now have usb and ethernet!!
<samueldr>
nice!
<samueldr>
on lk or linux, or only firmware?
<mDuff>
Hmm. I don't see a way to add new dtbs or other content to the sd_image assembled by raspberrypi-builder.sh
<mDuff>
would a patch that looks for an optional environment variable, and plumbs that through from the nix module, be accepted?
rajivr___ has joined #nixos-aarch64
<samueldr>
raspberrypi-builder.sh?
<samueldr>
dtbs, we ship those from linux
<samueldr>
it's a mainline generic image
<samueldr>
though if a systemm wants to customize that, hardware..deviceTree.base can be used
<mDuff>
specific goal: I'm trying to get g_ether to work; to do that following the approach used for Raspian &c., I'd add dtoverlay=dwc2 to config.txt, and put overlays/dwc2.dtb on the same filesystem.
* mDuff
pokes at config.hardware.deviceTree to try to make sense of how it's supposed to be used.
<mDuff>
...okay, if the only thing I need to do is assign `config.hardware.deviceTree.overlays`, that is indeed pretty simple.
<thefloweringash>
What do the aarch64 builders set their `cores` value to? I'm looking at that chromium build which is 10 hours in and up to 9796 of 36546 files. The builder machine on grafana is taking ~6% cpu, which is about two cores if you assume a 32 core machine. Chromium halves its core allocation, so I'm guessing `cores = 4`?
<thefloweringash>
I'm guessing it's not going to make the 2 day cutoff
<thefloweringash>
oh, it's actually running two jobs. it seems like chromium is then taking ~3%, or 1 core
magnetophon has quit [Remote host closed the connection]
<samueldr>
thefloweringash: I think it's something about how even if it's big-parallel it can be scheduled to a non big-parallel machine
<samueldr>
not sure
<thefloweringash>
I didn't realize there were non big-parallel aarch64 machines. is there a repo I pick through instead of asking dumb questions?
<samueldr>
I might be wrong, but I assumed big-parallel was "this machine builds big parallelized stuff"
<samueldr>
the same 48 core machine could be 2 jobs, tagged big-parallel, or 24 jobs, not tagged
<samueldr>
I don't know if the arm builders are documented
<thefloweringash>
so uh, about that armv7l vm project? :-)
<thefloweringash>
more seriously, I'm still interested in the project but I don't know how to keep tabs on progress. if there's a way I can help let me know.
<DigitalKiwi>
is there a way on nixos raspberry pi to tell what version of raspberry pi there is
<DigitalKiwi>
it is*
<sphalerite>
DigitalKiwi: probably look at the device tree somewhere in /sys/firmware
<samueldr>
thefloweringash: your previous aarch64 android phone, if it meets some requirements
<samueldr>
what I mean is the best device is one you already have
<samueldr>
THEN, not sure exactly
<DigitalKiwi>
found it
<samueldr>
the most useful ones for development are those with serial access
<DigitalKiwi>
ty!
<samueldr>
some sony ones have the UART documented by sony, on their site, but through test points, meaning you need to open the phone
<samueldr>
if you plan to look into a device which doesn't have a port yet, and is not a "GNU/Linux first" type of device
<samueldr>
the main things to look out for: (1) bootloader unlock possible (2) kernel sources
<samueldr>
and helpful things to look out for (3) TWRP with source (4) existing ports
<samueldr>
ports of other android-based systems*
orivej has quit [Ping timeout: 268 seconds]
orivej has joined #nixos-aarch64
<clever>
samueldr: perl is failing to cross-compile, is that a known issue? fixed at some point?
<gchristensen>
I don't think perl has ever really cross compiled?
<samueldr>
it does, otherwise stuff wouldn't work?
<gchristensen>
hrm
<clever>
make: *** No rule to make target 'install'. Stop.
<clever>
builder for '/nix/store/wafnfj5p1dflxfcqwnkilwzkajaa0z9m-perl5.30.0-XML-Parser-2.46-armv7l-unknown-linux-gnueabihf.drv' failed with exit code 2
<samueldr>
all I can say is that cross-system was tested to cross-compile the sd image for 19.09 and current staging as of yesterday
<samueldr>
ah
<samueldr>
that's fixe
<samueldr>
fixed*
<clever>
current staging has working cross-compile?
<clever>
if i delete that part of the code, it then hangs at:
<clever>
+ set -- root /dev/mmcblk0p2
<clever>
163 root=*)
<clever>
167 set -- $(IFS==; echo $o)
<clever>
samueldr: any ideas?
<samueldr>
both times it seems to come from parsing an option, weird
<samueldr>
could it be simply time based, and that happens around the same time?
<clever>
very
<samueldr>
those are hard to debug!
<samueldr>
the ROC-RK3399-PC in mainline linux has a bug where the type-c module kills the power supply for a short duration when enabled
<samueldr>
you see, a laptop would rely on a battery for that fraction of a second
<samueldr>
but the ROC-RK3399-PC uses type-c as its only power source!
<clever>
i know that the power is fine in this case, because the kernel keeps printing for another 2 seconds, as usb comes online
<clever>
and the gpu prints 100 seconds later, as a debug timer confirms what linux has done to the state
<samueldr>
oh, I haven't finished my story
<samueldr>
well, I think you connected the dots
<samueldr>
at some point during the boot, always around the same lines, it just would crash
<samueldr>
hard
<samueldr>
but it never got to printing anything about type-c!
<clever>
uart fifo?
<clever>
i had some similar weirdness, where i was only configuring the pin mux after i printed things
<samueldr>
I think the issue is that there was nothing that tried to print at that moment
<clever>
so id always loose the first 16 characters
<clever>
or rather, i lost everything except the last 16 chars
<clever>
because it only configured the pins correctly, once it was done printing, and the last 16 chars where in the fifo
<samueldr>
anyway, disabled TYPE_C, on a third of a hunch, a third of reading vague stuff about type-c and that board, and a final third of realizing the power was off at that point
<clever>
linux is definitely sitll responding, the echo in the tty reacts
<clever>
samueldr: the only thing i can think of right now, is that maybe the cross-compiled shell is faulty...
<samueldr>
unlikely
<samueldr>
try the same staging build using cross-system on the official pi firmware and see