Uclinux on the Pluto 6From this....To this...
Edwin Langley : Heberedwin@heber.co.ukCraig Duffy : University of the West ofEnglandCraig.Duffy@uwe.ac.uk
Project OriginPluto 6 Fruit machine controller boardmade by Heber:
● Heber have developed their own in-house monitor/executive– It has drivers written from scratch byHeber– It is fast, and ...
● A version of the Linux kernel formicrocontrollers without a MMU● First port in January 1998 by Rt-Control● Differences t...
● Create development environment– Obtain tool chain– m68k-elf-gdb● Create new board configuration● Edit entry assembly in ...
● Crashed in kernel during boot:– Assembly variables were wrong● #define MEM_SIZE 0x0016fefc– PAGE_OFFSET was wrong– Stack...
– Romfs too big● _ramstartcalculated >_ramendPorting uClinux to the Pluto 6RAM.text.data.romfs0x60000000 _stext_sdata_sbss...
● 2Mb of DRAM doesnt give even uClinuxmuch room to do anything– After 3 commands, memory is toofragmented to load programs...
Running the kernel from VRAM● Problem: program counter incrementing incorrectly● Possibly cache related
● Initial solution to use video card RAM● Solution found and borrowed from Heber:Getting more memory● Finally a working US...
● Vacuum Fluorescent Display– Simple character device– Clock ASCII characters in through 2 line serialportTime to write so...
● FPGA controls 256 lamps as 16 strobes of32, each has 8 brightness levels● Every 1ms, software must:– fill 8 32 bit data ...
● Problem:– Kernel timer used to rewrite lamp registersevery millisecond– Interrupt set for next jiffy, which isincremente...
● Choosing interface to user space– Write a char for brightness of each lamp● 1 file for all 256 lamps– Big overhead to ch...
Multiplexed lamp driver/> echo 0123456776543210 > /dev/lamps10/> echo 0707070707070707 > /dev/lamps15
Frame buffer driver● Graphics were a key part of project● Two options– Port a Denx Coral P X server on a PPC boardaccessed...
Frame buffer driver● Not a lot of designrequired● But understandingof sub system isrequired● Values written toCremson stor...
Frame buffer driver● Lots of code mistakes before finally:
Frame buffer driver● Endian issue, added byte swaps to macrosin fb_con.h:
Frame buffer driver● Forgot to allocate memory to 16 entryconsole pseudo palette:
Frame buffer driver● Had a try with 8 bit indirect colour mode● Created a new par instance
Frame buffer driver● Set bit field lengths in fb_var_screeninfo to 8:
Frame buffer driver● Set layer width in Cremson correctly:
Frame buffer driver● Finally, set the palette tables in videomemory in cremson_setcolreg():
Nano X● A pain to compile
IDE● Used a generic driver provided by uClinux● FPGA outputs same interrupt level forCompactFlash and Cremson● Lots of tro...
eXecute In Place● Tried XIP with romfs– Romfs scrambled when copying .data and .initfrom ROM area to RAM area– No need for...
● Project was successful● Verdict– Board is rather slow– Accumulated knowledge for future Heberboards● Lessons learned– Un...
Questions
Upcoming SlideShare
Loading in …5
×

UKUUG presentation about µCLinux on Pluto 6

621 views
510 views

Published on

Slides from a <a>talk</a> given at the UKUUG 2006 conference derived from my final year project on the UWE CRTS degree which involved porting uCLinux to the Pluto 6 gaming control board.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
621
On SlideShare
0
From Embeds
0
Number of Embeds
210
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

