Live data from Hacker News

68 Katy – 68000 Linux on a Solderless Breadboard

bigmessowires.com

1–10 of 40 posts

Re: 68 Katy – 68000 Linux on a Solderless Breadboard

#2
To clarify the article's text, uClinux is not (just) a distribution, but a version of the kernel that rus on MMU-less hardware.

The full Linux kernel does have m68k support, but it needs a 68020 or better CPU. This gets you real memory protection, VM etc.

Re: 68 Katy – 68000 Linux on a Solderless Breadboard

#3
That is seriously good work and an amazing DIY project!

I remember when I was a kid, trying to just get a pre-made Linux-image boot on my Amiga. I had a 68020 CPU, but due to no MMU and no FPU (neither being "normal" accessories at the time) I just couldn't get the thing to boot at all. Later, when I acquired a 68030 CPU, I at least had the MMU covered, but I was still a kid and didn't have a budget for a FPU. So I still couldn't get things booting.

Granted, back then I wouldn't know my way around Unix if I had been handed a booting system, but I was curious about this "Linux" thing which was supposed to be superior if you wanted to run BBSes, multitask and do stuff like that.

But despite all those resources I had, I couldn't get things going. And here this guy gets Linux running on a home-built 68008-based system of all things.

That is seriously cool!

Edit: I may be mixing up my 68k models. I also had a plain 68000 earlier, which was definitely not up for the task. If I'm mixing things up, please forgive me. It was a long time ago :)

Re: 68 Katy – 68000 Linux on a Solderless Breadboard

#4
The article spoke about a suspected memory leak in setenv(), I assume it uses uClibc but it was a bit light on the details (no source code links in the article, that I could find).

I dug up this link: http://git.uclibc.org/uClibc/tree/libc/stdlib/setenv.c?id=30... which I believe is the relevant function.

Unsurprisingly for this level of library code, it's not 100% super-obvious or easy to understand. Especially the details on the in-library memory management are unknown to me, but I thought it might be interesting.

Re: 68 Katy – 68000 Linux on a Solderless Breadboard

#5
post #3

That is seriously good work and an amazing DIY project! I remember when I was a kid, trying to just get a pre-made Linux-image boot on my Amiga. I had a 68020 CPU, but due to no MMU and no FPU (neither being "normal" accessories at the time) I just couldn't get the thing to boot at all. Later, when I acquired a 68030 CPU, I at least had the MMU covered, but I was still a kid and didn't have a budget for a FPU. So I s…

That's peculiar that a pre-baked linux distro for Amiga would require an FPU to boot. Off the top of my head I can't think why that would be :S

Re: 68 Katy – 68000 Linux on a Solderless Breadboard

#6
Steve of BMOW has done several amazing hardware projects including a homemade CPU from logic chips and CLPDs, Mac floppy emulators, and more. Rather than link them here, browse the links on his sidebar and read the descriptions of each project.

>Schematics? Forget it. Everything was built incrementally, one wire at a time, while staring at chip datasheets. It’s an organic creation.

Yeah, that's real hardware hacking right there.

Re: 68 Katy – 68000 Linux on a Solderless Breadboard

#8
post #4

The article spoke about a suspected memory leak in setenv(), I assume it uses uClibc but it was a bit light on the details (no source code links in the article, that I could find). I dug up this link: http://git.uclibc.org/uClibc/tree/libc/stdlib/setenv.c?id=30... which I believe is the relevant function. Unsurprisingly for this level of library code, it's not 100% super-obvious or easy to understand. Especially the…

> Unsurprisingly for this level of library code, it's not 100% super-obvious or easy to understand.

Sounds like you visit the wrong libraries. Try plan9's

Re: 68 Katy – 68000 Linux on a Solderless Breadboard

#9
post #4

The article spoke about a suspected memory leak in setenv(), I assume it uses uClibc but it was a bit light on the details (no source code links in the article, that I could find). I dug up this link: http://git.uclibc.org/uClibc/tree/libc/stdlib/setenv.c?id=30... which I believe is the relevant function. Unsurprisingly for this level of library code, it's not 100% super-obvious or easy to understand. Especially the…

The whole putenv()/setenv()/unsetenv()/environ API is inconsistent hack that is essentially impossible to implement without introducing memory leak in at least one of these operations without introducing some complex additional book keeping. The good news is that there aren't that many reasons to actually use these functions, as only reasonable usecase for modifying environment is changing environment of spawned subprocesses, which can be done by constructing your own environ and passing it as envp argument to exec().

On the other hand the memory leak is mostly negligible and one would assume that for reasonable program that calls setenv (ie. does not call setenv in a loop) probably smaller than cost of the aforementioned extra book keeping.

Post reply on HN