Need help with enumerating EVMC6670L assembled with TMDEXEVMPCI

You need to have a driver for the board in the host. We don't have a driver right now. But we have a reference kernel module code in the MCSDK. Please check the tools\boot_loader\examples\pcie in the MCSDK package for the host loader.

Thanks,

Arun.

Yes, I followed the README.pdf and built the PCIe linux host loader found in tools\boot_loader\examples\pcie\linux_host_loader. But before I even get to the step to install the host loader into the kernel, I expected to see the adapter+EVM get enumerated by the PC after Linux is loaded. The README indicated that the following should be in the list

local-ubuntu:~$ lspci….

No such entry or similar entry was output.

Are you suggesting that I need to install the Linux host loader first? I'm not quite sure I understand your answer.

Regards,

James

Hello David,

Thank you for the tip. Yes, the README was not clear on the step for reprogramming the IBL to the EEPROM, and I did not perform the IBL configuration step as required. The PCIe device now gets enumerated by the Linux host.

The problem I am having now is loading the host loader kernel module. The PC resets itself when I do "insmod pciedemo.ko". I've tried both the "hello world" and "post" examples with no success. I am running Fedora 10 linux and here is system info from "uname"

Linux  2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:18:33 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux

A related issue is that the EVM does not get enumerated during a PC warm reset. Is there a way to reset the adapater+EVM board during a PC reboot such that it can get enumerated without having to resort to power cycle?

Appreciate your help.

Regards

James

A follow on to my previous post...

The PC is resetting in the inbound BARn configuration code segment of the pciedemo.c file. Could the memory mapping between PC and DSP be incorrect and resulting in accessing an illegal PC address? When I stub that code section out along with the section for loading DSP with the demo app, the kernel module installation completes. Below is a snippet of the kernel log

Finding the device....
Found TI device
TI device: vendor=0x0000104c, dev=0x00008888, drv=0x00000000, irq=0x0003, bus=0x3facea00
Enabling the device....
ACPI: PCI Interrupt 0000:60:00.0[A] -> GSI 28 (level, low) -> IRQ 28
PCI: Setting latency timer of device 0000:60:00.0 to 64
Access PCIE application register ....

Here's the a verbose output of lspci:

60:00.0 Multimedia controller: Texas Instruments Unknown device 8888 (rev 01)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 28
        Region 0: Memory at f4500000 (32-bit, non-prefetchable) [size=1M]
        Region 1: Memory at f4400000 (32-bit, prefetchable) [size=512K]
        Region 2: Memory at f4000000 (32-bit, prefetchable) [size=4M]
        Region 3: Memory at f3000000 (32-bit, prefetchable) [size=16M]
        Region 4: Memory at f4490000 (32-bit, prefetchable) [size=4K]
        Region 5: Memory at f4480000 (32-bit, prefetchable) [size=64K]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [70] Express Endpoint IRQ 0
                Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag-
                Device: Latency L0s <1us, L1 <8us
                Device: AtnBtn- AtnInd- PwrInd-
                Device: Errors: Correctable- Non-Fatal- Fatal+ Unsupported-
                Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
                Link: Supported Speed unknown, Width x2, ASPM L0s, Port 0
                Link: Latency L0s <512ns, L1 <64us
                Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch+
                Link: Speed unknown, Width x2

James,

Glad to know you got enumeration working! For PC reset issue, we need to debug it, can you please provide the following information?

1) after enumeration, before inserting the kernel loadable module, use an emulator to connect to DSP, what is the value of BAR0 to BAR5 (0x21801010 to 0x21801024)?

(Note before you connect CCS, for this case, it is best to remove any GEL files to avoid any unnecessary DSP reset by the GEL file. One example is to go to:

ccs_base_5.0.x.xxxxx\emulation\boards\evmc6670l\gel

rename gel to gel_noused4now )

2) add the following printk in bold in the pciedemo.c code, recompile, insert the pciedemo.ko and use lspci to collect more information?

Void

PCI_FindPciDevices (Void)

