OpenQNX :: The QNX Community Portal

May 13, 2008 - 10:27 AM


	Create an account	Home · Submit News · QNX Forums · QNX Download · Search

		_

		Main Menu
	Home Modules QNX FORUMS QNX FAQ QNX Downloads Live QNX Support QNX Newsgroups Web Links OpenQNX project Mailing List QNX News QNX Reviews Search Stats Top List Contact Us

		Who's Online
	There are 56 unlogged users and 0 registered users online. You can log-in or register for a user account here.

iMX21ADS procnto hangs??
1, 2 Next

OpenQNX Forum Index » QNX Developers » Realtime and Embedded

Author

Message

bmartin

Post subject: iMX21ADS procnto hangs??

Posted: Feb 03, 2008 - 11:15 PM

Active Member

Joined: Feb 03, 2008
Posts: 17

Hello,

I am trying to get iMX21 BSP to work. I am fairly new to QNX.

I built the IFS as a virtual RAW+compress and when I run the startup in verbose mode everything is fine, but then when it tries to jump to the procnto it prints "Starting next program at " and then some virtual address and then it hangs. Any suggestions of what I could try? I have an iMX21ADSE dev board and the associated BSP which I have not modified.

Ben

bmartin

Post subject: More Info

Posted: Feb 05, 2008 - 05:03 PM

Active Member

Joined: Feb 03, 2008
Posts: 17

I found that ttc(TTC_INIT,START,&ttyctrl,0) never returns in the main() of the serial driver. Is this normal? What would cause this?

I debugged this by requesting a mmap_device_io for an LED physical address and then using out32() to turn on the LEDs. If If I put this command before ttc(TTC_INIT,START,&ttyctrl,0) the LED turns on. If I put this command after ttc(TTC_INIT,START,&ttyctrl,0) the LED never turns on.

Could this be related?

Ben

mario

Post subject: RE: More Info

Posted: Feb 05, 2008 - 05:09 PM

QNX Master

Joined: Sep 01, 2002
Posts: 2667

Yes it's normal, ttc takes over.

bmartin

Post subject: My Reply

Posted: Feb 05, 2008 - 09:24 PM

Active Member

Joined: Feb 03, 2008
Posts: 17

So if the main() for the serial driver never returns, how does anything else get a change to run?

Do you have any idea what I might want to check then? It still just hangs.

I suspected it was that ttc function was not returning, but if that isn't it, do you have any recommendations?

Is there any way of debugging this other than turning on an LED?

Ben

rgallen

Post subject: Re: My Reply

Posted: Feb 06, 2008 - 04:10 AM

QNX Master

Joined: Jul 11, 2002
Posts: 557

bmartin wrote:

Post your build file. What runs after the serial driver? Do you do a reopen?

vladimir_sun

Post subject:

Posted: Feb 06, 2008 - 04:03 PM

New Member

Joined: Jan 24, 2005
Posts: 4

I just encounter to the same problem while embedding QNX6 into XScale IPX420 custom board. Last what the system says was:

Starting next program at vfe020344

And looks like hanged up after that.

