IRC channel logs

<oriansj>stikonas: I agree removing the actual hardware from the bootstrap will be the biggest problem we face but I don't think the firmware bootstrap problem needs to be any harder than the Kernel bootstrap problem that builder-hex0 and fiwix beautifully solved.

<oriansj>for example: we have https://github.com/640-KB/GLaBIOS to pull from

<oriansj>and that is a FULL PC compatible BIOS that fits in 8KB

<oriansj>and there are projects like this: https://hackaday.com/2022/03/30/building-your-own-80386dx-isa-single-board-microcomputer/ and the FPGA 486; which suggests that the seeds of bootstrapped hardware are not that far off;

<oriansj>The grab some Rubylith tape and create some photolithographic masks bootstrapping step requires much more steps prior completed first; and incrementally solving the BIOS problem for even a single board would be a real gain.

<nikolar>and you don't even have to lay out the transistors by hand, just ask the toolchain to build you that fpga 486 :P

<oriansj>nikolar: fair enough; but that is the thing about bootstrapping. We don't need perfect now/first. Just an incremental improvement that allows others to move closer to the desired perfect goal.

<nikolar>and then you need someone who'll take all of the steps to prove that it can actually be done from scratch

<oriansj>nikolar: ideally multiple different people who don't like each other and have every reason to point out that the other is mistaken.

<nikolar>kek

<oriansj>and we need only one example of one board with one bios that one could bootstrap to break that "it can't be done" story and open the field up.

<aggi>oriansj: and you need someone neutral to review

<oriansj>aggi: or someone who wants to tear it apart.

<oriansj>like just some hateful monster who spits vile crap and tries every possible way to tear down what you made; then listen the actual technical content of it and if there are technical issues pointed out => address them. If no technical issues are raised => we passed with flying colors.

<oriansj>like if they say: just doing something like x crashes the compiler. Thank them for the bug report and address the bug which would cause that crash and then look for related bugs to address as well.

<oriansj>If there is no technical weakness nor problem pointed out; they are just throwing shades of personal preference and that can just be disregarded without comment.

<oriansj>Oh and before I forget; thank you aggi for your enhancements to TCC's usefulness in bootstrapping.

<aggi>oriansj: i haven't published yet

<aggi>my goal is a 100% pure tcc-toolchain supported system

<oriansj>I know but doing the work is hard and sometimes thankless and you deserve encouragement to continue the march.

<oriansj>just remember, when other people see your work, it is much easier for them to help you hit that goal.

<aggi>i don't want to cause too much noise and disturbance, and ideally can publish a _stable_ baseline

<aggi>and i got a few todos on my list which don't intersect with bootstrappable too

<oriansj>aggi: of course; who does decides and I look forward to it. (messy and chaos are just sometimes the growing pains of progress)

<aggi>for example, bearssl integration into the no-c++ system profile, because that's probably much easier to re-integrate with, once python/portage and perl/autotools are gone

<aggi>and finally, an i486-tcc-linux-musl.iso that is known good to work on almost any x86 system always, with all required development utilities contained

<aggi>the fact bootstrappable guarantees tcc-toolchain can be bootstrapped in compliance with acceptence criteria is a huge incentive to continue

<andydude>"solving the BIOS problem"?

<aggi>andydude: good question

<aggi>fyi, tcc-toolchain hasn't got 16bit real-mode assembly support

<aggi>binutils got, but those pull in a giant dependency graph of GNUism

<aggi>which isn't a licensing issue, it's a technical issue

<aggi>hence, please don't confuse my aversion towards GNU with GPL

<aggi>GPL is ok, it doesn't interfere with interests

<aggi>but i am hesitant, to accept a gigantic dependency graph to process 16bit real-mode assembly for BIOS code

<aggi>that's the circular-dependency issue, that i tried to introduce as a technical term (not political), that contradicts bootstrapping criteria

<aggi>as another side note, even when you approached 16bit systems that were known for free/open hardware SoC designs available

<oriansj>andydude: think how do you build a BIOS without having a BIOS

<aggi>in 16bit realm SDCC compile is commone, but that's written in, c++... circular dependency breaking clean bootstrapping

<andydude>So even seabios is useless, because tcc can't compile it?

<aggi>sdcc compiler

<aggi>andydude: simplified speaking, yes; but there's ore technical issues

<aggi>more

<oriansj>andydude: it is more like, it is helpful for later portability but not the first trusted BIOS sort of situation.

<andydude>what if seabios were just in hex0 format

<aggi>for their IBM PC, IBM considered the motorola mc68000 instead of Intel x86

<aggi>but this decision was made, in 1980s already

<aggi>so, what if, this question is obsolete

<aggi>x86 it is what we got

<aggi>and their business habits

<aggi>at Telekom universtity, they preferred to lecture 68k (20years ago, but this universtity closed in 2022)

