<clever>
samueldr: i would also file an issue to the rpi fork of linux, rpi_firmware_transaction() should assert that the address is within the lower 1gig, and give a better error
<samueldr>
hmm, I don't have an ethernet cable that can reach the Pi :/
<samueldr>
and vgencmd isn't in the default package set :)
<clever>
a bigger and more anoying problem, vcdbg is also very helpful at times
<samueldr>
way to set myself for failure :)
<clever>
but its binary only, arm32
<clever>
vcdbg is basically the same as `gdb /proc/kcore`
<clever>
it knows a lot of juicy secrets
<Jake[m]>
<samueldr "and vgencmd isn't in the default"> Wait isn't it? I feel like I remember using it on my pi.
<Jake[m]>
Yeah clever mentioned it's under raspberrypi-tools. Sorry if I'm misunderstanding though.
<samueldr>
Jake[m]: in the default installed package set lol
<clever>
Jake[m]: vcgencmd is opensource, vcdbg is closed, and nix only provides it on arm32 via patchelf i believe
<clever>
both are in the same derivation
<samueldr>
clever: how bad of a workaround would be it to break the part of the code that parses the cma= argument?
<clever>
currently, its configured for a 10x10 pixel screen, with 1 hsync and 1 vsync
<clever>
sure
<samueldr>
justanotheruser: probably not worth it compared to using unpackbootimg from a prebuilt boot.img to get the info
<justanotheruser>
or at least the nix-relevant bits
<samueldr>
on a prebuilt boot.img*
<samueldr>
then letting the user find the kernel repo I guess
<samueldr>
though finding the kernel repo is kind of totally different than parsing the Android.bp files
<samueldr>
I wouldn't like parsing Android.bp files for the values
<samueldr>
but parsing the repo (as in repo, the git tooling from google) to get the kernel repo location? might be doable
<justanotheruser>
ah, to write the Fairphone 3 config I was just stealing from the lineageOS ROM repo
<justanotheruser>
didn't realize there was a more straightforward way
<samueldr>
yeah, perfectly valid strategy
<samueldr>
yeah, I really want to write some docs about porting, but it's... kind of hard making time for that when I also want to work on the other stuff that's missing
<samueldr>
I need a team!
<clever>
samueldr: oops!, i just noticed, ive configured it for an FPS of 19,760, lol
<samueldr>
19760 or 19.760?
<clever>
19760
<samueldr>
that's a lot of frames
<samueldr>
audible even!
<clever>
they are only 10x10, with a pixel clock of 2.4mhz
<clever>
math says...
<clever>
> 2400000 / ((10+1) * (10+1))
<{^_^}>
19834
<clever>
that many fps
<clever>
1 pixel worth of hsync in each scanline, and 1 scanline worth of vsync in each frame
<samueldr>
if that was fixed, I'm sure aarch64 wouldn't cause issues to update in tandem
<samueldr>
my gut tells me we're losing between a half and one order of magnitude of build time
<colemickens>
I was going to ask about how much it would cost to buy|rent enough aarch64 to close the gap, but I guess maybe paying someone to work on a new scheduler might be a better use of money
<samueldr>
I think even reducing the shares could help
<samueldr>
or uh
<samueldr>
whatever is used to say how many builds in parallel
<samueldr>
they're oversubscribed I think
tilpner has quit [Remote host closed the connection]
<samueldr>
since firefox *can* build in under an hour
<samueldr>
(on the hydra infra!)
<colemickens>
samueldr: is it worth just having a special manual job for these exceptional builds that are specially scheduled?
tilpner has joined #nixos-aarch64
<samueldr>
but generally fails to build from 4 to 10 hours depending on when it ends up timing out
<samueldr>
we'd need a machine that's reserved for that I figure
<clever>
but as long as 32bit is enabled in the kernel, it solves the need for having a 32bit glibc
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
alp has joined #nixos-aarch64
<heywoodlh1>
Hey all, has anyone attempted a port of NixOS mobile to the Razer phone?
justanotheruser has quit [Ping timeout: 240 seconds]
<samueldr>
heywoodlh1: 1 or 2?
<heywoodlh1>
1
<samueldr>
2 I had a wee look early on, and it might present some structural differences in recent qualcomm hw
<samueldr>
1 I don't have the HW
<samueldr>
though it should be entirely possible to do, just as for the 2 it is
<samueldr>
razer are providing sources in a perfectly usable manner
<heywoodlh1>
I have a 1. I've been screwing around today with getting it ported but I'm such a noob with nix-shell that I'm hitting some walls.
justanotheruser has joined #nixos-aarch64
<samueldr>
sorry, I don't really have much time to expand on porting right now :)
<heywoodlh1>
I'm definitely out of my element but it sounded like a really fun challenge.
<samueldr>
are you a NixOS user otherwise?
<samueldr>
I'm curious since I've seen non-NixOS users be interested in some of NixOS-using projects without themselves using NixOS, which is always a bit surprising
<heywoodlh1>
I have been a pretty zealous Arch user for about 5 years but discovered NixOS and have been using it for a few months now. I absolutely love it.
<samueldr>
nice
<samueldr>
heywoodlh1: one thing that might help, I don't know *how much*, but at least understand the porting better, is to first port postmarketOS...
<samueldr>
at least when I made my first port (what kicked off the project) that's how I got to grips with understanding things better
<samueldr>
I had a solid proof of things that should be working
<samueldr>
their porting docs are much better since they have many more users that (1) contributed to the docs (2) used the docs to make ports
<samueldr>
though if you have precise questions, do ask
<heywoodlh1>
samueldr: in regard to attempting to port it, I basically copied the devices/oneplus-oneplus3 folder to devices/razer-phone folder and then started modifying the nix scripts to match the configuration changes relevant to the Razer.
<samueldr>
that's a valid approach
<heywoodlh1>
I probably should have gone with google-walleye since it has the same SOC as the Razer phone. But whatevs.
justanotheruser has quit [Ping timeout: 240 seconds]
<samueldr>
there's so few differences that you can compare the files and you should be good to go
<heywoodlh1>
Anyway, I *think* I got to the point where the kernel source is downloading properly. But there's a piece I can't seem to figure out.
<samueldr>
though with the kernel config you should probably compare against walleye's
<heywoodlh1>
Yeah, that makes sense
<samueldr>
heywoodlh1: is it "where do you get the config.aarch64 file"?
justanotheruser has joined #nixos-aarch64
<samueldr>
it's a hard thing to answer fullly because... there is no universal answer
<heywoodlh1>
samueldr: Well, that is something I was wondering about. What I did is grabbed the kernel config from a Razer kernel source.
<samueldr>
in theory the truthier answer is to start off the devices _defconfig from the kernel source tree... which sometimes is hard to know which file it is!
<samueldr>
right, sounds like you had the right idea
<heywoodlh1>
Okay well that is good to know
<samueldr>
you probably want to run something like `bin/kernel-normalize-config razer-cheryl` to "expand" the partial defconfig to a full kernel config
<samueldr>
(mind your NIX_PATH)
<heywoodlh1>
But I think the part I'm running into issues with is that I think the kernel starts building and then it fails because `sed` can't find a Makefile.
<samueldr>
another source for a config.aarch64 is the "/proc/config.gz" from either a running system, or extracted from a kernel image from a boot.img
<samueldr>
heywoodlh1: can you fork; branch-off; commit your work?
<samueldr>
well, and push and share
<heywoodlh1>
Yeah, let me do that.
<heywoodlh1>
I haven't yet, but I planned on it if I got something working
<samueldr>
thanks, that's going to make answering much easier
<samueldr>
since I'll just run the build to see the actual problem
<heywoodlh1>
I'm guessing I'll have to have my Razer rooted to actually look at /proc/config.gz?
<heywoodlh1>
I'll get it forked and my changes pushed
<samueldr>
no need to root
<samueldr>
if you are not already, there are other methods that are less invasive
<samueldr>
and "good" OEMs don't ship with /proc/config.gz enabled
<samueldr>
though that doesn't mean the config is not embedded in the kernel, which is possible even without having /proc/config.gz
<heywoodlh1>
Okay. I'll figure out how to get access to /proc/config.gz later
<samueldr>
the defconfig, in theory, should be enough
<samueldr>
but it looks like the configuration generation step of the kernel build doesn't honor it
<samueldr>
(I know I said I didn't have much time earlier, but I didn't have much time for vague questions, this is a precise question and is fine)
<heywoodlh>
Where would I define the sourceRoot?
<samueldr>
it would normally be in the mkDerivation call, so overrideAttrs should work, but it didn't for me when I tried just now
<samueldr>
looking into it a bit
<heywoodlh>
Again, Nix syntax is very new to me, so the instructions in kernel/default.nix didn't seem super clear to me as where the actual build commands run
<samueldr>
the kernel building tooling in NixOS has years of baggage
<samueldr>
and here I dropped another layer on top of that baggage
<heywoodlh>
Sure, makes sense.
<heywoodlh>
You could revise that sentence to "computers have years of baggage" lol
<heywoodlh>
Anyway, thanks for the assistance, I would love to run Nix on this Razer.
<heywoodlh>
*NixOS
<samueldr>
okay, so I have this fixed in an upcoming WIP commit,
<heywoodlh>
Was it a problem with my syntax in kernel/default.nix?
<samueldr>
no
<heywoodlh>
That's good to know :D
<samueldr>
if you look into the tarball, there is a subfolder named msm-4.4
bennofs_ has quit [Ping timeout: 244 seconds]
<samueldr>
when nix extracts the tarball, it tries hard to prevent tarbombs
<heywoodlh>
That makes sense
<samueldr>
so it creates a folder named msm-4.4-7083.tar, in which there is the msm-4.4 folder
<samueldr>
well, tarbombs are not really an issue, I might have also misdiagnosed that
<samueldr>
so by default nix goes "one level" into the tar
<samueldr>
well into the extracted folder
<samueldr>
but here there's two
<samueldr>
sourceRoot / setSourceRoot are generally used in those cases
<heywoodlh>
Ah
<samueldr>
but somewhere along the line overrideAttrs doesn't allow doing that
<samueldr>
with that I was able to normalize the config
bennofs has joined #nixos-aarch64
<heywoodlh>
samueldr: thanks! Those changes worked great. So what exactly does kernel-normalize-config do?
<heywoodlh>
Oh, just read the comments in the script
<samueldr>
takes a config file and runs it through "the default answers" in what would be a make menuconfig to expand it to a full config file
<samueldr>
it's also useful when upgrading a kernel
<samueldr>
or when changing forks for a device with multiple forks
<heywoodlh>
Okay, cool.
<heywoodlh>
I am definitely on a roll for stupid questions now, but I'm gonna ask anyway.
<samueldr>
nah, they'd be stupid only if you'd asked them multiple times and getting answers :)
<heywoodlh>
samueldr: appreciate it! Lol
<samueldr>
otherwise it's just that, asking questions
<heywoodlh>
So do I just use bin/menuconfig to actually flash the image to the device?
<samueldr>
bin/menuconfig is used to call up the kernel's menuconfig utility to configure kernel options
<samueldr>
(google for make menuconfig for more info)
<heywoodlh>
Got it. Looking online now.
<samueldr>
the installation instructions would look more like `fastboot flash boot result/boot.img` and something along the line
<samueldr>
it depends a bit on whether the device is A/B capable
<heywoodlh>
Ah yeah. When I flashed it with LineageOS it did require me to do something wierd with the A/B partitions.
<heywoodlh>
Super confusing but I did it lol
<heywoodlh>
What bootloader do you use/prefer to use with Nix?
<heywoodlh>
to clarify, I meant what bootloader do you use with NixOS Mobile
<samueldr>
on android-based devices we're mostly forced to use whatever is on the device!
<samueldr>
so this is ABL or aboot
<samueldr>
in practice the distinction changes nothing for you
<samueldr>
ABL works pretty much exactly like aboot
<samueldr>
this, in turn, boots the boot.img, which is a kernel+initramfs image
<samueldr>
the trick we're doing here is that in the initramfs we're bundling a menu to select a generation to boot from
<samueldr>
not implemented yet, it should also allow using kexec
<heywoodlh>
Okay.
<heywoodlh>
There were certain things in menuconfig that were blatantly obvious to select. Like Platform support for the SoC that's in the Razer. Any other suggestions on things I should probably make sure are selected in menuconfig?
<samueldr>
these are the "you couldn't know" changes
<samueldr>
everything else I believe can be handled through looking at the postmarketOS wiki, and comparing with walleye
<samueldr>
you'll also have some changes to apply on devices/razer-cheryl/default.nix which I haven't done
<samueldr>
mainly ab_partitions
<heywoodlh>
Okay. I'm going through the PostMarket stuff now and then I'll look at those.
<samueldr>
and mobile.usb.mode
taktoa[c] has quit [Ping timeout: 272 seconds]
<samueldr>
I would also include the "quiet" kernel command line option since it's the same SoC, maybe there is the same quirk/bug there
<samueldr>
somehow on walleye not having a quiet boot breaks the framebuffer :/
taktoa[c] has joined #nixos-aarch64
<samueldr>
their source tree is a bit unusual, it needed some different changes compared to the "universally good" patches for two out of three of those
<samueldr>
which means I'm vindicated! copying those patches per-device is mostly needed it looks like
<heywoodlh>
I didn't do all of the optional configurations for now. I plan on coming back to those later.
<samueldr>
I don't know them off the top of my head, but I think none of the optionals end up being needed to boot to the "desktop"
<heywoodlh>
Alright, I think I applied all the changes you made to my local repo
zupo has joined #nixos-aarch64
<heywoodlh>
samueldr: how do I deal with the A/B partitions on the Razer?
<heywoodlh>
Or was that in one of your patches
<samueldr>
with (only) my changes I was able to successfully build an android bootimg
<samueldr>
though I don't know if it worked (obviously)
<samueldr>
A/B is not dealt with yet
<samueldr>
I still need to find the mechanism used to tell the bootloader that the boot was successful
<samueldr>
right now after a number of boots on A, it goes to B, then the same number of boots goes into failure mode
<samueldr>
IIRC
<heywoodlh>
Okay. So how do I build an image?
<heywoodlh>
If anything, I'll try what I have now and see if it works
<samueldr>
nix-build --argstr device razer-cheryl -A build.default
<heywoodlh>
Hmm. Ran into an issue that I'm not sure why it's happening