The solvation was in the fact that Neutrino needs some space in the begin of RAM, obviously as address space for system devices. So I just shift the image in the RAM almost in it end, and "viola!" it starts.
You can add [image=0xSOMEADDR] tag in your buildfile before [virtual=.....
where 0xSOMEADDR is the address to load your image in the RAM.

For example RedBoot tell me the following:

RAM: 0x00000000-0x02000000, [0x0000e938-0x00fd1000] available

So 0x00fd1000 is the end of my available RAM.

After loading image by "load -b %{FREEMEMLO} -m ymodem" I see the next strings:

Entry point: 0x0000ed00, address range: 0x0000ec00-0x000b27cc

So I have image size and can substract it from end_address and evaluate the address-to-load. Then I add [image=0x00e20000] tag to buildfile and load new image by command:

load -b 0x00e20000 -m ymodem

Execute it from new entry point:

exec 0x00e20000

Here is my buildfile:
_______________________________________________________________________

[image=0x00e20000]

[virtual=armbe,srec +compress] .bootstrap = {
startup-ixdp425 -vvv
PATH=:/proc/boot:/bin:/usr/bin LD_LIBRARY_PATH=:/proc/boot:/lib:/usr/lib:/lib/dll procnto -v
}
[+script] .script = {
procmgr_symlink ../../proc/boot/libc.so.2 /usr/lib/ldqnx.so.2

display_msg Welcome to QNX Neutrino 6.3 on the IXDP425 Evaluation Board

devc-ser8250-ixp2400 -F -e -c14745600 -b115200 0xc8000000^2,15
waitfor /dev/ser1
reopen /dev/ser1

slogger
pipe

display_msg Starting PCI server...

pci-ixc1100
waitfor /dev/pci
SYSNAME=nto
TERM=qansi
HOME=/
PATH=:/proc/boot:/bin:/usr/bin:/opt/bin
LD_LIBRARY_PATH=:/proc/boot:/lib:/usr/lib:/lib/dll:/opt/lib

[+session] ksh &
}

[type=link] /bin/sh=/proc/boot/ksh
[type=link] /dev/console=/dev/ser1
[type=link] /tmp=/dev/shmem

libc.so

[data=c]
devc-ser8250-ixp2400

pci-ixc1100
pci

ls
ksh
pipe
pidin
uname
slogger
sloginfo
slay
_______________________________________________________________________

Now it hangs on the PCI server starting. Wink

bmartin

Post subject: Posting Build File

Posted: Feb 06, 2008 - 04:39 PM

Active Member

Joined: Feb 03, 2008
Posts: 17

Hey,
I appreciate the feedback.

I am loading the code into 0xC0100000. SRAM goes from C0000000 to C3FFFFFF. I will try pushing it back even further and see if that helps. Thanks for the feedback.

Anyways, I am basically using an unmodified build file from the BSP. Here it is:

###########################################################################
#
# Neutrino on the Freescale MX21ADS Board, with an ARM 920 core
#
###########################################################################

###########################################################################
## START OF BUILD SCRIPT
###########################################################################

[image=0xc0100000]

# For Redboot , use raw
[virtual=armle,raw +compress] .bootstrap = {

#For QNX IPL/sendnto, use binary
#[virtual=armle,binary +compress] .bootstrap = {
startup-mx21ads -vvvvv
PATH=:/proc/boot:/bin:/usr/bin LD_LIBRARY_PATH=:/proc/boot:/lib:/usr/lib:/lib/dll procnto -vvvvv
}
[+script] .script = {
# Initialise the console
devc-sermx1 -e -F -b115200 -c44333333 0x1000a000,20 0x1000b000,19
waitfor /dev/ser1
reopen /dev/ser1
display_msg Welcome to Neutrino on the Freescale MX21ADS (ARM 926 core) Board

slogger &

# Start some common servers
pipe &

#######################################################################
# display_msg Starting on-board ethernet with TCP/IP stack...
#######################################################################
display_msg Starting ethernet driver ...
io-net -dcrys8900 ioport=0xcc000300,irq=203,mac=00e02991234e -ptcpip

#######################################################################
## These env variables are inherited by all the programs which follow
#######################################################################
SYSNAME=nto
TERM=qansi
HOME=/
LD_LIBRARY_PATH=.:/tmp/:/proc/boot:/usr/photon/lib:/dll:/lib:/lib/dll:/usr/lib:/usr/photon/dll:/opt/lib
PATH=.:/tmp:/proc/boot:.:/sbin:/usr/sbin:/usr/bin:/bin:/usr/local/bin:/usr/photon/bin:/opt/bin
PHOTON_PATH=/usr/photon
PHOTON=/dev/photon
PROCESSOR=armle
MMEDIA_MIDI_CFG=/etc/config/media/midi.cfg

# Start the main shell
[+session] sh &
}

# Redirect console messages
[type=link] /bin/sh=/proc/boot/ksh
[type=link] /dev/console=/dev/ser1
[type=link] /tmp=/dev/shmem

# Programs require the runtime linker (ldqnx.so) to be at a fixed location
[type=link] /usr/lib/ldqnx.so.2=/proc/boot/libc.so

# Shared libaries
libc.so

###########################################################################
## uncomment for NETWORK driver (tiny stack)
###########################################################################
devn-crys8900.so
libsocket.so
npm-tcpip.so

# Executables
[data=c]

devc-sermx1
pipe
ls
slogger
sleep
sloginfo
pidin
ksh
uname
cat
slay
mount
umount
env
cp
dd

/etc/commands = {
}

Here is my output:
Dcache: 512x32 WB
Icache: 512x32
arm926 rev 4 127MHz
Header size=0x0000009c, Total Size=0x000004c8, #Cpu=1, Type=4
Section:system_private offset:0x000001d8 size:0x00000068
syspage ptr user:fc404000 kernel:fc404000
cpupage ptr user:fc404888 kernel:fc404888 spacing:32
kdebug info:00000000 callback:00000000
boot pgms: idx=0
0) base paddr:c010d000 start addr:fe0264e8
ramsize:00000000 pagesize:00001000
Section:qtime offset:0x00000148 size:0x00000048
boot:00000000 CPS:0000000001523c8b rate/scale:45112781/-15 intr:26
Section:callout offset:0x000000a0 size:0x00000048
reboot:fc4046f8 power:fc404714
timer_load:fc404728 reload:fc404758 value:fc404774
0) display:fc40478c poll:fc4047b0 break:fc4047dc
1) display:00000000 poll:00000000 break:00000000
Section:cpuinfo offset:0x00000190 size:0x00000020
0) cpu:41069264 flags:40000000 speed:0000007f cache i/d:1/0 name:48
Section:cacheattr offset:0x00000488 size:0x00000040
0) flags:32 size:0020 #lines:0200 control:fc404504 next:255
1) flags:11 size:0020 #lines:0200 control:fc404558 next:255
Section:meminfo offset:0x000004c8 size:0x00000000
Section:asinfo offset:0x00000308 size:0x00000100
0000) 0000000000000000-00000000ffffffff o:ffff a:0010 p:100 c:00000000 n:21
0020) 00000000c0000000-00000000c3ffffff o:0000 a:0017 p:100 c:00000000 n:28
0040) 00000000c010c110-00000000c02cb257 o:0000 a:0005 p:100 c:00000000 n:55
0060) 00000000c0100008-00000000c010c10f o:0000 a:0007 p:100 c:00000000 n:63
0080) 00000000c010c110-00000000c02cb257 o:0000 a:0007 p:100 c:00000000 n:71
00a0) 00000000c0000000-00000000c0007fff o:0020 a:0007 p:100 c:00000000 n:79
00c0) 00000000c00128a8-00000000c0100007 o:0020 a:0007 p:100 c:00000000 n:79
00e0) 00000000c02cb258-00000000c3ffffff o:0020 a:0007 p:100 c:00000000 n:79
Section:hwinfo offset:0x000002c0 size:0x00000048
0) size:3 tag:3 isize:3, iname:0, owner:65535, kids:1
12) size:3 tag:17 isize:3, iname:9, owner:0, kids:1
24) size:3 tag:3 isize:3, iname:32, owner:12, kids:1
36) size:4 tag:41 isize:4, iname:36, owner:24, kids:0
00 00 00 00
Section:typed_strings offset:0x00000240 size:0x00000028
off:0 type:5 string:'i.MX21ADS'
off:16 type:2 string:'localhost'
Section:strings offset:0x00000268 size:0x00000058
[0]'hw' [3]'Group' [9]'unknown' [17]'Bus' [21]'memory' [28]'ram' [32]'rtc'
[36]'NONE' [41]'Device' [48]'arm926' [55]'imagefs' [63]'startup'
[71]'bootram' [79]'sysram'
Section:intrinfo offset:0x00000408 size:0x00000080
0) vector_base:00000000, #vectors:64, cascade_vector:7fffffff
cpu_intr_base:00000000, cpu_intr_stride:0, flags:0000
id => flags:8000, size:0024, rtn:fc404588
eoi => flags:9000, size:0018, rtn:fc4045ac
mask:fc4045c4, unmask:fc4045e0, config:00000000
1) vector_base:00000040, #vectors:192, cascade_vector:00000008
cpu_intr_base:00000000, cpu_intr_stride:0, flags:0000
id => flags:0000, size:0060, rtn:fc4045fc
eoi => flags:1000, size:0034, rtn:fc40465c
mask:fc404690, unmask:fc4046c4, config:00000000
Section:smp offset:0x000004c8 size:0x00000000
Section:pminfo offset:0x000004c8 size:0x00000000
Section:mdriver offset:0x000004c8 size:0x00000000
Section:boxinfo offset:0x000001b0 size:0x00000028
hw_flags:00000000
Section:cpu offset:0x00000128 size:0x00000020
page_flush:fc4044c8 page_flush_deferred:fc404500
upte_ro:00000aae upte_rw:00000ffe
kpte_ro:0000000e kpte_rw:0000055e
mask_nc:0000000c

