Yannik_Sc has quit [Quit: Yannik_Sc]
* gchristensen accidentally got a second rpi 3b+
<samueldr> accidentally&
<samueldr> ?*
<clever> same way i accidentally ported an entire kernel to the rpi, lol
<samueldr> I accidentally got nixos running on my phone
<gchristensen> lol
<gchristensen> probably similar kinds of accidents
<gchristensen> I can't find my serial adapter :/
<clever> i have little-kernel booting on all rpi boards i own
<clever> for the rpi 1/2, i only confirmed uart and OTP access
<clever> the rpi3, i confirmed it can bring dram online
<clever> rpi4, dram is already online, so its mostly just been a playground for timers/uart
<gchristensen> the local Target carrying the Canakit has caused my ownership of rpis to go _/
<clever> lol
<samueldr> and here, in the canacountry you can't buy one in a shop
<clever> ive had to order all of mine online
<clever> you cant even find a micro-hdmi cable in a shop
<gchristensen> I'm impressed I still can, samueldr
<gchristensen> I was expecting them to be removed from shelves after Christmas
<gchristensen> hrm.
<gchristensen> my disorganized lifestyle is /very/ painful in times like this.
<clever> same, i had a micro hdmi cable, for my kindle fire
<clever> but now that i need it, its missing
<samueldr> I had one for the odroid-c1
<clever> it took me 2 weeks to just find some uSD cards, lol
<samueldr> but it doesn't work with the pi 4!
<gchristensen> ow, samueldr
<gchristensen> btw what is the chip on the rpi with the rpi logo on it? it is cute
<clever> samueldr: one gotcha with the rpi4, is that it only outputs on one hdmi by default i think
<samueldr> gchristensen: it's not a chip, it's an RF shield
<gchristensen> ah
<clever> it covers the wifi and bluetooth chips
<clever> they dont want the 2.4ghz leaking out
<gchristensen> ah!
<clever> but they are fine with 2.4ghz leaking out of the hdmi pins and jamming the wifi anyways :P
<gchristensen> it is a fairly competent computer (kit) for $70, I can't blame them too much
<clever> the pixel clock for 2560x1440@60hz, is right smack at 2.415ghz
<gchristensen> niiice
<gchristensen> I love Hector's account. so much good stuff.
<clever> so the hdmi will jam the wifi
<clever> my next plans for the rpi stuff, is to get the PLL and power domain control implemented in little-kernel
<clever> then i move on to sdhost, so i can load blobs from the SD card
<clever> then i can boot up the arm cpu, and have a proper kernel on both sides
<gchristensen> the canakit is so well done
<clever> what does it include?
<samueldr> the canakit kit for the pi 4 has stinky power leads though
<gchristensen> the card that shows the gpio pinout is great; the included PiSwitch is REALLY great
<gchristensen> including a power supply is such an obviously critical thing since that trips me up nearly everytime
Ox4A6F has joined #nixos-aarch64
<Ox4A6F> SD cards and Raspberry Pi. I've recently started using zfs on my rpi4.
<clever> i just printed out the gpio years ago, and never updated it
<clever> its still the rpi1 era pinout, lol
<samueldr> SD cards on the Pi are only good to load tianocore to then boot of a USB hard drive / SSD
<samueldr> :3
<clever> gchristensen: what does the PiSwitch do?
<samueldr> it's a switch
<samueldr> to switch your pi
<clever> switch it on?
<clever> switch the sd host?
<samueldr> power off/on
<clever> ah
<gchristensen> instead of plugging/unplugging
<clever> i see
<clever> ive been using the RUN header for similar purposes
<samueldr> the switch is in-line with their adapter
<gchristensen> nice, samueldr
<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
<gchristensen> thanks, clever!
<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> or the kernel?
<gchristensen> udev
<clever> you probably want /dev/disk/by-path
<samueldr> how is u-boot unhappy, gchristensen
<samueldr> hmm, 19.09 nixos image?
<gchristensen> nixos-sd-image-19.09.1993.d3d2de8b99b-aarch64-linux.img from https://hydra.nixos.org/build/111167113
<samueldr> not sure what was the support for the 3B+ at that point in time
<samueldr> (u-boot 2019.04 + whatever dt from the kernel)
<gchristensen> shall I try unstable?
<samueldr> two options to try, new kenel (thus different FDT) https://hydra.nixos.org/job/nixos/release-19.09/nixos.sd_image_new_kernel.aarch64-linux
<samueldr> or yeah, unstable
<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
<gchristensen> wait maybe not. I'm confused maybe.
<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
<gchristensen> thefloweringash: https://github.com/jerr0328/co2_prometheus
<gchristensen> ~$50 on ebay
<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> maybe hardware.enableRedistributableFirmware = true;
<DigitalKiwi> "what's that raspberry pi you got there for graham?" "I'm just seeing if you breathing makes me ill or merely your presence"
<gchristensen> error: unable to fork: Cannot allocate memory oops
<gchristensen> Mem: 0 0 0 0 0 0
<samueldr> that's a bit too few bits
<thefloweringash> you booted linux with 0 memory?!
<samueldr> I don't know how he would remember that
<samueldr> you know, having no memory at all
<DigitalKiwi> frog killer
<gchristensen> okay maybe it wasn't smart using zfs
<gchristensen> and the problem is I passed `-g` to `free` :)
<samueldr> ~ $ free --tebi
<samueldr> Swap: 0 0 0
<samueldr> Mem: 0 0 0 0 0 0
<samueldr> total used free shared buff/cache available
<samueldr> my new party trick!
<thefloweringash> it'll be a real party trick when free --tebi returns non-zero total
<gchristensen> I'm seeing a lot of rmdir: failed to remove '/lib': No such file or directory
<samueldr> ooh boy
<samueldr> I just tried something on a hunch
<samueldr> disabling CONFIG_PRINTK in the OEM kernel made the boots... much faster
<samueldr> let me time
<gchristensen> oh cool
<samueldr> no, not cool... really
<samueldr> ~3.3s
<samueldr> oh wow... something failed and it went to stage-2, and X11... almost instantly
<samueldr> I'm livi
<samueldr> livid*
<samueldr> hmm... 5.5s
<samueldr> might not have been as bad as I thought in the end
<samueldr> the reason it's not cool, and I'm livid, is that I think that android actually loses a bunch of time booting spewing debug log information
<samueldr> like an awful amount
<gchristensen> ooooooh ouch
<samueldr> boot to XFCE desktop from 20s to 12s, just by removing PRINTK
<samueldr> though, the silver lining is that I could make a kick-butt demo with additional optimizations
lovesegfault has quit [Quit: WeeChat 2.7]
minicom is now known as minicomocinim
minicomocinim is now known as minicom
ar has quit [Ping timeout: 252 seconds]
ar has joined #nixos-aarch64
<srk> I'm close to rpi images but for some reason make-ext4-fs fails with Resizing the filesystem on temp.img to 376405 (4k) blocks.
<srk> resize2fs: No space left on device while trying to resize temp.img
<srk> wtf
h0m1 has quit [Quit: WeeChat 2.7]
h0m1 has joined #nixos-aarch64
yvan-sraka has joined #nixos-aarch64
<srk> if I switch to resize2fs -M -P it works, returns quite different minimum size
<srk> Resizing from 471498 blocks to 314961 blocks. (~ 1230MiB)
<srk> Estimated minimum size of the filesystem: 434909
<Raito_Bezarius> srk: I think the issue is known and documented on some issue tracker
<srk> tried looking for similar message quickly but didn't find much
<srk> ah, previously there was no resize2fs but du of store paths and truncate
Yannik_Sc has joined #nixos-aarch64
yvan-sraka has quit [Quit: WeeChat 2.3]
yvan-sraka has joined #nixos-aarch64
<{^_^}> #62262 (by yegortimoshenko, 35 weeks ago, closed): lib/make-ext4: bump fudge factor to 96 MiB
<srk> I've tried with 16 * 16 fudge, didn't help :)
orivej has quit [Ping timeout: 265 seconds]
yvan-sraka has quit [Quit: WeeChat 2.3]
yvan-sraka has joined #nixos-aarch64
orivej has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
Yannik_Sc has quit [Ping timeout: 265 seconds]
<gchristensen> I can't seem to get a /dev/hidraw* device file on this pi even though when I plug the device in to my laptop, I do
<gchristensen> [62120.410605] hid-generic 0003:04D9:A052.0026: hiddev96,hidraw2: USB HID v1.10 Device [Holtek USB-zyTemp] on usb-0000:00:14.0-1/input0
<gchristensen> vs [25469.633160] hid-generic 0003:04D9:A052.0004: hiddev96: USB HID v1.10 Device [Holtek USB-zyTemp] on usb-3f980000.usb-1.1.2/input0
<sphalerite> gchristensen: `zgrep HIDRAW /proc/config.gz` on both?
<gchristensen> "not set" on the pi
<gchristensen> hm
<gchristensen> (=y on my laptop)
<sphalerite> yeah that'll probably be it then
<sphalerite> kernel rebuild time? Kernel rebuild time. :p
<srk> did like 6 of them since yesterday
<gchristensen> how strange
<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!
<{^_^}> https://github.com/NixOS/nixpkgs/pull/69057 (by volth, 19 weeks ago, merged): add config.environment.ld-linux
<srk> interesting, noticed that as well during pi boot
<srk> default /lib/ld would be nice, sometimes I only patch that one to make (java) apps work
<srk> FHS not so much
<srk> FHS is probably the loosest specification I've ever seen. everything is optional :D
<clever> fs/proc/kcore.c: proc_root_kcore = proc_create("kcore", S_IRUSR, NULL,
<clever> 32 proc-$(CONFIG_PROC_KCORE) += kcore.o
<clever> this file gave me an idea...
<clever> i could create a /dev/vccore, that generates a coredump of the VPU on the rpi
<clever> and then, if i know the symbol table, i can lookup anything i want
<clever> and just throw gdb at it
<ar> srk: POSIX? ;)
<srk> ar: same problem? :D
<srk> clever: does it come with SVD files? :))
<ar> srk: probably worse, but i've successfully wiped away traces of both specifications from memory
<srk> clever: I wrote SVD register viewer recently on top of hgdbmi http://ix.io/27z1
<clever> srk: SVD?
<srk> arm system view description (XMLs with peripherals/registers/fields)
<clever> srk: currently, its not producing any coredumps, and the cpu isnt arm based
<clever> srk: but i do have an exception handler installed, which can run more code when things go horribly wrong
<srk> cool
<srk> svd is generic, can be used to describe any device
<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
<whatisRT_> I've left everything in its default
<srk> maybe the firmware is too old
<srk> heh
<srk> 90% of all problems are power supply - swapping the official PSU with a 2A Nexus 7 seemed to solve the problem
<whatisRT_> Alright, seems like I have some stuff that I can try now, thanks!
whatisRT_ has quit [Read error: Connection reset by peer]
whatisRT_ has joined #nixos-aarch64
whatisRT_ has quit [Read error: Connection reset by peer]
whatisRT_ has joined #nixos-aarch64
t184256 has left #nixos-aarch64 [#nixos-aarch64]
t184256 has joined #nixos-aarch64
mDuff has joined #nixos-aarch64
whatisRT_ has quit [Remote host closed the connection]
mDuff has quit [Ping timeout: 260 seconds]
cptchaos83 has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
cptchaos83 has joined #nixos-aarch64
lovesegfault has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<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
<samueldr> clever: oh no
<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
<clever> Info : JTAG tap: auto0.tap tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x4)
<clever> Warn : There are no enabled taps. AUTO PROBING MIGHT NOT WORK!!
<clever> this is what ive got so far
<clever> but it turns out, openocd hasnt had a release in ages, so i have to build from master
<samueldr> oh, I thought it was a board for which you didn't boot a mainline u-boot yet
<samueldr> but rather it's breakage?
<sphalerite> yeah, it was working with 2019.07
<sphalerite> (I think it was 2019.07)
<samueldr> ah, that smells like a bisect!
<sphalerite> oh boy
<sphalerite> the really fun part is that I build the u-boot on the nanopi itself…
<samueldr> this is something that compiles a full image for an rk3399 board, so you can reduce unknowns https://github.com/samueldr/wip-roc-rk3399-pc
<sphalerite> hm maybe I'll ask #u-boot if there's anything obvious before starting to bisect
<samueldr> I would additionally pin-point the last working release
<sphalerite> well, vagrantc has already pointed out to me that I need arm-trusted-firmware 2.2
<samueldr> oh
<samueldr> that did help on the PBP and RK3399-PC
<sphalerite> wow, builtins.fetchGit is… not as fast as I hoped
<sphalerite> (doing nix-build -E 'import (builtins.fetchGit { url = /nixpkgs; rev = "a21c2fa3ea2b88e698db6fc151d9c7259ae14d96"; }) {}' -A armTrustedFirmwareRK3399 -o atf )
<samueldr> that's what I've been booting with
<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
<sphalerite> [ 0.172627] iommu: Default domain type: Translated
<sphalerite> [
<sphalerite> y
<sphalerite> oh wait, it detected a stall.
<samueldr> what are they selling?
<clever> openocd is now connected!, now to see what all the commands can do...
<sphalerite> I think it's dead
<sphalerite> the weird thing is, it doesn't get nearly as far with the other SD card
<sphalerite> welp, I guess it's no change from before for me: still power-cycling…
zarel has joined #nixos-aarch64
zarel_ has quit [Read error: Connection reset by peer]
<clever> and i now have jtag against the rpi3
<samueldr> yay!
<clever> samueldr: for some unknown reason, enabling jtag, forces the cpu into aarch64 mode
<samueldr> yay?
<clever> and due to using an arm32 boot stub, it fails, hard
<clever> 0x200 is the exception handler for invalid opcodes
<clever> 0x204 is an invalid opcode
<clever> so its stuck in an infinite loop, faulting within the fault handler
<clever> gist updated with the actual arm32 disassembly
ryantrinkle has quit [Ping timeout: 272 seconds]