UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor guangye.tian
Visitor
11,985 Views
Registered: ‎01-29-2009

Linux boot problem (xilinx ml403, linux-2.6-xlnx.git)

Jump to solution
Hello,

I am trying to boot linux on the xilinx ml403 board.

I used the device tree generator and the linux-2.6-xlnx from the xilinx git tree.

I generated xilinx.dts under EDK9.1 using the device tree generator and copied it to linux-2.6-xlnx.git/arch/powerpc/boot/dts/virtex405-ml403.dts.

Then I generated the file simpleImage.initrd.virtex405-ml403.elf, with boot argument being "console=ttyS0, 9600 root=/dev/ram".

Then I downloaded this file to the board and ran it with the xmd debugger. From the xmd terminal, it shows the following download information:
**********************************************************
XMD% dow simpleImage.initrd.virtex405-ml403.elf
System Reset .... DONE
Downloading Program -- simpleImage.initrd.virtex405-ml403.elf
        section, .text: 0x00400000-0x00408ccf
        section, .data: 0x00409000-0x0040ac5b
        section, __builtin_cmdline: 0x0040ac5c-0x0040ae5b
        section, .kernel:dtb: 0x0040ae60-0x0040c091
        section, .kernel:vmlinux.strip: 0x0040d000-0x005aa4b2
        section, .kernel:initrd: 0x005ab000-0x0071af1f
        section, .bss: 0x0071b000-0x00727ddb
Setting PC with Program Start Address 0x00400000
************************************************

Then when I run the processor, I got the following information from the console (HyperTerminal):
***************************************
zImage starting: loaded at 0x00400000 (sp: 0x0071bf1c)
Allocating 0x3908b0 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x005aa4b3)...done 0x36def0 bytes
Attached initrd image at 0x005ab000-0x0071af20
initrd head: 0x1f8b0808

Linux/PowerPC load: console=ttyS0 root=/dev/ram
Finalizing device tree... flat tree at 0x728300
***************************************

The terminal stoped and no more lines were printed.

I followed the instructions from "Debugging Kernel Boot Problems" in xilinx.wikidot.com, and tried to figure out the value of the program counter (pc) register. The values are someting like "0xc0007e9c" or "0xc0007e8c". And after checing the diassembled code of the "vmlinux" with the command "powerpc-405-linux-gnu-objdump -d vmlinux", I found that the processor is stuck in the <cpu_idle>.

Does any body have had similar problem? Could you give some hint to get the processor out the it?

Thank you,

Guangye
0 Kudos
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
14,375 Views
Registered: ‎09-10-2008

Re: Linux boot problem (xilinx ml403, linux-2.6-xlnx.git)

Jump to solution

Your console on the command line (dts file) is for a 16550 UART while you are using a UART Lite, try console=ttyUL0.  I think it says that on the wiki, but if not we should add it.

 

-- John

0 Kudos
10 Replies
Newbie goehler
Newbie
11,965 Views
Registered: ‎01-30-2009

Re: Linux boot problem (xilinx ml403, linux-2.6-xlnx.git)

Jump to solution

Hello Guangye,

 

I have a similar problem, unfortunately not for the ml403 board but a custom made one.

In my case the configuration is taken from a ml507 board (that actually runs on a native ml507 development environment)

with some adaption of the device tree configuration.

 

The break in <cpu_idle>  may indicate that the linux actually runs but you do not have console output.

 

(this is not the case for my board). 

 

Maybe a hint: did you enter in the xps device tree configuration the proper console device name 

(the one listed in the  *.mhs  file)? 

 

 regards

 

eckart

 

 


guangye.tian wrote:
Hello,

I am trying to boot linux on the xilinx ml403 board.

I used the device tree generator and the linux-2.6-xlnx from the xilinx git tree.

I generated xilinx.dts under EDK9.1 using the device tree generator and copied it to linux-2.6-xlnx.git/arch/powerpc/boot/dts/virtex405-ml403.dts.

Then I generated the file simpleImage.initrd.virtex405-ml403.elf, with boot argument being "console=ttyS0, 9600 root=/dev/ram".

