<Ke>
anyway, I had compile failure due to unknown compiler flags, did not check, if I did something different from mobile-nixos
<Ke>
I am very keen on keeping to one kernel for all the devices
<Ke>
so I wanted to extract the works as patch
<Ke>
the compiler flags had something to do with fpu and neon for some display code
<Ke>
but thanks, good to know anyway
<samueldr>
Ke: in aegis 128?
* samueldr
looks up the known issue
<Ke>
also nadia's u-boot code seems to work for her built binary, but not the one I patched with her patches
<samueldr>
starting from the same base u-boot?
<Ke>
so I am now using u-boot with video support
<samueldr>
ah, you switched device on me!
<samueldr>
I was about to say that the pinephone doesn't _require_ any patches IIRC
<samueldr>
ah, it does still
<samueldr>
(mainly for the 3GB variant)
<Ke>
I switched device on the also line, I am aware of that initial topic was pinephone
<samueldr>
(for pinephone still) I pick them all from the patchwork instance, for those that are needed
<samueldr>
they may very well be part of master and upcoming 2020.04
<Ke>
"also"-line
<samueldr>
yeah :)
<samueldr>
I haven't kept up much with the pinebook pro stuff
<Ke>
yes, I'll probably use mobile-nixos u-boot verbatim
<samueldr>
there's a new patchset on the patchwork from arnaud
<Ke>
I already imported it to my module
<samueldr>
which is AFAIK mainly a cleanup/rebase of the previous
<samueldr>
hmm, I can't seem to surface the known issue for that isse you had with CONFIG_CRYPTO_AEGIS128
<Ke>
I should really get a setup for testing the external display on pbp
<samueldr>
(I just end up disabling it, personally)
<samueldr>
oof, eDP type-c, always fun ;)
<Ke>
but mostly my pbp setup is done to acceptable extent
<samueldr>
note that something in the setup *may* have an orientation
<samueldr>
so try the cable both ways, and both ways
<samueldr>
meaning, turning the connector on the port 180°, and *also* swapping the ends
<Ke>
hmm crypto aegis does not seem display code, but maybe I missread the compilation failure context due to -j16
<samueldr>
(the latter it never happened to me, but I've seen it reported by trusted sources as a baffling issue)
<samueldr>
Ke: if it's the issue I was thinking about, though if you search the exact error message you had, IIRC a nixpkgs issue by the//floweringash should surface
dev_mohe has quit [Remote host closed the connection]
cole-h has quit [Ping timeout: 256 seconds]
zupo has joined #nixos-aarch64
Acou_Bass has quit [Ping timeout: 260 seconds]
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
v0|d has joined #nixos-aarch64
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<leonardp>
woohoo. i managed to boot a nanopi r4s with mainline kernel/uboot + patches only
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
jumper149 has joined #nixos-aarch64
jumper149 has quit [Quit: WeeChat 3.1]
jumper149 has joined #nixos-aarch64
zupo has joined #nixos-aarch64
jumper149 has quit [Client Quit]
rajivr has quit [Quit: Connection closed for inactivity]
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
jumper149 has joined #nixos-aarch64
jumper149 has quit [Quit: WeeChat 3.1]
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
jumper149 has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jumper149 has quit [Quit: WeeChat 3.1]
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
jumper149 has joined #nixos-aarch64
jumper149 has quit [Client Quit]
pbb has quit [Remote host closed the connection]
pbb has joined #nixos-aarch64
orivej has quit [Ping timeout: 245 seconds]
orivej has joined #nixos-aarch64
<samueldr>
Ke: it should have working FDE, all part of stage-1, so xorg is not in the picture
<samueldr>
(jumper149 who left) it could, once booted, it's mostly a NixOS system with some specialized configurations
<samueldr>
but "at this point" is extremely variable, is the software packaged (mostly not yet) can the specific device use the desired software (maybe)
<samueldr>
e.g. phoc as it is right now probably wouldn't work on anything else than the mainline-based devices where DRM+KMS is supported
<samueldr>
so basically generic uefi, and then pinephone and the chrometab
<Ke>
samueldr: how does text input work before graphics?
<samueldr>
custom implementation (based on standard libraries)
<samueldr>
but making it happen on your device is left as an exercise to the reader for the time being
<samueldr>
(it's part of my milestones for work, so it will happen during this year)
<samueldr>
the important part is that it's the same configuration as you would for NixOS
<samueldr>
stage-1 knows it's LUKS, so it knows to unlock it to make the partition available for mounting
<samueldr>
so you could, for example, boot a mobile nixos system from SD, flash the unencrypted image to the emmc to get the partitions right, resize them using something like cfdisk or cgdisk, maybe re-label the partname for the last partition, then do the usual luks dance to encrypt a partition
<samueldr>
my pinephone is dogfooding luks, so it should stay working
rmcgibbo[m] has left #nixos-aarch64 ["User left"]
orivej has quit [Ping timeout: 246 seconds]
zupo has joined #nixos-aarch64
<gchristensen>
I dragged my odroid c2 out today to play with
<gchristensen>
...right. this one has the serial port with the plug that I can't hook up my regular adapter to. hrm.
<gchristensen>
I think I know why I put it in the bin :P
<samueldr>
that's why the adafruit 954 and clones is quite nice
<samueldr>
distinct cables rather than a forced interface
<gchristensen>
that is what I have!
<gchristensen>
but the header on the c2 is shielded in a way I can't hook up
<samueldr>
I was able to confirm the breakout board brought up the proper RX/TX lines
<gchristensen>
nice :D
<gchristensen>
[root@elzar:~]# nixos-version
<gchristensen>
21.05pre276061.5e367ecef91 (Okapi)
<gchristensen>
that's better.
<zhaofeng>
Hi all, I'm trying to build the disk image for razer-cheryl2, and the build fails with `error: make_file: failed to allocate inode`. I definitely have enough space (>100G) in the directory. How would I go about debugging that?
<samueldr>
we are building the system image for the demo already!
<samueldr>
you can literally plonk that on your device and it will work*
<samueldr>
* (your mileage may vary)
<samueldr>
for every aarch64 devices this has worked, including pinephone, cheryl2, z00t, dumo, etc
<samueldr>
so you can have a trusted (assuming you trust nixos.org) starting point for the stage-2 system
<zhaofeng>
Oh great! I actually just want to use the device as a build machine for aarch64 stuff instead of getting graphics etc. to work, so my expectations are pretty low :P
<samueldr>
I would expect the demo rootfs to work once you have a port going
<samueldr>
so I assume you want to port to oneplus6
<samueldr>
are you interested in starting first with the vendor kernel?
<samueldr>
(I don't know how mainline will fare with anything)
<zhaofeng>
Yeah, I'm starting with the kernel from LineageOS
<samueldr>
good
<samueldr>
tip: start with `autoport` rather than with the cheryl2 config
<samueldr>
the autoporter will extract a known good vendor config from a vendor image
<zhaofeng>
Oh, on the topic of autoport, the FBI has joined the game and git.rip doesn't exist anymore :P
<samueldr>
:|
<samueldr>
gosh darn it
<samueldr>
the extracted android dumps project wasn't even close to being illegal
<samueldr>
annoying that their choice of host caused them to be removed
<samueldr>
but I *think* git.rip was... chaotic neutral aligned, in a way
<samueldr>
so it doesn't really surprise me
<zhaofeng>
Well yeah, I'm not entirely sure what dramatic stuff has git.rip done recently
<zhaofeng>
except for the gab source code mirror, which is 100% legal as it's GPL
<samueldr>
someone must have uploaded something bad to it
<samueldr>
>> The most illegal user there is exconfidential. It hosts above 200 company leaks. Including highly illegal Apple, CDProjektRed, Nintendo, NISSAN, Intel, and other leaks
<samueldr>
probably that
* samueldr
sighs
<samueldr>
hopefully the android dumps project figures out a less "hot" location to host their dumps
<samueldr>
it's EXTREMELY invaluable
* zhaofeng
shrugs
<samueldr>
a somewhat normalized dump of vendor images of android systems really was helpful to guesstimate what devices had which features
<samueldr>
I guess I'll have to take the time to work from actual OTA images and factory images rather than cheat
WilliButz has quit [Remote host closed the connection]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<gchristensen>
I then wondered is Image nixos or some odroid provided thing? should I back it up?
<gchristensen>
then:
<gchristensen>
looking at boot.ini, I saw: setenv bootargs "root=UUID=e139ce78-9841-40fe-8823-96a304a09859 rootwait ro ${condev} no_console_suspend hdmimode=${m} m_bpp=${m_bpp} vout=${vout} fsck.repair=yes net.ifnames=0 elevator=noop disablehpd=${hpd}"
<samueldr>
(most likely you were booting from SD, and the EMMC wasn't involved)
<gchristensen>
and wondered is that UUID my UUID, or the Image UUID?
<gchristensen>
I don't have a SD card
<samueldr>
I uh
<samueldr>
whew
<samueldr>
yeah, that kind of goes with what I had in mind: the firmware is annoying to grasp
<gchristensen>
yeah
<samueldr>
firmware here is u-boot, which handles the boot process
<samueldr>
and since it's part of the main storage, it really puts a big ol' wrench in the cogs
<gchristensen>
so I'm not sure if I need to be super careful and back this up, or just completely ignore it and make my own /boot vfat boot partition or ...
<samueldr>
I'm not fully confident with the amlogic stuff yet
<gchristensen>
yeah
<gchristensen>
so that is why I lost energy :P I think I'll just stick it back in and let it be ext4
<samueldr>
and then AFAIUI each vendor *can* have some differences with amlogic
zhaofeng is now known as zhaofeng_ircclou
<samueldr>
because, I'm not sure about this bit, but I believe each vendor may have their own signing keys in the boot process?
<samueldr>
there's something funky going on with amlogic and the way it verifies boot
<samueldr>
so some vendors (all?) have a custom tool to prepend their signed... things... at the start of the boot chain