<clever>
in this corner of the board, is the RUN header
<gchristensen>
the one thing I desperately wish was included was a proper serial adapter
<clever>
RUN is the main reset line for the entire SoC, it has a 3.3v pullup so the system will work normally
<gchristensen>
because even still I have a really terrible setup with wires taped together to various JST plugs I found in my toolbox
<clever>
the center pin is gnd, so if you just put a switch between RUN and GND, you can forcibly halt (or reset) the entire system
<samueldr>
clever: oof, why is the rightmost one square if GND is in the middle?
<clever>
samueldr: originally, it was just run + gnd
<clever>
samueldr: but the rpi4 added a 3rd pin
<samueldr>
I've seen that it's common practice to make pads square when it's ground as an indication
<samueldr>
ah
<gchristensen>
Ox4A6F: cool
<clever>
and to remain compatible with the existing layout of just accepting a 2 pin switch header
h0m1 has quit [Ping timeout: 265 seconds]
<gchristensen>
Ox4A6F: how is it going?
<clever>
samueldr: starting with the rpi4, under a complete shutdown (needs firmware config), the firmware will command the power regulator chips to shut off every power rail
<clever>
samueldr: once it goes down that hard, the cpu no longer has power, so twiddling the reset line wont do anything!
<gchristensen>
the one problem with the 40-pin pinout diagram is it doesn't provide an obvious way to orient the diagram to the pi
<clever>
samueldr: GLOBAL_EN is the reset line for the power regulator, and it has a 5v pullup instead, short to gnd to reset the regulator fully
<clever>
samueldr: with the right config, and an external board, you can use that as a software on/off setup
h0m1 has joined #nixos-aarch64
<clever>
it wont be as low of a draw as a PiSwitch, but it would allow for software power-down
<gchristensen>
okay, time to read the nixos docs and wiki, and pretend I have no idea how to do anything with regards to nixos & a raspberry pi
<clever>
gchristensen: mostly, just build the sd-image attr, and flash to a card
<gchristensen>
ssh I'm "pretending" I don't know anything
<gchristensen>
(good news, I barely know anything)
<samueldr>
before that last line I still didn't know if it was pretending, or pretending pretending
<gchristensen>
I've done it 2-3 times but I remember approximately 0
<Ox4A6F>
gchristensen: Fine, just not finding time to sleep. Or extend the wiki with ZFSonRPI section. :)
<gchristensen>
is there a section for that? :o
<Ox4A6F>
No, not yet.
<gchristensen>
uh oh, I don't know that I have the private SSH key for my garage door opener anymore ...
<samueldr>
hah
<gchristensen>
hrm when I open screen to this thing, it spews garbage. I'm sort of assuming it is a bad ground ...
<samueldr>
wrong TX/RX order?
<gchristensen>
swapping didn't improve the garbage :)
<gchristensen>
ah
<gchristensen>
the ground pin is not connected at all.
<gchristensen>
without any SD card at all, will it print anything over serial?
<clever>
gchristensen: which model?
<gchristensen>
3b+
<clever>
gchristensen: the mask rom on the rpi3 will never print anything on the uart, but i think it can blink an error code on the green led
<gchristensen>
okay
<clever>
nope, it cant even blink the led
<gchristensen>
I was just checking to see if my serial port was setup properly at all. since no activity is happening, I'll assume yes for now
<clever>
theres always the loopback test
<clever>
just link rx and tx together, ignore the pi!
<gchristensen>
well yeah but the shitty part that I need to test is how I connect it to the pi ;)
<clever>
one sec
<gchristensen>
Ox4A6F: how did you do the initial setup? I wouldn't mind this next Pi being ZFS :)
<clever>
gchristensen: one idea that comes to mind, is to take my zfs ami generation code, and adapt it for the rpi
<gchristensen>
hmm yeah
<samueldr>
since you have a 3B+, you could boot the sd-image from usb (just dd it to usb) and then install to SD like you would from the iso...
<samueldr>
... but this has the added complexity that you need to setup u-boot yourself
<gchristensen>
samueldr: oh that is a nice idea, oh that is a less nice idea
<clever>
gchristensen: if you apply that sed to your bootcode.bin file, it will print debug at 115200 baud on pins 14/15
<samueldr>
... but setting up u-boot could be as simple as making a first partition the same size as the first partition of the USB drive
<samueldr>
and dd'ing it
<gchristensen>
samueldr: oh that is a good idea =)
<gchristensen>
heck, `dd` the whole thing and then just fdisk
<clever>
gchristensen: that debug, only covers the bootcode.bin stage, and it will go silent once start.elf starts
<samueldr>
though you *will* need an FS that u-boot can read from as /boot/ on your drive
<gchristensen>
right
<samueldr>
(and set its boot flag on)
<clever>
gchristensen: but `enable_uart=1` in `config.txt` will enable start.elf to also print its own debug logs to the uart
<gchristensen>
I assume the sd card can be hotplugged while running
<gchristensen>
as long as it isn't booted from it
<clever>
oops, no, enable_uart=1 is for linux to use it
<samueldr>
I assume so, too
<samueldr>
never checked
<gchristensen>
well let's see :)
<clever>
samueldr: the mask rom doesnt care about the boot flag
<samueldr>
as I previously said, I rather not use the SD card when I can :D
<samueldr>
clever: u-boot does
<clever>
ahh
<gchristensen>
oh I missed that, samueldr
<clever>
the rpi3 is also able to load bootcode.bin + start.elf from usb mass-storage, once you burn a fuse in OTP
<clever>
so you can entirely do away with the SD card
<samueldr>
gchristensen: it's a different knid of setup, but basically I use a small broken SD card where I can reliably make a small FAT32 partition to install tianocor
<samueldr>
e
<samueldr>
then I just EFI boot via USB
<gchristensen>
oh wow!
<gchristensen>
nice :D
<samueldr>
clever: 3B+ doesn't need to burn a fuse
<gchristensen>
"Note: I (kalbasit) had to replace console=ttyS0,115200n8 console=ttyAMA0,115200n8 console=tty0 with console=ttyS1,115200n8 in /boot/extlinux/extlinux.conf to make the serial console work on my Rasberry-Pi 3. " I don't know if this is still true (about to find out) but it would be nice if this wasn't true
<Ox4A6F>
gchristensen: Booted sdimage and then plugged in an externe SD card reader and installed it on another card. Kinda lame.
<clever>
gchristensen: `uart_2ndstage=1` in `config.txt` is the one to make start.elf log to uart
<gchristensen>
Ox4A6F: easy and direct enough! :)
<samueldr>
Ox4A6F: entirely cromulent
<samueldr>
I wouldn't fault anyone installing it that way
<clever>
Ox4A6F: yeah, thats the 2nd way i was thinking of, just do a regular nixos-install
<samueldr>
that's basically what I described, but in the reverse, since 3B+ can boot via USB you can install to sd directly
<gchristensen>
laptops moving to nvme makes dd commands even more terrrifying to me (`of=/dev/sda`? wtf am I doing??)
<clever>
gchristensen: heh, yeah
<samueldr>
never ended up looking up how to make udev rename all external storage in a useful manner
<samueldr>
but *possibly* still requiring "new_kernel"
<gchristensen>
how about I do unstable, new kernel
<gchristensen>
that seems most likely to just work
<samueldr>
yep
<gchristensen>
hm instructions don't account for bz2
<samueldr>
right
<gchristensen>
okay rpi hacking will be nicer with a bourbon in hand, so back in a minute :)
<gchristensen>
okay yeah that note about the console stuff is still correct
<gchristensen>
okay this is surprising
<samueldr>
we have a bit issue with console
<gchristensen>
simply adding console=ttyS1,115200n8 to the list seemed to solve it?
<samueldr>
we don't have multiplexing
<gchristensen>
ah
<samueldr>
so we can't really have a working universal boot image :/
<gchristensen>
ow
<samueldr>
only the last one will work appropriately for all messages
<gchristensen>
ack
<samueldr>
I should really port the mobile nixos bootlogd to nixos
<samueldr>
once I solved a last issue with its use
<gchristensen>
samueldr: okay so /dev/mmcblk0p1 is u-boot and mandatory, /dev/mmcblk0p2 should probably be ext4 or something mounted at /boot, and mmcblk0p3 could be zfs /?
<samueldr>
something like that sounds right
<samueldr>
u-boot itself is not mandatory, but what is is a FAT32 partition with the raspberry pi firmware, and something it can boot, like a linux kernel or u-boot
<gchristensen>
right
<gchristensen>
I'll just not touch p1 :P
<samueldr>
here we're treating that partition as an opaque blob as it's how it is for other SBCs
<clever>
something id like, is the ability to just `nix-build` the entire VPU firmware
<clever>
obviously, you loose some rollback ability, but it would let you configure VPU offload routines, from configuration.nix
<gchristensen>
wat ...
<clever>
you want a dedicated FFT helper in the VPU?, enable it, nixos-rebuild, reboot
<gchristensen>
I dd'd this .img to my sdcard, but partition 1 starts 16G in
<clever>
there is a whole 16x SIMD processor, that is just sitting idle, in every pi
<samueldr>
16G in? that's unlikely, but 16MB in yes
<gchristensen>
ah yeah misreading
<samueldr>
that's slack space for u-boot for other boards
<clever>
allwinner needs the u-boot at a fixed offset, rather then within a filesystem
<clever>
the mask rom is a lot dumber
<samueldr>
not only allwinner
<samueldr>
rockhip, and amlogic too
<samueldr>
and all three also can read other sources like an SPI flash
<gchristensen>
I don't understand what is happening
<samueldr>
what's annoying is that rockchip, and amlogic both require the program to be where the GPT would be :(
<samueldr>
allwinner kind of, but it's luckily at a location where we can poke a hole
<clever>
samueldr: the old docs for the rpi1-3, say that the mask rom can boot from SPI flash, but the specs on how are undocumented
<gchristensen>
fdisk won't let me recreate the second partition (which started as 2.1G) any larger than 7M
<samueldr>
pretty sure it's "check how the CM boards do"
<clever>
and with the rpi4, they shuffled the boot priorities around, its nothing like before
<gchristensen>
ooooh
<clever>
samueldr: the compute modules have eMMC, which is just a single-chip SD card solution
<samueldr>
hmm
<samueldr>
right
<clever>
nothing public in the rpi 1-3 line uses the SPI boot
<samueldr>
so the answer is: don't :)
<clever>
the rpi4 also added some form of signing to this area, the recovery.bin or SPI blob must be correctly signed
<clever>
or it will treat it like the file doesnt exist
<samueldr>
yeah, that's a huge bummer :(
<clever>
that at least saves me the nightmare of figuring out DDR4, lol
<gchristensen>
the 16M beginning unused means fdisk really wanst to put partitions there
<clever>
but blocks any ability to develop my own usb boot
<samueldr>
gchristensen: I usually use cfdisk as a TUI tool, I never liked fdisk
<samueldr>
and I feel some, if not most, fdisk recommendations are actually harmful
<gchristensen>
heh
<clever>
ive always used fdisk
<samueldr>
you want to script? use sfdisk, you want to manipulate the partitions? use cfdisk
<Ox4A6F>
Should finally get some sleep, signing off.
<gchristensen>
see you Ox4A6F
<clever>
the only scary thing in fdisk, is resizing a partition
<gchristensen>
okay and p2 (/boot) needs to be bootable
<samueldr>
see you :)
<clever>
its delete + recreate scary :P
<samueldr>
I'm not saying most fdisk uses are harmful, the *recommendations* since users that know it will use it without asking for recommendation!
<samueldr>
though fdisk for scripting is actively dangerous as its UI is not stable, as proven in the past with the documentation issue we had
<gchristensen>
haha yes
<samueldr>
I'm thinking there is a tinge of elitism in some user's desire for fdisk
<gchristensen>
in my case I'm going to claim ignorance
<samueldr>
some gatekeeping like "you can't use fdisk? how will you be able to use the whole *Linux distro? go away and install noobuntu" or a similar color that I have observed
<clever>
lol
<samueldr>
pro-tip: I don't know how to use fdisk
<gchristensen>
me either apaprently
orivej has joined #nixos-aarch64
<gchristensen>
huh I don't seem to have a /etc/nixos/configuration.nix
<gchristensen>
maybe that is not surprising
<clever>
gchristensen: that trips up a lot of people, nixos-generate-config to fill things in
<clever>
id say its a bug, and the image should include a starter config, that basically makes nixos-rebuild a no-op
<gchristensen>
hmm
<gchristensen>
woot running nixos-install
<gchristensen>
woo
<gchristensen>
this might work
<gchristensen>
rmdir: failed to remove '/lib': No such file or directory
<gchristensen>
lol..?
<thefloweringash>
do you have a plan for this rpi?
<gchristensen>
yeah, I'm going to slap a co2 meter on to it and stick it in to a meeting pod at my coworking space and track it to see if that is why I feel so sick at the end of the day
<clever>
samueldr: it looks like the rpi 1-3, also have signature checking support, but its just disabled by default, and there is no way to turn it off once enabled
<samueldr>
fun!
<thefloweringash>
that's a neat application, where did you get the co2 meter? I could always use more sensors
<clever>
finding threads that explain a lot of the bits that the official docs dont
<clever>
basically, boot modes that require modifying the board to make use of
<clever>
or that software is missing for
<gchristensen>
thefloweringash: ebay :) it is from co2meter.com, "Mini CO2 Monitor" ZGm053KA
<clever>
it looks like somebody was able to load bootcode.bin from SPI flash, before the rpi4
<clever>
but the stock bootcode.bin just continues as normal, and assumes start.elf is on the SD card
<clever>
samueldr: there is also a OTP flag to allow SD card booting, i could see that being used in proper embeded situations, to just not even have that gaping backdoor open
<gchristensen>
hmmm
<gchristensen>
the hardware-configuration.nix didn't come out isn't correct
* gchristensen
is tirned
<gchristensen>
using the newest kernel didn't put most of the needed bcmxxxx modules in to kernelModules, and wifi ends up broken
<gchristensen>
:/ I can't get wlan0 to exist in the new install
<gchristensen>
why is it y on one system and unset on the other, and also have no matches in nixpkgs
<sphalerite>
different defaults per platform I guess
<gchristensen>
bummer
<gchristensen>
honestly not sure I can compile it on this thing
<srk>
you can cross compile
<srk>
finally \o/ Linux nixos 5.5.0 #1-NixOS SMP Mon Jan 27 00:23:03 UTC 2020 armv7l GNU/Linux
<srk>
previously used bcm2835_defconfig just to realize it's only pi3
<srk>
cannot access '/sys/class/gpio': No such file or directory
<srk>
oO
<srk>
was it removed already?
<srk>
funny it has zfs
<srk>
yeah # CONFIG_GPIO_SYSFS is not set
<gchristensen>
I wonder if we should just enable HIDRAW on all platforms for nixos
<gchristensen>
or turn off all remote-build support and only nix-copy-closure --use-substitutes for DRV copying
<gchristensen>
to the aarch64 community box so you can trust it better
<thefloweringash>
`rmdir: failed to remove '/lib'`: -- just saw this on nixos-unstable x86_64, apparently it's #69057 for creating /lib/ld-linux.so.2, which if disabled, calls `rmdir /lib || true`. It's since been amended with `--ignore-fail-on-non-empty` and reverted!
<clever>
srk: this block of code will dump all register state and hang, when any fatal error occurs
<clever>
my plan, is to generate a coredump here, and blast it out the uart
<clever>
then i can receive it on the other end, and open it in gdb
<srk>
handy
<clever>
except, i dont yet have a way to cross-compile gdb
<srk>
for arm?
<clever>
srk: for vc4
yvan-sraka has quit [Quit: WeeChat 2.3]
<clever>
srk: i need a gdb that runs on x86, but targets vc4
<clever>
this is where cross-compile gets complex
<clever>
the gdb i need, will be compiled by x86, and run on x86, but debug vc4 binaries
<srk>
ooh, I see
<srk>
didn't know it supports vc4
<clever>
but in future, i may want to compile on x86, run on arm, and debug vc4
<clever>
srk: i also dont know if gdb supports vc4! lol
<clever>
but i have a working binutils and gcc for vc4...
<srk>
cool
yvan-sraka has joined #nixos-aarch64
<clever>
Ericson2314: in theory, i could generate a /dev/vccore file, that works the same way as /dev/kcore
<clever>
Ericson2314: and then gdb on the arm cpu, could get a virtual coredump of the vc4, at runtime
yvan-sraka has quit [Client Quit]
yvan-sraka has joined #nixos-aarch64
yvan-sraka has quit [Client Quit]
yvan-sraka has joined #nixos-aarch64
<Ericson2314>
clever: that would be neat!
<clever>
Ericson2314: i recently discovered that the `vcdbg` program the rpi foundation ships, does exactly that
<clever>
but its closed-source
yvan-sraka has quit [Client Quit]
<Ericson2314>
clever: wow that's dissapointing
<Ericson2314>
why?!
<clever>
Ericson2314: it knows the memory layout and symbols for the closed-source firmware
<clever>
Ericson2314: it might even share header files with the firmware
<clever>
Ericson2314: but all its doing is mmap'ing /dev/vc-mem, which is a dev node to bypass the new security limits on /dev/mem
<clever>
so it can directly access the gpu area of ram
yvan-sraka has joined #nixos-aarch64
<clever>
i can create my own dev node, that wraps it with a coredump header, so you can just run gdb on it, same as /dev/kcore
<clever>
and then the .elf file explains everything in its debug info, as normal
yvan-sraka has quit [Client Quit]
yvan-sraka has joined #nixos-aarch64
whatisRT_ has joined #nixos-aarch64
yvan-sraka has quit [Client Quit]
yvan-sraka has joined #nixos-aarch64
<whatisRT_>
I'm trying to setup a headless rpi 3, but I'm running into an issue where uboot only boots if I connect a monitor via HDMI. I've found nothing on the internet about that and I've tried many different configurations. Is there someone here who might know something about this?
<srk>
do you have console?
<whatisRT_>
no
<srk>
usb->uart converter?
<whatisRT_>
also no, no special hardware
<srk>
how do you check if it boots? ping?
<whatisRT_>
yeah, that and ssh
<srk>
you might try modprobe.blacklist=vc4
<srk>
but it's hard to debug this without console
yvan-sraka has quit [Quit: WeeChat 2.3]
<srk>
maybe it's some option in config.txt, do you use defaults?
yvan-sraka has joined #nixos-aarch64
<whatisRT_>
Yeah, I tried basically every config I could find at this point
<whatisRT_>
I also tried nixos-generate-config with minimal changes
<whatisRT_>
Where would I put the blacklist option?
<srk>
kernel command line
<srk>
e.g. boot.kernelParams = ["console=ttyAMA0,115200n8" "modprobe.blacklist=vc4,pps_ldisc" ];
<whatisRT_>
I can try, but it really seems to be a pre boot issue
<whatisRT_>
When I connect the monitor, I can see uboot asking me about which kernel to choose and start the countdown
<srk>
ah, then config.txt is the only option I guess
<whatisRT_>
Where do I find it on nixos? It doesn't seem to be in /boot
<srk>
first partition
<whatisRT_>
alright, found it
yvan-sraka has quit [Quit: WeeChat 2.3]
yvan-sraka has joined #nixos-aarch64
<whatisRT_>
After looking around a bit, I don't see anything suspicious there
<sphalerite>
anyone know how I can get u-boot to chainload another u-boot image (.itb) from an ext4 filesystem on an SD card? I think I've almost got it — load mmc 1:1 $someaddress u-boot.itb — but I don't know which address to use :/
<samueldr>
is u-boot relocatable?
<samueldr>
is what I said even making sense%?
<samueldr>
include/configs/rk3399_common.h
<samueldr>
my partial knowledge, sphalerite, makes me think those configs are relevant
<sphalerite>
aah
<sphalerite>
(I like how you already know I'm fiddling with rk3399 x) )
<samueldr>
well
<samueldr>
you have a type
<samueldr>
:3
<samueldr>
I'm pretty sure it's your gru-adventures
<sphalerite>
hm but if it does need to be loaded at the same address every time, then it can't chainload itself I guess…
<samueldr>
I'm not sure
<sphalerite>
no it's not actually, ha, this is my nanopi m4-based backup server
<samueldr>
that was the other option lol
<sphalerite>
the self-hacked version of the helios64 x)
<sphalerite>
though I would have gone straight for the helios64 if it had existed when I was putting this thing together
<samueldr>
sphalerite: wondering if you could copy u-boot to location $alternative, run a command who's job is only to copy that $alternative location back to $original, then jump to it?
<sphalerite>
hm, maybe
<samueldr>
probably not a command, but jump to a small program
<sphalerite>
in any case, loading to $pxefile_addr_r then go $pxefile_addr_r didn't work
<samueldr>
probably because it's not the same addresses
<sphalerite>
yep
<samueldr>
but if you tweaked those addresses for $pxefile it would work I hope
<samueldr>
otherwise my partial knowledge is wrong
<samueldr>
btw, if I had to investigate writing a "jumpable" program to do that I think I would look at the u-boot SPL code
<samueldr>
since AFAIUI you could instrument it with console writes and such
<sphalerite>
yeeeeah well that's not my end goal, I just want to get the newer version of u-boot working tbh x)
<samueldr>
meanwhile if you made your own implementation it would likely require work to print to the console
<samueldr>
what doesn't right now?
<clever>
samueldr: i'm now playing with arm jtag, and cross-wiring 2 pi's
<clever>
the rpi4 in the black heatsink case, is running openocd, and bit-banging jtag over the gpio
<clever>
the rpi3 is then configured to route jtag to the right pins, and is running the open firmware
<samueldr>
that sounds fun :)
<sphalerite>
samueldr: I'm not 100% sure of everything that's happening — but after the SPL says "Trying to boot from MMC1" there's no more output on the serial console
<sphalerite>
it does spin up the HDDs though…
<samueldr>
I figure that's with master or 2020.01, right?
<samueldr>
do you know if the device tree has been synced with mainline recently?
<sphalerite>
yep 2020.01
<sphalerite>
nope
<samueldr>
is it *supposed* to boot?
<samueldr>
nope not synced or nope don't know?
<sphalerite>
I don't know
<samueldr>
right
<sphalerite>
I think it's supposed to boot? I didn't change anything in how I built it from the previous version
<sphalerite>
but maybe this is also more of an issue for #u-boot
<sphalerite>
I figured I'd go with 2.2 since that's what vagrantc said and since it's what's in nixpkgs :p
<samueldr>
sure :)
<sphalerite>
(current unstable at least)
<samueldr>
just saying that's something that worked for me on another rk3399 board
<sphalerite>
GIT FASTER
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sphalerite>
ooh, does it go via ~/.cache/nix/gitv2 when fetching from local as well..?
<samueldr>
oh good, I forgot to close a bunch of tabs when I finally finished setting up the GUI for the bootloady thing
<samueldr>
feels so good closing all those now-irrelevant tabs
<sphalerite>
wtf? fatal: not a tree object: a21c2fa3ea2b88e698db6fc151d9c7259ae14d96
<sphalerite>
YAY
<sphalerite>
not only does u-boot seem to work, it even seems to be capable of rebooting
<samueldr>
great
<sphalerite>
which is the main reason I wanted to update u-boot, to see if rebooting works now
<samueldr>
on the PBP, rebooting "doesn't reboot enough" for some use cases, the main one being the touchpad/keyboard firmware
<samueldr>
the power is not cut at all
<sphalerite>
ah
<samueldr>
pretty sure that won't affect you
<samueldr>
but something to kno
<samueldr>
know*
<sphalerite>
I think it was a similar problem but with the SD card for my nanopi
<sphalerite>
but I guess that could also be handled on the linux side
<sphalerite>
how can I justify getting a pinebook pro for myself? x)
<sphalerite>
aww, reboot didn't work this time
<samueldr>
sphalerite: Select All -> click on the justify icon in your editor
<sphalerite>
huh, so why did it reboot successfully that one time :/
<samueldr>
I may have been using not-2.2 for reboot to work
<samueldr>
not entirely positive
<sphalerite>
reboot worked once with 2.2
<samueldr>
the pinebook pro could be justified as making a statement
<samueldr>
this is what you want to see, pragmatic and accessible open-enough platforms?
<sphalerite>
but I already have an rk3399 laptop!
<samueldr>
though it's not built with the same spiriti in mind
<sphalerite>
I'd argue it is to some extent
<samueldr>
the chromebooks RK3399 are RK3399 because they varied their vendors
<samueldr>
just like there are mediatek, intel and AMD chromeos devices
<samueldr>
but it's not being built *for* openness, per se, even though the chrome hardware team do follow that ethos
<sphalerite>
sure, but a fairly common theme across chromebooks is that they have a strong security model while at the same time allowing users to take control of it
<samueldr>
yes, that's why it's hard to define it differently :)
<sphalerite>
anyway
<samueldr>
though I'm 99% sure the main reason is to show vendors: look, I don't *need* you
<samueldr>
they're not tied to either of [intel, amd, mediatek, rockchip]
<sphalerite>
I would like to have a pinebook pro to test it as a daily driver, see how well I can cope with fairly little computing power on my laptop
<samueldr>
can't you already do this with your gru-bob :)
<sphalerite>
and what's nice about the pinebook pro in comparison to the bob in that respect is that it has significantly more pixels
<sphalerite>
and a bigger keyboard
<samueldr>
see, that's a justification!
<samueldr>
also note you can enter my cool club of pinebook-toting nice people
<sphalerite>
lol
<sphalerite>
but I also worry that it'll succumb to the same fate as the bob
<sphalerite>
i.e. project that I'm sure I'll complete one day
<samueldr>
ah
<samueldr>
I personally think the more usual RK3399 boot chain of the pinebook pro may help here
<samueldr>
though, with that said, there's still no graphical init in u-boot so no boot selection still :(
<sphalerite>
oh yeah, with my coreboot-linux-kexec setup on the bob, wifi doesn't work :(
<sphalerite>
hah! I just did a successful reboot
<sphalerite>
now I don't know what to hope
<sphalerite>
it was either (A) the specific sd card or (B) the act of changing the SD card while linux was booted
<sphalerite>
oh wait, I celebrated too soon. u-boot worked, but linux isn't
<samueldr>
interesting
<sphalerite>
that is, it just stopped saying things