knerten has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 258 seconds]
sarcasticadmin has joined #nixos-aarch64
h0m1 has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-aarch64
h0m1 has joined #nixos-aarch64
rajivr has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 265 seconds]
evils has quit [Ping timeout: 240 seconds]
evils has joined #nixos-aarch64
<samueldr> banging my head against the gru-dumo problem again, and I really don't get what's up
<samueldr> beginning to wonder if google is somehow using a divergent source tree compared to what's published
<samueldr> since somehow their kernel build is able to use the mipi display properly, but I'm not able to reproduce while using their source tree
<samueldr> similar issue as when suspend/resume the display on mainline though AFAICT
<samueldr> ugh, I say that, but I just now somehow got it showing something
<samueldr> once
irminsul has joined #nixos-aarch64
<samueldr> now thinking about setting it up with chromeos again, to look at things under /sys, dmesg, and maybe the chosen FDT
zarel has joined #nixos-aarch64
{`-`}_ has joined #nixos-aarch64
tilpner_ has joined #nixos-aarch64
{`-`} has quit [Ping timeout: 240 seconds]
tilpner has quit [Remote host closed the connection]
tilpner_ is now known as tilpner
<samueldr> I basically built their prepareconfig kernel, the last time without any changes, and no cigar, once "dpms off" the panel won't turn back on again, same as with mainline
Asmadeus has quit [Ping timeout: 240 seconds]
Asmadeus has joined #nixos-aarch64
t184256 has left #nixos-aarch64 ["Error from remote client"]
t184256 has joined #nixos-aarch64
hexa- has quit [Ping timeout: 240 seconds]
hexa- has joined #nixos-aarch64
alp has joined #nixos-aarch64
alp has quit [Ping timeout: 272 seconds]
<samueldr> I guess more bisecting is in my future: doesn't even boot on 5.9, no serial output at all
<samueldr> (-rc2)
zarel has quit [Ping timeout: 240 seconds]
alp has joined #nixos-aarch64
cole-h has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
sarcasticadmin has quit [Quit: WeeChat 2.8]
sarcasticadmin has joined #nixos-aarch64
sarcasticadmin has quit [Quit: WeeChat 2.8]
sarcasticadmin has joined #nixos-aarch64
sarcasticadmin has quit [Client Quit]
alp has quit [Ping timeout: 272 seconds]
sarcasticadmin has joined #nixos-aarch64
knerten has joined #nixos-aarch64
sarcasticadmin has quit [Client Quit]
sarcasticadmin has joined #nixos-aarch64
orivej has joined #nixos-aarch64
justanotheruser has quit [Ping timeout: 240 seconds]
justanotheruser has joined #nixos-aarch64
<samueldr> now curious if 5.9-rc2 works on any other rk3399 devices (will test once my sleep cycle is done)
<clever> before: 7435 kbyte copied at a rate of 401 kbytes/second
<clever> after: 7435 kbyte copied at a rate of 1328 kbytes/second
<clever> samueldr: i noticed that the bootloader on the open firmware, compiled c++ without -O, adding -O alone (and fixing one bug) gave a major speed boost
<samueldr> nice
h0m1 has quit [Quit: WeeChat 2.9]
h0m1 has joined #nixos-aarch64
knerten1 has joined #nixos-aarch64
<Ke> samueldr: someone on #linux-rockchip is complaining about it not working
knerten has quit [Ping timeout: 240 seconds]
<samueldr> thanks for the heads-up Ke
<samueldr> now heads down on the pillow
justanotheruser has quit [Ping timeout: 264 seconds]
orivej has quit [Ping timeout: 240 seconds]
flox has joined #nixos-aarch64
<flox> Hi all. I am trying to get a package to cross-build for aarch64 but the nativeBuildInputs are missing `objdump` (or rather binutils) and just adding it will cause a exec format error. Does anyone know how to the right binutils needed for cross-building? :)=
knerten1 has quit [Ping timeout: 240 seconds]
cole-h has quit [Quit: Goodbye]
knerten has joined #nixos-aarch64
<sphalerite> flox: it's most likely already on PATH, just missing the host platform prefix
<sphalerite> flox: try using the environment variable $OBJDUMP
<sphalerite> flox: for example, for me, nix-shell '<nixpkgs>' -A pkgsCross.aarch64-multiplatform.hello --run 'echo $OBJDUMP' ⇒ aarch64-unknown-linux-gnu-objdump
<clever> sphalerite: already gave the same answer in #nixos
<clever> sphalerite: its a problem with mbuffer in nixpkgs master, already packaged but wont cross compile
<sphalerite> oh wow haha we literally used the exact same example xD
<clever> :D
<flox> support in stereo :D
<sphalerite> clever: you know things about linux on embedded devices, right? :) how realistic is the idea that I might be able to write a device tree for a wireless access point with very little prior experience with, say, 10h of effort?
<sphalerite> (technically not aarch64 but MIPS, but hey, this is the closest we have to an "embedded" channel AFAIK)
<clever> sphalerite: depends on if you have datasheets for the chip, and/or existing code
<clever> sphalerite: i'm currently trying to do something as "simple" as turning on the MMU in the arm, but i'm having to read 8000 page long pdf files (2 of them) to figure it out, lol
<flox> any advice on how to overlay mbuffer would be welcome though ;)
<sphalerite> clever: all the hardware should be supported by linux AFAIU
<sphalerite> hm, looked for a datasheet, https://openwrt.org/_media/media/tplink/atheros.ar7240.pdf the URL looked promising, the contents were severely disappointing x)
<sphalerite> flox: try using $OBJDUMP, as I mentioned in #nixos it _will_ be able to run on your build system
<clever> sphalerite: mbuffer's configure script is doing something wrong with objdump, its not clear what
<clever> sphalerite: just try `nix-build '<nixpkgs>' -A pkgsCross.aarch64-multiplatform.mbuffer` and youll see the fault
<clever> sphalerite: oh, "device tree" not "device driver", that should make things a lot simpler
<clever> sphalerite: to start with, are you able to boot linux and get a shell of some kind (uart?), what unbricking stuff is in place, to reflash it when it stops booting right?
<sphalerite> clever: yeah I saw that, it's trying to use an unprefixed objdump. The prefixed objdump should be fine
<sphalerite> clever: yeah I've got a uboot shell, I'm using that to load the kernel into memory via tftp and boot it from there without any flashing.
<clever> sphalerite: dtb as its own file, or appended to the kernel?
<sphalerite> clever: objcopy'd in, I've got the kernel recognising the dtb, it's just missing basically all its contents. https://gist.github.com/lheckemann/20a6d16c005b2c1bd10a1061355faf76 here's how boot looks so far
<clever> sphalerite: do you know what address the wifi controller is at? is it on some bus (pci, sdio) or directly in ram?
<flox> sphalerite: can you dumb that down for me? :D
<clever> flox: tell configure to run $OBJDUMP not objdump
<sphalerite> clever: it's on PCI, but for now I think getting the CPU clock right is more important ;)
<sphalerite> flox: $OBJDUMP _is_ the right objdump :)
<clever> sphalerite: is there an original os you can boot into to inspect? does that have a /proc/device-tree ?
<sphalerite> clever: there is, and it doesn't… iirc
<sphalerite> I'll double-check
<sphalerite> clever: nope, none
<clever> sphalerite: does dmesg say anything about dt?
<sphalerite> nope
<sphalerite> pretty sure the stock kernel doesn't use a device tree
<clever> ah, all platform_device based i'm guessing
<clever> the info is hard-coded into the kernel source
<sphalerite> fwiw the device is a unifi AP AC-lite
<sphalerite> I've emailed ubnt because they've "forgotten" to publish the GPL sources again :p
<clever> lol
<clever> i recently tried using a TP-link extender, and it was a royal pain :P
<clever> the unit only gets an ip if you boot it without the ethernet cable plugged in
<sphalerite> … what
<clever> you must register an acct on their website before you can even manage the unit
<sphalerite> wtf
<clever> the default access point has no password
<sphalerite> sounds like a case for disassembly.
<clever> you CANT SET A PASSWORD UNTIL ITS WORKING ON YOUR NETWORK, lol
<clever> the option to set the wifi pw just does nothing :P
<clever> the wizard to set it up, demands you connect to the existing wifi (which died a month ago)
<sphalerite> but yeah do you have any idea what to put in the device tree to get the CPU clock working?
<clever> only if you abort, and dig 2 menu's deep, can you find the access-point mode
<clever> sphalerite: do you have a cpus node in the device-tree yet?
<sphalerite> yes
<clever> what is the compatible= on that cpu node?
<sphalerite> mips,mips24Kc
<clever> [clever@amd-nixos:~/apps/rpi/linux/Documentation]$ grep -r --color mips24Kc
<clever> sphalerite: can you find docs in this dir, for that entry?
<sphalerite> nope
<clever> to the source!, `cd ..` and try the grep again
<sphalerite> in the entire linux tree all I find is 3 other DTS fragments
<sphalerite> clocks = <&pll ATH79_CLK_CPU>;
<clever> yep, so you need to look for a node with the name of pll
<sphalerite> the trouble is, I'm not sure if the pll will be in the same place in ar7240 as in ar9331
<clever> one sec
<clever> [root@rpi:~]# ls -l /sys/bus/platform/drivers/bcm2835-clk
<clever> total 0
<clever> lrwxrwxrwx 1 root root 0 Aug 29 11:05 3f101000.cprman -> ../../../../devices/platform/soc/3f101000.cprman
<clever> sphalerite: this tells you the address of an instance for a driver
<clever> lrwxrwxrwx 1 root root 0 Aug 29 11:05 /sys/bus/platform/drivers/bcm2835-clk/3f101000.cprman/of_node -> ../../../../firmware/devicetree/base/soc/cprman@7e101000
<clever> and when DT is active, where that info came from in the DT
<clever> poke around in the original kernel, and see what info leaks out of it
<sphalerite> ah wait crap I think I'm confusing SoCs here
<sphalerite> ha, yes, it's a qca9563, not an ar7240. Wrong AP :)
<clever> sphalerite: here is an example of dmesg when DT is definitely being used: https://gist.github.com/cleverca22/d5afd32b44fdb71df7008afe7a9f34a1
<sphalerite> clever: is there a kernel arg you used to make it that verbose about it?
<clever> not sure, ive turned a lot of debug things on
<sphalerite> but I am certain it's using my device tree — if I leave the "chosen" node out, it says that it's ignoring the dt because it has no /chosen node
<clever> the kernel cmdline is also part of that chosen node
<sphalerite> yeah I don't care about that much though, because I can set the cmdline from u-boot
<sphalerite> so I have an empty chosen node
<clever> uboot is probably patching the dtb for you
<clever> similar to how the code i linked is patching it
<sphalerite> I'm not sure this u-boot has device tree support
zupo has joined #nixos-aarch64
<clever> at least on arm, there is a single register that is used for either atags or dtb
<clever> so the thing launching linux has to put the right one into that register
<sphalerite> I'm embedding the device tree in the kernel image with CONFIG_MIPS_ELF_APPENDED_DTB=y
<clever> ah
<clever> 2020-08-29 07:50:58 < clever> sphalerite: dtb as its own file, or appended to the kernel?
<clever> so it is appended to the binary
<sphalerite> not appended as in cat, but yes
<clever> depending on which flag you do, the build system will either append it for you, or expect you to append it later
<clever> in that case, linux will detect it during boot, and patch the dtb itself, based on what came in via the legacy route
<sphalerite> ok I'll take two steps back and say everything I'm doing: 1. make ath79_defconfig 2. setting CONFIG_MIPS_ELF_APPENDED_DTB=y via menuconfig 3. building 4. mips-unknown-linux-musl-objcopy --update-section .appended_dtb=/scratch/aclite.dtb vmlinux 5. make uImage 6. loading and booting the uImage through uboot with tftp
<clever> ahhh, thats a bit different from the options ive seen in arm
<sphalerite> and if I leave 2 and 4 out, the kernel says "OF: fdt: No valid device tree found, continuing without"
<clever> a bit weird that it wants you to manually mutate an elf like that
<sphalerite> hence my belief that the u-boot doesn't support device trees
<clever> yeah, definitely sounds like uboot isnt passing one in
<sphalerite> well, I think it's nicer than appending it with cat :)
<clever> the dtb has a magic number at the start of it, so you can detect the cat
<sphalerite> yes, but having ELF metadata specifying it is nicer IMHO :)
<clever> arm has ARM_APPENDED_DTB: e.g. cat zImage <filename>.dtb > zImage_w_dtb
<sphalerite> yes that's also an option with mips, but I think having it in a section with the corresponding metadata is nicer.
<clever> and ARM_ATAG_DTB_COMPAT will then patch that DTB, based on the ATAGS coming in via the legacy route
<sphalerite> anyway, the dtb is loading fine and the cmdline is coming in from u-boot correctly
<clever> yeah, that is nicer, but it also makes the nix build more painful
<clever> every time you change the dtb, it has to rebuild the entire kernel
<sphalerite> not really, if you make vmlinux the output of the kernel drv, you can objcopy in the dtb and build a uImage from it in a separate drv.
<sphalerite> (also it builds sooooo much faster than any other kernels I've ever built)
<clever> ah, wasnt sure if the uImage step needed the kernel build system
quinn has quit [Quit: ZNC 1.8.1 - https://znc.in]
<sphalerite> (builds in under 5 minutes, yay for embedded systems with next to no device drivers :D )
<clever> i think youll need to find the PLL block, maybe via /sys, or maybe via decompiling the kernel in ida or ghidra
<clever> sphalerite: oh, also
<clever> [root@rpi:~]# dtc /proc/device-tree
<clever> sphalerite: if you run this, youll see the dtb linux booted with, it may differ slightly
<sphalerite> I can't do that, the stock firmware doesn't use DT as mentioned previously, while the new kernel doesn't finish booting
<clever> ah yeah
<clever> i had similar trouble with the pi
<clever> initially
<clever> pi2 would hang hard after uncompressing
<clever> pi3 would work for very very basic static stuff in the initrd, but segfault like mad for anything more complicated
<sphalerite> and the clock frequency in the boot log I'm currently getting (last message from the kernel) looks very wrong :)
<sphalerite> hm and in the stock firmware find /sys -name '*pll*' returns nothing :/
<clever> it may be named differently
<clever> clock, clk
<clever> what is the compatible= for the pll?
<sphalerite> I don't know
<sphalerite> yeah I found /sys/devices/system/clocksource/clocksource0 but it doesn't seem to be helpful
<clever> sphalerite: cat /sys/kernel/debug/clk/clk_summary ?
<clever> that looks very basic, when compared to a pi
<sphalerite> it's a more specialised device than a pi :)
<clever> sphalerite: you may be able to cheat, and just claim a fixed clockrate of 775mhz
<sphalerite> in the CPU node?
<clever> yeah
<clever> sphalerite: this says that there is a 19.2mhz clock, and its called clk_osc
<clever> and there is no way to change anything about it or turn it on/off
<clever> then you can point the cpu node towards your fixed-clock
<clever> line 166 of rpi3.dts then says that the clock management driver should should use clk_osc as an input
<clever> so when the clock driver wants to do its math, it can learn that the input was 19.2mhz
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tilpner has quit [Quit: tilpner]
tilpner has joined #nixos-aarch64
orivej has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
pinage404[m] has joined #nixos-aarch64
evils has quit [Ping timeout: 265 seconds]
justanotheruser has joined #nixos-aarch64
evils has joined #nixos-aarch64
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
julm has quit [Remote host closed the connection]
julm has joined #nixos-aarch64
WilliButz has quit [Remote host closed the connection]
WilliButz has joined #nixos-aarch64
h0m1 has quit [Quit: WeeChat 2.9]
h0m1 has joined #nixos-aarch64
justanotheruser has quit [Quit: WeeChat 2.7.1]
justanotheruser has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tilpner has quit [Ping timeout: 256 seconds]
tilpner has joined #nixos-aarch64
<pie_> does hydra do aarch builds?
<pinage404[m]> yes, it seems to do, at least aarch64
<pie_> im still yet to learn my way around hydra at all
<pie_> hm, no bot?
<pie_> issue: " Porting termux packages / reusing patches"
bennofs__ has joined #nixos-aarch64
bennofs_ has quit [Ping timeout: 240 seconds]
<samueldr> pinage404[m]: tip for the future, the matrix<->irc bridge is lossy on multi-line messages https://logs.nix.samueldr.com/nixos-aarch64/2020-08-29#3920399;
<samueldr> it's fine to have them, but you might want to start them up by sending a useful first line
<samueldr> now, to answer your question, the generic sd image
<samueldr> the best place for up-to-date info should be here: https://nixos.wiki/wiki/NixOS_on_ARM
<samueldr> now, for your particular setup
<samueldr> there's multiple avenues
<samueldr> the 3B and 3B+ can boot via USB
<samueldr> the 3B requires permanent changes (via software)
<samueldr> the 3B+ IIRC doesn't
<samueldr> it might be quite important for you to identify whether you are using a 3B or 3B+ :)
<samueldr> though usb boot is... sometimes not good
<samueldr> the drivers in the boot rom are quite limited (understandably!) so some pen drives won't work too well
<samueldr> one alternative to help is to *not* enable USB booting (for the 3B) (though it wouldn't matter)
<samueldr> and rather boot this from SD https://github.com/pftf/RPi3
<samueldr> you can use the smallest microSD card you have laying around, even
<samueldr> though, you won't be able to boot the sd image from there :/
<samueldr> (side-note while a page loads on my end) you probably will end up needing to power the hard drive via a powered usb hub
<samueldr> though I have succesfully ran a 3B (not plus) using a usb hard drive, it might have been asking for trouble
<samueldr> so yeah, if you go the UEFI way, you should be able to boot the UEFI iso, just like on bog standard computer
<samueldr> if you install via UEFI, it's just like on a standard computer
rajivr has quit [Quit: Connection closed for inactivity]
<samueldr> (except that your firmware actually lives on an sd card instead of a flash chip :))
<samueldr> if you install via SD, you can "install in place"; the default setup assumes you will edit the configuration.nix at /etc/nixos/, and reuse the parittioning as it is
cole-h has joined #nixos-aarch64
Guest21769 has quit [Remote host closed the connection]
Amanda has joined #nixos-aarch64
Amanda is now known as Guest19238
zupo has joined #nixos-aarch64
quinn has joined #nixos-aarch64
Darkmatter66_ has quit [Ping timeout: 240 seconds]
Darkmatter66 has joined #nixos-aarch64
cole-h has quit [Quit: Goodbye]
ryantrinkle has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 240 seconds]
<sphalerite> clever: cool, thanks :)
pbb has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
pbb has joined #nixos-aarch64
<colemickens> Is it worth having a unofficial hydra job for wip-pinebook-pro? It's nice to have a stock sd card image to start from, in case you don't have a local aarch64 builder, it can be a hassle to get a full sd card image.
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr> it should still all cross-compile
<colemickens> I knew that.
<colemickens> I don't know what I was thinking.
<samueldr> hah
<samueldr> I thought I was missing something
<samueldr> though I'd like it if there was more built artifacts for well-in-demand platforms like those
<samueldr> but at the same time
<samueldr> I hate that it's needed
<samueldr> I haven't tested yet, but IIRC 5.9 shouldn't need any patches to boot
<samueldr> so with 5.9 hopefully you'll be able to get yourself going with the generic image
<colemickens> yeah, after reading through the Graphics PR, I think I've come up with a strategy. Normal UEFI install to eMMC. A wip-pb-pro built uboot on the SD Card. If that goes well and I understand how to recover from bad SPI flash, I'll try moving uboot from SD to SPI.
<samueldr> sounds good
<samueldr> though IIRC grub didn't work well
<samueldr> (or at all?)
<colemickens> uboot->uefi grub you mean?
<samueldr> yes
<samueldr> there's no non-uefi grub for arm AFAIK
<samueldr> and not sure what it'll look like with systemd-boot
<samueldr> though *do* feel free to try
<colemickens> okay, I was building in some "uboot->uefi" might not work potential too. I thought someone commented that systemd-boot had worked for them. Seems ideal so worth it to me to try anyhow.
<samueldr> yeah, if you can go with uefi it's probably the best solution
<samueldr> I haven't done much with the PBP yet, since the last time, and didn't have a setup to get systemd-boot at the time
<samueldr> colemickens: SPI is empty out of the box, and you can erase it if u-boot works (and has the sf command)
<samueldr> colemickens: additionally you can force maskrom / rockusb mode with an internal button
<samueldr> which allows you to plug the type-c cable on a computer to, among other things, operate on the SPI flash using some rockchip tools
<samueldr> (open source tools)
<colemickens> is there actually a button?
<colemickens> from the wiki I thought I had to maybe short something myself (which is fine)
<samueldr> 28, reset and recovery button
<samueldr> >> The Recovery button is used to place the device in maskrom mode; this mode allows flashing eMMC using Rockchip tools (e.g. rkflashtools).
<samueldr> though it seems some users apparently have trouble with it
<samueldr> never tried it
<colemickens> oh nice, it doesn't seem mentioned here: https://wiki.pine64.org/index.php/Pinebook_Pro_SPI
<samueldr> I somehown ever screwed up SPI flash :)
<samueldr> I always installed/erase through u-boot
<samueldr> and from the same build
<samueldr> so I have a high level of confidence that u-boot will work
<colemickens> oh yes it does, wow, reading comprehension fail
<samueldr> >> The button works by shorting two pins in an SPI device
<samueldr> so yes, you short the spi device :3
<colemickens> yeah, after reading through other forum threads and all of your docs/nix I feel confident. Just wanted to be prepared, minimize future panic.
<samueldr> don't hesitate to ask me here directly
<samueldr> I hate to say that
<samueldr> but the official pine channel has many people that answer authoritatively while not being right
<samueldr> I hold in my ethics to say "I don't know" when I don't _know_
<colemickens> I appreciate it!
<samueldr> ooooh... I think I have an intuition as to why some people have issues with the maskrom button
<samueldr> it's a misnomer
<samueldr> it's a "skip spi" button
<samueldr> so if you have your eMMC with a bum u-boot, it won't go in the (fallback) maskrom rockusb mode
<colemickens> if the eMMC uboot is bad in that case, how do you zero out the emmc to recover?
<samueldr> remove the eMMC :)
<samueldr> or flip its switch off
<samueldr> ideally you'd then put it on one of the eMMC USB or SD adapters
<samueldr> but that might not be something you own
<samueldr> IIRC the switch is fine to flip once booting, but I'm not 100% sure
<colemickens> yeah I think the wiki talks about hot swapping it
<colemickens> I forgot there was a switch though, very nice.
<colemickens> I love the good vibes I get from this experience so far. Nice community on the SW side and the pine64 folks seem genuine/capable/community/hacker friendly.