zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Thra11 has quit [Ping timeout: 246 seconds]
orivej has quit [Ping timeout: 272 seconds]
orivej has joined #nixos-aarch64
samrose has quit [Read error: No route to host]
Thra11 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Thra11 has quit [Quit: WeeChat 1.9.1]
<samueldr>
welp, until libre.computer has a confirmed working mainline kernel, I'm stopping; it reliably hangs after modules start loading, but even with dynamic debug and the whole firehose I can't seem to pinpoint to one module
<samueldr>
tried (at runtime) disabling a couple modules, but something must have forced them to load as they still loaded
<samueldr>
I have suspicions that it's either the ethernet driver or the rockchipdrm (hdmi I guess) drivers causing issues as they are the most noisy before it fails
<samueldr>
though whatever noise they do, it's nothing useful as it hangs in an uncontrolled manner, with different stuff happening before the hang
<samueldr>
it's plausible, too, that it hangs before whatever makes it hang has any time to show up in the serial logs
Thra11 has joined #nixos-aarch64
<samueldr>
though, if anyone here has ideas on how I could debug this further, I'm all ears
<gchristensen>
ah, bummer...
FRidh has quit [Quit: Konversation terminated!]
zupo has joined #nixos-aarch64
jackdk has joined #nixos-aarch64
<samueldr>
yeah :/
<samueldr>
can't attempt the big dogfooding event for a while I guess
<samueldr>
it'd probably faster to get an RK3399 chromebook instead
<makefu>
samueldr: i've got my aio-3399 board running till: [ OK ] Reached target Multi-User System.
<makefu>
:D
<makefu>
it boots with mainline
<samueldr>
so the u-boot version I brewed up works right with yours, given the right defconfig?
<samueldr>
neat!
<samueldr>
I guess you had to `cp` the right dtb right?
<makefu>
yeah the cp thing is what i did right now, i wanted to test the uboot you brewed up
<samueldr>
(though here I'm guessing I'm SOL until an engineer from libre.computer of firefly does the work, since erm, I'm not knowledgeable in those things)
<makefu>
yeah, do something fun instead. these boards are simply not worth investing so much time
<samueldr>
yeah, "confirmed", here it wouldn't help me since you dit "nothing special" :)
<samueldr>
well, I went until it stopped being a learning experience
<samueldr>
same with u-boot
<samueldr>
that's a good part of the value, for me, to learn more about the diverse ARM things
<makefu>
next step for me will be the uboot, maybe i can flash yours onto the emmc
<makefu>
"and that all suppliers suck in different ways"
<samueldr>
yes, that I knew already
<samueldr>
I'm waiting for the amlogic board
<makefu>
:D
<samueldr>
amlogic seems to be much more mainline friendly
<samueldr>
but I think they have some baggage that will be annoying
<samueldr>
their magic sector is at sector 0x02 on 512B sectors
<samueldr>
so...
<samueldr>
right in the GPT
<samueldr>
while allwinner and rockchip leave enough room to split the GPT
<makefu>
oh wow, why would they do this?
<samueldr>
legacy from before GPT?
<makefu>
from like 20 years ago?
<samueldr>
it was a hole before GPT
<samueldr>
well, before GPT caught on
<samueldr>
"no one would use GPT on an SBC"
<samueldr>
or something along the line :)
<makefu>
haha yeah
<makefu>
let me attach rj45 to the board
<samueldr>
though, to be fair, the amlogic board I'm waiting for has SPI flash, so it's a non-issue for actual use
<makefu>
(wifi does not seem to be working out of the box at least)
<samueldr>
(same with the renegade, it has SPI so I'm fine with the dirty u-boot since anyway it won't be on the storage device)
<samueldr>
the libre.computer peeps have stated that every board they make, now, will have SPI flash to save the bootloader
<makefu>
that is a good thing
<samueldr>
and, having a pine a64-lts with SPI, I can say that it's amazing
<samueldr>
yeah
<samueldr>
(pine64 isn't libre.computer, to be clear)
<makefu>
yay ethernet is working
<samueldr>
I don't have to deal with annoying `dd` at a random location, and with a recent u-boot, EFI boot works
<samueldr>
though I faced an annoying fact yesterday, and I'm less "proud" of how it works now
<samueldr>
actions will transmit all the data in the workspace between steps
* samueldr
rephrases
<samueldr>
actions will transmit all the data in the workflow (a workspace directory) between steps
<samueldr>
so the nix-build one has a result symlink
<samueldr>
but things outside the workspace directory are not kept
<samueldr>
/nix/store is outside the workspace directory
<makefu>
haha i see
<samueldr>
so I had to make a dumb thing to "unravel" the /nix/store paths
<samueldr>
I chose to do it non-recursively and document that it shouldn't hold further references to the nix store
<makefu>
then again, which machines are performing the build? some nice guys at github/microsoft?
<samueldr>
yes
<samueldr>
github has the infra
<samueldr>
I think this might have been made an urgent issue to work on, since gitlab had that for a while
<makefu>
so they want to replace travis by just having everything available directly from the start (similar to gitlab)
<samueldr>
yes
<samueldr>
well
<samueldr>
no
<samueldr>
I'd say things like travis probably are better in the end if you have a complex workflow
<samueldr>
but maybe my view is tainted by the way nix doesn't fit because of /nix/store
<samueldr>
e.g. right now you couldn't make a cachix workflow step that implicitly pushes whatever was built in the previous step
<makefu>
when i tested gitlab ci for the first time it was absolutely fantastic and it was quite sad that CI was never (until now it seems) a primary part of github
<samueldr>
more boilerplate would need to be written
<samueldr>
though IIRC, my complaining here about /nix/store disappearing is the same for gitlab CI
<samueldr>
sams kind of infra
<samueldr>
Actions are built on Docker containers
<samueldr>
(I did do some light stuff in gitlab CI in the past)
<makefu>
in gitlab-ci it depends on how you configured your runner
<makefu>
you can also have an 'ssh' runner which just logs onto the machine and does stuff jenkins-style
<samueldr>
so yeah, I'm thinking I might need to add an option to the action to also allow copy-closureing the closure so one could upload a closure instead of a built artifact
<samueldr>
yeah, I was talking about the hosted docker-based CI
<makefu>
ah okay
<makefu>
still the github workflow stuff has some potential to be very cool, especially for smaller projects where you just want to automate a release for example
<samueldr>
exactly
<samueldr>
and AFAICT nothing stops anyone to write their own action with complex behaviour if it is desire
<samueldr>
d
<samueldr>
like, I could make all the steps into one CI script, into one action, instead of relying on external ones
<makefu>
i am sure there are some hard limits, like with everything on github
<samueldr>
that's for sure
Thra11 has quit [Ping timeout: 246 seconds]
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 255 seconds]
<makefu>
i've tested the built bootloader and together with the trust.img everything seems to be working. however it is now missing the default dtb for the rk3399-roc-pc (your board). not sure where this comes from
<samueldr>
firefly's engineers seem... dumb
<samueldr>
instead of adding a target to u-boot
<samueldr>
they just re-use whatever last one they worked on
<makefu>
yeah it seems so ...
<samueldr>
ah!
<samueldr>
I think it's "because of my fix" though
<makefu>
yep maybe
<makefu>
i removed the patches
<samueldr>
I added a target for the roc-rk3399-pc without doing anything to make their board load the proper target
<makefu>
now i see the first unattended reboot
<samueldr>
so it uses whatever target is the first in the "choice"
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]