AVR runs ARM emulator that runs Ubuntu Linux at effective frequency 6.5 kHz:
http://hackaday.com/2012/03/28/building-the-worst-linux-pc-ever/ :)
AVR running Linux
Author
Message
This is the sort of thing I might ponder, but end up rejecting. Nice to see there are people in the world that reject such notions and just do it for the sake of doing it.
The perpetrator of this ummmmm... thingy has been seen on avrfreaks recently.
- S
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 100381 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Level: 10k+ Postman
Joined: Tue. Nov 11, 2003
Posts: 10343 View posts
Location: Bartlesville Oklahoma USA
A pretty cool hack, but I don't think I would actually use it for anything.
If you don't know my whole story, keep your mouth shut.
If you know my whole story, you're an accomplice. Keep your mouth shut. 
Insanely brilliant.
[note to self: never complain about boot times again]
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 100381 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Quote:
but I don't think I would actually use it for anything
Not the Linux itself but the ARM emulator in this is the real "clever bit" and would act as yet another solution to perennial "how do I run code from RAM/SDCard/whatever?" question. It'd also mean that easy to find/use ARm dev tools (arm-gcc for example) could be used for developing the code.
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9845 View posts
Location: Melbourne, Australia
I loved this when we all had a look at work - but I'd REALLY love to see it running on the XMEGA, overclocked to 72MHz (the maximum stable speed I was able to get in my own testing with room temperature/3.3V) and the EBI used for faster memory access.
- Dean :twisted:
PS: The Comedy Option: Run avrice on the emulated ARM to debug AVR code simulated on the AVR.
Level: Raving Lunatic
Joined: Wed. Mar 12, 2003
Posts: 2951 View posts
Location: Portland, Oregon USA
There is a moment in all new technologies when the developer is overcome by massive feeling of despair that results from having spent many, many long hours getting the new technology to do something 'stupid', or to say, something that can be done much cheaper and easier with existing, older technology.
Steven Levy describes this emotion in the book 'Hackers' when he describes the MIT student who spent a hundred hours getting the school's DEC minicomputer to emulate a typewriter.
This overwhelming feeling of despair and worthlessness is in reality a major breakthrough in bringing advanced technology from the lab to the real world. The feeling passes; the tech breakthough remains. And as the technology advances, increases in speed and comes down in price, it creates more wealth in the real world.
Congratulations!
Torby wrote:
It could be used to benchmark the compiler and the tools :-)
A pretty cool hack, but I don't think I would actually use it for anything.
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9845 View posts
Location: Melbourne, Australia
Quote:
A pretty cool hack, but I don't think I would actually use it for anything.
Something created simply because you can is beautiful in its own right; as it serves no practical purpose, it itself becomes something to admire and thus gives itself worth.
- Dean :twisted:
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 100381 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Quote:
Something created simply because you can is beautiful in its own right;
Reminds me of Rowland Emett - anyone who doesn't already know his work should Google it. Wonderful stuff. The guy was clearly stark staring bonkers but an utter genius with it!
abcminiuser wrote:
Something created simply because you can is beautiful in its own right; as it serves no practical purpose, it itself becomes something to admire and thus gives itself worth.
thanks :)
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9845 View posts
Location: Melbourne, Australia
Quote:
thanks Smile
If it's any consolation, the Apps team in Norway were going nuts over this the other day. We'd love to see you port it to the XMEGA devices and use the hardware EBI and USART-SPI modules to see how well it performs, if you have the time.
- Dean :twisted:
I would sincerely hope that someone in Atmel has already posted some XMegas, programmers, debuggers, adapters, norse figurines etc. in Dmitry's direction?
Is there some Atmel "award of engineering excellence" that can be handed out?
This reminds me an oil tanker propelled with two short oars.
Seems like the definition of beauty is highly subjective.
Snake oil. Show me the code and the schematic for wiring up a ram stick. How do you set 32 address lines and read and write 32 data bits without latches? How do you do row and column refreshes every couple of milliseconds?
I'd like to see a schematic and some details about the refresh too. But wasn't it 30 pin SIMM? They have 12 address lines (12 rows x 12 columns) and 8 data lines.
I have no idea how ram row and column refresh works. You have a 12 bit counter on the columns and a 1 of 12 code on the rows?
um...the code is on the site, as is the wiring info. http://dmitry.co/ click on "thoughts" on the left
abcminiuser wrote:
Quote:
thanks Smile
If it's any consolation, the Apps team in Norway were going nuts over this the other day. We'd love to see you port it to the XMEGA devices and use the hardware EBI and USART-SPI modules to see how well it performs, if you have the time.
- Dean :twisted:
i haven't any xmegas or a way to program them (i assume my simple programmer will not program them?) , sorry. I just got started with AVRs (having graduated from PICs - having 1 cycle/clock is so nice :) )
bobgardner wrote:
http://dmitry.co/images/uARM.zip
Snake oil. Show me the code and the schematic for wiring up a ram stick.
This project is so brilliant! I wonder how much time will pass before it's used in some PIC vs AVR discussion. 8)
Well, I used to be a pic guy (see my site, etc) But I've switched now. 4x faster at same speed helps a lot, but pics still do have some cool things avrs lack: self-programming from anyplace in flash instead of just last few pages, ability to use the reset pin as a gpio without making your life a pain when reprogramming, etc... but AVRs are faster, have easier memory map, simpler asm, and did i mention faster? so for 8-bit AVRs are my new thing. 16-bit dsPICs though are unbeatable (100MHz chip in a 20-pin DIP is cool).
This project would be almost impossible on a 8-bit pic though (it would be too slow) - I tried. on a dsPIC it works very fast
So there are at least two giant breakthroughs here... the big ram and the ARM interpreter. Is that ARM interpreter written in c or c++? OK, one more question.... who reads the sd card? The AVR or the interpreted ARM? I guess the next question is: would a JVM interpreter run java faster than the ARM interpreter runs compiled c for the ARM? "lines per second" or some metric like that.
emulator is all c, ram access code is c + asm (c-only version code provided too but asm code is 10x faster)
avr accesses sd card, linux accesses it through a paravirtualized device (pvDisk)
I already have made a working jvm for avr and will publish it soon enough (it is much faster) and unlike the former attempts(nanovm, etc) i support synchronization, threading, proper garbage collection, all data types, interfaces, exceptions, etc
i just finished optimizing the ram routines, they can now read/write multiple bytes at a time, up to 256 per call. refresh is also optimized. refresh now takes up 28723 cycles every 64ms (1.87% of the cpu time at 24MHz). Ram read is now 16+12x cycles for x bytes. write is 21+12x - quite fast (1.92MB/s read 1.90MB/s write using 32 byte blocks at 24 MHz)
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9845 View posts
Location: Melbourne, Australia
Dmitry,
Do you think you could get this running on an XPLAIN-A1 board, with its hardware SDRAM controller and on-board 8MB SDRAM? It's half of what you quote in your article, but I imagine the 32MHz core speed with DMA and hardware memory refresh would more than make up for the smaller amount of RAM.
- Dean :twisted:
anything under 10KB ram is a bit difficult (no icache) so if that board comes with a micro that has 16KB of ram or more, it'll work just fine
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9845 View posts
Location: Melbourne, Australia
Unfortunately it's only got 8KB of internal SRAM, but it also has 8MB of onboard SDRAM - which is mappable to the internal memory space.
- Dean :twisted:
abcminiuser wrote:
Unfortunately it's only got 8KB of internal SRAM, but it also has 8MB of onboard SDRAM - which is mappable to the internal memory space.- Dean :twisted:
this sounds like a job for the new xmegas with 32k sram!
Also, don't forget the X1 EBI controller has simultaneous support for SD RAM and SRAM ...
Last thing I would like to mention, why didn't Dmitry use an older Linux kernel? If I'm not mistaken, aren't there 16 bit binaries still around?
Dmitry emulated an ARM processor. ARMs arent 16 bit, so no binaries for ARM in 16 bit exist. Besides, what benefit would an older kernel provide?
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 100381 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Kartman wrote:
...Besides, what benefit would an older kernel provide?
No less benefit than emulating a new kernel...LOL!
Level: Raving Lunatic
Joined: Fri. Dec 16, 2005
Posts: 3270 View posts
Location: Bratislava, Slovakia
clawson wrote:
This (the instruction bus width) is what ARM (the CM-variety where's no escape from Thumb) and AVR have in common. Quite surprisingly.
Quote:
ARMs arent 16 bit
Not even in Thumb mode? ;-) :?
JW
Thumb is not 16-bit in any reasonable sense. It is just a collection of most commonly-used instructions in 32-bit-length, shrunk down to 16-bit length (think of it as huffman-coding the instruction stream, with an input symbol length of 32bits and symbol index as 16 bits). The registers are still 32 bit as are all operations. My emulator does support Thumb.
I did manage to run it in 8K just now, so i guess it will work on the XMega :)
Once I finished the emulator, i picked a random recent kernel and built it (I stared working on this project a while ago). The whole point was to boot a modern OS
You must have to much time!
But a great job
I'm a bit surprise that it run that slow!
When I was playing with a AVR emulator on a AVR it could run in about 1/25 of the real speed!
but you are running about 100 times slower than that!
What is killing you?
read RAM
decode instruction
execute the instruction
handling of flags
handling of registers
special code for R14 and R15
or ???
Perhaps you could tell how many clk's you use in the different instructions phases, and perhaps I have some ideas to speed it up.
Jens
I'd guess emulating the mmu will chew up a few cycles. Nothing like having hardware to do the grunt work.
yes one way to speed it up would be to have one AVR to run the ARM emulator, and one to do the memory stuff.