{

    Uint32 i;

    struct pci_dev * dev = NULL ;

     while ((dev = pci_get_device (PCI_ANY_ID, PCI_ANY_ID, dev)) != NULL)

    {

                        if ((dev->vendor == PCIE_TI_VENDOR) && (dev->device == PCIE_TI_DEVICE)) {

                                    printk ("Found TI device\n");

                                    irqNo = dev->irq ;

                                    GEM = dev ;

                                    printk ("TI device: vendor=0x%08x, dev=0x%08x, drv=0x%08x, irq=0x%04x, bus=0x%08x\n", dev->vendor, dev->device, dev->driver, dev->irq, dev->bus);

                                    for (i=0; i<6; i++) { /* BAR0, 1...., 5 */

                                                printk("TI device requested: resource[%d], Start 0x%8x, End 0x%8x, Flags 0x%x\n",

                                                            i, (int)dev->resource[i].start, (int)dev->resource[i].end, (int)dev->resource[i].flags);

                                    }

                                    break ;

                        }

            }

}

Thanks & regards,

David Zhou

David,

I will try out the debugging steps and provide you with the info.

An added note, I did notice that you had tagged the post with "C6678". We are using the C6670. Any issues with running the PCIe demo on C6670?

Regards,

James

David,

I don't have access to the DSP emulator at the moment, but I here is the additional debug from the kernel module:

Finding the device....
Found TI device
TI device: vendor=0x0000104c, dev=0x00008888, drv=0x00000000, irq=0x001c, bus=0x3facea00
TI device requested: resource[0], Start 0xf4500000, End 0xf45fffff, Flags 0x200
TI device requested: resource[1], Start 0xf4400000, End 0xf447ffff, Flags 0x1208
TI device requested: resource[2], Start 0xf4000000, End 0xf43fffff, Flags 0x1208
TI device requested: resource[3], Start 0xf3000000, End 0xf3ffffff, Flags 0x1208
TI device requested: resource[4], Start 0xf4490000, End 0xf4490fff, Flags 0x1208
TI device requested: resource[5], Start 0xf4480000, End 0xf448ffff, Flags 0x1208
Reading the BAR areas....

Regard,

James

James,

BAR0 we have a mask to request 16K, but your system granted 1024K. Seems this is OK. Flag bit 0x00000200 is set, this also matches our test log. Then the following bold code should be executed:

               */

    if (barFlags [0] & IORESOURCE_MEM) {         

        regBase = barStart [0] ;

        /* Map the memory region. */

        request_mem_region (regBase,

                                              barLen [0],

                                              "DSPLINK");

    }

    else {

        /* Map the memory region. */

        request_region (regBase,

                                              barLen [0],

                                              "DSPLINK");

    }

    if (regBase > 0) {

        regVirt = ioremap (barStart [0],

                                              barLen [0]) ;

    }

You should get a non-null pointer for regVirt, please add a printk to check here. Then you need to find an emulator to see if the PCIE registers below (inbound translation) are successfully written by host or not, or where we break.

                        //Pointing to the beginning of the application registers

                        ptrReg = (Uint32 *) regVirt;

                        printk(“ptrReg is 0x%x\n”, ptrReg);

                        //Configure IB_BAR0 to BAR0 for PCIE registers

                        *(ptrReg+IB_BAR0/4)      = 0;    

                        *(ptrReg+IB_START0_LO/4) = (int)GEM->resource[0].start;   

                        *(ptrReg+IB_START0_HI/4) = 0;    

                        *(ptrReg+IB_OFFSET0/4)   = PCIE_BASE_ADDRESS;   

