FRidh has joined #nixos-aarch64
zupo has joined #nixos-aarch64
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
<makefu> however it is a good feeling to actually see the system boot up in any way
<samueldr> wait, so you're not booted with that new u-boot, right?
<makefu> not yet, no
<samueldr> ah
<samueldr> 99% sure it will need the same fixup
<samueldr> did you do anything special with the image to make it boot to multi-user?
<makefu> http://paste.krebsco.de/AY3pMFxj/+inline , no nothing special
<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> btw, I added this workflow which builds on push, and uploads a release on new release https://github.com/samueldr/ROC-RK3399-PC-overlay/blob/master/.github/main.workflow
<samueldr> the latter being neat
<samueldr> (building on push is also great for PRs)
<makefu> so cool
<makefu> this is the new github workflow stuff, right?
<samueldr> yes, Actions
<samueldr> Actions are the working bits, Workflows are composed of Actions
<makefu> and it directly creates a release? or where does gets pushed to
<makefu> pretty awesome
<samueldr> you see "on release"
<samueldr> that means that whenever the "release" event from github happens it will trigger
<samueldr> triggered by the Draft a new release
<samueldr> and it uploads on the release, to GitHub https://github.com/samueldr/ROC-RK3399-PC-overlay/releases
<makefu> how does the "building" happen?
<samueldr> nix-build
<makefu> ah samueldr/action-nix-build
<samueldr> :D
<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> yeah that is pretty cool
<samueldr> hm, not seeing anything about timeouts
<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…]
<samueldr> in the roc-rk3399-pc_defconfig I added `CONFIG_TARGET_RK3399_ROC_PC=y` a similar "fix" would be needed for the AIO
<samueldr> (and possibly its own defconfig, etc)
<makefu> not sure what does not work right now but the device booted from reset to nixos!
<makefu> my work here is done. now i have to write everything together
<samueldr> lol