<cidkid>
they are pretty much the same exact device except the resolution
ryantrinkle has quit [Ping timeout: 265 seconds]
<cidkid>
also, my boot img got built, but I always get gcc errors when building on nixos-unstable, but no errors when I use nixpkgs-19.09
<cidkid>
Don't know if something changed or what
<samueldr>
the cross-compilation infra had issues with glibc recently
<cidkid>
ah
<samueldr>
I *think* the fix got merged like today, so once the channels update it may work on unstable
<samueldr>
staging worked
<samueldr>
don't hesitate to ask if you have further issues, getting questions helps me know what issues others face
<cidkid>
also can I build aarch64 rootfs on x86-64 as long as I have boot.binfmt.emulatedSystems set to [ "aarch64-linux" ]; or would I have to build on a fully arm64 emulator
<samueldr>
the rootfs currently cannot build using cross-compilation
<samueldr>
a bunch of things won't cross-compile as they are
<samueldr>
but, using binfmt emulatedSystems, considering most of it is in the cache, it should work
<samueldr>
I would *still* build stage-1 (boot.img) as cross in that case
<cidkid>
I did build stage-1 as cross
<samueldr>
cool thing: the rootfs is basically universal
mDuff has quit [Ping timeout: 265 seconds]
<cidkid>
and it makes me happy to know binfm emulatedSystems will probably work
<samueldr>
I used the same exact .img on the pinephone devkit, all my aarch64 test targets, and the chromeos-based device
<cidkid>
Ah good to know
<samueldr>
I was pleasantly surprised to see that
<cidkid>
does nixos-mobile use libhybris in anyway at all at the current moment, as during the bootimg building I see that it fetches a libhybris.tar.gz
<samueldr>
libhybris in the rootfs is used by adb
<samueldr>
otherwise, it's planned to make use of it for all it can help us with, using OEM kernels
<samueldr>
I've been hard at work on early boot work, which means not much has happened on the running system still :(
<samueldr>
but, coming hopefully soon this month, everytning boot related should be solid, including generation selection
<samueldr>
(which I'm currently going back to finish up and merge)
<cidkid>
ah alright
<cidkid>
thank you for your work btw
<cidkid>
I'll talk again once I get my rootfs booting o/
<samueldr>
alright :)
<samueldr>
glad to have more device work being done :)
<cidkid>
yeah always good to see
<cidkid>
is there any plans to actually show the nix-build command to build rootfs
<cidkid>
because it took me a second to figure it out lol
<cidkid>
show in docs I mean.
<samueldr>
oops!
<samueldr>
I assumed it was there
* samueldr
opens an issue
<samueldr>
at least I now have that specific issue, in addition to "moar docs/"
<cidkid>
thats the only complaint I really had with docs, as just taking a look at another devices default.nix pretty much got me to where I could get a working boot img building
<cidkid>
nix-build --argstr device $DEVICE -A build.rootfs should work to build rootfs yeah?
<samueldr>
from the root of the repo, I believe so, but it may not build a usable rootfs
<samueldr>
you'd need to build examples/demo -A android-device IIRC
* samueldr
needs to double-check
<samueldr>
yep, this, in turn, builds the rootfs and boot.img together
<cidkid>
is android-device the device name?
<samueldr>
the attribute name is literally android-device, you still need your --argstr device $DEVICE
<cidkid>
ah
<cidkid>
alright
<samueldr>
though build.rootfs will be available soon on the demo once that PR is merged
<cidkid>
so nix-build --argstr device $DEVICE -A android-device should work
<samueldr>
nix-build examples/demo --argstr device $DEVICE -A android-device
<cidkid>
alright
<cidkid>
I'll do that if my current rootfs that is building doesn't work
<samueldr>
if you don't use examples/demo, the rootfs it would build is basically a minimal system that would be useless on the cellphone since VTs generally don't work
<cidkid>
damn
<cidkid>
alright well time to restart rootfs rebuild
<samueldr>
but the other builds on top of that one, so it's not lost exactly
<samueldr>
the demo has an XFCE-based X11 session that is actually usable to do basic stuff
<cidkid>
trace: warning: The option `services.xserver.desktopManager.xfce.extraSessionCommands' defined in `<unknown-file>' has been renamed to `services.xserver.displayManager.sessionCommands'
<cidkid>
hmm
<cidkid>
wonder whats wrong
<samueldr>
it's been a small while since I rebuilt that system image, it looks like nixos-unstable changed sessionCommands
<samueldr>
a tip, once out of stage-1, it's basically a normal nixos system, with all the good and the bad it entails :)
<cidkid>
alright
<cidkid>
I guess I'll just build the minimal rootfs until the demo build gets fixed
<cidkid>
just to test if it properly boots
<samueldr>
if on `fastboot boot` you get a white nixos logo you're almost guaranteed things will work
<cidkid>
alright
<cidkid>
would the sessionCommands error be hard to fix at all?
<samueldr>
probably not
<cidkid>
do you know what file that is defined in
<samueldr>
it's likely renaming that configuration in examples/demo/configuration.nix :)
<cidkid>
ah xserver error fixed
<cidkid>
now we have
<cidkid>
error: attribute 'targetPlatform' missing, at /nix/var/nix/profiles/per-user/root/channels/nixos/pkgs/development/tools/build-managers/meson/default.nix:91:17(use '--show-trace' to show detailed location information
<samueldr>
that could be from the cross-compilation auto-detection
<cidkid>
anyway to disable that or I'm I just screwed
<cidkid>
error:Failed assertions:- pkgs.targetPlatform.system expected to be `aarch64-linux`, is `x86_64-linux`(use '--show-trace' to show detailed location information)
<samueldr>
that's closer to what is desired I think
<samueldr>
at least it's not trying to cross-compile anymore
<samueldr>
not sure what could be missing for binfmt-based build to work
<cidkid>
oof
<cidkid>
I'll just stick with building the minimal config I guess
<cidkid>
is there a temp way to override targetPlatform?
<samueldr>
not entirely sure, I've been sticking to totally native builds for stage-2, and cross-compilation for stage-1
<cidkid>
maybe I'll set that up
<cidkid>
I don't know
h0m1 has quit [Ping timeout: 272 seconds]
h0m1 has joined #nixos-aarch64
<cidkid>
how would I setup native builds
lovesegfault has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
<cidkid>
samueldr: if you get a chance could you upload your rootfs. if not thats fine, but It'll take me a bit to setup a emulated aarch64 qemu system
<samueldr>
I think I'll build a fresh one, and informally upload it so it can be used for those that can't easily kickstart themselves with a native build
<samueldr>
wouldn't be less secure than using a random user's "kitchened" android rom
* samueldr
starts abuild
<samueldr>
anyway I was overdue, I was still relying on a system image from the community build infrastructure, which has less guarantees about security and purity than if I now launch a build on a local board at home
<cidkid>
I'm trying to setup a aarch64 qemu vm
<cidkid>
but god this is a pain
<cidkid>
is there ever plans to have a prebuilt official rootfs
cidkid has quit [Remote host closed the connection]
cidkid has joined #nixos-aarch64
<lovesegfault>
cidkid: There is one? the aarch64 sdImage
<samueldr>
a prebuilt official rootfs for mobile nixos, yes, not sure when though
<cidkid>
samueldr: what board do you compile the rootfs on
<samueldr>
a random rk3399 aarch64 board I have, I guess a raspberry pi would work too, never tried
<samueldr>
as long as it's aarch64
<cidkid>
maybe I'll get a aarch64 vm up and going
<cidkid>
and build from their
cidkid has quit [Ping timeout: 260 seconds]
lovesegfault has quit [Ping timeout: 265 seconds]
lovesegfault has joined #nixos-aarch64
cidkid has joined #nixos-aarch64
<cidkid>
someone please ping me when the rootfs gets uploaded, thank you
orivej has joined #nixos-aarch64
lovesegfault has quit [Quit: WeeChat 2.7]
<samueldr>
just saying, the build is going, though it apparently is building webkitgtk, not and a bunch of things I'm not sure make sense, I'll have to investigage
<samueldr>
not sure if this'll be over by the time I look tomorrow :)
<DigitalKiwi>
Why can't I get my pi to work
<DigitalKiwi>
Is the wiki up to date should I look at that
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 268 seconds]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
wavirc22 has joined #nixos-aarch64
orivej has quit [Ping timeout: 265 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
cidkid has quit [Remote host closed the connection]
cidkid has joined #nixos-aarch64
<cidkid>
did the rootfs ever do anything while I was asleep?
<srk>
DigitalKiwi: what images you're using for rpi? how it doesn't work?
<DigitalKiwi>
It's after I try to nixos-rebuild on it after it just never comes back I have to boot into the original one and rollback
<DigitalKiwi>
Which is ... well it's a headless pi so quite annoying
wavirc22 has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
cidkid has quit [Ping timeout: 260 seconds]
<srk>
is it stuck loading kernel? compare extlinux entries?
cidkid has joined #nixos-aarch64
<cidkid>
samueldr: I'll comment on the github issue for the docs, but you want people doing fastboot flash boot result instead of fastboot boot result due to some phones not booting the image with fastboot boot
cidkid has quit [Ping timeout: 260 seconds]
andi- has quit [Ping timeout: 265 seconds]
ryantrinkle has quit [Ping timeout: 265 seconds]
andi- has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cidkid has joined #nixos-aarch64
cidkid has quit [Remote host closed the connection]
zupo has joined #nixos-aarch64
cidkid has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
minicom has joined #nixos-aarch64
cidkid has quit [Ping timeout: 268 seconds]
ryantrinkle has quit [Quit: Leaving.]
ryantrinkle has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
zupo has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 240 seconds]
ryantrinkle has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cidkid has joined #nixos-aarch64
zupo has joined #nixos-aarch64
cidkid has quit [Read error: Connection reset by peer]
cidkid has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cidkid has quit [Ping timeout: 260 seconds]
cidkid has joined #nixos-aarch64
cidkid has quit [Read error: Connection reset by peer]
cidkid has joined #nixos-aarch64
cidkid has quit [Ping timeout: 260 seconds]
cidkid has joined #nixos-aarch64
cidkid has quit [Ping timeout: 260 seconds]
cidkid has joined #nixos-aarch64
cidkid has quit [Ping timeout: 265 seconds]
cidkid has joined #nixos-aarch64
cidkid has quit [Ping timeout: 240 seconds]
cidkid has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
cidkid has quit [Ping timeout: 248 seconds]
<samueldr>
I want it to be documented for those phones where fastboot boot will not work, right, but not outright
<samueldr>
this is, imo, a defect from those phones :(
cidkid has joined #nixos-aarch64
cidkid has quit [Read error: Connection reset by peer]
cidkid has joined #nixos-aarch64
cidkid has quit [Ping timeout: 260 seconds]
cidkid has joined #nixos-aarch64
<cidkid>
samueldr: have you started the rootfs build?
<samueldr>
it ended while I was AFK, now copying it and checking it actually runs
<cidkid>
Alright cool
<cidkid>
Thanks in advanced
Ox4A6F has quit [*.net *.split]
goibhniu has quit [*.net *.split]
Ericson2314 has quit [*.net *.split]
{^_^} has quit [*.net *.split]
alienpirate5 has quit [*.net *.split]
Irenes[m] has quit [*.net *.split]
Dezgeg has quit [*.net *.split]
fpletz has quit [*.net *.split]
flokli has quit [*.net *.split]
Ericson2314 has joined #nixos-aarch64
goibhniu has joined #nixos-aarch64
Ox4A6F has joined #nixos-aarch64
Dezgeg has joined #nixos-aarch64
Irenes[m] has joined #nixos-aarch64
flokli has joined #nixos-aarch64
alienpirate5 has joined #nixos-aarch64
{^_^} has joined #nixos-aarch64
fpletz has joined #nixos-aarch64
<samueldr>
it's currently uploading
<cidkid>
It boots?
<cidkid>
And I flash it once I get out of school
<samueldr>
it worked, yes
<cidkid>
Ping me if im online with the link
<samueldr>
(my upload speed isn't great)
<cidkid>
That's fine
<cidkid>
How big was the image
<samueldr>
3.2GiB
<cidkid>
Ight
<samueldr>
and consider there is no optimization, only a simple nixos configuration you could replicate on other nixos systems
<cidkid>
Alright
<cidkid>
Also looks like I'm flashing to userdata lol
<samueldr>
:)
<cidkid>
My system is 3g :/
<samueldr>
and that's a bigger one!
<cidkid>
So 200mb under the needes
<cidkid>
*needed
<samueldr>
some of my test devices have much smaller system partitions
<cidkid>
Ah
<sphalerite>
samueldr: btw I've got mobile-nixos running on my non-broken A1 too, just from an SD card :D
<samueldr>
at some point I'll (or someone else?) be looking at integrating LVM so you can the system partitions (A/B), and userdata merged into one block
<sphalerite>
samueldr: haven't got around to trying the new init yet though
<samueldr>
sphalerite: great :D
<cidkid>
What is the new init
<cidkid>
As I might rebuild my boot omg
<cidkid>
*img
<samueldr>
what's written on the tin :)
<samueldr>
merged yesterday definitely after you built your own boot.img
<samueldr>
the stage-1 program that boots your system has been entirely refactored, revised, all the res
<cidkid>
Ooh
<cidkid>
Alright rebuild bootimg when I get home
<samueldr>
shouldn't be required to do so, but not a bad idea to do so either :)
<samueldr>
as part of cleaning the foundations, so the next step (generation selection, recovery menu) work better
<cidkid>
Is the new init in the rootfs or?
<samueldr>
in the boot.img
<samueldr>
your older will still work, the rootfs was left untouched
<cidkid>
Alright
<cidkid>
I probably won't rebuild right now then
<cidkid>
I'm hyped for the boot menu tho
<cidkid>
I'll move over my repo to github and open a PR aswell
<cidkid>
When I get home
<cidkid>
So Oneplus 5/5T will be hopefully merged soon
<samueldr>
hopefully!
<cidkid>
Is the more specific arch patch needed for most phones
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
orivej has quit [Ping timeout: 268 seconds]
cidkid has quit [Ping timeout: 265 seconds]
cidkid has joined #nixos-aarch64
<cidkid>
samueldr: should all pull requests for device be drafts, or actual pull requests ready for review
<cidkid>
*devices
<samueldr>
when ready, undraft it, otherwise draft helps me know it's not exactly ready
<samueldr>
but as github disallows marking a non-draft PR as draft, this is not as useful as it should be
<cidkid>
What would you consider ready?
<samueldr>
that it boots, and you think it's ready to be reviewed
<cidkid>
Alright
<samueldr>
that's something I need to document as prat of the porting process: "how to PR"
<cidkid>
I'll put it as draft right now as I'm still waiting for your rootfs right now
<cidkid>
but after that I'll mark it as a actual pR
<cidkid>
*waiting for rootfs to download
<samueldr>
and as part of that guide, I want to make a "test" stage-1 that can be booted to figure out many things about the device
<samueldr>
plans, they never seem to want to be done :)
<cidkid>
if the debug boot img boots should it probably boot into stage 2?
<samueldr>
the "debug" boot image?
<cidkid>
one sec
<cidkid>
the boot image you gen from examples/demo/
<samueldr>
if you changed no setting (including added nothing to `local.nix`), it should boot to stage-2
<samueldr>
and yes, that one should
<cidkid>
alright
<samueldr>
well, not the burn tool, but that's to be expected
<cidkid>
I'll wait to do PR until I get the rootfs downloaded
<cidkid>
and installed
<cidkid>
unless draft PR could be more useful in the long run
<samueldr>
I can't really say, it's up to you at that point :)
<cidkid>
Alright draft PR made
<cidkid>
Also thank you for helping me along with all of this and answering my questions
<samueldr>
I think a draft PR, as early as possible, is not a bad idea as it shows interest in one device, somone else might just need that boost to kickstart themselves in working on the same port :)
<cidkid>
yeah fair enough
<samueldr>
you're welcome, the whole point is to have multiple people contributing and not create some kind of echochamber around myself :)
<cidkid>
After it boots I'll set it ready for review
<cidkid>
should I bother applying the 01_more_precise_arch patch or should I just leave it seeing it got fixed in nixpkgs
<samueldr>
I'm confused, I thought it wasn't fixed%?
<cidkid>
mmm maybe it didn't
<samueldr>
do you happen to own both a 5 and 5T and tested on both?
<samueldr>
while true that they are basically the same, if they use a slightly different build I rather only the one that was tested by merged, the other kept as an open PR until validated by being run on hardware
<cidkid>
I do not own a 5
<cidkid>
but if you give me a day or 2 I can have someone test it for me
<cidkid>
although I can remove oneplus-cheeseburger and commit it so it's only dumpling
<samueldr>
hmm, we may want to keep them as a "combined" device, since it looks like both are using the same kernel config
<cidkid>
I don't know how to define two different resolutions or they would be one device
<samueldr>
I see that lineageos has them as split devices, but it may be a limitation coming from them being unable to do some property work at runtime
<cidkid>
as 5T has 2160x1920 and 5 has 1080x1920
<samueldr>
to be fair, those resolution entries are currently unused by mobile nixos
<cidkid>
oh
<samueldr>
I think my main actual issue is "which name?"
<samueldr>
do you know if oneplus has a name for the combined family?
<cidkid>
no but lineageOS dev for our phone calls unified builds cheeseburgerdumplings
<cidkid>
for recoveries and things
<samueldr>
that's perfectly fine here
<samueldr>
oneplus-cheeseburgerdumplings
<cidkid>
alright let me do that real quiclk
<cidkid>
does nixos-mobile actually do anything with the amount of memory defined in the file?
<samueldr>
not yet
<cidkid>
alright
<cidkid>
as both 5/5t have 6/8 of ram variants
<samueldr>
though it's expected that the minimum amount is documented
cidkid has quit [Remote host closed the connection]
cidkid has joined #nixos-aarch64
<cidkid>
alright the commit merging them together has been pushed
<samueldr>
I don't see a BGR / RGB fix patch, just a heads up that it may be required or else colours will be wonky
<cidkid>
is that a nix only issue?
<samueldr>
unsure
<cidkid>
as postmarketOS didn't need a RGB patch
<samueldr>
I think it's a multi-prong issue
<samueldr>
they use a green logo
<samueldr>
the green channel is untouched :)
<cidkid>
ah but the background in weston didn't look miscolored
<samueldr>
I haven't verified
<samueldr>
but yeah, other prong
<samueldr>
I think weston knows how to deal with BGR
<cidkid>
ah alright
<samueldr>
meanwhile, ply-image (or is it fbdev?) doesn't
<cidkid>
You know I was actually just looking at that one lol
<samueldr>
considering it's of the same vintage, it's expected that usb rndis won't work with the older init, and will require some configuration with the new init
<samueldr>
adb will not work as it is
<cidkid>
alright
<cidkid>
I just built a new boot img based on the new init
<cidkid>
will see how that functions
<cidkid>
gmm
<cidkid>
*hmm
<cidkid>
odd I'm not getting the yellow screen with frowning phone with the non android-burn-tool while building with new init
ryantrinkle has quit [Ping timeout: 245 seconds]
<samueldr>
right, it's the one regression with the new init, that I have to fix with a non-trivial fix
<cidkid>
oh alright
<samueldr>
it waits indefinitely for the NIXOS_SYSTEM drive to appear
<cidkid>
android-burn-tool isn't doing anything either now
<cidkid>
is that a known regression aswell or is that a bad sign?
<andi->
Is there a pinebook pro contender yet? I am primarily concerned about the RAM amounts :/
<samueldr>
considering you don't have RNDIS on your device, you wouldn't be able use the burn tool anyway
<cidkid>
yeah but that let me know if framebuffer and all worked properly
<samueldr>
though I think that I forgot that I removed the yellow/green screen thing
<cidkid>
oh alright
<samueldr>
it's all going away with the early boot UI where a more appropriate status display will be shown
<samueldr>
andi-: not really
<samueldr>
andi-: it's still the best non-windows-on-arm one
<samueldr>
andi-: and the windows on arm ones are not much better ram-wise
<andi->
I am so sick of this Dell XPS being super slugish in every regard... I have the feeling it is mostly Intel that is to blame.
<samueldr>
(with the added worry that it's a piece of junk)
<samueldr>
those windows on arm devices have a weird setup where the eMMC is co-opted to also store the firmware of your device, but is "secure" so you can't change it...
<samueldr>
... except that you can still manipulate it and brick the device
<samueldr>
just like qualcomm phones :(
<samueldr>
it's basically a qualcomm phone, but with a hinge and keyboard
<andi->
awwh, not gonna touch those then
<flokli>
samueldr: what arm laptop would you recommend to use if you'd have the choice?
<flokli>
something rockchip-based?
<samueldr>
AFAIK only the pinebook pro is a real thing
<samueldr>
the MNT reform probably wouldn't pass airport security
<samueldr>
in addition to having the weirdest keyboard layout
<samueldr>
anything current allwinner-based is not gonna have the oomph, in addition to be limited to 2GiB of RAM
<cidkid>
with the new boot UI thing be able to be flashed to recovery and used as a recovery type thing?
<cidkid>
as the only reason I'd need to change generations would be a nixos-rebuild that bugs something out
<samueldr>
cidkid: it already is flashed to recovery on one of my test device, dogfooding it to easily poweroff the device, rather than rely on TWRP :D
<cidkid>
ah nice
thefloweringash has joined #nixos-aarch64
<thefloweringash>
What’s this, Allwinner has a memory limit?
<cidkid>
good to know
<samueldr>
hi thefloweringash
<thefloweringash>
Hello!
<samueldr>
all boards have limits, A64 is limited to to GiB of ram
<samueldr>
(funny to see you join with that question)
<thefloweringash>
(I’m always lurking)
<andi->
samueldr: that is probably the matrix bridge being evil again... he probably got a lot of history
<samueldr>
to 2 GiB of RAM*
<samueldr>
ah
<thefloweringash>
I didn’t have anything to add or ask until that :-)
<samueldr>
I generally keep joins/parts off
<samueldr>
I don't think allwinner per-se is limited, but the A64 is
<samueldr>
just like RK3399 is limited to 4GiB
<thefloweringash>
Oh did the bridge /join me when o started sending?
<andi->
yes
<samueldr>
on my side yeah
<thefloweringash>
That’s entertaining, oh dear
<clever>
yeah, spooky when you respond to a convo you couldnt have seen, lol
<samueldr>
there is one platform I don't know of yet: mediatek chromebooks
<samueldr>
one big minus: mediatek
<samueldr>
one big plus: corebot
<samueldr>
coreboot*
<samueldr>
though the current ones seem as limited ram-wise
<samueldr>
I don't know if it's a platform limit or OEM being cheap
<cidkid>
what are the big issues currently with the Boot UI if you don't mind me asking
<samueldr>
cidkid: implementing it
<cidkid>
ah
<samueldr>
I need to take one step back from the POC, and make bindings in mruby for the GUI library
<samueldr>
but the biggest question mark, which GUI library, is now answered
<cidkid>
well thats good
<samueldr>
I wouldn't touch a mediatek chromebook with a long pole, considering google ships chromeos with 3.18 series kernel, that must mean they can't do much better like they do for RK3399 :/