<samueldr>
oh, I thought they were assembled, but I just reopened the page
<samueldr>
and no
<samueldr>
oh well
<samueldr>
(I thought it was way too cheap on a second look)
<clever>
in theory, i could design something similar, using a mux and a pico
<clever>
program the pico to manage the mux, and also act as a usb<->sd converter
<clever>
that would be simpler then the full on emulation
<clever>
but then require waiting for a reflash, and wear out the target
<samueldr>
yeah, maybe emulating SD is still a good goal (even if slow)
<clever>
in my use-case, i would use the sd emulation for the bootcode.bin/start.elf/kernel.img/initrd/config.txt files
<clever>
once those are loading, i have enough code to do netboot, so the rootfs doesnt care
<samueldr>
yep
<samueldr>
many times I want sd emulation just to test u-boot changes
<clever>
the rootfs is also changing far less often
<samueldr>
because with u-boot, many boards can boot just fine from usb or network or many other targets
<clever>
but i can see the same argument for a muxer
<clever>
mount the mux, copy those 5 files, umount
<clever>
5 files is much less wear then a re-image
<clever>
samueldr: as for my recent work, i can now boot LK on the VPU side (start.elf, relying on the closed bootcode.bin), and then an embeded LK can then boot on the ARM (both pi1 or pi2, but you must choose at build-time)
<samueldr>
cool!
<clever>
SD also works from the arm-lk side, so i can just load a kernel.img, patch a dtb, and chainload it
<clever>
i could embed u-boot instead, but that requires patching a lot of things in an unfamiliar codebase
<clever>
u-boot assumes your using the official firmware
<clever>
ive already had weird bugs from LK doing the same
<clever>
the main peripherals, are in a 16mb chunk of the physical address space, at a different address on every model
<clever>
0x20000000/0x3f000000
<clever>
is that a typo on the official docs??
<clever>
nope
justanotheruser has quit [Ping timeout: 260 seconds]
<clever>
samueldr: on the pi2 and pi3, there is ALSO a 1mb chunk of arm-local peripherals, at 0x4000_0000, so the 2 windows are back to back
<clever>
LK assumed that it was a single 17mb window, at a given base addr
<clever>
i then changed that base addr, because the hw lets you move things
* samueldr
knows some of these words
<clever>
so LK was looking for the 1mb window, at the wrong addr
<samueldr>
don't stop, it's still interesting!
<clever>
i had to fix LK, to expect 2 mmio windows
<samueldr>
mamma mio
<clever>
memory mapped IO
<samueldr>
(yeah I know, it had to vacate my mind into IRC)
<clever>
:D
<clever>
ive also run into a weird problem i cant make sense of
<clever>
the arm core wont start at all, if i enable the l1 cache on the vpu
<clever>
hexa-: ive recently re-arranged all of the code, and this repo is now able to run as one of: bootcode.bin, start.elf, recovery.bin, or start4.elf
<clever>
it has drivers for the VC4 ram, composite video, and spinning up the arm core
<clever>
and it can also run on the arm core of either a pi1 or a pi2
<clever>
and SD drivers, so it can read a card
<clever>
hexa-: it should be a relatively simple task to then add a linux bootloader to the mix, and get linux working once again
<clever>
and since discovering this, i can now wire linux into the composite video driver
<clever>
that should then give me a fully working desktop env
<hexa->
nor the video stuff :p
<hexa->
alot of this goes over my head
<clever>
hexa-: pi1 linux support is iffy, it was crashing due to weird bugs, i dont know if it was armv6 or something else, have you had to debug anything like that?
<hexa->
armv6 *shrug*
<hexa->
it had 512M of ram
<hexa->
it was rough
bpye has quit [Ping timeout: 240 seconds]
bpye has joined #nixos-aarch64
orivej has joined #nixos-aarch64
lopsided98 has quit [Ping timeout: 258 seconds]
lopsided98 has joined #nixos-aarch64
evils has quit [Ping timeout: 265 seconds]
alpernebbi has joined #nixos-aarch64
FRidh has joined #nixos-aarch64
sciamp has joined #nixos-aarch64
cole-h has quit [Ping timeout: 240 seconds]
sciamp has quit [Read error: No route to host]
sciamp has joined #nixos-aarch64
sciamp has quit [Client Quit]
sciamp has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
FRidh has quit [Read error: No route to host]
FRidh has joined #nixos-aarch64
nesnera_om[m] has left #nixos-aarch64 ["User left"]
sciamp has quit [Ping timeout: 260 seconds]
sciamp has joined #nixos-aarch64
sciamp has quit [Ping timeout: 268 seconds]
bennofs[m] has joined #nixos-aarch64
FRidh has quit [Quit: Konversation terminated!]
zupo has joined #nixos-aarch64
jumper149 has joined #nixos-aarch64
patagonicus0 has joined #nixos-aarch64
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
<ehmry>
is it just me, or is haskellPackages usually half broken on the nixos-unstable branch for aarch64?
<hexa->
ehmry: so, the haskell-updates hydra job only runs on x86_64 and none of the maintainer has any stake in aarch64 deployments
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<hexa->
so its probably hit-and-miss
<hexa->
(source: maralorn, I asked)
<ehmry>
i don't know how broken it gets, but I usually have to comment things out of systemPackages and find old packages from hydra
<gchristensen>
it seems a bit weird that haskell packages doesn't mostly just work on aarch64
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
monk has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
monk has joined #nixos-aarch64
monk has left #nixos-aarch64 ["Disconnected: Replaced by new connection"]
monk has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 268 seconds]
dev_mohe has joined #nixos-aarch64
dev_mohe has quit [Client Quit]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<samueldr>
you probably want to add the sh snippet there
<samueldr>
without the || true
<superherointj>
Thanks. Will give it a try.
<samueldr>
it's 100% a workaround, but my experience with it, and sphalerite's experience, it's solid once it's going
<samueldr>
and either it works (most of the time) or it fails, there's no in-between
<samueldr>
(in maybe 100+ boots of my tablet with the issue, it failed only once with the equivalent workaround)
<samueldr>
while beforehand it failed regularly
<colemickens>
<samueldr "the change you linked from colem"> I think my change was more about the in-place raspberry pi bootloader installer actually, rather than anything to do with the actual sd image.
<colemickens>
Maybe I've forgotten or was missing context from my nick mention, but wanted to throw it out.
<samueldr>
oh right, it still would have needed it in the sd image generation in that case
sciamp has quit [Quit: Konversation terminated!]
drag0nius has joined #nixos-aarch64
drag0nius has quit [Ping timeout: 240 seconds]
alpernebbi has quit [Quit: alpernebbi]
justanotheruser has quit [Ping timeout: 260 seconds]
globin has quit [Ping timeout: 248 seconds]
globin has joined #nixos-aarch64
jumper149 has quit [Quit: WeeChat 3.1]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
justanotheruser has joined #nixos-aarch64
<superherointj>
samueldr, the workaround you suggested seems to be working. It errors but does not block. Proceedes to NixOS Stage 2.