//Configure IB_BAR1 to BAR1 for LL2 for core0

                        *(ptrReg+IB_BAR1/4)    = 1;    

                        *(ptrReg+IB_START1_LO/4) = (int)GEM->resource[1].start;   

                        *(ptrReg+IB_START1_HI/4) = 0;    

                        *(ptrReg+IB_OFFSET1/4)   = LL2_START + (1 << 28);   

                        //Configure IB_BAR2 to BAR2 for MSMC

                        *(ptrReg+IB_BAR2/4)      = 2;    

                        *(ptrReg+IB_START2_LO/4) = (int)GEM->resource[2].start;   

                        *(ptrReg+IB_START2_HI/4) = 0;    

                        *(ptrReg+IB_OFFSET2/4)   = MSMC_START; 

                        //Configure IB_BAR3 to BAR3 for DDR

                        *(ptrReg+IB_BAR3/4)      = 3;    

                        *(ptrReg+IB_START3_LO/4) = (int)GEM->resource[3].start;   

                        *(ptrReg+IB_START3_HI/4) = 0;    

                        *(ptrReg+IB_OFFSET3/4)   = DDR_START; 

Regards, Eric

Eric,

Confirmed, the regVirt value is non-NULL (0x01600000).  I placed a return before configuring IB_BAR0-3, and init_module() exited and kernel module install completed. Without the return, the PC automatically resets.

Can you resend your comment about the checking PCIE registers through emulator? It was cut off in your post. I will not get to debug with the emulator until next Monday. I will surely send you my findings at that time.

Regards,

James

James,

Sorry for the message cut-off. When you have an emulator, please let me know:

1) BAR0-5 before insert the module

2) IB_BAR, IB_START_LO, IB_START_HI, IB_OFFSET for 0-3 before and after insert the module

Regards, Eric

Eric,

Attached is the pciedemo.c debug output containing the information you requested.

8176.pciedemo_debug.rtf

Regards,

James

Since you mentioned that the machine is "server class" I suspect you may be running a 64-bit version of Linux.  Therefore, I have the theory that the output of pci_resource_start() is a 64-bit value which is getting chopped off when assigned to Uint32 barStart[].  When compiled, does pciedemo.c produce warnings for these lines of code, regarding assigning a 64-bit value to a 32-bit variable?

John,

Yes, we are running with 64-bit Linux. Compilation of the kernel module code does not produce warnings related to the pci_xxx() calls. Only warnings from printk() argument formats are produced (i.e. "warning: format %08x expects type unsigned int, but argument 2 has type Uint32", etc.)

I changed the direct virtual address accesses for the IB_BARn configurations to ioread32() and iowrite32() and that seems to have resolved the PC rebooting, however DSP memory peeks using the emulator starting at 0x21800300 does not indicate that the IB BARn register were written to. The values remained 0x0.

Regards,

James

I am still suspecting 64-bit architecture, since the code is using Uint32 extensively.  I have updated the code to use correct types for current 2.6 kernels such as the 2.6.23 that you are using.  I compiled, but have not yet run this code.

I also updated it to use the ioread32() and iowrite32() macros for all the remote IO to ensure the barrier is included.

This will be tested with the 6678 tomorrow.

See attachment for updated file.

Hi James,

We tested the code with 6678 today and the boot demo was successful. Can you let us know if that code worked for you?

Regards, Eric

Eric,

We tested the updated pciedemo.c code on our 64-bit Linux kernel 2.6.23.1-42.fc8 with our 6670 board. Got a kernel panic:

Found TI device
TI device: vendor=0x0000104c, dev=0x00008888, drv=0x00000000, irq=0x001c, bus=0x3fa95a00
Reading the BAR areas....
Enabling the device....
PCI: Setting latency timer of device 0000:60:00.0 to 64
Access PCIE application register ....
Boot entry address is 0x1082c8e0
Total 4 sections, 0xd420 bytes of data written to core 0
Unable to handle kernel paging request at ffffc2000187fff8 RIP:
 [<ffffffff883a938b>] :pciedemo:WriteDSPMemory+0x101/0x142