Then I downloaded this file to the board and ran it with the xmd debugger. From the xmd terminal, it shows the following download information:
**********************************************************
XMD% dow simpleImage.initrd.virtex405-ml403.elf
System Reset .... DONE
Downloading Program -- simpleImage.initrd.virtex405-ml403.elf
        section, .text: 0x00400000-0x00408ccf
        section, .data: 0x00409000-0x0040ac5b
        section, __builtin_cmdline: 0x0040ac5c-0x0040ae5b
        section, .kernel:dtb: 0x0040ae60-0x0040c091
        section, .kernel:vmlinux.strip: 0x0040d000-0x005aa4b2
        section, .kernel:initrd: 0x005ab000-0x0071af1f
        section, .bss: 0x0071b000-0x00727ddb
Setting PC with Program Start Address 0x00400000
************************************************

Then when I run the processor, I got the following information from the console (HyperTerminal):
***************************************
zImage starting: loaded at 0x00400000 (sp: 0x0071bf1c)
Allocating 0x3908b0 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x005aa4b3)...done 0x36def0 bytes
Attached initrd image at 0x005ab000-0x0071af20
initrd head: 0x1f8b0808

Linux/PowerPC load: console=ttyS0 root=/dev/ram
Finalizing device tree... flat tree at 0x728300
***************************************

The terminal stoped and no more lines were printed.

I followed the instructions from "Debugging Kernel Boot Problems" in xilinx.wikidot.com, and tried to figure out the value of the program counter (pc) register. The values are someting like "0xc0007e9c" or "0xc0007e8c". And after checing the diassembled code of the "vmlinux" with the command "powerpc-405-linux-gnu-objdump -d vmlinux", I found that the processor is stuck in the <cpu_idle>.

Does any body have had similar problem? Could you give some hint to get the processor out the it?

Thank you,

Guangye

 

 

0 Kudos
Visitor guangye.tian
Visitor
11,959 Views
Registered: ‎01-29-2009

Re: Linux boot problem (xilinx ml403, linux-2.6-xlnx.git)

Jump to solution

Hello Eckart,

 

Thank you for your information. I checked the console device name defined in XPS -> Software Platform Settings -> OS and Libraries -> device-tree:

 

The "console device" is defined as "RS232_Uart" which is identical to the INSTANCE NAME of the xps_uartlite component in the .mhs file. (as below)

 

******************

BEGIN xps_uartlite
 PARAMETER INSTANCE = RS232_Uart
 PARAMETER HW_VER = 1.00.a
 PARAMETER C_BAUDRATE = 9600
 PARAMETER C_DATA_BITS = 8
 PARAMETER C_ODD_PARITY = 0
 PARAMETER C_USE_PARITY = 0
 PARAMETER C_SPLB_CLK_FREQ_HZ = 100000000
 PARAMETER C_BASEADDR = 0x84000000
 PARAMETER C_HIGHADDR = 0x8400ffff
 BUS_INTERFACE SPLB = plb
 PORT RX = fpga_0_RS232_Uart_RX
 PORT TX = fpga_0_RS232_Uart_TX
 PORT Interrupt = RS232_Uart_Interrupt
END

****************** 

 

 

By the way, the .dts file generated by the device tree generator is:

******************