<aggi>in the grand scheme of things, that's the whole Telekom/AT&T vs. BSD dispute

<aggi>wikipedia documents a few details, AT&T had insisted the boot-code parts remain proprietary to them

<aggi>GNU/binutils got a 16bit real-mode assembler, but it doesn't solve technical issues of bootstrapping from 16bit systems that are obsolete

<aggi>the 16bit systems (16bit address bus, 4/8bit ALU), never were sufficiently maintained

<aggi>i grew up behind iron curtain, when Intel insisted upon the COCOM and SCPA anti-competitive regulations

<aggi>that's history

<aggi>born in 1981, i didn't have a chance to study U880 clones in year 2000 anylonger, because at that time the former soviet/GDR semiconductor business was already defunct

<aggi>instead, they introduced the Intel/Altera propriatary malice into Telekom University

<andydude>I recently found this article https://www.righto.com/2022/11/how-8086-processors-microcode-engine.html

<andydude>it's fascinating to see how MUL is implemented with tons of ROLs

<andydude>I grew up on Mac, so I was exposed to 68k before x86

<andydude>everything I learned about booting x86 I learned from tianocore/edk2

<andydude>the only part of it I remember now is https://en.wikipedia.org/wiki/A20_line

<aggi>at Telekom University they lectured "digital circuit design", 68k assembly

<aggi>but this unversity closed 2022, indefinitely

<aggi>i don't miss it

<aggi>and their contracting and business habits

<aggi>drowning in proprieatary vendor malice

<Googulator>oh yes, the infamous Gate A20

<Googulator>had "fun" time handling that in builder-hex0

<Googulator>at least it's simplified by only supporting systems with BIOS-controlled Gate A20, or none at all (recent systems since Haswell/Bulldozer)

<andydude>Science is supposed to be about keeping an open mind, and data-driven hypothesis, not vendor hatred.

<aggi>just received a few more extortion letters from financial departent

<aggi>that intended to sponsor Intel FABs with 12billion cash

<aggi>Intel fab construction in Magdeburg, terminated indefinitely

<Googulator>well, if it's aimed at building fabs in Europe, I'm down for it, even if it's Intel

<Googulator>Only having high-end fabs in Taiwan is a huge global vulnerability

<aggi>i was fighting this tooth and nail

<aggi>although my influence is marginal

<Googulator>I wonder what's the best node today that can be fabbed outside Taiwan in existing facilities

<aggi>i wonder, why they didn't talk to Lattice Semi

<aggi>or, how could projects such as #bootstrappable do all their work, without 12billion subsidy cash

<aggi>whatabout, why would competetent telco management be necessary, another one, for the lulz

<aggi>but i don't want to drag anyone into this

<aggi>it's just, i received another extortion letter today

<aggi>that routes cash into "climate transformation fund" to sponsor Intel and Elon Musk with

<aggi>and a few other wish thinks

<aggi>and i am drowning in another pile of **** of government corruption

<andydude>I just watched ThePrimagen's video about the Automattic extortion ring

<aggi>imagine if there was competent management, to coordinate and route fundings to those who deserve it

<andydude>Automattic asked WP-Engine for $30 million, WP-Engine said no. Automattic proceeded to launch a smear campaign against WP-Engine.

<aggi>but, if there was cash dedicated to projects, a mob of me-too follows along with it

<aggi>if i could, all that i asked for, was a few credible accounting records made, by projects such as #bootstrappable

<aggi>that's how many man hours of work you invested

<aggi>that's the money you get

<aggi>but that's all past and long gone

<andydude>Sounds like a meritocracy

<andydude>Googulator: last time I checked the lowest common denominator is still 14nm

<aggi>j-core.org had considered another one

<aggi>they said, 100nm or something was affordable and available

<Googulator>andydude: are there any still operational 14nm fabs outside Taiwan that the world can fall back to in the event of a Chinese invasion?

<Googulator>because that's my main concern here

<aggi>Googulator: what's wrong with 100nm?

<aggi>2024-09-27 14:49:55 <aggi> Googulator: what's wrong with 100nm?

<andydude> https://www.asml.com/en/products/euv-lithography-systems

<aggi>to my knowledge j-core.org were the last free/opensource project to approach it

<aggi>but their turtle board never went into production

<andydude>Googulator: ASML will send you a shipping container with a fab in it

<andydude>pretty sure that counts as "outside Taiwan"

<aggi>was 100nm manufacturing available "outside Taiwan"?

<Googulator>that's good to know :) I was thinking, if panic buttons are pressed, humanity loses all relevant silicon fab capability for decades - but I guess that's not entirely the case

<andydude>5nm might be lost to history, but we'll still have 14nm

<Googulator>14nm is good enough to restart from, at least - 100nm not so much

<aggi>Googulator: j-core.org didn't consider any of the modern manufacturing

