<clever> samueldr: oooo!
<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> samueldr: ah, how readable is this readme? https://github.com/librerpi/lk-overlay
<samueldr> seems good
<samueldr> no licensing information on the repo though :)
<clever> need to figure that out
<clever> its an overlay for LK, which is mit based
<clever> but a lot of the code is just copy/pasted from rpi-open-firmware, which is gpl based
bpye has quit [Ping timeout: 240 seconds]
bpye has joined #nixos-aarch64
superherointj has quit [Quit: Leaving]
justanotheruser has joined #nixos-aarch64
h0m2 has quit [Ping timeout: 258 seconds]
h0m2 has joined #nixos-aarch64
s1341_ has quit [Ping timeout: 250 seconds]
sorear has quit [Ping timeout: 245 seconds]
sorear has joined #nixos-aarch64
s1341_ has joined #nixos-aarch64
<hexa-> heads-up: linuxPackages_rpi went to 5.10
<hexa-> #113363
<{^_^}> https://github.com/NixOS/nixpkgs/pull/113363 (by mweinelt, 6 weeks ago, merged): raspberrypi: update kernel, firmware, eeprom and userland
<hexa-> finally got around to testing and just merged
<hexa-> 5.10.11 is a bit dated right now … but it is what it is
<clever> hexa-: have you heard of my rpi work?
<hexa-> pretty sure I have
<hexa-> i'm a bit fuzzy on the details, it was open source firmware?
<clever> yeah
<hexa-> ah librepi
<clever> yep
<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
<hexa-> how is that goingneat
<hexa-> -
<hexa-> neat
<hexa-> I'm not that deep into the boot stuff
<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…]
<ehmry> no error, stuff just stops building https://www.spam.works/uploads/aws-0.22.log
<ehmry> I don
<ehmry> 't take haskell seriously anymore
zupo has joined #nixos-aarch64
<dotlambda> Has anyone tried running NixOS on a Rock Pi 4 C or knows how it compares to the ROCKPro64?
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dotlambda has quit [Quit: ZNC 1.8.1 - https://znc.in]
dotlambda has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
zupo has joined #nixos-aarch64
evils has joined #nixos-aarch64
<samueldr> I think andi- might?
<samueldr> I don't remember which "rock" (not actually related) family he tried
sciamp has joined #nixos-aarch64
fila has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<andi-> samueldr: yeah a 4c
dustinm has quit [Quit: Leaving]
<andi-> It works even while running off an Sd card.
<samueldr> then dotlambda wonders how it compares :)
<andi-> No problems for the last 6m
<samueldr> (which you probably cannot compare)
<samueldr> andi-: mainline-based kernel, right?
<andi-> I have no clue about that ecosystem.
<andi-> It probably has different issues.
<andi-> samueldr: everything mainline
<samueldr> oh, RK3399 is so solid I assume all boards have basically the same support
<samueldr> (except if extremely new or extremely wild)
<andi-> Mainline kernel, U-Boot etc..
<samueldr> yep
<samueldr> and I say so because of my "fun" experiments with more "wild" "boards" like the pinebook pro, compared to less "wild" boards
<samueldr> RK3399 seems to be under control :)
<andi-> I've started tinkering with another libav/ffmpeg for the new v4l2 based decoder support but it works good enough already
rajivr has quit [Quit: Connection closed for inactivity]
orivej has joined #nixos-aarch64
dustinm has joined #nixos-aarch64
zupo has joined #nixos-aarch64
<hexa-> colemickens: does #112677 enable uboot support for the rpi4 and if yes, with which kernel?
<{^_^}> https://github.com/NixOS/nixpkgs/pull/112677 (by colemickens, 7 weeks ago, open): nixos rpi bootloader: install files for raspberry pi 4 (rpi4)
<hexa-> as in: is it working for you?
<samueldr> unless they undid my work when they split the rpi4 image nix files
<samueldr> the rpi4 image was already being built with u-boot
<samueldr> but u-boot + rpi foundation kernel
<samueldr> the change you linked from colemickens was intended to add the missing rpi4 files for the generic mainline-based sd image
fila has left #nixos-aarch64 ["Leaving"]
justanotheruser has quit [Ping timeout: 250 seconds]
cole-h has joined #nixos-aarch64
awmv has joined #nixos-aarch64
justanotheruser has joined #nixos-aarch64
superherointj has joined #nixos-aarch64
<superherointj> Hello. Got some weird issue with EMMC. At first it won't boot. Then, if I press 'r' (for reboot) everything works just fine.
<superherointj> Thanks for any idea.
<samueldr> oh
<samueldr> uh
<samueldr> welcome to my hell
<samueldr> I suspect there is marginal behaviour in the Linux mmc driver around hs200, hs400 too, access mode
<samueldr> there is a workaruond
<samueldr> I need to find it in another user's repos :)
<samueldr> but it's less integrated with NixOS than I assumed :/
<samueldr> this is a bash implementation of the same idea I'm using for the same issue on another rk3399 system: https://github.com/NixOS/mobile-nixos/blob/master/devices/asus-dumo/fixup_sdhci_arasan_task.rb
<samueldr> sometimes it just works first try, sometimes it takes multiple tries
<samueldr> another workaround is disabling hs200 either in the device tree or bluntly in the kernel driver
<samueldr> but then it goes slower
<superherointj> Slower only at boot?
<samueldr> if you disable hs200
<samueldr> but if you unbind/bind until it shows up it'll work just fine
<samueldr> and it is hard to reproduce, and possibly hardware dependent
<superherointj> I can reproduce it every time I turn the board on.
<samueldr> that counts as being "hard" to reproduce when you want to debug such an issue :)
<samueldr> though it's not impossible, it's not necessarily on command
<samueldr> so a developer might think they have a solution, but only made it happen less often :)
<superherointj> That is really helpful. :)
<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.