/dts-v1/;
/ {
    #address-cells = <1>;
    #size-cells = <1>;
    compatible = "xlnx,virtex405", "xlnx,virtex";
    model = "testing";
    DDR_SDRAM: memory@0 {
        device_type = "memory";
        reg = < 0x0 0x4000000 >;
    } ;
    SRAM: memory@ffe00000 {
        device_type = "memory";
        reg = < 0xffe00000 0x100000 >;
    } ;
    chosen {
        bootargs = "console=ttyS0 root=/dev/ram";
        linux,stdout-path = "/plb@0/serial@84000000";
    } ;
    cpus {
        #address-cells = <1>;
        #cpus = <0x1>;
        #size-cells = <0>;
        ppc405_0: cpu@0 {
            clock-frequency = <100000000>;
            compatible = "PowerPC,405", "ibm,ppc405";
            d-cache-line-size = <0x20>;
            d-cache-size = <0x4000>;
            dcr-access-method = "native";
            dcr-controller ;
            device_type = "cpu";
            i-cache-line-size = <0x20>;
            i-cache-size = <0x4000>;
            model = "PowerPC,405";
            reg = <0>;
            timebase-frequency = <100000000>;
            xlnx,apu-control = <0xde00>;
            xlnx,apu-udi-1 = <0xa18983>;
            xlnx,apu-udi-2 = <0xa38983>;
            xlnx,apu-udi-3 = <0xa589c3>;
            xlnx,apu-udi-4 = <0xa789c3>;
            xlnx,apu-udi-5 = <0xa98c03>;
            xlnx,apu-udi-6 = <0xab8c03>;
            xlnx,apu-udi-7 = <0xad8c43>;
            xlnx,apu-udi-8 = <0xaf8c43>;
            xlnx,deterministic-mult = <0x0>;
            xlnx,disable-operand-forwarding = <0x1>;
            xlnx,fastest-plb-clock = "DPLB1";
            xlnx,mmu-enable = <0x1>;
            xlnx,pvr-high = <0x0>;
            xlnx,pvr-low = <0x0>;
        } ;
    } ;
    plb: plb@0 {
        #address-cells = <1>;
        #size-cells = <1>;
        compatible = "xlnx,plb-v46-1.00.a", "simple-bus";
        ranges ;
        LEDs_4Bit: gpio@81400000 {
            compatible = "xlnx,xps-gpio-1.00.a";
            reg = < 0x81400000 0x10000 >;
            xlnx,all-inputs = <0x0>;
            xlnx,all-inputs-2 = <0x0>;
            xlnx,dout-default = <0x0>;
            xlnx,dout-default-2 = <0x0>;
            xlnx,family = "virtex4";
            xlnx,gpio-width = <0x4>;
            xlnx,interrupt-present = <0x0>;
            xlnx,is-bidir = <0x1>;
            xlnx,is-bidir-2 = <0x1>;
            xlnx,is-dual = <0x0>;
            xlnx,tri-default = <0xffffffff>;
            xlnx,tri-default-2 = <0xffffffff>;
        } ;
        LEDs_Positions: gpio@81420000 {
            compatible = "xlnx,xps-gpio-1.00.a";
            reg = < 0x81420000 0x10000 >;
            xlnx,all-inputs = <0x0>;
            xlnx,all-inputs-2 = <0x0>;
            xlnx,dout-default = <0x0>;
            xlnx,dout-default-2 = <0x0>;
            xlnx,family = "virtex4";
            xlnx,gpio-width = <0x5>;
            xlnx,interrupt-present = <0x0>;
            xlnx,is-bidir = <0x1>;
            xlnx,is-bidir-2 = <0x1>;
            xlnx,is-dual = <0x0>;
            xlnx,tri-default = <0xffffffff>;
            xlnx,tri-default-2 = <0xffffffff>;
        } ;
        Push_Buttons_Position: gpio@81440000 {
            compatible = "xlnx,xps-gpio-1.00.a";
            reg = < 0x81440000 0x10000 >;
            xlnx,all-inputs = <0x1>;
            xlnx,all-inputs-2 = <0x0>;
            xlnx,dout-default = <0x0>;
            xlnx,dout-default-2 = <0x0>;
            xlnx,family = "virtex4";
            xlnx,gpio-width = <0x5>;
            xlnx,interrupt-present = <0x0>;
            xlnx,is-bidir = <0x1>;
            xlnx,is-bidir-2 = <0x1>;
            xlnx,is-dual = <0x0>;
            xlnx,tri-default = <0xffffffff>;
            xlnx,tri-default-2 = <0xffffffff>;
        } ;
        RS232_Uart: serial@84000000 {
            clock-frequency = <100000000>;
            compatible = "xlnx,xps-uartlite-1.00.a";
            current-speed = <9600>;
            device_type = "serial";
            interrupt-parent = <&xps_intc_0>;
            interrupts = < 1 0 >;
            port-number = <0>;
            reg = < 0x84000000 0x10000 >;
            xlnx,baudrate = <0x2580>;
            xlnx,data-bits = <0x8>;
            xlnx,family = "virtex4";
            xlnx,odd-parity = <0x0>;
            xlnx,use-parity = <0x0>;
        } ;
        SysACE_CompactFlash: sysace@83600000 {
            compatible = "xlnx,xps-sysace-1.00.a";
            interrupt-parent = <&xps_intc_0>;
            interrupts = < 0 2 >;
            reg = < 0x83600000 0x10000 >;
            xlnx,family = "virtex4";
            xlnx,mem-width = <0x10>;
        } ;
        xps_bram_if_cntlr_1: xps-bram-if-cntlr@ffffc000 {
            compatible = "xlnx,xps-bram-if-cntlr-1.00.a";
            reg = < 0xffffc000 0x4000 >;
            xlnx,family = "virtex4";
        } ;
        xps_intc_0: interrupt-controller@81800000 {
            #interrupt-cells = <0x2>;
            compatible = "xlnx,xps-intc-1.00.a";
            interrupt-controller ;
            reg = < 0x81800000 0x10000 >;
            xlnx,num-intr-inputs = <0x2>;
        } ;
    } ;
    ppc405_0_dplb1: plb@1 {
        #address-cells = <1>;
        #size-cells = <1>;
        compatible = "xlnx,plb-v46-1.00.a", "simple-bus";
        ranges ;
        mpmc@0 {
            #address-cells = <1>;
            #size-cells = <1>;
            compatible = "xlnx,mpmc-3.00.a";
        } ;
    } ;
}  ;
 

