iMX21ADS procnto hangs??

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

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

Yes it’s normal, ttc takes over.

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

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

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. ;)

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
  2. cpu:41069264 flags:40000000 speed:0000007f cache i/d:1/0 name:48
    Section:cacheattr offset:0x00000488 size:0x00000040
  3. flags:32 size:0020 #lines:0200 control:fc404504 next:255
  4. flags:11 size:0020 #lines:0200 control:fc404558 next:255
    Section:meminfo offset:0x000004c8 size:0x00000000
    Section:asinfo offset:0x00000308 size:0x00000100
  5. 0000000000000000-00000000ffffffff o:ffff a:0010 p:100 c:00000000 n:21
  6. 00000000c0000000-00000000c3ffffff o:0000 a:0017 p:100 c:00000000 n:28
  7. 00000000c010c110-00000000c02cb257 o:0000 a:0005 p:100 c:00000000 n:55
  8. 00000000c0100008-00000000c010c10f o:0000 a:0007 p:100 c:00000000 n:63
  9. 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
  10. size:3 tag:3 isize:3, iname:0, owner:65535, kids:1
  11. size:3 tag:17 isize:3, iname:9, owner:0, kids:1
  12. size:3 tag:3 isize:3, iname:32, owner:12, kids:1
  13. 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
  14. 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
  15. 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!

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.

Hey,

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

Ben

[/quote]
Hey,

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

Evented. :slight_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. :slight_smile:
But you’ll not lost anythging if you’ll try. ;)

PS: BTW, it’s 20:40 here, in Moscow. :slight_smile:

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

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.

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?

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!

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.

Yes, it sounds as if there might be a problem with the command line for devc-ser8250. I notice you are setting stride… is the stride correct?

Ok, so here is where I am.

If I comment out the serial driver (as well as the reopen) I can see the system boot up to the ksh prompt no problem (except I have no stdin). If I uncomment the serial driver so that it executes- even if I don’t call reopen (so that I continue to use my old stdout)- it hangs. Just so you know, while I am debugging, I am using one UART 1 for my debug stdout. I am trying to initialize the serial driver on UART 2 so that I can continue to use UART 1 to do fprintf() provided I don’t call reopen.

Originally I was thinking this pointed to the problem to the serial driver. I spent a whole day stepping through the code. Like I said, on the last line of main.c for the serial driver, when I call ttc with that init_start it never returns. (One guy on the forum said that this call never returns in any system, so to test this, I started the serial driver as a process and used waitfor to wait until my serial device started. I waited forever. I think it is supposed to return)

While I was debugging I noticed something else curious. If I leave the serial driver commented (as well as reopen) so that the system would normally make it to the prompt, but I add a call “sleep 1” the system hangs at the sleep call as well. Should I suspect perhaps a callout function maybe? Perhaps the interrupt controller? These would affect both sleep and the serial driver.

Any suggestions? I am pulling my hair out now.

Ben

It sounds like the timer interrupt is not firing. This would also indicate why you don’t have stdin, since the debug callouts simply poll the device for input during the clock tick.
Could you also test this by running date in a loop - if time is not advancing, then anything that tries to use a sleep/timer would just hang.

Ok, so I got a partial solution today.

The -c attribute for the serial device was 44333333, but I changed this to 31750000 and now my serial driver works. The reason it was working before was because I am not using the ipl for now, so nothing ever set the baud rate, so it just held the proper divisor from the boot strap.

Now that I have STDIN things are a little easier. “Sleep 1” still hangs forever. “Date” returns the epoch whenever it returns (in other words, it isn’t incrementing). There is obviously something going on here.

Hey! At least I can type now! Whoohooo.

Thanks for you help thus far. I think I am close! My guess is that once I get my timer working (so that sleep and date perform correctly) it will just by typical debugging to get the rest of it up and running.

Well I figured out why sleep was hanging today. Boy it is a lot easier to debug once you have a working terminal!

Anyways, the issue was that for whatever reason the BSP never enables the clock to the timer module in the driver.

If you are using the iMX21 BSP and having this trouble, look into the GPT1_EN bit in the Peripheral Clock Control Register 1. You must enable it.

Also, the reason for the UART clock being wrong was because in my BSP they have "do not populated"ed the 26MHz crystal and so the system is running of the 32798 oscillator. With the 512X frequency multiplier, this gives a frequency of 16.777MHz feeding the PLL instead of 26MHz. The theoretically correct clock speed for the UART is thus: 31999993MHz in the build script, not 44333333 MHz.

Incidentely, if you want the timer to count correct seconds, then you need to adjust the timer driver (init_qtime_mx21.c in startup) for the new clock rate as well. The MX21_CLOCK_FREQ define should be adjusted to 15999997UL, and the MX21_CLOCK_RATE should be adjusted to 62500013UL. (Remember, these changes are only if you aren’t using a 26MHz xtal).

I haven’t looked into any other subsystems other than the serial driver and the timer. There could be more issues, but for now, things are looking up! Hopefully this will help someone out there so they don’t spend 2 weeks debugging as I just did.