jtojnar has quit [Ping timeout: 255 seconds]
jtojnar has joined #nixos-aarch64
disasm has joined #nixos-aarch64
orivej has quit [Ping timeout: 245 seconds]
jtojnar has quit [Remote host closed the connection]
orivej has joined #nixos-aarch64
jtojnar has joined #nixos-aarch64
zupo has joined #nixos-aarch64
zupo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Moredread[m] has quit [Remote host closed the connection]
Ericson2314 has quit [Remote host closed the connection]
sphalerit has quit [Read error: Connection reset by peer]
nocent has quit [Read error: Connection reset by peer]
bennofs[m] has quit [Remote host closed the connection]
cornu has quit [Remote host closed the connection]
exarkun1 has quit [Remote host closed the connection]
timokau[m] has quit [Remote host closed the connection]
dtz has quit [Remote host closed the connection]
codyopel has quit [Write error: Connection reset by peer]
thefloweringash has quit [Read error: Connection reset by peer]
zupo has joined #nixos-aarch64
zupo has quit [Client Quit]
sphalerit has joined #nixos-aarch64
codyopel has joined #nixos-aarch64
timokau[m] has joined #nixos-aarch64
Ericson2314 has joined #nixos-aarch64
Moredread[m] has joined #nixos-aarch64
nocent has joined #nixos-aarch64
cornu has joined #nixos-aarch64
dtz has joined #nixos-aarch64
bennofs[m] has joined #nixos-aarch64
exarkun has joined #nixos-aarch64
thefloweringash has joined #nixos-aarch64
jtojnar has quit [Ping timeout: 252 seconds]
Thra11 has joined #nixos-aarch64
lopsided98_ has joined #nixos-aarch64
lopsided98 has quit [Ping timeout: 252 seconds]
<sphalerite> samueldr: any chance I could pick your brain regarding getting my own kernel running on the nanopi? :)
<samueldr> ask
<samueldr> I don't know how much I can help
<sphalerite> specifically, I have no idea where the kernel lives, and would appreciate any help finding out
<samueldr> but will try!
<samueldr> right, you're new to all things u-boot
<sphalerite> I have managed to build my own u-boot and use that, but the vendor branch has next to no config options
<samueldr> sphalerite: which nanopi model exactly already?
<sphalerite> m4
<samueldr> okay, nothing in mainline u-boot (boo)
<sphalerite> I also don't know how to get a serial console, which is a bit of a pain :p
<samueldr> do you have a usb serial interface?
<clever> sphalerite: do you know which pins it is?
<sphalerite> clever: no, that's the problem
<sphalerite> samueldr: as in a USB-TTL adapter? Yeah two
<samueldr> good
<clever> sphalerite: do you have a scope or volt meter?
<sphalerite> I have managed to talk to UART4 on it, but that isn't used by u-boot or as a kernel console
<clever> sphalerite: kernel console can be moved around, console=ttyS3
<samueldr> debug UART
<sphalerite> clever: if only I knew how to change the kernel params :)
<sphalerite> samueldr: aaaaaaaaaaaaaaaaaah why didn't I find this myself xD
<sphalerite> thanks
<samueldr> probably easier to get u-boot speaking serial first
<clever> sphalerite: kernel cmdline can be set in uboot cfg, or baked into the kernel at build-time
<clever> samueldr: yeah
<sphalerite> clever: if only I knew how to set the uboot cfg :)
<sphalerite> or get my own kernel booting. (see above)
<samueldr> sphalerite: where's the downstream (oem) u-boot you used?
<samueldr> I want to check some assumptions first
<samueldr> the only branch I presume
<samueldr> oof, 2014.10
<sphalerite> it's quite close to https://github.com/rockchip-linux/u-boot
<sphalerite> not sure which branch of the latter it was
<sphalerite> aaaah the debug uart is even physically labelled "DBG UART"
<samueldr> :3
<sphalerite> is there a standard order for the pins?
<samueldr> no
<samueldr> you probably don't want to plug the +5V one from your dongle
<samueldr> at least for most boards I used it's never used
<sphalerite> yeah wasn't planning to, I've always had RX, TX and GND be enough too
<sphalerite> clever: how do I tell which pin is which using my voltmeter?
<sphalerite> ah perfect
<samueldr> GND should be square
<samueldr> labelled here
<clever> sphalerite: ground is easy to find, just ohm things out to a ground, when its off
<samueldr> (I say should be square since it looks square on their design)
<clever> sphalerite: power is found with a volt meter, and can be ignored
<clever> tx/rx, connect one to the rx of your usb, and see if you hear any chars
<samueldr> so ground looks like the one closed to the outside of the board
<samueldr> and tx/rx labels are "meaningless" as in some OEM will label the pin you plug RX in RX, and some will name it TX
<samueldr> because of how you plug RX in TX and TX in RX
<sphalerite> lol
* samueldr sighs
<clever> there is a slight risk of damage, if you connect tx and tx together
<samueldr> eek, 16:36 already :/ have something this evening and need to do things yet
<clever> but no risk from rx<->rx
<clever> so just try connecting a random one to your rx, and then see what comes out
<samueldr> but yeah, since it's u-boot 2014.xx
<samueldr> I won't be able to help
<samueldr> I've never looked at u-boot's things in details and relied on something available since ~2016, or 2018 for UEFI
<samueldr> though I'm thinking there might be value in figuring out those older u-boot with nixos (and including generation boot) as sometimes mainline just isn't available :/
<samueldr> (going in with the mindset that it's better to use hardware you already have, than to throw it away and buy something better supported)
<sphalerite> We have serial! :D
<samueldr> good
<sphalerite> woo I can talk to the u-boot!
<samueldr> tohugh the fact that it's that old of a u-boot means I really don't know how to help better with nixos
<samueldr> the whole sd_image setup right now pretty much assumes use of the generic distro configuration from newer u-boots
<samueldr> (or iso image with uefi)
<sphalerite> eh, it's fine, I'll work something out :)
<sphalerite> having the serial console is already really helpful
<sphalerite> if you have any idea how to find a kernel image in an SD image that would also be really helpful
zupo has joined #nixos-aarch64
<sphalerite> I've found dtbs already, but that's it so far
<samueldr> there's a page off the rockchip wiki that might help
* samueldr is foraging
<samueldr> that's how rockchip assumes OEMs will make their boards boot, and probably how it boots for yours
<samueldr> (chrome devices definitely diverge there)
<samueldr> AFAIK chrome devices still have the same BootROM, but due to the presence of the SPI chip with their bootloader, the boot process diverge really earl
<samueldr> y
<samueldr> at least for the 32 bit RK3228 it apparently would go through the usual rockchip stuff if you futzed around
<sphalerite> hmm
<samueldr> I'm confused now, hmmm playing with device trees while having partial knowledge and no good resource is fun
<samueldr> (especially considering apparently no one has documented device tree overlays with the mainline kernel and mainline device trees)
<samueldr> for the raspberry pi*
<samueldr> though just now I think I realized how it worked in a broken way before and now doesn't work
<samueldr> booted using Tianocore + grub, no device tree loaded, means it used the built-in DT (or maybe one from the UEFI build)
<samueldr> which that one apparently had symbols(?)
<samueldr> while the mainline one built by nixos maybe doesn't
<samueldr> -@, --symbols
<samueldr> Enable generation of symbols
<samueldr> (all that to make the cheap-o screen thing work, and also learn more about device trees along the way)
<samueldr> definitely makes sense though now, the error message, >> [ 2366.698566] OF: resolver: no symbols in root of device tree.
<sphalerite> so confusing how there's github.com/linux-rockchip and github.com/rockchip-linux >_<
<samueldr> :o
zupo_ has joined #nixos-aarch64
zupo has quit [Ping timeout: 250 seconds]
jtojnar has joined #nixos-aarch64
jtojnar has quit [Remote host closed the connection]
jtojnar has joined #nixos-aarch64
Thra11 has quit [Ping timeout: 245 seconds]
zupo_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jtojnar has quit [Remote host closed the connection]