****************** 

 

Guangye 

0 Kudos
Xilinx Employee
Xilinx Employee
14,376 Views
Registered: ‎09-10-2008

Re: Linux boot problem (xilinx ml403, linux-2.6-xlnx.git)

Jump to solution

Your console on the command line (dts file) is for a 16550 UART while you are using a UART Lite, try console=ttyUL0.  I think it says that on the wiki, but if not we should add it.

 

-- John

0 Kudos
Visitor guangye.tian
Visitor
11,929 Views
Registered: ‎01-29-2009

Re: Linux boot problem (xilinx ml403, linux-2.6-xlnx.git)

Jump to solution

Hello John,

 

Thank you very much. Finally it boots by changing the console name to ttyUL0.

 

Yes, it is already mentioned on the wiki page " Configuring, Building and Loading Linux After 9/1/08" 

 

Guangye 

0 Kudos
Observer kadionik
Observer
8,298 Views
Registered: ‎06-02-2008

Re: Linux boot problem (xilinx ml403, linux-2.6-xlnx.git)

Jump to solution

Dear all,

 

i'm trying to reconstruct an HW design with BSB from ISE 11.4  for an old ML403 board for running Linux on the onboard PowerPC chip.

I'm unable to have a good design.

 

In the best case, I've had:

Finalizing device tree... flat tree at 0x....

message

 

I've checked to use ttyUL0 with the uart-lite IP block.

Has anyone a pointer to a design for the ML403 board that can run under Linux (> 2.6.3x)?

 

The reference design on the Xilinx web site are outdated: http://www.xilinx.com/products/boards/ml403/reference_designs.htm  for ISE 8.1

It would be nice that Xilnx updates their reference designs ;-)

 

Sincerely Yours;

 

Patrice

 

0 Kudos
Highlighted
Observer kadionik
Observer
8,278 Views
Registered: ‎06-02-2008

Re: Linux boot problem (xilinx ml403, linux-2.6-xlnx.git)

Jump to solution

Dear all,

 

I've solved myself the problem.

 

With BSB, please validate interrupt for all peripherals (except for leds).

In the DTS file, please use ttyUL0 if you use the uartlite peripheral. Please validate its use and its console support in the Linux kernel configuration.

 

Useful docs:

- Debugging Kernel Boot Problems. http://xilinx.wikidot.com/debugging-kernel-boot-problems for printing the log_buf buffer if no console traces are present...

- Configuring and Installing Linux on Xilinx FPGA Boards. http://splish.ee.byu.edu/projects/LinuxFPGA/configuring.htm

- Building Linux 2.6 on ML40x boards. http://www.dti.dk/_root/media/29559_Building%20Linux%202%206%20on%20ML40x%20boards.pdf

 

I can now use Xenomai 2.5.6 with Linux 2.6.35 on my old ML403 board.

 

Cheers;

 

Pat.

 

zImage starting: loaded at 0x00400000 (sp: 0x008b1eb0)
Allocating 0x427ed0 bytes for kernel ...
gunzipping (0x00000000 <- 0x0040d000:0x005e2212)...done 0x3ea04c bytes
Attached initrd image at 0x005e3000-0x008b06d0
initrd head: 0x1f8b0808

Linux/PowerPC load: console=ttyUL0 ip=192.168.0.100 root=/dev/ram ramdisk_size=8
Finalizing device tree... flat tree at 0x8be300
Using Xilinx Virtex machine description
Only using first contiguous memory region
Linux version 2.6.35+ (kadionik@linux01) (gcc version 4.2.2) #9 PREEMPT Sun Mar1
Found initrd at 0xc05e3000:0xc08b06d0
Zone PFN ranges:                                                                
  DMA      0x00000000 -> 0x00004000                                             
  Normal   empty                                                                
