31–40 of 62 posts
Only to make it even funnier by the glazed look in my girlfriends eyes when I was trying to explain whats so funny about guy bootstrapping a 32bit OS on a 8bit micro controller.
I mean the idea of emulating 32bit OS on a 8bit machine is not something too ridiculous on its own. But the setup he used. Oh my god. Must stop trying to comprehend this madness.
Kudos to Dmitry.
The linked blog post misses the interesting bits. Yes, it boots Ubuntu (slowly) via an ARM emulator written for AVR. That's just software. What struck me is that he wrote a controller for an 8 bit FPM DRAM bus instead of just using a big SRAM. That's surprising, and not at all trivial to do over a bunch of GPIO pins.
It can't be that hard; I once bitbanged a 30 pin SIMM on a PIC with an interrupt to trigger the refresh. The 30 pin SIMM is 16MB and easy to wire (0.1" pitch). 16 MB of SRAM is probably going to be TSOP or worse, and probably in multiple packages. The multiplexed DRAM bus would also help with the pin count, but it's not clear to me that was a concern.
And sure, I can see how it's done and announce it's "easy". But I'd be hesitant to try it. So if you've actually done it, bravo.
(edit: Among other things, how did you handle the case of your refresh ISR firing in the middle of a read cycle? Certainly can be done correctly, but it's a non-trivial (albeit software-side) problem to solve.)
"Hackers Successfully Install Linux on a Potato" http://www.bbspot.com/news/2008/12/linux-on-a-potato.html
Linux is generally considered the go-to OS for under powered computers "Under-powered" is a moving target. It seems to apply best to computers that don't quite meet the specs of the current Windows, or perform very poorly with it. Anything without a prayer of running WinXP is much worse than under-powered, and modern Linux is a poor choice. An old linux2.4 distro would be a good option, or my personal favorite for tr…
Earlier quoted context omitted.
There is no X, he is accessing the system through minicom.
Theoretically you could boot X without a hardware framebuffer emulator. X supports rendering to normal RAM as well (for example, for VNC connections).
Earlier quoted context omitted.
It can't be that hard; I once bitbanged a 30 pin SIMM on a PIC with an interrupt to trigger the refresh. The 30 pin SIMM is 16MB and easy to wire (0.1" pitch). 16 MB of SRAM is probably going to be TSOP or worse, and probably in multiple packages. The multiplexed DRAM bus would also help with the pin count, but it's not clear to me that was a concern.
The point was more than you can wire the SRAM to the address bus of the CPU with maybe a little GPIO logic for bank switching to expand the address space. The DRAM has to be done over GPIO (my count is 22 data signals) solely, with attention to timings and refresh. And sure, I can see how it's done and announce it's "easy". But I'd be hesitant to try it. So if you've actually done it, bravo. ( edit: Among other thing…
Earlier quoted context omitted.
The point was more than you can wire the SRAM to the address bus of the CPU with maybe a little GPIO logic for bank switching to expand the address space. The DRAM has to be done over GPIO (my count is 22 data signals) solely, with attention to timings and refresh. And sure, I can see how it's done and announce it's "easy". But I'd be hesitant to try it. So if you've actually done it, bravo. ( edit: Among other thing…
I handled it thusly: while reading or writing RAM, interrupts are off. Between bytes read they are re-enabled. This means that the longest refresh delay is the length of a ram read/write. This is why my refreshes happen every 62ms and not every 64ms as the DRAM datasheet specifies - to allow me this leeway to be a bit late with the refresh.
The point being: it's non-trivial.
And this was 15 years before Inception... ;)
Anybody have a SPARC 1 emulator?
Earlier quoted context omitted.
I handled it thusly: while reading or writing RAM, interrupts are off. Between bytes read they are re-enabled. This means that the longest refresh delay is the length of a ram read/write. This is why my refreshes happen every 62ms and not every 64ms as the DRAM datasheet specifies - to allow me this leeway to be a bit late with the refresh.
Hm... sounds wrong to me. What if the software ends up spinning on the DRAM? You'll run with interrupts disabled pretty much all the time and miss your next refresh. You need to guarantee the timer, but not clobber a transaction in progress. You need to check a flag out of the DRAM access routine or something that tells you a refresh was missed and do it synchronously I guess. The point being: it's non-trivial.
[also, why do I keep being told I am submitting too fast, please slow down. I just posted 2 comments here, that is all. Had to make a new username :(]
Earlier quoted context omitted.
Hm... sounds wrong to me. What if the software ends up spinning on the DRAM? You'll run with interrupts disabled pretty much all the time and miss your next refresh. You need to guarantee the timer, but not clobber a transaction in progress. You need to check a flag out of the DRAM access routine or something that tells you a refresh was missed and do it synchronously I guess. The point being: it's non-trivial.
Please note what I said. I release interrupts after every byte READ/WRITTEN , so that the maximal delay to a refresh is the length of a single byte read/write. In case it wasn't clear, the only interrupt in use is the ram refresh interrupt. If it is masked, and triggers, it will execute the handler when it is unmasked. This means that even a loop on RAM read/write will not starve RAM of refreshes [also, why do I keep…
I think there is extra throttling on brand-new accounts, to help keep spam under control. Once your account is a little older it will be less restricted.
Also: welcome, and thanks for joining the discussion!