ucLinux on Papilio Plus using Amber Core


ben

Recommended Posts

Hi all,

Wanting to learn a bit about the bare metal side of operating systems, I'm trying to get ucLinux run on the Papilio Plus.

I downloaded the open-source Amber core (ARM SoC, with an older instruction set) from OpenCores. The 'regular' core (the only one that had a chance to fit in a Papilio) has a 3-stage pipeline and a cache controller, giving 0.75 MIPS per MHz... this should be more than enough to run a basic OS and some programs.

I was afraid that the core would not fit on the LX9 (as the docs were talking about the much bigger SLX45), but I just managed to get it to compile under ISE. I just had to manually enable some 'ifdef' sections to get the right source files in.

It takes 91% of the slices (77% of the LUTs), including a basic internal ram controller, a crude sram controller, and three 'wing controllers' (capable of input/output and interrupt trigger). To get linux working, you'll also need an UART module, an interrupt controller, and a timer module, which should all fit without problems in the remaining space.

Basically, this first step says that, yes, you can have an ARM system running linux inside a Papilio. Still, you'll have to give up your ideas about fancy cores (a VGA controller ? who needs it when you've got a serial connection ?), which makes the whole 'i'm doing this on a FPGA' thing a bit pointless... perhaps a simple, hi-speed data acquisition core could fit, though.

Anyway, I'll finish the SoC, probably using the cores in the Amber project if they fit, and then attack the Linux part, which should not be too much of a problem once I've got the toolchain up and running, as the Amber project also provides source for linux. I will post some code once I have something running.

Then, the big question will be: what can you do with an embedded linux with 48 GPIO lines and 4Mbit of RAM ? All ideas are welcome !

Link to comment
Share on other sites

I got the 'full' system (with uart, interrupts and timer) to pass p&r in ISE. It looks like it fits !

(I'm not that confident, as xst complains a lot: I may have made some silly mistakes and some 'unused' parts may have been discarded...)

Next step is setting up a simulation toolchain, to check that basic assembly programs (uart read/write) work as expected. Then, upload the system on a Papilio Plus and do some real life testing, and then attack the bootloader, and then finally have a look at that linux thing.

Link to comment
Share on other sites

Hehe, you make it sound so easy.

to be honest, it really looks complicated to me... a bit of bragging can only help !

still, I just completed the first major achievement: upload the system on a papilio with a minimal assembly 'bootloader', and see the output on the serial console! at this point, it's only a '3', but 'hello world' is definitely withing grasp.

Link to comment
Share on other sites

Just wondering: did you manage to get the spi flash to work on the papilio plus ?

I was initially thinking of using an SD card as a boot device, but then I remembered that the flash chip was there. It might just be the best way to store the kernel and boot ram disk (and some other filesystem ?) you'd get a independant device, with all wings free, and spi flash should be faster (and more reliable) than sd cards.

That's item #1453 on my todolist, though. I will probably start with the xmodem upload code that is used in the Amber project, as this is much easier for debugging.

Link to comment
Share on other sites

  • 1 month later...

mmm. checking the linux kernel size, I realize that won't work so easily on a papilio : it's more than 500k long ! I might make it smaller by dropping parts (network etc.), but that's a lot of work, and I'm afraid that goes beyond my skills.

My guess is that 32 bit arm code is really not size-optimized at all (that's actually why arm introduced thumb code format), so another platform might be more suitable : perhaps PicoBlaze would be better ?

Link to comment
Share on other sites

mmm. checking the linux kernel size, I realize that won't work so easily on a papilio : it's more than 500k long ! I might make it smaller by dropping parts (network etc.), but that's a lot of work, and I'm afraid that goes beyond my skills.

My guess is that 32 bit arm code is really not size-optimized at all (that's actually why arm introduced thumb code format), so another platform might be more suitable : perhaps PicoBlaze would be better ?

Ben,

I'm currently on uClinux port for ZPUino. I'm actually amazed at your code size (have you disabled all filesystems?) - my kernel is about 1.5M in size, with networking and filesystem support. Of course, it will still need some effort in order to run, since this is a whole new platform and CPU.

I don't think you'll be able to run uClinux with picoblaze. It's very limited for this task.

Alvie

Link to comment
Share on other sites

I'm currently on uClinux port for ZPUino. I'm actually amazed at your code size (have you disabled all filesystems?) - my kernel is about 1.5M in size, with networking and filesystem support. Of course, it will still need some effort in order to run, since this is a whole new platform and CPU.

I don't think you'll be able to run uClinux with picoblaze. It's very limited for this task.

500k is the "stock" amber linux kernel, it's a 2.4 linux (not uclinux, my guess is they disabled the mmu part themselves). Networking is enabled, but I'm not sure about filesystems.

About PicoBlaze: it is definitely possible, as there is an official Xilinx howto, It uses a specific dev board, with lots of onboard ram, so I'm not sure this would fit in the sram of a papilio plus. And I'd be much happier with a ZPUino implementation, if only for the open source aspects.

Link to comment
Share on other sites

About PicoBlaze: it is definitely possible, as there is an official Xilinx howto, It uses a specific dev board, with lots of onboard ram, so I'm not sure this would fit in the sram of a papilio plus. And I'd be much happier with a ZPUino implementation, if only for the open source aspects.

You sure you don't mean MicroBlaze ? PicoBlaze is an 8-bit MCU with very restrict memory address space.

Alvie

Link to comment
Share on other sites

  • 3 weeks later...

Ben,

I just stumbled across some information about linux on the Microblaze. First of all, Xilinx bought PetaLinux! So hopefully that means the PetaLinux base will be released for use on Xilinx chips...

Second, I came across a very recent tutorial/guide that looks pretty good:

http://forums.xilinx...ort/td-p/144312

Look in the thread for the Project.tar attachment. I'm attaching it here too just in case it gets lost.

Project.tar

Link to comment
Share on other sites

  • 1 year later...

Hi,

 

just curious, what clock speed can you reach with the amber CPU?

 

As you mentioned "bare metal" and "ZPU": I just posted a bare metal ZPU example :)

http://forum.gadgetfactory.net/index.php?/topic/2058-medium-zpu-simple-example/#entry14088

 

This one provides 32k RAM, or less (64K is possible with editing).

For Linux, I'd have a look at the zpuino: http://zpuino.blogspot.fi/

It uses the sdram, memory should not be an issue.

Link to comment
Share on other sites

  • 2 weeks later...

If you are memory constrained then the *nix to port would probably be 2.11BSD on PDP-11 (aka RetroBSD on MIPS in a more recent incarnation). Linux is not optimised for size but for performance on modern PC class hardware. 2.11BSD was designed to run with full networking on a system with 1MB of RAM. 11 code is tighter than ARM though.

 

Other "micro Unixen" include UZI (aimed at Z80 mainly), OMU (originally intended for 68K), and ELKS (8086). Plus these days Minix is free so I guess you could run Minix on an 8086 FPGA core 8)

 

To me the more interesting questions are things like "How much of the OS can you turn into raw FPGA" - eg having instructions for 'reschedule', 'zero page', 'syscall', some of the file system elements and other hot paths.

 

Alan

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.