System page at phys:c0012000 user:fc404000 kern:fc404000
Starting next program at vfe0264e8

One other thing. I don't think I have redboot on my system. When I load it up, it loads linux. There is this "blob" bootloader if I press a key. To get around this, I have been using the USB/UART bootstrap. I am just using the USB to load memory with the code and then jump to it. I had to change from binary to raw to make this work. I don't think this is related though - but I have been wrong before.

Thanks again for the help!

Last edited by bmartin on Feb 06, 2008 - 06:26 PM; edited 1 time in total

bmartin

Post subject: RE: Posting Build File

Posted: Feb 06, 2008 - 04:42 PM

Active Member

Joined: Feb 03, 2008
Posts: 17

To clarify, I am not actually loading linux/blob. It just looks like this is what is pre-installed. I am switching a dip so that it loads using the USB/UART bootstrap. Basically, freescale has this GUI that you can use to load a binary file into SRAM or FLASH and then jump to it. I am loading the above (currently) into 0xC0100000 and then jumping to this location.

bmartin

Post subject: Tried That

Posted: Feb 06, 2008 - 05:14 PM

Active Member

Joined: Feb 03, 2008
Posts: 17

Hey,

I moved the image to C3000000 as you suggested, but it still hangs at the same spot. Shoot.

Ben

