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>
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: 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
<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
<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]
<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>
>> 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>
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.