PGD 13fc0b067 PUD 13fc0c067 PMD 12006c067 PTE 0
Oops: 0002 [1] SMP
CPU 3
Modules linked in: pciedemo(U) fuse windrvr6(P)(U) nfsd exportfs lockd nfs_acl auth_rpcgss autofs4 sunrpc cpufreq_ondemand acpi_cpufreq loop dm_multipath ipv6 snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_hwdep snd soundcore firewire_ohci firewire_core crc_itu_t floppy iTCO_wdt iTCO_vendor_support shpchp serio_raw tg3 joydev button sg sr_mod cdrom ata_piix mptsas mptscsih mptbase scsi_transport_sas dm_snapshot dm_zero dm_mirror dm_mod ahci libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd
Pid: 10883, comm: insmod Tainted: P        2.6.23.1-42.fc8 #1
RIP: 0010:[<ffffffff883a938b>]  [<ffffffff883a938b>] :pciedemo:WriteDSPMemory+0x101/0x142
RSP: 0000:ffff8100bba2dc18  EFLAGS: 00010297
RAX: 000000001082c8e0 RBX: 0000000000000000 RCX: 0000000000000001
RDX: ffffc2000187fff8 RSI: 0000000000000001 RDI: ffffc20001600638
RBP: 000000000087fffc R08: ffffffff81377168 R09: 000000000000001d
R10: 0000000000000046 R11: ffff81013fc01600 R12: 0000000000000004
R13: 0000000000000000 R14: ffff8100bba2de50 R15: 0000000000000001
FS:  00002aaaaaacc6f0(0000) GS:ffff81013fc01800(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffc2000187fff8 CR3: 00000000bb86e000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process insmod (pid: 10883, threadinfo ffff8100bba2c000, task ffff810120050810)
Stack:  ffff8100bba2de50 ffff8101360dac00 ffffffff883c5280 000000000000001d
 ffffc200015f9dc8 ffffffff883a9b60 ffffffff81321d77 ffffffff8137c260
 ffff8100bba2ddd8 ffffc200015f9dc8 ffff8100bba2dca8 ffffffff8102e012
Call Trace:
 [<ffffffff883a9b60>] :pciedemo:init_module+0x256/0x2c2
 [<ffffffff8102e012>] update_curr+0xf8/0x11a
 [<ffffffff8125b09d>] thread_return+0x0/0xd8
 [<ffffffff8102e012>] update_curr+0xf8/0x11a
 [<ffffffff8125fb0f>] kprobe_flush_task+0x5d/0x9f
 [<ffffffff8125b11a>] thread_return+0x7d/0xd8
 [<ffffffff8105541c>] __link_module+0x0/0x19
 [<ffffffff81033355>] __cond_resched+0x2d/0x55
 [<ffffffff8125b1ec>] cond_resched+0x2e/0x39
 [<ffffffff8125b23f>] wait_for_completion+0x30/0xb3
 [<ffffffff8105541c>] __link_module+0x0/0x19
 [<ffffffff81056e09>] sys_init_module+0x15d5/0x173a
 [<ffffffff8100bd45>] tracesys+0xd5/0xda

Follow on to previous post...

The updated pciedemo.c code did not configure the IB BARn registers at 0x21800300 as expected. The registers remained '0x0'. Are you testing with a 64-bit kernel?

I've made some modifications to the code by casting the IB BARn virtual addresses and offsets to 64-bit unsigned integer. This modification resolved the DSP register writes and IB BARn get configured as expected. I have not yet made the corresponding modifications to the pushData() and WriteDSPMemory() functions. I suspect these have similar casting issues.

Regards,

James

James,

From log "Total 4 sections, 0xd420 bytes of data written to core 0".  I knew there are 4 sections in pcieDdrInit.h:

Section: 1, size: 0xd0e0 bytes, start address: 0x10820000
Section: 2, size: 0x158 bytes, start address: 0x10830b08
Section: 3, size: 0x1c8 bytes, start address: 0x10830800
Section: 4, size: 0x20 bytes, start address: 0x10830ae8

Can you open the pcieDdrInit.h with a text editor, then at the second to the last line you should see:

 0x00, 0x00, 0x00, 0x20, 0x10, 0x83, 0x0A, 0xE8, 0x10, 0x82, 0x0D, 0xBA, 0x10, 0x82, 0x0D, 0xC4, 0x10, 0x82, 0x0D, 0xCA, 0x10, 0x82, 0x0D, 0xD0,
0x10, 0x82, 0x0D, 0xD6, 0x10, 0x82, 0x0D, 0xE0, 0x10, 0x82, 0x0D, 0xE6, 0x10, 0x82, 0x0D, 0xEC, 0x00, 0x00, 0x00, 0x00,

The first 4-byte is just 0x20, the next 4-byte is 0x10830ae8 (the start address). The rest are just data. Can you verify via emulator that those data are correctly wriiten to core 0 starting address: 0x10830ae8?

If so, can you check magic address 0x1087fffc via emulator, is that written to 0x1082c8e0 (the boot entry address)? did we fail at this point?

"Unable to handle kernel paging request at ffffc2000187fff8 RIP:
 [<ffffffff883a938b>] :pciedemo:WriteDSPMemory+0x101/0x142"

Regards, Eric

My test was on a 32-bit Linux kernel. Thanks for letting us know you findings, waiting for more insights from you, sorry I don't have a 64-bit machine to test.

Regards, Eric

I've gotten farther beyond configuring the IB BARn registers. I've updated all I/O memory access to use addresses and offsets that are cast to resource_size_t. Emulator confirms that ddrInitCode data is written to core 0 starting at address 0x10830ae8 and magic address 0x1087fffc contains 0x1082c8e0 (the boot entry address).

However, nothing indicates that the helloWorld demo application got executed (no serial port output). The DDR init did not clear the magic address as expected, so the kernel module kept polling forever until I cleared the magic address using the emulator.

I attempted to run the POST demo and it didn't execute as well.

Is the pciedemo tailored specifically for 6678? I noticed in the code that it tries to write the helloWorld image to core 9, but we are using the 4-core 6670. Is the magic address the same for 6670? Any ideas on porting it for 6670, if necessary, is greatly appreciated.

Regards, James

James,

Ideally, the MAGIC_ADDRESS would be the last 32-bit word of local L2, thus you can use the whole memory region continously. For 6678, this is 0x87fffc. For 6670, this is 0x8ffffc.

However, we only tested PCIE boot on c6678. The two projects: pcieboot_ddrinit and pcieboot_helloworld are built with "EVMC6678L".

1) the ibl code (mcsdk_2_00_00_11\tools\boot_loader\ibl\src\device\c66x\c66xinit.c) only monitors address 0x87fffc, no matter it is a 6670 or 6678 DSP.

