zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
grw has quit [*.net *.split]
samueldr has quit [*.net *.split]
Aleksejs has quit [*.net *.split]
Aleksejs has joined #nixos-aarch64
samueldr has joined #nixos-aarch64
grw has joined #nixos-aarch64
grw has quit [*.net *.split]
samueldr has quit [*.net *.split]
Aleksejs has quit [*.net *.split]
Aleksejs has joined #nixos-aarch64
samueldr has joined #nixos-aarch64
grw has joined #nixos-aarch64
ryantrinkle has quit [Ping timeout: 276 seconds]
orivej has joined #nixos-aarch64
ryantrinkle has joined #nixos-aarch64
<betaboon>
samueldr: yeah i did. and i was thinking of using nix-shell as shebang xD but then i thought "hm maybe allow non nix users to use it as well XD
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
I think that device exhibits the minimum requirements for boot partition; an older device that's not even aarch64 also has a 16MiB boot partition
<samueldr>
so I think that's how much space a bootloader that kexecs needs to fit in
<samueldr>
here this is a configuration that, last verified in september, built with actual cross-compilation an sd image
<ornxka>
ooh
<samueldr>
it disables a few options that have issues with cross-compilation
<samueldr>
there were new regressions in nixpkgs last month though
<samueldr>
(IIRC all are have PR opened to fix)
<samueldr>
though, using cross-compilation have drawbacks, where when/if you nixos-rebuild, the rebuild would be a native build, and you'd have no actual cache for those builds
<ornxka>
hm
<samueldr>
as the build "system" (as in x86_64-linux) changes, the builds are different due to the nature of now nix works
<samueldr>
of how nix works*
<ornxka>
i was thinking of setting up remote build after i had set up the image, and have it so that when i do eg nix-env blahblah on the arm system, it would cross-compile the package on the remote x86 system
<ornxka>
is that possible?
<clever>
samueldr: but if you set configuration.nix to want a cross-compile, via nixpkgs.crossSystem and nixpkgs.localSystem, it will farm the build out to an x86 machine
<clever>
and reuse the cross-compiled products
<samueldr>
clever: that's ornxka that wants to know that :)
<samueldr>
an yeah, I thought there was a way, but wasn't sure
<samueldr>
ornxka: is your target aarch64? if so, nixpkgs has a pretty well furnished cache
<samueldr>
it would be working against the current for the standard use case to go with cross-compilation
<ornxka>
its armv7 unfortunately
<samueldr>
aw, I was checking, just in case
orivej has quit [Ping timeout: 240 seconds]
<clever>
samueldr: dangit, lol
<clever>
i trimmed my nails, and now i cant get the SD card out of an rpi3!
<samueldr>
see? now you're forced to impleement an SD out of an FPGA
<clever>
[ 0.000000] paging_init 1
<clever>
[ 0.000000] paging_init 2
<clever>
1628 pr_info("paging_init 2\n");
<clever>
1630 pr_info("paging_init 3\n");
<clever>
1629 ->>>>>>>map_lowmem();
<clever>
ok, so its hanging here
<samueldr>
aarch64?
<clever>
arm32 on rpi3
<samueldr>
right, wasn't sure if it was 32 or 64 bit
<clever>
its either locking up solid, or its unmapping the uart from its own address space
<samueldr>
since IIRC aarch64 makes it harder by needing a trustzone implementation
<clever>
i believe i figured out how to unlock aarch64 on the rpi3 open firmware
<clever>
there was a #define nearby, to unlock it
<clever>
which failed, because i was testing on an rpi2, lol
<clever>
the rpi2 has a better uSD slot
<clever>
arm32 and arm64 have entirely different ISA's
<clever>
so the chainloader silently failing, indicates that it was expecting arm64 opcodes
<clever>
[ 0.000000] for_each_memblock (ptrval) to (ptrval)
<clever>
%p failed, and it crashed on the first iteration of the loop
<samueldr>
clever: not sure if you've seen my notes about the minimal requirements for a "tertiary" bootloader using linux on android devices
<samueldr>
but it's not going to be especially fun
<clever>
?
<samueldr>
16MiB to fit initrd + kernel(+dtb)
<clever>
have you seen how small haskell-init was?
<samueldr>
yeah, but it has to be useful in the end :)
<samueldr>
I have to make some userspace optimisations next I believe
<samueldr>
since systemd-udevd brings in a bunch of bytes
<clever>
do you have working framebuffer?
<samueldr>
yes
<samueldr>
and it's among the "bloated" kernel built-ins
<samueldr>
QUALCOMM!!!!!!!
<clever>
whats the touchscreen and button input methods?
<samueldr>
they're espeically good at making sure their kernels can't build with options toggeled off
<clever>
/dev/event ?
<samueldr>
clever: probably both working
<samueldr>
touchscreen works in x11
<samueldr>
using libinput iirc
<samueldr>
so that's like all standard stuff
<samueldr>
the main issue will be userspace implementation of a GUI in <8MiB
<clever>
yeah
<samueldr>
which *is* possible, after all, TWRP does it
<samueldr>
qualcomm's drivers are full of unverified dependencies to other modules where irrelevant :(
<clever>
||| 1470 pr_info("c.3\n");
<clever>
||| 1471 ->>>>>>>->>>>>>>->>>>>>>/* This better cover the entire kernel */
<clever>
this is where it fails, lol
<clever>
[ 0.000000] for_each_memblock 1000 to 30000000
<clever>
i think its mapping that whole range...
<clever>
from 4kb to 768mb
<clever>
the kernel is definitely in there
<clever>
BCM2708ArmControl::start(): mapped peripherals VC 0x7E000000 to ARM 0x3F000000
<clever>
but the uart start saround 1008mb
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<clever>
ok, thats a problem
<clever>
it was remapping ram before io, and cutting itself off, so i couldnt see any more debug
<clever>
so i modified it to print all mappings, before applying any
<clever>
its only mapping io, and nothing else
<clever>
only mapping ram*
<clever>
i think i need more DT entries, to map gpio
ryantrinkle has quit [Ping timeout: 245 seconds]
<clever>
| 755 pr_info("foo\n");
<clever>
| 757 pr_info("done\n");
<clever>
| 756 ->>>>>>>BUG_ON(pmd_bad(*pmd));
<clever>
[ 0.000000] foo
<clever>
samueldr: ok, that is not where i expected an error.....
<samueldr>
in the README?
<clever>
samueldr: BUG_ON is just halting
<samueldr>
maybe BUG_OFF is an appropriate response?