<nschoe>
Hi everyone, I'm having a bit of an issue. This morning I successfully managed to cross-compile a haskell package (trivial hello world) from laptop to a rPi3 target. I copied the clojure and it works, yay \o/
<nschoe>
- first of all --dry-run doesn't show the usual "these will be built/fetched" but starts copying right away
<nschoe>
Now every thing fails weirdly: 'nix-build -A test-hpi --dry-run' :
<nschoe>
Now I'm try to do the same with a trivial example using HPi. Since it's marked as broken in nixpkgs(and refers to an old 0.5.1 version), I've decided to write an override and this is what I've got: https://paste.ofcode.org/3rexdNnrGiNXjbfQkeyHca . Conceptually simple: my test-hpi depends on HPi and I'm overriding the HPi with the new version.
<nschoe>
I see downloads from cache.nixorg.org as if... I was not building for aarch64.
<nschoe>
- third I don't understand all these dependencies as HPi only depends on bytestring and base
<nschoe>
Have I missed something in the way I wrote my default.nix?
<nschoe>
(Sorry for long message, I wanted to give context :D)
<nschoe>
Thanks in advance for your time & help :)
<bennofs[m]>
nschoe: those dependencies may be due to callHackage perhaps? since callHackage requires cabal2nix which might require some downloads?
<bennofs[m]>
just a guess
<bennofs[m]>
the log you posted has no error, did it finish like that?
<nschoe>
bennofs[m]: okay for the deps. I genuinely have no idea, though I feel like it's an awful lot of deps for callHackage. But okay.
<nschoe>
The log doesnt' produce errrors because I CTRL + C it
<nschoe>
As I was afraid it would pull too many thingsand fill my disk.
<nschoe>
bennofs[m]: I've tried another run, I just modified my default.nix file to return hspkgs.test-hpi (I know it's the same but I was running out of rationality).
<nschoe>
I'm also letting it build this time, to see what happens.
<bennofs[m]>
if cabal2nix is not statically linked (default is not for haskell packages in nixpkgs afaik), then it pulls all deps as well
<bennofs[m]>
it would also explain why you didn't get the "will be built..." yet, since cabal2nix is required at evaluation time (the fetching is triggered during evaluation of your default.nix)
<nschoe>
bennofs[m]: okay so the fatc that it was copying things from the cache is because those deps are 'nativeBuildInputs' and will run on my host.
<nschoe>
I see.
<nschoe>
So it's a one-time thing: I need to let it build.
<nschoe>
bennofs[m]: thanks for the help :)
<nschoe>
I'll let it build and see what this gives.
<thefloweringash>
what am I doing wrong? if I boot mobile-nixos directly I see stage-1 then a black screen. if I boot recovery I see stage-1, the pretty menu, then stage-2 and a login prompt.
<samueldr>
thefloweringash: oops
<samueldr>
I think it's my fault, since I mostly verify with OEM kernels without a VT, it slipped past
<samueldr>
so your console is likely there, but not presented
<thefloweringash>
I'm used to linux just using whatever framebuffers it finds. There must be something mapping it away at the end of stage 1 if I can see the stage 1 output?
worldofpeace has left #nixos-aarch64 ["User left"]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<nschoe>
Hey all, do you know if library bcm2835 is packages somewhere for the rPi (rPi 3B is that matters)?
<srk>
hey, what are you looking for? :)
<srk>
(trying to do)
<nschoe>
srk: hi again (thanks again :D). I'm still working on cross-compiling packages for my rPi. This time I've made a small (trivial) prograsm which uses HPi (https://hackage.haskell.org/package/HPi).
<nschoe>
But the cross-compilation fails with "error: anonymous function at /nix/store/vdp83skxk0als8wd319szp6gp7035rp3-cabal2nix-HPi-0.7.0/default.nix:1:1 called without required argument 'bcm2835'"
<nschoe>
And indeed, on my laptop 'nix search bcm2835' doesn't produce any result.
<nschoe>
I've launched a 'nix search -u bcm2835' on the rPi buts it's been 10 minutes, CPU is at 11% and memory is at 89% consumed by nix search and still no result.
lordcirth has quit [Read error: Connection reset by peer]
<hexa->
probably faster to ripgrep nixpkgs.git :)
lordcirth has joined #nixos-aarch64
<nschoe>
srk: so the TL;Dr is that I'm trying to cross compile a (haskell) package which needs 'bcm2835' as external library.
<nschoe>
hexa-: on the rpi you mean?
<hexa->
on any checkout you have lying around
<nschoe>
But I would need to git clone nixpkgs, even with --deth=1 I'm afraid it's going to take some time.
<srk>
I'm not aware of any such library that's why I'm asking :)
<srk>
,locate bcm2835
<{^_^}>
Found in packages: linux.dev, linux-libre.dev, linux_mptcp.dev, linux_testing.dev, linux_mptcp_94.dev, linuxPackages_4_4.kernel.dev, linuxPackages_4_9.kernel.dev, linuxPackages_5_5.kernel.dev, linuxPackages_4_14.kernel.dev, linuxPackages_4_19.kernel.dev, linuxPackages_hardened.kernel.dev, linuxPackages_xen_dom0.kernel.dev, linuxPackages_latest-libre.kernel.dev, linuxPackages_latest_xen_dom0.kernel.dev, and 3 more
<hexa->
just blaming hackage-packages.nix :3
<srk>
and 3 more :D
<srk>
> haskellPackages.bcm2835
<srk>
> pkgs.haskellPackages.bcm2835
<{^_^}>
attribute 'bcm2835' missing, at (string):306:1
<{^_^}>
attribute 'bcm2835' missing, at (string):306:1
<nschoe>
srk: hum this is not a haskell package, this would be an external library.
<nschoe>
This is a rPi-specific library I reckon.
<hexa->
8897: librarySystemDepends = [ bcm2835 ];
<nschoe>
Deals with the SoC
<srk>
a yeah
<srk>
just found the same thing as hexa- :)
<srk>
haha
<srk>
and right bellow is {bcm2835 = null;}
<hexa->
introduced in 0139c51f1bb9
<srk>
so it's not in nixpkgs
<hexa->
hrhr
<hexa->
like a stub?
<nschoe>
hexa-: probably: must explain why the package is marked as broken.
<nschoe>
srk: he hbot returned some packages in which it was found, right?
<nschoe>
So I guess I'll have totry and package it from source
<nschoe>
clever: yes (sorry I shoul dhave provided the link, my bad)
<clever>
> This package is a FFI wrapper around the bcm2835 library by Mike McCauley
<{^_^}>
undefined variable 'This' at (string):306:1
<nschoe>
clever: yes that's the one.
<clever>
In order to compile programs including this library, you will need to have the bcm2835 library installed. It can be found at http://airspayce.com/mikem/`bcm2835`/index.html.
<srk>
do you really need it? :) I mean it's a bit Pi specific and there are standard ways to do SPI/I2C/GPIO
<clever>
nschoe: so the library just isnt packaged yet, youll want to package it, and use an overlay to put it at pkgs.bcm2835, then cabal2nix will find it seamlessly
<nschoe>
clever: no indeed. I think nobody packaged it yet.
<nschoe>
clever: yep that's it.
<srk>
pff, there's bunch of these pi specific libs on hackage
<nschoe>
srk: ?
<srk>
nschoe: pi ecosystem is weird due to things introduced by raspberry pi foundation
<nschoe>
srk: well I don't need HPi specifically, but I need I2C accessfrom Haskell :)
<nschoe>
srk: ah, okay.
<srk>
nschoe: e.g. you can control gpio via libgpiod (and also via now deprecated /sys/class/gpio)
<clever>
nschoe: i2c access, you can do with standard i2c stuff
<srk>
same with SPI ^ :)
<clever>
nschoe: just /dev/i2c-0 and `modprobe i2c-dev` i think
<nschoe>
clever: I have no idea what "standard i2c stuff" mean. I previously used wiringPi when I used rapsbian. I udnerstadn I2C protocol all right. But not how to use it "the normal way" on Linux.
<clever>
nschoe: linux itself can drive the i2c controller for you, and will show up under /dev/i2c-0
<nschoe>
clever: okay so i see h2C and hsI2c indeed.
<nschoe>
clever: yes I have used i2cdetect in command line before indeed.
<nschoe>
Just assumed it was exposed by wiringPi when I used it.
<nschoe>
But... now ^^
<srk>
nschoe: I love pifoundation for that, searching for anything pi related needs to include 'mainline' or you get raspbian related stuff :)
<clever>
nschoe: ive also done some special i2c stuff on my pi's
<nschoe>
clever: like what?
<clever>
nschoe: normally on a pi, you must mess with the gpio alt functions, to map an i2c controller to a certain set of pins, before you do the i2c action
<nschoe>
srk: yes its' always raspbian-specific. But I really want to give NixOS a try on the rPi :)
<clever>
nschoe: and you either do that at boot (in config.txt) or with /dev/mem writes
<clever>
nschoe: but, you can explain the entire mux to linux
<clever>
this code, creates 3 more i2c nodes in /dev/
<clever>
and linux will remap the alt functions for you, when you try to read any of them
<clever>
but on the rpi 1-3, there isnt very many choices for which pins to route them to
<clever>
most of the other options are "internal" things you shouldnt be touching normally
<clever>
nschoe: what is your end-goal with the i2c stuff?
<nschoe>
clever: on my robot, I have a motor controller and an arduino, both talking on I2C with my rPi
<clever>
ah, nice
andi- has joined #nixos-aarch64
<nschoe>
:)
<clever>
you might also be interested in my open firmware stuff
<nschoe>
the link you showed a couple messages ago?
<clever>
yeah
<clever>
it can boot nixos on the rpi2 and rpi3
<nschoe>
Nice.
<nschoe>
What's the goal when compared to the official firmware?
<clever>
support all of the hw, but be open source
<srk>
nschoe: motors + i2c = danger :D ;)
<nschoe>
clever: okay. Well each day its own battle. Now I'm fighting with NixOS + raspberryPi + haskell + cross compilation. I'll try the open firmware late r:)
<nschoe>
srk: why is it dangerous? ^^
<nschoe>
srk: it's been runing fine formany years for me :)
<srk>
noonien: depends on motor size obviously but I've learned it the hard way with i2c encoders - when motors were enabled it screwed i2c bus and robot started spinning madly :)
<srk>
bot for a local competition, was quite fun but also epic fail
<clever>
srk: sounds like EMI
<clever>
needs moar shielding!
<srk>
(more specifally i2c over wires + motors ..)
<srk>
clever: no, differential bus :)
<nschoe>
I'd agree with clever
<srk>
rs485 or CAN
<clever>
nschoe: with the open firmware, you can also do custom stuff on the VPU, for more compute offload
<clever>
nschoe: is the motor controler the kind where you set a speed+direction over i2c?
<noonien>
protocols that don't have differential pairs are not made to work over long distances (long distance is probabably >2-3cm, in this case)
<nschoe>
But I want to make a robotics tutorial and KISS. So I'm using a well known controller board, I2C-based.
<nschoe>
Well ideally I don't yse i2c for board to board communication, as you said it's too fragile and EMI kills it. I only use I2c to communicate on same board.
<nschoe>
I think it support SPI too, though...
<srk>
exactly :)
<noonien>
you could use shielding, but that will just make your problems less frequent
<nschoe>
noonien: yeah, agreed. Arduino's Wire library it notoriously bad at this. It will hang when I2C doesn't behave as expcted.
<clever>
nschoe: the kind of compute offload the open firmware allows, would let you do that timing stuff right on the VPU, in the rpi's firmware
<clever>
nschoe: it could (for example), even drive the motors before linux has booted
<noonien>
i'm actually working on something similar, i hate c++ with a passion so i'm converting my current project to rust
<noonien>
and some C FFI for the arduino parts that i have to use atm
<nschoe>
srk: ohI've been into robottics fro 4 years now ^^
<nschoe>
I'm just using the quarantine time to __finally__ freshen up my robot and (hopefully) make it a tutorial: Autonomous robot + Haskell + NixOS. How does that sound? :D
<srk>
:))
<nschoe>
srk: oh nice project!
<nschoe>
noonien: well, let's keep in touch then :)
<srk>
noonien: I've been following embedded rust since zync.rs times but then I've found ivory/tower :)
<nschoe>
I also plan on using arduino-copilot to generate C code for the arduino. alp is the one who introduced me to this. I can't wait to test this
<srk>
++
<noonien>
i'm working on an ventilator for covid pacients, the project will be OSS, i'll probably package important stuff with nix so it'll be easy to work with
<clever>
noonien: have you seen the real engineering video?
<noonien>
i would have used a STM32, but the hardware choice was out of my hands. stm32 has increddible rust support
<srk>
noonien: yeah, I was thinking about repurposing my bldc controller for that :)
<noonien>
clever: not popped in my news feed yet
<alp>
noonien, a coworker did just that, it's great to see a bunch of initiatives like this everywhere
<srk>
nschoe: join us on #haskell-embedded ;)
<nschoe>
srk: sure
<noonien>
we're currently using a stepper to drive 2 arms to push on a resursication bag, but we've just got hold of a medical blower fan, with a really strange bldc driver
<srk>
alp: theres' a bunch of initiatives but lacking coordination :(
<clever>
noonien: he goes over the real problems, about how a Ventilator can damage the lungs if not functioning "properly"
<noonien>
ah, 24 days ago, weird that it has not popped up in my feed, would have thunk google was better at tracking what i do :D
<clever>
and how a lot of the home-grown solutions dont deal with those issues
<noonien>
yes, we've got several mechanica and software failsafes in place
<srk>
and fw verification? :)
<clever>
noonien: thunderfoot has also been making a number of covid videos, and google has been smiting him, lol
<noonien>
we've also spoken to doctors and other people that are doing this
<clever>
noonien: if you search for his video, by exact title, with thunderfoot in the search string, it doesnt appear anywhere
<noonien>
yeah, i'm aware of his situation, i'm a big fan of descentralization, hopefully we get rid of big corporation taking over the internet at some point
<noonien>
there's really no good reason for youtube to exist anymore, imho.
<noonien>
we've got flow and pressure sensors on the inspiration and expiration pathways. and we use them, i'm going to compute the lung resistance and conformity after i finish with the rust rewrite
<clever>
nice
<srk>
noonien: opensource/hw?
<noonien>
i've already got flow and pressure control working with a simplle PID
<noonien>
it's not updated in a few weeks, the software has been completely rewritten
<srk>
and platform is still rpi + mega?
<noonien>
the electronics are ran by a teensy atm.
<srk>
ok
<nschoe>
Erf I get only Read failed with i2cget :/
<clever>
nschoe: what does i2cdetect and i2cdump say?
<noonien>
i'm also working on spontanous patient breathing, meaning that when a patient tries to inspire, the system will detect it and trigger a breath cycle
Thra11 has quit [Ping timeout: 244 seconds]
<nschoe>
clever: i2cdetect -y 1 does detect the shipt at the correct address
<noonien>
learning to measure flow with venturi tubes was interesting
<srk>
nschoe: yeah, that's what I wanted to do as well since I have current sensing already :)
<nschoe>
srk: ? message was for noonien no?
<srk>
yes
<srk>
sry :)
<nschoe>
np
* srk
trying to finish some modules while bragging on irc, confusing :D
<noonien>
we're using a differential pressure sensor and a 3d printed venturi tube
<srk>
cool!
<nschoe>
srk: holly sh*t! i2c dump just thread hell! xD I ran i2c dump and motors started to turn very fast :D
<srk>
:D
<srk>
clever: ^ danger danger :D
<clever>
nschoe: i2cdump is designed for smbus style i2c stuff, and some devices also perform actions on read
<noonien>
it'll be a bit interesting to learn how to package rust with the required toolchains using nix
<noonien>
i currently use rustup
<srk>
noonien: I can now do nix-build and get a firmware bin from haskell -> c -> arm-gcc :D
<srk>
(only stm32 for now tho)
<nschoe>
clever: well apparently the MD25 controller does something
<nschoe>
on read*
zarel has quit [Ping timeout: 256 seconds]
<nschoe>
clever: for i2cget to work, I don't have anything "specific" to do beforehand, like enabling / openeing a socket or smth?
<clever>
nschoe: nope
<nschoe>
Just run as root and it's supposed to read the byte, right?
<clever>
nschoe: but, i2cget works by writing a register number, then issuing a read
<clever>
nschoe: and some i2c devices work differently
<nschoe>
clever: yes, but that is supposed to be standard.
<nschoe>
ah?
zarel has joined #nixos-aarch64
<srk>
_supposed_ :)
<clever>
nschoe: youll have to read the docs for your controller to see what exactly it does
<nschoe>
yes.
<clever>
o read one or more of the MD25 registers, first send a start bit, the module address (0XB0 for example) with the read/write bit low, then the register number you wish to read. This is followed by a repeated start and the module address again with the read/write bit high (0XB1 in this example). You are now able to read one or more registers. The MD25 has 17 registers numbered 0 to 16 as follows;
<clever>
the docs do agree with that
<nschoe>
Yeah, maybe this has to do with this 7 vs 8bit address
<clever>
i think all addresses are 7bit, and the 8th bit is if its a read or write
<nschoe>
noonien: thank :)
<clever>
nschoe: what about i2cget and i2cput? do those work?
<noonien>
(i'm not sure if you're driving a bldc or a stepper, sorry, this is for a stepper)
<srk>
trinamic? :)
<noonien>
yeah :D
<srk>
(no youtube here :D)
<nschoe>
clever: yes, butwhat I mean is that i2cdetect shows my device on 0x58. Maybe I'm supposed to add the 0 or 1 myself wih i2cget
<nschoe>
noonien: in my current small robot those are brushed DC motors ^^
<noonien>
TMC2130 V2
<nschoe>
But the video looks interesting anyway.
<clever>
nschoe: i2cget and i2cdetect both operate in the same 7bit space
<noonien>
nschoe: i see, good luck! :D
<nschoe>
clever: okay so that's not it :D
<clever>
nschoe: on the actual wire, the address is shifted by 1 bit (*2), and the r/w bit is added in
<srk>
noonien: I'm BLDC all-in now :D
<nschoe>
srk: I agree. But this robot is designed, again, to be reproducile by beginners
<srk>
nschoe: yup, nothing wrong about that :)
<nschoe>
srk: otherwise I'd have made the controller board myself :D :D
<srk>
nschoe: I wanted to do a rpi shield with two DC/BLDC motors as well but didn't get to it
<noonien>
yeah, i see that the BLDC tech has improved a lot in the past few years
<srk>
nschoe: the idea was/is to run CANOpen via SLCAN (basically CAN over UART) :D
Thra11 has joined #nixos-aarch64
<clever>
srk: if you lack a proper motor controller and only have some H bridges, then my custom firmware may be of use
<srk>
clever: I'm building CANOpen 402 compliant servo controller for a few years now :)
<nschoe>
Okay something is definitely off, i2cget does return some values now, but they are meaningless.
<nschoe>
*sigh* I need a break I think :=)
<clever>
nschoe: got a scope?, try peeking on the lines
<clever>
srk: https://imgur.com/dIbqouE this would be the VPU bit-banging an 80mhz signal, and i could generate more complex waveforms like a stepper drive
<clever>
srk: https://imgur.com/H2i43Mj and then i pushed it as hard as i could, 125mhz (note, i only have a 100mhz scope, lol)
<srk>
pff, need to switch pc, imgur won't load.. :D
<clever>
srk: and the jitter was low enough that i cant measure any on my scope (though i'm past nyquist, lol)
<srk>
clever: cool! steppers are pretty hard to control with mcus due to this
<clever>
srk: in theory, you could program the VPU to generate stepper phase signals
<clever>
micro-stepping might be a problem, not sure
<srk>
why? that's just more pulses :)
<clever>
the issue, is that to talk to the linux/arm cores, you have to go out to dram (enless you exclusively use a 32bit cmd fifo)
<clever>
and that will cause the cpu to stall for a short period
<clever>
and then your micro-stepping hangs on a random state
<clever>
without micro-stepping, you can "safely" stop at any state, and the stepper will hold its position
<clever>
(ignoring inertia)
<srk>
true
<srk>
like ideally you would drive steppers using FOC (Field oriented control) but that requires FPGAs :)
<srk>
and is actually harder than FOC for BLDC
<clever>
srk: and you know why the ARM typically doesnt do the stepper signals itself?
<noonien>
that's great, how much memory does it have? does it use the sd card at all?
<clever>
noonien: so, you could have an rpi4 run custom code immediately on power up (about 0.7 seconds)
<clever>
noonien: if i use custom SPI firmware, i loose the dram init code, so your limited to 128kb, maybe 1mb
<noonien>
srk: awesome!
<srk>
noonien: doing my decentralization part :D
<clever>
noonien: you also loose access to the arm cores
<noonien>
i see
<clever>
noonien: ive not figured out arm or dram yet, on the rpi4
<clever>
noonien: but if you dont need more ram, you can get custom code running on an rpi4 in under a second from power-on, so the hw will be cheap, it just wont be a normal rpi env
<noonien>
mouting an usb drive and doing a kexec would also be a solution perhaps
<noonien>
the rpi is only used as an interface to the operator
<clever>
noonien: you shouldnt even need kexec, you can put the entire rootfs into the initrd, or have the initrd load a squashfs into ram on bootup
<noonien>
it's not neccesarely vital, except for stopping the machine, or changing the parameters
<clever>
noonien: you may also want to look into my haskell-init project
<ornxka>
they were able to achieve code execution and the easiest way to get output was to just play the entire binary/contents of memory through the headphone jack
<srk>
!!!
<srk>
ornxka: that's why they ditched the jack? :D
<ornxka>
it must be :p
<thefloweringash>
srk: your ls1k is sometimes just hanging?
<srk>
thefloweringash: no it was hanging with linux_latest at that time when I've tried to run nixos on it natively
<srk>
I don't have access to it anymore tho, now trying to upstream novena armv7l stuff :D
<srk>
it's so close..
<thefloweringash>
hmm, my lx2k sometimes just disappears. nothing on the serial port, just gone.
<srk>
wow
<srk>
this imx6q starts overheating after like 8 hours of compiling kernel and it leads to weird compilation errors :D
<srk>
need to either add fan or compile on just 3 cores :D
<lordcirth>
srk, on my PBP I disabled some cores to prevent overheating
<srk>
^^
<srk>
PBP?
<srk>
pinebook
<lordcirth>
pinebook-pro
<lordcirth>
If I'd just turned down the number of build cores, it would have used the fast cores first. So I shut off core 5 completely
<srk>
is it actively cooled?
<lordcirth>
Nope, basically no cooling
<srk>
weird
<srk>
btw looks like MNT Reform is going to have crowdfunding campaing soon-ish (~2week estimate)
<srk>
lordcirth: some of these overpowered mobile cpus are hard to cool down even actively, commonly they use pretty big metal plates in tablets to spread the heat
<srk>
but if you just put a heatsink directly on a chip it's not enough even with fan :D
<samueldr>
thefloweringash: since it's a nexus pretty sure you have UART in headphone jack
<samueldr>
the circuit is rather trivial
<samueldr>
as for your issue, maybe patch the DTB so you can have a "panic" LED, just in case
<samueldr>
when the device panics, such a configured LED will flash
<samueldr>
though I'm pretty sure it's a dumb thing with console binding
<samueldr>
if you have a way to plug in a usb keyboard (e.g. USB A to micro B) you could try blindly typing a command
<samueldr>
echo 1 | sudo tee /sys/class/vtconsole/vtcon*/bind
<samueldr>
I'm not positive the console is or isn't active in that case
<samueldr>
and if it's active it's not that great :/
<samueldr>
(remember the time android had a root shell running in the background?)
<srk>
what would be the best phone for mobile nixos?
<samueldr>
a quick way to know if the console works would be to send a `reboot` command
<samueldr>
maybe sudo reboot
<samueldr>
trivial enough to type without typos
<samueldr>
srk: in order, one your already own, none for the moment, the pinephone, maybe any of those listed and aarch64 (except motorola-addison), otherwise something with some developer community behind to confirm others have booted custom stuff
<samueldr>
the pinephone is a bit underpowered though, but is likely to be one that will work with most configurations as it's mainline-based and made for non-android linux
<samueldr>
the librem 5 *could* be an option, I don't have one, neither is it planned _for me_ currently to add support
<samueldr>
though it's likely to use a similar configuration than the pinephone for booting, so should be rather trivial to get going
<srk>
I have iphone se something :( would still use my old sony erricson but got this as a gift
<samueldr>
(not sure about comms though after)
<samueldr>
ah
<srk>
but I would like to switch to something OSHW at some point
<srk>
(or roll my own :D)
<samueldr>
"one you own" also assumed "one that has not been artificially limited in the name of pretense of security"
<srk>
yeah, guessed so :)
<samueldr>
*if* I had to recommend one, probably oneplus 3, simply because they can be gotten quite cheaply, and yet untested, it's likely they are trivial to recover from a brick
<samueldr>
(bricking is unlikely unless you want to go further than the designs allow)
<srk>
pinephone looks pretty cool tho
<samueldr>
so with the oneplus3 you could have fun playing with the partition layout and likely know you can recover
<samueldr>
(I'll be testing that in fact some time in the future)
<samueldr>
the pinephone is pretty cool
<srk>
I see, I guess the price point won't be that high compared to new pinephone as well
<samueldr>
look on ebay or czech your local classified
<srk>
so I might look for something older.. just because of mobile-nixos because I can't use android :D
<samueldr>
(pun intended!)
<srk>
;)
<samueldr>
but make sure it has an aarch64 SoC **and** the android system is "arm64"
<samueldr>
e.g. the motorola-addison has an aarch64 SoC, but an "arm" (armv7l) kernel/userland on android
<srk>
interesting
<samueldr>
so it's unclear what happens for those with regards to running proprietary things
<samueldr>
AFAIK samsung may have done that for a while in their more inexpensive ranges
<samueldr>
and I know LG has been doing it for a while
<srk>
like even pinephone probably has some proprietary parts, right?
* srk
not aware of basebands w/o blobs
<samueldr>
yes, though it is something I quite like: it's all laid out in front of you and pointed out
<srk>
I see, will read about it a bit more
<samueldr>
compared to the sleaziness I feel from another "libre" phone that is apparently "RYF" but where they are hiding many blobs
<samueldr>
apparently it's okay to ship with a binary blob if you completely hide it from the users
<samueldr>
which is bonkers
<srk>
...
<samueldr>
I would be fine with a "this has a blob, look at it, here it is, here's how it's being loaded, here's how you can change it so it may be liberated at some point"
<samueldr>
not a "shhh, we are using another CPU in the phone to bootstrap the RAM so the main one will never have seen the blob... by the way you can't use that CPU since we've soiled it with the blob, toodls"
<samueldr>
toodles*
<samueldr>
srk: IIRC it's the same exact SoC as that "libre" phone
<srk>
oO
<samueldr>
hm?
<samueldr>
yep, i.MX8M
<srk>
not sure if that imx8 som needs blobs
<samueldr>
yes transitively due to the RAM
<samueldr>
it's the RAM training
<srk>
right, he mentions that
<samueldr>
(I could be wrong, maybe it's possible to use it with some kind of ram that doesn't need training?)
<samueldr>
but if it's with DDR4 it's gonna need it
<srk>
not my area of expertise :) hope it can be reversed and reflashed at some point
<samueldr>
I hope so, too
<samueldr>
which is the issue with that "libre" phone
<samueldr>
if/when it is, you won't be able to fix it!
<srk>
yeah, I guess such phones are not that easy to disassemble and tinker with
<samueldr>
the pinephone is relatively easy to disassemble
<samueldr>
but there's no clear "hack/mod me here" part of the board
<samueldr>
though they do have a pogo pin interface for misc. uses
<srk>
nice
nschoe has quit [Ping timeout: 265 seconds]
qyliss has quit [Quit: bye]
qyliss has joined #nixos-aarch64
nschoe has joined #nixos-aarch64
Darkmatter66 has quit [Ping timeout: 240 seconds]
Darkmatter66 has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]