***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<fossy>i opened an issue so we wouldn't forget <dannym>janneke: No problem. Meanwhile, I've been busy prodding AMD to see the light of bootstrapping :) <janneke>dannym: oh, that's a recent x86 arch without ME or proprietary BIOS? <dannym>ME-like thing (PSP) is still there <dannym>I can't drag them all the way at once ;) <dannym>It has an emulator and everything <dannym>So, situation slowly improving :) <dannym>You have no idea how many meetings that took to clear... I'm a pro at meetings now <g_bor[m]>I also have something similar. I started to have a look at the intel fsp. So far I found nothing that could not be done based on the public docs, but I have only checked the first part of fsp-t so far. <janneke>dannym: i was trying to remember in public here what i think you told me :-) <g_bor[m]>Also I have found it problematic to find datasheets for some AMD chipsets, so there might be some guesswork in having those started. I had better luck with intel chpisets in this regard. Do you expect that this will also be solved? <dannym>Confirming several weeks of guesswork here before it worked well enough that AMD got interested ;) <dannym>Now we have AMD employees helping, too <dannym>Like people doing the AMD evaluation boards; and the head of firmware at AMD <dannym>Hmm, for datasheets it depends on whether it's something that a competitor could use to undercut AMD and produce compatible chips <dannym>A lot of stuff that is not a competitive advanteage they just straight out publish <dannym>But for things where you need to know in detail how their chiplet interconnects work, those are under NDA <dannym>But it's easy enough to get access to those (took under a day for me to get cleared for that) <dannym>But they are a typical semiconductor company--default mode is "confidential"; it's hard work to make them work the other way, "open first" <dannym>Advantage is that they've supported coreboot (i.e. written code for coreboot) for AMD CPUs before. Now it's just a matter of prodding them to do it again... <dannym>Long term, there are people at AMD doing the hard work of convincing their streeting committee to just do silicon initialization in an open source project for ALL future cpus <dannym>I'll know more about the latter at the end of this month <dannym>janneke: I'll have a meeting with the security quickscan people tomorrow at 12:00 CET <OriansJ`>It'll be wonderful to see more blobless computers in the future. <janneke>dannym: ah, that's great; let me see if i can join <pder>stikonas: nice job on getting perl modules working. Is there a reason you are still using "tcc -ar" instead of ar from binutils in your latest perl branch? <pder>Oh yeah, nvm, perl is built before binutils. ***stikonas_ is now known as stikonas
<stikonas>pder: and apparently for binutils we still need to sort out libtool <stikonas>which is a bit tricky but hopefully possible <pder>ive been away, whats the issue with it? <stikonas>we think we should regenerate libtool files too <stikonas>then also somewhat depends on ar/ld, but we might be able to get away with setting it to tcc -ar and true <stikonas>also just in general need to familiarize with libtool <stikonas>pder: so with perl, I can run newer automake (at leats until it doesn't require newer autoconf) <pder>for the easy stuff to add to coreutils build, I know we need env and dirname. Anything else? <stikonas>newer autoconf now can find perl modules <stikonas>but later autom4te invocation gets stuck <pder>interesting. I remember a perl Configure script getting stuck as well- not sure if the same issue <stikonas>perl Configure script probably wouldn't support tcc anyway <stikonas>it might also be that some perl modules aren't fully working <pder>What do we need to generate the perl Configure script? <stikonas>pder: anyway, it's now pushed, so you can try building newer autoconf with ./configure <stikonas>especially since it's unlikely to work yet in our non-standard environment <pder>what autoconf should I try building? <pder>stikonas: would it be difficult to include Devel-Trace in the perl build? It could be useful for debugging these hangs- its similar to sh +x <pder>I tried building autoconf-2.57 and ran into that autom4te hang <stikonas>pder: I don't even see Devel-Trace in extention list in 5.6.2? <pder>Hmm, I am not sure on how old it is <pder>its probably not part of core perl. But a version of Devel::Trace existed in 1998 <stikonas>maybe can just drop it to perl's lib folder? <pder>possibly, I need to read up on how all this works <pder>apparently the perl debugger works with perl -d so hoping that will give some clues to the hang <stikonas>usually you are quite good at solving these issues <stikonas>(last time I guess it was that flushing issue in musl) <pder>So something is hanging in the following command after debugging /after/autoconf-2.57/bin/autom4te <pder>/after/bin/m4 --nesting-limit=1024 --fatal-warning --include=/after/autoconf-2.57/lib --include=/usr/local/share/autoconf --define=divert /after/autoconf-2.57/lib/m4sugar/m4sugar.m4 /after/autoconf-2.57/lib/m4sugar/m4sh.m4 /after/autoconf-2.57/lib/autoconf/autoconf.m4 </dev/null <pder>But I can run that command without issue outside of perl <pder>I tried creating a trivial perl script that does $result = `m4 command above` and this hangs <pder>But I can run the m4 command from the shell <pder>My guess is the issue is in perl and not m4. I was able to run the same command adjusting all of the paths to ones outside the chroot using the perl on my system <stikonas>but somehow autoconf was not happy with the produced file <pder>I tried running strace on our perl running the $result = `m4 command above` and it seems to be hanging on read(5, ) so maybe something related to pipes? <stikonas>pder: this perl is still built using old musl... <pder>Can't hurt, but I may have already tried that <pder>Yeah, I just rebuilt perl and still get the same issue <stikonas>pder: maybe can try to build perl with HAS_PIPE in config.h <pder>stikonas: so I tried extracting the perl-5.6.2 source and ran ./Configure -Dcc=tcc -des && make <pder>it builds miniperl but fails a bit later on. However copying miniperl over /after/bin/perl seems to fix that hanging error in autom4te <pder>so maybe you can compare what Configure does compared to your build? <pder>Note that paths will be wrong if you use Configure -des <pder>I should clarify that the miniperl build after running Configure was able to run my trivial $result = `m4 command`; <stikonas>if ours is hanging, it's almost surely compile options, so I guess we are hitting some stub due to missing defines in config.h <pder>Yeah, our current miniperl hangs on the trivial program that calls m4. The miniperl built by running Configure and make does not hang, so I was suggesting comparing the two different configs <stikonas>well, I have already tried adding HAS_PIPE... <stikonas>that might be necessary but is not sufficient <stikonas>but yeah, I guess we can add quite a few more HAS_* defines <stikonas>I already had to add a couple extra for autoconf <stikonas>anyway, all of this looks very promising <stikonas>so I think we'll soon have newer autoconf <stikonas>then we need to sort out libtool, which might be slightly annoying, but hopefully not too bad <stikonas>and then I think we'll be getting close to building gcc <Hagfish>i guess any step can throw in some weird hurdles, but yeah, it does sound like there's not much left before gcc <stikonas>well, this perl issue, get newer autoconf/automake (hopefully relatively easy), libtool, then a few trivial rebuilds and/or newer versions (gawk/sed) <stikonas>and then gcc, which will require some work to cleanup and fix, but it does build <stikonas>although, I don't know yet which libtool to target <stikonas>I guess depends on whether pder can figure out an issue with perl