From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremiah@pdp10.guru Subject: Re: Preparing the reduced bootstrap tarballs Date: Wed, 21 Nov 2018 03:36:39 +0000 Message-ID: <874lcb14qg.fsf@ITSx01.pdp10.guru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47164) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gPJJq-000569-2s for guix-devel@gnu.org; Tue, 20 Nov 2018 22:36:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gPJJm-0008MP-Ue for guix-devel@gnu.org; Tue, 20 Nov 2018 22:36:50 -0500 Received: from itsx01.pdp10.guru ([74.207.247.251]:38502 helo=itsx01) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gPJJm-0008Ft-OJ for guix-devel@gnu.org; Tue, 20 Nov 2018 22:36:46 -0500 List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: rekado@elephly.net, samplet@ngyro.com Cc: guix-devel@gnu.org > Now that=E2=80=99s a project for a free hardware design that I=E2=80=99d = happily work > on :) Sweet > Reading and transmitting of the bitstream can be done in hardware alone > (shift register, MUX, photoresistors, =E2=80=A6), though I=E2=80=99d need= to know what > kind of interface there is on the receiving side. Just flash memory / > TTL shift register? Well ultimately that would need to be a memory bus that is connected to their TTL DRAM (64KB chips) or TTL SRAM (so we wouldn't have to worry about memory refresh or other sort of issues like that) and setting the memory address block starting from Zero until end of deck. The Memory is Big Endian Bit, Byte and Word Addressed. The number address pins needs to be atleast 9 (otherwise the bootstrap binaries would exceed the address space the reader could write to) and not to exceed 64 (As I don't plan on implementing a 128bit ALU with Floating point and Vector instructions needed to comply with the 128bit version of the spec). I am planning on having the memory data bus to be 8bits wide as all instructions and datatypes are multiples of 8bits. I can provide a clock signal for when the next value is to be loaded or a line for you to directly drive the memory chips. Or we could go the uart route and simply leverage a classic serial connector. > I?ve thought about this a bit. Would it be possible to go even more > mechanical, and implement the SPI protocol in switches toggled by holes > cut in some kind of insulating tape? Well that mechanical aspect would be what you would expect in punched cards or paper tape (I was planning on doing a paper tape reader to allow easier manual inspection of outputs, inputs and binaries) > You could have a couple of steel > balls (bearings?) balanced on top of each other, connected to a circuit > using brushes or springs. Then, you place the tape in between the > bearings. When there?s a hole in the insulating tape, they make > contact, and when there is no hole, no contact. Yep, classical through-hole reader technology. Not as reliable as optical sensors but much more low tech and no room for anyone to insert anything funny with the sensors. > Then, you have a row of > holes for the SPI clock, and a row of holes for the SPI data. All you > would have to do is hook up the right voltage to it, and you could write > to a flash ROM by pulling manually punched tape through it. (You could > use a crank or motor if the timing needs to be more precise.) Well you could have a hole aligned with the values being read (say a 9th bit) which would trigger a clock pulse to indicate reading of the next byte. > Then, you could take an x200 and setup the bootrom to be whatever you > wanted with no software whatsoever. Not possible, there is a 700+KB microcode blob in that CPU, without which the CPU fails to power on for more than 10 clock cycles. > If you adjusted stage0 to set up a > ?cache-as-RAM? environment (like they do in coreboot), you could do > quite a bit of manoeuvring before having to initialize RAM. Well the 4MB of space (or 6MB if you have Penryn chip) is more than enough to bootstrap cc_x86 and be able to compile a self-hosting C compiler > That is, > you could probably set up a tiny Scheme environment and do more hardware > initialization from there. Well the hardware initialization isn't a concern as that is currently well documented in libreboot's code. The hard part is those computers are only going to be working for a few more years before tin whiskers kill the whole lot of them (the transistion to lead-free solder occurred during that time) and then we will have a working solution to hardware that is no longer available, no longer works and we can't build more that will exactly match those specs without considerable effort. > Obviously all of this would be easier on a simpler computer, but then > presumably you have to move from a simpler computer to a more > complicated computer at some point (depending on your needs). I assume a 64bit processor with 16+GB of memory, a SATA interface and a network interface should be sufficiently complicated to bootstrap everything we will need to conern ourselves with in the next couple years. (We can always enhance a design of our own making) The Low end will be a 16bit processor with only 64KB of RAM and will probably require ugly coding to fit some of the programs in that address si= ze. > The nice > thing about booting the x200 as a simple computer is that you can just > expand its boundaries until it is full-featured. One needs to be precise by what one means by full-featured. Would you consider Minix or Linux 1.0 a full-featured kernel? Would the ability to build GCC and guile be considered full-featured enough? Because I can build productive environments down to a hex0-monitor in a few hundred bytes of total memory. > Sorry for derailing a bit, I just wanted to share some idle thoughts. I actively encourage alternative perspectives and I love being told how I can do this better. I look forward to more ideas and suggestions from you on this subject later ^_^ Just an open reminder our #bootstrappable channel is always looking for people intersted in these sorts of topics and we love hearing about what you have created in this regard. -Jeremiah