<colemickens> I'm gonna cry, if I'm reading this right
<samueldr> sounds plausible to be a fix for usb booting
<colemickens> I guess it gives me one or two more things to try!
<samueldr> you never tried SD, no?
<colemickens> no, I've read that mmc is not working well with mainline kernel yet
<colemickens> but take that with the grain of salt that all potentially dated cargo culted info is, you know
<colemickens> ( I do know that rpi4uefi somehow disables it, I think, the the kernel spams mmc errors when I was getting it booted via uboot->grub that many others online also report)
<samueldr> neat, I now have DRM rendering on SDM845 (razer-cheryl2) tested to work
<colemickens> !
<colemickens> nice
<samueldr> (with the mobile nixos gui stuff)
<samueldr> albeit the drawing can be seen refreshing... slowly enough
<samueldr> like 1/4th of a second to redraw
<colemickens> (the nixos installer media booting sshd now is a huge, huge help in iterating.)
<samueldr> but it's a good start, compared to not having anything at all drawn
monk has left #nixos-aarch64 ["Error from remote client"]
<samueldr> this also tells me that it's extremely likely the eDP output of the razer phone 2 just works
<samueldr> I'll have to do some wayland testing
<samueldr> hopefully *actually* doing double-buffering rendering will help with speed
<samueldr> I think the main issue is that 144hz is too much for the 1440p panel
<samueldr> well, for the dumb way rendering works
<samueldr> though... it wasn't that bad with fbdev
<samueldr> oh right, it never ran at 144hz either
<samueldr> nope, recovery (which runs at 60hz) is the same
<samueldr> anyway, I prefer a slow-to-render UI than no UI at all
<colemickens> it seems like that's probably not yet applied. I'll have to add that to my patches
<samueldr> I feel many interfaces fail their users
<colemickens> can't tell if that was pulled in?
<samueldr> I'll tell you what I do
<samueldr> tig drivers/pci/controller/pcie-brcmstb.c
<colemickens> I can even get to the thread view and all, but like... boy it's nice when github tells me what branches commits and in, etc
<samueldr> yep
<colemickens> good point good point
<samueldr> patchwork is another way to look for more info
<samueldr> *when* it's in a patchwork instance
<samueldr> for the kernel it's a toss-up if it's on a patchwork or not
<samueldr> in this instance it is
<samueldr> the kernel's patchwork is split per list AFAIUI
<colemickens> how did you even find that though
<samueldr> 50% getting used to it
<samueldr> 50% google
<samueldr> it didn't find it
<samueldr> because obviously it won't
<samueldr> the search is too specific
<samueldr> but SOMEHOW
<samueldr> the first result is what I want, kind of
<samueldr> it found me the right patchwork instance
<samueldr> then
<samueldr> the hard part
<samueldr> at the top, "Show patches with"
<samueldr> change State to "any", and Archived to "Both"
<samueldr> search by string
monk has joined #nixos-aarch64
<samueldr> that gives me all the revisions known to the patchwork instance
<samueldr> then click on the patch column, since it's been accepted the Series column becomes almost useless
<samueldr> (it resets State and Archived)
<samueldr> here anyway it's a lone patch, not part of a series, so it's less of an issue
<samueldr> pro-tip: the `mbox` link can be `git am`'d
<samueldr> series too
<samueldr> diff cannot since it's strictly the diff, without the required metadata to am
<samueldr> colemickens: does that help? ;)
<colemickens> uuuuhhh I think
* colemickens bookmarks this in the irc logs
<samueldr> ,permalink
<samueldr> basically, AFAIUI patchwork is another interface on top of mailing lists, but ONLY contains patches
<samueldr> it's in my opinion the better way to casually browse patches for Linux and U-Boot
<samueldr> especially since it handles series being revised as [vX]
<samueldr> (contains patches and their replies, obviously)
monk has left #nixos-aarch64 ["Error from remote client"]
rajivr has joined #nixos-aarch64
monk has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
h0m1 has quit [Ping timeout: 260 seconds]
h0m1 has joined #nixos-aarch64
matthewcroughan has joined #nixos-aarch64
<matthewcroughan> Heyo :D
monk has left #nixos-aarch64 ["Error from remote client"]
<matthewcroughan> samueldr: damn, so I followed the wiki but the board won't boot.
<samueldr> matthewcroughan: you have the armv7l orange pi pc I presume, right?
<samueldr> have you used an armv7l sd image or an aarch64 image?
<matthewcroughan> Flashed generic aarch64 and then flashed uboot with dd as specified
<matthewcroughan> Aarch64
<samueldr> the orange pi pc is armv7l
<samueldr> BUT
<samueldr> they have boards named in annoyingly confusing ways
<samueldr> so maybe it's not an orange pi pc
<matthewcroughan> It's the orange pi 3
<samueldr> alright, Allwinner H6, right?
<samueldr> you'll need the proper u-boot
<samueldr> they are *not* cross-compatible through different boards
<matthewcroughan> Yeah I was just about to link that
<samueldr> do you have a serial cable to help debug? it really helps
<matthewcroughan> That is correct
<matthewcroughan> samueldr: not at the moment, no
<samueldr> so yeah, the Allwinner H6 *is* aarch64
<matthewcroughan> But it doesn't even power on, nothing I could debug.
<samueldr> that's what you think ;)
<samueldr> it might be throwing some early messages
<samueldr> though maybe not if you used the wrong u-boot
<matthewcroughan> I'm interested. Let me go grab what I think is a USB to serial.
<samueldr> which u-boot did you install to it?
<matthewcroughan> The one specified in the wiki.
<samueldr> there is no wiki page for the orange pi 3
<matthewcroughan> Moving back to my pc, will specify in 20 seconds.
<samueldr> so basically what you may have done is similar to taking the bios of Thinkpad x230 and shoving it on a thinkpad x250 ;)
<samueldr> (with much probably less catastrophical failures)
<matthewcroughan> I flashed `uboot-orangepi_pc_defconfig-2017.11.nixpkgs.20171211.1545c3163bc6cf3cd0e81fee73dbf9baf29e5b0b.u-boot-sunxi-with-spl.bin`
<samueldr> yeah, completely wrong machine, not event the same cpu architecture :)
<matthewcroughan> samueldr: I like thinkpads. I appreciate that analogy more than you know :D
<samueldr> nerds are easy to please ;)
<matthewcroughan> Instructions unclear, flirted on IRC.
<samueldr> hmm... it doesn't look like upstream uboot has support for the orange pi 3 yet
<samueldr> ugh, that won't load
<samueldr> there's too many
<samueldr> but if you press `T` you get into a lazy fuzzy search
<samueldr> type orangepidefconfig
<samueldr> there's no orange pi 3 defconfig AFAICT
<samueldr> to the mailing list!
<matthewcroughan> You have destroyed my Thinkpad X230T.
<matthewcroughan> It is gone.
<matthewcroughan> All I have is this IRC client to reach you by, Firefox is now a zombie process. Thanks Gitlab.
<samueldr> the good news is that it seems it's coming
<samueldr> woopsie
<matthewcroughan> samueldr: Really? So what is it that Armbian uses?
<samueldr> matthewcroughan: they often use the vendor forks
* samueldr checks their build system
<samueldr> it's not the worst, but it's not the best
<matthewcroughan> The speed at which you're traversing these repos makes me feel like upgrading to a Thinkpad T480 would improve my productivity.
<samueldr> looks like they vendor'd a patch to add it to _a_ u-boot
<matthewcroughan> Github doesn't load that fast here :D
<samueldr> matthewcroughan: hah, it's also because I already know where to go
<samueldr> it is unclear if it should be applied to mainline u-boot or not
<matthewcroughan> So, there is a defconfig here. So all I have to do is compile this u-boot and flash it in the right sectors?
<samueldr> and it is unclear if other patches are needed
monk has joined #nixos-aarch64
<samueldr> since the official upstreaming had more than the minimum https://patchwork.ozlabs.org/project/uboot/cover/20210110192939.3138193-1-jernej.skrabec@siol.net/
<samueldr> matthewcroughan: I would go applying that series of patch from u-boot on top of mainline u-boot instead of digging through armbian
<samueldr> tip: the series link to the top right makes a one-file patch
<matthewcroughan> so, I clone the latest u-boot and apply the patch?
<samueldr> yeah
<matthewcroughan> sweet
<samueldr> that should put the commits appropriately in the history even
<matthewcroughan> I'm beginning to like bootloaders.
<samueldr> we won't accept such a patch in Nixpkgs, but considering it's fresh from this month, it's probably going to be part of the next u-boot update
<samueldr> ~2020.04 I guess
<samueldr> 2021*
<matthewcroughan> samueldr: failed patch :p
<matthewcroughan> Patch failed at 0001 sunxi: board: extract creating a unique sid into a helper function
<samueldr> hm
<samueldr> might need some manual editing love I guess, or try on top of the 2020.01 tag
<samueldr> 2021.01 **
<matthewcroughan> error: patch failed: arch/arm/dts/Makefile:605
<matthewcroughan> it only adds one line to Makefile, hmm
<matthewcroughan> but it adds it in the middle of the list, instead of at the bottom, durr
<samueldr> they might very well have standards to follow
<samueldr> and `git am` is bad at applying patches
<samueldr> try -p1
<samueldr> 2/1747 +S
<samueldr> uh
<matthewcroughan> I used git apply to deduce that, I know am is bad :D
<samueldr> try git am --show-current-patch | patch -p1
<samueldr> when in a failed patch
<samueldr> then git am --continue
<matthewcroughan> Hunk #1 succeeded at 605 with fuzz 1.
<matthewcroughan> patching file configs/orangepi_3_defconfig
<matthewcroughan> patching file board/sunxi/MAINTAINERS
<matthewcroughan> patching file arch/arm/dts/sun50i-h6-orangepi-3.dts
<samueldr> (assuming things were fine)
<matthewcroughan> it only errors out on that Makefile
<matthewcroughan> so can I continue and then add it manually?
<samueldr> or add it manually, stage the change, then --continue
<samueldr> and presto, it's part of your commit
<matthewcroughan> samueldr: seems to apply cleanly, actually
<matthewcroughan> it's a lie
<matthewcroughan> IDK why it claimed to fail, it wrote the file successfully.
<samueldr> I stopped assuming git's behaviour makes sense
<matthewcroughan> well, assuming that worked, how compile? :D
<samueldr> customize the u-boot derivation
<matthewcroughan> so, make menuconfig?
<samueldr> src can be changed
<matthewcroughan> so build uboot from nixpkgs, using a custom src?
<samueldr> yeah
<samueldr> start from ubootOrangePiZeroPlus2H5
<samueldr> change the defconfig name
<samueldr> and the attribute name
<samueldr> and nothing else really
<matthewcroughan> feels good being able to fork u-boot just for this lmfao
<samueldr> ain't open source great?
<matthewcroughan> No, it's bait
<clever> i'm a bit surprised as how open the new RP2040 from rpi is
<clever> i wasnt expecting to even see bootrom source
<matthewcroughan> yeah but RiscV is coming to eat everyone, so who cares? :D
<clever> matthewcroughan: riscV is eating more then you want...
monk has left #nixos-aarch64 ["Error from remote client"]
<clever> matthewcroughan: throwing takedown notices to anybody trying to host the docs
<samueldr> clever: there's a retraction
<matthewcroughan> These are the two stories from today that excited me.
<matthewcroughan> clever: how embarassing
<clever> samueldr: still feels off, that they are so confused about their own docs, to have done that in the first place
<samueldr> sure
<matthewcroughan> It won't matter for the same reason Elastic Search can't really stop Amazon from strip mining them.
<samueldr> just saying that things evolved :)
<samueldr> and it's important to continue with the less "fun" parts when outrage happens
<samueldr> the follow-ups
<simpson> It's a sign of times ahead. What one would want is a vendor who cannot wait to give us the datasheets.
<clever> samueldr: and twitter's UI makes that somewhat difficult
<samueldr> yes
<samueldr> if I wasn't already following her, I wouldn't have known I guess
<clever> i am following, and didnt see the follow-up
<samueldr> 84 RTs vs 9 RTs
<samueldr> oh right, following with not-an-official-client
<clever> the snr ratio is horid
<clever> i can get a notification on my phone, then it will vanish in the middle of reading it
<clever> and then i can spend an hour scrolling thru the feed on the website, and not find the same tweet
<clever> samueldr: how does this look, as a starting point for the RP2040 SDK? https://gist.github.com/cleverca22/54185973f524ae8196ca02db099cca16
<samueldr> no opinion clever
<samueldr> I don't know enough about embedded development
<clever> the only real problem i have so far, is that i cant use the proper pkgsCross stdenv
<clever> it winds up trying to build host tools with the cross gcc
<clever> i must use a host stdenv, and jam a cross gcc into buildInputs
<matthewcroughan> Cool, so now I've got this
<matthewcroughan> can i now just use `nix-builld` with some overrides?
<clever> probably
<samueldr> that's my assumption
<matthewcroughan> how do you do overrides in nix-build? O.o
<matthewcroughan> so it'll probably be like `nix-build '<nixpkgs>' -A u-boot`
<clever> matthewcroughan: --arg passes arguments to the `<nixpkgs> {}` area
<clever> so you can do `--arg config '{ packageOverrides = ...; }'`
<clever> or you can do `--arg overlays '[ (self: super: {}) ]'`
<clever> you can also do: nix-build -E 'with import <nixpkgs> {}; u-boot.overrideAttrs (old: {})'
<matthewcroughan> packageOverrides?
<clever> or both at once, nix-build -E 'with import <nixpkgs> { config or overlays =; }; u-boot'
<matthewcroughan> I'm not understanding what packageOverrides is
<matthewcroughan> I understand u-boot.overrideAttrs
<clever> the old config.nix way of doing overrides
<clever> before overlays came around
monk has joined #nixos-aarch64
<samueldr> matthewcroughan: note that u-boot provides a "builder" function
<samueldr> so it will not be as trivial
<samueldr> maybe first try just forking and dirtily editing the derivation
<samueldr> to confirm you're not twisting it into overrides all for naught
<matthewcroughan> samueldr: so something like this? nix-build -E 'with import <nixpkgs> {}; u-boot.overrideAttrs {old: { src = builtins.fetchGit { url = "https://github.com/MatthewCroughan/u-boot" ref = "v2021.01-orangepi3"}; }}
<samueldr> > pkgs.u-boot
<{^_^}> attribute 'u-boot' missing, at (string):471:1
<samueldr> u-boot is not a package :)
<matthewcroughan> what is it?
<matthewcroughan> it's pkgs.misc/uboot
<samueldr> it exposes multiple attributes, which are all built through helper functions
<matthewcroughan> sure is a pkg
<matthewcroughan> then why is it in pkgs?
<samueldr> because it's multiple packages
<samueldr> one per platform
<samueldr> > pkgs.buildUBoot
<{^_^}> <LAMBDA>
<samueldr> you can, though, override buildUBoot I believe
<matthewcroughan> so, at this point I'm better off making a local clone of nixpkgs
<samueldr> [22:27:42] <samueldr> maybe first try just forking and dirtily editing the derivation
<matthewcroughan> because the overrides will get sillyh
<samueldr> :)
<matthewcroughan> sorry :D
<samueldr> [22:27:55] <samueldr> to confirm you're not twisting it into overrides all for naught
<samueldr> I even predicted the sillyness :)
<matthewcroughan> sure, I'm just not lingofied enough to understand the jargon
<matthewcroughan> I will be though
<samueldr> sorry, not sayng I told you so, just saying I knew what you were going to get yourself into
<samueldr> when I hack around on u-boot I always end-up doing modifications to a nixpkgs checkout, much easier
<matthewcroughan> Right well I'm going to get a tea
<matthewcroughan> at 3:30AM
<matthewcroughan> and when the Tea is done, nixpkgs will still be cloning
<samueldr> make worktrees from a central git clone :)
<samueldr> man git-worktree
<samueldr> worktrees are also why I have a 8.4GiB .git folder for linux
<samueldr> 40 different remotes
<matthewcroughan> I'm not sure I follow what the use case is?
<matthewcroughan> so you just have one git repo, and every repo you ever want to do anything with is just part of this megarepo?
<samueldr> the .git folder is shared, so you can checkout multiple branches at different locations
<clever> samueldr: my rpi/firmware .git is huge, but thats more because they keep pushing binaries, lol
<clever> samueldr: they also tried to delete the history, but github still had it, so i was able to recover it
<samueldr> yeah, linux is cheating less so with mainly source code
<samueldr> in other news, DRM drawing on SDM845 now goes fast!
<clever> the firmware repo has massive changes on every commit, because binary doesnt diff well
<matthewcroughan> Got back from making tea
<matthewcroughan> resolving deltas :D
<matthewcroughan> samueldr: how would worktrees help me btw?
<matthewcroughan> The cloning time would still be massive
<samueldr> assuming you already had a nixpkgs checkout
<matthewcroughan> ah ok
<matthewcroughan> so every machine you have just has this same worktree config?
<samueldr> no need to re-clone multiple times
<samueldr> nah, I make a worktree for "long lived" feature branches I work on
<samueldr> think of it as a checkout, but in another directory
<samueldr> so you can still play with the repo on the main branch or similar
<matthewcroughan> samueldr: there's no device tree file for the orange pi 3
<samueldr> in mainline linux?
<matthewcroughan> in u-boot in the arch/arm/dts
<samueldr> tried with the "new-kernel" image?
<samueldr> oh
<samueldr> that should have been part of the patchset you applied
<matthewcroughan> ah, guess simply because it fails at the stage of modifying the makefile, it fails.
<matthewcroughan> didn't realise that's how patch failure worked, since I don't really ever fix failures.
<matthewcroughan> yeah lol, the whole patch fails because of its position in a list.
Church- has joined #nixos-aarch64
<matthewcroughan> samueldr: what is this that you've given me? https://patchwork.ozlabs.org/series/223574/mbox
<Church-> sphalerite: So I saw you had some success getting nixos running on the helios64?
<matthewcroughan> error: patch failed: board/sunxi/board.c:789
<matthewcroughan> god damnit
<samueldr> matthewcroughan: I believe it was
<samueldr> sorry :/
<matthewcroughan> samueldr: do we know what the commit hash was when this patch was pushed?
<samueldr> nope
<matthewcroughan> wtf
<matthewcroughan> w t f
<samueldr> if a patch doesn't apply, it's to the author to fix (except when trivial)
<samueldr> but we maybe can figure out
<samueldr> see, github is a snitch
<samueldr> your branch
<samueldr> see how it recognized a specific author?
<matthewcroughan> yeah
<samueldr> two even (?)
<samueldr> sometimes you can look at their profile and see their fork of the project
<samueldr> sometimes you can get their WIP branch that way
<samueldr> but doesn't look like it's the case here
<matthewcroughan> branchmageddon
<samueldr> another thing to look at is the date the patch was posted to the patchwork
<samueldr> it can't have come from after
<matthewcroughan> yeah I was going to try and rollback the git to that date
<samueldr> also try on top of the 2021.01 tag (if that wasn't what you did)
<samueldr> oh right
<samueldr> that's what you did
<matthewcroughan> yeah, I just didn't realise I'd have to apply after fixing, only to find an error in boards.c
* samueldr tries to apply to take a look
monk has left #nixos-aarch64 ["Error from remote client"]
<samueldr> I finished what I was doing so I have a few minutes I'll spare to see
<matthewcroughan> samueldr: I went back to c8f2a060a1 which is the result of `git rev-list -1 --before="Jan 10 2021" master`
<matthewcroughan> same conflicts
<matthewcroughan> git reset --hard HEAD~1 until clean merge? :D
<samueldr> it was a trivial fix AFAICT
<samueldr> (sorry, trivial if you're already used to these kind of badly applying patches)
<matthewcroughan> hah
<matthewcroughan> yes, and I am not used to it
<matthewcroughan> thanks for the patience
<samueldr> at the moment it hasn't taken much of my involvement, and your patient and nice enough
<matthewcroughan> so the resultant uBoot upstream nixpkg change would look like this right?
<matthewcroughan> for ` ubootOrangePi3`
<samueldr> nope :)
<samueldr> look for an aarch64 board
<matthewcroughan> produces a different filesToInstall ?
<matthewcroughan> oh
<samueldr> though it does produce only that one file
<matthewcroughan> great, so how would I express that I want to build u-boot for that one board?
<matthewcroughan> nix-build -A ubootOrangePiPc ?
<samueldr> you'll need to add it to all-packages.nix
<matthewcroughan> sorry, `nix-build -A ubootOrangePi3`
<samueldr> and use the proper name
<samueldr> yeah
<samueldr> just search for ubootOrangePiPc in all-packages.nix and I guess it should be self-evident how to add your board
<matthewcroughan> alright, done that, so my cmd should now work if I pass `-I ./nixpkgs` for my local nixpkgs?
<samueldr> or rather `nix-build -A ...` at the root of the nixpkgs checkout
<samueldr> oh
<samueldr> no
<samueldr> it won't
<samueldr> nix-build -A pkgsCross.aarch64-multiplatform.ubootOrangePi3
<samueldr> (assuming you build from an x86_64 platform)
<matthewcroughan> yeah I am
<matthewcroughan> I love Nix so much.
<matthewcroughan> I can't believe cross compiling is made this easy with Nix.
<samueldr> same
<samueldr> sure, you had to edit nixpkgs a bit
<samueldr> but that's also 90% of the work for making the actual change
<matthewcroughan> yeah, totally
<samueldr> once u-boot supports the board upstream
<matthewcroughan> very easy to get into
<matthewcroughan> I've been using arch for 3 years and wouldn't even know how to get started being a package maintainer
<samueldr> things like this Mobile NixOS only works that well because Nix, Nixpkgs and NixOS is a force multiplier
<samueldr> a finished build cannot be in a weird state
<matthewcroughan> Well thanks so far for helping me out with this. Hopefully if this process is this painless for other boards, I can help with board support.
<samueldr> so it's really easy to trust a build
<samueldr> when a board is already in u-boot mainline, it's literally just the tail end of what you did
<samueldr> obviously we only want to expose u-boot builds that have been tested and known to work
<matthewcroughan> uh oh
<matthewcroughan> fatal error: sun50i-h6-cpu-opp.dtsi: No such file or directory
<samueldr> hm
monk has joined #nixos-aarch64
<matthewcroughan> Using your git as a src of course
<samueldr> yeah
<samueldr> >> Becasue of that, this series should be applied on top of:
<matthewcroughan> Ah, yes, nix.
<matthewcroughan> I.e "Nothing".
<samueldr> yeah
<samueldr> I covered that earlier with cole//mickens, idiosyncracy with patchwork
<samueldr> click the round - next to "Action Required" and "No"
<matthewcroughan> He blocked me for being annoying as hell early on :P
<samueldr> so that's why things didn't apply cleanly
<matthewcroughan> okay, so we need to apply this, as well as the patch from dhweg?
<samueldr> maybe even v3
<samueldr> https://patchwork.ozlabs.org/project/uboot/list/?series=&submitter=&state=*&q=sunxi%3A+Add+support+for+Tanix+TX6&archive=both&delegate=
<samueldr> but yeah, basically it is needed too
<samueldr> it helps sometimes to read the patch notes ;)
<matthewcroughan> v2 as well?>
<samueldr> v3 only
<matthewcroughan> so two patches?
<samueldr> two patch _sets_
<samueldr> here it's 5 patches total :)
<matthewcroughan> so the series, of both?
<samueldr> both series
<matthewcroughan> just tried applying on my own, hopefully did it right
<matthewcroughan> git push --set-upstream origin v2021.01-orangepi3
<matthewcroughan> crap
monk has left #nixos-aarch64 ["Error from remote client"]
monk has joined #nixos-aarch64
<matthewcroughan> samueldr: am I fetchingthe repo right? https://pastebin.com/raw/3Zj9KkAk
<samueldr> use fetchFromGitHub with github sources
<matthewcroughan> Just making sure, because it prints this when cloning https://pastebin.com/raw/Mkxwnxem
<matthewcroughan> samueldr: why overcomplicate tit thought?
<matthewcroughan> I was never able to figure fetchFromGitHub properly
<samueldr> I don't know what fetchGit does in this case, I'm not using it generally
<samueldr> maybe what you do is fine
<samueldr> I would simply have used fetchFromGitHub
<matthewcroughan> that's not a builtin
<samueldr> four main params: owner, repo, rev, sha256
<matthewcroughan> so there are no docs I can see here about it
<samueldr> github.com/owner/repo and then rev is something like a revision hash or a tag name
<matthewcroughan> but where's the doc though?
<samueldr> yeah, it's part of Nixpkgs
<matthewcroughan> doesn't matter anyway, I got the u-boot bin
<matthewcroughan> time to test it
<matthewcroughan> what I did worked
<matthewcroughan> samueldr: seems again that the pi doesn't get to bootload anything
<matthewcroughan> No power led
<samueldr> I cannot say more at that point :)
<samueldr> but serial would be the better way to check
<matthewcroughan> Damnit
<samueldr> on many inexpensive boards the leds are all software controlled
<samueldr> and it may be that u-boot doesn't set them up
<samueldr> e.g. I know the pinephone and pinebook both needed work to make the LEDs light up
<matthewcroughan> yeah and it is noted that hdmi doesn't even work in some cases on the opi-pc
<matthewcroughan> so I guess I won't know until I get serial working
<matthewcroughan> does the installer image have serial out?
<samueldr> just checking, the BL31 line is also in tour buildUboot call, right?
<samueldr> it might not, but you'll have u-boot output on serial telling you more
<samueldr> at least you'll know whether u-boot fails or linux fails
<matthewcroughan> I do not have the BL31 line samueldr
<samueldr> that's needed
<samueldr> start from a complete allwinner-based aarch64 u-boot buildLinux call
<samueldr> (e.g. the orangepi whatever h5)
<samueldr> that's because BL31 is the trustzone implementation... and not to bore you with details I don't exactly know to the full extent... it's needed for u-boot to work
<matthewcroughan> didn't realise that was mandatory
monk has left #nixos-aarch64 ["Error from remote client"]
<matthewcroughan> samueldr: just making sure. The procedure is: 1. Flash the `nixos-sd-image-20.09.2671.fe08be60cb8-aarch64-linux.img` 2. Flash uboot in the correct sector.
<samueldr> yep
<matthewcroughan> samueldr: why is there so much perl
orivej has joined #nixos-aarch64
cole-h has quit [Ping timeout: 256 seconds]
<matthewcroughan> samueldr: https://pastebin.com/raw/J9V1JsZz
<matthewcroughan> sorry if you got that thrice, bouncer acting up
<matthewcroughan> flashing and trying, just giving you my last_will
<matthewcroughan> going to bed will report on things later :D
<matthewcroughan> Nope, didn't work either. Oh well.
<matthewcroughan> Was worth a try and learned a lot!
<sphalerite> Church-: yep, not with a mainline kernel yet though
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-aarch64
tilpner has quit [Quit: tilpner]
<Ke> so do people have working helios64s now
<Ke> ?
<sphalerite> I've sold mine to a colleague, but yes it's working
tilpner has joined #nixos-aarch64
alpernebbi has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 265 seconds]
<Church-> sphalerite: How non mainline are we talking?
<sphalerite> Church-: quite a lot of patches, but on top of 5.9
orivej has quit [Ping timeout: 265 seconds]
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Quit: dev_mohe]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Acou_Bass has quit [Quit: ZNC 1.8.2 - https://znc.in]
bdju has quit [Ping timeout: 240 seconds]
Acou_Bass has joined #nixos-aarch64
bdju has joined #nixos-aarch64
orivej has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
<Church-> Oh okay cool.
<Church-> Know if zfs works? Had to build a dkms myself on armbian
<sphalerite> Yep, works no problem
<Church-> Cool. So what's the process for actually building the image?
<Church-> Haven't done that before
<sphalerite> grab https://github.com/angerman/nixos-docker-sd-image-builder/ , make some adjustments if you like, run make :)
<sphalerite> oh right, that's assuming you have aarch64 building available
<sphalerite> be it by running directly on aarch64 hardware, by having an aarch64 remote builder, or via qemu-user
<Church-> Got it
<matthewcroughan> Alright, I'm awake again :Dsam
<matthewcroughan> wow, my fingers are cold
<matthewcroughan> samueldr: meant to tag you! :)
<matthewcroughan> I'm gonna get the serial out now and see how u-boot is doing (or not) on the pi.
alpernebbi has quit [Quit: alpernebbi]
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 272 seconds]
rajivr has quit [Quit: Connection closed for inactivity]
Darkmatter66 has joined #nixos-aarch64
Mic92 has joined #nixos-aarch64
<matthewcroughan> OMG Mic92 o/
<matthewcroughan> Mic92: so, I'm following this https://nixos.wiki/wiki/Template:ARM/installation_allwinner
<Mic92> matthewcroughan: I don't have an allwinner board unfortunally, but I would love to have support in https://github.com/Mic92/nixos-aarch64-images
<matthewcroughan> I compiled u-boot for the pi3, using the patches you can see in the last 5 commits https://github.com/MatthewCroughan/u-boot/commits/v2021.01-orangepi3
<matthewcroughan> Mic92: my intention is to make a PR to your repo
<Mic92> matthewcroughan: ok. I think you will need to refactor https://github.com/Mic92/nixos-aarch64-images/blob/main/pkgs/build-image/build-image.py a bit. There I assume that uboot is copied to a partition. which does not quite work with allwinner
<Mic92> There firmware works a bit like MBR
<Mic92> So like BIOS bootloader
<Mic92> the reason is that there offset is smaller than what you can use as the smalles LBA if I remember correctly
<matthewcroughan> I need to get it working before I even attempt to look at your stuff :P
<matthewcroughan> for some reason this u-boot doesn't work
<Mic92> matthewcroughan: ok. good luck with that.
monk has joined #nixos-aarch64
<Mic92> It's a bit annoying that every arm board needs its own u-boot.
<matthewcroughan> Mic92: yeah, sad
<matthewcroughan> sync
<matthewcroughan> lmao I ran sync here instead of on my terminal
<matthewcroughan> ffs
Darkmatter66 has quit [Ping timeout: 246 seconds]
zupo has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 260 seconds]
<makefu> better sync than be sorry! I am also one of these guys which run sync after everything 'just to be sure'
<mgdm> my boss in my first job alwasy ran it twice because he didn't trust it
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 256 seconds]
<samueldr> I sure want to, at some point, play with that: https://github.com/kdrag0n/fastboot.js
<samueldr> might even play nice with u-boot's own fastboot implementation
* colemickens feels like that's a fun sentence
<colemickens> "u-boot's fastboot impl" joy
<samueldr> hm?
<samueldr> it worked well when I was able to use it
jumper149 has joined #nixos-aarch64
<matthewcroughan> samueldr: what does uboot/fastboot have to do with eachother?
<matthewcroughan> a javascript bootloader?
<samueldr> that could be like asking what does windows and firefox have to do with eachother?
<samueldr> ;)
<samueldr> fastboot is a protocol used to do some maintenance with hardware, in a way
<samueldr> commonly used to flash operating systems on android phones
<samueldr> fastboot.js is an implementation of the "computer side" of fastboot, in javascript for WebUSB
<samueldr> u-boot can be put in a mode where it exposes the fastboot protocol to, mainly, flash operating system images
<matthewcroughan> samueldr: fascinating
<LinuxHackerman> mgdm: have you seen people writing `sync; sync; sync` before?
<matthewcroughan> LinuxHackerman: yeah I do that a lot
<mgdm> LinuxHackerman: I have not seen it to that level yet, no, only twice
<matthewcroughan> I contracted it from a friend.
<matthewcroughan> sync
<matthewcroughan> ah crap, wrong windo
<LinuxHackerman> Apparently that tradition started on a system where the sync command didn't actually work right
<LinuxHackerman> So you'd type sync, then after it finished, type sync again, then again a third time
<LinuxHackerman> the key being that the time spent typing sync again would allow the system enough time to actually flush the caches
<LinuxHackerman> sync;sync;sync therefore completely defeats the point :D
<mgdm> hah
<LinuxHackerman> and also just one sync should work correctly on a modern system so…
<LinuxHackerman> also, cool to see you here :D are you still in Glasgow?
<mgdm> this was ~15y ago when I encountered it being written twice
<mgdm> I am yeah!
<LinuxHackerman> Got around to trying nixos yet? ;)
<mgdm> I've got 3 of them now :D including an AWS graviton2 that I joined this channel when I couldn't get it to start
<LinuxHackerman> ooooh
<mgdm> (it works fine now)
<mgdm> you're in Berlin, iirc...?
<LinuxHackerman> Munich
<mgdm> ah! sorry
<LinuxHackerman> Are you feeling the brexit much? I hear some vegetables and stuff aren't available anymore
<mgdm> not noticed much difference here tbh
<mgdm> aside from a deep and abiding loathing for those who caused it, but that was there before
<LinuxHackerman> hah
<mgdm> a lot of the trouble seems to be UK companies exporting things to the EU, many of those companies are run by people who voted to leave, and who are now going to go out of business
<mgdm> ANYWAY
alex_giusi_tiri has joined #nixos-aarch64
pbb has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
pbb has joined #nixos-aarch64
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
veleiro` has joined #nixos-aarch64
<matthewcroughan> samueldr: Linux localhost 3.10.65 #1 SMP PREEMPT Wed Jan 9 13:47:51 CST 2019 armv8l
<matthewcroughan> that's what I get from the orange pi on its default non-armbian reference linux 3.10 on the emmc
<samueldr> vendors generally use trashy "BSP" kernel source trees from the SoC makers
<matthewcroughan> armbian boots and says Linux orangepi3 5.10.4-sunxi64 #20.11.7 SMP Tue Jan 5 23:28:09 CET 2021 aarch64 GNU/Linux for uname -a
<{^_^}> https://github.com/NixOS/nixpkgs/pull/20 (by bluescreen303, 8 years ago, merged): just a small kernel upgrade
<matthewcroughan> serial is a lot faster woo
<matthewcroughan> my nixos aarch64 image + dd of u-boot seems not to work.
<matthewcroughan> maybe I can get the u-boot binary from armbian and use it, then figure out the patching later/
<samueldr> if you don't have u-boot output from the image, it serves no purpose to look at the kernel version
<matthewcroughan> I do have u-boot output from armbian
<samueldr> I meant on your image that doesn't work
<matthewcroughan> I have u-boot output from armbian *and* whatever is pre-installed on the emmc
<matthewcroughan> samueldr: yeah, I don't get anything at all, it's odd
<samueldr> can you share the complete changes you made to your nixpkgs checkout?
<matthewcroughan> samueldr: Linux orangepi3 5.10.4-sunxi64 #20.11.7 SMP Tue Jan 5 23:28:09 CET 2021 aarch64 GNU/Linux
<{^_^}> https://github.com/NixOS/nixpkgs/pull/20 (by bluescreen303, 8 years ago, merged): just a small kernel upgrade
<matthewcroughan> whoops wrong paste
<samueldr> at a glance that u-boot build looks fine
<samueldr> no idea at this point
<samueldr> but yeah you might be able to use armbian's u-boot
<samueldr> except I think they mess with the default u-boot boot strings
<samueldr> so it could end up not working
<samueldr> but still worth a try I guess
<matthewcroughan> samueldr: any idea where I would siphen that?
<samueldr> not at all
<samueldr> I'm not an armbian dev, nor an armbian user
<matthewcroughan> samueldr: maybe we've got the wrong offset for the h6 cpu?
<samueldr> unlikely, but something to check
<matthewcroughan> I'm assuming all sunxi are alike.
<matthewcroughan> samueldr: the filename that comes out of `nix-build` is not `uboot-<devicename>-defconfig` etc
<matthewcroughan> it's just `u-boot-sunxi-with-spl.bin`
<samueldr> I know
<samueldr> and it's okay
<matthewcroughan> right, just checking, because this guy's stuff is labelled right https://www.cs.helsinki.fi/u/tmtynkky/nixos-arm/installer/
<samueldr> that was a secondary step
<samueldr> since all build products are named the same
<matthewcroughan> should I be able to blank the SD card and flash u-boot, and see something out of serial? Even without an OS ?
<samueldr> not that these haven't seen any kind of update since late 2018 and shouldn't be relied on
<samueldr> note*
<samueldr> yes
<matthewcroughan> samueldr: OMG, I got an output from U-Boot on its own.
<matthewcroughan> OH.. wait, it fell back to EMMC. Got too excited.
srk has quit [Ping timeout: 268 seconds]
srk has joined #nixos-aarch64