2) after Linux host load pciedboot_ddrinit code into local L2 (you verified) and boot entry address into 0x87fffc. IBL code should be able to find 0x87fffc is non-zero and the program jump to the 0x1082c8e0 to execute the ddrinit program.

3) the ddrinit program will clear 0x87fffc first and monitor it. After you load helloworld code and write the 0x87fffc with new boot entry address, the program will jump again to execute the helloworld and print info on serical port.

This sequence should work in 6670 as well if we used 0x87fffc thoroughly, although it causes a memory gap there (you can't load a program across 0x87fffc). If you wanted to change MAGIC_ADDRESS to 0x8ffffc for 6670, then you need to change the ibl code, re-comile, and change both projects with EVMC6670L in define and re-compile. 

Since the boot failed in your 6670, several things to check in sequence:

1) if PCIE registers correctly configured =======> I think it is OK now

2) if the ddrinit code properly load into L2=======> I think it is OK now, but you can dump them to compare: A) RESET DSP, load pcieboot_ddrinit_evm6678l.out file with CCS and save the memory of the 4 regions B) reset DSP, let Linux host to load the .h file and save the same memory regions C) diff between A) and B), they should be the same, otherwise the Linux loader has a problem.

3) is the IBL code working properly? Please note the IBL code is running in local L2 (the memory region 0x0080xxxx) to monitor the 0x87fffc.  Did you run some other programs in local L2 which may swipe out the IBL code?

Regards, Eric  

Eric,

The following is our testing to confirm correct operations per your suggestions.

Test configuration:
Linux 64-bit
EVM6670L with lastest IBL (i2crom_0x51_c6678_le.dat) programmed in EEPROM

1) confirmed PCIe registers properly configured

2) compared runs using CCS and Linux loader and confirmed DDR init code in all 4 sections properly loaded into DSP memory (starting at 0x10820000)

