Re: [Xenomai-help] Problems when cross-compiling Xenomai

["Felipe Brandão Cavalcanti" <cavalkaf@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 5635 bytes --]

2010/2/13 Felipe Brandão Cavalcanti <cavalkaf@domain.hid>

>
>
> 2010/2/13 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>
> Felipe Brandão Cavalcanti wrote:
>> > OK - I did apply the patch to 2.6.30.10, with some very minor
>> modifications
>> > in the sound system and in the headers (MACH_TYPE_IGEP0020 wasn't
>> defined).
>> > I also applied the latest Adeos Ipipe patch.
>> >
>> > However, the compiled kernel doesn't boot - it actually just sits there,
>> > doing nothing:
>> >
>> > Bytes transferred = 2555616 (26fee0 hex)
>> > ## Booting kernel from Legacy Image at 80000000 ...
>> >    Image Name:   Linux-2.6.30.10
>> >    Image Type:   ARM Linux Kernel Image (uncompressed)
>> >    Data Size:    2555552 Bytes =  2.4 MB
>> >    Load Address: 80008000
>> >    Entry Point:  80008000
>> >    Verifying Checksum ... OK
>> >    Loading Kernel Image ... OK
>> > OK
>> >
>> > Starting kernel ...
>> >
>> > Uncompressing
>> >
>> Linux..................................................................................................................................................................
>> > done, booting the kernel.
>> >
>> > My guess is that Linux is simply not sending anything through my serial
>> > (i.e., debug) port. Should I attempt to port over the serial driver, or
>> is
>> > this something else?
>> > I am also downloading kernel 2.6.32 to see if I can make it boot on my
>> IGEP.
>>
>> Do you pass the proper "console=" argument to the kernel? Is the support
>> for serial driver enabled in the kernel?
>>
>> If yes, then apply trick #1 from the "Tips and tricks" section in the
>> "porting I-pipe to a new board" HOWTO on Xenomai website.
>>
>>
> Yeah, I called it with the console= argument, and support is enabled. Just
> tested 2.6.32 - working fine in my board!
>
> I will try 2.6.30 again, but this time with no I-pipe patch, as well as
> enabling the low-level debug options.
>
>

OK - so I compiled the kernel with a series of kernel debug options, to find
out what was going on. However, the kernel is stuck in a very strange
position - just after starting the network!

So, any ideas on where I should take a look? I will attempt disabling
network support, but this would a temporary solution, as I actually need
network on my embedded system.

Thanks for the help,
  -Felipe Brandão Cavalcanti

Here is my console output:

Starting kernel ...

Uncompressing
Linux............................................................................................................................................................................................
<5>Linux version 2.6.30.10 (jdoe@domain.hid) (gcc version 4.3.2 (GCC) ) #1 Mon
Feb 15 18:06:42 CET 2010
CPU: ARMv7 Processor [411fc083] revision 3 (ARMv7), cr=10c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: IGEP v2.x board
Memory policy: ECC disabled, Data cache writeback
<5>Truncating RAM at 80000000-9fffffff to -87ffffff (vmalloc region
overlap).
<7>On node 0 totalpages: 32768
<7>free_area_init_node: node 0, pgdat c06f9208, node_mem_map c0d29000
<7>  Normal zone: 256 pages used for memmap
<7>  Normal zone: 0 pages reserved
<7>  Normal zone: 32512 pages, LIFO batch:7
<6>OMAP3430 ES3.1
<6>SRAM: Mapped pa 0x40200000 to va 0xd7000000 size: 0x100000
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
<5>Kernel command line: mem=512M console=ttyS2,115200n8 console=tty0
omapfb.mode=dvi:1024x768MR-16@domain.hid root=/dev/mtdblock4 rootfstype=jffs2
<3>Unknown boot option `omapfb.mode=dvi:1024x768MR-16@domain.hid': ignoring
<6>NR_IRQS:402
<6>Clocking rate (Crystal/DPLL/ARM core): 26.0/332/720 MHz
<6>GPMC revision 5.0
<6>IRQ: Found an INTC at 0xd8200000 (revision 4.0) with 96 interrupts
<6>Total of 96 interrupts on 1 active controller
<6>OMAP34xx GPIO hardware version 2.5
PID hash table entries: 512 (order: 9, 2048 bytes)
<6>OMAP clockevent source: GPTIMER1 at 32768 Hz
Console: colour dummy device 80x30
<6>console [tty0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:  8
... MAX_LOCK_DEPTH:          48
... MAX_LOCKDEP_KEYS:        8191
... CLASSHASH_SIZE:          4096
... MAX_LOCKDEP_ENTRIES:     16384
... MAX_LOCKDEP_CHAINS:      32768
... CHAINHASH_SIZE:          16384
 memory used by lock dependency info: 3871 kB
 per task-struct memory footprint: 2304 bytes
<6>Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
<6>Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
<6>Memory: 128MB = 128MB total
<5>Memory: 116308KB available (4880K code, 8068K data, 180K init, 0K
highmem)
<7>ODEBUG: 0 of 0 active objects replaced
<6>Calibrating delay loop... 715.27 BogoMIPS (lpj=2793472)
Mount-cache hash table entries: 512
<6>CPU: Testing write buffer coherency: ok
<6>net_namespace: 988 bytes
<6>regulator: core version 0.5
<6>NET: Registered protocol family 16



>
>> --
>>                                             Gilles.
>>
>>
>
>
> --
>       -Felipe Brandão Cavalcanti
>       LARA - Robotics and Automation Laboratory
>       Department of Electrical Engineering
>       UnB - University of Brasília, Brazil
>       http://www.lara.unb.br/~fbcavalcanti/<http://www.lara.unb.br/%7Efbcavalcanti/>
>



-- 
      -Felipe Brandão Cavalcanti
      LARA - Robotics and Automation Laboratory
      Department of Electrical Engineering
      UnB - University of Brasília, Brazil
      http://www.lara.unb.br/~fbcavalcanti/

[-- Attachment #2: Type: text/html, Size: 7269 bytes --]