IRC channel logs
2020-02-12.log
back to list of logs
<civodul>we really have to fix that AArch64 Guile 3.0 bug <civodul>also, would be nice if linux-libre would actually build *and* boot :-) <janneke>civodul: i've been "waiting" to put this up, trying to somehow debug the linux-libre boot since sunday... :-( <janneke>as it is, i don't think this is guix material <civodul>it's great that you were patient enough to get this far already <janneke>civodul: hmm, yes -- i'd be happy to post it to guix blog; but it could be read as: "how to boot guix while still using a non-free kernel" :-( <janneke>it would be a pretty nice machihne once linux-libre boots! <civodul>janneke: you're right, well, "we" :-) can fix the linux-libre issue <civodul>and then publish an updated version on the Guix blog *janneke actually meant to say: *love it* *janneke just found that u-boot/pinebook pro won't boot vmlinux, but needs `arch/arm64/boot/Image' <stikonas>hmm, isn't arch/arm64/boot/Image the standard thing with arm64 u-boot? <stikonas>although, on my rockpro64 I have an intermediate step (grub2) <janneke>stikonas: yes, that's what i just heard <stikonas>btw, are you putting u-boot on eMMC or SPI? <janneke>although i did not know it was "standard u-boot", only that vmlinux won't work for me <janneke>stikonas: do you have any idea if i can boot an mmc image with qemu? <stikonas>I think you can, but you probably need some arm64 UEFI image <stikonas>or maybe you can just boot kernel directly... <stikonas>in that case you should extract kernel/initramfs/dtb from your image and pass it to qemu... <janneke>stikonas: the mmc image that i'm using has a separate rk3399-pinebookpro.dtb <janneke>so, from your remark i take it that that's tied to the kernel? *janneke tried to google what dtb or fdt stands for... <stikonas>unlike x86_64 which has mostly buses that can be probed <stikonas>on arm most buses are simpler and you need to describe which devices are connected <stikonas>so that kernel knows what e.g. controls fan, what controls sdcard voltage, etc.. <janneke>the u-boot that guix installs creates a fdtdir, and i'm wondering if that could work at all as the image i'm using has this .dtb file <stikonas>hmm, I haven't used fdtdir but I think it's probably similar to config file vs conf.d folders <stikonas>I have some guide for Gentoo on rockpro64 (also rk3399 based, just as pinebook pro) <janneke>yeah, it looks like that...but given that i get to see no u-boot output -- very discouraging this rebooting all the time <stikonas>yeah, I think there is a bug in u-boot, so u-boot fails to power on HDMI screen <janneke>stikonas: i got one cable that fits the sockets, but i am unsure about this 3.3v thing and uart people are talking about <janneke>it seems some cables have that built in? <janneke>should u-boot detect a serial cable and wait if it sees it? <stikonas>somebody on #linux-rockchip (anarsoul if I remember correctly) did some investigations, and he got HDMI screen to show something while in u-boot but it wasn't very useful image <stikonas>janneke: I think you can ignore that 3.3v thing <stikonas>only 3 cables are needed (ground, tx and rx) <stikonas>u-boot has serial cable drivers but you need to specify correct baud rate <stikonas>I usually just power the board using normal power cable instead of providing power via serial cable <janneke>hmm, i do not have a any ttyUSB on my other laptop when i plug the cabel in <janneke>stikonas: i already much appreciate your help, i'm /so/ lost here <stikonas>ttyUSB device node should appear as soon as you plug USB device in... Even if serial wires are not connected <janneke>it will all make perfect sense, once it works <stikonas>I get something like [51749.388545] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0 <stikonas>[51757.028214] usb 1-6.3: FTDI USB Serial Device converter now attached to ttyUSB0 <stikonas>maybe different drivers create different device nodes... <janneke>hmm, but that's still listening even when i unplug the usb cable <fossy>like virtual terminal 1 is TTY1 <dddddd>I used a raspberry pi, no usb involved. I did check the volts, to match. Not pinebook, but "similar" (teres) <stikonas>janneke: can you check lsmod | grep usbserial *janneke flipped the uart switch <vagrantc>janneke: i don't think qemu supports emulating a the pinebookpro <vagrantc>janneke: but exciting regarding your guix on it! <stikonas>vagrantc: can't it emulate generic cortex A72 or something like that <vagrantc>stikonas: probably ... which doesn't really emulate a pinebookpro :) <janneke>i just flipped the uart switch for serial output...but after re-assembling it does not turn on again :-( <janneke>ah, opening the back cover disconnected the battery cable <janneke>i was wondering about that loose connector when i opened it <dddddd>OriansJ, fossy, M1 hex literal uses double quotes, not single (which is string instead) wrt the example of some days ago. <OriansJ>dddddd: you have that backwards; "raw string" 'hex literal' <dddddd>I think you called '0280284849' a hex literal. <OriansJ>as raw strings are converted to hex and hex literals are just passed to hex2 to deal with <dddddd>but, being not processed at all... I see it just as string. <OriansJ>dddddd: what does it look like when processed by hex2 <dddddd>My point of view is M1, I guess. <OriansJ>"hello world" becomes 68656C6C6F20776F726C6400 in M1 but hex2 turns back into hello world in the binary <OriansJ>'68656C6C6F20776F726C6400' is processed as 68656C6C6F20776F726C6400 in M1 but hex2 is where it becomes what we really want <OriansJ>it is the literal hex we want written <janneke>hmm, it seems that ttyUSB is only a courtesy symlink, created by a udev rule? <janneke>so i'm trying /gnu/store/yz4rkj6pnx4md4izszaj2jndnhx5jhd5-screen-4.8.0/bin/screen /dev/bus/usb/001/001 15000000 <janneke>but that says: /var/run/utmp: No such file or directory <OriansJ>Unlike various other systems, where utmp logging can be disabled by removing the file, utmp must always exist on Linux. <OriansJ>see if touch /var/run/utmp fixes the problem <janneke>it seems that minicom runs...haven't run that in > 25y <dddddd>OriansJ, makes some sense if one thinks of what happens after hex2 does its thing, Just a bit weird in the context of M1 itself. OK