<aggi>they said, 100nm or something was cheap and available, for free/open hardware SoC

<aggi>and, hell yes, an i386 SMP clocked to 500MHz or something, that would be awesome

<Googulator>I'm not talking about for open hardware development, but rather, a node the world can fall back to if Taiwan is invaded

<aggi>Googulator: that's the former soviet semiconductors, that detonated in 1986 when Chernobyl went boom

<aggi>"tell me, you're a nuclear engineer such as myself, how does an RBMK reactor explode?"

<andydude>huh ASML is headquartered in the Netherlands

<aggi>andydude: the Zeiss optics manufacturer is headquarter in Thuringia, a few miles away from my home

<aggi>however, i didn't study physics and laser optics

<aggi>i merely follow news

<aggi>the Z80 clone manufacturing, was located in Erfurt city, Thuringia

<aggi>that's former GDR, a little distant to Chernobyl and Belarus and their facilities

<andydude>I think the closest fab to me is GlobalFoundries in NY

<andydude>Where do I go for 100nm?

<aggi>andydude: ask j-core.org

<oriansj>well 230nm is good enough for a 64bit processor and 4+GB of RAM

<aggi>that was the last known free/open GPL-compliant project i knew

<oriansj>and if one isn't requiring high yields or fast production; we could design a bootstrappable lithography lab for under $10K

<oriansj>The initial steps might be annoying if one expects to bootstrap all of the chips in that lithography lab first too

<oriansj>and is purchased silicon wafer blanks and chemical acceptable might become a question if one wants perfect and complete knowledge of every detail of the process.

<oriansj>but we can deal with that later as we have https://libresilicon.com/ giving a process good enough for 32bit CPUs (or slow 64bit CPUs)

<Googulator>depends on whether it's possible to hide a backdoor in blank wafers or chemicals

<oriansj>Googulator: depends if we are worried about defending against nanoscale assemblers

<andydude>Pedagogy is more viral than Security

<andydude>imho

<oriansj>andydude: well long term incremental projects can appear to be quite insane from the outside; but the results are thus far exactly as specified. #bootstrappable will just slowly grow until the answer to the question of how to go from nothing to a fully complete working computer with software is completely answered to the level desired by any individual. With the various forks and offshots to address various wants and needs; which make

<oriansj>the community larger and richer in potential solutions to problems that may arise.

<andydude>aggi: I understand 0% of the words on that website

<aggi>andydude: j-core.org? they implemented a 100% free/open hardware SoC GPL compliant, but they're not compliant with bootstrapping criteria

<andydude>what is SuperH

<aggi>andydude: a non-x86 architecture, they had chosen because it's supported by GNU gcc/binutils

<aggi>to my understanding, they got 100% free/open non-patent incumbered schematics for hardware and tooling ready to deploy it

<andydude>Why not RiscV?

<aggi>although they were whining about Xilinx

<andydude>what is Xilinx?

<aggi>andydude: because RISC-V isn't fully supported by GNU, and you would need most recent kernels/toolchains

<aggi>andydude: Xilinx is an AMD subsidiary, similar to Altera that is married to Intel

<aggi>for hardware development

<aggi>besides, a few hackers in the realm of j-core too bothered with tcc-toolchain, that's how they caught my attention

<aggi>i am not involved with disputes over GPLv3, although it seems a big deal among them

<aggi>don't ask me why that is

<aggi>a guy named Rob Langley was the author of busybox, but chose to fork it into toybox, for aboriginal linux distribtion of his

<aggi>which wasn't maintained for a decade since then

<aggi>in practice, there's no way around x86, although it sucks

<aggi>that's why, j-core project has less relevance than i would appreciate

<aggi>j-core.org wanted both, free/open hardware and software, chose SuperH instead of x86, and failed

<andydude>it sounds like they succeeded in a goal no one cares about

<aggi>except for the fact, year 2023 german governent intended to dump 12billion of cash of subsidies into Intel Fabs

<aggi>how much money had j-core.org needed to do their thing?

<aggi>they had published some hacker talks, they could spawn some hardware manufacturing on "deprecated" equipment, for a few thousands of cash

<aggi>but their turtle board never was available, although it was some precious thing

<aggi>it didn't fit into bootstrappable criteria 100%, but at least they were 100% GPL compliant

<aggi>and they said, it was a few thousand cash required only, not billions of it

<aggi>that's why, i got mad over the Intel subsisides in Magdeburg, who announced they'll not establish their Fabs, few days ago

<aggi>VICTORY!~

<aggi>yet, why talk to me?

<aggi>ACTION has to refrain diverting into politics

<aggi>because, i had supported some Intel deals made, if they had not ignored the free/open people including the ones here

<andydude> https://buildd.debian.org/stats/graph-week.png

<andydude>aide from a 3% difference, riscv looks fully supported to me

IRC channel logs

2024-09-27.log