Last edited by bmartin on Feb 06, 2008 - 06:26 PM; edited 1 time in total

vladimir_sun

Post subject: Re: Tried That

Posted: Feb 06, 2008 - 05:42 PM

New Member

Joined: Jan 24, 2005
Posts: 4

[/quote]Hey,

My mistake. Ram goes from 0xC0000000 to C3FFFFFF. Apparently I can't do math this morning.
[/quote]

Evented. Smile

[/quote]
That doesn't change anythign though. I moved the image to C3000000 as you suggested, but it still hangs at the same spot. Shoot.

Ben[/quote]

So, you have 64Mb of RAM. And move the image at the 48-th megabyte. Try to place your image before the 32 Mb border. I read anywere, that in the ARM archecture every process can use only 32Mb of RAM. To access more RAM space it need some magical tricks. I don't know where is the relation in this suggestion, don't ask. It's just a sensation. Smile

But you'll not lost anythging if you'll try. Wink

PS: BTW, it's 20:40 here, in Moscow. Smile

bmartin

Post subject: My Reply

Posted: Feb 06, 2008 - 06:24 PM

Active Member

Joined: Feb 03, 2008
Posts: 17

As per the suggestions above, I have tried the code at

0xC0004000
0xC0100000
0xC1000000
0xC2000000
0xC3000000

They all hung at exactly the same place. I don't think this is the issue. Any other suggestions? I am really stuck!

Thanks
Ben

vladimir_sun

Post subject: RE: My Reply

Posted: Feb 06, 2008 - 06:44 PM

New Member

Joined: Jan 24, 2005
Posts: 4

Ok, let's dance with drumms.

Mayby you can try another format of image. I load up the S-record motorolla format for RedBoot ram start, as was recommended in my BSP. You load raw.
Try [virtual=armle,srec +compress] instead of [virtual=armle,raw +compress] .

And another one offer. More right. Let's wait while anybody of guru awakened and glanced at this thread.

bmartin

Post subject: RE: My Reply

Posted: Feb 06, 2008 - 07:03 PM

Active Member

Joined: Feb 03, 2008
Posts: 17

Made a bit of an advancement. I commented out the serial driver, as well as the waitfor and reopen commands following it. Now I can't input anything, but I get to here!

System page at phys:c0012000 user:fc404000 kern:fc404000
Starting next program at vfe0264e8
Welcome to Neutrino on the Freescale MX21ADS (ARM 926 core) Board
Starting ethernet driver ...
Unable to start "io-net" (2)
sh: j_init: tcgetpgrp() failed: Inappropriate I/O control operation
sh: warning: won't have full job control
#

This is a big step forward I think! Hmmm...so I suppose this means that the issue is in the serial driver...once again pointing to that ttc() function above perhaps. Any suggestions?

vladimir_sun

Post subject: RE: My Reply

Posted: Feb 06, 2008 - 07:22 PM

New Member

Joined: Jan 24, 2005
Posts: 4

I don't know wether it war ttc or not, but procnto has beet started now and you have worken system. Congratulations! It was needed to wast almost a week for me to achieve this conditions. Now you can to dig deep into the manual of your board and rake the BSP code.
You take the point!

bmartin

Post subject: RE: My Reply

Posted: Feb 06, 2008 - 09:13 PM

Active Member

Joined: Feb 03, 2008
Posts: 17

Well I am not so sure I am off to the races yet, but thanks anyways. (For the record, today marks 1 week of pulling my hair out as well) My running hypothesis now is that the problem is somewhere in the serial code. From what I can see, this last call to ttc() is the final enable for the serial port, so I doubt the problem is actually in ttc() but rather in something I set up that gets enabled at that point. Interrupts perhaps? Thanks for your help so far.

Jump to:

All times are GMT

1, 2 Next

OpenQNX Forum Index » QNX Developers » Realtime and Embedded

All logos and trademarks in this site are property of their respective owners. The comments are property of their posters.
Powered by OpenQNX: The QNX Community Portal Site
QNX and the QNX logo are registered trademarks of QNX Software Systems.