Movable zone start PFN for each node                                            
early_node_map[1] active PFN ranges                                             
    0: 0x00000000 -> 0x00004000                                                 
MMU: Allocated 1088 bytes of context maps for 255 contexts                      
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256      
Kernel command line: console=ttyUL0 ip=192.168.0.100 root=/dev/ram ramdisk_size8
PID hash table entries: 256 (order: -2, 1024 bytes)                             
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)                   
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)                    
Memory: 57800k/65536k available (3824k kernel code, 7736k reserved, 188k data, )
Kernel virtual memory layout:                                                   
  * 0xfffdf000..0xfffff000  : fixmap                                            
  * 0xfde00000..0xfe000000  : consistent mem                                    
  * 0xfde00000..0xfde00000  : early ioremap                                     
  * 0xc5000000..0xfde00000  : vmalloc & ioremap                                 
Hierarchical RCU implementation.                                                
        RCU-based detection of stalled CPUs is disabled.                        
        Verbose stalled-CPUs detection is disabled.                             
NR_IRQS:512                                                                     
clocksource: timebase mult[d55555] shift[22] registered                         
I-pipe 2.12-01: pipeline enabled.                                               
Console: colour dummy device 80x25                                              
pid_max: default: 32768 minimum: 301                                            
Mount-cache hash table entries: 512                                             
NET: Registered protocol family 16                                              
PCI: Probing PCI hardware                                                       
bio: create slab <bio-0> at 0                                                   
vgaarb: loaded                                                                  
Switching to clocksource timebase                                               
NET: Registered protocol family 2                                               
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)                  
TCP established hash table entries: 2048 (order: 2, 16384 bytes)                
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)                        
TCP: Hash tables configured (established 2048 bind 2048)                        
TCP reno registered                                                             
UDP hash table entries: 256 (order: 0, 4096 bytes)                              
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)                         
NET: Registered protocol family 1                                               
RPC: Registered udp transport module.                                           
RPC: Registered tcp transport module.                                           
RPC: Registered tcp NFSv4.1 backchannel transport module.                       
Trying to unpack rootfs image as initramfs...                                   
rootfs image is not initramfs (no cpio magic); looks like an initrd             
Freeing initrd memory: 2869k freed                                              
I-pipe: Domain Xenomai registered.                                              
Xenomai: hal/powerpc started.                                                   
Xenomai: scheduling class idle registered.                                      
Xenomai: scheduling class rt registered.                                        
Xenomai: real-time nucleus v2.5.6 (Wormhole Wizards) loaded.                    
Xenomai: starting native API services.                                          
Xenomai: starting POSIX services.                                               
Xenomai: starting RTDM services.                                                
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).                        
ROMFS MTD (C) 2007 Red Hat, Inc.                                                
msgmni has been set to 118                                                      
io scheduler noop registered                                                    
io scheduler deadline registered                                                
io scheduler cfq registered (default)                                           
Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled                        
84000000.serial: ttyUL0 at MMIO 0x84000000 (irq = 16) is a uartlite             
console [ttyUL0] enabled                                                        
brd: module loaded                                                              
loop: module loaded                                                             
xilinx_emaclite 81000000.ethernet: Device Tree Probing                          
xilinx_emaclite 81000000.ethernet: error registering MDIO bus                   
xilinx_emaclite 81000000.ethernet: MAC address is now 00:0a:35:ae:02:00         
xilinx_emaclite 81000000.ethernet: Xilinx EmacLite at 0x81000000 mapped to 0xC57
mice: PS/2 mouse device common for all mice                                     
i2c /dev entries driver                                                         
TCP cubic registered                                                            
NET: Registered protocol family 17                                              
IP-Config: Guessing netmask 255.255.255.0                                       
IP-Config: Complete:                                                            
     device=eth0, addr=192.168.0.100, mask=255.255.255.0, gw=255.255.255.255,   
     host=192.168.0.100, domain=, nis-domain=(none),                            
     bootserver=255.255.255.255, rootserver=255.255.255.25RAMDISK: gzip image f0
VFS: Mounted root (ext2 filesystem) readonly on device 1:0.                     
Freeing unused kernel memory: 168k init                                         
init started: BusyBox v1.7.1 (2008-04-01 18:14:12 MEST)                         
starting pid 829, tty '': '/etc/rc.sh'                                          
/etc/rc.sh: line 5: cannot create /etc/mtab: Read-only file system              
                                                                                