3) IBL does not appear to be running correctly. DDR init boot entry address is written to the MAGIC ADDR 0x87fffc, but it never gets cleared. We also tested using the c6670 version of IBL and got the same results.

James,

Thanks for the testing. I will find a 6670L card and try next Monday.

Regards, Eric

James,

I am testing a C6670 card. After the PCIE enumeration, the PC register is at 0x0080075A, this is the IBL code waitForBoot() at mcsdk_2_00_00_11\tools\boot_loader\ibl\src\device\c66xc66xinit.c. This should work by jumping to the boot entry address when written into MAGIC_ADDRESS.

Is your PC at this address? If not, where is it? You can build the IBL by following the mcsdk_2_00_00_11\tools\boot_loader\ibl\doc\build_instructions.txt. A file called ibl_c66x_init.le.out will be generated under mcsdk_2_00_00_11\tools\boot_loader\ibl\src\make\ibl_c66x. Then you can load the symbol into DSP to see where the code stops. I can upload this out file to you if needed. 

I had other troubles on 6670 card which is preventing me from testing whether the PCIE demo can work or not. Since you verified that enumration is OK, host loader is OK. The problem is in IBL, it didn't jump. Hope you can move forward by checking where PC is. In the meantime, I am working on the PCIE boot verification on 6670.

Regards, Eric 

Eric,

Yes, after the PCIE enumeration the PC register is at 0x0080075A.  

Regrads, James

James,

You are right. After 6670 loaded with the ddrInit code by host, it stuck at platform_init() function for CSL_SGMII_getStatus() before clearing the MAGIC_ADDRESS to 0, the PC pointer is at 0x108264xx. Sorry, we didn't try this before and thought the same 6678 code can work for 6670. I will check when we plan to add 6670 PCIE boot demo into MCSDK.

Here is my suggestion you can try,
1) in the c66xinit.c, change #define MAGIC_ADDR (*(volatile unsigned int *)0x87fffc) to 0x8ffffc for 6670, re-build IBL for 6670
2) re-program IBL and IBL configuration table for 6670
3) rebuild ddrInit and hello world by changing Predefined Symbols from "_EVMC6678L_" to "_EVMC6670L_", and re-generate .h files to be loaded by host PC

Let me know if you need further help on this topic.

Regards, Eric

Eric,

Thanks for your confirmation. I will attempt to rebuild IBL, ddrInit, and helloWorld for 6670. Unfortunately, we are have issues using the Windows GNU tools MinGW installer to rebuild IBL. Could be a firewall issue, so will be trying to install manually.

On a side note, could you tell me what version of Fedora you used to validate the code?

Regards, James

James,

The machine we tested is a 32-bit Ubuntu 10.04, Linux  version 2.6.32-28.

Regards, Eric

James,

I successfully booted the "hello world" and "post" demo via 6670 PCIE. We will add the 6670 PCIE boot package in the next MCSDK release. Did you make that work already? I found there is another change needed in c66xinit.c  

1) DEVICE_REG32_W ((PCIE_BASE_ADDR + PCIE_BAR1), 0x0007FFFF); ==========> to 0x000FFFFF;    //1M LL2,   6670 has 1M LL2 and we need to access the address 0x8ffffc, so this mask need to change
2) DEVICE_REG32_W ((PCIE_BASE_ADDR + PCIE_BAR2), 0x003FFFFF);===========>to 0x001FFFFF;    //2M Shared L2

Maybe you already figured those out. Anyway, let me know you progress and if need further help. My test was done on 32-bit Ubuntu.

Regards, Eric

Eric,

Appreciate the looking into the fix for 6670 PCIe. Is the next MCSDK release coming soon? Any chance we can get a patch sooner than later? I don't have the ability to patch IBL since our firewall is blocking our ability to download the required packages to rebuild it.

Also, could you identify the expected changes to the package? Will it include support for 64-bit kernel?

Regards,  James

James,

Next release is around August 18, we are trying to put 6670 PCIE boot exmaples there. The changes should be very minor, it is unlikely 64-bit Linux can be supported.

Regards, Eric