Syslink + Beagleboard XM + Linux Kernel 3.11.4

Jernej Turnsek

Other Parts Discussed in Thread: DM3730, OMAP3530

Hi,

I am trying to port Syslink (2.21.02.10) to Linux Kernel 3.11.4 on platform Beagleboard XM (DM3730 processor). I was able to fix the Syslink code in order to compile and run on Beagle. Now I am running ex01_helloworld which does run, but with some problems. I stuck at that point. In my console I am seeing like everything is ok:

jernej@beaglexm:~/share/ex01_helloworld/release$ sudo ./run.sh
+ ./slaveloader startup DSP server_dsp.xe64P memmap.txt
Attached to slave procId 0.
Mapping SV: 0x8f000000, SP: 0x8f000000, MP: 0x8f000000,
size 0x800000, mask 0x5, cached 0
ProcMgr_map succeeded
Mapping SV: 0x8ef00000, SP: 0x8ef00000, MP: 0x8ef00000,
size 0x10000, mask 0x5, cached 0
ProcMgr_map succeeded
Mapped entries in memmap.txt to slave procId 0.
Loading procId 0.
Loaded file server_dsp.xe64P on slave procId 0.
Started slave procId 0.
+ ./app_host DSP
--> App_exec:
App_exec: event received from procId=0
<-- App_exec: 0
+ ./slaveloader shutdown DSP memmap.txt
Stopped slave procId 0.
Unloaded slave procId 0.
Unmapping SV: 0x8f000000, SP: 0x8f000000, MP: 0x8f000000,
size 0x800000, mask 0x5, cached 0
Found MKV entry (0xd2000000)
ProcMgr_unmap succeeded
Unmapping SV: 0x8ef00000, SP: 0x8ef00000, MP: 0x8ef00000,
size 0x10000, mask 0x5, cached 0
Found MKV entry (0xcfa20000)
ProcMgr_unmap succeeded
Mapped entries in memmap.txt to slave procId 0.
Detached from slave procId 0.

but when examining the dmsg I see kernel oops.

Attached file: 5148.dmesg_output_working_ex01_helloworld_3.txt

It shows a lot of Ipc_attach failures and In-band Error seen by IVA_SS at address 0. I've looked into other forum conversations and I still don't know what is causing this.

Also when I run example for the first time, it is ok (except the oops in kernel), but when I run it for the second time, beagle freezes up.

I am using

ipc_1_25_03_15

uia_1_03_01_08

xdais_7_21_01_07

xdctools_3_25_03_72

bios_6_35_04_50

CCS 5_5_0 installation

O yes, I have also configured the beagle boot parameters to use only 239MB of RAM, because otherwise examples doesn't work.

Any suggestions what is wrong and how to proceed?

Thanks,

Jernej

over 11 years ago

0 Chris Ring over 11 years ago

TI__Genius 17205 points

Google turned up this old thread when I searched for "In-band Error seen by IVA_SS"

http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/127768.aspx

That thread hints at some kernel config changes you may need(?). Maybe those config changes would remove that error.

Also, FWIW, I think the Ipc_attach: Ipc_procSyncStart failed! messages are benign. I think those are printed when it's trying to handshake with the DSP, which can take some time while the DSP is booting up. You can see from the time stamps that, even though there's a mountain of trace, not much time has passed.

The stack trace is a bit odd - but I've been away from the SysLink code base for a while. The NotifyDriverShm_Params_init() called deep inside Ipc_attach() is a pretty harmless fxn. It seems like it gets pre-empted - maybe by an interrupt handler that hasn't been plugged. Maybe by the DSP has generated an interrupt that no one has plugged yet?

Maybe some of your changes disabled some of the SysLink ISR registration?

Chris

0 Jernej Turnsek over 11 years ago in reply to Chris Ring

Prodigy 40 points

Hi Cris,

I thank you for taking your time. It means really a lot to us users that we are not alone with our problems.

Regarding Ipc_procSyncStart I am very pleased that this is not a problem at all, although it looks very scary with so much failed messages.

Regarding the "In-band Error seen by IVA_SS" I looked into that thread you mentioned. I don't have CONFIG_OMAP_IOMMU_IVA2 option actually set in my kernel config file, but I wrote a patch which is defining CONFIG_OMAP_IOMMU_IVA2 in omap hwmod setting file (omap_hwmod_3xxx_data.c) This is the only place where this option has an effect.

I have also checked my changes in the SysLink implementation. I rewrote the iommu functionality in omap3530_hal_mmu.c and add an offset of 16 (NR_IRQS) to the ARM_INT0 interrupt:

typedef enum NotifySetup_ARM_INT_tag {
NotifySetup_ARM_INT0 = 42u /*26u*/
} NotifySetup_ARM_INT;

This offset was derived from NR_IRQS from the kernel itself. I did not put offset on DSP_INT0 interrupt, although I tried, but there was no effect.

I was also investigating a little bit further and found out that when I insmod syslink.ko for the first time after reboot and then run the ex01_helloworld, I get that stack dump and "In-band Error seen by IVA_SS" error. But when I do rmmod syslink.ko and after that insmod again and then run ex01_helloworld, error disappeared and also there is no stack dump. I am thinking that some kind of initialization might be a problem. Am I right?

Also what is strange, that when I do only one insmod syslink.ko and ran ex01_helloworld for the second time, board freezes completely. I then can not examine system messages of what went wrong.

Any thoughts?

Jernej

0 Yulin Liu over 10 years ago

Prodigy 80 points

Hi Jernej: I saw in you post you managed to compile syslink to support kernel 3.11.4, how did you do that? I'm using Linux ezsdk beagleboard 06.00.00, which has the kernel version 3.11 In products.mak I put LINUXKERNEL=//board-support/linux-3.3.7 While run make, it shows"could not find file //board-support/Linux-3.3.7/include/config/kernel.release" Searching in these folders there is no kernel.release, I assume this is because of higher kernel version. But I'm not familiar with making kernel. Could you or anyone help me out? Thanks!

Processors

Processors forum

Syslink + Beagleboard XM + Linux Kernel 3.11.4