IRC channel logs
2020-02-13.log
back to list of logs
<markjenkinswznc>Interesting to hear you have Pinebook Pro Janneke. I've been doing much of my knightpies development on a plain Pinebook, including taking advantage of the small size to code on public transit. Two things I find interesting about Allwinner SOCs 1) they have a small ROM which does a non-configurable fixed boot order (aprox): USB, SD/microSD, eMMC, small internal flash. All the u-boot magic happens from there. If this component really is a ROM <markjenkinswznc>it can be treated as part of the hardware (and autited). Point 2) even despite Allwinner not being a great free software citizen, thier price point has attracted driver reverse engineering and I think they did put all the hardware init stuff paired with u-boot out there as free software. All told, an interesting owner controllable platform. <dddddd>Point 2 is about the ATF, right? <markjenkinswznc>dddddd, re point 2, yes, I believe ATF is part of the u-boot hard init stuff, though my knowledge of these things has a ways to go <markjenkinswznc>I wasn't careful enough to explain that plain Pinebook uses an Allwinner SOC and Pinebook Pro uses a RockRidge SOC, so all the stuff about Allwinner SOC realm doesn't apply <markjenkinswznc>also checked in again and discovered I was incorrect to mention USB boot by Allwinner BROM (boot read only memory), which is good news as USB takes a lot of code to implement, access to eMMC, microSD and other flash is simpler <dddddd>IIRC, when compiling u-boot you provide the ATF, already compiled from another repo (not u-boot's). <dddddd>I'm not familiar with RockRidge. <janneke>markjenkinswznc: yeah, thought it might be a good idea to help the arm port <dddddd>Yeah, something like that name. Anyway, I don't know the details. Thank you for the correction. <markjenkinswznc>I would assume he means Mes, in which case I might prefer a really high end x86 or Power9 workstation running qemu userland mode as the way to test a aarch64 GNU/Linux binary (a cool trick that doesn't require emulating a full VM) <janneke>i believe most of stage0 works, but nothing onwards; guix still has a traditional bootstrap <markjenkinswznc>I'm should benchmark my Raptor computer systems Blackbird running qemu aarch64 in GNU/Linux userland mode <dddddd>janneke, thanks... that was the questions, from with point / which parts. <janneke>yeah, so next stages are full source bootstrap and platform diversity; also there is auditability <dddddd>markjenkinswznc, qemu sometimes has bugs. I don't have problems with a more recent version, but some old one I use is unreliable. <janneke>OriansJ fork of mes can be seen as a "monster audit" <janneke>yes, i want to run arm without qemu, that has been troublesome esp. with tricksy debugging things <dddddd>janneke, so is porting of code in high level language? I'm missing something, sorry. <janneke>eh, can you rephrase that -- i cannot parse -- who is porting what? <markjenkinswznc>dddddd, good to know, though sad if aarch64 is buggy. It definitely makes sense to have the real ARM hardware as well, but if a fast workstation with the same OS as the target (allows for quemu userland trick) with an accurate emulator can speed up development in some phases, all the better <janneke>yes, mescc needs work; and the whole bootstrap needs to be done <janneke>dddddd: "porting" is probably the wrong term <janneke>"attempting, implementing and fixing the reduced binary seed bootstrap for arm" is probably better <markjenkinswznc>dddddd, I think what it comes down to re aarch64 (arm) is mescc-tools-seed has arm port, mescc-tools has arm port, M2-planet has arm port, and mes has arm port <janneke>i do not expect much actual "porting" to be done, the higher level tools "should" just run on arm too <janneke>but i'm pretty certain it will take a couple of months to get the bootstrap to "just run" <dddddd>markjenkinswznc, from my notes... the M2-Planet tests pass on qemu 3.1.0 (debian 10) but some crash kind of randomly in 2.1.2 (debian 8). I didn't use debugging features. Nor testes versions inbetween. <janneke>fossy has been "porting" the mes bootstrap from guix to bash; they can probably also tell you what we may expect <dddddd>janneke, OK... I'll try to remember what "the" bootstrap is for you, to put your comments in the right frame. Note that not everyone is at the same point or sees the same path. <janneke>dddddd: yes, i'm sometimes talking from my own perspective, context <dddddd>janneke, sure. It takes time to know each other perspective. Thanks for your patience. <janneke>i really meant guix's commencement.scm <janneke>:-) i like it a lot when people try hard to understand eachother, thank you <markjenkinswznc>fossy, when you were discussing gcc-seed many days ago and I didn't get a chance to weigh in, was just lurking. A shout out of moral support for gcc-seed and the overall idea of guix-less bootstraps. In my strange imagination this is actually useful for Guix for a certain case as well -- but first I have to cover two cases where it doesn't apply to give context: <markjenkinswznc>Case 1) The normal starting point for Guix users would be bootstrapping from another GNU/Linux -- and they might as well have Guix stuff come up as soon as possible (as is already the case). <markjenkinswznc>Case 2) The other extreme would be something like building knight ISA out of TTL, hand verifying a bootrom on tape and/or with an inspection circuit built in LEDs and running stage0, M2-planet, mes-m2, and some kind of M2 authored kernel to provide a sufficient environment to cross compile a Guix GNU/Linux for some other platform. That also might as well also have Guix specifics come up as soon as possible on first GNU/Linux boot. <markjenkinswznc>Case 3) Where gcc-seed helps: I'm imagining bootstrapping Guix with help of gcc-seed from a strange middle ground involing three three computers A, B, C as follows: <markjenkinswznc>Computer A is a retro platform (hardware+OS) I'm willing to sort of trust that's not GNU/Linux on x86/amd64 where it should be possible to build gcc-seed or something similar that's shell based and the 2004 tccboot bootloader-compiler hack to produce a x86 boot image for computer B (old x86 linux 2.4 compatible). <markjenkinswznc>Computer B self-compiles Linux with the 2004 tccboot hack and uses a gcc-seed or similar built userland, and computer B bootstraps Guix to be run on any Guix supported platform, perhaps even creating a reproducable .iso. Computer C boots Guix from boot media created by computer B. <markjenkinswznc>In this middle-ground case, gcc-seed or similar helps move the process along faster as Guix support isn't required to go from A->B, the idea is to escape from computer A to a minimal GNU/Linux that runs on computer B as fast as possible with dependancies and instruction set and executable format porting effort re computer A minimized as much as possible. <vagrantc>whoah, this might be better as a blog post :) <vagrantc>general irc etiquette is more than a few lines to use a pastebin... <dddddd>Let's say those are a few lines (of great comments, better than sparse phrases sentences). I like the content too, a lot. <OriansJ>janneke: also would you be open to a change in how MesCC deals with assembly generation? As you might benefit from a trick in GCC's playbook to enable faster porting and ultimately faster binaries <OriansJ>it also would enable a crazy idea to make a scheme compiler written in scheme become the root of Guix's trust