Please press Enter to activate this console.                                    
starting pid 838, tty '': '/bin/sh'                                             
/bin/sh: can't access tty; job control turned off                               
~ # sh --login                                                                  
sh: can't access tty; job control turned off                                    
~ # latency -t2                                                                 
== Sampling period: 100 us                                                      
== Test mode: in-kernel timer handler                                           
== All results in microseconds                                                  
warming up...                                                                   
RTT|  00:00:01  (in-kernel timer handler, 100 us period, priority 99)           
RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst
RTD|     -2.554|     -1.445|      4.216|       0|     0|     -2.554|      4.216
RTD|     -2.554|     -1.353|     11.839|       0|     0|     -2.554|     11.839
RTD|     -2.551|     -1.409|     10.469|       0|     0|     -2.554|     11.839
RTD|     -2.552|     -1.403|     10.269|       0|     0|     -2.554|     11.839
RTD|     -2.552|     -1.410|     17.738|       0|     0|     -2.554|     17.738

 

0 Kudos
Observer kadionik
Observer
8,216 Views
Registered: ‎06-02-2008

Re: Linux boot problem (xilinx ml403, linux-2.6-xlnx.git)

Jump to solution

Hi all,

 

I've written a page on how to use Xenomai on PowerPC processor into Virtex FPGA: http://uuu.enseirb-matmeca.fr/~kadionik/powerpc_virtex-xenomai/index.html

 

Cheers;

 

Pat.

0 Kudos
Xilinx Employee
Xilinx Employee
8,184 Views
Registered: ‎09-10-2008

Re: Linux boot problem (xilinx ml403, linux-2.6-xlnx.git)

Jump to solution
Hi Pat,

That's interesting info. Maybe I missed it, but I didn't see any numbers to show the differenece between without Xenomai and with it so that we understand how much it helped.

Thanks.
0 Kudos
Observer kadionik
Observer
8,100 Views
Registered: ‎06-02-2008

Re: Linux boot problem (xilinx ml403, linux-2.6-xlnx.git)

Jump to solution

Hi John,

 

I will give some measurements with a video decoder to show the benefit to have a realtime extension: not faster but time constraints respected...

 

Cheers;

 

Pat.

0 Kudos
Observer kadionik
Observer
2,490 Views
Registered: ‎06-02-2008

Re: Linux boot problem (xilinx ml403, linux-2.6-xlnx.git)

Jump to solution

Hi,

 

Some very simple measurements on processing time (not on latency time) by using a H.263 decoder (tmndec) applied to an H.263 encoded file (51 H.263 frames).

For stressing the system, I've used stress tool: http://weather.ou.edu/~apw/projects/stress/

 

With standard Linux kernel for PowerPC/Xilinx (version 2.6.35):

Without CPU loading:

# cat godec                                                                
./tmndec -o5 stream.263 miss_dec.qcif

/bin # ./godec                                                                  
0.63 seconds, 51 frames, 80.95 fps

 

With CPU loading:

/bin # stress -i 20 -c 20 &                                                     
/bin # stress: info: [799] dispatching hogs: 20 cpu, 20 io, 0 vm, 0 hdd   
/bin # ./godec                                                                  
17.57 seconds, 51 frames, 2.90 fps  

 

With Xenomai Linux kernel for PowerPC/Xilinx (version 2.6.35 with Xenomai):

Without CPU loading:

/bin # ./godec                                                                  
0.65 seconds, 51 frames, 78.46 fps

 

With CPU loading:

/bin # stress -i 20 -c 20 &                                                     
/bin # stress: info: [799] dispatching hogs: 20 cpu, 20 io, 0 vm, 0 hdd  

/bin # ./godec                                                                  
19.20 seconds, 51 frames, 2.66 fps

Program executed as a POSIX RT thread with sched tool (SCHED_FIFO scheduling used by Xenomai for POSIX RT threads http://xenomai.org/index.php/Porting_POSIX_applications_to_Xenomai#Real-time_priorities):

/bin # sched -f 99 ./godec                                                      
0.65 seconds, 51 frames, 78.46 fps

 

With Xenomai extension, processing time for decoder as a Xenomai RT thread (SCHED_FIFO, priority 99) is bounded even with CPU loading...

 

Pat.

0 Kudos