<ukky>
jaeger: I have some experience with U-Boot for Arm platform at work, is there any way I can help you with?
<jaeger>
Not sure, though I appreciate the offer. I've been reading some docs such as https://u-boot.readthedocs.io/en/latest/board/starfive/visionfive2.html (which seems to be the most useful) and it seems like I could maybe use its instructions to get a bootable image created from crux packages if I figured out how to configure eEnv.txt, etc.
<jaeger>
It uses a JH7110 so I'm reading more about that
<ukky>
My company makes embedded devices, based on different CPUs, SoC, etc. Arm is just one of them. Some products use X86_64, some use even MicroBlaze.
<ukky>
I am kinda responsible on the boot loader side, just for a few products.
<jaeger>
Nice. I think it would be interesting to work in embedded, though maybe also maddening since there are tons of them
<jaeger>
I have a buddy who works for Kali doing ARM development
<ukky>
I just started working with Arm, since May, it is a new product line.
<jaeger>
Ah
<ukky>
I took a quick look at the guide for your board and do not anticipate any issues
<ukky>
If you need any help initializing eMMC from U-Boot, let me know
<jaeger>
The guide looks useful, it's just a lot of terminology for which I'm not familiar since I haven't done much embedded stuff. Raspberry Pis make it too easy by not using u-boot, heh
<jaeger>
Thanks, I'll keep it in mind
<ukky>
You can ask me about terms you don't know. There are so many acronyms nowdays.
dim44 has joined #crux-arm
pitillo has quit [Ping timeout: 264 seconds]
pitill0 has quit [Ping timeout: 264 seconds]
pitillo has joined #crux-arm
pitill0 has joined #crux-arm
beerman has quit [Server closed connection]
beerman has joined #crux-arm
<jaeger>
The jumpers on the board are set in QSPI mode. Do I understand correctly that that means it's booting SPL and u-boot from onboard NOR flash, then looking for the kernel and filesystem elsewhere?
<ukky>
Jumpers just define primary boot device
<jaeger>
UART mode makes sense, and I assume SDIO means SD card or eMMC
<jaeger>
yeah
<jaeger>
And QSPI is the onboard flash, right?
<ukky>
yes, SD and eMMC protocol is the same
<ukky>
yes, QSPI is on-board flash
<jaeger>
ok, cool
<jaeger>
One of their docs says:
<jaeger>
"QSPI Flash (For SPL + OpenSBI + U-Boot) + NVMe/SD Card/eMMC (For Kernel + File System and later)"
<jaeger>
which seems like pretty much exactly what I want... SQPI -> NVMe (eventually)
<jaeger>
Though right now I'm working on QSPI->SD
<jaeger>
s/SQPI/QSPI/
<ukky>
it depends on the boot stages how to implement booting kernel from eMMC or NVMe
<ukky>
Usually U-Boot loads kernel, but not always
<jaeger>
I may be misunderstanding but my thinking was I could tell u-boot to find the kernel and filesystem on the SD card or the NVMe, hopefully
<ukky>
It all depends on U-Boot boot script how to find kernel to boot. U-Boot is limited in scanning, but if you know where kernel might be, you can write a script for primary and secondary location, i.e. try NVMe, then try eMMC
<jaeger>
ok
<ukky>
Finally made aarch64 cross-toolchain: file test: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, with debug_info, not stripped
<pitillo>
beerman: great, I'm building it too on the odroid and the rpi3
<pitillo>
ukky: have you used toolchain repo have you built it or by your way?
<pitillo>
jaeger: welcome to uboot fight xD (at the beggining quite hard, but at the end, pretty straighforward
crux-arm-bot has joined #crux-arm
crux-arm-bot has left #crux-arm [#crux-arm]
<crux-arm-bot>
[ crux-ports-opt-arm ]: llvm: update to 17.0.5
<beerman>
Perfect :)
beerman has quit [Remote host closed the connection]
beerman has joined #crux-arm
<ukky>
pitillo: used original crux-arm toolchain repo, but had to modify it a bit for latest package versions.
<pitillo>
ukky: nice, versions and the path or something else?
<pitillo>
do you have a diff to save it and apply in case we get the repo on github?
<ukky>
pitillo: I can create a git diff and send it to w/e (mailing list?). btw, I couldn't access old git repo on crux-arm, just downloaded latest versions of each file
<pitillo>
ukky: I'll contact sepen to publish toolchain and pkgutils-cross on github
<ukky>
besides versions bump to the latest stable, there is a patch to apply, even for arm32 toolchain.
<pitillo>
keepnthebdiff near to do a PR when they are ready and keep track of uour work
<pitillo>
that sounds great... stable and robust piece to build.toolchains
<pitillo>
and very customizable IMHO.... not only components options
<ukky>
also, Makefile needs a rework to auto-create download path for kernel, i.e. 'v6.x' part in the path.
<ukky>
also, I had to add CXX definition for some targets, otherwise Makefile uses host's g++
<pitillo>
interesting... so not only versions and patch
<pitillo>
that sounds great really. Someone else givit ing some love xD
<ukky>
and running 'make' requires using 'make MACHTYPE=$MACHTYPE' instead, as MACHTYPE is not defined withing make shell (sh)
<pitillo>
I've sent a message to sepen.... let's see if he can get some time to publish these repos
<ukky>
I moved 'work/test.c' into 'test/test.c', but using 'work/' as output direcrory.
<pitillo>
minor change... the other ones are the interesting and big impact ones
<ukky>
next step for me would be to create newlib (elf, or baremetal) toolchains for arm32/aarch64
<pitillo>
should't be difficult to adapt the Makefile for them (that's what I meant above by customization
<ukky>
agree, for newlib we just need to remove glibc targets from Makefile
<pitillo>
we tried to do something kiss... and compared with other solutions, there is no doubt it is (I don't mean it's better or worse, just different)
<pitillo>
yeah, same for musl, uclibc, diet....
<ukky>
that would be nice, I mean support glibc, musl, uclibc, dietlibc, newlib. This would attract more devs/users to crux distro.
<ukky>
just have clean guide how to do it would be sufficient
<jaeger>
Bit of a snag on the VisionFive 2 boot... only one branch of starfive tech's kernel tree actually compiles and it causes a panic on boot :P
<ukky>
jaeger: can you post full boot log, please?
<jaeger>
I didn't save it, will do so when I have time to mess with it again
<ukky>
do you have a way to redirect console output to serial port and grab it? i.e. is kernel command line editable?
<jaeger>
I can get the output but for some reason I have no input when connected to it... haven't figured that out yet
<jaeger>
There's no HDMI output, just using serial with a pl2303 usb adapter
<jaeger>
Which works fine on other devices like a la frite... but no input on the visionfive 2 for some reason
<ukky>
jaeger: you need to edit /etc/inittab to start agetty on a serial port
<jaeger>
Of course, and that's done... but it doesn't boot that far
<jaeger>
When I say "no input" I mean "no input" - even at u-boot
<ukky>
oh
<jaeger>
I do see the u-boot menu but can't interact with it... so I've configured it to boot the kernel I want, which then panics
<ukky>
have you enabled local echo in terminal client? have you disabled HW/SW flow control?
<jaeger>
echo doesn't seem to be the issue, as there's also no response to anything I type at the boot menu. Would be able to see a result even if I couldn't see my input
<jaeger>
Haven't tried flow control yet
<jaeger>
Something like 'stty -F /dev/ttyUSB0 cs8 -parenb -cstopb' maybe
<jaeger>
Maybe not, that appears to be how it's set by default
<ukky>
maybe 'stty -ixon'?
<ukky>
I always use minicom, but can try 'xterm + stty' and see if I can communicate with U-Boot
<ukky>
jaeger: couldn't make xterm work with my device, but 'screen' works. All I need is 'screen /dev/ttyUSB0 115200', input in U-Boot interface works.
<jaeger>
That's how I'm using it here, too. No input but output is fine.
<jaeger>
Possibly interesting data point, I tried it on the mac mini with the same invocation (screen /dev/<usbserialdev> 115200) and it works there. Same cable
<jaeger>
So at least I can use that as a fallback but I'll try to discover what's different about their tty device configs
<ukky>
question, is /dev/ttyUSB0 writable by your user?
<jaeger>
yes
<jaeger>
input/output work fine with this same serial adapter on other boards as I mentioned
<jaeger>
just not the visionfive2
<jaeger>
Very odd
<ukky>
spooky
<ukky>
Are you connecting serial cable via jumper wires to a GPIO header? or, is there a UART/RS232/USB connector?
<jaeger>
gpio
<ukky>
try swapping UART pins on the header. At work my UART2USB adapter has labels RX and TX swapped.
<jaeger>
It works on the mac mini, though, without any changes
<ukky>
what is 'ls -l /dev/ttyUSB0'?
<jaeger>
Sorry, had to go for a while. Looks like -ixon works... which I thought I had tried for some reason but I guess not
<ukky>
nice
<jaeger>
Next time I have the mac mini turned on I'll see if I can check if that's set by default... but it works, at least
<jaeger>
Thanks for the help
<ukky>
you are welcome, any time
<jaeger>
OK, now at least I know I can get it to boot a crux installation. I gutted the debian image except for the kernel, modules, and /boot, uncompressed all the crux packages in for the rest :)
<ukky>
that was fast
<jaeger>
Well, I already had all the packages :)
<ukky>
For RISC-V?
<jaeger>
yeah
<jaeger>
Been building them for quite a while now... I started with a debian install on the visionfive2 building crux packages in a chroot... then I installed all of those into a rootfs to use with qemu, then I rebuilt them all in qemu
<jaeger>
That order may sound strange but I was just experimenting, it wasn't a specific goal
<ukky>
it's good when you have options
<jaeger>
Yeah
<jaeger>
Neither of my options are very fast, but it's just learning/hobby, so no need to rush
<ukky>
same here, plus too much work
<ukky>
I've got new PC at work in June and still have no time to complete CRUX installation, only SSH/console works
<jaeger>
Got to start somewhere, heh
<ukky>
The task gets harder when you want to replace sysvinit, service manager, remove eudev, etc
<jaeger>
indeed
<ukky>
so, are you booting from SD/NVMe now on your VisionFive2?
<jaeger>
uSD for now, going to look into NVMe later
sajcho has joined #crux-arm
<sajcho>
jaeger: vf2 sometimes behaves strangely. Personally, I went the kernel upstream, u-boot upstream route and I'm satisfied so far.