AVR running Linux

Go To Last Post
37 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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/ :)

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The perpetrator of this ummmmm... thingy has been seen on avrfreaks recently.

- S

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh wow - this is utterly brilliant!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A pretty cool hack, but I don't think I would actually use it for anything.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Insanely brilliant.

[note to self: never complain about boot times again]

Nigel Batten
www.batsocks.co.uk

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Torby wrote:
A pretty cool hack, but I don't think I would actually use it for anything.
It could be used to benchmark the compiler and the tools :-)

avrfreaks does not support Opera. Profile inactive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

Nigel Batten
www.batsocks.co.uk

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This reminds me an oil tanker propelled with two short oars.

Seems like the definition of beauty is highly subjective.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

um...the code is on the site, as is the wiring info. http://dmitry.co/ click on "thoughts" on the left

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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 :) )

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Snake oil. Show me the code and the schematic for wiring up a ram stick.
http://dmitry.co/images/uARM.zip

This project is so brilliant! I wonder how much time will pass before it's used in some PIC vs AVR discussion. 8)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

ARMs arent 16 bit

Not even in Thumb mode? ;-) :?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
...Besides, what benefit would an older kernel provide?

No less benefit than emulating a new kernel...LOL!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

ARMs arent 16 bit

Not even in Thumb mode? ;-) :?
This (the instruction bus width) is what ARM (the CM-variety where's no escape from Thumb) and AVR have in common. Quite surprisingly.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd guess emulating the mmu will chew up a few cycles. Nothing like having hardware to do the grunt work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.