granra has quit [Quit: Page closed]
petersjt014 has quit [Remote host closed the connection]
makefu has quit [Ping timeout: 268 seconds]
orivej has quit [Ping timeout: 245 seconds]
makefu has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
maskerad has quit [Ping timeout: 268 seconds]
orivej has joined #nixos-aarch64
maskerad has joined #nixos-aarch64
orivej has quit [Ping timeout: 245 seconds]
zupo has joined #nixos-aarch64
orivej has joined #nixos-aarch64
maskerad has quit [Ping timeout: 250 seconds]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
maskerad has joined #nixos-aarch64
orivej has quit [Ping timeout: 246 seconds]
zupo has joined #nixos-aarch64
maskerad has quit [Remote host closed the connection]
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
zupo has joined #nixos-aarch64
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 246 seconds]
zupo_ has quit [Client Quit]
orivej has joined #nixos-aarch64
worldofpeace has quit [Remote host closed the connection]
worldofpeace has joined #nixos-aarch64
<makefu> samueldr: i wanted to create a page for the arm board i am tinkering with in the nixos wiki. do we have a template or should i just copy-paste from another board?
<samueldr> copy/paste, either pine a64-lts or raspberry pi
<samueldr> they are the two I worked the most on
<samueldr> makefu: there's no clear guidelines for the page names right now
<makefu> that is actually what i did, copied the pine a64
<samueldr> makefu: what's the board name, and page name?
<makefu> good enough, i just didn't want to miss something
<samueldr> I would like it to be MFG_NAME as much as possible
<samueldr> huh
<makefu> AIO-3399C , not created yet
<samueldr> MFG_BOARDNAME
<samueldr> okay, so probably Firefly_AIO-3399C
<makefu> yep
<samueldr> thanks for creating an entry for the board :)
<samueldr> (not all end-users do)
<makefu> i think it is worthwile. because i would check the wiki before buying a new arm board :)
<makefu> if the status is "well... nothing actually works" then i might hesitate, worse yet for boards not in the list :D
<samueldr> same
<samueldr> I even added good documentation that's not found elsewhere for the PINE A64-LTS, namely mainline u-boot in the SPI NOR flash
orivej_ has joined #nixos-aarch64
orivej has quit [Ping timeout: 268 seconds]
<makefu> that is really awesome, yeah. i try to get the aio-3399c board to a similar level. but at first i will have to get it to boot nixos :)
<samueldr> makefu: tried booting the aarch64 **iso** with the board?
<samueldr> it *might* be able to UEFI boot, since the u-boot fork from Firefly doesn't look too out of date
<makefu> how would i do this? just flash the iso onto the rootfs partition of the emmc?
<makefu> or write onto another mmc?
<samueldr> let me open the documentation for that board to see how likely
<makefu> yep
<samueldr> >> SPI interface
<samueldr> yeah, if the u-boot build has UEFI support, and it is built with it, it might boot with a usb drive
<makefu> cool
<samueldr> I know my pine A64-LTS when u-boot is burned to the SPI will boot from USB in that case
<samueldr> ah, forget about it
<samueldr> too old
<samueldr> just verified
<makefu> too bad
<samueldr> it was added april last year (2018) to u-boot
<samueldr> their fork is 2017.09
<samueldr> it *might* be updated soon since they handled the u-boot port for libre.computer
* samueldr sighs
<samueldr> in other news
<samueldr> sd_image might work without having to "burn" a u-boot to it
<samueldr> if they built their u-boot with the generic distro thing
<makefu> okay, sounds good.
<samueldr> `CONFIG_CMD_BOOT_ANDROID=y` hmmmm probably not then
<makefu> it seems i can also just flash the rootfs via the rockusb mode. not sure if that works out correctly though
<makefu> what is the nixos equivalent to the ubuntu base-img tarball?
<makefu> well at first i will check out the serial console
<samueldr> I have a confession to make: I have almost zero experience with those kind of things outside nixos :o
<samueldr> ah, no, I have some experience with archlinuxarm, but then it's different from both ubuntu and nixos
<makefu> no need for a confession :)
<samueldr> I know :)
<samueldr> hmm, also maybe a bunch about the non-rockchip android boot process
<samueldr> nice, the documentation refers to a u-boot source tree which isn't their github repo :/
<makefu> they moved the u-boot sources to gitlab afair
<samueldr> hmmmm, safe I found https://gitlab.com/T-Firefly
<samueldr> hmm, looks like their github repo had its default branch set to `stable`... master has a less up-to-date u-boot fork (2017.02) but has the right defconfig according to their doc
<samueldr> the gitlab repo is one commit out of date compared to the github repo
<makefu> maybe te defconfig could be cherry-picked onto the latest uboot
<samueldr> definitely can't; it's not in the defconfig where the magic happens, though I might be wrong
<makefu> all this embedded stuff is just so super complicated :D
<samueldr> cursory looks they have a *bunch* of changes on top of upstream u-boot
<samueldr> they make it complicated by not collaborating :(
<samueldr> but even then, firefly might not be the only ones to blame, it might be rockchip's own tree which is to blame
<makefu> yeah. after the wiki page i wanted to write a first review of their stuff and i will add this point
<samueldr> wondering if this might be more up to date and working https://github.com/rockchip-linux/u-boot/tree/stable-4.4-rk3399-linux
<samueldr> if I understand everything the defconfig they are using is a generic one
<samueldr> hmm, firefly-rk3399_defconfig, but not sure it applies to the AIO board
<makefu> seems to be, at least according to their documentation
<makefu> (formatting is fucked up for the page)
<samueldr> maybe they are compatible
<makefu> maybe so. all the boards should be pretty similar (tm)
<samueldr> hmm, from a cursory glance, it might be annoying to get u-boot working with the generic distro thing (extlinux)
<samueldr> but if my hunch is right, might not be too difficult
<samueldr> I'm thinking mainly that somehow the u-boot env will need to be pre-seeded with the right configs
<samueldr> that would be my first try, getting the boot environment setup that way... which might not be enough; there is probably something else in rk33plat.h that somehow sets their environment "right" for them
<samueldr> oh, forgot to say: it looks like the "include/config" file for rk3399 is rk33plat.h
<samueldr> hmmm, though it's in the firefly fork, but not on the rockchip one?
<samrose_> samueldr: how is this aarch64 iso typically installed?
<samueldr> ooof
<samueldr> samrose_: the board needs to be able to boot standard UEFI programs
<samueldr> recent u-boot can
<samrose_> ah ok
<samueldr> assuming you have u-boot started and running, or another UEFI implementation
<samueldr> (left as an exercise to the reader)
<samueldr> (1) burn the iso like you would for x86_64
<samrose_> heh
<samueldr> (2) boot the device
<samueldr> (3) install like you would for x86_64
<samrose_> thanks for the info
<samueldr> this allows tianocore to be used on the raspbery pi
<samueldr> so no u-boot, but uefi boot
<samueldr> though, to continue with the train of thought I had:
<samrose_> is that how the iso is booting in these tests? https://github.com/NixOS/nixpkgs/blob/master/nixos/release-combined.nix#L88
<samueldr> looks like the `stable-4.4-rk3399-linux` branch of the rockchip u-boot fork might work out of the box with a nixos sd image
<samueldr> so might be a good idea to investigate it?
<samueldr> samrose_: boot-stage1 skips the bootloader I think
<samueldr> but right now there are things that make them fail on aarch64
<samueldr> some cannot be ran on uefi (e.g. the bios boot ones)
<samueldr> but the uefi ones should at one point be able to work
<samueldr> it might be a simple oversight like using an x86_64 only thing somewhere
<samrose_> ok, so hydra is able to run the aarch64 sd image and the iso in qemu, and then it skips boot loader and jumps right into boot stage 1
<samueldr> I don't think there is an sd_image test
<samrose_> (I'll study that boot-stage-1 test too)
<samueldr> I'm pretty sure there isn't since (IIRC) u-boot is annoying to boot right now?
<samueldr> to boot in qemu with kvm*
<samueldr> at least, I had troubles doing so
<samrose_> mmm, ok
<samueldr> but not with kvm turned off
<samrose_> but I am probably misinterpreting
<samueldr> ah, that list you're linking to is build artifacts necessary to complete a build
<samueldr> so it *builds* sd_image and builds the other tests
<samueldr> but they are all independent
<samueldr> but yeah, stage-1 would be tested and working for aarch64-linux if it was in supportedSystems
orivej_ has quit [Ping timeout: 244 seconds]
orivej has joined #nixos-aarch64
lopsided98 has quit [Ping timeout: 246 seconds]
lopsided98 has joined #nixos-aarch64
lopsided98 has quit [Ping timeout: 246 seconds]
lopsided98 has joined #nixos-aarch64
<makefu> samueldr: okay finally got debug serial working, seems they use baud rate 1500000 and the diagram they are using has rx and tx switched up ...
<samueldr> makefu: switched up?
<samueldr> your TX is on their RX and your RX is on their TX?
<samueldr> (if so that is the right way around)
<samueldr> (and annoying to me)
<makefu> your description is what i would have expected ...
<samueldr> white: TXD, output line of serial port, TX needle of serial port of development board
<samueldr> green: RXD, input line of serial port, RX needle of serial port of development board
<samueldr> yeah
<samueldr> looks like theirs are labeled weirdly
<makefu> exactly
<makefu> i also do not get why they use some weird baud rate as a default
<samueldr> probably legacy with rockchip things
<makefu> maybe so
<makefu> https://paste.krebsco.de/DTRhqHFp is the boot log till ubuntu boots
<makefu> Model: Firefly-RK3399 Board
<makefu> :D yeah saw the same
<makefu> => version
<makefu> U-Boot 2017.09-gd80ac02 (Dec 13 2018 - 09:05:11 +0800)
<samueldr> that's good to know, the exact commit can be found
<makefu> uboot became really powerful in the last years. the last time i checked (when flashing uboot for the mr3020 wifi router) the features were super limited. not it can do all kinds of stuff
<samueldr> yeah, they built good things inside u-boot, like that exlinux parsing thing
<samueldr> and last year uefi by suse
<samueldr> the uefi one is perfect considering how EBBR is probably going to be a thing
<samueldr> hmm, gd80ac02 isn't in rockchip's nor firefly's trees
<samueldr> ah, I was looking at a particular thing, but it was the bl31, which isn't part of u-boot
<samueldr> (not the commit hash, something else entirely)
<samueldr> yeah, so this is part of rockchip's u-boot fork I think
<samueldr> "Firefly-RK3399 Board" isn't at all part of firefly's
<makefu> i think it is part of the rockchip uboot
<samueldr> the commit itself might not be (might have been rebased)
<makefu> i check this real quick
<samueldr> `Hit any key to stop autoboot:` might be ctrl+c on rockchip
<samueldr> ah, or not, it seems to be something else
<makefu> i simply it space bar and this worked
orivej has quit [Ping timeout: 240 seconds]
<samueldr> yeah, it's for before the countdown is done (looking at the source) there's an ifdef for rockchip and it would seem it checks if ctrl+c is held
<samueldr> >> printenv bootcmd
<samueldr> >> bootcmd=run distro_bootcmd
<samueldr> that's what our standard builds do
<samueldr> and looking at the source code, `run distro_bootcmd` might work here
<samueldr> but I'm thinking that they replace `bootcmd` with something else
<makefu> => printenv bootcmd
<makefu> bootcmd=boot_android ${devtype} ${devnum};bootrkp;run distro_bootcmd;
<samueldr> u-boot will run the contents of that after the delay
<samueldr> help run, for details
<samueldr> >> printenv distro_bootcmd
<samueldr> if you have this set, you're good to go to boot nixos
<makefu> => printenv distro_bootcmd
<makefu> distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
<makefu> => printenv boot_targets
<makefu> boot_targets=mmc1 mmc0 usb0 pxe dhcp
<samueldr> that's what I see on my pine
<samueldr> though something would need to be figured out to get this as the default bootcmd
<samueldr> maybe you can saveenv