https://elinux.org/api.php?action=feedcontributions&user=Cschalle&feedformat=atomeLinux.org - User contributions [en]2024-03-19T02:49:28ZUser contributionsMediaWiki 1.31.0https://elinux.org/index.php?title=Xmas_Video&diff=74503Xmas Video2011-10-28T11:59:32Z<p>Cschalle: Add category</p>
<hr />
<div>Christmas Lights Controller using the [[Hammer Board]]<br />
<br />
[http://www.youtube.com/watch?v=revJ7Kccufg Christmas Eve Sarajevo Video (YouTube)]<br />
<br />
[http://www.youtube.com/watch?v=V5_GyEc_9GM Mad Russian Christmas Video (YouTube)]<br />
<br />
[http://www.flickr.com/photos/21836722@N02/sets/72157603459882107/with/2110566815/ Construction Photos]<br />
<br />
[[Category:Hardware]]</div>Cschallehttps://elinux.org/index.php?title=Source_Task_List&diff=74497Source Task List2011-10-28T11:58:22Z<p>Cschalle: Add category</p>
<hr />
<div>Below is a list of tasks to be worked on for the CELF Source Tree.<br />
If no one has signed up for a task, feel free to do so (on a first-come, first-served basis).<br />
<br />
To edit the task list, you can click on either EditText or<br />
EditTable at the bottom of this page.<br />
<br />
Please see the [[Outstanding Patch List]] page for information about patches that<br />
have been submitted but not applied yet.<br />
<br />
Please fill in the person (which can be a wiki name if you have a page on this site) or company<br />
name. Please also provide contact information if you are not a member of the forum.<br />
If you would like to commit to a completion date, please enter that as well, in the form:<br />
YYYY-MM-DD. Finally, add any notes you think are pertinent to this task.<br />
<br />
If you need to create a page with more detailed information about the task, please do so<br />
and link to that page either in the Task Description or the Notes field.<br />
<br />
Status should be one of: "not done", "started", "done", "cancelled"<br />
<br />
== Task List ==<br />
{| <br />
|- bgcolor="80C0c0"<br />
| align="center" | '''Task Description'''<br />
| align="center" | '''Project'''<br />
| align="center" | '''Person'''<br />
| align="center" | '''Expected Completion Date'''<br />
| align="center" | '''Status'''<br />
| align="center" | '''Notes'''<br />
|- <br />
| Create project status table<br />
| patch isolation<br />
| [[User:Tim Bird|Tim Bird]]<br />
| -<br />
| .<br />
| -<br />
|}<br />
<br />
== Recently retired items ==<br />
{| <br />
|- bgcolor="80C0c0"<br />
| align="center" | '''Task Description'''<br />
| align="center" | '''Project'''<br />
| align="center" | '''Person'''<br />
| align="center" | '''Retired Date'''<br />
| align="center" | '''Status'''<br />
| align="center" | '''Notes'''<br />
|}<br />
<br />
<hr /><br />
[[Category Task List]]<br />
<br />
[[Category:CELinux]]</div>Cschallehttps://elinux.org/index.php?title=M8050&diff=74269M80502011-10-28T10:46:28Z<p>Cschalle: Add category</p>
<hr />
<div>[[image:m8050.jpg]][[image:m8050-2.jpg]]<br />
<br />
=== Hardware ===<br />
* S3C2440 at 405MHz<br />
* 128mb sdram<br />
* 128mb nand flash<br />
* wm8750 audio codec<br />
* 240x320 TFT lcd<br />
* touchscreen<br />
* trackball w/ red and green leds<br />
* number keypad w/ user defined keys<br />
* laser barcode scanner<br />
* 3 track magnetic card reader<br />
* 802.11b/g<br />
* bluetooth<br />
* 5800mAh Li-Ion Battery<br />
* 200mAh Li-Pol backup battery<br />
* microSD slot<br />
<br />
[[Category:Hardware]]</div>Cschallehttps://elinux.org/index.php?title=Literati:Opening_White_Literati&diff=74257Literati:Opening White Literati2011-10-28T10:45:25Z<p>Cschalle: Fix category</p>
<hr />
<div>== Step 0: Flip it Over ==<br />
<br />
[[File:LiteratiStep0.jpg]]<br />
<br />
== Step 1: Slide White Part Toward Top ==<br />
<br />
[[File:LiteratiStep1.jpg]]<br />
<br />
== Step 2: Remove First Screw Holding Gray Back ==<br />
<br />
[[File:LiteratiStep2.jpg]]<br />
<br />
== Step 3: Remove Second Screw Holding Gray Back ==<br />
<br />
[[File:LiteratiStep3.jpg]]<br />
<br />
== Step 4: Slide Gray Back Toward Top ==<br />
<br />
[[File:LiteratiStep4.jpg]]<br />
<br />
== Step 5: Remove Gray Back By Lifting It Up ==<br />
<br />
[[File:LiteratiStep5.jpg]]<br />
<br />
[[Category:Literati]]</div>Cschallehttps://elinux.org/index.php?title=Literati:Serial_Port&diff=74245Literati:Serial Port2011-10-28T10:44:43Z<p>Cschalle: Add category</p>
<hr />
<div>==Location==<br />
[[File:literati-w-1637287.gif|thumb|White model #1637287]]<br />
The Serial port on the White literati model #1637287 is located on the right side of the device seen in the picture on the right.<br />
this is also true on the older black models.<br />
<br />
currently we do not know where they are on the newer models a picture of a newer model is also on the right and circled is what is believed to be the serial port.<br />
[[File:literati-w-new.jpg|thumb|White Model new]]<br />
<br />
the serial port header has the follow pinout from top to bottom:<br />
<br />
{|border=1<br />
!Number<br />
!Description<br />
|-<br />
|1<br />
|5V<br />
|-<br />
|2<br />
|TX<br />
|-<br />
|3<br />
|RX<br />
|-<br />
|4<br />
|GND<br />
|}<br />
<br />
The UART TX and RX signals are at +3.3v TTL level which requires a [[RS232_Level_Shifter]] if connecting to a standard RS-232 interface or to a standard USB-to-RS232 adapter. A wide range of USB-to-TTLUART adapters are available including the following:<br />
<br />
* [http://www.dealextreme.com/p/data-cable-compatible-with-nokia-ca-42-446 Nokia CA-42 Data Cable]<br />
* [http://www.dlpdesign.com/usb/usb232r.shtml DLP Design FT232R Based Adapter]<br />
* [http://www.sparkfun.com/products/718 Sparkfun FT232R Based Adapter]<br />
<br />
Once connected this will enable access the bootloader and start up processes of the linux kernel.<br />
<br />
<br />
==Easy Serial Port Access==<br />
[[File:Literati_serial_open.jpg|thumb|View of the serial port access]]<br />
[[File:Literati_serial_closed.jpg|thumb|Serial port with back on]]<br />
[[File:Literati_serial_connected.jpg|thumb|Serial cable connected]]<br />
<br />
Use the following items to expose the serial port in a handy way that does not require reopening of the literati to access the serial port:<br />
<br />
* a bit of ribbon cable<br />
* male header pins<br />
* female socket<br />
<br />
<br />
another option includes the use of a [http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=CP1-3513-ND 1/8" audio jack] which can be easily mounted by drilling a hole in the back cover.<br />
<br />
==Using CA-42 Serial Cable==<br />
[[File:Literati_CA-42-small.jpg|thumb|CA-42 USB Serial Cable]]<br />
[[File:Literati_CA-42_DKU-5_pinout.jpg|thumb|CA-42 Pinout]]<br />
[[File:Literati_CA-42_and_DKU-5_disassembled.jpg|thumb|CA-42 Cut Open]]<br />
<br />
One of the simplest way to connect your PC to the Literati serial port is to order a [http://www.dealextreme.com/p/data-cable-compatible-with-nokia-ca-42-446 Nokia CA-42 Data Cable] from [http://www.dealextreme.com DealExtreme]. When you receive it, you can cut it open to find 3 or 4 wires depending on the revision. If you have three wires, then you will find GND, RX, and TX. If you have four wires, then the fourth wire is +3.3V. The example CA-42 only has three. The cable can be soldered to a female pin header so it can connect to the male pins used to expose the serial port to the outside.<br />
<br />
==Boot Loader==<br />
during the boot process there is a 3 second count down to allow a user to enter the bootloader before booting the kernel.<br />
<br />
To get out of the bootloader right now you type "reset" and the device will reboot allowing you to get out of the bootcmd line<br />
there is a way to boot from nand but iv forgot to log the offsets. <br />
<br />
==Boot CMD's==<br />
<pre><br />
boot zImage from sd that fat32 part<br />
boot zImage from sd that fat32 part<br />
boot zImage from sd that fat32 part<br />
boot zImage from sd that fat32 part<br />
? - alias for 'help'<br />
base - print or set address offset<br />
bdinfo - print Board Info structure<br />
bootm - boot application image from memory<br />
branch - enable or disable branch prediction<br />
TestMemory - start application at address 'addr'<br />
cmp - memory compare<br />
cp - memory copy<br />
crc32 - checksum calculation<br />
dcache - enable or disable data cache<br />
dnw - initialize USB device and ready to receive for Windows server (specific)<br />
echo - echo args to console<br />
erase - erase FLASH memory<br />
exit - exit script<br />
flinfo - print FLASH memory information<br />
go - start application at address 'addr'<br />
help - print online help<br />
icache - enable or disable instruction cache<br />
imls - list all images found in flash<br />
itest - return true/false on integer compare<br />
loadb - load binary file over serial line (kermit mode)<br />
loads - load S-Record file over serial line<br />
loady - load binary file over serial line (ymodem mode)<br />
loop - infinite loop on address range<br />
md - memory display<br />
mm - memory modify (auto-incrementing)<br />
movi - moviNAND sub-system<br />
mtest - simple RAM test<br />
mw - memory write (fill)<br />
nand - NAND sub-system<br />
nboot - boot from NAND device<br />
nm - memory modify (constant address)<br />
printenv- print environment variables<br />
protect - enable or disable FLASH write protection<br />
reset - Perform RESET of the CPU<br />
saveenv - save environment variables to persistent storage<br />
setenv - set environment variables<br />
sleep - delay execution for some time<br />
test - minimal test like /bin/sh<br />
version - print monitor version<br />
1 update boot from sd <br />
2 update kernel from sd <br />
3 update resource from sd <br />
4 update all <br />
</pre><br />
<br />
[[Category:Literati]]</div>Cschallehttps://elinux.org/index.php?title=Literati:Opening_White_Literati&diff=74239Literati:Opening White Literati2011-10-28T10:43:42Z<p>Cschalle: Add category</p>
<hr />
<div>== Step 0: Flip it Over ==<br />
<br />
[[File:LiteratiStep0.jpg]]<br />
<br />
== Step 1: Slide White Part Toward Top ==<br />
<br />
[[File:LiteratiStep1.jpg]]<br />
<br />
== Step 2: Remove First Screw Holding Gray Back ==<br />
<br />
[[File:LiteratiStep2.jpg]]<br />
<br />
== Step 3: Remove Second Screw Holding Gray Back ==<br />
<br />
[[File:LiteratiStep3.jpg]]<br />
<br />
== Step 4: Slide Gray Back Toward Top ==<br />
<br />
[[File:LiteratiStep4.jpg]]<br />
<br />
== Step 5: Remove Gray Back By Lifting It Up ==<br />
<br />
[[File:LiteratiStep5.jpg]]<br />
<br />
[[Categoty:Literati]]</div>Cschallehttps://elinux.org/index.php?title=Literati&diff=74233Literati2011-10-28T10:43:13Z<p>Cschalle: Add category</p>
<hr />
<div>== Links ==<br />
<br />
# New Dev forum [http://literati.linuxprogrammer.org http://literati.linuxprogrammer.org]<br />
# Old Dev forum [http://forum.literatidevs.com/index.php http://forum.literatidevs.com/index.php]<br />
<br />
== Hardware ==<br />
<br />
* CPU: S3C6410 running at 666Mhz<br />
* Memory: 64MB<br />
* LCD: innolux lcd 480 X 800<br />
<br />
=== NAND (internal flash) ===<br />
<pre><br />
NAND device: Manufacturer ID: 0xec, Chip ID: 0xdc (Samsung NAND 512MiB 3,3V 8-bit)<br />
Creating 5 MTD partitions on "NAND 512MiB 3,3V 8-bit":<br />
0x00000000-0x00040000 : "Bootloader"<br />
0x00040000-0x00340000 : "Kernel"<br />
0x00340000-0x00d40000 : "resource"<br />
0x00d40000-0x11140000 : "File System 1"<br />
0x11140000-0x20000000 : "User space"<br />
</pre><br />
<br />
=== Datasheets ===<br />
<br />
[http://www.mt-system.ru/documents/smdk6410_users_manual_rev1.0.pdf smdk6410] it looks to be based on this.<br />
[[File:Lookbook-schematics.pdf]]<br />
<br />
[http://www.gst-lcd.com/spec/tftspec/LTE480WV-F01(4.8inch).pdf LCD] [http://www.diytrade.com/china/4/products/3920682/4_8inch_TFT_LCD_Module_800x480_LTE480WV-F01.html quick view]<br />
<br />
=== JTAG Port ===<br />
The JTAG port has yet to be identified on the Literati.<br />
<br />
=== Serial Port ===<br />
[[Literati:Serial Port|Serial Port Access]]<br />
<br />
=== Opening Your Literati (White Sunway Model) ===<br />
[[Literati:Opening White Literati|Opening White Literati]]<br />
<br />
== Kernel testing ==<br />
[[Burn Kernel/Booting from SD]]<br />
<br />
=== dmesg from ygator ===<br />
<br />
<pre><br />
Linux version 2.6.24.2 (root@ligang-laptop) (gcc version 4.1.2) #180 Mon Aug 23 00:49:07 CST 2010<br />
CPU: ARMv6-compatible processor [410fb766] revision 6 (ARMv7), cr=00c5387f<br />
Machine: SMDK6410<br />
Ignoring unrecognised tag 0x00000000<br />
Memory policy: ECC disabled, Data cache writeback<br />
On node 0 totalpages: 16384<br />
DMA zone: 128 pages used for memmap<br />
DMA zone: 0 pages reserved<br />
DMA zone: 16256 pages, LIFO batch:3<br />
Normal zone: 0 pages used for memmap<br />
Movable zone: 0 pages used for memmap<br />
CPU S3C6410 (id 0x36410101)<br />
S3C6410: core 666.000 MHz, memory 111.000 MHz, peripheral 55.500 MHz<br />
S3C6410: EPLL 192.000 MHz<br />
S3C64XX Clocks, (c) 2007 Samssung Electronics<br />
CPU0: D VIPT write-back cache<br />
CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets<br />
CPU0: D cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets<br />
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256<br />
Kernel command line: console=ttySAC0,115200 loglevel=0 ubi.mtd=3 root=ubi0:rootfs rootfstype=ubifs<br />
Trying to install chained interrupt handler for IRQ0<br />
Trying to install chained interrupt handler for IRQ1<br />
Trying to install chained interrupt handler for IRQ32<br />
Trying to install chained interrupt handler for IRQ33<br />
PID hash table entries: 256 (order: 8, 1024 bytes)<br />
timer tcon=00600900, tcnt 29b0, tcfg 00001919,00000040, usec 000077ee<br />
Console: colour dummy device 80x30<br />
console [ttySAC0] enabled<br />
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)<br />
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)<br />
Memory: 64MB = 64MB total<br />
Memory: 61708KB available (2768K code, 265K data, 104K init)<br />
Calibrating delay loop... 665.19 BogoMIPS (lpj=1662976)<br />
Mount-cache hash table entries: 512<br />
CPU: Testing write buffer coherency: ok<br />
net_namespace: 64 bytes<br />
NET: Registered protocol family 16<br />
================> wifi status change from 0 to 0<br />
S3C6410 Power Management, (c) 2008 Samsung Electronics<br />
s3c6410: Initialising architecture<br />
S3C DMA-pl080 Controller Driver, (c) 2006-2007 Samsung Electronics<br />
Total 32 DMA channels will be initialized.<br />
SCSI subsystem initialized<br />
usbcore: registered new interface driver usbfs<br />
usbcore: registered new interface driver hub<br />
usbcore: registered new device driver usb<br />
NET: Registered protocol family 2<br />
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)<br />
TCP established hash table entries: 2048 (order: 2, 16384 bytes)<br />
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)<br />
TCP: Hash tables configured (established 2048 bind 2048)<br />
TCP reno registered<br />
NetWinder Floating Point Emulator V0.97 (double precision)<br />
io scheduler noop registered<br />
io scheduler anticipatory registered (default)<br />
io scheduler deadline registered<br />
io scheduler cfq registered<br />
S3C_LCD clock got enabled :: 111.000 Mhz<br />
LCD TYPE :: LTE480WV will be initialized<br />
Window[0] - FB1: map_video_memory: clear ff200000:000bb800<br />
FB1: map_video_memory: dma=53900000 cpu=ff200000 size=000bb800<br />
Console: switching to colour frame buffer device 100x30<br />
fb0: s3cfb frame buffer device<br />
s3c_lcd_set_power:1 <br />
PWM channel 1 set g_tcnt = 1000, g_tcmp = 480 <br />
S3C ADC driver, (c) 2007 Samsung Electronics<br />
S3C ADC driver successfully probed !<br />
s3c-uart.0: s3c_serial0 at MMIO 0x7f005000 (irq = 37) is a S3C<br />
s3c-uart.1: s3c_serial1 at MMIO 0x7f005400 (irq = 38) is a S3C<br />
s3c-uart.2: s3c_serial2 at MMIO 0x7f005800 (irq = 39) is a S3C<br />
s3c-uart.3: s3c_serial3 at MMIO 0x7f005c00 (irq = 40) is a S3C<br />
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize<br />
loop: module loaded<br />
Driver 'sd' needs updating - please use bus_type methods<br />
S3C NAND Driver, (c) 2007 Samsung Electronics<br />
S3C NAND Driver is using hardware ECC.<br />
NAND device: Manufacturer ID: 0xec, Chip ID: 0xdc (Samsung NAND 512MiB 3,3V 8-bit)<br />
Creating 5 MTD partitions on "NAND 512MiB 3,3V 8-bit":<br />
0x00000000-0x00040000 : "Bootloader"<br />
0x00040000-0x00340000 : "Kernel"<br />
0x00340000-0x00d40000 : "resource"<br />
0x00d40000-0x11140000 : "File System 1"<br />
0x11140000-0x20000000 : "User space"<br />
UBI: attaching mtd3 to ubi0<br />
UBI: physical eraseblock size: 262144 bytes (256 KiB)<br />
UBI: logical eraseblock size: 258048 bytes<br />
UBI: smallest flash I/O unit: 2048<br />
UBI: VID header offset: 2048 (aligned 2048)<br />
UBI: data offset: 4096<br />
UBI: attached mtd3 to ubi0<br />
UBI: MTD device name: "File System 1"<br />
UBI: MTD device size: 260 MiB<br />
UBI: number of good PEBs: 1040<br />
UBI: number of bad PEBs: 0<br />
UBI: max. allowed volumes: 128<br />
UBI: wear-leveling threshold: 4096<br />
UBI: number of internal volumes: 1<br />
UBI: number of user volumes: 1<br />
UBI: available PEBs: 10<br />
UBI: total number of reserved PEBs: 1030<br />
UBI: number of PEBs reserved for bad PEB handling: 10<br />
UBI: max/mean erase counter: 3/1<br />
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver<br />
UBI: background thread "ubi_bgt0d" started, PID 223<br />
usb_host_clk_en <br />
otg_phy_init ...................!<br />
s3c2410-ohci s3c2410-ohci: S3C OHCI<br />
s3c2410-ohci s3c2410-ohci: new USB bus registered, assigned bus number 1<br />
s3c2410-ohci s3c2410-ohci: irq 47, io mem 0x74300000<br />
usb usb1: configuration #1 chosen from 1 choice<br />
hub 1-0:1.0: USB hub found<br />
hub 1-0:1.0: 1 port detected<br />
s3c6410_OTGHCD s3c6410_OTGHCD: S3C6410 OTGHCD<br />
s3c6410_OTGHCD s3c6410_OTGHCD: new USB bus registered, assigned bus number 2<br />
s3c6410_OTGHCD s3c6410_OTGHCD: irq 58, io mem 0x7c000000<br />
===============Enter ID_DEVICE Mod===============<br />
===============Enter ID_DEVICE Mod===============<br />
usb usb2: configuration #1 chosen from 1 choice<br />
hub 2-0:1.0: USB hub found<br />
hub 2-0:1.0: 1 port detected<br />
otg_phy_init ...................!<br />
===============Enter ID_DEVICE Mod===============<br />
===============Enter ID_DEVICE Mod===============<br />
otg_phy_init ...................!<br />
Loaded s3c-udc version Aug 23 2010 (DMA Mode)<br />
input: midfun-keys as /devices/platform/midfun-keys/input/input0<br />
input: s3c-keypad as /devices/platform/s3c-keypad/input/input1<br />
s3c-keypad Initialized<br />
S3C Keypad Driver<br />
S3C24XX RTC, (c) 2004,2006 Simtec Electronics<br />
s3c2410-rtc s3c2410-rtc: rtc disabled, re-enabling<br />
s3c2410-rtc s3c2410-rtc: rtc core: registered s3c as rtc0<br />
S3C PWM Driver, (c) 2006-2007 Samsung Electronics<br />
i2c /dev entries driver<br />
s3c2410-i2c s3c2410-i2c: slave address 0x10<br />
s3c2410-i2c s3c2410-i2c: bus frequency set to 108 KHz<br />
s3c2410-i2c s3c2410-i2c: i2c-0: S3C I2C adapter<br />
s3c-hsmmc: card inserted.<br />
[s3c_hsmmc_probe]: s3c-hsmmc.1: at 0xc5000000 with irq 57. clk src: sclk_DOUTmpll_mmc1<br />
TCP cubic registered<br />
NET: Registered protocol family 1<br />
NET: Registered protocol family 17<br />
NET: Registered protocol family 15<br />
ieee80211: 802.11 data/management/control stack, git-1.1.13<br />
ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com><br />
ieee80211_crypt: registered algorithm 'NULL'<br />
ieee80211_crypt: registered algorithm 'WEP'<br />
ieee80211_crypt: registered algorithm 'CCMP'<br />
ieee80211_crypt: registered algorithm 'TKIP'<br />
VFP support v0.3: implementor 41 architecture 1 part 20 variant b rev 5<br />
s3c2410-rtc s3c2410-rtc: setting system clock to 2011-02-06 04:43:51 UTC (1296967431)<br />
UBIFS: recovery needed<br />
UBIFS: recovery completed<br />
UBIFS: mounted UBI device 0, volume 0, name "rootfs"<br />
UBIFS: file system size: 259854336 bytes (253764 KiB, 247 MiB, 1007 LEBs)<br />
UBIFS: journal size: 12902400 bytes (12600 KiB, 12 MiB, 50 LEBs)<br />
UBIFS: media format: w4/r0 (latest is w4/r0)<br />
UBIFS: default compressor: lzo<br />
UBIFS: reserved for root: 4952683 bytes (4836 KiB)<br />
VFS: Mounted root (ubifs filesystem).<br />
Freeing init memory: 104K<br />
UART err int.<br />
s3c-nand: 1 bit(s) error detected, corrected successfully<br />
s3c-nand: 1 bit(s) error detected, corrected successfully<br />
s3c-nand: 1 bit(s) error detected, corrected successfully<br />
mmc0: host does not support reading read-only switch. assuming write-enable.<br />
mmc0: new SD card at address ebe2<br />
mmcblk0: mmc0:ebe2 SD512 500224KiB <br />
mmcblk0: p1<br />
s3c-nand: 1 bit(s) error detected, corrected successfully<br />
s3c-nand: 1 bit(s) error detected, corrected successfully<br />
s3c-nand: 1 bit(s) error detected, corrected successfully<br />
UBI: attaching mtd4 to ubi1<br />
UBI: physical eraseblock size: 262144 bytes (256 KiB)<br />
UBI: logical eraseblock size: 258048 bytes<br />
UBI: smallest flash I/O unit: 2048<br />
UBI: VID header offset: 2048 (aligned 2048)<br />
UBI: data offset: 4096<br />
UBI: attached mtd4 to ubi1<br />
UBI: MTD device name: "User space"<br />
UBI: MTD device size: 238 MiB<br />
UBI: number of good PEBs: 955<br />
UBI: number of bad PEBs: 0<br />
UBI: max. allowed volumes: 128<br />
UBI: wear-leveling threshold: 4096<br />
UBI: number of internal volumes: 1<br />
UBI: number of user volumes: 1<br />
UBI: available PEBs: 0<br />
UBI: total number of reserved PEBs: 955<br />
UBI: number of PEBs reserved for bad PEB handling: 9<br />
UBI: max/mean erase counter: 2/1<br />
UBI: background thread "ubi_bgt1d" started, PID 500<br />
UBIFS: recovery needed<br />
UBIFS: recovery completed<br />
UBIFS: mounted UBI device 1, volume 0, name "ubifs1"<br />
UBIFS: file system size: 240758784 bytes (235116 KiB, 229 MiB, 933 LEBs)<br />
UBIFS: journal size: 12128256 bytes (11844 KiB, 11 MiB, 47 LEBs)<br />
UBIFS: media format: w4/r0 (latest is w4/r0)<br />
UBIFS: default compressor: lzo<br />
UBIFS: reserved for root: 4952683 bytes (4836 KiB)<br />
usbcore: registered new interface driver usbhid<br />
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver<br />
s3c-nand: 1 bit(s) error detected, corrected successfully<br />
s3c-nand: 1 bit(s) error detected, corrected successfully<br />
Adding 64492k swap on /mnt/swap/actual_swap. Priority:-1 extents:1 across:64492k<br />
usb 1-1: new full speed USB device using s3c2410-ohci and address 2<br />
usb 1-1: not running at top speed; connect to a high speed hub<br />
usb 1-1: configuration #1 chosen from 1 choice<br />
================> wifi status change from 0 to 1<br />
rtusb init ---><br />
<br />
<br />
=== pAd = c4f01000, size = 439728 ===<br />
<br />
RTMPAllocAdapterBlock, Status=0<br />
usbcore: registered new interface driver rt2870<br />
RTMPAllocTxRxRingMemory, Status=0<br />
-->RTUSBVenderReset<br />
RTUSBVenderReset<br />
Key1Str is Invalid key length(0) or Type(0)<br />
Key2Str is Invalid key length(0) or Type(0)<br />
Key3Str is Invalid key length(0) or Type(0)<br />
Key4Str is Invalid key length(0) or Type(0)<br />
1. Phy Mode = 0<br />
2. Phy Mode = 0<br />
NVM is Efuse and its size =2d[2d0-2fc] <br />
3. Phy Mode = 0<br />
RTMPSetPhyMode: channel is out of range, use first channel=1 <br />
== rt28xx_init, Status=0<br />
0x1300 = 00073200<br />
s3c_lcd_set_power:1 <br />
PWM channel 1 set g_tcnt = 1000, g_tcmp = 96 <br />
Terminate the task(RtmpMlmeTask) with pid(559)!<br />
Terminate the task(RtmpCmdQTask) with pid(560)!<br />
Terminate the task(RtmpTimerTask) with pid(558)!<br />
---> RTMPFreeTxRxRingMemory<br />
- RTMPFreeTxRxRingMemory<br />
================> wifi status change from 1 to 0<br />
usb 1-1: USB disconnect, address 2<br />
rtusb_disconnect: unregister usbnet usb-s3c24xx-1<br />
RtmpOSNetDevDetach(): RtmpOSNetDeviceDetach(), dev->name=ra0!<br />
RTUSB disconnect successfully<br />
</pre><br />
<br />
[[Category:Development Boards]]<br />
[[Categoty:Literati]]</div>Cschallehttps://elinux.org/index.php?title=TutorialWishlist&diff=74227TutorialWishlist2011-10-28T10:41:42Z<p>Cschalle: Add category and suggest deletion</p>
<hr />
<div>This page provides a place for compiling a list of tutorials that would be useful. Feel free to add to the list and update the list appropriately with a link when a tutorial is found or contributed.<br />
<br />
==Beginner==<br />
<br />
==Intermediate==<br />
<br />
==Advanced==<br />
<br />
[[Category:ToDelete]]</div>Cschallehttps://elinux.org/index.php?title=Preemption_Instrumentation&diff=74221Preemption Instrumentation2011-10-28T10:41:07Z<p>Cschalle: Add categories</p>
<hr />
<div>@) '''''Preliminary Draft''''' @) under construction<br />
<br />
<br />
<br />
== Introduction ==<br />
Preemption instrumentation is used to detect and measure periods where the kernel is non-preemptible<br />
for a long period of time. The maximum non-preemptible period corresponds with the maximum<br />
scheduling latency in the kernel, and thus an important characteristic of realtime accuracy.<br />
<br />
By instrumenting the kernel to measure the longest preemption-off periods, it becomes possible<br />
to identify and resolve realtime problems with the kernel.<br />
<br />
=== CELF 1.0 (2.4.20-based) system ===<br />
The CELF 1.0 kernel contains something called "preempt-times", to find the maximum preemption-off<br />
periods in the kernel.<br />
<br />
Not much information is available about this system. But here are some pointers if you want<br />
to poke around:<br />
- the code for this is conditional on CONFIG_PREEMPT_TIMES<br />
- the main source file for the system appears to be in the file /kernel/preem_latency.c<br />
<br />
The 2.4 code generates a report of the 20 longest preempt-off windows per-CPU, identified by start and end source file and line number, whenever a /proc file is read. <br />
=== preemption latency measurementin 2.6 ===<br />
Con Kolivas introduced a preemption latency measurement mechanism for 2.6.8-rc1<br />
<br />
The mechanism sets a reporting threshold and dumps function names and addresses of the start/stop points, plus a stack trace of the end point, to the console/syslog if the time exceeds that threshold.<br />
<br />
Con said:<br />
<hr /><br />
Because of the recent discussion about latency in the kernel I asked William Lee Irwin III to help create some instrumentation to determine where in the kernel there were still sustained periods of non-preemptible code. He hacked together this simple patch which times periods according to the preempt count. Hopefully we can use this patch in the advice of Linus to avoid the "mental masturbation" at guessing where latency is and track down real problem areas.<br />
<br />
It is enabled via a config option and by setting the threshold at boot by passing the parameter:<br />
<code>preempt_thresh=2</code> to set the threshold at 2ms for example.<br />
<br />
The output is a warning in syslog like so:<br />
<br />
5ms non-preemptible critical section violated 2 ms preempt threshold starting at add_wait_queue+0x21/0x82 and ending at add_wait _queue+0x4a/0x82<br />
<br />
I would not recommend using this patch for daily use but please try it out on multiple setups/filesystems etc and help us track down the areas. Unfortunately I am not personally capable of fixing the code paths in question so I'll need the help of others in this.<br />
<hr /><br />
<br />
==== LKML discussion ====<br />
The thread of kernel discussion about this feature is [http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=2h6xN-6yB-13%40gated-at.bofh.it&rnum=2&prev=/groups%3Fq%3D%2BInstrumenting%2Bhigh%2Blatency%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3D2h6xN-6yB-13%2540gated-at.bofh.it%26rnum%3D2 here].<br />
<br />
<br />
=== Comparison of two systems ===<br />
Todd Poynor of [[Monta Vista]] Software wrote:<br />
<hr /><br />
The code in the CELF tree is an older version of the instrumentation shipped with [[Monta Vista]]'s products; it originated (I believe) from Jun Sun and George Anzinger (a.o.?), and was formerly publically maintained during 2.4 and perhaps 2.5 as the preempt-times patch by Robert Love.<br />
<br />
I haven't looked at wli's new patch in detail. The instrumentation is probably similar between the two, except that the 2.4 code doesn't handle conditional scheduling "lock break" -- there was a community-contributed version that fixed this, but preempt-times went into unmaintained status around that time and nobody picked it up. There are a number of special cases in the 2.4 code, such as explicit scheduling by a process with a non-zero preempt count, that are probably better handled by the conditional scheduling logic. There's also some obscure reporting of softirq masks handled in preempt-off windows for softirq processing, which might not be appropriate for 2.6 or for systems that run softirqs in threads.<br />
<br />
<br />
<br />
The William Irwin patch was incorporated into Ingo Molnar's Involuntary preemption patch<br />
=== Ingo's patch ===<br />
<br />
=== Realfeel ===<br />
<br />
=== latencytest-0.5.5 ===<br />
Takashi Iwai, as leader in the ALSA project, is the author of a program called "latencytest"<br />
<br />
See http://www.alsa-project.org/~iwai/alsa.html#LatencyTest<br />
<br />
=== Rationale ===<br />
This is useful for finding spots of maximum preemption off.<br />
<br />
== Downloads ==<br />
=== Patch ===<br />
- Patch for 2.6.7 is here:<br />
- base patch: [[Media:preempt-timing-1.patch]]<br />
- fixup patch: [[Media:preempt-timing-fixup.patch]]<br />
''NOTE: William Lee Irwin III said he would be providing a cleaned-up patch against 2.6.8 or -mm soon''<br />
<br />
- Patch for 2.6.8-rc2 is here:<br />
- Ingo Molnar made some additional fixes, and posted an updated patch<br />
- see http://redhat.com/~mingo/voluntary-preempt/preempt-timing-on-2.6.8-rc2-O2<br />
- see continuing discussion of this version at: http://lkml.org/lkml/2004/8/2/66<br />
- try searching for "voluntary preempt" on lkml for additional discussion<br />
<br />
=== Utility programs ===<br />
None<br />
<br />
== How To Use ==<br />
See introduction text.<br />
<br />
Ingo Molnar wrote this in another thread:<br />
<br />
<pre>the kernel command line option for immediate 2:1 is:<br />
<br />
"voluntary-preempt=2 preempt=1"<br />
</pre><br />
<br />
== Sample Results ==<br />
Con wrote:<br />
<hr /><br />
This works very nicely standalone getting us this for example with the <br />
fixed patch:<br />
<br />
<pre><br />
6ms non-preemptible critical section violated 1 ms preempt threshold <br />
starting at exit_mmap+0x1c/0x188 and ending at exit_mmap+0x118/0x188<br />
[<c011d769>] dec_preempt_count+0x14f/0x151<br />
[<c014d0d4>] exit_mmap+0x118/0x188<br />
[<c014d0d4>] exit_mmap+0x118/0x188<br />
[<c011df0a>] mmput+0x61/0x7b<br />
[<c01226fa>] do_exit+0x142/0x510<br />
[<c014c928>] unmap_vma_list+0xe/0x17<br />
[<c0122b8a>] do_group_exit+0x41/0xf9<br />
[<c0105fd5>] sysenter_past_esp+0x52/0x71<br />
</pre><br />
<br />
which then an objdump of the inlined code has allowed us to track it <br />
down to this:<br />
<br />
<pre><br />
profile_exit_mmap(mm);<br />
lru_add_drain();<br />
c014cfce: e8 18 72 ff ff call c01441eb <lru_add_drain><br />
spin_lock(&mm->page_table_lock);<br />
c014cfd3: e8 16 06 fd ff call c011d5ee <inc_preempt_count><br />
</pre><br />
<br />
<br />
That's pretty specific. I dont think this comes under the umbrella of <br />
statistics as such. Sure it can be modified to do it but I was looking <br />
for a tool to find where specific latency hotspots still exist.<br />
<br />
== Future Work ==<br />
Here is a list of things that could be worked on for this feature:<br />
- <br />
<br />
<br />
== uncategorized information ==<br />
Here is some more stuff I found, that I haven't categorized yet.<br />
<br />
* realfeel.c is a program which programs the RTC to generate data at the rate of 2KHz, and measure the deviation from expected time to the actual time of wakeup of the program. It is available at:<br />
* surely LTT could show data on interrupt and scheduling latency (with a good post-processor)<br />
* surely HRT facilities could be used to create short periodic interrupt timer tests<br />
<br />
* There's a good article on preemption testing at: [http://www.linuxdevices.com/articles/AT8906594941.html Linux Scheduler Latency] (This is the Clark Williams article)<br />
<br />
=== stress testing ===<br />
Here's information about stress tests that were conducted by Clark Williams in his <br />
preemption testing in March 2002:<br />
<br />
After a bit of experimentation, I set up stress-kernel to run the following programs:<br />
<br />
** NFS-COMPILE<br />
** TTCP<br />
** FIFOS_MMAP<br />
** P3_FPU<br />
** FS<br />
** CRASHME<br />
<br />
<br />
The NFS-COMPILE script is the repeated compilation of a Linux kernel, via an NFS filesystem exported over the loopback device. The TTCP (Test TCP) program sends and receives large data sets via the loopback device. FIFOS_MMAP is a combination test that alternates between sending data between two processes via a FIFO and mmap'ing and operating on a file. The P3_FPU test does operations on floating point matrices. The FS test performs all sorts of unnatural acts on a set of files, such as creating large files with holes in the middle, then truncating and extending those files. Finally the CRASHME test generates buffers of random data, then jumps to that data and tries to execute it.<br />
<br />
<br />
[[Category:Kernel]]<br />
[[Category:Linux]</div>Cschallehttps://elinux.org/index.php?title=RTS7751R2D_Handling_Manual&diff=74203RTS7751R2D Handling Manual2011-10-28T10:40:18Z<p>Cschalle: Add category</p>
<hr />
<div>'''<code>RTS7751R2D</code> Linux software handling manual (CELF 040126 kernel version)'''<br />
<br />
[[Image:REnesasSH4.JPG]]<br />
<br />
'''Table of Contents:'''<br />
<br />
<br />
== Technology Adopted in this release ==<br />
{| <br />
|- <br />
| bgcolor="#80FF80" | <br />
| bgcolor="#80FF80" | Technology<br />
| bgcolor="#80FF80" align="center" | Support Status<br />
| bgcolor="#80FF80" align="center" | Arch Dependent<br />
| bgcolor="#80FF80" | Comment<br />
|- <br />
| 1<br />
| Kernel preemption<br />
| align="center" | ○<br />
| align="center" | No<br />
| .<br />
|- <br />
| 2<br />
| Lock breaking<br />
| align="center" | △<br />
| align="center" | No<br />
| .<br />
|- <br />
| 3<br />
| O(1) Scheduler<br />
| align="center" | ○<br />
| align="center" | No<br />
| .<br />
|- <br />
| 4<br />
| Prioritized Work Queues<br />
| align="center" | ×<br />
| align="center" | ??<br />
| Celf as is<br />
|- <br />
| 5<br />
| High Res POSIX timers<br />
| align="center" | ×<br />
| align="center" | Yes<br />
| SH-4 can use TMU3/4 as a High Res Timer. Mitsubishi has posted Hi-res timer support patch, but not yet merged to CELF kernel<br />
|- <br />
| 6<br />
| Kernel XIP<br />
| align="center" | ○<br />
| align="center" | No<br />
| .<br />
|- <br />
| 7<br />
| User-space XIP<br />
| align="center" | △<br />
| align="center" | No<br />
| .<br />
|- <br />
| 8<br />
| Parallel and deferred I/O initialization<br />
| align="center" | ×<br />
| align="center" | ??<br />
| .<br />
|- <br />
| 9<br />
| Dynamic Power Management (DPM) Framework<br />
| align="center" | ×<br />
| align="center" | YES<br />
| SH-4 can not scale clock<br />
|- <br />
| 10<br />
| CPU Frequency Scaling<br />
| align="center" | ×<br />
| align="center" | Yes<br />
| SH-4 can not scale clock<br />
|- <br />
| 11<br />
| Deferred periodic kernel process<br />
| align="center" | ×<br />
| align="center" | ??<br />
| Celf as is<br />
|- <br />
| 12<br />
| Protected RAM File System<br />
| align="center" | △<br />
| align="center" | No<br />
| .<br />
|}<br />
<br />
.<br />
{| <br />
|- <br />
| Support Status<br />
| ○ = Activated in this release<br />
|- <br />
| △ = code merged, but not activated<br />
|- <br />
| × = not available in this release<br />
|- <br />
| Arch dependency<br />
| "No" means common in all architecture<br />
|}<br />
<br />
== Download and Install tool chain ==<br />
Download tool chain (RPM) for SH-3/4 processor from http://tree.celinuxforum.org/pubwiki/moin.cgi/ToolChains<br />
<br />
SH toolchain [http://tree.celinuxforum.org/toolchains/tools_sh4_RPMS.tar.gz tools_sh4_RPMS.tar.gz]<br />
<br />
It contains gcc 3.2.3, binutil 2.13.90.0.18 for compiling SH-Linux code.<br />
<br />
To install this tool chain.<br />
<br />
<pre><br />
#tar xvzf tools_sh4_RPMS.tar.gz<br />
#rpm -i binutils-sh4-2.13.90.0.18-1.i686.rpm<br />
#rpm -i gcc-sh4-3.2.3-2.i686.rpm<br />
</pre><br />
<br />
And you can also obtain libraries for compiling some applications as user-space packages. [http://tree.celinuxforum.org/toolchains/Userland_sh4_RPMS.tar.gz Userland_sh4_RPMS.tar.gz]<br />
<br />
<pre><br />
#rpm -i --force --ignorearch glibc-devel-sh4-2.3.1-3u.sh4.rpm<br />
</pre><br />
<br />
<br />
'' <> Note - You would like to use these packages on Windows, you need to install *cygwin* packages to Cygwin.<br />
''<br />
<br />
It will automatically copy each file to proper location. If not defined please add “/usr/local/bin” to your search path. If everything successfully installed, you can start gcc compiler using following command<br />
<br />
<pre><br />
#sh4-linux-gcc –v<br />
</pre><br />
<br />
you can see version info.<br />
<br />
== Board Hardware manual ==<br />
You can download Hardware manual of rts7751r2d platform from [[Media:R2DHWmanual.pdf]]<br />
<br />
== Update your own kernel ==<br />
Download kernel source code (SRPM) from from http://tree.celinuxforum.org/pubwiki/moin.cgi/ToolChains<br />
<br />
<pre><br />
#cd (your working location)<br />
#tar xzvf celinux-040126.tgz<br />
</pre><br />
<br />
It will create directory named “celinux-040126”<br />
<br />
Then config your kernel using “menuconfig” tool.<br />
<br />
'' <> Note - You CAN NOT use “xconfig” tool to current CE-Linux-040126 kernel code''<br />
<br />
<pre><br />
#make menuconfig<br />
#make dep<br />
#make zImage<br />
</pre><br />
<br />
<br />
If there is no error, you can see “vmlinx” created in project root and “zImage” in ./arch/sh/boot directory.<br />
Use “zImage” file as a compressed kernel image to copy to CF card.<br />
<br />
== Initializing CF card for Linux (ext2/swap format & create partition) ==<br />
CF card must be formatted “ext2”. You can format and initialize CF card using following command<br />
<br />
<pre><br />
#mount -t ext2 /dev/(your CF device name) /mnt/cf (depends on your environment)<br />
#/sbin/fdisk /dev/(your CF device name)<br />
</pre><br />
<br />
<br />
<pre><br />
SH IPL+eth version 1.0, Copyright (C) 2000 Free Software Foundation, Inc.<br />
? --- Show this message (HELP)<br />
b --- Boot the system<br />
g --- Invoke GDB stub<br />
l --- Show about license<br />
w --- Show about (no)warranty<br />
m --- Serial load<br />
n --- Ether Boot<br />
z --- JMP zImage<br />
j --- JMP 0x8c002000<br />
i --- Board Infomation<br />
d --- memory display db,dw,dl<br />
e --- memory edit eb,ew,el<br />
v --- Show version infomation</pre><br />
<br />
<br />
<pre><br />
#/sbin/mkfs –t ext2 /dev/(your CF device normal partition name) <br />
<- ex “/dev/sda1” not “/dev/sda”<br />
#/sbin/mkswap /dev/(your CF device swap partition name)<br />
<- ex. “/dev/sda2”<br />
</pre><br />
<br />
If you are using USB CF card adaptor, your CF device name would be /dev/sda1<br />
If you are using CF slot built in your notebook PC, it would be /dev/hde1<br />
<br />
== Copy root file image to ext2 formatted CF card ==<br />
You can use root_file binary image (RPM) from from [http://tree.celinuxforum.org/toolchains/Userland_sh4_RPMS.tar.gz Userland_sh4_RPMS.tar.gz]<br />
<br />
<br />
<pre><br />
#tar xvzf Userland_sh4_RPMS.tar.gz<br />
#mount /dev/(your CF device name) /mnt/cf (depends on your environment) <br />
#cd /mnt/cf<br />
#rpm2cpio <package_name>.sh4.rpm | cpio -id<br />
</pre><br />
<br />
<br />
'' <> Note - You need to resolve package conflict by yourself''<br />
<br />
See appendix A in detail<br />
<br />
== Linux kernel update on CF card ==<br />
Compressed Linux kernel image “zImage” is stored in /boot directory of CF card. So you need to overwrite “zImage” to update kernel. <br />
And also you need to execute “lilo” command on host machine to update kernel information. You may find “lilo” command in your host environment even you are not using “lilo” as a boot loader. You may be using GRUB as a boot loader in your host environment. You have to add “-r” option to “lilo” command so that “lilo” can refer external kernel information named “lilo.conf”. <br />
<br />
** DANGEROUS** If you missed to add “-r” option, you may corrupt your host kernel environment. Before executing “lilo” command, you need to check “lilo.conf” file saved in /etc directory of CF card and “boot.b” file in /boot directory of CF card. Due to your CF location in host environment, you may need to update “lilo.conf” description. The root file image provided from us contains “lilo.conf” file that defines “boot=/dev/sda, disk=/dev/sda”. It expect CF card can be accessed as /dev/sda, it may be expecting USB CF card adopter is used for CF card access. If your CF card can be accessed as “/dev/hde”, you need to update “boot=/dev/hde, disk=/dev/hde” in “lilo.conf” file.<br />
<br />
To copy kernel image CF card<br />
<br />
<pre><br />
mount /dev/(your CF device name) /mnt/cf (depends on your environment)<br />
cp (your working location)/arch/sh/boot/zImage /mnt/cf/boot<br />
/sbin/lilo –r /mnt/cf<br />
</pre><br />
<br />
If “Append sh-linux *” displayed at “lilo” command, your kernel was successfully updated on CF card<br />
<br />
== Console connection ==<br />
RTS 7751R2D (R2D) support serial console terminal connected to CN7 (upper Dsub connector) using cross cable. Serial communication setting is<br />
<br />
<pre><br />
- Baud rate = 115200<br />
- Data = 8bit<br />
- Parity = none<br />
- Stop = 1 bit<br />
- Flow control = none<br />
</pre><br />
<br />
You can modify console setting defined in boot parameter to support USB keyboard as a input device. Also you can re-assign console screen to LCD/VGA output managed by SM501 display controller.<br />
<br />
== Linux kernel start from CF ==<br />
RTS 7751R2D (R2D) platform support is shipped with IPL (boot loader) program that is burned on FROM. We adopt IPL named "ipl+g" developed by Mr.Niibe he is a maintainer of Linux-SH, and we add some futures to original "ipl+g" to support various kind of boot method as follows.<br />
<br />
* CF boot (boot compressed kernel image saved in CF card)<br />
* Network boot (boot kernel from host machine connected via LAN)<br />
* XIP boot (boot executable kernel image saved in FROM expansion card)<br />
* JTAG debugger boot (start kernel already loaded into SD-RAM using JTAG debugger)<br />
<br />
These boot method depends on SW6 setting. You can find SW6 near ALTERA FPGA.<br />
<br />
{| <br />
|- <br />
| bgcolor="#80FF80" | <br />
| bgcolor="#80FF80" | ON ( ↓ )<br />
| bgcolor="#80FF80" | OFF ( ↑ )<br />
|- <br />
| SW6-1 (○○○●)<br />
| auto start (same as type “b”)<br />
| display prompt when IPL start<br />
|- <br />
| SW6-2 (○○●○)<br />
| start XIP kernel<br />
| normal boot<br />
|}<br />
<br />
So please confirm SW6 is correctly set due to your boot requirement.<br />
<SW6 setting><br />
{| <br />
|- <br />
| bgcolor="#80FF80" | <br />
| bgcolor="#80FF80" | kernel boot method<br />
| bgcolor="#80FF80" | SW6-4/SW6-3<br />
| bgcolor="#80FF80" | SW6-2<br />
| bgcolor="#80FF80" | SW6-1<br />
| bgcolor="#80FF80" | comment<br />
|- <br />
| 1<br />
| CF, interactive<br />
| Don’t care for boot<br />
| OFF<br />
| OFF<br />
| type “h” for help, “b” for normal boot<br />
|- <br />
| 2<br />
| CF, auto boot<br />
| OFF<br />
| ON<br />
| boot automatically from CF<br />
|- <br />
| 3<br />
| Network boot<br />
| OFF<br />
| OFF<br />
| type n“ for ipl prompt<br />
|- <br />
| 4<br />
| JTAG debugger mode<br />
| OFF<br />
| OFF<br />
| type “j” for ipl prompt<br />
|- <br />
| 5<br />
| XIP<br />
| ON<br />
| ON<br />
| boot automatically from FROM board<br />
|}<br />
<br />
== Kernel start from network ==<br />
<br />
When downloading the kernel from network, use BOOTP/DHCP server (on <br />
the host machine) and obtain an IP address and file name to be <br />
downloaded.<br />
<br />
'''Host side setting'''<br />
<br />
* NFS Server<br />
* DHCP/BOOTP Server<br />
<br />
Setting example for the following host machine is described in the <br />
Appendix C.<br />
<br />
<pre><br />
R2D IP Address: 192.168.10.72<br />
Host IP Address: 192.168.10.70<br />
R2D MAC Address: 00:00:e1:6b:33:5d<br />
Kernel Download Directory: /tftpboot<br />
NFS Root Directory: /tftpboot/rootfs<br />
</pre><br />
<br />
<br />
'''Kernel Configrarion'''<br />
<br />
Kernel Commandline and kernel option for NFS root mount as follows.<br />
<br />
* "mem=64M console=ttySC0,115200 root=/dev/nfs ip=boopt"<br />
* CONFIG_NFS_FS<br />
* CONFIG_ROOT_NFS<br />
<br />
You can also use r2d_nfs.config under arch/sh directory.<br />
<br />
After building a kernel, copy arch/sh/boot/zImage to /tftpboot which is specified in the setting file of BOOTP/DHCP server on host machine.<br />
Enter "n" command for network booting on the prompt.<br />
<br />
<br />
<pre><br />
Boot Log<br />
> n<br />
n<br />
Booting from network!<br />
- ioaddr 0xfe242000, addr 00:00:e1:6b:33:5d 100Mbps<br />
full-duplex<br />
Searching for server (BOOTP/DHCP)...<br />
IP Address: 192.168.192.190 <- R2D IP Address<br />
Server: 192.168.192.189 <- Host IP Address<br />
Kernel to load: "/tftpboot/zImage" <- File to be downloaded<br />
Loading Kernel: /tftpboot/zImage ..............................................<br />
</pre><br />
<br />
<br />
== Kernel start from FROM extension card (Kernel space XIP) ==<br />
<br />
'''Build XIP kernel'''<br />
<br />
Build XIP kernel according to the following procedure. The XIP kernel <br />
will be configured at CONFIG_XIP_KERNEL.<br />
<br />
<pre><br />
#cd celinux-040126<br />
#cp arch/sh/r2d_xip.config .config<br />
#make ARCH=sh CROSS_COMPILE=sh4-linux- oldconfig <br />
#make ARCH=sh CROSS_COMPILE=sh4-linux- dep <br />
#make ARCH=sh CROSS_COMPILE=sh4-linux- xImage <br />
</pre><br />
<br />
<br />
xImage.bin file will be created under celinux-040126 directory. Copy <br />
this file to CF or NFS root.<br />
<br />
<br />
'''Copy XIP kernel on CF to FROM extension card'''<br />
<br />
Bootloader jumps to the 0x00020000 (mtd1 area).<br />
XIP kernel image uses regular kernel (zImage) that MTD is usable and <br />
writes in mtd1 area.<br />
<br />
<br />
<pre><br />
#eraseall /dev/mtd1<br />
#dd if=xImage.bin of=/dev/mtd1<br />
</pre><br />
<br />
<br />
In the same way, cramfs image can be written in mtd2/mtd3.<br />
<br />
<br />
'''SW6 setting for XIP'''<br />
<br />
When having the SW6-2 "ON" and turn on R2D, serial console shows the <br />
message "booting XIP Kernel at 80020000" and XIP kernel will start.<br />
<br />
<br />
'''[[Flash ROM]] Mapping'''<br />
<br />
Currently, MTD device mapping on [[Flash ROM]] is set as below.<br />
{| <br />
|- <br />
| 0x00000000-0x00020000<br />
| "bootloader"<br />
| <br />
|- <br />
| 0x00020000-0x00320000<br />
| "mtdblock1"<br />
| XIP kernel<br />
|- <br />
| 0x00320000-0x00520000<br />
| "mtdblock2"<br />
| <br />
|- <br />
| 0x00520000-0x01000000<br />
| "mtdblock3"<br />
| <br />
|}<br />
<br />
== RUN demo program (SM501 multi-frame graphics demo) ==<br />
In CELF SDK CD-ROM, you can find a demo application “demo.tgz” that is designed runs on this platform. <br />
We wrote some sample code for SM501 multi-frame operation.<br />
<br />
[ SM501 debug command ]<br />
{| <br />
|- <br />
| bgcolor="#80FF80" | <br />
| bgcolor="#80FF80" | name<br />
| bgcolor="#80FF80" | function<br />
| bgcolor="#80FF80" | usage<br />
|- <br />
| 1<br />
| view<br />
| display enabler<br />
| '''view 1 1''' = enable(show) /dev/fb1<br />
|- <br />
| '''view 1 0''' = disable(hide) /dev/fb1<br />
|- <br />
| 2<br />
| bitmap<br />
| display bitmap data<br />
| '''bitmap /dev/fb0 test.bmp'''<br />
|- <br />
| 3<br />
| ckey<br />
| chroma key setting<br />
| '''chkey /dev/fb2 1 7fff0000''' = enable fb2 and set chroma key register as 7fff0000<br />
|- <br />
| This function only effective on <code>VideoAlpha</code> and Alpha plane<br />
|- <br />
| 4<br />
| cap<br />
| capture enabler<br />
| '''cap 1''' = enable video capture<br />
|- <br />
| '''cap 0''' = disable video capture<br />
|- <br />
| 5<br />
| zoom<br />
| scaler setting<br />
| '''zoom /dev/fb1''' 87ff87ff = set zoom register value<br />
|- <br />
| 6<br />
| csr<br />
| H/W cursor color setting<br />
| '''csr 2222 3333 4444''' = set cursor color register<br />
|- <br />
| 7<br />
| chg<br />
| display size and location set<br />
| '''chg /dev/fb1 320 240 640 480 100 100''' =set /dev/fb1 size as 320 x 240 and set real display size as640 x 480 and set display location (100, 100)<br />
|- <br />
| This command only effective on movable plane exceptpanel screen<br />
|- <br />
| 8<br />
| mod<br />
| set register value<br />
| '''mod ''register_address''''' = modify register value<br />
|- <br />
| 9<br />
| mod2<br />
| show register value<br />
| '''mod2 ''register_address''''' = display current register value<br />
|}<br />
<br />
Some study on SM501 frame architecture<br />
SM501 has 5 frame buffer and 2 H/W cursor plane. Each frame has following functions.<br />
<br />
'''/dev/fb0''' ''voyager_video_fb'' 0xb0000000<br />
<br />
Display plane for Panel(LCD) and parent frame for all other display frame.<br />
Currently fb0 size is set to 640 x 480. Have scroll capability.<br />
<br />
'''/dev/fb1''' ''voyager_video_fb'' 0xb00a0000 & 0xb0140000<br />
<br />
Frame for video screen and parent of “video_alpha” frame<br />
flexible resolution, video capture function, H/W scaller function, accept YUV data<br />
Can use double buffer architecture ( fb1 has two separate memory space)<br />
<br />
'''/dev/fb2''' ''voyager_valpha_fb'' 0xb01e0000<br />
<br />
Frame for video_alpha screen, son of video (fb1)<br />
flexible resolution, chroma key function, H/W scaller function, accept YUV data<br />
This frame can be displaied only upon video frame (fb1), so if video frame is<br />
disabled, this frame also disabled automatically.<br />
<br />
'''/dev/fb3''' ''voyager_alpha_fb'' 0xb0280000<br />
<br />
Frame for alpha screen.<br />
flexible resolution, chroma key function, accept YUV data<br />
This chroma key can be enable on whole frame including fb0.<br />
No H/W scaller capability, can not accept YUV format<br />
<br />
'''/dev/fb4''' ''voyager_cursor_fb'' 0xb0320000<br />
<br />
H/W cursor frame.<br />
Size is only 64 x 64 and 2 bit color setting (you can choose 3 color from 16 bit color)<br />
rest of 1 color must be transparent color.<br />
<br />
'''/dev/tty0'''<br />
<br />
console input for /dev/fb0. Screen saver function supported in H/W.<br />
You can display text data using re-direct function <br />
“cat /dev/tty0 > /dev/tty0” to show LCD character.<br />
Initial setting for fb0 is 640 x 480 16bit color RGB screen.<br />
<br />
== Swap console device ==<br />
<br />
Original Linux code for this board is expecting serial console device as a system console that is terminal connected to CN7 (upper Dsub connector). This setting is defined as a kernel boot parameter in “lilo.conf”. As this R2D board has a VGA output and USB host interface, you can use CRT as a console monitor and USB keyboard as a system keyboard. This part is introducing how to activate these alternative console devices.<br />
<br />
'''< How to use VGA monitor as a system console >'''<br />
<br />
To use VGA monitor as a system display, you have to declare following sentence in “lilo.conf” append line.<br />
<br />
<pre><br />
video=voyager_crt_fb:mode:640x480x16<br />
</pre><br />
<br />
After you modify “lilo.conf”, you need to run “lilo –r” command to activate this neww setting. Then /dev/fb0 is assigned to “voyager_crt_fb” device, so you can see booting message on VGA monitor screen.<br />
<br />
'''< How to use USB keyboard as a system keyboard >'''<br />
<br />
You can use USB keyboard as input device which name is /dev/input/mice as following kernel configration.<br />
<br />
<pre><br />
CONFIG_USB=y<br />
CONFIG_USB_OHCI_VOYAGERGX=y<br />
CONFIG_USB_USE_INTERNAL_MEMORY=y<br />
CONFIG_USB_KBD=y<br />
CONFIG_USB_MOUSE=y<br />
CONFIG_INPUT=y<br />
CONFIG_INPUT_KEYBDEV=y<br />
CONFIG_INPUT_MOUSEDEV=y<br />
</pre><br />
<br />
<br />
'''< CRT output switching >'''<br />
<br />
Following figure shows SM501 frame buffer architecture. If you switch “merge” setting between CRT and Panel (red circled position) you can switch CRT output even If you assigned CRT as a console device. This “merge” control is managed by 9th bit of “CRT display register”. I attached small program “vc”Media:vc.zipthat just reverse this bit.<br />
<br />
Also I attached two file “.inputrc” and “inittab” for activating USB hot key to switch this bit. So copy “.inputrc” to /root directory and modify “initrc” as attched so that system login automatically after boot and accept hot key.<br />
Due to setting defined in “.inputrc” current hot ket is “CTRL+F” to switch CRT output.<br />
<br />
== Appendix A (root_fs information) ==<br />
<hr /><br />
Pre defined user accounts<br />
{| <br />
|- <br />
| bgcolor="#80FF80" | <br />
| bgcolor="#80FF80" | user name<br />
| bgcolor="#80FF80" | password<br />
| bgcolor="#80FF80" | login<br />
|- <br />
| 1<br />
| root<br />
| (none)<br />
| accept console login<br />
|- <br />
| 2<br />
| guest<br />
| guest<br />
| accept console, ftp, telnet login<br />
|}<br />
<br />
<hr /><br />
Network setting --- modify following script to fit your environment<br />
<br />
<pre><br />
/etc/sysconfig/network-scripts/ifcfg-eth0<br />
BROADCAST=192.168.10.255<br />
IPADDR=192.168.10.76<br />
NETMASK=255.255.255.0<br />
NETWORK=192.168.10.0<br />
ONBOOT=yes<br />
</pre><br />
<br />
<br />
<hr /><br />
Pre installed package list<br />
{| <br />
|- <br />
| glibc-2.3.1-3u<br />
| mgetty-1.1.30-2u<br />
|- <br />
| cracklib-2.7-20u<br />
| mingetty-1.00-5u<br />
|- <br />
| libcap-1.10-15u<br />
| minicom-2.00.0-12u<br />
|- <br />
| libtermcap-2.0.8-32u<br />
| modutils-2.4.22-8u<br />
|- <br />
| pam-0.75-46u<br />
| net-tools-1.60-12u<br />
|- <br />
| popt-1.6.3-1u<br />
| portmap-4.0-52u<br />
|- <br />
| tcp_wrappers-7.6-34.as21.1u<br />
| psmisc-21.2-4u<br />
|- <br />
| zlib-1.1.4-7u<br />
| procps-2.0.11-6u<br />
|- <br />
| setup-2.5.23-1u<br />
|- <br />
| bash-2.05b-16u<br />
| sh-utils-2.0.12-3u<br />
|- <br />
| busybox-0.60.5-5u<br />
| sox-12.17.3-10u<br />
|- <br />
| bzip2-1.0.2-8u<br />
| strace-4.4.93-2u<br />
|- <br />
| devfsd-1.3.25-1u<br />
| sysklogd-1.4.1-12u<br />
|- <br />
| dhcp-3.0pl1-20u<br />
| <code>SysVinit-2.84-7u</code><br />
|- <br />
| e2fsprogs-1.32-6u<br />
| tar-1.13.25-11u<br />
|- <br />
| filesystem-2.2.1-2u<br />
| tcpdump-3.7.2-1u<br />
|- <br />
| fileutils-4.1.9-11u<br />
| telnet-0.17-25u<br />
|- <br />
| findutils-4.1.7-9u<br />
| termcap-11.0.1-16u<br />
|- <br />
| ftp-0.17-17u<br />
| textutils-2.0.21-5u<br />
|- <br />
| gawk-3.1.1-9u<br />
| tinylogin-1.4-1u<br />
|- <br />
| gdb-5.3-1u<br />
| util-linux-2.11y-4u<br />
|- <br />
| grep-2.5.1-7u<br />
| vsftpd-1.2.0-2.1<br />
|- <br />
| hdparm-5.2-4u<br />
| wireless-tools-25-4u<br />
|- <br />
| initscripts-7.04-1u<br />
| xinetd-2.3.10-2u<br />
|- <br />
| iptables-1.2.7a-2u<br />
| iputils-20020927-2u<br />
|- <br />
| iproute-2.4.7-7u<br />
| setup-rts7751r2d-1.0.0-1u<br />
|- <br />
| kernel-pcmcia-cs-3.1.31-13u<br />
| ipl+eth-1.0.0-1u<br />
|- <br />
| MAKEDEV-1.0.0-1u<br />
|}<br />
<br />
== Appendix B (default “lilo.conf” in /etc directory) ==<br />
<br />
<pre><br />
linear<br />
# You must appoint your CF mounting device name on following lines.<br />
# Default CF mounting device is /dev/hdc.<br />
boot = /dev/sda<br />
disk = /dev/sda<br />
<br />
bios = 0x80<br />
#<br />
delay = 30<br />
#vga = normal<br />
image = /boot/zImage<br />
label = linux<br />
root = /dev/hda1<br />
read-only<br />
</pre><br />
<br />
<br />
If you use USB CF card adaptor in Linux host environment, CF device can be accessed as “/dev/sda” .<br />
This “lilo.conf” is expecting CF card can be there. If your CF device name is different, you need to modity”boot=” and “disk=” portion in this “lilo.conf” file.<br />
<br />
To update kernel, you have to do “lilo –r” command in host environment. “-r” option is mandatory.<br />
Also you have to use “boot.b” file, that can be copy from root_fs/boot directory.<br />
<br />
== Appendix C ==<br />
<hr /><br />
Example of /etc/dhcpd.conf<br />
<br />
<pre><br />
ddns-update-style ad-hoc;<br />
<br />
subnet 192.168.10.0 netmask 255.255.255.0 {<br />
range 192.168.10.76 192.168.10.76;<br />
default-lease-time 600;<br />
max-lease-time 7200;<br />
}<br />
host r2d {<br />
hardware ethernet 0000e16b335d;<br />
fixed-address 192.168.10.76;<br />
filename "/tftpboot/zImage";<br />
option root-path "192.168.10.70:/tftpboot/rootfs ;<br />
}<br />
</pre><br />
<br />
<br />
<hr /><br />
Example of /etc/bootptab<br />
<br />
<pre><br />
r2d:sm=255.255.255.0:ha=0000e16b335d:ip=192.168.10.76:hd=/tftpboot:bf=zImage:<br />
rp=/tftpboot/rootfs<br />
</pre><br />
<br />
<br />
<hr /><br />
Example of /etc/exports<br />
<br />
<pre><br />
/tftpboot 192.168.10.76(rw,no_root_squash)<br />
</pre><br />
<br />
[[Category:Development Boards]]</div>Cschallehttps://elinux.org/index.php?title=IDE_Preempt&diff=74191IDE Preempt2011-10-28T10:38:49Z<p>Cschalle: Add categories</p>
<hr />
<div><br />
== Introduction ==<br />
"IDE Preempt" is the shorthand name for a feature which allows the IDE driver to be<br />
preempted during its initialization. There are long delays associated with<br />
the initialization of the IDE driver. Use of the IDE-preempt feature allows other kernel<br />
initialization work to proceed while the IDE driver is initializing, under<br />
certain circumstances.<br />
<br />
Currently, the set of conditions under which this feature is useful is<br />
pretty limited. The IDE driver must be configured and compiled as a<br />
kernel loadable module. This rules out most desktop uses of<br />
the IDE-preempt feature.<br />
<br />
This code basically turns the main busywait routine, <code>ide_delay_50ms()</code>, in the IDE driver<br />
into scheduled timeout and yield.<br />
<br />
=== Rationale ===<br />
Allowing other initialization operations to occur during IDE driver init prevents<br />
wasting CPU cycles in IDE driver busywait calls.<br />
<br />
== Downloads ==<br />
=== Patch ===<br />
- Patch for CELF version 040304, AND for 2.4.20 is here: [[Media:ide-preempt-2.patch]]<br />
- /\ THIS PATCH (IN ISOLATED FORM) HAS NOT BEEN TESTED /\<br />
- [Patch for 2.6.xx is *here*]<br />
<br />
=== Utility programs ===<br />
None<br />
<br />
== How To Use ==<br />
- Apply the patch to your 2.4.20-based (CELF or kernel.org) source tree<br />
- Configure the kernel:<br />
- with "Preemptible IDE delays" turned on<br />
- with the IDE driver configured as a module<br />
- Compile the kernel and modules<br />
- Set up your system to load the IDE driver module during system startup, after kernel boot<br />
- Set up your system to perform other initialization operations during the IDE driver initialization<br />
- Measure the decrease in total system boot time from running the IDE driver init concurrently<br />
with other system initialization tasks<br />
<br />
Note that to benefit from this feature you load the IDE driver as a module. When the IDE driver is<br />
linked statically with the kernel, then when the driver initializes there are no other kernel threads<br />
running which can take advantage of the time freed up from the busywait conversion.<br />
Also, in order to benefit from this there must be additional user-space or kernel<br />
tasks to run when loading the IDE driver.<br />
<br />
== Sample Results ==<br />
Busywait-style delays such as udelay() in module init functions inhibit kernel preemption because the Big Kernel Lock is held, while yielding [[APIs]] such as schedule_timeout() allow preemption (because the kernel handles the BKL specially and releases and reacquires it across reschedules alloowed by the current thread).<br />
<br />
IDE modules were one of the major offenders in this regard identified while looking at a couple of embedded platforms. The ide-probe-mod driver spends a great deal of time in repeated calls to ide_delay_50ms() during probe and drive identification, which busy waits (in order to let the IDE controller make progress before polling for status or to allow previous operations to complete). The ide-preempt fix changes these to schedule_timeout().<br />
<br />
Todd Poynor of [[Monta Vista]] measured the effect on a 200MHz IBM 405GP "Walnut" evaluation board with a 33MHz PCI bus. A Seagate Barracuda ATA IV 60GB disk drive with an ext2 filesystem was cabled to one of the two IDE interfaces on a Promise Ultra66 PCI-IDE bridge card (PDC20262 chipset). The ide-mod, ide-probe-mod, and ide-disk drivers were loaded as modules. The drivers for PCI, PCI-IDE disk, and ext2 filesystem were built statically into the kernel.<br />
<br />
Use of this feature had these effects on module loading time:<br />
<br />
<br />
<pre><br />
Original: 255.221 ms<br />
New: 296.977 ms<br />
</pre><br />
<br />
<br />
Note the elapsed time increased somewhat for two reasons. First, waiting times are slightly longer due to back porting a bug fix from the 2.5 kernel (which waits for an extra millisecond each time). Second, extra overhead was introduced by use of the schedule() function.<br />
<br />
The fix had these effects on maximum preemption-off windows, measured via /proc/latencytimes:<br />
<br />
<br />
<pre><br />
Original: 251.065 ms<br />
New: 9.865 ms<br />
</pre><br />
<br />
<br />
The ide-probe-mod driver spent almost all its time in about five calls to ide_delay_50ms(); use of preemptible delays freed up almost 250 milliseconds of time for other threads to run.<br />
<br />
== Future Work ==<br />
Here is a list of things that could be worked on for this feature:<br />
- version 2 of patch uses CONFIG_INSTANT_ON instead of CONFIG_FASTBOOT - this is a bug<br />
- test the patch<br />
- port the patch to 2.6<br />
- determine if and how this could be converted into a generalized driver init concurrency mechanism<br />
<br />
[[Category:Kernel]]<br />
[[Category:Linux]]<br />
[[Category:Tips and Tricks]]</div>Cschallehttps://elinux.org/index.php?title=Hrt_Project&diff=74185Hrt Project2011-10-28T10:37:45Z<p>Cschalle: Add category</p>
<hr />
<div><br />
== POSIX high-res-timers page ==<br />
<br />
[http://sourceforge.net/projects/high-res-timers/ Official HRT site]<br />
<br />
== Other Links ==<br />
<br />
CELF's timer hash array project page: [[Timer Hash Array Project]]<br />
<br />
CELF's patch archive page: [[Patch Archive]]<br />
<br />
[[Category:Kernel]]</div>Cschallehttps://elinux.org/index.php?title=Links_I%27m_working_on&diff=74179Links I'm working on2011-10-28T10:36:43Z<p>Cschalle: Add category</p>
<hr />
<div>[http://hp.vector.co.jp/authors/VA002416/teraterm.html TeraTerm]<br />
<br />
[[Category:ToDelete]]</div>Cschallehttps://elinux.org/index.php?title=Instrumentation_API&diff=74173Instrumentation API2011-10-28T10:36:05Z<p>Cschalle: Add category</p>
<hr />
<div>We seek to define an API to allow for simple measurement of timing data inside the<br />
Linux kernel. <br />
<br />
<br />
<br />
== Requirements ==<br />
(these notes are from the face-to-face meeting on Jan 10th)<br />
- The clock needs to support instrumentation lasting during the boot up period. This<br />
may be up to 2 minutes. For warm resets, the clock may not be reinitialized (is this true?)<br />
Therefore, even for bootup measurements, the clock may be running far into its cycle when<br />
the measurements are made.<br />
- Note that embedded processors have CPU clock ranging from a few MHZ to <br />
a few GHZ. A 1 GHZ clock will overrun 32 bits in about 4 seconds.<br />
- result is that we should probably use a 64-bit clock value.<br />
- for supporting periods of several seconds, a clock driver will need<br />
to manage upper bits to handle hardware clock overrun or wrap.<br />
- There should be a config option to turn on or off support for the feature<br />
- The instrumentation clock must be available early<br />
(before calibrate_delay()). It should probably be initialized inside setup_arch()<br />
- Note that a free-running clock could be set up by firmware<br />
(before kernel start)<br />
- Note that often you can use same clock as system clock (used for<br />
jiffies)<br />
- 1 usec or greater resolution is desired.<br />
- 100 usec accuracy is desired for our current bootup time measurement work<br />
- the value returned should not fluctuate with changes in CPU frequency.<br />
- Alternative, the CPU frequency should not be modified during the <br />
timing period. For the BTWG, the timing period is system bootup, so it<br />
should be easy to avoid changing CPU frequency during this period. (??)<br />
- the value returned should be monotonically increasing (except for rollover or<br />
some process specifically setting the clock)<br />
- the values returned need not be linearly related. That is, it is acceptable<br />
for the values to be non-linear, as long as the conversion to time results (sec, nsec)<br />
is correct. Thus, as one example of value management, it is possible to<br />
store the hardware clock value in the low 32 bits, and the number of rollovers<br />
in the high 32 bits. This works even if the clock source itself is less than<br />
32 bits wide (eg 12 bits, or 16 bits).<br />
- the API should be available on all architectures of interest (eg. cpu cycle read<br />
is not available on ARM or SH)<br />
- it should add minimal overhead to the system.<br />
<br />
== Proposed Specification ==<br />
=== Old proposed spec. ===<br />
- unsigned long long get_cycles(void) - which maps to get_arch_cycles()<br />
- unsigned long cycles_to_usec(unsigned long long) - which maps to arch_cycles_to_usec()<br />
<br />
Problems:<br />
- usecs returned in a unsigned 32-bit overflows at about 4000 seconds. This<br />
should be enough for a reasonable bootup time.<br />
<br />
=== Another old proposed spec. (deprecated) ===<br />
- see [[Timing APISpecification _R2]]<br />
<br />
=== New proposed spec. ===<br />
- use sched_clock(), and admonish board support authors to support it properly<br />
- also, document methods to provide scaling factor prior to time_init()<br />
to that measurements are available from very start of kernel execution.<br />
<br />
== [[APIs]] needed by current systems ==<br />
=== printk-times ===<br />
- static inline void highres_timer_read_ticks (u32 *slow, u32 *fast)<br />
- static inline void highres_timer_ticks_to_timeval(u32 slow, u32 fast, struct timeval *tv)<br />
<br />
In the patch submitted to the forum, this was only supported on x86.<br />
The highres_timer_ticks_to_timeval used a hardcoded value which had<br />
to be set at compile time. highres_timer_read_ticks used a read of<br />
the Time Stamp Counter (TSC) of the central processor.<br />
Also, highres_timer_ticks_to_timeval did not handle rollover<br />
from fast to slow very well.<br />
<br />
Current implementation for x86 (see [[Printk Times]]) uses hardcoded<br />
cpu_fixed_khz (in the 2.4 version of the patch), which requires<br />
a code change for different targets.<br />
<br />
These techniques are not portable.<br />
<br />
Problems:<br />
- separation of timer value into high and low 32-bit values<br />
doesn't seem necessary<br />
- it doesn't resemble other clock read [[APIs]] in the kernel<br />
- it should use term "clock" instead of "timer"<br />
- uses hard-coded (compiled in) value for conversion function<br />
<br />
=== KFI ===<br />
- unsigned long kfi_readclock(void)<br />
(which maps to do_getmachinecycles() )<br />
- unsigned long kfi_clock_to_usecs(unsigned long clocks)<br />
(which maps to machinecycles_to_usecs() )<br />
<br />
Problems:<br />
- has kfi in name<br />
- only supports 32-bit clock value<br />
<br />
=== kernel tracing ===<br />
- get_profiler_timestamp()<br />
- defined in /asm-<arch>/profiler.h<br />
<br />
On alpha get_profiler_timestamp is:<br />
<br />
<pre><br />
- #define get_profiler_timestamp() \ <br />
+ ( { \ <br />
+ register u32 __res; \ <br />
+ asm volatile ("rpcc %0" : "=r" (__res)); \ <br />
+ __res; \ <br />
+ } )<br />
+<br />
+/* Always u32, even when CONFIG_TRACE_TRUNCTIME */<br />
+typedef u32 profiler_timestamp_t;<br />
</pre><br />
<br />
<br />
On x86 get_profiler_timestamp is:<br />
<br />
<pre><br />
#ifdef CONFIG_TRACE_TIMESTAMP<br />
+#define get_profiler_timestamp() \ <br />
+ ( { \ <br />
+ register u64 __res; \ <br />
+ if (test_bit(X86_FEATURE_TSC, boot_cpu_data.x86_capability)) { \ <br />
+ __asm__ __volatile__( \ <br />
+ "rdtsc" : "=A"(__res) \ <br />
+ ); \ <br />
+ } \ <br />
+ else { \ <br />
+ /* no rdtsc, use jiffies instead */ \ <br />
+ __res = jiffies; \ <br />
+ } \ <br />
+ __res; \ <br />
+ } )<br />
+<br />
+#ifdef CONFIG_TRACE_TRUNCTIME<br />
+typedef u32 profiler_timestamp_t;<br />
+#else<br />
+typedef u64 profiler_timestamp_t;<br />
<br />
</pre><br />
<br />
<br />
Problems:<br />
- only supported on ALPHA and x86<br />
<br />
<br />
See http://www.kernel.org/pub/linux/kernel/people/andrea/ikd/README<br />
for information and for patches.<br />
<br />
=== Linux Trace Toolkit ===<br />
[don't know - need to find out]<br />
<br />
=== kgdb instrument functions ===<br />
- rdtsc(t1,t2)<br />
- extern unsigned long fast_gettimeoffset_quotient;<br />
<br />
I'm not sure where fast_gettimeoffset_quotient comes<br />
from, but it is used like this:<br />
<br />
<pre><br />
ll = 1LL << 32; <br />
do_div(ll, fast_gettimeoffset_quotient); <br />
cycles = (unsigned int)ll;<br />
</pre><br />
<br />
<br />
This is later used with the values returned from rdtsc, to convert it<br />
to integer and fractional seconds.<br />
<br />
Problems:<br />
- this only works on x86 (rdtsc)<br />
<br />
== Current [[APIs]] ==<br />
=== Current Linux (2.4) get_cycles() ===<br />
Linux version 2.4.20 has:<br />
- typedef unsigned long long cycles_t<br />
- cycles_t get_cycles(void) defined in include/asm/timex.h<br />
This returns 0 on x86 processors without a TSC, and 0 on some other processors<br />
- supported on x86, ppc, mips, alpha<br />
- not supported on arm, sh<br />
<br />
There appears to be no supporting function to convert to usecs.<br />
<br />
=== Current Linux (2.6) sched_clock() ===<br />
Linux version 2.6.7 has:<br />
- sched_clock() - returns current time in nanosec units.<br />
- unsigned long long sched_clock(void)<br />
- this routine won't function correctly (it returns 0) until a valid scale<br />
factore is set (for x86 and ppc). For x86, this means until the routine<br />
<code>set_cyc2ns_scale()</code> is called. This is normally called from <code>time_init()</code>.<br />
- on x86, it reads TSC.<br />
- on x86, found in <code>arch/i386/kernel/timers/timer_tsc.c</code><br />
- set_cyc2ns_scale() (x86 only)<br />
- static inline void set_cyc2ns_scale(unsigned long cpu_mhz)<br />
- initializes the conversion factor for the clock scaling of sched clock.<br />
- this is also called?? for CPU frequency changes<br />
<br />
- for a large number of architectures, sched_clock is defined as:<br />
<br />
<pre><br />
unsigned long long sched_clock(void)<br />
{<br />
return (unsigned long long)jiffies * (1000000000 / HZ);<br />
}<br />
</pre><br />
<br />
- this only give jiffy accuracy (10 ms, when HZ=100)<br />
- this is completely unacceptable for microsecond timings<br />
<br />
=== do_gettimeofday() ===<br />
This is supported all platforms. Most (??) have sub-jiffy resolution (usecs<br />
or better?).<br />
<br />
- When is this available in boot cycle?<br />
- What is overhead of call?<br />
<br />
I'm assuming the overhead of the call to do_gettimeofday is what has prompted<br />
the proposal for Fast Timestamps (see next section).<br />
<br />
Todd Poynor writes:<br />
Re: gettimeofday(), the implementation can vary considerably between<br />
architectures. Generally, I believe architectures read the count of<br />
jiffies and also a board-specific microsecond timer source, if any, to<br />
add the number of microseconds that have elapsed since the last timer<br />
interrupt bumped jiffies. And a spinlock is expected to be held during<br />
this operation. gettimeofday() is available everywhere, but not all<br />
boards necessarily implement microsecond accuracy -- I don't know<br />
statistics on this. You would probably also need some hook to<br />
compensate for the place in the boot sequence in which the system time<br />
is seeded from the RTC or set via settimeofday, etc. gettimeofday()<br />
isn't setup immediately at kernel startup, but not long afterwards, and<br />
it would probably be easy to force the init earlier.<br />
<br />
Directly using the microsecond-level accuracy time source for<br />
gettimeofday would be board-specific, so an API wrapper would still be<br />
needed.<br />
<br />
Greg Ungerer writes:<br />
On many platforms (I would think most) it [gettimeofday] gives much better<br />
than jiffy resolution.<br />
<br />
Looking around the underlying architecture and platform code<br />
in 2.6 it looks like most have code to deal with determining<br />
the time reasonably accurately in do_gettimeofday(). Even on<br />
the small/slower embedded processors I deal with this is easy<br />
to do, and mostly gives resoutions in the usec's range.<br />
<br />
The support do this on an architectural and platform basis<br />
is flexible enough and easy to implement I would argue there<br />
is more value in implementing a better do_gettimeofday()<br />
[if it is only jiffie resolution on your platform of interest]<br />
than to have a separate API. A good gettimeofday helps all<br />
system timing calculations.<br />
<br />
<br />
=== Fast Timestamp (proposal) ===<br />
This was a proposal for a mechanism that could quickly record a timer value<br />
that could be translated into timeofday (timeval) at some later time.<br />
The purpose of this would be to separate the operations of acquiring<br />
the timing data, and converting the units into a recognizable form.<br />
I didn't understand the full context, but I gather that this was decoupled<br />
to allow for very quick time recording, with later subsequent interpretation,<br />
possible to preserve performance inside the network stacks.<br />
<br />
1) Some kind of fast_timestamp_t, the property is that this stores<br />
enough information at time "T" such that at time "T + something"<br />
the fast_timestamp_t can be converted what the timeval was back at<br />
time "T".<br />
<br />
For networking, make skb->stamp into this type.<br />
<br />
2) store_fast_timestamp(fast_timestamp_t *)<br />
<br />
For networking, change do_gettimeofday(&skb->stamp) into<br />
store_fast_timestamp(&skb->stamp)<br />
<br />
3) fast_timestamp_to_timeval(arch_timestamp_t *, struct timeval *)<br />
<br />
For networking, change things that read the skb->stamp value<br />
into calls to fast_timestamp_to_timeval().<br />
<br />
It is defined that the timeval given by fast_timestamp_to_timeval()<br />
needs to be the same thing that do_gettimeofday() would have recorded<br />
at the time store_fast_timestamp() was called.<br />
<br />
See http://lwn.net/Articles/61269/<br />
<br />
what was final status of this? David Miller was going to push this<br />
proposal to arch maintainers for sanity checking. I don't know <br />
what happened.<br />
<br />
== Other information ==<br />
=== System Tap timestamp notes ===<br />
See [[System Tap Timestamp Notes]]<br />
<br />
[[Category:Kernel]]</div>Cschallehttps://elinux.org/index.php?title=High_Resolution_Timers&diff=74161High Resolution Timers2011-10-28T10:35:06Z<p>Cschalle: Add category</p>
<hr />
<div>== Description ==<br />
The objective of the high resolution timers project is to implement the POSIX 1003.1b Section 14 (Clocks and Timers) API in Linux. This includes support for high resolution timers - that is, timers with accuracy better than 1 jiffy.<br />
<br />
When the project started, the POSIX clocks and timers APIs were not supported by Linux. Over time, the clocks and timers APIs have been adopted, and core infrastructure support for high resolution timers has been accepted into the mainline kernel (in 2.6.21). However, as of this writing, not all embedded platforms has support for high resolution timers, <br />
and even when support is present in the kernel code, it can be tricky to configure it for the kernel.<br />
<br />
== Rationale ==<br />
Currently, timers in Linux are only supported at a resolution of 1 jiffy. The length of a jiffy is dependent on the value of HZ in the Linux kernel, and is 1 millisecond on i386 and some other platforms, and 10 milliseconds on most embedded platforms.<br />
<br />
Higher resolution timers are needed to allow the system to wake up and process data at more accurate intervals.<br />
<br />
== Resources ==<br />
=== Projects ===<br />
==== hrtimers - Thomas Gleixner's patch ====<br />
One project to support high resolution timers is Thomas Gleixner's hrtimers.<br />
<br />
Thomas gave a presentation at the Ottawa Linux Symposium, July 2006, presenting the current status of hrtimers. The presentation is here:<br />
[http://www.tglx.de/projects/hrtimers/ols2006-hrtimers.pdf OLS hrtimers]<br />
<br />
As of July 2006, "generic clock sources" was accepted into Linus' mainline kernel tree (2.6.18-rc??). This means it should be appear in the mainline 2.6.18 kernel version, when that is available. hrtimers should soon follow, likely appearing in 2.6.19.<br />
<br />
In February of 2006, James Perkins of WindRiver wrote:<br />
----<br />
ktimers has been obsoleted by hrtimers, and the core of hrtimers was<br />
merged and is present in Linus' 2.6.16-rc2. hrtimers is used as the base<br />
for itimers, nanosleep, and posix-timers. hrtimers are well-described by<br />
Jonathan Corbet at http://lwn.net/Articles/167897/<br />
<br />
Since only the core of hrtimers is in 2.6.16-rc2, the hrtimers generally<br />
use the system timer as their tick source and run at HZ. John Stultz'<br />
generalized time source code has not yet been merged. Thomas Gleixner is<br />
maintaining his git tree and has graciously published patches at<br />
http://www.tglx.de/projects/hrtimers/ that include generalized<br />
clocksource, new timeofday patches, and get you the real "high<br />
resolution" timers for a subset of architectures.<br />
<br />
High-res timers work is experimental and shifting and has been focusing<br />
on getting x86 working first, if this is adequate for you and you can<br />
use 2.6.16 kernels it's recommended, and let us all know of any problems<br />
or improvements. In contrast, the previous implementation that George<br />
Anzinger lead provides a fairly comprehensive set of functionality, back<br />
in the 2.6.8-2.6.10 era, but it isn't an active project at this time.<br />
----<br />
''Note that the current HRT maintainers objected to this characterization.''<br />
<br />
==== HRT - Geoge Anzinger's patch ====<br />
Prior to hrtimers, the main patch which provided high resolution timers was<br />
George Anzinger's patch.The official HRT site for this patch is at:<br />
* [http://sourceforge.net/projects/high-res-timers/ high-res-timers]<br />
<br />
<br />
<br />
== Downloads ==<br />
=== Patch ===<br />
* See [[Patch Archive]]<br />
* Tom Rini has posted some patches for earlier 2.6 kernels at:<br />
** [http://source.mvista.com/~trini/hrt/hrt_07Dec2004_001_2.6.10-rc3.patch trini patches]<br />
<br />
== Utility programs ==<br />
<br />
== How To Use ==<br />
In order to use high resolution timers, you need to verify that the kernel has support for this feature for your<br />
target processor (and board). Also, you need to configure support for it in the Linux kernel.<br />
<br />
Set CONFIG_HIGH_RES_TIMERS=y in your kernel config.<br />
<br />
Compile your kernel and install it on your target board.<br />
<br />
To use the Posix Timers API, see this online resource [http://www.opengroup.org/onlinepubs/009695399/basedefs/time.h.html]<br />
<br />
== How to detect if your timer system supports high resolution ==<br />
Here are several ways you can identify if your system supports high resolution timers.<br />
<br />
* Examine kernel startup messages<br />
Watch the kernel boot messages, or use <tt>dmesg</tt>. If the kernel successfully turns<br />
on the high resolution timer feature, it will print the message<br />
"Switched to high resolution mode on CPU0" (or something similar) during <br />
startup.<br />
<br />
* Examine /proc/timer_list<br />
You can also examine the timer_list, and see whether specific clocks<br />
are listed as supporting high resolution. Here is a dump of /proc/timer_list<br />
on an [[OSK]] (ARM-based) development board, showing the clocks configured<br />
for high resolution.<br />
<br />
** cat /proc/timer_list<br />
<pre>Timer List Version: v0.3<br />
HRTIMER_MAX_CLOCK_BASES: 2<br />
now at 294115539550 nsecs<br />
<br />
cpu: 0<br />
clock 0:<br />
.index: 0<br />
.resolution: 1 nsecs<br />
.get_time: ktime_get_real<br />
.offset: 0 nsecs<br />
active timers:<br />
clock 1:<br />
.index: 1<br />
.resolution: 1 nsecs<br />
.get_time: ktime_get<br />
.offset: 0 nsecs<br />
active timers:<br />
#0: <c1e39e38>, tick_sched_timer, S:01, tick_nohz_restart_sched_tick, swapper/0<br />
# expires at 294117187500 nsecs [in 1647950 nsecs]<br />
#1: <c1e39e38>, it_real_fn, S:01, do_setitimer, syslogd/796<br />
# expires at 1207087219238 nsecs [in 912971679688 nsecs]<br />
.expires_next : 294117187500 nsecs<br />
.hres_active : 1<br />
.nr_events : 1635<br />
.nohz_mode : 2<br />
.idle_tick : 294078125000 nsecs<br />
.tick_stopped : 0<br />
.idle_jiffies : 4294966537<br />
.idle_calls : 2798<br />
.idle_sleeps : 1031<br />
.idle_entrytime : 294105407714 nsecs<br />
.idle_sleeptime : 286135498094 nsecs<br />
.last_jiffies : 4294966541<br />
.next_jiffies : 4294966555<br />
.idle_expires : 294179687500 nsecs<br />
jiffies: 4294966542<br />
<br />
<br />
Tick Device: mode: 1<br />
Clock Event Device: 32k-timer<br />
max_delta_ns: 2147483647<br />
min_delta_ns: 30517<br />
mult: 140737<br />
shift: 32<br />
mode: 3<br />
next_event: 294117187500 nsecs<br />
set_next_event: omap_32k_timer_set_next_event<br />
set_mode: omap_32k_timer_set_mode<br />
event_handler: hrtimer_interrupt<br />
</pre><br />
<br />
Here are some things to check:<br />
<br />
1. Check the resolution reported for your clocks. If your clock supports high resolution, it will have a .resolution value of 1 nsecs. If it does not, then it will have a .resolution value that equals the number of nanoseconds in a jiffy (usually 10000 nsecs, on embedded platforms).<br />
<br />
2. Check the event_handler for the Tick Device. If the event handlers is 'hrtimer_interrupt' then the clock is set up for high resolution handling. If the event handler is 'tick_handle_periodic', then the device is set up for regular tick-based handling.<br />
<br />
3. Check the list of timers, and see if the attribute .hres_active has a value of 1. If so, then the high resolution timer feature is active.<br />
<br />
* Run a test program<br />
You can run a small test program, and actually measure that the timers are returning in<br />
less than the period of a jiffy. If they are, this is the most definitive proof that your kernel<br />
supports high resolution timers.<br />
One example program you can try is [http://rt.wiki.kernel.org/index.php/Cyclictest cyclictest].<br />
Here is a sample command line which will test timers using nanosleep:<br />
** cyclictest -n -p 80 -i 500 -l 5000<br />
This does a test of clock_nanosleep, with priority 80, at 500 microsecond intervals, running<br />
the 5000 iterations of the test.<br />
<br />
== How to validate ==<br />
See above with regard to cyclictest<br />
<br />
== Sample Results ==<br />
[Examples of use with measurement of the effects.]<br />
<br />
== Case Study 1 ==<br />
== Case Study 2 ==<br />
<br />
== Status ==<br />
<br />
*Status: implemented<br />
*Architecture Support:<br />
:(for each arch, one of: unknown, patches apply, compiles, runs, works, accepted)<br />
** i386: works<br />
** ARM: unknown<br />
** PPC: works<br />
** MIPS: unknown<br />
** SH: unknown<br />
<br />
== Future Work/Action Items ==<br />
<br />
Here is a list of things that could be worked on for this feature:<br />
*Documentation<br />
*Testing<br />
<br />
== Old information (for 2.4 kernel) ==<br />
The High Resolution Timers system allows a user space program to be wake up from a timer event with better accuracy, when using the POSIX timer APIs. Without this system, the best accuracy that can be obtained for timer events is 1 jiffy. This depends on the setting of HZ in the kernel. In the 2.4 kernel, HZ was set to 100, which means that the best accuracy you could <br />
get on a timer wakeup in user space was 10 milliseconds.<br />
<br />
Put differently, if you asked for a timer event in 500 microseconds, you would wake up in 10 milliseconds (at least).<br />
<br />
To support this feature on a particular board, you have to add a kernel driver that uses a timer on the system and supports the interface documented in:<br />
<code><br />
include/linux/hrtime.h (in the CELF tree)<br />
</code><br />
Additional documentation about this feature is available in<br />
<code><br />
Documentation/high-res-timers/<br />
</code><br />
<br />
Patches for high-res timers were first presented at the time of kernel version 2.5.47,<br />
in November, 2002. See [http://lwn.net/Articles/14538/ early patches]<br />
<br />
[[Category:Kernel]]</div>Cschallehttps://elinux.org/index.php?title=Heap_memory&diff=74155Heap memory2011-10-28T10:34:22Z<p>Cschalle: Add category</p>
<hr />
<div>Heap is the memory allocated in runtime during program execution. When memory is allocated using malloc() or calloc() for any pointer in a program, the size of the memory is allocated from the heap memory area and is assigned to the pointer. Until the pointer is freed using free() the heap memory is used by the pointer variable.<br />
<br />
See [[Memory Debuggers]] for tools that help analyze memory usage patterns, detect unbalanced allocations and frees, report buffer over- and under-runs, etc.<br />
<br />
[[Category:Tips and Tricks]]</div>Cschallehttps://elinux.org/index.php?title=Function_sections&diff=74137Function sections2011-10-28T10:33:43Z<p>Cschalle: Add category</p>
<hr />
<div>== Introduction ==<br />
"Function sections" is a technique for reducing the size of the kernel image.<br />
It does this by placing each function into its own linker section, which then<br />
allows the linker to do better dead code removal.<br />
<br />
Denys reported that usage of this technique got him about a 10% reduction in kernel<br />
size.<br />
<br />
== Theory of operation ==<br />
Denys Vlasenko wrote:<br />
<br />
-ffunction-sections instructs gcc to place each function<br />
(including static ones) in its own section named .text.function_name<br />
instead of placing all functions in one big .text section.<br />
<br />
At link time, ld normally coalesces all such sections into one<br />
output section .text again. It is achieved by having *(.text.*) spec<br />
along with *(.text) spec in built-in linker scripts.<br />
<br />
However, if ld is invoked with the option --gc-sections, it tracks references, starting<br />
from the entry point and marks all input sections which are reachable<br />
from there. Then it discards all input sections which are not marked.<br />
<br />
This doesn't buy much if you have one big .text section per .o module,<br />
because even one referenced function will pull in entire section.<br />
However, if you use -ffunction-sections to split .text into per-function<br />
sections it makes --gc-sections much more useful.<br />
<br />
-fdata-sections is analogous: it places each global or static variable<br />
into .data.variable_name, .rodata.variable_name or .bss.variable_name.<br />
<br />
== Status ==<br />
Denys submitted patches in July 2008 to make the kernel compilable using<br />
"gcc -ffunction-sections -fdata-sections". See http://lkml.org/lkml/2008/7/1/499<br />
<br />
[[Category:Tips and Tricks]]<br />
[[Category:Kernel]]</div>Cschallehttps://elinux.org/index.php?title=Testfortest&diff=74131Testfortest2011-10-28T10:33:00Z<p>Cschalle: Add category and suggest deletion</p>
<hr />
<div>[[Category:ToDelete]]</div>Cschallehttps://elinux.org/index.php?title=Rt_Preempt_Subpatch_Table&diff=74125Rt Preempt Subpatch Table2011-10-28T10:32:23Z<p>Cschalle: Add category</p>
<hr />
<div>Here is a table of rt-preempt sub-patches and the kernel features they introduce and affect:<br />
{| <br />
|- bgcolor="80c080"<br />
| . <br />
| align="center" | '''PATCH'''<br />
|- bgcolor="80c080"<br />
| Kernel item <br />
| p-smp <br />
| p-cleanup <br />
| add-lnr<br />
| add-crs<br />
| *fix-scheduling*<br />
| *keventd*<br />
| idle-thread-p-fix<br />
| remove-bkl<br />
|- <br />
| spinlock_t <br />
| add break_lock <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
|- <br />
| rwlock_t <br />
| add break_lock <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
|- <br />
| _raw_read_trylock() <br />
| create <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
|- <br />
| generic_raw_read_trylock() <br />
| create <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
|- <br />
| cond_resched_lock() <br />
| check for break_lock <br />
| . <br />
| . <br />
| . <br />
| add calls to <br />
| . <br />
| . <br />
| . <br />
|- <br />
| <spinlock routines>() (read_lock(), spin_lock_irqsave(), spin_lock_irq(), spin_lock_bh(), read_lock_irqsave(), read_lock_irq(), read_lock_bh(), write_lock_irqsave(), write_lock_irq(), write_lock_bh()) <br />
| enabled irqs, check for lock break requests <br />
| . <br />
| . <br />
| . <br />
| change some *_lock() to *_lock_irq()s <br />
| . <br />
| . <br />
| . <br />
|- <br />
| need_lockbreak() <br />
| . <br />
| create <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
|- <br />
| cond_resched() <br />
| . <br />
| fix <br />
| . <br />
| . <br />
| add calls to <br />
| . <br />
| . <br />
| . <br />
|- <br />
| lock_need_resched() <br />
| . <br />
| . <br />
| create<br />
| . <br />
| add calls to <br />
| . <br />
| . <br />
| . <br />
|- <br />
| lock/unlock_kernel() <br />
| . <br />
| . <br />
| . <br />
| . <br />
| add calls to <br />
| . <br />
| . <br />
| . <br />
|- <br />
| cond_resched_softirq() <br />
| . <br />
| . <br />
| . <br />
| . <br />
| add calls to <br />
| . <br />
| . <br />
| . <br />
|- <br />
| filemap_sync() <br />
| . <br />
| . <br />
| . <br />
| . <br />
| create replacement with cond_resched()<br />
| .<br />
| . <br />
| . <br />
|- <br />
| __filemap_sync() <br />
| . <br />
| . <br />
| . <br />
| . <br />
| create? <br />
| . <br />
| . <br />
| . <br />
|- <br />
| unmap_vmas() <br />
| . <br />
| . <br />
| . <br />
| . <br />
| change ZAP_BLOCK_SIZE<br />
| . <br />
| . <br />
| . <br />
|- <br />
| helper_init() <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| create <br />
| . <br />
| . <br />
|- <br />
| rest_init() <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| enable_preemption <br />
| . <br />
|- <br />
| start_kernel() <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| disable preemption<br />
| . <br />
|- <br />
| PREEMPT_BKL <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| create <br />
|- <br />
| _smp_processor_id() <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| create <br />
|- <br />
| current_cpu_data <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| replace with cpu_data[] <br />
|- <br />
| in_atomic() <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| alters <br />
|- <br />
| nmi_enter/exit(), irq_enter()<br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| alter to use add/sub_preempt_count() <br />
|- <br />
| add/sub_preempt_count() <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| create <br />
|- <br />
| <u>ARRAY(0x1016aca4)</u>release_kernel_lock() <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| create <br />
|- <br />
| lock/unlock_kernel() <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| create sem version<br />
|- <br />
| DEBUG_PREEMPT <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| create <br />
|- <br />
| smp_processor_id() <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| add debug version<br />
|- <br />
| might_sleep() <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| . <br />
| created in rtp3<br />
|}<br />
<br />
== Sub-patch summaries ==<br />
* preempt-smp - spin irq-nicely and request cross-CPU lock-breaks if needed.<br />
*** add break_lock field to spinlock_t and rwlock_t, and add _raw_read_trylock() function<br />
*** generic_raw_read_trylock() needs to an ARCH-optimized version<br />
* preempt-cleanup - fixes some issues with cond_resched, and adds need_lockbreak()<br />
* add-lock_need_resched - self-explanatory<br />
* sched-add-cond_resched_softirq - allows some softirqs-disabled codepaths to preempt<br />
* *fix-scheduling*, break-latency* - add cond_resched() to lots of places<br />
*** add lock_kernel and unlock_kernel in a few places<br />
*** adjust some routines to allow rescheduling better (dependent on PREEMPT and SMP)<br />
* fix-keventd-execution-dependency - schedule work differently during kevent initialization<br />
* idle-thread-preemption-fix - disable preemption during bootup (until idle thread is running)<br />
* remove-the-bkl-by-turning-it-into-a-sempahore - self-explanatory<br />
*** adds _smp_processor_id() to help debug incorrect usage of this routine<br />
*** adds add/sub_preempt_count, with debug aids to detect underflows<br />
*** adds DEBUG_PREEMPT to enable both of the above<br />
*** replace current_cpu_data with cpu_data[_smp_processor_id()]<br />
*** add PREEMPT_BKL, and change routines lock/unlock_kernel to use a semaphore<br />
<br />
<br />
== Terminology ==<br />
* voluntary preempt = add preemption points to PREEMPT kernels (mostly via added calls to cond_resched())<br />
* might_sleep =<br />
* latency timing = system for keeping track of preemption request vs. actual preemption occurence<br />
** this is used to emit warnings when a user-defined threshold is exceeded, and is useful for debugging the preemption features of this patchset<br />
* latency trace = system for logging preemption-related events<br />
<br />
[[Category:Kernel]]</div>Cschallehttps://elinux.org/index.php?title=Sunplus_SPMP3050A&diff=74119Sunplus SPMP3050A2011-10-28T10:31:48Z<p>Cschalle: Add category</p>
<hr />
<div>= Sunplus SPMP3050A =<br />
<br />
== Introduction == <br />
<br />
The Sunplus SPMP3050A is a chip which is used in MP4 players. An MP4 player with this chip is available from [http://www.dealextreme.com/details.dx/sku.14785~r.66422016 DeaslExtreme] for only USD 44.92 (price as of 2008-11-20). This player has 2GB flash, 8 MB ram and a color LCD screen.<br />
<br />
== Features ==<br />
<br />
Some of the key characteristics:<br />
* 32-bit ARM926EJ with a Programmable CPU Operating Frequency from 82kHz to 168MHz.<br />
* Support RGB Bayer Patterns Output Sensors with up to 6M-pixel (2872x2160) image resolution. <br />
* Support YUV422-Output Sensors or CCD modules up to 3M (2048x1536) image size.<br />
* Support LCM/LCD/OLED Panel of resolution up to 240x320.<br />
* Support 18-bit(RGB666), 16-bit(RGB565), 12-bit(RGB444), 8-bit(RGB332) LCMs.<br />
* Support 18-bit(RGB666) LCD.<br />
* Built-in TV encoder, provide NTSC/PAL composite video output.<br />
* Build-in USB1.1 Full-Speed Host and device Controller and Transceiver.<br />
* Support SD/microSD/MMC/MMC4.0-4bits card<br />
* Support SLC and MLC NAND-type Flash memory<br />
* Embedded 16-bit high-quality Stereo Audio ADC/DAC <br />
* Line-in and Line-out support.<br />
* Embedded microphone input and headset output with amplifier.<br />
* Support stereo speaker output with external amplifier.<br />
* Standard JPEG CODEC.<br />
* H.263 baseline profile level30, MPEG4 simple profile level3 CODEC <br />
* Support 3GP/ASF/AVI/MP4 file format <br />
* MPEG4/H.263 frame rate is up to 30 fps @ 352x288 resolution, 10 fps @.640x480 resolution<br />
* 1 UART port for debug.<br />
* 13 GPIO with built-in interrupt function<br />
* Built-in 3-channel inputs 10-bit SAR ADC with 24K sampling rate for touch panel, battery power monitor and other applications. <br />
* 6x2 Keypad interface <br />
<br />
== References ==<br />
<br />
[http://spmp305x.spritesserver.nl/wiki/index.php/Main_Page spmp305x wiki] is a wiki for this chip. Unfortunately it is heavily vandalised.<br />
<br />
A specification of the chipset can be found at http://www.htmmi.com/products/dsc/spmp.asp<br />
<br />
Unfortunately no datasheet is available, which is a pity as this thing would be a very nice, ultra cheap linux box.<br />
<br />
http://www.mympxplayer.org also has a long thread on this chip and the players based upon it [http://www.mympxplayer.org/previous-vt8674.html here]<br />
<br />
[[Category:Hardware]]</div>Cschallehttps://elinux.org/index.php?title=Remote_Board_Access_Spec&diff=74107Remote Board Access Spec2011-10-28T10:31:01Z<p>Cschalle: Add category</p>
<hr />
<div>This is a specification for a system for "Remote Board Access".<br />
<br />
VERSION 0.3<br />
<br />
== Introduction ==<br />
This specification describes the configuration and conventions used for a "Remote Board Access"<br />
system. "Remote Board Access" (or RBA) is the name used to describe a configuration of <br />
hardware and software which allows for an individual developer to build Linux software and test<br />
it on a target machine (usually an embedded board), which is accessed remotely.<br />
<br />
Related to this "access specification", is the definition of an automated test framework which<br />
can be built upon it. Some aspects of this specification directly address the requirements<br />
of such a framework. However, some aspects of this specification also support the activity of individual developers working interactively with embedded development boards.<br />
<br />
This specification creates standards for two main activities:<br />
*building software for a target machine<br />
*accessing and controlling a target machine<br />
<br />
=== Taming Variability in Embedded Configurations ===<br />
The key idea of this specification is to create a uniform method of access to build tools,<br />
software, and the board itself, for an embedded target board. A significant problem in the embedded space is the variety of configurations that are presented to a software developer for such boards. A large number of items in the configuration and setup of an embedded target board vary from board to board. This includes a such things as the bootloader, compiler (location, version and supported architecture), kernel version, kernel configuration, file system type, and methods of target access for software installation, console access, command invocation, file system access, etc.<br />
<br />
It is very difficult for both a human engineer and an automated test system to deal with this large variety of factors. One of the primary purposes, then, of this specification is to create a model whereby these factors are masked and a uniform method is presented for building and installing software, and manipulating the target board. <br />
<br />
=== Rationale ===<br />
This specification is needed in order to:<br />
*to create a uniform method of building software and controlling a target board<br />
:*to allow for automation of testing activities on a board<br />
:*to eliminate or reduce the learning curve for using different boards<br />
*this specification deals with one area of interface (between a host and a target) that is part of the overall architecture of the CELF OpenTestLab<br />
:*see TestLabArchitecture for more information. <br />
<br />
== Definitions ==<br />
; host: The machine used to control or access one or more target boards.<br />
; target: A development board which can be accessed remotely using the RBA system.<br />
; toolchain: The collection of programs used to create software for a target machine. This consists of the compiler (including preprocessor), assembler, linker and other programs used for manipulating source and machine code into a form usable on the target. This usually consists of software from the Linux packages for gcc, binutils, and glibc.<br />
<br />
== Use Cases - Interactive ==<br />
=== basic remote board use ===<br />
*a developer wants to build a kernel, boot it on the target, and view the kernel bootup messages<br />
*also, the developer wants to log in to the new kernel, and run a variety of user space applications<br />
<br />
Steps:<br />
#developer sets target-specific work environment<br />
#*<code>target setenv <target></code><br />
#developer gets target-specific kernel source<br />
#*<code>target get_kernel</code><br />
#developer sets the kernel configuration<br />
#*developer gets default kernel config for $TARGET<br />
#**<code>target get_config</code><br />
#**or "make $TARGET_defconfig" should work<br />
#*developer makes config modifications (by hand)<br />
#*<code>make menuconfig</code>, or <code>vi .config</code><br />
#developer builds the kernel<br />
#*environment provides ARCH, CROSS_COMPILE, and kimage vars<br />
#*<code>make $kimage</code>, or <code>target kbuild</code><br />
#developer installs kernel on the target<br />
#*<code>target kinstall</code><br />
#developer gets a target console<br />
#*<code>target console</code><br />
#developer resets target board<br />
#*<code>target reset</code><br />
#developer logs into target board<br />
#*(login on console) or <code>target login</code><br />
#*developer can now run commands interactively on the target<br />
<br />
=== testing a kernel configuration ===<br />
*a developer wants to test a particular kernel configuration option on a target<br />
*:developer needs a baseline configuration for that target, and a way to make modifications<br />
*:alternatively, the developer needs a way to upload their own configuration to the host<br />
<br />
Steps:<br />
#developer copies desired configuration file to RBA host<br />
#*<code>scp myconfig rbahost:/home/<user>/</code><br />
#developer logs into RBA host using ssh<br />
#developer sets target-specific work environment<br />
#*<code>target setenv <target></code><br />
#developer gets target-specific kernel source<br />
#*<code>target get_kernel</code><br />
#developer sets the kernel configuration<br />
#*developer uses default configuration with some modifications:<br />
#**developer gets default kernel config for $TARGET<br />
#**<code>target get_config</code><br />
#**or "make $TARGET_defconfig" should work<br />
#**developer makes config modifications (by hand)<br />
#**<code>make menuconfig</code>, or <code>vi .config</code><br />
#*OR developer uses their own configuration<br />
#*<code>cp /home/<user>/myconfig .</code><br />
#*<code>make oldconfig</code><br />
#developer builds the kernel<br />
#*environment provides ARCH, CROSS_COMPILE, and kimage vars<br />
#*<code>make $kimage</code><br />
#developer locks target for use<br />
#developer installs kernel<br />
#*<code>target kinstall</code><br />
#developer gets a target console<br />
#*<code>target console</code><br />
#developer resets target board<br />
#*<code>target reset</code><br />
#developer logs into target board<br />
#*(login on console) or <code>target login</code><br />
#developer examines messages, runs tests, etc.<br />
<br />
=== testing a new kernel patch ===<br />
*a developer wants to apply a patch to a target-specific kernel (to see if it applies) and run the new kernel on the target hardware (to see if the new feature works)<br />
<br />
Steps:<br />
#developer copies desired configuration file to RBA host<br />
#*<code>scp myconfig rbahost:/home/<user>/</code><br />
#developer uploads a patch to the RBA host<br />
#*<code>scp foo.patch rbahost:/home/<user>/</code><br />
#developer logs into RBA host using ssh<br />
#developer sets target-specific work environment<br />
#*<code>target setenv <target></code><br />
#developer gets target-specific kernel source<br />
#*<code>target get_kernel</code><br />
#developer applies patch to kernel source<br />
#*<code>patch -p1 /home/<user>/foo.patch</code><br />
#developer sets the kernel configuration<br />
#*developer uses default configuration with some modifications:<br />
#**developer gets default kernel config for $TARGET<br />
#***<code>target get_config</code><br />
#***or "make $TARGET_defconfig" should work<br />
#**developer makes config modifications (by hand)<br />
#***<code>make menuconfig</code>, or <code>vi .config</code><br />
#*OR developer uses their own configuration<br />
#**<code>cp /home/<user>/myconfig .</code><br />
#**<code>make oldconfig</code><br />
#developer builds the kernel<br />
#*environment provides ARCH, CROSS_COMPILE, and kimage vars<br />
#*<code>make $kimage</code><br />
#developer locks target for use<br />
#developer installs kernel<br />
#*<code>target kinstall</code><br />
#developer gets a target console<br />
#*<code>target console</code><br />
#developer resets target board<br />
#*<code>target reset</code><br />
#developer logs into target board<br />
#*login on console) or <code>target login</code><br />
#developer examines messages, runs tests, etc.<br />
<br />
=== testing user-space software ===<br />
*a developer wants to test a user-space program on the target<br />
**developer needs target-specific kernel running on target<br />
**developer needs to be able to upload user-space program to RBA host<br />
**developer needs build environment for user-space program<br />
**developer needs a way to install program on the target<br />
***should be able to put program in already-available root filesystem<br />
**developer needs a way to run program on target, and gather results<br />
<br />
=== testing a new baseline kernel ===<br />
A target maintainer may want acquire target-specific patches, and apply to a new kernel.org baseline<br />
*this is to see which target-specific patches do not apply cleanly any more.<br />
*target-specific patches should be separated from baseline kernel<br />
**target-specific kernel source should be available as baseline kernel + patches<br />
<br />
Steps (summary):<br />
*login to rba host<br />
*get kernel<br />
*get target (old/existing) baseline<br />
*install new baseline<br />
*diff old-baseline kernel >target-patch<br />
*patch new-baseline <target-patch<br />
**report problems<br />
*compile<br />
**report problems<br />
<br />
== Use Cases - Automated ==<br />
<br />
=== automated unit test ===<br />
A developer wants to test a particular feature of the kernel or default software, in a unit test. A series of tests are to be performed, without user interaction.<br />
<br />
*need to put test script on target (target cp)<br />
*need to initiate test on target (target reset, target run)<br />
*need to handle watchdogging the program/target<br />
**need external reset control (external power control is also desirable)<br />
*need to get results from target<br />
*need to set a config option<br />
*need to patch the kernel<br />
*need to compile, install, start the kernel<br />
<br />
<br />
=== automated patch test ===<br />
*a developer wants to test that a patch can be compiled for a number of different architectures and platforms<br />
*the developer submits the patch to a patch server<br />
*the patch server iterates through a list of registered RBA sites, for each site:<br />
*the patch server obtains the kernel source for the target (on the RBA host, under the patch server account)<br />
*the patch server uploads the patch<br />
*the patch server compiles the kernel<br />
<br />
=== automated regression test<br />
*lab software checks for update to linux kernel (or other software)<br />
**when new version is detected, code is downloaded and test is run automatically<br />
<br />
=== run test suite on a non-lab node ===<br />
*developer accesses test server and selects a test run download and run on their local host/target combination<br />
*pre-requisite - user verifies that their host/target combination interoperates with the RBA system<br />
**user downloads an interoperability test and runs it<br />
*web server provides list of available tests<br />
*client can download and run a test from the server<br />
**test programs for target must be packaged somehow [need specification for format]<br />
<br />
== Supported operations (tasks) ==<br />
*verify that the target machine is available for use (target status)<br />
*reserve target for use (target acquire [timeout])<br />
*unreserve target (target release)<br />
*build kernel<br />
**obtain kernel source for target (target get_kernel)<br />
**set up build environment for kernel (target setenv)<br />
**get default kernel configuration (target get_config)<br />
*build root filesystem for target<br />
*build program for target<br />
**upload source for program for target (scp)<br />
**set up build environment for programs (target setup_build_environment)<br />
*install kernel (target kinstall)<br />
*install program (target cp)<br />
*install rootfs (target fsinstall)<br />
*get results (target cp)<br />
*control target<br />
**reset target machine ("target reset")<br />
**power cycle target machine ("target power_off", "target power_on", "target power")<br />
**access console ("target console")<br />
**access target remotely ("target login")<br />
<br />
== Specifications ==<br />
=== Machine configuration ===<br />
Model: an RBA site consists of a single host, connected to one or more target machines.<br />
<br />
A host has sufficient software to perform a number of development activities<br />
relative to its target machines. Specifically, the host MUST provide<br />
software and mechanisms to:<br />
#acquire, build and install the Linux kernel software for the target<br />
#reset and power-cycle the target<br />
#access the boot console of the target (for interactive use)<br />
#copy files to and from the target<br />
#execute commands on the target<br />
<br />
A lab host, in practice, is expected to be a normal PC machine running the Linux operating system. It should have sufficient performance and disk space to build the Linux kernel, and to host a number of copies of the Linux kernel source tree (and other source and binaries used for both host and target operation.) A minimum of 10 gigs of free hard disk space is recommenced on a lab host.<br />
<br />
All remote board access operations must be available from the Linux command line, and runnable in a batch mode (without interaction).<br />
<br />
=== Required/Recommended software for RBA host ===<br />
*toolchains - minimally capable of building a Linux kernel<br />
**toolchain source (for compliance with GPL)<br />
**toolchain binaries<br />
*kernel source<br />
*default config for target<br />
*"target" command, with following sub-commands:<br />
**target name is specified on command line<br />
**optional RBA_TARGET environment variable can specify the target being used<br />
*support the following sub-commands: <br />
**get_kernel [-o dir] - copy source for kernel to . or specified dir<br />
***kernel source should include a defconfig for the target<br />
**get_config [-o dir] - copy default target config to . or specified dir<br />
**setenv - prepare environment for building software for target<br />
**status - show current status of target (who is currently using it, is it operating, etc.)<br />
**info - show information about the target (technical information about target)<br />
**acquire [time[m|h|d]] - lock target board for use (default is 2 hours)<br />
***[-s time] specify starting time, default is now<br />
**release - unlock target board for use (terminate a current reservation (same as "acquire 0")<br />
**reset - reset target board<br />
**power_off - turn off power to target<br />
**power_on - turn on power to target<br />
**power - power cycle target (turn power off then on again)<br />
**console - access console for target (place where bootloader messages (and kernel boot messages) appear)(Only one of these is allowed)<br />
**login - get (non-console) login prompt for target (There can be multiple of these)<br />
**list - show list of targets available on this host<br />
**kinstall [<kinstall-type>] - kernel install - copy kernel from kernel build area to target, or to place on host where it is used to boot the target<br />
***<kinstall-type> specifies the type of kernel install to use. Use target kinstall_list to see possible options. Some examples might be: tftp, host, serial_download, eth_download, download_XIP, etc.<br />
**cp - copy file to/from the target<br />
**wait - wait for an operation to complete on the target<br />
**run [xxx] - run a program on the target<br />
*customary kernel command-line development tools<br />
**vi, diff, patch, make<br />
**toolchain specific to target: gcc, binutils, etc.<br />
**nice to have, but not required:<br />
***diffstat, cscope, ccache, ctags, diffinfo, tpm<br />
**~/bin should be on the path, so users can install their own software<br />
*target root file system (binaries)<br />
*(optional) target root file system source and build system<br />
<br />
=== Required Hardware support for RBA target ===<br />
*some remote console capability (usually serial)<br />
*ability to survice power-off/power-on cycle - in the minimum, if remote reboot and remote reset are not supported<br />
* a mechanism to remotely power-off/power-on the target (This might be provided by X10 control of the board power supply via software on the host)<br />
<br />
=== Optional Hardware support for RBA target ===<br />
*ability to remotely reset the target by software control on the host<br />
<br />
=== Required/Recommended software for RBA target ===<br />
This is the absolute minimum.<br />
*target-specific bootloader<br />
**must support some remote console (serial is best)<br />
**must support dynamically loading the kernel (either via serial or via network, usually tftp from host is best)<br />
*Linux kernel<br />
*login shell<br />
*init script that can start test scripts on startup<br />
<br />
=== Advanced optional features ===<br />
*networking support, and one or more of the following:<br />
**telnetd, rshd or sshd<br />
***this would support remote command execution<br />
*ftpd, rcpd, sshd?<br />
**this would support remote <br />
*this would support file operations (in non-NFS-rootfs mode)<br />
*ssh and scp availability on target<br />
**this would support file operations (in non-NFS-rootfs mode)<br />
**this would support remote command execution<br />
*networking supporttelnetd<br />
**this would support remote command execution<br />
*web server on host with CGI support for target status<br />
*web server on host with CGI-based RBA target reservation system<br />
<br />
=== Required commands ===<br />
<br />
== Notes (informational and non-normative) ==<br />
additional information or clarifying comments<br />
<br />
== References ==<br />
pointer(s) to implementation, open source project(s), POSIX specification, etc.<br />
<br />
=== Related work ===<br />
Remote System Framework for eclipse - proposal by MontaVista - see<br />
[https://bugs.eclipse.org/bugs/attachment.cgi?id==18820 RSF EclipseCon Presentation.ppt]<br />
<br />
Device Software Development Platform - proposal for target development model and system for use with Eclipse. See:<br />
[http://www.eclipse.org/proposals/eclipse-dsdp/index.html http://www.eclipse.org/proposals/eclipse-dsdp/index.html]<br />
<br />
== Remaining Issues ==<br />
[this is a placeholder section for listing issues while the spec is under development.<br />
It should be empty when the spec is completed (or the issues should be deferable to<br />
a subsequent version of the spec).]<br />
<br />
[[Category:HOWTOs]]</div>Cschallehttps://elinux.org/index.php?title=RidgeRun_LeopardBoard_SDK_Hints&diff=74101RidgeRun LeopardBoard SDK Hints2011-10-28T10:29:45Z<p>Cschalle: Add categories</p>
<hr />
<div>== Solutions to known issues ==<br />
<br />
=== 'division by zero' in kernel error when I try to use ALSA input ===<br />
<br />
This is a known issue that has been discussed on the ASOC mailing list. The problem is<br />
that the function davinci_pcm_enqueue_dma performs this operations:<br />
<br />
<pre><br />
data_type = prtd->params->data_type;<br />
count = period_size / data_type;<br />
</pre><br />
<br />
The first time, data_type is set to zero, so we get the error Division<br />
by zero in kernel. This is the reason why the pipe arecord | aplay<br />
works after running arecord or aplay first.<br />
<br />
Apply the [[Media:Asoc-davinci-pcm.patch]] to the kernel 2.6.29 to resolve this issue.<br />
<br />
=== 'Kernel panic' Unable to mount root fs when using NFS ===<br />
<br />
This issue happens when NFS file system is used. Leopard Board does not have a MAC address assign, this issue can be detected by taking a look into the kernel log after booting the board:<br />
<br />
1. MAC address is set to 00:00:00:00:00<br />
<br />
<pre><br />
[42949373.950000] dm9000 Ethernet Driver, V1.31<br />
[42949374.080000] dm9000 dm9000: eth%d: Invalid ethernet MAC address. Please seg<br />
[42949374.080000] eth0 (dm9000): not using net_device_ops yet<br />
[42949374.090000] eth0: dm9000e at c780c000,c7810016 IRQ 73 MAC: 00:00:00:00:00)<br />
</pre><br />
<br />
2. Kernel panic error<br />
<br />
<pre><br />
[42949465.940000] Kernel panic - not syncing: VFS: Unable to mount root fs on u)<br />
</pre><br />
<br />
There are different ways of solving this issue:<br />
<br />
1. Forced the leopard to get a MAC address: run the ping command in the u-boot console:<br />
<br />
<pre><br />
Leopard Board # ping <ip_address> or <br />
Leopard Board # setenv bootcmd="ping 192.168.1.1;nboot KERNEL"<br />
</pre><br />
<br />
2. Apply the [[Media:mac_address.patch]] that generates a random MAC address for the leopard.<br />
<br />
<br />
=== 'Leopard Board got bricked ' BOOTUBLStarting UART Boot... ===<br />
<br />
Whenever UBL or the Uboot on a Leopard Board fail, this means that your board got bricked, however, there's an easy way to recover it. For information on how to recover your leopard, go to: [http://designsomething.org/leopardboard/f/22/t/97.aspx How to recover a bricked Leopard Board]<br />
<br />
=== 'NAND read: 'FS' is not a number' UBOOT,KERNEL,FS are not set ===<br />
<br />
This issue causes your board to do not boot, causing the following message:<br />
<br />
<pre><br />
NAND read: 'FS' is not a number<br />
<br />
NAND read: 'KERNEL' is not a number<br />
## Booting image at 82000000 ...<br />
Bad Magic Number<br />
</pre><br />
<br />
The problem is that "make install" was ran over the uboot that comes preinstalled on the Leopard Board. This uboot doesn't support<br />
the MTD partitions causing the above messages. To solve this issue:<br />
<br />
1. Run "make installbootloader": this will upgrade your board with the uboot that comes with the SDK<br />
<br />
2. Reboot your board<br />
<br />
3. Run "make install"<br />
<br />
If the problem persists, your board probably got bricked, refer to: [http://designsomething.org/leopardboard/f/22/t/97.aspx How to recover a bricked Leopard Board]<br />
<br />
=== 'xdctools and dvsdk directories not found' ===<br />
<br />
The SDK requires several tools provided by TI, which you should have installed on your host machine.<br />
<br />
If the following error appears, you should download [http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/rtsc/xdctools_3_10/xdctools_3_10_05_61/index_external.html xdctools_setuplinux_3_10_05_61.bin]<br />
<br />
<pre><br />
Please provide the path to xdctools_3_10_05_61 installation location or press ctrl-c to abort<br />
<br />
Unable to find the directory . Aborting<br />
make[1]: *** [xdctools_3_10_05_61] Error 1<br />
make[1]: Leaving directory `<home_directory>/DM355SDK789311/proprietary/xdctools_3_10_05'<br />
Error building xdctools_3_10_05<br />
make: *** [dependency_build] Error 1<br />
<br />
</pre><br />
<br />
Also, if the following error appears, you should download [https://focus-webapps.ti.com/licreg/productdownload.tsp?toPerform=productDownload&downloadPage=true&location=http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_2_00/latest//exports//dvsdk_setuplinux_2_00_00_22.bin dvsdk_setuplinux_2_00_00_22.bin]<br />
<br />
<pre><br />
Please provide the path to dvsdk_2_00_00_22 installation location or press ctrl-c to abort<br />
<br />
Unable to find the file /.dvsdk_version. Aborting<br />
make[1]: *** [dvsdk_2_00_00_22] Error 1<br />
make[1]: Leaving directory `<home_directory>/DM355SDK789311/proprietary/dvsdk_2_00_00'<br />
Error building dvsdk_2_00_00<br />
make: *** [dependency_build] Error 1<br />
<br />
</pre><br />
<br />
Both packages should be install in your home directory for the SDK to find them automatically, if you do install these tools in another path, you can provide the correct path when the SDK requests it or create a dynamic link from that path to your home directory.<br />
<br />
=== 'Error building gst-dmai-plugins' ===<br />
<br />
If you are having the following error when building gst-dmai-plugins:<br />
<br />
<pre><br />
js: "/home/jim/DM355SDK789311/proprietary/xdctools_3_10_05/<br />
xdctools_3_10_05_61/packages/xdc/xdc.tci", line 461:<br />
xdc.services.global.XDCException: xdc.MODULE_NOT_FOUND: xdc.module:<br />
module name '-p' must be qualified with its package name<br />
"./config.bld", line 5<br />
gmake: *** No rule to make target `.configuro'. Stop.<br />
js: "/home/jim/DM355SDK789311/proprietary/xdctools_3_10_05/<br />
xdctools_3_10_05_61/packages/xdc/tools/Cmdr.xs", line 40: Error:<br />
xdc.tools.configuro: configuration failed due to earlier errors<br />
(status = 2); 'linker.cmd' deleted.<br />
</pre><br />
<br />
You might have a corrupted file system on your host machine. <br />
*Run 'make clean' in ~/DM355SDK789311$<br />
*Check for any messages about corrupted files in the log, if found, fix the corresponding issue.<br />
*Run 'make clean' again<br />
*Compile again the SDK: 'make'<br />
<br />
=== 'mono (mono-common) is NOT installed' ===<br />
<br />
It is a known issue with the old SDK: LeopardSDK-781811-Linux-x86-Install.bin. The issue basically consists on the package mono-common not installed, and then mono-gmcs, when they both are already installed in the host machine.<br />
<br />
<pre><br />
>> mono (mono-common) is NOT installed<br />
gmcs (mono-gmcs) is installed<br />
There are missing packages, please install them:<br />
apt-get install mono-common<br />
make: *** [.oscheck] Error 1<br />
</pre><br />
<br />
One workaround to get pass this issue, once you have both packages installed, is to remove gmcs from:<br />
<br />
<pre><br />
bsp/arch/host.required<br />
</pre><br />
<br />
or you can also create a symbolic link to the gmcs2 with name gmcs<br />
<br />
<pre><br />
sudo ln -s /usr/bin/gmcs /usr/bin/gmcs2<br />
</pre><br />
<br />
=== CMEMK errors when capturing video ===<br />
<br />
This is not a non fatal error found in the SDK when video is captured using the VGA. <br />
<br />
<pre><br />
<br />
Execution ended after 13373478335 ns.<br />
Setting pipeline to PAUSED ...<br />
Setting pipeline to READY ...<br />
Setting pipeline to NULL ...<br />
[42949461.220000] CMEMK Error: FREE: Not a registered user of physical buffer 0x87b14000<br />
[42949461.230000] CMEMK Error: FREE: Not a registered user of physical buffer 0x874d8000<br />
CMEM Error: free[42949461.240000] CMEMK Error: FREE: Not a registered user of physical buffer 0x874d3000<br />
: failed to free[42949461.250000] CMEMK Error: FREE: Not a registered user of physical buffer 0x87c8a000<br />
0x41c1c000<br />
CME[42949461.260000] CMEMK Error: FREE: Not a registered user of physical buffer 0x874d2000<br />
M Error: free: f[42949461.270000] CMEMK Error: FREE: Not a registered user of physical buffer 0x874d1000<br />
ailed to free 0x[42949461.280000] CMEMK Error: FREE: Not a registered user of physical buffer 0x874ec000<br />
41997000<br />
CMEM E[42949461.290000] CMEMK Error: FREE: Not a registered user of physical buffer 0x87507000<br />
rror: free: failed to free 0x419ab000<br />
CMEM Error: free: failed to free 0x419ac000<br />
CMEM Error: free: failed to free 0x41b22000<br />
CMEM Error: free: failed to free 0x41b23000<br />
<br />
</pre><br />
<br />
<br />
<br />
In order to correct this issue, the patch [[Media:Update-cmem.patch]] should be applied in DM355SDK789311/proprietary/dvsdk_2_00_00.<br />
<br />
== Integrating the audio codecs on RR SDK ==<br />
<br />
'''Important:''' The audio codecs are still been tested. Their functionality needs to be improved, there for many changes are required.<br />
<br />
=== RidgeRun Integration and Testing Status ===<br />
<br />
<br />
{| border=2<br />
! Codec !! Example Verified !! GStreamer Integration Complete !! GStreamer Integration Verified !! Notes<br />
|-<br />
| G.711 encode<br />
| Not tested<br />
| Not integrated<br />
| Not verified<br />
|<br />
|-<br />
| G.711 decode<br />
| Not tested<br />
| Not integrated<br />
| Not verified<br />
|<br />
|-<br />
| MP3 encode<br />
| Complete <br />
| Complete<br />
| Complete<br />
| A<br />
|-<br />
| MP3 decode<br />
| Complete<br />
| Complete<br />
| Complete<br />
|<br />
|-<br />
| WMA encode<br />
| Example fails.<br />
|<br />
|<br />
|<br />
|-<br />
| WMA decode<br />
| No tested.<br />
| Not integrated<br />
| Not verified<br />
|<br />
|-<br />
| AAC encode<br />
| Complete<br />
| Complete<br />
| Complete<br />
| A<br />
|-<br />
| AAC decode<br />
| Complete<br />
| Complete<br />
| Complete<br />
|<br />
|-<br />
| AEC <br>(acoustic echo cancellation)<br />
| Not tested<br />
| Not integrated<br />
| Not verified<br />
|<br />
|-<br />
|}<br />
<br />
Notes:<br />
<br />
* A - Can not record from alsa (alsasrc) and encode on the same GStreamer pipeline. Can record from alsa (alsasrc) and save to a file (in .pcm format).<br />
<br />
=== Integrating the audio codecs into the SDK ===<br />
<br />
'''NOTE:''' This is still under construction<br />
<br />
* Select the codecs in the SDK configuration menu<br />
<br />
1. Run make config<br />
2. Go to: Proprietary software<br />
3. Select:<br />
Texas Instruments CodecEngine for DM355<br />
Gstreamer DMAI plugins<br />
------> SVN plugins source (Branch)<br />
Build DM355s Codec configuration instead of standard D355 codecs<br />
<br />
* You need to download the codecs from Texas Instruments page. [http://www.go-dsp.com/forms/TIDigitalMediaSWCM/index.htm Download]. Once you extract all the files contained in the package:<br />
<br />
*Create a folder name codecs under proprietary.<br />
<pre><br />
DM355SDK789311/proprietary$ mkdir codecs<br />
</pre><br />
<br />
*Copy the folder with the codecs in the SDK directory<br />
<pre><br />
cp bundle-dm355s-AUDIO1-v1.2/aaclc_enc_2_6_00_production_dm355_mvl/packages-production/ittiam DM355SDK789311/proprietary/codecs -R<br />
</pre><br />
<br />
Repeat this step for:<br />
<pre><br />
cp bundle-dm355s-AUDIO1-v1.2/mp3_enc_2_8_00_production_dm355_mvl/packages-production/ittiam/ DM355SDK789311/proprietary/codecs -R<br />
cp bundle-dm355s-AUDIO1-v1.2/mp3_dec_3_6_00_production_dm355_mvl/packages-production/ittiam/ DM355SDK789311/proprietary/codecs -R<br />
cp bundle-dm355s-AUDIO1-v1.2/aaclc_enc_2_6_00_production_dm355_mvl/packages-production/ittiam/ DM355SDK789311/proprietary/codecs -R<br />
cp bundle-dm355s-AUDIO1-v1.2/wma_dec_4_6_01_production_dm355_mvl/packages-production/ittiam/ DM355SDK789311/proprietary/codecs -R<br />
cp bundle-dm355s-AUDIO1-v1.2/wma_enc_2_5_00_production_dm355_mvl/packages-production/ittiam/ DM355SDK789311/proprietary/codecs -R<br />
<br />
</pre><br />
<br />
*After the last step, the folder /DM355SDK789311/proprietary/codecs/ittiam/codecs$ should look like this:<br />
<br />
<pre><br />
aac_dec aaclc_enc mp3_dec mp3_enc wma_dec wma_enc<br />
</pre><br />
<br />
'''NOTE:''' This is important, because the encoders and decoders are going to search for the available codecs in this directory.<br />
<br />
*Apply the patch for the codecs to include the parameters definitions for the mp3 and aac encoders. This [[Media:Encoding-parameters.patch]] needs to be applied on the directory DM355SDK789311/proprietary/codecs. <br />
<br />
*The audio codecs have been tested and are working in Diego Dompe's branch, specifically in the revision 496.<br />
<br />
1. Go to /DM355SDK789311/proprietary/gst-dmai-plugins/<br />
make clean<br />
<br />
2. Go to /DM355SDK789311/proprietary/gst-dmai-plugins/src/ <br />
svn update -r 496<br />
autoreconf --install<br />
<br />
3. Apply the [[Media:Audio_decoders.patch]] in the directory /DM355SDK789311/proprietary/gst-dmai-plugins/src/src<br />
<br />
4. Compile the plugins. <br />
Go to /DM355SDK789311/proprietary/gst-dmai-plugins/<br />
make VERBOSE=1<br />
<br />
5. Install the plugins<br />
Go to /DM355SDK789311/proprietary/gst-dmai-plugins/<br />
make install<br />
<br />
=== Disable audio codecs in the SDK ===<br />
<br />
If you want to disable an specific codec in the SDK, follow the next steps. This example will remove the aac encoder and decoder.<br />
<br />
1. Modify the dm355s.cfg file<br />
<br />
<pre><br />
* Go to DM355SDK840402/proprietary/gst-dmai-plugins/src/src$<br />
* Open the dm355s.cfg file<br />
* Comment the lines:<br />
var AAC_DEC = xdc.useModule('ittiam.codecs.aac_dec.ce.AAC_DEC');<br />
var AACLC_ENC = xdc.useModule('ittiam.codecs.aaclc_enc.ce.AACLC_ENC');<br />
{name: "aaclcdec", mod: AAC_DEC, local: true, groupId: 1},<br />
{name: "aaclcenc", mod: AACLC_ENC, local: true, groupId: 1},<br />
</pre><br />
<br />
2. Modify the configure.ac file<br />
<br />
<pre><br />
* Go to DM355SDK840402/proprietary/gst-dmai-plugins/src$ <br />
* Open the configure.ac file<br />
* Comment the lines:<br />
#AC_DEFINE([AACLC_ARM_ITTIAM_ENCODER],[1],[Ittiam ARM AACLC Encoder])<br />
enable_aaclcenc_xdm1=1;<br />
enable_aaclcdec_xdm1=1;<br />
</pre><br />
<br />
3. Compile the plugins and install them<br />
<br />
<pre> <br />
* Go to DM355SDK840402/proprietary/gst-dmai-plugins$ <br />
* make VERBOSE=1<br />
* make install<br />
</pre><br />
<br />
[[Category:Development Boards]]<br />
[[Category:Tips and Tricks]]</div>Cschallehttps://elinux.org/index.php?title=Realtime_Preemption&diff=74089Realtime Preemption2011-10-28T10:28:16Z<p>Cschalle: Add category</p>
<hr />
<div>Table Of Contents:<br />
<br />
<br />
== Description ==<br />
=== Overview ===<br />
Realtime Preemption is (as of this writing 12/21/2004) a patch which tries to improve realtime performance of the<br />
Linux kernel.<br />
<br />
Recent patches from Ingo include a (large) number of technologies for improving preemption and debugging preemption<br />
issues with the Linux kernel.<br />
<br />
An overview of the technologies is as follows:<br />
** voluntary preempt = a set of voluntary preemption points for the kernel, to improve normal scheduling latency (These changes basically<br />
** BKL change to semaphore<br />
** latency tracer<br />
* <br />
<br />
==== Voluntary Preempt ====<br />
Overview:<br />
** if it's on at compile time, it can be turned off at runtime with the command line: "voluntary-preemption=0" or "voluntary-preemption=off"<br />
** Creates a new function might_resched(), which is used by might_sleep().<br />
***** might_resched calls cond_resched() if voluntary preemption is on.<br />
** Adds might_sleep in several places.<br />
<br />
==== Conversion of Spinlocks to Mutexes ====<br />
According to Ingo Molnar, it's primary author, "the big change in this release is the addition of PREEMPT_REALTIME, which is<br />
a new implementation of a fully preemptible kernel model"<br />
<br />
For a brief description of the overall technology, see:<br />
http://kerneltrap.org/node/3995?PHPSESSID=4bc02ae16e5a27308031f3cd664fd574<br />
<br />
Briefly, the technology makes spinlocks and rwlocks preemptible by default.<br />
** the patch auto-detects at compile-time the type of lock to use for a spinlock (mutex or original raw_spinlock)<br />
** it uses a feature of gcc to manage this (reducing patch size)<br />
** it uses native Linux semaphores for preemption<br />
** it convert rwlocks to rw-semaphores<br />
** apparently, about 90 locks are targetted for NON-conversion to preemptibility (that is, they are preserved as RAW_SPINLOCKS)<br />
<br />
Ingo mentioned at one time that this was about 20% of the locks in his kernel configuration, implying that there were about<br />
450 spinlocks present in the kernel in his configuration.<br />
<br />
Ingo said this about how well this works on Un-processor (UP) systems versus<br />
SMP systems.<br />
<br />
<br />
<pre>...and no matter how well UP works, to fix SMP one has to 'cover' all the<br />
necessary locks first before fixing it, which (drastic) increase in raw<br />
locks invalidates most of the UP efforts of getting rid of raw locks.<br />
That's why i decided to go for SMP primarily - didnt see much point in<br />
going for UP.<br />
</pre><br />
<br />
Normally, in UP the spinlocks are compiled away. When PREEMPT is turned on (without the new patch)<br />
these spinlocks are turned into markers for non-preemptible regions. When RT-PREEMPT is used,<br />
<br />
=== people working on/interested in this stuff ===<br />
** Ingo Molnar, [[Red Hat]], voluntary preemption, Ingo real-time preemption<br />
** Sven Dietrich, [[Monta Vista]], MV real-time preemption<br />
** Daniel Walker, [[Monta Vista]], priority inheritance??<br />
** John Cooper, [[Time Sys]], ???<br />
** Tim Bird, Sony, port to 2.6.10-native, port to PPC<br />
** Scott Woods, [[Time Sys]], IRQ threading??<br />
<br />
=== people working on related stuff ===<br />
** Bill Huey, [[Lynux Works]]??, mmlinux<br />
<br />
=== miscellaneous comments ===<br />
==== Comments regarding the scheduling of RT tasks ====<br />
Ingo said (in this [http://groups-beta.google.com/group/linux.kernel/browse_frm/thread/e8b81552643bfc50/d0e021c7065fa600?q=OSDL+bug+3770&_done=%2Fgroup%2Flinux.kernel%2Fsearch%3Fgroup%3Dlinux.kernel%26q%3DOSDL+bug+3770%26qt_g%3D1%26searchnow%3DSearch+this+group%26&_doneTitle=Back+to+Search&&d#d0e021c7065fa600 message]):<br />
<hr /><br />
note that my -RT patchset includes scheduler changes that implement<br />
"global RT scheduling" on SMP systems. Give it a go, it's at:<br />
<br />
http://redhat.com/~mingo/realtime-preempt/<br />
<br />
you have to enable CONFIG_PREEMPT_RT to active this feature. I've<br />
designed this code to not hurt non-RT scheduling, and i've optimized<br />
performance for the 'lightly loaded case' (which is the most common to<br />
occur on mainline-using systems).<br />
<br />
A very short description of the design: there's a global 'RT overload<br />
counter' - which is zero and causes no overhead if there is at most 1 RT<br />
task in every runqueue. (i.e. at most 2 RT tasks on a 2-way system, at<br />
most 4 RT tasks on a 4-way system, etc.) If the system gets into 'RT<br />
overload' mode (e.g. the third RT task gets activated on a 2-way box),<br />
then the scheduler starts to balance the RT tasks agressively. Also,<br />
whenever an RT task is preempted on a CPU, or is woken up but cannot<br />
preempt a higher-prio RT task on a given CPU, then it's 'pushed' to<br />
other CPUs if possible. This design avoids global locking (it avoids a<br />
global runqueue), which simplifies things immensely. (I first tried a<br />
global runqueue for RT tasks but the complexity impact was much bigger.)<br />
<br />
(note that these scheduler changes are resonably self-contained and do<br />
not depend on other parts of PREEMPT_RT, so in theory they could be<br />
added to mainline too, after some time - given lots of testing and broad<br />
agreement.)<br />
<hr /><br />
<br />
==== comments regarding the hard parts of this work ====<br />
Ingo says (at: http://groups-beta.google.com/group/linux.kernel/msg/cf036477d30ab736)<br />
<br />
<pre>some of the harder stuff:<br />
<br />
- the handling of per-CPU data structures (get_cpu_var())<br />
<br />
- RCU and softirq data structures<br />
<br />
- the handling of the IRQ flag<br />
</pre><br />
<br />
<br />
==== comments about the number of raw spinlocks needed ====<br />
Ingo says (at: http://groups-beta.google.com/group/linux.kernel/msg/e63b2860d2e993dd)<br />
<br />
<br />
<pre>Sven Dietrich <sdietr...@mvista.com> wrote:<br />
<br />
> IMO the number of raw_spinlocks should be lower, I said teens before.<br />
<br />
> Theoretically, it should only need to be around hardware registers and<br />
> some memory maps and cache code, plus interrupt controller and other<br />
> SMP-contended hardware.<br />
<br />
yeah, fully agreed. Right now the 90 locks i have means roughly 20% of<br />
all locking still happens as raw spinlocks.<br />
<br />
But, there is a 'correctness' _minimum_ set of spinlocks that _must_ be<br />
raw spinlocks - this i tried to map in the -T4 patch. The patch does run<br />
on SMP systems for example. (it was developed as an SMP kernel - in fact<br />
i never compiled it as UP :-|.) If code has per-CPU or preemption<br />
assumptions then there is no choice but to make it a raw spinlock, until<br />
those assumptions are fixed.<br />
</pre><br />
<br />
<br />
=== Rationale ===<br />
This feature is intended to provide much better realtime scheduling response for a Linux<br />
system.<br />
<br />
== Resources ==<br />
=== Projects ===<br />
Various parties are working on ports: [[Time Sys]] and Monta Vista, in particular, seem to have<br />
made ports to PPC and ARM platforms.<br />
<br />
=== Specifications ===<br />
None that I'm aware of.<br />
<br />
=== Online resources ===<br />
The original announcement for voluntary-preemption:<br />
** http://people.redhat.com/mingo/realtime-preempt/older/ANNOUNCE-voluntary<br />
<br />
Here's some stuff by Jonathon Corbet:<br />
<br />
** http://lwn.net/Articles/106010/<br />
** http://lwn.net/Articles/107269/<br />
** http://lwn.net/Articles/108216/<br />
** http://lwn.net/Articles/129511/<br />
<br />
There's a page of links about RT for audio at:<br />
** http://www.affenbande.org/~tapas/wiki/index.php?Low%20latency%20for%20audio%20work%20on%20linux%202.6.x<br />
<br />
A brief introduction of RT patch (Sorry, in Japanese only):<br />
** http://www.atmarkit.co.jp/fembedded/rtos03/rtos03a.html<br />
<br />
* Paper: "[http://www.reliableembeddedsystems.com/pdfs/2010_03_04_rt_linux.pdf Embedded GNU/Linux and Real-Time an executive summary]", 2010 by Robert Berger<br />
** This papers, prepared for the Embedded World Conference 2010, compares different real-time approaches (including RT-preempt and dual-kernel approaches).<br />
** The paper has an extensive list of references, which are very good.<br />
<br />
== Downloads ==<br />
=== Patch ===<br />
See http://redhat.com/~mingo/realtime-preempt/<br />
<br />
=== Utility programs ===<br />
[other programs, user-space, test, etc. related to this technology]<br />
<br />
== How To Use ==<br />
** apply patch<br />
** choose desired preemption level<br />
** compile kernel<br />
<br />
=== Configuration variables ===<br />
The patch introduces (or modifies) the following configuration variables:<br />
{| <br />
|- <br />
| Variable <br />
| Purpose<br />
|- <br />
| ASM_SEMAPHORES <br />
| <br />
|- <br />
| BLOCKER <br />
| <br />
|- <br />
| CRITICAL_IRQSOFF_TIMING <br />
| <br />
|- <br />
| CRITICAL_PREEMPT_TIMING <br />
| <br />
|- <br />
| CRITICAL_TIMING <br />
| <br />
|- <br />
| FRAME_POINTER <br />
| <br />
|- <br />
| LATENCY_TIMING <br />
| <br />
|- <br />
| LATENCY_TRACE <br />
| <br />
|- <br />
| MCOUNT <br />
| <br />
|- <br />
| PREEMPT <br />
| <br />
|- <br />
| PREEMPT_BKL <br />
| <br />
|- <br />
| PREEMPT_DESKTOP <br />
| <br />
|- <br />
| PREEMPT_HARDIRQS <br />
| <br />
|- <br />
| PREEMPT_NONE <br />
| <br />
|- <br />
| PREEMPT_RT <br />
| <br />
|- <br />
| PREEMPT_SOFTIRQS <br />
| <br />
|- <br />
| PREEMPT_TRACE <br />
| <br />
|- <br />
| PREEMPT_VOLUNTARY <br />
| <br />
|- <br />
| RTC_HISTOGRAM <br />
| <br />
|- <br />
| RT_DEADLOCK_DETECT <br />
| <br />
|- <br />
| RWSEM_GENERIC_SPINLOCK <br />
| <br />
|- <br />
| RWSEM_XCHGADD_ALGORITHM <br />
| <br />
|- <br />
| SPINLOCK_BKL <br />
| <br />
|- <br />
| USE_FRAME_POINTER <br />
| <br />
|- <br />
| WAKEUP_TIMING <br />
| <br />
|}<br />
<br />
* retrieved from patch with command:<br />
<br />
<pre><br />
grep "[+-]config " realtime-preempt-2.6.10-mm1-V0.7.34-01 | sed "s/[+-]config //" | sort | uniq<br />
</pre><br />
<br />
<br />
== How to validate ==<br />
[put references to test plans, scripts, methods, etc. here]<br />
** use included trace feature, or<br />
** use included latency overrun reporting mechanism<br />
** [[Preemption_Instrumentation]]<br />
<br />
== Related projects ==<br />
[[Monta Vista]] released a similar technology, which had the following features:<br />
<br />
See http://groups-beta.google.com/group/linux.kernel/msg/7eeef031d9ec1446<br />
<br />
<pre>These RT enhancements are an integration of features developed by<br />
others and some new MontaVista components:<br />
<br />
- Voluntary Preemption by Ingo Molnar<br />
- IRQ thread patches by Scott Wood and Ingo Molnar<br />
- BKL mutex patch by Ingo Molnar (with MV extensions)<br />
- PMutex from Germany's Universitaet der Bundeswehr, Munich<br />
- MontaVista mutex abstraction layer replacing spinlocks with mutexes<br />
</pre><br />
<br />
== Sample Results ==<br />
[Examples of use with measurement of the effects.]<br />
=== Case Study 1 ===<br />
** Linux RT Benchmarking Framework<br />
*** http://www.opersys.com/lrtbf/<br />
** Summary of dicussion in LKLM (sorry in Japanese)<br />
*** http://japan.linux.com/kernel/05/07/25/2334226.shtml?topic=1<br />
*** http://japan.linux.com/kernel/05/08/29/0817208.shtml?topic=1<br />
<br />
=== Case Study 2 ===<br />
<br />
Trevor Woerner published some results in November 2005<br />
regarding some latency measurements he have been<br />
recording on the 2.6.14 kernel with Ingo's patches.<br />
<br />
See http://geek.vtnet.ca/embedded/LatencyTests/html/index.html<br />
<br />
=== Case Study 3 ===<br />
<br />
== Status ==<br />
* [[Rt_Preempt_Subpatch_Table]]<br />
* Status: [not started??]<br />
(one of: not started, researched, implemented, measured, documented, accepted)<br />
* Architecture Support:<br />
(for each arch, one of: unknown, patches apply, compiles, runs, works, accepted)<br />
** i386: unknown<br />
** ARM: unknown<br />
** PPC: unknown<br />
** MIPS: unknown<br />
** SH: unknown<br />
<br />
== Future Work/Action Items ==<br />
Here is a list of things that could be worked on for this feature:<br />
- help with mainlining???<br />
- perform testing on multiple platforms<br />
- provide use cases for justification<br />
- what else?<br />
- break patch into manageable pieces - doesn't Ingo use any kind of patch management system???<br />
<br />
<br />
=== people who expressed interest ===<br />
Manas Saksena, Jon Masters, Takeharu Kato, Ralph Siemsen, Jyunji Kondo<br />
<br />
[[Category:Kernel]]<br />
[[Category:Tips and Tricks]]</div>Cschallehttps://elinux.org/index.php?title=RT-Preempt_Tutorial&diff=74083RT-Preempt Tutorial2011-10-28T10:27:02Z<p>Cschalle: Add category</p>
<hr />
<div>A summary tutorial of techniques [http://fossprogramming.com/rt-preempt-celf-b.odt] for using rt-preempt and real-time with Linux.<br />
<br />
The video of Kevin Dankwardt [http://fossprogramming.com/elc2010-dankwardt-rt-preempt.ogv] speaking on the use of RT-Preempt <br />
<br />
The slides (html)[http://fossprogramming.com/celf/celf-dankwardt-2010-b.html] (.odp)[http://fossprogramming.com/dankwardt.odp] from that talk.<br />
<br />
The sample programs, and the rt-preempt patch, from the summary can be found at [http://fossprogramming.com/examples.tar.bz2]<br />
<br />
The kernel [http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.33.3.tar.bz2] used in that example<br />
<br />
[[Category:HOWTOs]]</div>Cschallehttps://elinux.org/index.php?title=Ramdisks_demasked&diff=74071Ramdisks demasked2011-10-28T10:26:25Z<p>Cschalle: Add category</p>
<hr />
<div>= Ramdisks demasked =<br />
<br />
== Introduction ==<br />
<br />
When a system does not boot as quickly as expected, people sometimes revert to using a populated ram disk. The idea is that a ram disk resides in RAM, and hence is faster than a flash file system (which is correct). However, in the end no performance gain occurs. This page described why this happens and why in general a ram disk is not a good idea.<br />
<br />
== How ram disks are used ==<br />
<br />
The standard way to use a populated ram disk is to make a ram disk image, load it to memory using the boot loader (e.g. using a grub initrd line in menu.lst) and tell the kernel to use the ram disk (by means of the initrd= and root=/dev/ram0 kernel parameter).<br />
<br />
== Why is there no performance gain? ==<br />
<br />
This is simple. The ramdisk need to be loaded from flash memory. This takes time. After that there is indeed a speedup because you do not need to access the flash any more. However, the gain from this speedup hardly ever recoups the time needed to load the flash disk in the first place.<br />
<br />
Reason for this is that if there is no ram disk only those parts of an executable that are really needed are read from the background memory. Unit of transfer is a page (typically 4K or 8K). So if you were using only a few functions from e.g. glibc only those pages are loaded, not the full glibc (which might be around 1MB).<br/><br />
However in case of a ram disk, the whole glibc needs to be loaded. It is easy to see that loading a whole file (as done in the ram disk case) takes more time than reading the pages that you need (as is the case in the non ramk disk case).<br />
<br />
Now you might reason that pages might be read multiple times, which contribues to the gain. Technically you are right. Rereading the same page several times will cause some saving (although it still can be argued if this is enough to recover the ram disk load time). However lets look a little bit deeper:<br/><br />
If a page is reread it has been dropped from the buffer cache. This means that the kernel is running out of buffer space. If that is the problem then a ram disk is not going to be the solution! Better use no ram disk and give that memory to the kernel, who will most likely be able to use it in a more efficient manner.<br />
<br />
== But is there no situation when a ram disk will give a gain? ==<br />
<br />
Of course there are. I can think of the following situations:<br />
<br />
* If most or all pages of your ram disk are used, especially if your boot loader is faster reading the ram disk than the kernel is (this could be related to compression and/or to less read overhead).<br />
* If the source of the ram disk might disappear (e.g. if the ram file system resides on the network or on a removable disk that may be removed).<br />
* If execution start time is more important than boot time (then it helps if glibc and friends are in RAM). (this might also be the case if your ramfs is e.g. read over the network).<br />
<br />
== But what about initramfs? ==<br />
<br />
initramfs has the same inherent problems. It does a little bit better job because it copies the data to the buffer cache. After that the memory occupied by the initramfs image is released. However, still it reads more than needed.<br />
<br />
== So ram disks are useless? ==<br />
<br />
No, not at all. Having populated ram disk and use them as root filesystem is often not very meaningful. However a ram disk or ramfs device which is used to store temporary data can be very useful. It is a lot faster to write a 1MB temp file to RAM than it is to write it to flash.<br />
<br />
[[Category:Tips and Tricks]]</div>Cschallehttps://elinux.org/index.php?title=Soft_IRQ_Threads&diff=74047Soft IRQ Threads2011-10-28T10:23:33Z<p>Cschalle: Add category</p>
<hr />
<div>== Introduction ==<br />
This page describes [[Soft IRQ]] threads, which is a mechanism to run certain interrupt bottom halves using a <br />
kernel thread with scheduling that can be prioritized in the same scheduling class as other threads and processes.<br />
<br />
=== LKML discussions ===<br />
Recently (July 2004), two patches have been submitted to provide Soft IRQ threads for the Linux kernel.<br />
<br />
==== [[Time Sys]] patch ====<br />
See http://lkml.org/lkml/2004/7/13/125<br />
<br />
It applies against 2.6.8-mm1, with one PPC-specific reject<br />
<br />
==== Korty patch ====<br />
See http://lkml.org/lkml/2004/7/13/152<br />
<br />
=== Rationale ===<br />
This feature is important because it allows [[Soft IRQ]] processing to be scheduled at a lower priority than<br />
realtime threads. This allows for better realtime handling by the Linux kernel.<br />
<br />
== Downloads ==<br />
=== Patch ===<br />
- [Patch for CELF version XXXXXX is *here*]<br />
- [Patch for 2.4.xx is *here*]<br />
- [Patch for 2.6.xx is *here*]<br />
<br />
=== Utility programs ===<br />
None<br />
<br />
== How To Use ==<br />
[Should fill this in]<br />
<br />
== Sample Results ==<br />
<br />
== Future Work ==<br />
Here is a list of things that could be worked on for this feature:<br />
(None so far)<br />
<br />
[[Category:Kernel]]</div>Cschallehttps://elinux.org/index.php?title=Sw_Suspend&diff=74041Sw Suspend2011-10-28T10:22:41Z<p>Cschalle: Add category</p>
<hr />
<div>Table Of Contents:<br />
<br />
<br />
This page has information about [[Sw Suspend]], which is of interest to CE Linux Forum members,<br />
because we can use [[Sw Suspend]] as a start point of [[Snap Shot Start]] or hibernation on flash<br />
<br />
== CELF Technology/Project pages ==<br />
* [link to public wiki technology page]<br />
<br />
== Documents ==<br />
* [[Pm Sub System]] - Descriptions about kernel 2.6.x power managment subsystem<br />
* [[Sw Suspend Porting Notes]] - [[Sw Suspend]] quick-hack porting guide<br />
[links to documents]<br />
<br />
== Open Source Projects/Mailing Lists ==<br />
<br />
[[Category:HOWTOs]]</div>Cschallehttps://elinux.org/index.php?title=Reciva_Barracuda&diff=74035Reciva Barracuda2011-10-28T10:21:05Z<p>Cschalle: Add category</p>
<hr />
<div>The Barracuda Module is a Samsung [[S3C2410]] based cpu module which is used in some of the [http://www.reciva.net/ Reciva] internet radio devices.<br />
<br />
[[Media:barracuda_1.6.pdf|Module Datasheet]]<br />
<br />
[[Category:Hardware]]</div>Cschallehttps://elinux.org/index.php?title=Suspend_To_Disk_For_ARM&diff=74029Suspend To Disk For ARM2011-10-28T10:19:50Z<p>Cschalle: Add category</p>
<hr />
<div>Table Of Contents:<br />
<br />
<br />
== Description ==<br />
<br />
This page shows the result of applying suspend to disk feature for ARM architecture.<br />
Related pages are:<br />
<br />
* [[Sw Suspend]] - Information about [[Sw Suspend]]<br />
* [[Sw Suspend Porting Notes]] - [[Sw Suspend]] quick-hack porting guide<br />
<br />
<br />
== Target Environment ==<br />
<br />
=== Hardware Information ===<br />
<br />
[[OSK|OSK]] reference board is used.<br />
<br />
Since OSK5912 board does not have disk to save suspend image to, flash is used to store suspend image.<br />
<br />
=== Software Information ===<br />
<br />
linux kernel 2.6.11 based kernel is used for swsusp, and 2.6.14 based kernel is used for suspend2.<br />
Necessary patches are described in next section.<br />
<br />
<br />
== swsusp for ARM ==<br />
<br />
=== build kernel ===<br />
Below is the kernel patch stack applied on top of vanilla 2.6.11 kernel.<br />
<br />
* patch-2.6.11-omap1 from [http://www.muru.com/linux/omap/ muru.com]<br />
* [[Media:swsusp-arm-2.6.11.patch| swsusp-arm-2.6.11.patch]]<br />
* [[Media:swsusp-osk-2.6.11.patch| swsusp-osk-2.6.11.patch]]<br />
<br />
To build kernel, do the following: <br />
<br />
(assuming you have cross comiler for ARM)<br />
* enable CONFIG_PM<br />
* enable CONFIG_SOFTWARE_SUSPEND<br />
* enable CONFIG_SWSUSP_MTDBLOCK_FLUSH<br />
<br />
This can be done for example by:<br />
<br />
<pre><br />
$ make omap_osk_5912_defconfig<br />
$ make menuconfig<br />
<br />
General setup ---><br />
[*] Power Management Support<br />
[*] Software Suspend (EXPERIMENTAL)<br />
[*] Flush MTD Block<br />
<br />
also, NFS is used as rootfs<br />
<br />
File systems ---><br />
Network File Systems ---><br />
[*] Root file systems on NFS<br />
<br />
$ make uImage<br />
</pre><br />
<br />
also, check that CONFIG_SYSFS is enabled. (which is default)<br />
<br />
=== do swsusp ===<br />
<br />
Boot OSK board with above kernel.<br />
Issue following command as super user to suspend to disk:<br />
<br />
<pre><br />
(mount sysfs)<br />
$ mkdir /sys<br />
$ mount -t sysfs none /sys<br />
<br />
(enable flash as swap)<br />
$ mkswap /dev/mtdblock3<br />
$ swapon /dev/mtdblock3<br />
<br />
(run some applications)<br />
<br />
(trigger suspend to disk)<br />
$ echo disk > /sys/power/state<br />
</pre><br />
<br />
After the suspend to disk is triggered, messages are emitted to console, and machine would halt.<br />
<br />
On next bootup of the board, pass below additional argument to kernel: <br />
** resume=/dev/mtdblock3 <br />
<br />
Below is an example: <br />
<br />
<pre><br />
OMAP5912 OSK # setenv bootargs console=ttyS0,115200n8 ip=dhcp root=/dev/nfs resume=/dev/mtdblock3<br />
OMAP5912 OSK # saveenv<br />
</pre><br />
<br />
<br />
and then boot as usual.<br />
<br />
At near end of booting kernel, system reads suspended image, and resumes.<br />
<br />
<br />
=== Known Problems / FAQs ===<br />
<br />
- I would like to suspend image to different storage <br />
I have only tested with mtdblock3, and in swsusp-osk-2.6.11.patch, it is hard coded (sorry...) <br />
For other device (such as USB storage), I have not tested.<br />
<br />
- When the suspended image gets big, system does not resume <br />
This turned out to be misconfiguration of EMIFS_CS3 register at boot loader, if you are using <br />
u-boot. There are 2 solutions to this: <br />
<br />
*** fix EMIFS_CS3 value in u-boot and rebuild it<br />
*** set the correct value in kernel and rebuild it<br />
<br />
u-boot fix for file u-boot-1.1.[123]/board/omap5912osk/platform.S or u-boot-1.1.4/omap5912osk/lowlevel_init.S:<br />
<br />
<pre><br />
VAL_TC_EMIFS_CS3_CONFIG:<br />
- .word 0x88011131<br />
+ .word 0x88013141<br />
</pre><br />
<br />
<br />
kernel re-set the value for file arch/arm/mach-omap/board-osk.c<br />
<br />
<pre><br />
+ #define EMIFS_CS3_VAL (0x88013141)<br />
static void __init osk_init(void)<br />
{<br />
+ /* Workaround for wrong CS3 (NOR flash) timing<br />
+ * There are some U-Boot versions out there which configure<br />
+ * wrong CS3 memory timings. This mainly leads to CRC<br />
+ * or similiar errors if you use NOR flash (e.g. with JFFS2)<br />
+ */<br />
+ if (EMIFS_CCS(3) != EMIFS_CS3_VAL)<br />
+ EMIFS_CCS(3) = EMIFS_CS3_VAL;<br />
</pre><br />
<br />
== suspend2 for ARM ==<br />
=== build kernel ===<br />
Below is the kernel patch stack applied on top of vanilla 2.6.14 kernel.<br />
<br />
* patch-2.6.14-omap1 from [http://www.muru.com/linux/omap/ muru.com]<br />
* 100-suspend2-2.2-rc14-for-2.6.14.patch from [http://www.suspend2.net suspend2.net]<br />
* [[Media:suspend2-2.2-rc14-arm-fixups.patch| suspend2-2.2-rc14-arm-fixups.patch]]<br />
* [[Media:suspend2-osk.patch| suspend2-osk.patch]]<br />
<br />
To build kernel, do the following:<br />
(assuming you have cross comiler for ARM)<br />
<br />
* enable CONFIG_PM<br />
* enable CONFIG_SUSPEND2<br />
* enable CONFIG_SUSPEND2_CRYPTO<br />
* enable CONFIG_CRYPTO<br />
* enable CONFIG_CRYPTO_LZF<br />
<br />
This can be done for example by:<br />
<br />
<pre><br />
$ make omap_osk_5912_defconfig<br />
$ make menuconfig <br />
<br />
Power management options ---><br />
[*] Suspend2 ---><br />
[*] File Writer<br />
[*] Swap Writer<br />
<br />
<br />
Cryptographic options ---><br />
[*] Cryptographic API<br />
<*> LZF compression algorithm<br />
<br />
also, change the OSK system timer to MPU Timer<br />
<br />
System Type ---><br />
TI OMAP Implementations ---><br />
System timer ---> use mpu timer<br />
<br />
$ make uImage<br />
</pre><br />
<br />
=== do suspend2 ===<br />
<br />
Boot OSK board with above kernel.<br />
On bootup of the board, pass below additional argument to kernel: <br />
** resume2=swap:/dev/mtdblock3 <br />
<br />
Below is an example: <br />
<br />
<pre><br />
OMAP5912 OSK # setenv bootargs console=ttyS0,115200n8 ip=dhcp root=/dev/nfs resume2=swap:/dev/mtdblock3<br />
OMAP5912 OSK # saveenv<br />
</pre><br />
<br />
<br />
<br />
Install hibernate script into target system, which could be obtained from suspend2 web page.<br />
<br />
Issue following command as super user to suspend to disk:<br />
<br />
<pre><br />
(enable flash as swap)<br />
$ mkswap /dev/mtdblock3<br />
$ swapon /dev/mtdblock3<br />
<br />
(trigger suspend2 to disk)<br />
$ hibernate<br />
</pre><br />
<br />
After the suspend to disk is triggered, messages are emitted to console, and machine would halt.<br />
<br />
Power the board again, make sure the kernel parameter contains resume2=swap:/dev/mtdblock3.<br />
<br />
At near the end of kernel boot, suspend2 resume operation begins, and resumes from previously suspended state.<br />
<br />
<br />
== snapshot boot for ARM ==<br />
<br />
/\ * * * WARNING * * * <br />
/\ This feature is very experimental, Your boot loader might get corrupted. <br />
/\ To restore boot loader, refer [[OSK|osk page]]], "Flash Recovery Utility" section. <br />
<br />
=== what is it ===<br />
<br />
Snapshot boot is similar to swsusp, but with much faster start up, by kernel and boot loader working together. <br />
In swsusp, time taken to resume is not very fast, since (a) it starts at `late_initcall', (b) snapshot image <br />
is copied twice (swap -> allocated mem -> orig mem), and (c) device state transfer from active -> suspend -> <br />
resume. In snapshot boot, image is copied directly to orig mem addr, and jumps into kernel resume point, not <br />
kernel entry point, and kernel handles device resume, and thaw processes.<br />
<br />
=== build boot loader ===<br />
<br />
Below is the patch stack applied on top of u-boot-1.1.4 from [http://sourceforge.net/projects/u-boot u-boot] web page. <br />
First three patches are to build osk5912 target, rest are for snapshot boot.<br />
<br />
* [[Media:omap5912osk-fix-undef.patch| omap5912osk-fix-undef.patch]]<br />
* [[Media:omap5912osk-fix-cfi-flash.patch| omap5912osk-fix-cfi-flash.patch]]<br />
* [[Media:omap5912osk-fix-setup-val.patch| omap5912osk-fix-setup-val.patch]]<br />
* [[Media:snapshot-boot-core.patch| snapshot-boot-core.patch]]<br />
* [[Media:snapshot-boot-arm.patch| snapshot-boot-arm.patch]]<br />
* [[Media:snapshot-boot-osk.patch| snapshot-boot-osk.patch]]<br />
<br />
To build u-boot, do the following:<br />
<br />
<pre><br />
$ make CROSS_COMPILE=arm-linux- omap5912osk_config<br />
$ make CROSS_COMPILE=arm-linux- all<br />
</pre><br />
<br />
=== install boot loader ===<br />
<br />
If autoboot is set, hit any key to enter u-boot command prompt. <br />
<br />
Below is example installation <br />
<br />
<pre><br />
OMAP5912 OSK # tftp 0x10000000 u-boot.bin<br />
<br />
Take note of bytes that were transfered; take note of below message<br />
Bytes transferred = 96952 (17ab8 hex)<br />
<br />
OMAP5912 OSK # protect off 00000000 0001ffff<br />
OMAP5912 OSK # erase 00000000 0001ffff<br />
OMAP5912 OSK # cp.b 0x10000000 0x00000000 0x00017ab8<br />
OMAP5912 OSK # protect on 00000000 0001ffff<br />
OMAP5912 OSK # reset<br />
</pre><br />
<br />
<br />
Again, if you are messed up, take a look at [[OSK|osk page]]], "Flash Recovery Utility" section. <br />
<br />
<br />
=== build kernel ===<br />
Below is the kernel patch stack applied on top of vanilla 2.6.11 kernel. <br />
First three patches are the same patches that were used in swsusp.<br />
<br />
* patch-2.6.11-omap1 from [http://www.muru.com/linux/omap/ muru.com]<br />
* [[Media:swsusp-arm-2.6.11.patch| swsusp-arm-2.6.11.patch]]<br />
* [[Media:swsusp-osk-2.6.11.patch| swsusp-osk-2.6.11.patch]]<br />
* [[Media:swsusp-preserve-image.patch| swsusp-preserve-image.patch]]<br />
* [[Media:snapshot-core-2.6.11.patch| snapshot-core-2.6.11.patch]]<br />
* [[Media:snapshot-arm-2.6.11.patch| snapshot-arm-2.6.11.patch]]<br />
<br />
To build kernel, do the following: <br />
<br />
(assuming you have cross comiler for ARM)<br />
<br />
<pre><br />
$ make omap_osk_5912_defconfig<br />
$ make menuconfig<br />
<br />
General setup ---><br />
<br />
PCCARD (PCMCIA/CardBus) support ---><br />
<*> PCCard (PCMCIA/CardBus) support<br />
<*> 16-bit PCMCIA support (NEW)<br />
<*> OMAP CompactFlash Controller<br />
<br />
[*] Power Management Support<br />
[*] Software Suspend (EXPERIMENTAL)<br />
[*] Flush MTD Block<br />
[*] Preserve swsuspend image<br />
<br />
also, NFS is used as rootfs<br />
<br />
File systems ---><br />
Network File Systems ---><br />
[*] Root file systems on NFS<br />
<br />
$ make uImage<br />
</pre><br />
<br />
=== do snapshot boot ===<br />
<br />
On bootup of the board, pass below additional argument to kernel: <br />
** resume=/dev/mtdblock3 <br />
** prsv-img <br />
<br />
Below is an example: <br />
<br />
<pre><br />
OMAP5912 OSK # setenv bootargs console=ttyS0,115200n8 ip=dhcp root=/dev/nfs resume=/dev/mtdblock3 prsv-img<br />
OMAP5912 OSK # saveenv<br />
</pre><br />
<br />
<br />
Boot OSK board with above kernel.<br />
<br />
Issue following command as super user to suspend to disk: (These steps are identical to swsusp)<br />
<br />
<pre><br />
(mount sysfs)<br />
$ mkdir /sys<br />
$ mount -t sysfs none /sys<br />
<br />
(enable flash as swap)<br />
$ mkswap /dev/mtdblock3<br />
$ swapon /dev/mtdblock3<br />
<br />
(run some applications)<br />
<br />
(trigger suspend to disk)<br />
$ echo disk > /sys/power/state<br />
</pre><br />
<br />
After the suspend to disk is triggered, messages are emitted to console, and machine would halt. Power off the board.<br />
<br />
Power on the board, and hit any key to enter u-boot command prompt. <br />
From u-boot, issue snapshot boot command.<br />
<br />
<pre><br />
OMAP5912 OSK # bootss 0x00240000<br />
</pre><br />
<br />
<br />
The snapshot boot will start, and system resumes from previously suspended system state.<br />
Note that same image could be reused, (by specifying prsv-img in kernel command line) and <br />
contribute to fast startup of whole system.<br />
<br />
=== Startup comparison ===<br />
<br />
Below is a comparison of swusps vs. snapshot boot startup time. Time is measured using printk times,<br />
so there is some overhead due to measurement. Rootfs is nfs, and application is mplayer, running mpeg file.<br />
Application and userland is not optimized, prelink, XIP or other startup improvement techniques are not applied,<br />
so refer the data with relative time, not absolute time. Normal startup time without swsusp nor snapshot boot is<br />
about 11 seconds.<br />
<br />
Media:mplayer-swsusp.log<br />
Media:mplayer-ssboot.log<br />
<br />
NOTE: The latter two log files were not found on the old CELF Pulic Wiki, therefore links are broken here.<br />
<br />
[[Category:Kernel]]</div>Cschallehttps://elinux.org/index.php?title=Parallel_RC_Scripts&diff=74023Parallel RC Scripts2011-10-28T10:18:36Z<p>Cschalle: Add category</p>
<hr />
<div>== Description ==<br />
One way to reduce bootup time is to run RC scripts in parallel. RC scripts are normally run in sequence in a desktop configuration of Linux. By running the scripts in parallel, it is possible to take advantage of the multi-processing capabilities of the OS (such as overlapping execution with I/O, etc.)<br />
<br />
== How to implement or use ==<br />
See the projects listed below for details on different methods of doing this.<br />
<br />
== Expected Improvement ==<br />
[Not determined yet.]<br />
<br />
== Resources ==<br />
=== Projects ===<br />
* InitNG: a new replacement for SysV init. Boots your system much faster by running as much as possible asynchronously. See [http://www.initng.org/ InitNG]<br />
* IBM article on on using Makefile techniques to express dependencies between services and support parallel service start. See [http://www-106.ibm.com/developerworks/linux/library/l-boot.html?ca=dgr-lnxw04BootFaster BootFaster]<br />
* Richard Gooch project to rewrite boot script system from scratch. Eliminates lots of BSD and SYS V-isms, and introduces dependencies. See [http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/ boot scripts]<br />
* Serel project - for parallelizing service startup. Commands are inserted into RC scripts to cause needed services to start (based on XML database of dependencies). See [http://www.fastboot.org/ fastboot]<br />
<br />
== Specifications ==<br />
*LSB specification for comments in RC Scripts which allow parallization. See [http://www.linuxbase.org/spec/refspecs/LSB_1.1.0/gLSB/initscrcomconv.html]<br />
<br />
== Patches ==<br />
None.<br />
<br />
= Case Studies =<br />
[None yet.]<br />
<br />
== Case 1 ==<br />
[put information about an actual use of this technique here. A case study should include:]<br />
<br />
Hardware:: [hardware description here]<br />
Kernel Version:: [kernel version here]<br />
Configuration:: [information about the configuration used here]<br />
Time without change:: [put that here]<br />
Time with change:: [put that here]<br />
<br />
[Add any additional notes as you see fit.]<br />
== Case 2 ==<br />
== Case 3 ==<br />
<br />
[[Category:HOWTOs]]</div>Cschallehttps://elinux.org/index.php?title=Pre_Linking&diff=74017Pre Linking2011-10-28T10:17:14Z<p>Cschalle: Add category</p>
<hr />
<div>== Description ==<br />
Pre-Linking is a mechanism for linking programs to shared libraries ahead of time.<br />
In general, every time an application is run it must have it's external symbols resolved - looked up in the shared library symbol table, and fixed up in the program binary to refer to the correct offsets in the library. To use prelinking, a special utility is run which does this resolution and fixup once for the program. This saves the cost of linking at runtime. <br />
<br />
There is an existing package from RedHat which provides this feature.<br />
<br />
A drawback of this is that if the shared library is changed, the fixups are no longer correct, and the program must be fixed-up again. This is much less of an issue in an embedded situation, where the programs and libraries are less likely to change than in a desktop or server Linux system.<br />
<br />
== Overview of linking ==<br />
There is an excellent paper with an overview of dynamic linking issues at: [http://web.archive.org/web/*/http://www.cis.upenn.edu/~mwh/papers_DB/ieee_computer97.pdf Pre Linking Overview]<br />
This paper describes not only pre-linking, but lazy linking and more exotic systems, like compile-on-load.<br />
<br />
== Expected Improvement ==<br />
[This is not measured yet.]<br />
<br />
We expect that with use of prelinking, there will be a slight reduction in boot time for Linux system, in the area of initial application loading.<br />
<br />
We need to use this system and measure the effect of prelinking for a determined set of applications.<br />
<br />
== Resources ==<br />
<br />
=== RedHat prelinking system ===<br />
*The prelink package is at: http://people.redhat.com/jakub/prelink/<br />
*A white paper is at: [http://people.redhat.com/jakub/prelink/prelink.pdf prelink]<br />
<br />
prelink currently supports the following architectures: alpha, arm, cris, i386, ia64, ppc32, ppc64, s390, sh, sparc32, sparc64, x86_64. At present the glibc dynamic linker is required to prelink executables and load prelinked code, uClibc does not support it.<br />
<br />
=== Instructions for using prelinking with Gentoo ===<br />
The following page has information on how to use prelinking with a Gentoo system:<br />
<br />
http://www.gentoo.org/doc/en/prelink-howto.xml<br />
<br />
=== Related Projects ===<br />
*Prebinding (RelCache) - RelCache (aka ELF prebinding) news http://mail-index.netbsd.org/tech-userlevel/2002/12/04/0017.html <br />
*RelCache vs. Red Hat prelink<br />
http://mail-index.netbsd.org/tech-userlevel/2002/12/01/0000.html <br />
*Resident - Resident Good (comparisons with prebind)<br />
http://www.shiningsilence.com/dbsdlog/2004/01/20/215.html<br />
<br />
<br />
== Specifications ==<br />
None so far.<br />
<br />
== Patches ==<br />
No kernel patches required for kernels 2.4.10 and later.<br />
<br />
== Case Studies ==<br />
=== Case 1 - Panasonic mobile phone prelink ===<br />
Panasonic used pre-linking on their Linux-based mobile phones. These used a 2.4.x Linux kernel,<br />
for an ARM processor. Measuring the time to load a single multimedia application with regular<br />
dynamic linking and pre-linking, showed that pre-linking could save a lot of time.<br />
<br />
; Hardware : ARM9 (unspecified CPU frequency)<br />
; Kernel Version : 2.4.20 (based on Monta Vista Linux CEE 3.1), glibc 2.3<br />
; Time without change : 2479 ms<br />
; Time with change : 125 ms<br />
; Source : page 19 of [http://tree.celinuxforum.org/CelfPubWiki/ITJ2005Detail1-2?action=AttachFile&do=get&target=CELF_Technical_Jamboree_June13.pdf Making Mobile Phone with CE Linux]<br />
<br />
=== Case 2 ===<br />
=== Case 3 ===<br />
<br />
== Future Work ==<br />
This item is a work-in-progress, and we are just getting started.<br />
<br />
== Material from CELF presentations ==<br />
=== ARM Prelink ===<br />
* Japan Jamboree #3<br />
** http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree3#head-1515fb2d64cd91370e9cb2f6ad4847483e729cf3 In the presentation of "Making Mobile Phone with CE Linux", the evaluation of Prelink on ARM architecture was mentioned.<br />
*** by Mr. Mizuyama (Panasonic Mobile)<br />
<br />
=== MIPS Prelink ===<br />
* Japan Jamboree #13<br />
** http://tree.celinuxforum.org/CelfPubWiki/JapanTechnicalJamboree13#head-ab59e6354d343ec0a804b5f440d35b5dcc27304c<br />
*** Evaluation report by Mr. Yagi (Mitsubishi)<br />
<br />
[[Category:HOWTOs]]</div>Cschallehttps://elinux.org/index.php?title=Mini2440&diff=74011Mini24402011-10-28T10:16:07Z<p>Cschalle: Add categories</p>
<hr />
<div>= Hardware=<br />
<br />
[[image: Mini2440 3.jpg|600px|link=http://www.friendlyarm.net/products/mini2440]]<br />
<br />
*Dimension: 100 x 100 mm<br />
*CPU: 400 MHz Samsung S3C2440A ARM920T (max freq. 533 MHz)<br />
*RAM: 64 MB SDRAM, 32 bit Bus<br />
*Flash: 64 MB / 128 MB / 256 MB / 1GB NAND Flash and 2 MB NOR Flash with BIOS<br />
*EEPROM: 256 Byte (I2C)<br />
*Ext. Memory: SD-Card socket<br />
*Serial Ports: 1x DB9 connector (RS232), total: 3x serial port connectors<br />
*USB: 1x USB-A Host 1.1, 1x USB-B Device 1.1<br />
*Audio Output: 3.5 mm stereo jack<br />
*Audio Input: Connector + Condenser microphone<br />
*Ethernet: RJ-45 10/100M (DM9000)<br />
*RTC: Real Time Clock with battery<br />
*Beeper: PWM buzzer<br />
*Camera: 20 pin (2.0 mm) Camera interface<br />
*LCD Interface: 41 pin (1.0 mm) connector for FriendlyARM Displays and VGA Board<br />
*Touch Panel: 4 wire resistive<br />
*User Inputs: 6x push buttons and 1x A/D pot<br />
*User Outputs: 4x LEDs<br />
*Expansion: 40 pin System Bus, 34 pin GPIO, 10 pin Buttons (2.0 mm)<br />
*Debug: 10 pin JTAG (2.0 mm)<br />
*Power: regulated 5V (DC-Plug: 1.35mm inner x 3.5mm outer diameter)<br />
*Power Consumption: Mini2440: 0.3 A, Mini2440 + 3.5" LCD: 0.6 A, Mini2440 + 7" LCD: 1 A<br />
<br />
= Barebox =<br />
<br />
Barebox uses the same build (Kbuild) and configuration (Kconfig) tools as the Linux kernel.<br />
<br />
1) First you need to clone the tree<br />
<br />
git clone git://git.pengutronix.de/git/barebox.git<br />
<br />
Most probably you want to use a released Barebox version, by running 'git checkout <version>'. Check which versions are available with 'git tag -l' and use the latest one.<br />
<br />
2) Then you need to configure it:<br />
<br />
make mini2440_defconfig<br />
<br />
3) Compile it<br />
<br />
make<br />
<br />
4) Now you need to flash the nand for this you can use OpenOCD<br />
<br />
= OpenOCD =<br />
<br />
now you need so start OpenOCD. For this you need to specify the interface (First) and then the board<br />
<br />
for this I just a Jlink<br />
<br />
openocd -f interface/jlink.cfg -f target/samsung_s3c2440.cfg -c "adapter_khz 12000"<br />
<br />
Flashing barebox <br />
And then the following steps:<br />
*connect a terminal application to the mini2440's serial connector<br />
*connect the mini2440 to a working network<br />
*switch S2 to boot from NOR to boot into 'supervivi'<br />
*switch on your mini2440<br />
*run the OpenOCD daemon configured with the file shown above<br />
*connect to the OpenOCD daemon via 'telnet'.<br />
*run the following commands to download a barebox into your target<br />
<br />
<br />
> halt<br />
> load_image \<path to the 'barebox.bin'\> 0x31000000 bin<br />
> resume 0x31000000<br />
<br />
Now a barebox is starting from an already initialized CPU and SDRAM (done by<br />
'supervivi').<br />
<br />
Change to your terminal console and configure the network first. Adapt the<br />
following settings to your network:<br />
<br />
eth0.ipaddr=192.168.1.240<br />
eth0.netmask=255.255.255.0<br />
eth0.gateway=192.168.23.2<br />
eth0.serverip=192.168.1.7<br />
<br />
A 'ping' to your TFTP server should bring a "...is alive" message now.<br />
<br />
We are ready now to program a barebox into the NAND flash:<br />
<br />
erase /dev/nand0.barebox.bb<br />
tftp barebox.bin /dev/nand0.barebox.bb<br />
<br />
[[Category:Development Boards]]<br />
[[Category:Hardware]]</div>Cschallehttps://elinux.org/index.php?title=NGW100-RTC&diff=74005NGW100-RTC2011-10-28T10:14:37Z<p>Cschalle: Add category</p>
<hr />
<div>== Adding an external RTC ==<br />
Unfortunately the RTC embedded in the AT32AP700x is not battery backed (and no battery can be added) and consequently loses the time on powerloss.<br />
In order to keep the time one has to add an external rtc.<br />
<br />
I've choosen the simple DS1672 Binary Counter RTC from Maxim IC [http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2750], as it is already supported in the linux kernel. (Device-Drivers->RTC->DS1672, CONFIG_RTC_DRV_DS1672') and as it is quite cheap and simple.<br />
<br />
=== Enabling it in Linux ===<br />
Select support for i2c, i2c-gpio, rtc, rtc-ds1672 in the Kernel config, either as module or compiled in.<br />
(either via 'make menuconfig', or for Buildroot 'make linux26-menunonfig')<br />
<br />
In arch/avr32/boards/atngw100/setup.c add<br />
{I2C_BOARD_INFO("ds1672", 0x68), },<br />
to static struct i2c_board_info __initdata i2c_info[] (line 169)<br />
<br />
OR compile and load this simple module/driver:<br />
#include <linux/i2c.h><br />
#include <linux/rtc.h><br />
#define DRV_VERSION "0.1"<br />
static struct i2c_board_info i2c_info = {I2C_BOARD_INFO("ds1672", 0x68)};<br />
static struct i2c_client *i2c_client;<br />
static int __init ngw_ds1672_init(void)<br />
{<br />
struct i2c_adapter *adap = i2c_get_adapter(0);//we only have 1 i2c.<br />
i2c_client = i2c_new_device(adap,&i2c_info);<br />
return 0;<br />
}<br />
static void __exit ngw_ds1672_exit(void)<br />
{<br />
i2c_unregister_device(i2c_client);<br />
}<br />
MODULE_AUTHOR("Peter Huewe <peterhuewe <!at!> gmx.de>");<br />
MODULE_DESCRIPTION("Register Dallas/Maxim DS1672 i2c-client");<br />
MODULE_LICENSE("GPL");<br />
MODULE_VERSION(DRV_VERSION);<br />
module_init(ngw_ds1672_init);<br />
module_exit(ngw_ds1672_exit);<br />
<br />
== Setting the system clock from RTC at boot time ==<br />
<br />
In order to use the external RTC as a reference clock, I'd recommend adding the line to setup.c and compile in the drivers mentioned above (i2c, i2c-gpio, rtc, rtc-ds1672).<br />
<br />
Then, in the kernel config, set 'CONFIG_RTC_HCTOSYS_DEVICE' to 'rtc1' in order to use the external RTC as reference clock.<br />
Location:<br />
-> Device Drivers<br />
-> Real Time Clock<br />
-> Set system time from RTC on startup and resume<br />
-> RTC used to set the system time (change this from rtc0 to rtc1)<br />
<br />
<br />
== Schematics ==<br />
In order to ease the wiring of the ds1762 I created some schematics<br />
<br />
<br />
[[File:Ds1672-rtc Schaltplan.png]] [[File:Ds1672-rtc Steckplatine.png]]<br />
<br />
Schematics / Image created with [[fritzing]] - [http://fritzing.org/]<br />
<br />
[[Category:HOWTOs]]</div>Cschallehttps://elinux.org/index.php?title=Flameman/tutorm68k&diff=73999Flameman/tutorm68k2011-10-28T10:07:04Z<p>Cschalle: Add category</p>
<hr />
<div>For more interesting projects done by Flameman, be sure to checkout his [[Flameman#master_index|project index]]<br />
<br />
<br />
[[Image:tutorm68k-board.jpg]]<br />
<br />
this board has<br />
* mc68000 or mc68010<br />
* 2 acia mc6850 (set at 19200bps)<br />
* 1 pit mc68230<br />
* 2 ram 2x32Kbyte=64Kb, replaced with NVRAM<br />
* 2 rom ??? kb<br />
* motorola tutor firmware<br />
* board size: 250x130 mm <br />
* case size: 285x295 mm<br />
* 1A power consume<br />
<br />
<br />
case has been build from "IBM 3197 Terminal Logic Base"<br />
<br />
modified 04-2011: preliminary built tests firmware is on the go, minimal bsp support<br />
<br />
<br />
<br />
== picoMMU ==<br />
<br />
http://www.appuntidigitali.it/4262/virtualizzazione-a-basso-costo-col-motorola-68010/<br />
<br />
http://forums.freescale.com/freescale/board/message?board.id=CFCOMM&thread.id=7736<br />
<br />
=== develop ===<br />
<br />
==== IBM le suonerebbe mostrando quanti anni fosse avanti ====<br />
<br />
* parliamo di “pipeline”?<br />
si scopre che nel 1967 IBM mentre rilasciava il primo 360/91<br />
gia’ introduceva il concetto di “pipeline”<br />
(inventato da R.Tomasulo)<br />
<br />
* parliamo di “cache memory” ?<br />
e il 360, con tempo medio d’accesso di 80 nano secondi, introduceva anche quella<br />
ben 10-12 volte piu’ veloce della standard magnetic core memory<br />
<br />
* parliamo di “memoria virtuale” ?<br />
scopriamo che nel 1970 l’evoluzione dei sistemi 360 si distingue per la gestione della memoria virtuale, fatto decisamente inedito.<br />
La famiglia 370 portera’ negli nni a venire molti tecnici al di fuori del mondo IBM a denigrare la bassa capacita’ di memoria di alcuni sistemi IBM rispetto ad altre marche, non conoscendo le funzioni straordinarie della gestione della memoria virtuale.<br />
Se per quei tempi il meccanismo poteva essere “visionario” i fatti “moderni” hanno incontroverbilmente dimostrato quanto costoro errassero gravemente: per poter funzionare, un programma, deve essere caricato nella memoria centrale del computer. Se la memoria e’ troppo poca il programma non gira.<br />
<br />
Nei sistemi mainframe e mini IBM il problema e’ stato risolto con la memoria virtuale, che consente una gestione totalmente automatica di carico/scarico di parti di programma, non richieste in un determinato momento, da disco a memoria centrale.<br />
<br />
Ma non solo!, una altra funzione molto importante e’ il “virtual storage” (come lo chiama IBM), che consente di caricare in memoria parti di dati di cui il sistema prevede il prossimo utilizzo. In questo modo la macchina non deve chiedere frequentemente i dati che le servono, perche’ questi si trovano già disponibili nella memoria centrale. In sostanza il sistema vede memoria centrale e memorie di massa come un tutt’uno.<br />
<br />
la rivoluzione, quella vera, e’ nel 1978<br />
ovvero 2 anni prima che il prototipo del PC IBM vienise estremamemente semplificato, ridisegnato da Donald Estridge, in modo che potesse entrare negli stipendi della gente comune, e poi spedito in Microsoft,<br />
quella piccola azienda che non conosceva nessuno, ma che vendeva BASIC per macchine come l’Altair 8800, e che per IBM avrebbe invece dovuto confezionare quel sottile ed innocente sistema operativo DOS capace di far girare applicazioni assai modeste, senza pretese di affidabilita’, scalabilita’, e quantaltro ai tempi NON necessitava di timesharing, multitasking, etc, e quanto era stava per essere annunciato.<br />
<br />
Prima di svelarlo, un attimo di suspense … per ricordare che il core business IBM ha sempre ruotato nel gestire in modo estremamente sicuro ed efficiente una rete aziendale:applicazioni multiutente di buon livello, con ampio ventaglio per tutti i settori aziendali, oltre che piena coperatura anche per le esigenze di enti pubblici.<br />
<br />
Questi sono gli obiettivi che portarono la vera grande immensa rivoluzione segnata nel 1978 dal lancio del sistema S/38, pensato per abbattere il limite imposto dalla memoria, creando un continuo unico tra memoria e disco<br />
era nata la memoria virtuale, l’abbiamo gia’ detto, ma non solo! Veniva anche introdotto anche il concetto di oggetti incapsulati (le fondamenta della sicurezza, quella vera, in multiutenza blindata)<br />
e per finire, veniva introdotto anche il concetto di macchina virtuale, un meccanismo capace di rendere indipendente il layer applicativo dalla substrato hardware sottostante<br />
<br />
shock: era francamente troppo meraviglioso!<br />
<br />
tanto che nel ‘78 quella macchina (e il suo sistema operativo) era dannatamente difficile da comprendere, ma non solo per i clienti parecchio sbigottiti, ma sopratutto per gli sviluppatori che preferirono restare coi piedi per terra<br />
<br />
l’esperienza non segno’ tante vendite ma getto’ le fondamenta dei successivi AS400<br />
<br />
xke’ l’obbiettivo primario era, come sempre, rendere il sistema ottimizzato per elaborare transazioni, tante transazioni, tanto, ma proprio tanto IO !<br />
<br />
i successivi sistemi operativi si presentarono omogenei e completi, ma la grossa novita’ stava nel fatto che il software al lato applicativo, cioe’ quello vicino al cliente, era stranamente indipendente dalle evoluzioni hardware!<br />
<br />
Pazzesco ! Del resto l’obbietto “macchina virtuale” era centrato al punto che offriva compreso nel prezzo un database relazionale integrato ai più bassi livelli di macchina!<br />
<br />
e non solo! gran parte della virtualizzazione rendava davvero possibile operare con tecnologia Object Oriented (e siamo solo nel 1988!), in modo ampiamente scalabile, lavorando in multiprocessing, e, cosa fodamentale: progettato garantendo la massima sicurezza e riservatezza a causa della sua struttura interna (la tipicizzazione quasi richiama i concetti moderni introdotti da SUN con java)<br />
<br />
Gli AS400 hanno cambiato parecchie volte l’archietettura delle cpu degli strati harware + bassi, questo la dice lunga non solo sulla virtualizzazione ma anche sulla filosofia (non solo) IBM circa la struttura dell’architettura di un sistema di elaborazione: ovvero che non debba gravitare completamente e solamente sulla velocita’ del processore (o dei processori) “centrali”, non devono premiare SOLO la cpu (central process …), anzi al contrario, questi sistemi dispongono diversi processori specializzati in vari compiti per ottimizzare tutto il flusso di elaborazione degli input e degli output: sono macchine per elaborare dati e costruire informazioni utili in ambito aziendale, quindi vale la regola del “tanto I/O, poco calcolo”, che e’, come detto, l’opposto di quanto serve in un pc dedicato, per esempio, ad un gioco o ad un calcolo matematico o alla grafica.<br />
<br />
Ora, arrivando circa ai nostri anni, nel 2000 IBM presenta una nuova serie di server AS/400, chiamti “iSeries”, di classe paragonabile ai mainframe per affidabilita’ e scalabilita’, diffondendo il supporto agli open standard per lo sviluppo di nuove applicazioni e introducendo il concetto di potenza su richiesta (capacity on demand) utilissima per superare nelle aziende i picchi di necessita’ elaborativa, senza per questo ricorrere a macchine piu’ potenti.<br />
<br />
Fra le feature e’ possibile partizionare i dischi (LPAR) in modo da rendere disponibili parallelamente sistemi operativi diversi, ma tutti sotto la garanzia di affidabilità dell’hardware ormai ultrasperimentato.<br />
<br />
Nel 2003 arrivano anche i server serie z, fra cui lo z990 che vanta features sbalorditive:<br />
partendo dalla tecnologia del modulo di CPU, realizzato in MultiChipModule, ai risultati, pari a 9.000 mips, 13 miliardi di transazioni al giorno, l’affidabilita’ meno di 5 minuti di downtime all’anno, e le possibilita’ di distribuire dinamicamente i workload all’interno della macchina in base alle priorita’ stabilite dal cliente.<br />
<br />
==== idee che portano alla picoMMU ====<br />
<br />
con 68010 iniziano le possibilita' di virtualizzare: ai tempi venne sfornata una segment MMU mc68451, oggi si trova solo doc cartacea della paged MMU mc68851: nel mio caso non voglio impiegarla, troppo complessa, e quel punto impigherei un 68030 con MMU, una versione semplificata proprio della mc68851, gia’ integrata, xke' francaemente per il kernel semplice che ho in mente una paged MMU e’ esagerata<br />
<br />
quindi penso che, per la mia m68010 board, mi sintetizzero’ qualcosa di molti simil a quanto fu fatto per Apple Lisa<br />
<br />
ovvero qualcosa che soddisfi l’equazione<br />
<br />
if (!S) PA=(VA && MASK) + DISPLACEMENT<br />
else (!S) PA=VA<br />
<br />
Physical Addrss<br />
Virtual Address<br />
<br />
Praticamente un sistema di traslazione a un solo livello da VA a PA. Estremamente semplice.<br />
<br />
Beh, certo, dipende sempre da quello che vuoi farci. Se il kernel è “semplice” (non so com’è strutturato) come dici, può andare bene.<br />
<br />
esatto! e cosi’ posso anche rilassarne l’implementazione in VHDL, sia per complessita’, sia per risorse richieste<br />
<br />
fra l’altro ho spulciato la documentazione tecnica di Apple Lisa scoprendo che anche la loro MMU usava un approccio simile: PA=VA + displacement!<br />
<br />
ora, considerando che una unita’ segmente MMU mc68451 riesce a gestire solo 32 Task, considerando che aggiunge 4 cicli di clock per la traduzione, che necessita esclusivamente di un 68010, e considerando che 32Task indirizzabili rischiano di essere oggettivamente pochi al punto che sarebbe auspicabile porre almeno un paio di mc68451 in parallelo (cosa prevista, dunque fattibile) per scalarne il numero di Task indirizzabili (2×32): beh, visto che in embedded cio’ che si vende e’ 68ec/hc000, visto che della mc68451 non c’e’ documentazione (ne fornitura), ma che sopratutto queste MMU sono in fin dei conti di compromesso circuitale tanto quanto algoritmico: ma allora xke’ dunque non sintetizzare qualcosa di specifico, che riutilizzabile con core 68000 in commercio, e che concorra a semplificare ulteriormente l’intero progetto ?<br />
<br />
detto fatto, e il picoKernel ringrazia<br />
<br />
Immaginavo, ma io mi chiedo: non conviene buttarsi direttamente su soluzioni embedded che abbiano già integrata una MMU (magari più semplice, come quella presente nel 68030 o nel 68060)?<br />
Così si eviterebbe di dover progettare parte di una circuiteria, per quanto sia di gran lunga più semplice il modello PA=VA+Offset.<br />
<br />
Non sono un esperto di sistemi embedded, per cui non riesco a capire quali vantaggi possa portare una soluzione custom (che richiede maggiori costi di progettazione, e relativa perdita di tempo) rispetto a una preconfezionata.<br />
Mi sfugge il dominio applicativo nel suo complesso.<br />
<br />
in campo embedded si diventa maniacali, meno codice si scrive meglio e’ (a volte meno memoria dinamica, malloc per capirci, si usa, meglio e’)<br />
<br />
ne consegue che si tende a fare sistemi con task statici, memoria statica, poco codice e molto diretto al “problem solution”: questo xke’ impiegare una MMU (paged oriented) costa MOLTO in termini di codice!<br />
<br />
nel mio caso, a maggior ragione, il problem e’ … general purpose avocation, cioe’ hobby & learn for research<br />
<br />
sicche’ il primo punto e’ stato capire le differenze fra una segment MMU e una paged MMU, per poi farsi una idea di cosa altro si possa fare (’case we want to reinvent the wheel) per limare al massimo il codice da scrivere senza scendere al compromesso dei task statici<br />
<br />
ora, dagli studi e’ emerso che usare la MMU mc68851 e’ pari ad usare la MMU integrata in mc68030,40,60,..: stessa filosofia (paged MMU handling), stessa complessita’ (anzi la mc68851 e’ un filo + complessa, + transistor, qualche funzioncina in +, delle MMU integrate)<br />
<br />
il punto allora e’:<br />
<br />
* il progetto e’ nato per scopo hobbistici<br />
* quindi ha poco man power e poco tempo a disposizione<br />
* il kernel vuole essere semplice<br />
* ma non cosi’ “castrato” da dover ripiegare sul multi-tastking statico<br />
* le cpu target sono tutte CPU mmu-less (tipo mc68HC000)<br />
* quindi serve supporto MMU hw, esterno, per realizzare “memoria virtuale a basso costo”<br />
* (che poi e’ il titolo di questo thread)<br />
* dove “costo” e’ espresso in termini di man power, si: proprio tempo e codice da scrivere (nonche’ bug, nella filosofia the more lines you write the more bugs you have to find)<br />
<br />
una volta studiato cio’ che esiste, visti pregi e difetti, e relativi compromessi, si e’ pensato ad un possibile riutilizzo del nuovo know/how: quindi se prima ha avuto senso pensare (e studiare come) stare leggeri col codice impiegando una MMU sempliciotta come la mc68451, ora (anche, ma non solo, xke’ e’ un chip obsoleto, sprovvisto di doc) si pensa di riutilizzare quanto appreso in campo per confezionare qualcosa di nuovo che possa essere benissimo infilato in un progetto di sintesi di + ampio respiro<br />
<br />
gia’, non e’ troppo complesso infatti recuperare il codice VHDL della “picoMMU” (che massimizza al massimo i compromessi circuitali ma anche e sopratutto di codice al lato OS) ed aggiungerla (proprio come blocco funzionale) al progetto di una cpu (e magari anche RISC) in sintesi: tutto OnChip, tutto semplice, tutto gestibile con poche risorse “umane”, senza dover scomodare soluzione “preconfezionate”, che sono, in tutta franchezza “grasso che cola”<br />
<br />
chiudo lasciando intendere che il progetto della picoMMU e’ un filo + complesso di quanto ho riassunto prima come linee (o meglio bozza) base:<br />
<br />
quanto ho implementato, infatti, modella lo spazio virtuale (VAddr) di un task in 4 blocchi distinti<br />
<br />
<pre><br />
1) stack<br />
2) data<br />
3) text (codice eseguibile)<br />
4) shared memory<br />
<br />
la traduzione VAddr –> PAddr passa dunque per 4 comparatori di area<br />
if (x in min..max) in_range=true<br />
if (!S) switch (Vaddr) // user space address<br />
(<br />
range stack: PAddr=VAddr+stack.displacement;<br />
range data: PAddr=VAddr+data.displacement;<br />
range text: PAddr=VAddr+text.displacement;<br />
range shared: PAddr=VAddr+shared.displacement;<br />
default trap picoMMU_address_error;<br />
)<br />
else PAddr=VAddr; // superuser space address<br />
<br />
la picoMMU si compone di 4 registri che necessitano di aggiornamento ad ogni context switch<br />
<br />
32bit stack.displacement;<br />
32bit data.displacement;<br />
32bit text.displacement;<br />
32bit shared.displacement;<br />
<br />
tot 4×32bit=4×4byte=16byte OverHead<br />
<br />
(si, il 68000 ha 24bit di addr esterni, volendo si possono risparmiare 4byte spillando 1 byte per ogni registro: si hanno 12byte al posto di 16byte)<br />
<br />
restano altri registri<br />
* da inizializzare al kernel_mmu_init<br />
* oppure per “task” particolari<br />
<br />
32bit stack.range.min stack.range.max;<br />
32bit data.range.min data.range.max;<br />
32bit text.range.min text.range.max;<br />
32bit shared.range.min shared.range.max;<br />
</pre><br />
<br />
un modello molto semplice ma efficace!<br />
<br />
ma a livello di costi, per un hobbista, c’è comunque così tanta differenza fra una soluzione già bella e pronta (come la serie 683xx di Motorola/FreeScale) e una basata su 68HC000 + logica ad hoc?<br />
<br />
assolutamente si!<br />
<br />
in termini di codice da scrivere, in termini di riutilizzo di codice (specialmente vhdl), in termini di possibilita’ di impiego su altre cpu!<br />
<br />
addr di 24 o 32bit ? eleganza e linearita’, salvo o non salvo il package, si chiese motorola<br />
<br />
se la picoMMU e’ memorymapped in supervisior data area, allora aggiornare i suoi registri significa muovere 4 byte sul bus dati (ne + ne meno di una periferica qualsiasi, cosi’ e’ vista in supervisor data area). Ora, muovere sul package del 68000 gli addr bit son 24bit e sembra essere vantaggioso risparmiarsi 1 byte, ma si scopre invece che costa SEMPRE di meno una move.l di 4 byte che 3 move.b che 1 move.b, o da una move.w di 2 byte seguita da 1 move.b da 1byte. Costa di meno in termini di istruzioni e di cicli bus. Vero, non c’e’ nessun vantaggio =P<br />
<br />
come nel caso della mc68451, anche questo approccio di traduzione da VA a PA per essere “stabile” costa (purtroppo) 4 stadi sincroni al clock della cpu. Costa dunque 4 cicli di clock, e bisogna tenerne conto.<br />
<br />
4 cicli di clock e’ un limite imposto dalle tempistiche necessarie a propagare in modo corretto i segnali all’interno degli stadi, non tanto limiti ditenlogia a disposizione quanto limiti di progetto superabili SOLO riprogettando in modo + furbo<br />
<br />
Nel mio caso occorre attendere un tempo necessario affinche’ gli indireizzi siano stabili, campionarli poi in un latch (campo VA).<br />
In questa fase vengono attivati i 4 comparatori dei range dei blocchi (stack,data,text,shared)<br />
bisognera’ attendere un tempo necessario affinche’ il risultato delle 4 comparazioni vada a selezionare il registo da dare in pasto alla ALU per il “giusto” displacement (stack.disp,data.disp,text.disp,shared.disp)<br />
a quel punto la alu avra’ 32bit stabili di address e 32bit stabili del displacemente e dovra’ sommare bit a bit<br />
per produrre in uscita finalmente il campo PA<br />
<br />
il disegno + semplice che posso scrivere impiega 4 stadi, “garantiti ad informazione stabile”, pertanto chiede 4 colpi di clock<br />
<br />
Potrei ridurre i colpi di clock prendnedo + confidenza con i veri tempi di propagaziione, trovando magari scorciatoie: e sara’ il prossimo passo, di raffinamento<br />
<br />
forse potresti risparmiare un ciclo di clock eliminando il sommatore finale (e quindi anche la sua circuiteria), e sostituendolo con un selettore che preleva n bit alti dal VA, e i rimanenti m bit (bassi) dall’apposito displacement.<br />
<br />
In pratica una volta che il VA diventa “stabile”, vengono costruiti 4 indirizzi fisici “al volo”, prelevando i suoi n bit alti, e gli m bit (bassi) dei 4 displacement. A questo punto il comparatore dovrà semplicemente scegliere fra quale di questi 4.<br />
<br />
Quindi avresti una sorta di paginazione della memoria (soluzione meno generale / flessibile rispetto alla tua), che potrebbe anche andare bene.<br />
<br />
Certo, bisogna vedere sempre in che modo si prevede di implementare il kernel e le applicazioni, ma potrebbe rivelarsi un buon compromesso.<br />
<br />
il super trucco, volendo c’e'!<br />
<br />
e’ l’asso nella manica poco elegante ma molto efficacie che vorresti non dover giocare se non proprio proprio non ci sono altre carte, xke’ costa, e costa parecchio (in termini di euro al chip)<br />
<br />
si puo’ pensare di ricorrere ad PLL per raddoppiare la frequenza di clock interna alla CPLD/FPGA<br />
<br />
dunque, il clock CPU e’ di 12.5Mhz, con un PLL posso raddoppiarlo 2X in locale per una logica programmabile che regge tranquillamente fino a 50Mhz (con tempi di propagazione delle celle garantiti essere inferiori a 1/50Mhz) anche nei modelli economici, e! cosa essenziale, e! con un corridoio di aggancio di soli 5nsec di ritardo, quindi di fatto posso comprimere 4 cicli di clock in 2 cicli di clock senza stravolgere il progetto della picoMMU restando perfettamente allineato con il clock della CPU<br />
<br />
volevo ordinare un paio di PLL da Distrilect semi, un mc88920 ha un syncing addirittura + veloce di 5nec richiesti: aggancia in in 2.5nsec<br />
<br />
poi ho scoperto che queste meravigliosi PLL sono gli stessi PLL montati sull’apple LC475: in Distrilect c’era una ottima fornitura, alcuni addirittura largamente superiori ai requisiti<br />
<br />
<pre><br />
–> MC88920 is rated at 50MHz (2×25MHz bus<br />
–> MC88916DW70 is rated at 70MHz (2×35MHz bus)<br />
–> MC88916DW80 is rated at 80MHz (2×40MHz bus)<br />
</pre><br />
<br />
il modello + semplice costa oltre 40 euro, su ebay ho trovato 2 macchine LC475 funzionanti ed intere a 30 euro + 10 di shipping.<br />
<br />
L’hobbista si arrangia, anche dissaldando un chip SMD per risaldarlo su adattatore DIL (5 euro tutto compreso dalla Cina) =P<br />
<br />
ROFL: mitico! :D<br />
<br />
Comunque aumentando il clock dell’FPGA… stai barando!!! :D :D :D<br />
<br />
Però non credo che si possano dimezzare i cicli di clock. Molto dipende dal tempo che impiega l’address bus per stabilizzarsi. E’ soltanto quando il suo valore si trova stabilmente nel latch dell’FPGA, che è possibile poi “lavorare” anche a frequenze maggiori.<br />
<br />
eh si, giocarsi l’asso nella manica e’ barare =P<br />
<br />
tuttavia e’ un baro efficente, cioe’ che garantisce il risultato, xke’ se esternamente alla CPLD/FPGA ci si sincronizza su valori stabili dell’Addr proprio sul /AS (address strobe) della CPI, di li in poi, una volta campionati bit e’ affare della logica programmabile, la quale internamente e’ capace di propagare informazioni fra celle in tempi inferiori a 1/5Mhz, per esempio<br />
<br />
e dunque stringendo stringendo, se i tempi di propagazione di un agglomerato di celle (e qui dipende dai percorsi segnati dal compilatore VHDL to bitstream, ma solitamente sceglie percorsi subottimi “abbastanza” buoni sia per spazio che per tempo) reggono allora si puo’ fare l’asso nella manica ha proposto di fare: dimezzare i cicli di clock visti da tutto cio’ che segue la picoMMU<br />
<br />
tra l’altro si possono costruire half-adder molto veloci e comodi: il punto xro’, va detto, il punto rimane il disegno a stadi strettamente sincroni, xke’ tecnicamente gia’ il disegno del 68000 rispetto al disegno del 6800 ci insegna che si possono benissimo rilassare i vincoli sincroni pur garantendo tempistiche e funzionamento: ho ancora poca malizia e poche conoscenze in campo di logiche di sintesi per poter definire meccanismi asincroni infra stadio (per ridurre gli stadi), tuttavia e’ quantomeno intuibile il poter fare altrettanto internamente alla CPLD/FPGA<br />
<br />
ah, in caso di IRQ, la picoMMU si vede un FCR proveniente da text&data-superuser-space, quindi cortocircuita tutti gli stadi a seguire per forwardare in uscita direttamente quanto ha campionato in ingresso: PA=VA in 1 solo ciclo di clock!<br />
<br />
[[Category:HOWTOs]]</div>Cschallehttps://elinux.org/index.php?title=Hawkboard/Sandbox&diff=73993Hawkboard/Sandbox2011-10-28T10:00:19Z<p>Cschalle: Add category and suggest deletion</p>
<hr />
<div>[[Category:ToDelete]]</div>Cschallehttps://elinux.org/index.php?title=LocalUserGroups&diff=73987LocalUserGroups2011-10-28T09:55:52Z<p>Cschalle: Add category</p>
<hr />
<div>== Local Embedded Linux groups ==<br />
If you are interested in meeting with developers in your area, please add your name and location. Add contact information to your User Account so that people can get in touch with you.<br />
=== Canada ===<br />
==== Ontario ====<br />
* [[User:Wmat|Bill Traynor]] (Waterloo)<br />
<br />
=== United States ===<br />
==== Ohio ====<br />
* [[User:Cbrake|Cliff Brake]] (Akron, OH)<br />
<br />
==== Virginia ====<br />
<br />
* [[User:balister|Philip Balister]] (Blacksburg, VA)<br />
<br />
==== Pennsylvania ====<br />
<br />
* [[User:svolpe|Shane Volpe]] (Pittsburgh, PA)<br />
* [[User:sidhayn|Rick Farina]] (Pittsburgh, PA)<br />
* [[User:tblumer|Todd Blumer]] (Cranberry Twp., PA)<br />
<br />
[[Category:CELinux]]</div>Cschallehttps://elinux.org/index.php?title=Links_I%27m_working_on&diff=73981Links I'm working on2011-10-28T09:55:08Z<p>Cschalle: Add category</p>
<hr />
<div>[http://hp.vector.co.jp/authors/VA002416/teraterm.html TeraTerm]<br />
<br />
[Category:ToDelete]</div>Cschallehttps://elinux.org/index.php?title=S3c2440kits&diff=73891S3c2440kits2011-10-28T08:40:02Z<p>Cschalle: Add category</p>
<hr />
<div>===Highlights===<br />
{|border="1"<br />
|Samsung S3C2440A, based on ARM920T, 400MHz<br>64MB SDRAM and 64MB NAND Flash<br>UART, Ethernet, Audio I/O, SD card,...<br>Four USB HOST and One USB device<br>Supports 24-bit TFT LCD with touchscreen<br>Supports Linux2.6 and WinCE 5.0<br />
|[[File:S3c2440kits-mini.jpg]]<br />
|}<br />
<br />
=='''Hardware'''==<br />
===CPU Board <b>----- [http://code.google.com/p/corewind2440/wiki/Core2440III Core2440-III]</b>===<br />
[[File:S3c2440-top.jpg]][[File:S3c2440-back.jpg]]<br />
* ARM9 Samsung S3C2440A development board<br />
* 64Mbyte SDRAM, 64Mbyte Nand Flash<br />
* 250 pins connectors( Extend out all the I/O from S3C2440A with 250-pin connector)<br />
* One JTAG interface<br />
* RTC support<br />
* PCB: 6 layers, 78.7mm X 38mm X 1.6 mm<br />
<br />
===Mother board 1 <b>----- [http://code.google.com/p/corewind2440/wiki/Kit2440III Kit2440-III]</b>===<br />
[[File:S3c2440-kit-interface.jpg]]<br />
* LCD/Touch Screen interface (40-pin FPC connector, support resolution up to 2048*2048)<br />
* Audio input and output slot (3.5mm audio jack)<br />
* <b>4 USB Host interface and 1 USB device</b><br />
* one SD card slot<br />
* One 10/100M Ethernet interface (RJ45)<br />
* 3 serial port(One 3-wire Serial port, the others was under the DB9 interface)<br />
* One 20-pin Jtag interface<br />
* One reset button<br />
* two expansion connector (two 20Pin 2mm pitch of the GPIO Interface Contains:Camera, SPI, I/O, AD)<br />
* PCB: 4 layers, 105mm x 80mm <br />
* Fully supports Linux2.6.29<br />
<br />
===Electrical Characteristics===<br />
* Power supply: +9V<br />
* Working temperature: 0~70°C<br />
<br />
=='''Software'''==<br />
===Linux===<br />
* Version: 2.6.29<br />
* Compile: arm-linux-gcc-4.3.2<br />
* Support file system<br />
** Yaffs — readable and writable file system, default selection.<br />
** Cramfs — compressed read-only file system, not recommended.<br />
** Ext2 — available when connecting a hard-disk<br />
** Fat32 — be used in mobile storing device.<br />
** NFS — network file system, can be used for debugging applications and drivers<br />
* drivers for source code<br />
** 3 standard serial port drivers.<br />
** Audio driver ( support playing and recording ).<br />
** LCD drivers ( including: resolution 320×240, 240×320 and 640×480 ).<br />
** Touch-screen driver.<br />
** USB camera ( including: OV511 camera and others ).<br />
** USB mouse, USB keyboard, U disk, mobile hard disk and so on.<br />
** Nand Flash, SD card driver, Yaffs driver, Watchdog, DM9000 driver, RTC driver.<br />
* Linux application and service program.<br />
** busybox1.2.0 tool kit ( includes general Linux instructions ).<br />
** Telnet、FTP、inetd ( remote login tools and services ).<br />
** Madplay ( MP3 player in console ).<br />
** rz and sz ( file receiving and sending application via serial port in console ).<br />
** Qt/Embedded <br />
===Manuals===<br />
[http://corewind2440.googlecode.com/files/KIT2440_III_user_manul.pdf KIT2440_III_user_manul]<br><br />
[http://corewind2440.googlecode.com/files/KIT2440_III_Linux_Development_manual.pdf KIT2440_III_Linux_Development_manual]<br><br />
[http://corewind2440.googlecode.com/files/KIT2440_III_WinCE_Development_manual.pdf KIT2440_III_WinCE_Development_manual]<br><br />
[http://corewind2440.googlecode.com/files/WinCE5_0_installation_guidance.pdf WinCE5_0_installation_guidance]<br><br />
<br />
===Development Resoures===<br />
<hr><br />
{|<br />
|[[File:S3c2440kits-revl1-soft.jpg]]<br><br><br />
|<b>[http://code.google.com/p/corewind2440/wiki/StartHere Developers' Resources]</b><br><br>Join and share full development<br> resources of KIT2440-III<br>[http://code.google.com/p/corewind2440/wiki/StartHere Start Here! >>]<br>[http://code.google.com/p/corewind2440/wiki/Linux Linux development >>]<br>[http://code.google.com/p/corewind2440/wiki/Wince WinCE development >>]<br><br><br />
|[[File:S3c2440kits-revl1-line2.jpg]]<br />
|[[File:S3c2440kits-revl1-hard.jpg]]<br><br><br />
|<b>[http://code.google.com/p/corewind2440/wiki/Hardware Hardware Information]</b><br><br>Major component<br>information available<br>[http://code.google.com/p/corewind2440/wiki/Kit2440III Kit2440-III >>]<br> [http://code.google.com/p/corewind2440/wiki/Core2440III Core2440-III >>]<br><br><br><br><br />
|[[File:S3c2440kits-revl1-line2.jpg]]<br />
|[[File:S3c2440kits-revl1-com.jpg]]<br><br><br />
|<b>[http://armdevs.com/products/product_9.html Buy now]</b><br><br>Kit2440-III product<br> Marketplace<br>[http://armdevs.com/products/ Go >>]<br><br><br><br><br />
|}<br />
<hr><br />
[[Category:Development Boards]]</div>Cschallehttps://elinux.org/index.php?title=SMDK2440Info&diff=73885SMDK2440Info2011-10-28T08:39:14Z<p>Cschalle: Add category</p>
<hr />
<div>Here are the instructions which came with the patch to support the SMDK2440 board from<br />
Samsung.<br />
<br />
<br />
<pre><br />
The attached patch implements SMDK2440 board support for CELF kernel<br />
with power management feature enabled.<br />
SMDK2440 board is an evaluation board for Samsung's S3C2440 processor<br />
(ARM920T core).<br />
A part of draft CELF PM spec is implemented in this patch. (System<br />
suspend/resume and dynamic power management framework is implemented.)<br />
<br />
Attached diff_stat_2440 contains diff stats.<br />
For details, please see the attached README.txt.<br />
<br />
Thank you,<br />
Best regards,<br />
Joo-Young Hwang<br />
<br />
=======================================================<br />
Joo-Young Hwang, Ph.D, Senior Engineer,<br />
CE Linux Forum PMWG co-chair<br />
SAMSUNG Electronics Co., Ltd.<br />
=======================================================<br />
</pre><br />
<br />
<br />
<br />
<hr /><br />
Here are the contents of the README file that came with the patch<br />
to support the SMDK240 board.<br />
<br />
<br />
# Contents of this patch<br />
<br />
(1) SMDK2440 board support<br />
- SMDK2440 board is evaluation board for Samsung's S3C2440 processor.<br />
- S3C2440 has ARM920T core and operates at up to 533MHz clock.<br />
- For more details, please visit the following URL.<br />
http://www.samsung.com/Products/Semiconductor/SystemLSI/MobileSolutions/MobileASSP/MobileComputing/S3C2440X/S3C2440X.htm<br />
<br />
(2) Power Management Support<br />
This patch implements a subset of CELF 1.0 Power Management Specification.<br />
- System suspend/resume is supported.<br />
- While system is suspended, memory is set to self refresh mode, processor goes to its power off mode,<br />
and other devices like LCD and audio codec are suspended. All cpu contexts and device contexts are<br />
restored successfully when system is resumed.<br />
- Automatic suspending a device which is inactive for a period is not supported.<br />
- Dynamic Power Management framework is supported.<br />
- [[Monta Vista]]'s Dynamic Power Management framework is successfully working on SMDK2440.<br />
<br />
2. Environment<br />
- target kernel (celinux-040304, "celf2" kernel)<br />
- endian ( little endian)<br />
- compiler ( gcc 2.95.3 and 3.3.2)<br />
- enabled devices: serial, LCD(Frame-buffer device), sound, USB host, MTD-nand flash support, Touch Screen panel, Ethernet, Keyboard(optional)<br />
<br />
3. How to build<br />
<br />
<pre><br />
[celinux-040503]$vi Makefile [enter]<br />
<br />
Environment Variables ; ARCH :=arm , CROSS_COMPILER="your arm-toolchain directory"<br />
<br />
[celinux-040503]$make smdk2440_config [enter]<br />
<br />
*** Default configuration for smdk2440 installed<br />
*** Next, you may run 'make oldconfig'<br />
<br />
[celinux-040503]$make oldconfig [enter]<br />
<br />
......<br />
<br />
*** End of Linux kernel configuration.<br />
*** Check the top-level Makefile for additional configuration<br />
*** Next, you must run 'make dep'.<br />
<br />
[celinux-040503]$make dep [enter]<br />
<br />
[celinux-040503]$make zImage [enter]<br />
</pre><br />
<br />
[[Category:Hardware]]</div>Cschallehttps://elinux.org/index.php?title=TCube_Info&diff=73873TCube Info2011-10-28T08:38:32Z<p>Cschalle: Add category</p>
<hr />
<div>This page describes how to load Linux on the T-Cube board.<br />
<br />
Table Of Contents:<br />
<br />
<br />
<hr /><br />
<br />
== Hardware Used ==<br />
* Board Order Number: SEMC5701(T-Cube)/SHIMAFUJI<br />
** CPU<br />
*** VR5701 (NEC VR5500A SOC chip) (333MHz)<br />
* Memory<br />
** 64 Mbyte SDRAM<br />
** 16 Mbyte Flash<br />
* Graphics controller<br />
** SMI (SM722GX )<br />
* Other Feature<br />
** Timer x 4 ( VR5701 )<br />
** UART x2 ( VR5701 /16550 compatible)<br />
** PCI ( VR5701 ) -- no PCI connector/header on the baord<br />
** Sound AC97 ( VR5701 )<br />
** IDE/Compact Flash ( VR5701 )<br />
** RTC (RV 5C348B)<br />
** Ethernet ( Intel GD82559ERSL3DG )<br />
** USB(USB2) ( NEC uPD720101 )<br />
** CF<br />
<br />
== Software and Configuration Files Used ==<br />
* PMON<br />
** setup<br />
** boot<br />
* Toolchain<br />
** Mips Toolchain from Lineo<br />
* kernel<br />
** celinux-040503.tar.bz2<br />
* root filesystem<br />
** [unprepared]<br />
<br />
== General Outline for Bootstrapping using PMON ==<br />
=== Preparing Target Hardware and Connections ===<br />
** Connections:<br />
*** Host machine Ethernet to hub (I configured as 192.168.1.1)<br />
*** T-Cube Ethernet to hub (I configured as 192.168.1.2)<br />
*** Connect serial cable between T-Cube and host machine<br />
**** Serial1 connector to interface module serial port<br />
**** Other end of null-modem cable to first serial port (ttyS0) on the Linux host machine<br />
<br />
=== Preparing Host Software ===<br />
* Download and place files in /tftpboot<br />
* Make sure tftpd is ready to run<br />
* Confirm minicom is configured to access /dev/ttyS0, at 115K N81<br />
<br />
=== Using PMON to Boot the Kernel ===<br />
* Root filesystem is NFS<br />
<br />
==== Building the Kernel ====<br />
Here are some commands I used to build the kernel:<br />
* cd celinux-040503/<br />
* export PATH=/usr/local/bin:$PATH<br />
* cp arch/mips/defconfig-tcube .config<br />
* make ARCH=mips CROSS_COMPILE=mipsel-linux- menuconfig<br />
** disable XIP<br />
* make ARCH=mips CROSS_COMPILE=mipsel-linux- dep<br />
* make ARCH=mips CROSS_COMPILE=mipsel-linux-<br />
<br />
==== Preparing the Kernel to Download ====<br />
* cp vmlinux /tftpboot/<br />
<br />
==== Starting the NFS daemon ====<br />
* /etc/rc.d/init.d/nfs start<br />
<br />
==== Setting Environment Variable and Write Environment Value on T-Cube ====<br />
* minicom (set to /dev/ttyS0)<br />
* Set environment variable<br />
** Set variable tty0 (I used "set tty0 115200")<br />
** Set variable netaddr (I used "set netaddr 192.168.1.2")<br />
** Set variable bootaddr (I used "set bootaddr 192.168.1.1")<br />
** Set variable bootfile (I used "set bootfile vmlinux")<br />
* Write environment value<br />
** Employed "write_env" command<br />
<br />
==== Downloading the Kernel to T-Cube ====<br />
* minicom (set to /dev/ttyS0)<br />
* Download the kernel<br />
** Employ "boot" command<br />
** As "boot" command completes, "Entry-address" appears.<br />
<br />
==== Booting the Kernel ====<br />
* Employ "go" command (I used "g -e Entry-address")<br />
<br />
[[Category:Development Boards]]</div>Cschallehttps://elinux.org/index.php?title=TUSB2046B&diff=73867TUSB2046B2011-10-28T08:37:48Z<p>Cschalle: Add category</p>
<hr />
<div>TUSB2046B is a RoHS Compliant single chip 4-Port USB Hub from Texas Instruments<br />
<br />
* Fully Compliant With the USB Specificationas a Full-Speed Hub: TID #30220231<br />
* 32-Terminal LQFP Package With a 0.8-mm Terminal Pitch or QFN Package with a 0.5-mm Terminal Pitch(1)<br />
* 3.3-V Low Power ASIC Logic<br />
* Integrated USB Transceivers<br />
* State Machine Implementation Requires No Firmware Programming<br />
* One Upstream Port and Four Downstream Ports<br />
* All Downstream Ports Support Full-Speed and Low-Speed Operations<br />
* Two Power Source Modes<br />
* Self-Powered Mode<br />
* Bus-Powered Mode<br />
* Power Switching and Overcurrent Reporting Is Provided Ganged or Per Port<br />
* Supports Suspend and Resume Operations<br />
* Supports Programmable Vendor ID and Product ID With External Serial EEPROM<br />
* 3-State EEPROM Interface Allows EEPROM Sharing<br />
* Push-Pull Outputs for PWRON Eliminate the Need for External Pullup Resistors<br />
* Noise Filtering on OVRCUR Provides Immunity to Voltage Spikes<br />
* Package Pinout Allows 2-Layer PCB<br />
* Low EMI Emission Achieved by a 6-MHz Crystal Input<br />
* Migrated From Proven TUSB2040 Hub<br />
* Lower Cost Than the TUSB2040 Hub<br />
* Enhanced System ESD Performance<br />
* Supports 6-MHz Operation Through a Crystal Input or a 48-MHz Input Clock<br />
<br />
<br />
[http://focus.ti.com/docs/prod/folders/print/tusb2046b.html TUSB2046B Product Page]<br />
<br />
[http://www.mouser.com/search/ProductDetail.aspx?R=TUSB2046BVFvirtualkey59500000virtualkey595-TUSB2046BVF Mouser Part Lookup]<br />
<br />
[http://www.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=296-11088-ND Digikey Part Lookup]<br />
<br />
[http://www.jameco.com/webapp/wcs/stores/servlet/ProductDisplay?langId=-1&storeId=10001&catalogId=10001&productId=764078 Jameco Part Lookup]<br />
<br />
[http://www.instructables.com/id/EEXHOBCAOEEUR4U24X/ Custom Hub Project using a TUSB2046]<br />
<br />
[[Category:Hardware]]</div>Cschallehttps://elinux.org/index.php?title=LF-1000&diff=73861LF-10002011-10-28T08:36:36Z<p>Cschalle: Add category</p>
<hr />
<div>[[File:lf-1000 cpu.jpg|right]]<br />
= Summary =<br />
OEM branded version of the MagicEyes [[Pollux]] VF3520F [[media:pollux-datasheet.pdf|Datasheet]]<br />
<br><br />
<br />
== Core ==<br />
*ARM926EJ-S- 393MHz<br />
**16KByte I-Cache<br />
**16KByte D-Cache<br />
**High performance 32bit CPU Core<br />
**Jazelle Java Hardware Accelerator<br />
*90 nm Process<br />
*288pin FBGA<br />
*15mm x 15mm<br />
*0.65mm pitch<br />
<br />
== Memory ==<br />
*DDR SDRAM Controller<br />
*133MHz DDR SDRAM memory x 16bit<br />
*Single DDR memory bank<br />
*Up to 128MB<br />
*Peak Memory Bandwidth : 533MByte/sec<br />
*8 Channel DMA<br />
<br />
== Storage ==<br />
*Static Bus controller<br />
*16 bit data bus<br />
*SLC/ MLC NAND Support<br />
*8 bit NAND flash<br />
*8/16 bit SRAM Support<br />
*Boot form NAND flash NOR flash<br />
*IDE interface with PIO mode<br />
*SD/ MMC interface<br />
**Two Channels of SD/MMC<br />
**SD mem Version 2.00<br />
**SDIO version 1.10<br />
**MMC version 4.2<br />
**clock speed up to 52MHz<br />
**PIO and DMA mode data transfer<br />
<br />
==3D Graphic Accelerator ==<br />
3D Performance : 133M Texel/sec, 1.33M Polygon/sec<br><br />
OpenGL ES 1.1 Compatible<br><br />
512-depth instruction memory<br><br />
256 Vector Input/Constant Registers<br><br />
16 Vector General Purpose Registers<br><br />
2x2 Sub-Pixel Accuracy<br><br />
Per-Pixel Fogging<br><br />
Hardware Dithering<br><br />
Texture Features<br />
*Perspective Correction<br />
*Multi-Texturing<br />
*Bi-Linear Filtering<br />
*MIPMAP<br />
<br />
== Display Subsystem ==<br />
Onboard TFT controller<br><br />
* Support for screens with a size up to 1280 * 1024@60Hz<br />
* Supports Flat Panel I/F: Color TFT at 16, 18, 24 bit//Pixel, STN-LCD<br />
** Display Layers<br />
*** RGB Layer : 2 Layer, 8/16/24bpp Format<br />
*** YUV Layer : YUV4:2:0, 2D/Linear Format, Scale Up/Down<br />
** Effects : Color Key, Priority, Alpha Blending(16 Levels)<br />
** Color Control : Brightness, Contrast, Hue, Saturation<br />
** Output Format<br />
*** CCIR 601/656, RGB, M-RGB(Multiplexed RGB)<br />
*** Supports NTSC/PAL Encoder with Analog DAC<br />
*** CVBS Output<br />
*** Independent Dual Display Output<br />
<br />
== Integrated peripherals ==<br />
=== USB ===<br />
USB Host 1.1<br />
*3 downstream ports <br />
<br />
USB 2.0 Device<br />
*Support FS/HS dual mode operation <br />
<br />
=== I2C interface ===<br />
2 channel I2C-bus<br />
100Kbps ~ 1Mbps Speed<br />
<br />
=== Other ===<br />
4Ch UART, <br />
SSP/ SPI interface<br />
ADC<br />
PWM<br />
JTAG<br />
<br />
== Power Management == <br />
*Individual block dynamic power controlller <br />
* Supports various power down mode<br />
** Idle<br />
** Stop<br />
== Operating Temperature ==<br />
* 0℃ ~ 70℃<br />
<br />
== Operating Systems ==<br />
* Microsoft Windows CE 5.0/6.0<br />
* Linux<br />
<br />
[[Category:Hardware]]</div>Cschallehttps://elinux.org/index.php?title=Mobile_Pro&diff=73849Mobile Pro2011-10-28T08:35:20Z<p>Cschalle: Add category</p>
<hr />
<div>This is the site for the NEC [[Mobile Pro]] 770/780/790 set of Handheld PCs. These handhelds are rather neat, and can make a powerful target for a strong linux system. Among the overall specs of these things we have:<br />
<br />
* VR4121 168mhz 32/64 bit processor (PD30121) - you can access some info about it here: http://www.linuxdevices.com/products/PD3171456766.html<br />
* 32mb of RAM memory<br />
* 24mb of ROM memory<br />
* 16mb of Flash (only on the 790 model)<br />
* A PC card bridge serving one PCMCIA slot and one [[Compact Flash]] slot<br />
* Near full size keyboard<br />
* 640x240 64k color DSTN LCD screen with touch panel<br />
* 56k modem<br />
* [[IrDA]]<br />
* NEC proprietary serial plug, requires NEC cable or just wire a cable yourself and solder it onto the pins<br />
* VGA out<br />
Components inside it listed and checked so far (this list was made while fixing a problem with the PCMCIA socket, so it will be updated later with more accurate information) - refer to the board picture for more info, I will try to get a scan of it later.<br />
<br />
* NEC VR4121A D30121F1 (PD30121) Processor<br />
* RICOH RFC5C396L PC Card controller<br />
* CONEXANT RP56LD (Modem controller)<br />
* [[Media Q]] MQ200 LCD Controller<br />
* 2x HYUNDAI GM72V661641CLT7J 64mbit chips onboard<br />
* 2x HYUNDAI GM72V661641CLT7J 64mbit chips on a plugable board (memory upgrade anyone?)<br />
* 2x NEC 023C128040L (???) -> Supposedly the ROM chips, but I can't find any information. I haven't really looked for it yet either.<br />
Here we got a pic of the thing: <br />
[http://i7.photobucket.com/albums/y283/ricmm104/mp-open.jpg mp-open.jpg]<br />
<br />
The front - CF slot in the middle, headphones jack and microphone at the right:<br />
[http://i7.photobucket.com/albums/y283/ricmm104/mp-front.jpg mp-front.jpg]<br />
<br />
PCMCIA Socket on the right side:<br />
[http://i7.photobucket.com/albums/y283/ricmm104/mp-pcmcia.jpg mp-pcmcia.jpg]<br />
<br />
Back of the device (battery):<br />
[http://i7.photobucket.com/albums/y283/ricmm104/mp-back.jpg mp-back.jpg]<br />
<br />
Bottom of the device, you can see the RAM/ROM plugable boards compartment's cover:<br />
[http://i7.photobucket.com/albums/y283/ricmm104/mp-bottom.jpg mp-bottom.jpg]<br />
<br />
And the board picture mentioned before:<br />
[http://i7.photobucket.com/albums/y283/ricmm104/mp-board.jpg mp-board.jpg]<br />
<br />
I'm currently working using the linux-mips.org [[VR41xx]] code with a few modifications and code obtained from Linux on MCR700 project. Development is going on continuously on this device, the page will be updated when deemed necessary.<br />
<br />
Contact me for more info on: mendoza dot ricardo at gmail dot com<br />
<br />
I would be interested in helping out on this project - how do i contact you? - Paul<br />
<br />
[[Category:Hardware]]</div>Cschallehttps://elinux.org/index.php?title=Flash_Filesystem_Benchmarks_Protocol&diff=73843Flash Filesystem Benchmarks Protocol2011-10-28T08:34:38Z<p>Cschalle: Add category</p>
<hr />
<div>This page refers to the benchmarks presented at [[Flash Filesystem Benchmarks]]<br />
<br />
== Tested filesystems ==<br />
<br />
The test bench covers the following filesystems :<br />
* '''JFFS2''' filesystem. All tests are performed with this filesystem.<br />
* '''UBIFS''' filesystem. All tests are performed with this filesystem.<br />
* '''SquashFS over ''ubiblk'''''. ''ubiblk'' is a UBI to block translation module that Free Electrons has developed, it makes it possible to mount a SquashFS filesystem inside an UBI volume. In this case, none of the tests involving write or removal are performed, since SquashFS is a read-only filesystem. Those results are labeled <code>squashfs-ubiblk</code> in our graphs.<br />
* '''SquashFS over ''mtdblock_ro'' over ''gluebi''''', which makes it possible to mount a SquashFS filesystem inside an UBI volume. Contrary to ''ubiblk'', this solution is completely in the mainline Linux kernel. In this case, none of the tests involving write or removal are performed, since SquashFS is a read-only filesystem. Those results are labeled <code>squashfs-gluebi</code> in our graphs.<br />
* '''YAFFS2 filesystem'''. All tests are performed with this filesystem. However, unfortunately, YAFFS2 doesn't build for recent (2.6.39, 3.0) kernel versions, so we were unable to update our test results for YAFFS2.<br />
* '''Raw'''. This is not a filesystem, but only raw read performances on the flash measured by ''nanddump''ing the flash.<br />
<br />
All filesystem supports are built as module, including the UBI support. The ''logfs'' filesystem is not tested as it is way too unstable.<br />
<br />
== Tests performed ==<br />
<br />
Multiple tests are performed on each filesystem / size couple, and those tests give the following list of values as result:<br />
<br />
* <code>init_time</code> and <code>init_cpu_time</code> --> [[#Init test|module initialisation time]]<br />
* <code>init_mem</code> --> [[#Init test|module initialisation memory usage]] (x)<br />
* <code>mount_time</code> and <code>mount_cpu_time</code> --> [[#Mount test|mount time]]<br />
* <code>mount_mem</code> --> [[#Mount test|memory usage for mounting the filesystem]] (x)<br />
* <code>remount_time</code> --> [[#Mount test|hot remount time]]<br />
* <code>used_space</code> --> [[#Mount test|space used by the filesystem after mounting]]<br />
* <code>read_time</code> and <code>read_cpu_time</code> --> [[#Read timing test|read timing test]] <br />
* <code>remove_time</code> and <code>remove_cpu_time</code> --> [[#Erase test|erase test]]<br />
* <code>write_time</code> and <code>write_cpu_time</code> --> [[#Write test|write test]]<br />
* <code>video_write_time</code> and <code>video_write_cpu_time</code> --> [[#Big file write test|big - uncompressible - file write test]]<br />
<br />
Items marked with an (x) don't seem to be reliable yet.<br />
<br />
The tests are run in the order as shown above. One filesystem/size couple (e.g. jffs2/128MB) is tested, then the board is reset and the next filesystem/size couple is tested.<br />
<br />
Notes :<br />
* The time measurements are done with the <code>time</code> util (not the shell builtin) is used to launch the command to be timed. When a cache can speed the measured criterium up (e.g. read or remove), a <code>sync</code> is included in the command being timed. The CPU time as well as the wall-clock time are measured. So for example, <code>mount_time</code> in our graphs is the wall-clock time needed to perform the mount test, while <code>mount_cpu_time</code> in our graphs is the CPU time needed to perform the mount test.<br />
* The memory measurements are done using the content of /proc/meminfo right before and after the measured command. The sum of "MemFree", "Buffers" and "Cached" is considered to be free memory. The memory usage is then the difference before/after. The results tend to show that this approach isn't reliable with regard to absolute memory consumption: results for one filesystem with different sizes do not always follow a law. Results are sometimes negative (memory usage<0).<br />
However, when comparing results (as opposed to "absolute results") of the different filesystems, some constantly have a low footprint whereas other have a large one. When the memory usage doesn't scale, it is also obvious.<br />
<br />
===Init test===<br />
The init test consists of modprobing the filesystem driver.<br />
<br />
In the case of a filesystem on top of UBI, it also consists of modprobing ubi and attaching a<br />
device.<br />
<br />
Both time and memory consumption (with inconsitencies explained above) are<br />
measured.<br />
<br />
===Mount test===<br />
This test simply consists of mounting a partition. (In the case of ubifs,<br />
attaching occured in the previous test)<br />
<br />
Both time and memory are measured.<br />
<br />
After the mount, a remount (<code>mount -o remount</code>) timing test is also<br />
performed when applicable (ie. not for read-only filesystems).<br />
<br />
The used space on flash is also measured, using <code>df</code>.<br />
<br />
===Read timing test===<br />
A tar archive of the test filesystem's content is created and written to<br />
/dev/zero (Note: tar detects writes to /dev/null and discards them). A sync is performed afterward.<br />
<br />
This test filesystem contains what would a root filesystem contain.<br />
<br />
As reference time, a "raw" read operation is also performed: It consists of<br />
a <code>nanddump</code> of the same amount of flash as the uncompressed size of the<br />
filesystem. Compressed filesystems may have a better result than this<br />
reference time.<br />
<br />
===Erase test===<br />
The whole content of the filesystem is <code>rm -rf</code>-ed ; a sync is then<br />
performed. All of this is timed.<br />
<br />
===Write test===<br />
The content of a folder - previously mounted in a tmpfs - is copied into the<br />
flash partition. When this partition is large, it is done several times<br />
until the partition is almost full: (size / 8) times<br />
<br />
===Big file write test===<br />
This test is almost the same as the previous one but only one video is<br />
written (possibly several times, as before).<br />
<br />
==Communication with the device==<br />
A serial connection with the device is assumed. The bench script waits until<br />
a prompt (U-Boot or shell) is displayed and sends a batch of commands to be<br />
executed. It waits for the next prompt, parses the result and stores it in a<br />
SQL database when needed, and sends the next commands.<br />
<br />
Multiline shell commands aren't passed through the serial line but are<br />
stored in shell files and these files are executed. However, we do so for<br />
all filesystems and all sizes homogeneously, so the overhead is consistent.<br />
<br />
==Kernel and RootFS==<br />
The kernel is loaded in ram from an external storage (MMC, tftp etc.) to<br />
ensure maximal free space on the flash. On most cards, it may be possible to<br />
use the whole flash by putting the first stage bootloader and uboot on an<br />
MMC card. However, we didn't need to for the tests on IGEPv2.<br />
<br />
The RootFS is also put on an external storage (here, NFS). However, for<br />
read/write operation, the output/input is stored/loaded to/from<br />
devzero/ramfs to avoid hihgly random latency.<br />
<br />
==Issues==<br />
<br />
<br />
===Memory usage measurement===<br />
The measured init memory footprint is sometimes negative. It also does not<br />
always follow any law with regard to scaling.<br />
<br />
The results are however mostly consistent and make it possible to compare<br />
the considered filesystems.<br />
<br />
===Block filesystems and bad blocks===<br />
When a block filesystem encounters a bad block, it has now way of dealing<br />
with them. So, when the filesystem becomes large, it inevitably fails to<br />
flash.<br />
<br />
The results for these tests are then unreliable and must be manually<br />
deleted.<br />
<br />
===Free space shortage===<br />
When the filesystem size is near from the flash size, some filesystem fail<br />
to write any more data. That kind of problems occured when writing video:<br />
That kind of data can't be compressed.<br />
<br />
They also took a long time to fail and sometime also made the system lack of<br />
free memory. It hasn't be verified yet, but one hypothesis might be that the<br />
wear-leveling and garbage-collecting processes fail to efficiently operate<br />
under such load and need too much memory.<br />
<br />
===Non-significant time measurment===<br />
For unforseeable reasons, the time taken by an operation can be much larger<br />
than expected and/or than on another batch of tests.<br />
<br />
Running several occurencies of the tests, remove the highest and lowest<br />
values and computing the average could be a solution.<br />
<br />
That solution has been implemented but its implementation isn't perfect: it should first remove the best and worts results and that would need a lot of runs.<br />
<br />
===UBI not scaling as expected===<br />
UBI init time is supposed to scale linearly with the size of the device. But<br />
since the tests always use the same mtd partition and thus, the same UBI<br />
device size (no matter what the volume size may be), the init time won't<br />
reflect the size of the filesystem. A fix could be to define a different<br />
partition at each boot. The size of the test partition can be precised at<br />
each reboot but if this size is defined to be that of the filesystem,<br />
because of UBI overhead, ubifs will lack of space.<br />
<br />
[[Category:Flash Filesystem Benchmarks]]</div>Cschallehttps://elinux.org/index.php?title=Flash_Filesystem_Benchmarks_Kernel_Evolution&diff=73831Flash Filesystem Benchmarks Kernel Evolution2011-10-28T08:34:12Z<p>Cschalle: Ad</p>
<hr />
<div>This page is part of the [[Flash_Filesystem_Benchmarks]] effort done by Free Electrons with funding from the CE Linux Forum.<br />
<br />
This page makes it possible to monitor performance regressions in newer kernel versions. Each board/filesystem couple should be watched. More results will come shortly.<br />
<br />
== IGEPv2 Board / UBIfs ==<br />
[[File:Elinux-igepv2-ubifs-comparison-init_time.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-init_cpu_time.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-init_mem.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-mount_time.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-mount_cpu_time.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-mount_mem.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-remount_time.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-remount_cpu_time.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-used_space.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-read_time.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-read_cpu_time.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-remove_time.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-remove_cpu_time.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-write_time.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-write_cpu_time.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-video_write_time.png]]<br />
[[File:Elinux-igepv2-ubifs-comparison-video_write_cpu_time.png]]<br />
<br />
== IGEPv2 Board / JFFS2 ==<br />
[[File:Elinux-igepv2-jffs2-comparison-init_time.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-init_cpu_time.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-init_mem.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-mount_time.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-mount_cpu_time.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-mount_mem.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-remount_time.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-remount_cpu_time.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-used_space.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-read_time.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-read_cpu_time.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-remove_time.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-remove_cpu_time.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-write_time.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-write_cpu_time.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-video_write_time.png]]<br />
[[File:Elinux-igepv2-jffs2-comparison-video_write_cpu_time.png]]<br />
<br />
== IGEPv2 Board / SquashFS over gluebi+mtdblock_ro ==<br />
[[File:Elinux-igepv2-sqfs-gluebi-comparison-init_time.png]]<br />
[[File:Elinux-igepv2-sqfs-gluebi-comparison-init_cpu_time.png]]<br />
[[File:Elinux-igepv2-sqfs-gluebi-comparison-init_mem.png]]<br />
[[File:Elinux-igepv2-sqfs-gluebi-comparison-mount_time.png]]<br />
[[File:Elinux-igepv2-sqfs-gluebi-comparison-mount_cpu_time.png]]<br />
[[File:Elinux-igepv2-sqfs-gluebi-comparison-mount_mem.png]]<br />
[[File:Elinux-igepv2-sqfs-gluebi-comparison-used_space.png]]<br />
[[File:Elinux-igepv2-sqfs-gluebi-comparison-read_time.png]]<br />
[[File:Elinux-igepv2-sqfs-gluebi-comparison-read_cpu_time.png]]<br />
<br />
== IGEPv2 Board / SquashFS over ubiblk ==<br />
[[File:Elinux-igepv2-sqfs-ubiblk-comparison-init_time.png]]<br />
[[File:Elinux-igepv2-sqfs-ubiblk-comparison-init_cpu_time.png]]<br />
[[File:Elinux-igepv2-sqfs-ubiblk-comparison-init_mem.png]]<br />
[[File:Elinux-igepv2-sqfs-ubiblk-comparison-mount_time.png]]<br />
[[File:Elinux-igepv2-sqfs-ubiblk-comparison-mount_cpu_time.png]]<br />
[[File:Elinux-igepv2-sqfs-ubiblk-comparison-mount_mem.png]]<br />
[[File:Elinux-igepv2-sqfs-ubiblk-comparison-read_time.png]]<br />
[[File:Elinux-igepv2-sqfs-ubiblk-comparison-read_cpu_time.png]]<br />
<br />
<br />
----<br />
<br />
----<br />
<br />
<br />
== Calao-USB9263 Board / UBIfs ==<br />
[[File:Elinux-calao-ubifs-comparison-init_time.png]]<br />
[[File:Elinux-calao-ubifs-comparison-init_cpu_time.png]]<br />
[[File:Elinux-calao-ubifs-comparison-init_mem.png]]<br />
[[File:Elinux-calao-ubifs-comparison-mount_time.png]]<br />
[[File:Elinux-calao-ubifs-comparison-mount_cpu_time.png]]<br />
[[File:Elinux-calao-ubifs-comparison-mount_mem.png]]<br />
[[File:Elinux-calao-ubifs-comparison-remount_time.png]]<br />
[[File:Elinux-calao-ubifs-comparison-remount_cpu_time.png]]<br />
[[File:Elinux-calao-ubifs-comparison-used_space.png]]<br />
[[File:Elinux-calao-ubifs-comparison-read_time.png]]<br />
[[File:Elinux-calao-ubifs-comparison-read_cpu_time.png]]<br />
[[File:Elinux-calao-ubifs-comparison-remove_time.png]]<br />
[[File:Elinux-calao-ubifs-comparison-remove_cpu_time.png]]<br />
[[File:Elinux-calao-ubifs-comparison-write_time.png]]<br />
[[File:Elinux-calao-ubifs-comparison-write_cpu_time.png]]<br />
[[File:Elinux-calao-ubifs-comparison-video_write_time.png]]<br />
[[File:Elinux-calao-ubifs-comparison-video_write_cpu_time.png]]<br />
<br />
== Calao-USB9263 Board / JFFS2 ==<br />
[[File:Elinux-calao-jffs2-comparison-init_time.png]]<br />
[[File:Elinux-calao-jffs2-comparison-init_cpu_time.png]]<br />
[[File:Elinux-calao-jffs2-comparison-init_mem.png]]<br />
[[File:Elinux-calao-jffs2-comparison-mount_time.png]]<br />
[[File:Elinux-calao-jffs2-comparison-mount_cpu_time.png]]<br />
[[File:Elinux-calao-jffs2-comparison-mount_mem.png]]<br />
[[File:Elinux-calao-jffs2-comparison-remount_time.png]]<br />
[[File:Elinux-calao-jffs2-comparison-remount_cpu_time.png]]<br />
[[File:Elinux-calao-jffs2-comparison-used_space.png]]<br />
[[File:Elinux-calao-jffs2-comparison-read_time.png]]<br />
[[File:Elinux-calao-jffs2-comparison-read_cpu_time.png]]<br />
[[File:Elinux-calao-jffs2-comparison-remove_time.png]]<br />
[[File:Elinux-calao-jffs2-comparison-remove_cpu_time.png]]<br />
[[File:Elinux-calao-jffs2-comparison-write_time.png]]<br />
[[File:Elinux-calao-jffs2-comparison-write_cpu_time.png]]<br />
[[File:Elinux-calao-jffs2-comparison-video_write_time.png]]<br />
[[File:Elinux-calao-jffs2-comparison-video_write_cpu_time.png]]<br />
<br />
== Calao-USB9263 Board / SquashFS over gluebi+mtdblock_ro ==<br />
[[File:Elinux-calao-sqfs-gluebi-comparison-init_time.png]]<br />
[[File:Elinux-calao-sqfs-gluebi-comparison-init_cpu_time.png]]<br />
[[File:Elinux-calao-sqfs-gluebi-comparison-init_mem.png]]<br />
[[File:Elinux-calao-sqfs-gluebi-comparison-mount_time.png]]<br />
[[File:Elinux-calao-sqfs-gluebi-comparison-mount_cpu_time.png]]<br />
[[File:Elinux-calao-sqfs-gluebi-comparison-mount_mem.png]]<br />
[[File:Elinux-calao-sqfs-gluebi-comparison-used_space.png]]<br />
[[File:Elinux-calao-sqfs-gluebi-comparison-read_time.png]]<br />
[[File:Elinux-calao-sqfs-gluebi-comparison-read_cpu_time.png]]<br />
<br />
== Calao-USB9263 Board / SquashFS over ubiblk ==<br />
[[File:Elinux-calao-sqfs-ubiblk-comparison-init_time.png]]<br />
[[File:Elinux-calao-sqfs-ubiblk-comparison-init_cpu_time.png]]<br />
[[File:Elinux-calao-sqfs-ubiblk-comparison-init_mem.png]]<br />
[[File:Elinux-calao-sqfs-ubiblk-comparison-mount_time.png]]<br />
[[File:Elinux-calao-sqfs-ubiblk-comparison-mount_cpu_time.png]]<br />
[[File:Elinux-calao-sqfs-ubiblk-comparison-mount_mem.png]]<br />
[[File:Elinux-calao-sqfs-ubiblk-comparison-read_time.png]]<br />
[[File:Elinux-calao-sqfs-ubiblk-comparison-read_cpu_time.png]]<br />
<br />
[[Category:Flash Filesystem Benchmarks]]</div>Cschallehttps://elinux.org/index.php?title=Flash_Filesystem_Benchmarks_3.0&diff=73825Flash Filesystem Benchmarks 3.02011-10-28T08:33:43Z<p>Cschalle: Add category</p>
<hr />
<div>This page is part of the [[Flash_Filesystem_Benchmarks]] effort done by Free Electrons with funding from the CE Linux Forum. This page presents the results of our tests with a 3.0 vanilla Linux kernel.<br />
<br />
'''Note:''' yaffs2 isn't included because it doesn't build against 3.0 (since the removal <code>include/linux/smp_lock.h</code>, actually)<br />
<br />
==Board IGEPv2==<br />
[[File:Elinux-igepv2-3.0-init_time.png]]<br />
[[File:Elinux-igepv2-3.0-init_cpu_time.png]]<br />
[[File:Elinux-igepv2-3.0-init_mem.png]]<br />
[[File:Elinux-igepv2-3.0-mount_time.png]]<br />
[[File:Elinux-igepv2-3.0-mount_cpu_time.png]]<br />
[[File:Elinux-igepv2-3.0-mount_mem.png]]<br />
[[File:Elinux-igepv2-3.0-remount_time.png]]<br />
[[File:Elinux-igepv2-3.0-remount_cpu_time.png]]<br />
[[File:Elinux-igepv2-3.0-used_space.png]]<br />
[[File:Elinux-igepv2-3.0-read_time.png]]<br />
[[File:Elinux-igepv2-3.0-read_cpu_time.png]]<br />
[[File:Elinux-igepv2-3.0-remove_time.png]]<br />
[[File:Elinux-igepv2-3.0-remove_cpu_time.png]]<br />
[[File:Elinux-igepv2-3.0-write_time.png]]<br />
[[File:Elinux-igepv2-3.0-write_cpu_time.png]]<br />
[[File:Elinux-igepv2-3.0-video_write_time.png]]<br />
[[File:Elinux-igepv2-3.0-video_write_cpu_time.png]]<br />
<br />
==Board Calao-USB9263==<br />
[[File:Elinux-calao-3.0-init_time.png]]<br />
[[File:Elinux-calao-3.0-init_cpu_time.png]]<br />
[[File:Elinux-calao-3.0-init_mem.png]]<br />
[[File:Elinux-calao-3.0-mount_time.png]]<br />
[[File:Elinux-calao-3.0-mount_cpu_time.png]]<br />
[[File:Elinux-calao-3.0-mount_mem.png]]<br />
[[File:Elinux-calao-3.0-remount_time.png]]<br />
[[File:Elinux-calao-3.0-remount_cpu_time.png]]<br />
[[File:Elinux-calao-3.0-used_space.png]]<br />
[[File:Elinux-calao-3.0-read_time.png]]<br />
[[File:Elinux-calao-3.0-read_cpu_time.png]]<br />
[[File:Elinux-calao-3.0-remove_time.png]]<br />
[[File:Elinux-calao-3.0-remove_cpu_time.png]]<br />
[[File:Elinux-calao-3.0-write_time.png]]<br />
[[File:Elinux-calao-3.0-write_cpu_time.png]]<br />
[[File:Elinux-calao-3.0-video_write_time.png]]<br />
[[File:Elinux-calao-3.0-video_write_cpu_time.png]]<br />
<br />
[[Category:Flash Filesystem Benchmarks]]</div>Cschallehttps://elinux.org/index.php?title=Flash_Filesystem_Benchmarks_2.6.38&diff=73819Flash Filesystem Benchmarks 2.6.382011-10-28T08:33:21Z<p>Cschalle: Add category</p>
<hr />
<div>This page is part of the [[Flash_Filesystem_Benchmarks]] effort done by Free Electrons with funding from the CE Linux Forum. This page presents the results of our tests with a 2.6.38 vanilla Linux kernel.<br />
<br />
<br />
==Board IGEPv2==<br />
[[File:Elinux-igepv2-38-init_time.png]]<br />
[[File:Elinux-igepv2-38-init_cpu_time.png]]<br />
[[File:Elinux-igepv2-38-init_mem.png]]<br />
[[File:Elinux-igepv2-38-mount_time.png]]<br />
[[File:Elinux-igepv2-38-mount_cpu_time.png]]<br />
[[File:Elinux-igepv2-38-mount_mem.png]]<br />
[[File:Elinux-igepv2-38-remount_time.png]]<br />
[[File:Elinux-igepv2-38-remount_cpu_time.png]]<br />
[[File:Elinux-igepv2-38-used_space.png]]<br />
[[File:Elinux-igepv2-38-read_time.png]]<br />
[[File:Elinux-igepv2-38-read_cpu_time.png]]<br />
[[File:Elinux-igepv2-38-remove_time.png]]<br />
[[File:Elinux-igepv2-38-remove_cpu_time.png]]<br />
[[File:Elinux-igepv2-38-write_time.png]]<br />
[[File:Elinux-igepv2-38-write_cpu_time.png]]<br />
[[File:Elinux-igepv2-38-video_write_time.png]]<br />
[[File:Elinux-igepv2-38-video_write_cpu_time.png]]<br />
<br />
==Board Calao USB-9263==<br />
[[File:Elinux-calao-38-init_time.png]]<br />
[[File:Elinux-calao-38-init_cpu_time.png]]<br />
[[File:Elinux-calao-38-init_mem.png]]<br />
[[File:Elinux-calao-38-mount_time.png]]<br />
[[File:Elinux-calao-38-mount_cpu_time.png]]<br />
[[File:Elinux-calao-38-mount_mem.png]]<br />
[[File:Elinux-calao-38-remount_time.png]]<br />
[[File:Elinux-calao-38-remount_cpu_time.png]]<br />
[[File:Elinux-calao-38-used_space.png]]<br />
[[File:Elinux-calao-38-read_time.png]]<br />
[[File:Elinux-calao-38-read_cpu_time.png]]<br />
[[File:Elinux-calao-38-remove_time.png]]<br />
[[File:Elinux-calao-38-remove_cpu_time.png]]<br />
[[File:Elinux-calao-38-write_time.png]]<br />
[[File:Elinux-calao-38-write_cpu_time.png]]<br />
[[File:Elinux-calao-38-video_write_time.png]]<br />
[[File:Elinux-calao-38-video_write_cpu_time.png]]<br />
<br />
[[Category:Flash Filesystem Benchmarks]]</div>Cschallehttps://elinux.org/index.php?title=Flash_Filesystem_Benchmarks_2.6.39&diff=73807Flash Filesystem Benchmarks 2.6.392011-10-28T08:33:01Z<p>Cschalle: Add category</p>
<hr />
<div>This page is part of the [[Flash_Filesystem_Benchmarks]] effort done by Free Electrons with funding from the CE Linux Forum. This page presents the results of our tests with a 2.6.39 vanilla Linux kernel.<br />
<br />
'''Note:''' yaffs2 isn't included because it doesn't build against 2.6.39 (since the removal <code>include/linux/smp_lock.h</code>, actually)<br />
<br />
==Board IGEPv2==<br />
[[File:Elinux-igepv2-39-init_time.png]]<br />
[[File:Elinux-igepv2-39-init_cpu_time.png]]<br />
[[File:Elinux-igepv2-39-init_mem.png]]<br />
[[File:Elinux-igepv2-39-mount_time.png]]<br />
[[File:Elinux-igepv2-39-mount_cpu_time.png]]<br />
[[File:Elinux-igepv2-39-mount_mem.png]]<br />
[[File:Elinux-igepv2-39-remount_time.png]]<br />
[[File:Elinux-igepv2-39-remount_cpu_time.png]]<br />
[[File:Elinux-igepv2-39-used_space.png]]<br />
[[File:Elinux-igepv2-39-read_time.png]]<br />
[[File:Elinux-igepv2-39-read_cpu_time.png]]<br />
[[File:Elinux-igepv2-39-remove_time.png]]<br />
[[File:Elinux-igepv2-39-remove_cpu_time.png]]<br />
[[File:Elinux-igepv2-39-write_time.png]]<br />
[[File:Elinux-igepv2-39-write_cpu_time.png]]<br />
[[File:Elinux-igepv2-39-video_write_time.png]]<br />
[[File:Elinux-igepv2-39-video_write_cpu_time.png]]<br />
<br />
==Board Calao USB-9263==<br />
[[File:Elinux-calao-39-init_time.png]]<br />
[[File:Elinux-calao-39-init_cpu_time.png]]<br />
[[File:Elinux-calao-39-init_mem.png]]<br />
[[File:Elinux-calao-39-mount_time.png]]<br />
[[File:Elinux-calao-39-mount_cpu_time.png]]<br />
[[File:Elinux-calao-39-mount_mem.png]]<br />
[[File:Elinux-calao-39-remount_time.png]]<br />
[[File:Elinux-calao-39-remount_cpu_time.png]]<br />
[[File:Elinux-calao-39-used_space.png]]<br />
[[File:Elinux-calao-39-read_time.png]]<br />
[[File:Elinux-calao-39-read_cpu_time.png]]<br />
[[File:Elinux-calao-39-remove_time.png]]<br />
[[File:Elinux-calao-39-remove_cpu_time.png]]<br />
[[File:Elinux-calao-39-write_time.png]]<br />
[[File:Elinux-calao-39-write_cpu_time.png]]<br />
[[File:Elinux-calao-39-video_write_time.png]]<br />
[[File:Elinux-calao-39-video_write_cpu_time.png]]<br />
<br />
[[Category:Flash Filesystem Benchmarks]]</div>Cschallehttps://elinux.org/index.php?title=Flash_Filesystem_Benchmarks_2.6.36&diff=73801Flash Filesystem Benchmarks 2.6.362011-10-28T08:32:36Z<p>Cschalle: Add category</p>
<hr />
<div>This page is part of the [[Flash_Filesystem_Benchmarks]] effort done by Free Electrons with funding from the CE Linux Forum.<br />
<br />
* The results below are old, and our test scripts have been improved, so we recommend looking at our results for newer kernel versions instead<br />
* These results were obtained on a [http://www.calao-systems.com/articles.php?lng=en&pg=5932 CALAO Systems USB-A9263-C02] board.<br />
* See our [http://elinux.org/images/d/d7/Elce2010-flash-filesystems.pdf ELCE 2010 presentation] for complete details and graphical representations of those results.<br />
<br />
Test: init_time (s)<br />
size ubifs jffs2 yaffs2<br />
8 0.34 0.12 0.07<br />
32 0.78 0.39 0.25<br />
128 1 0.41 0.26<br />
252 1.17 0.42 0.26<br />
<br />
Test: init_mem (KB)<br />
size ubifs jffs2 yaffs2<br />
8 888 444 96<br />
32 916 464 96<br />
128 956 576 88<br />
252 988 436 80<br />
<br />
Test: mount_time (s)<br />
size ubifs jffs2 yaffs2<br />
8 0.14 0.11 0.03<br />
32 0.36 0.48 0.34<br />
128 0.43 1.38 0.51<br />
252 0.33 2.08 0.96<br />
<br />
Test: mount_mem (KB)<br />
size ubifs jffs2 yaffs2<br />
8 544 184 8<br />
32 532 316 20<br />
128 548 712 664<br />
252 540 1540 2336<br />
<br />
Test: init_time + mount_time (s)<br />
size ubifs jffs2 yaffs2<br />
8 0.48 0.23 0.1<br />
32 1.14 0.87 0.59<br />
128 1.43 1.79 0.77<br />
252 1.5 2.5 1.22<br />
<br />
Test: init_mem + mount_mem (MB)<br />
size ubifs jffs2 yaffs2<br />
8 1432 628 104<br />
32 1448 780 116<br />
128 1504 1288 752<br />
252 1528 1976 2416<br />
<br />
Test: used_space (KB)<br />
size ubifs jffs2 yaffs2<br />
8 4520 4196 8000<br />
32 16164 13940 30204<br />
128 64748 54028 117428<br />
252 127192 109880 233676<br />
<br />
Test: read_time (s)<br />
size ubifs jffs2 yaffs2<br />
8 4.46 1.48 1.18<br />
32 1.84 5.46 1.8<br />
128 4.86 19.53 4.81<br />
252 11.59 43.97 11.51<br />
<br />
Test: remove_time (s)<br />
size ubifs jffs2 yaffs2<br />
8 7.4 5.76 9.52<br />
32 6.93 5.11 7.77<br />
128 10.16 8.97 16.42<br />
252 17.26 9.82 37.56<br />
<br />
Test: write_time (s)<br />
size ubifs jffs2 yaffs2<br />
8 4.83 15.97 4.31<br />
32 16.47 60.83 11.14<br />
128 61.41 236.96 37.09<br />
252 118.38 459.58 70.56<br />
<br />
Test: video_write_time (s)<br />
size ubifs jffs2 yaffs2<br />
8 - 16.06 3.69<br />
32 19.03 60.92 8.45<br />
128 72.76 238.99 28.85<br />
252 140.16 461.35 55.16<br />
<br />
<br />
[[Category:Flash Filesystem Benchmarks]]</div>Cschallehttps://elinux.org/index.php?title=Flash_Filesystem_Benchmarks&diff=73789Flash Filesystem Benchmarks2011-10-28T08:31:54Z<p>Cschalle: Add category</p>
<hr />
<div>[http://free-electrons.com Free Electrons] has performed flash filesystem benchmarks, with funding from the [http://www.celinuxforum.org/ CE Linux Forum]. This page is the starting page to present the methodology and the results of these benchmarks.<br />
<br />
== Test methodology ==<br />
<br />
Free Electrons created Python scripts that automate the execution of commands through a serial line (including bootloader and kernel booting), and measure the time taken to execute these commands. The scripts were designed to be generic, and support for new boards can easily be added by creating board specific Python definitions. The complete details of what tests are performed and how measurements are made are available in the [[Flash Filesystem Benchmarks Protocol]] page.<br />
<br />
The current version of these scripts can be found in a Git repository on [https://gitorious.org/ffs-benchmarks/ffs-benchmarks gitorious], and are released under the terms of the GPLv2 license. Working board automation files are provided for the [http://www.calao-systems.com/articles.php?lng=en&pg=5932 CALAO USB-A9263-C02] and [http://www.igep.es/index.php?option=com_content&view=article&id=46&Itemid=55 IGEPv2 boards]. You will need to build a root filesystem to run the tests on and create filesystems of different sizes (8, 32, 252 and 508 MB) to be tested ; both of which that have been used by Free Electrons will be available soon.<br />
<br />
== Results ==<br />
<br />
=== Comparison of different versions of the Kernel ===<br />
<br />
See [[Flash Filesystem Benchmarks Kernel Evolution]] to find possible regressions<br />
<br />
=== Linux 3.0 results ===<br />
See [[Flash Filesystem Benchmarks 3.0]] for the results<br />
<br />
=== Linux 2.6.39 results ===<br />
See [[Flash Filesystem Benchmarks 2.6.39]] for the results<br />
<br />
=== Linux 2.6.38 results ===<br />
See [[Flash Filesystem Benchmarks 2.6.38]] for the results<br />
<br />
=== Linux 2.6.36 results ===<br />
See [[Flash Filesystem Benchmarks 2.6.36]] for the results<br />
<br />
== Presentations of the results ==<br />
<br />
Previous results of those benchmarks were presented:<br />
* At [http://www.embeddedlinuxconference.com/elc_europe10/index.html ELC Europe 2010], the [http://elinux.org/images/d/d7/Elce2010-flash-filesystems.pdf slides] are available<br />
* At [http://www.embeddedlinuxconference.com/elc_europe08/index.html ELC Europe 2008], the [http://tree.celinuxforum.org/CelfPubWiki/ELCEurope2008Presentations?action=AttachFile&do=get&target=flash-filesystems.pdf slides] are available<br />
<br />
== Details on the hardware platforms used ==<br />
<br />
* [http://www.calao-systems.com/articles.php?lng=en&pg=5932 CALAO USB-A9263-C02]<br />
** AT91SAM9263 processor at 200 Mhz<br />
** 64 MB of RAM<br />
** 256 MB of NAND Flash from Samsung K9F2G08U0A<br />
* [http://www.igep.es/index.php?option=com_content&view=article&id=46&Itemid=55 IGEPv2 boards]<br />
** DM3730 processor at 1 Ghz<br />
** 512 MB of RAM<br />
** 512 MB of dual-plane SLC OneNAND Flash from Numonyx NAND04GR4E1A<br />
<br />
[[Category:Flash Filesystem Benchmarks]]</div>Cschalle