IRC channel logs
2024-01-24.log
back to list of logs
<gnucode>sneek: later tell damo22 Did you ever get the Hurd to run on a T410 ? <damo22>sneek: later tell gnucode I don't have a T410, i am working on HP T620 which is an AMD board, see my latest mail to the list <sneek>damo22, gnucode says: Did you ever get the Hurd to run on a T410 ? <damo22>i added ACPI >= v2.0 support to gnumach :D <damo22>if you want some background on what happened with gitea <damo22>damn, t620 crashes again, but at least i get a log now, except its only visible for a split second <damo22>it crashes at timer calibration.... CRASH <damo22>it has about 6-7 clock interrupts <damo22>the second one is not defined in the vectors so maybe its triggering an interrupt with no vector and crashing? <anatoly>solid_black: I wonder why does the indented list of packages in bootstrap.sh contain duplicates from the rest of the list? <solid_black>basically the indented list is things that I wanted to get building (and mostly succeeded in it), in the order that we need for e.g. bootstrapping the 'hurd' package <solid_black>(but that should not cause any issues, abuild skips already-built packages) <anatoly>I'd keept he original list as comment and build the current one in a clean manner :-) <solid_black>sure, please feel free to submit PRs / patches / whatever <anatoly>Yep, I'd guess that it skips, otherwise you wouldm't leave it like this :-) <solid_black>I'm bootstraping the whole thing again on a different host right now, and will try booting it <solid_black>still need grub from elsewhere, since ours doesn't yet build <anatoly>So it will die on the grub from the list <anatoly>So it will die on the grub from the list? <anatoly>I prepped simple Containerfile to run the build process <anatoly>I guess cross-building will stay for some time? <solid_black>I think we're probably going to want to use Gitea/Forgejo Actions, thir little GitHub actions Clone? <solid_black>also we're going to want to detect changed APKBUILD's and only rebuild those, this is what upstream Alpine does <solid_black>yeah, we'll keep bootstrapping for now probably, but should switch to native builds once the system boots & abuild works inside <anatoly>Yep, I will look at their gitlab setup to see how they deal with it <anatoly>I wa thinking to prepapare a container with cross-compiler pre-built, basically up to the step of building that list of packages <anatoly>I was thinking to prepapare a container with cross-compiler pre-built, basically up to the step of building that list of packages <solid_black>next thing, I think gnucode is going to run Gitea/Forgejo on his Guix GNU/Linux machine? So for native builds, we'll have to make it spawn qemu <solid_black>speaking of providing a container with a cross toolchain pre-built: I think this would be a great thing to do even unrelated to this distro project <solid_black>just so that people who may not even know much about Hurd are able to easily test building their software for the Hurd in their CI <solid_black>I mean, just an easily usable Docker / OCI image with Debian or something, with a Hurd cross-toolchain installed, so they can just run their builds on CI without having to know anything about the Hurd or how to set it up <solid_black>ok no, my build is not broken, it's just that I didn't install my signing key into the system-wide trusted keys dir <anatoly>it is still building last few package <anatoly>I should've ran it on a faster machine <solid_black>fwiw, x86_64-hurd bootstrap currently fails at glibc, because we're using the 2.38 release and there have been incompatible changes to gnumach that require matching glibc updates <solid_black>I could backport the patches, but let's just wait for the 2.39 release which should happen in a few days <solid_black>and I'll bump the symbol version to GLIBC_2.39 too, so please don't publish any images until then <solid_black>after that, we could totally apply my aarch64 patches and builf an aarch64-gnu userland :) <anatoly>sure, I had no plans, I will first cleanup Containerfile, probably will do fork of your fork and will commit on top of hurd branch <anatoly>Nope, nothing came to my mind do far <solid_black>do you have experience with bare metal arm/aarch64 hacking? <anatoly>I mean as a test run cross-build on arm, probably won't be faster than in qemu on fast x86 :-D <solid_black>yes, but it's important that it works on real arm boards and not just in qemu, 'cause as I understand it there's lots and lots of variation, and qemu only implements a fraction of it <solid_black>also people who own arm boards are more likely to have experience with the low level details of it <solid_black>I don't think "hurd" should be melded into another word? I'd rather have Something Hurd than Somethinghurd <anatoly>It is mt. Matterhorn so I played with the word :-) <anatoly>some people buy arm-boards to blink with a led few times and then collect dust with it :-D <anatoly>Aoraki Hurd? aka Mount Cook Hurd :-) <solid_black>naming things is truly the hardest problem in computer science :) <solid_black>of the things suggested so far, I like Everest Hurd most; if only it wasn't for Everest Linux :( <anatoly>Etna Hurd, trully belissimo Hurd distro <solid_black>so, you should have lots of packages in ~/packages/main/x86-hurd/ <solid_black>and the cross toolchain packages in ~/packages/main/x86_64/ <anatoly>Btw, regarding the patch for /usr/share/abuild/functions.sh, would pre-building patched version of abuild package for linux be the solution? So as a separate process build it for alpine linux witht he patch applied and then put it into a repo which is added when bootstrapping hurd? <solid_black>that makes sense, yes; I already apply the same patch when building abuild for the target system <anatoly>solid_black: which packages do you choose when you do apk add, I guess it should be all because they are a part of base system? <solid_black>it depends on what you want? but the base system needs something like hurd, openrc, busybox to even boot <solid_black>(this is theoretical, I haven't tried booting it just yet) <solid_black>alpine-base depends on busybox and openrc, so you could narrow that down to gnumach, hurd, alpine-base <anatoly>I will try it at some point but I will concentrate on the building tools in preparation for CI <anatoly>solid_black: can we take alpine qemu image, keep grub and replace the rest with packages for hurd? <solid_black>we can run grub-install from anywhere (Debian for example) <solid_black>eventually we'll want to build our own grub of course <solid_black>fwiw there are other scripts in scripts/ that build images <damo22>even with these three commits, my t620 board still crashes when you enable interrupts to calibrate the timer: <damo22>* e88639b0 (HEAD -> fix-ioapic, zam/fix-ioapic) apic: Support 48 interrupts and up to two IOAPICs <damo22>* d4388546 ACPI: Support XSDT (ACPI >= v2.0) <damo22>* fd0958d5 ioapic: Remove IMCR toggle <damo22>i know everyone here has their own hurd projects, but it would be nice if someone helps with gnumach for more hardware support <damo22>acpi v2 is a blocker for most modern hw, so i pushed hard on that one <damo22>but theres still problems to fix <solid_black>I'd love to, but I have zero idea about anything hardware related, sorry <damo22>i had very little knowledge of that either a few years ago <solid_black>oh, perhaps you could share which resources you found useful to learn this stuff? <damo22>i use the source like a reference <damo22>since it implements the firmware needed to bring up the board, you can see what stuff is exposed from a board port <damo22>netbsd kernel source is useful to study for ideas too <damo22>if you want to see some particular quirk of hardware, use the linux source <janneke>also, rumpdisk enabled me to install the hurd on a T60 <damo22>i have hurd booting in PIC mode on an HP T620 <damo22>but to make the NIC work, i need APIC mode <damo22>solid_black: you could find a board that you want to use as a server, that has an existing coreboot port, buy a usb->serial dongle and connect it up to your dev machine via com0 and try to make it boot hurd <solid_black>I know I'm the one who's always saying that one learns things by trying to do something and seeing what breaks, but this never seemed to work for me for the hardware part <damo22>software engineering is useless without hardware <solid_black>but it looks like I'm just missing some fundamental understanding of how things fit together <damo22>you need to know hardware 101, basically how to wire up a serial port <solid_black>something I've observed others have natural understanding of <solid_black>yes, I don't even know what a serial port is, other than that it's a port that you could connect to and maybe get output from (and a console on) <damo22>in its simplest form, it has 2 wires, tx and rx <solid_black>does it send bits? bytes? does one vary electricity? (current?) <damo22>you just need to connect tx -> rx on each side <damo22>each wire has a node that is labelled, and the signal passing through it is called something <damo22>so on one side of a serial connection, there are TX and RX endpoints <damo22>one of them transmits data, one of them receives data <damo22>to make a serial connection between two pcs, you just cross over the TX -> RX on each side <damo22>which is usually done with a "null modem" cable that plugs into a db-9 jack on each side <solid_black>I don't think I understand what any of that means, sorry :( <youpi>solid_black: on side puts e.g. 5V on the wire <youpi>the other side can measure that <youpi>that's how you can transmit a 1 <youpi>and you can use e.g. 0V or -5V to transmit a 0 <youpi>then both sides "just" need to agree on the speed at which 0s and 1s god <solid_black>is 5V an actual value that is commonly used, or just a placeholder? <youpi>it's an actual value for some of the existing standards <youpi>also, you need a start sequence <youpi>so that the receive knows when it starts <solid_black>is there some acknowlegdement / "wait, I didn't get it, send it again" mechanism, like in TCP? <youpi>the serial port doesn't implement that <youpi>it's up to the application to handle that <solid_black>also, and this might be a dump question, but how do you put some voltage onto the wire? I imagined voltage is something that you can have *between* two pins in a single circuit <damo22>there is a ground wire on each side <youpi>there is also a ground pin, yes <solid_black>so is there then a (commonly used) higher level protocol on top that lets you reliably transmit stuff? <youpi>for a dumb terminal that just shows the text, you don't care <solid_black>so when I say console=com0, is that higher level protocol getting used? <youpi>you might get glitches, but for small cables that's rare enough <youpi>that's not reliable for transmitting data of course, but then you'd use specialized tools <solid_black>so this seems to be a mechanism for transferring individual bits so far <youpi>the serial port will send 7 or 8 bits at a time, with the start squence before it, and possible a parity bit after <youpi>cadences at the configured bps (or baud) <solid_black>right, I've heard the term "baud rate" thrown around serial ports <damo22>its the number of bits per second being sent <youpi>which is not the obtained bit per second of the transfer, since the start sequence and the parity bits also take some time <youpi>see the B* macros: B9600, B115200 etc. <solid_black>ok, so 38400 bits per second, including special ones like partity bits, so that would be in the order of 4k bytes per second? <youpi>(your questions are really not dumb, they're right on the spot) <youpi>that's the kind of speed you had with 56k modems :) <damo22>it would be very helpful if this becomes part of your knowledge so we can collaborate on gnumach <youpi>my first Internet connection was at 2400 baud <solid_black>how is this related to modems? do modems use the same serial ports? <youpi>they're connected through a serial cable yes <youpi>the modem itself also sends the bits on the telephone line <youpi>it's not just +5V/-5V, there is modulation <solid_black>what else are serial ports/cables used for? I've only heard about them being used for getting a console basically so far <youpi>but apart from the electric details, the principle is the same <damo22>many industrial peripherals use serial ports <solid_black>that modem sits in between a computer and the telephone line I understand, yes <solid_black>I'm not *that* young, I remember a time where I could not use my granddad's PC when my grandma was talking on the phone :D <solid_black>ok, eeprom is also the term I've heard somewhere, perhaps related to flashing indeed <damo22>probably industrial facilities use serial ports to interconnect heavy machinery with a central pc <solid_black>how does using a serial port connected to a modem to access Internet compare to using an Ethernet connection? <damo22>in Australia, dial up modem is better <solid_black>what is the interface called (instead of eth0)? is there a local network, do you have peers? is there a protocol used between the oc and the modem, for ensuring integrity? <youpi>solid_black: serial ports are *way* simpler than ethernet <youpi>between the pc and the modem there is just the parity bit that checks some integrity, but that's very weak <solid_black>hm, so I imagine you need _an ethernet card_ (& drivers for it / netdde) to connect via ethernet? <youpi>again, we use higher-level protocols for checksums <youpi>modems and serial ports have a weak parity bit <youpi>that's fine enough for displaying stuff on a terminal <youpi>for sending data, you'll add checksums <youpi>solid_black: to connect via ethernet you need an ethernet card indeed <youpi>to connect to the internet via a modem, ethernet is not involed, you use ppp <damo22>bidirectional serial connection needs just a pair of pre-negotiated speeds and 3 wires... <youpi>which puts the ip packet in a ppp frame (basically just encodes the bytes, managing the limitation to 7 bit if any) <solid_black>aha, so ppp is a "physical" level protocol, just like ethernet? but simpler? <youpi>you configure ppp to use the serial port to send the data of the ppp frame <youpi>and that goes over the modem <youpi>and just below the network layer <solid_black>and you're only connected to the modem on the other side, there are no peers? <solid_black>what is your local network then, and how do you get an IP address assigned? <damo22>as an example, my T620 is connected with a crossover serial cable to my laptops serial port, and i set both speeds to 115200, and when i type into a minicom console configured for the right serial port, the text appears in the other side if its listening <youpi>solid_black: on the other side you have the same <youpi>another modem, another serial cable, and another pc that does the converse <youpi>unpacking the ppp frame, etc. <youpi>for ip assignation: it's part of the ppp protocol, there is a negociation step when you connect <youpi>(which is still used nowadays with dsl and even ftth) <damo22>solid_black: if you want to port an ARM board <damo22>using your new toolchain, you can use a serial port <solid_black>alright, another dumb question: how do I even know if I have a serial port? <solid_black>can it look like anything, as long as there are two wires? <damo22>your phone has lots of them, bluetooth is basically a serial port over the air <solid_black>I've also heard something about USB ports and headphone jacks being used as serial ports? <youpi>solid_black: you'll want 3 wires, for the ground and both directions <youpi>it's a "bit" more complex, but basically it's a serial port, yes <youpi>as for proper serial port (as in recognized by e.g. a modem), it's the DB-9 or DB-25 plugs <solid_black>ok, there must be a difference between "a serial port" (as in, some sort of a port that is serial, not parallel), and the specific sort of a serial port that we were talking about? is there a specific name for the latter? <youpi>you'll easily find usb-to-db-9 converters <damo22>also, if you dig into coreboot, you will find that most boards that have native serial ports are provided by a "super i/o" chip, and these have pins you can use directly <youpi>sometimes the pin are not plugged to an actual db-9 plug <solid_black>I don't think I understand what that means either -- "super i/o chip"? "pins you can use directly"? <youpi>super-i/O is just that that chip integrates various i/o interfaces <youpi>so you can just plug to the pins of the chip that provides the serial port <solid_black>also: do these two (or three?) wires plug directly onto a pin on the CPU? <youpi>it's a separate chip on the board <damo22>now you are asking more hardware questions! <solid_black>I imagine I need to do some x86 in/out from software; what does that actually do? <youpi>yes, you'd out(0x378) to send a byte on the serial port <youpi>which makes the cpu write the byte on the data bus of the board <youpi>and the i/o chip catches it, and sends it on the serial port <youpi>between the cpu and the rest of the board yes <youpi>it's kinda special with x86 but that's the idea <youpi>(on most hardware it's just an address in "memory" which happens not to be actual memory, but the i/o chip) <youpi>ah, I wrote 378 above, I meant 3f8 yes <youpi>378 would be the parallel port :) <solid_black>my (probably naive, please correct me) understanding was that "x86" (or IA-32 or whatever) is the ISA of the CPU, and then there's a technically orthogonal thing called "IBM PC compatible" (which gnumach calls "at"?) which specifies the "platform", including at which addresses devices are memory-mapped, and probably things like this 0x378 <youpi>(it's not naive at all, most people don't understand it :) ) <youpi>the in/out instructions in the intel manual don't specify anything about the meaning of the address <solid_black>is this data bus itself standardized? (between different IBM PC compatibles? different CPU architectures? different "platforms"?) <youpi>e.g. you have the PCI standard, but the CPU usually doesn't directly speak PCI <youpi>so most often you have a chip on the board that connects the cpu to the rest of the world (pci, pci-x etc.) <youpi>but from a programmatic point of view on the cpu, you don't care about that interconnexion, you just use in/out <youpi>and the chip handles routing to the proper device <youpi>ooooh, that good old document, still there around :D <solid_black>how does memory mapped I/O work? I think I read somewhere that there is a single memory bus, which all the memory-mapped devices (including the RAM? can there be several instances of the RAM btw?) are connected to, and each devices only responds to requests about addresses that it "knows" it's mapped to <youpi>it's the board that manages the mapping <solid_black>does the CPU itself (as opposed to software running on it) know whether some address is memory-mapped or not? <youpi>whatever is around the cpu :) <youpi>sometimes you had two northbridge and southbridge chips <youpi>to separate PCI, ISA, AGP, whatever <youpi>but from the point of view of the cpu it's just "the mainboard" <solid_black>ok then, how come prefetching / speculative execution does not mess with mmio? <youpi>if you don't configure the cpu properly <youpi>you have to tell e.g. in the page table "no cache" <solid_black>so the cpu really has no idea on its own, the software must do it <youpi>the software knows what is proper ram from the bios <youpi>the bios being very knowledged how to ask that from the board <solid_black>is bios like efi boot services or runtime services? iow, does it stay resident after boot? <youpi>you have some int service in real mode, and bios32 in protected mode <damo22>bios in terms of coreboot has two main phases: bringup of the mainboard, and "payload" or something to hand off execution to <solid_black>"where" is it? is it just some code that the cpu jumps to (via an interrupt handler?), or some special magic? <solid_black>does the kernel have to be careful to not touch the physical pages used by that bios <youpi>the int 0x16 is plugged to it, yes <youpi>the vga, network, etc. cards can also have some rom between 0xc0000 and 0xeffff <solid_black>can userland just raise any interrupt? it certainly can raise int 0x80; what prevents it from raising 0x16? <youpi>biosmem: 0000000000000f0000:000000000000100000, reserved <damo22>0xb8000 has the text frame buffer <youpi>biosmem is just the gnumach name for parsing e820 <youpi>solid_black: I don't remember exactly, but most probably it's the int table that says from which rings an interrupt can be called <damo22>heres a real question : Why would a board crash if you enable interrupts but the timer interrupt fires 6 or 7 times first? <youpi>depends what you call "crash" <youpi>do you have the reason for the reboot? <youpi>"reboot" is normally a cpu thing <youpi>that can be due to stack overflow <damo22>hmm, i am pretty sure i added 48 interrupt vectors for both IOAPICs <damo22>it faults just as i am calibrating the lapic timer <damo22>maybe the timer expires and calls an invalid interrupt? <damo22>does this work on AMD x86? asm volatile ("pause" : : : "memory") <youpi>pause is a quite old additions, so I guess it should be ok <damo22>one of the lines that is interesting is LAPIC_NMI ACPI_ID=ff flags=0005 lint=01 <damo22>the rest are supported by gnumach <damo22>but i dont know what that one is for <damo22>non-maskable interrupt, not sure if its required to boot the machine <saravia`>Hi colleges <-- I was lerning over 6 years for come to here ... I think, I'm ready for use hurd <saravia`>u_u... one question, one version of gnu distro which works with hurd fisical? <etno>saravia`: hi! I am rather new here, but I think that the question is not so much about the disto, but rather about the hardware. It would seem that most people laying around here have Hurd working with Thinkpad machines. Although qemu is the big contender. <sneek>Welcome back gnucode, you have 1 message! <sneek>gnucode, damo22 says: I don't have a T410, i am working on HP T620 which is an AMD board, see my latest mail to the list <gnucode>That's a really old Thinkpad that some Hurd people use in real hardware <gnucode>I am trying to install the Hurd in a T410. The installer boots and is able to access the internet from the ethernet port. <etno>gnucode: at some point, I may buy such a machine if I get tired of trying :-) So far, I still have hope with my spare laptop. And there is a chance that I fix stuff while fighting. <etno>I believe I solved an FPU initialization issue already 🎉 <gnucode>etno: I have the Hurd running in a T43. That machine is really pretty stable. :) <damo22>saravia``: if you want hurd on real hardware (not qemu) there are limited choices at the moment <anatoly>I remember running it on an asus eeepc 90x series netbook loong time ago :-) <gnucode>damo22: We should probably have a list of machines that you can buy that people run the Hurd on. And we should add it to the manual/ wiki <damo22>i dont think that is so useful because the list should be very long <damo22>and we want to encourage people to try new ones <gnucode>sneek later tell solid_black I have a very very simple website set up with emacs' org-mode <gnucode>damo22: I think that list would still be useful for people to know.