UKUUG presentation about µCLinux on Pluto 6

  1. 1. Uclinux on the Pluto 6From this....To this...
  2. 2. Edwin Langley : Heberedwin@heber.co.ukCraig Duffy : University of the West ofEnglandCraig.Duffy@uwe.ac.uk
  3. 3. Project OriginPluto 6 Fruit machine controller boardmade by Heber:
  4. 4. ● Heber have developed their own in-house monitor/executive– It has drivers written from scratch byHeber– It is fast, and well understood– We provide to customers drivers compiledto Library object files● However there is a problem...– Future boards may use more complexperipheral buses– We will require more complex software● E.G. TCP/IP stack, USB hostingProject Origin
  5. 5. ● A version of the Linux kernel formicrocontrollers without a MMU● First port in January 1998 by Rt-Control● Differences to Linux - uClinux has:– No virtual address spaces; applications mustbe linked to absolute addresses– No memory protection– To have drivers altered to operate throughlocal bus instead of ISA/PCI, with biggerinterrupt vector rangesBackground to uClinux
  6. 6. ● Create development environment– Obtain tool chain– m68k-elf-gdb● Create new board configuration● Edit entry assembly in crt0_ram.S– Set variables _rambase, _ramstart, _ramend,_ramvec.● Edit linker script in ram.ld– Link to DRAM at 0x60000000Porting uClinux to the Pluto 6
  7. 7. ● Crashed in kernel during boot:– Assembly variables were wrong● #define MEM_SIZE 0x0016fefc– PAGE_OFFSET was wrong– Stack corruption● Set SP to end of external SRAM– MBAR wrongly set to address of SRAM● #define MCF_MBAR 0x10000000Porting uClinux to the Pluto 6
  8. 8. – Romfs too big● _ramstartcalculated >_ramendPorting uClinux to the Pluto 6RAM.text.data.romfs0x60000000 _stext_sdata_sbss_ebssDynamicmemory0x6016FEFCA0A1A0 + ROMFS sizeA1 + ROMFS sizeCopy datafrom endforwards– VBR set to start of RAM, overwriting kernel– Set _ramvec to ColdFire internal SRAM● Finally a working kernel!– But...
  9. 9. ● 2Mb of DRAM doesnt give even uClinuxmuch room to do anything– After 3 commands, memory is toofragmented to load programs:Porting uClinux to the Pluto 6– Romfs contents restricted– Tools are required to test drivers/bin> vi__alloc_pages: 0-order allocation failed (gfp=0x1d2/0)__alloc_pages: 4-order allocation failed (gfp=0x1f0/0)Allocation of length 65000 from process 20 failedFree pages: 136kB ( 0kB HighMem)Zone:DMA freepages: 0kBZone:Normal freepages: 136kBZone:HighMem freepages: 0kB( Active: 5, inactive: 27, free: 34 )= 0kB)6*4kB 2*8kB 2*16kB 0*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB = 136kB)= 0kB)
  10. 10. Running the kernel from VRAM● Problem: program counter incrementing incorrectly● Possibly cache related
  11. 11. ● Initial solution to use video card RAM● Solution found and borrowed from Heber:Getting more memory● Finally a working USABLE kernel!FPGA for DRAMto local busdecodingDRAMBattery16Mb localbus interfaceDRAM card
  12. 12. ● Vacuum Fluorescent Display– Simple character device– Clock ASCII characters in through 2 line serialportTime to write some drivers!/> echo hello world! > /dev/vfd0
  13. 13. ● FPGA controls 256 lamps as 16 strobes of32, each has 8 brightness levels● Every 1ms, software must:– fill 8 32 bit data registers, each bitcorresponds to one lamp– Write the strobe number to illuminate to theMPX control register in the FPGA● The FPGA splits the 1ms period into 8segments, using 1 data register for each● Each bit of each data register = 1/8msMultiplexed lamp driver
  14. 14. ● Problem:– Kernel timer used to rewrite lamp registersevery millisecond– Interrupt set for next jiffy, which isincremented by timer interrupt– Timer interrupt frequency determined by HZ– HZ default is 100 (every 10ms)– Lamps flash (on for 1ms, off for 9ms)– Increased HZ to 1000Multiplexed lamp driver
  15. 15. ● Choosing interface to user space– Write a char for brightness of each lamp● 1 file for all 256 lamps– Big overhead to change 1 lamp● 1 file for each lamp– 256*3*2=1536 context switches● Best compromise– 1 file for each lamp strobeMultiplexed lamp driver
  16. 16. Multiplexed lamp driver/> echo 0123456776543210 > /dev/lamps10/> echo 0707070707070707 > /dev/lamps15
  17. 17. Frame buffer driver● Graphics were a key part of project● Two options– Port a Denx Coral P X server on a PPC boardaccessed through PCI running full Linux– Write a frame buffer driver from scratchCremson videocontrollerDRAMFujitsu Calypso 32 Graphics card
  18. 18. Frame buffer driver● Not a lot of designrequired● But understandingof sub system isrequired● Values written toCremson stored ina par structure– Initial par instancewith set valuesused for testing● 1024x768x16fb_infofb_var_screeninfofb_fix_screeninfofb_monospecsfb_ops * fb_opsfbgen_get_fix()fbgen_get_var()fbgen_set_var()fbgen_get_cmap()fbgen_set_cmap()fbgen_pan_display()fb_cmapdisplay * displayPar *cremsonfb_infofb_info_genfbgen_hwswitch * cremsonfb_switchcremson_detect()cremson_encode_fix()cremson_decode_var()cremson_encode_var()cremson_get_par()cremson_set_par()cremson_get_getcolreg()cremson_set_getcolreg()cremson_pan_display()cremson_blank()cremson_set_disp()uint32_t fbcon_cmap[256]void *screen_base_physvoid *screen_base_virtuint32_t vid_mem_lenparCremson registercopiesunsigned int parsize
  19. 19. Frame buffer driver● Lots of code mistakes before finally:
  20. 20. Frame buffer driver● Endian issue, added byte swaps to macrosin fb_con.h:
  21. 21. Frame buffer driver● Forgot to allocate memory to 16 entryconsole pseudo palette:
  22. 22. Frame buffer driver● Had a try with 8 bit indirect colour mode● Created a new par instance
  23. 23. Frame buffer driver● Set bit field lengths in fb_var_screeninfo to 8:
  24. 24. Frame buffer driver● Set layer width in Cremson correctly:
  25. 25. Frame buffer driver● Finally, set the palette tables in videomemory in cremson_setcolreg():
  26. 26. Nano X● A pain to compile
  27. 27. IDE● Used a generic driver provided by uClinux● FPGA outputs same interrupt level forCompactFlash and Cremson● Lots of trouble with Cremson Vsync interruptwhile unmasking in ColdFire for the IDE– Mask Vsync on Cremson– Unmask interrupt vector on ColdFire● Copied romfs to CompactFlash card● Altered kernel command line to mount asroot FS
  28. 28. eXecute In Place● Tried XIP with romfs– Romfs scrambled when copying .data and .initfrom ROM area to RAM area– No need for romfs with a working disk present● Added initial vector table to crt0_rom.S● Split DRAM card into 2 Mb "ROM" and therest as RAM area● Could finally boot straight into uClinux atpower onMEMORY {flash : ORIGIN = 0x00000000, LENGTH = 0x00200000ram : ORIGIN = 0x00200000, LENGTH = 0x00E00000}
  29. 29. ● Project was successful● Verdict– Board is rather slow– Accumulated knowledge for future Heberboards● Lessons learned– Understand code before starting● learned lesson porting● used lesson on frame buffer– Learned lots about kernel programmingConclusion
  30. 30. Questions

×