[EHL] CAN0 TX work, RX doesn't work in ubuntu22. about slimbootloader HOT 24 CLOSED

EHL as RX:

EHL as TX:

The signal are captured between CAN device and EHL, channel 3 is RX, channel 4 is TX.

from slimbootloader.

probe and enable process:

[   78.488558] m_can_pci_probe
[   78.489344] m_can_class_register
[   78.489349] m_can_dev_setup
[   78.489360] m_can_read reg:0x0, val:0x32150323
[   78.489376] m_can_read reg:0x18, val:0x0
[   78.489378] m_can_write:0x18,val:0x1
[   78.489386] m_can_write:0x18,val:0x3
[   78.489389] value:0x3
[   78.489391] m_can_read reg:0x18, val:0x3
[   78.489398] m_can_pci 0000:00:18.1 (unnamed net_device) (uninitialized): m_can_config_endisable success
[   78.489415] m_can_read reg:0x18, val:0x3
[   78.489417] m_can_write:0x18,val:0x8003
[   78.489429] m_can_read reg:0x18, val:0x8003
[   78.489431] m_can_write:0x18,val:0x3
[   78.489442] m_can_read reg:0x18, val:0x3
[   78.489444] m_can_write:0x18,val:0x0
[   78.489446] value:0x0
[   78.489456] m_can_read reg:0x18, val:0x0
[   78.489458] m_can_pci 0000:00:18.1 (unnamed net_device) (uninitialized): m_can_config_endisable success
[   78.489463] register_candev
[   78.489474] register_netdevice:can%d
[   78.489781] m_can_read reg:0x40, val:0x0
[   78.489811] m_can_pci 0000:00:18.1: m_can device registered (irq=221, version=32)
[   78.527578] m_can_read reg:0x40, val:0x0
[   78.528219] m_can_read reg:0x40, val:0x0
[  109.043026] m_can_read reg:0x40, val:0x0
[  138.087046] m_can_read reg:0x40, val:0x0
[  138.116198] m_can_read reg:0x40, val:0x0
[  138.137610] m_can_read reg:0x40, val:0x0
[  138.143567] m_can_read reg:0x40, val:0x0
[  138.154529] m_can_open
[  138.154538] open_candev
[  138.154645] request_irq name:can0, irq:221 ret:0
[  138.154648] m_can_chip_config
[  138.155432] m_can_read reg:0x18, val:0x0
[  138.155435] m_can_write:0x18,val:0x1
[  138.155442] m_can_write:0x18,val:0x3
[  138.155444] value:0x3
[  138.155447] m_can_read reg:0x18, val:0x1
[  138.155458] m_can_read reg:0x18, val:0x1
[  138.155470] m_can_read reg:0x18, val:0x1
[  138.155482] m_can_read reg:0x18, val:0x1
[  138.155494] m_can_read reg:0x18, val:0x1
[  138.155506] m_can_read reg:0x18, val:0x1
[  138.155518] m_can_read reg:0x18, val:0x1
[  138.155530] m_can_read reg:0x18, val:0x1
[  138.155541] m_can_read reg:0x18, val:0x1
[  138.155553] m_can_read reg:0x18, val:0x1
[  138.155566] m_can_read reg:0x18, val:0x1
[  138.155570] m_can_pci 0000:00:18.1 can0: Failed to init module
[  138.155575] m_can_write:0xbc,val:0x777
[  138.155577] m_can_write:0x80,val:0x0
[  138.155578] m_can_write:0xc0,val:0x10003080
[  138.155580] m_can_write:0xc8,val:0x7
[  138.155581] m_can_write:0xf0,val:0x103000
[  138.155583] m_can_write:0xa0,val:0x400c00
[  138.155585] m_can_write:0xb0,val:0x1e00
[  138.155587] m_can_read reg:0x18, val:0x1
[  138.155589] m_can_read reg:0x10, val:0x80
[  138.155590] can.ctrlmode: 0x0
[  138.155592] m_can_write:0x18,val:0x1
[  138.155593] m_can_write:0x10,val:0x80
[  138.155594] m_can_write:0x50,val:0xffffffff
[  138.155596] m_can_write:0x54,val:0xe7ffffff
[  138.155598] m_can_write:0x58,val:0x0
[  138.155599] m_can_write:0x1c,val:0x9ad18
[  138.155601] m_can_write:0x20,val:0xf0001
[  138.155603] m_can_read reg:0x18, val:0x1
[  138.155604] m_can_write:0x18,val:0x0
[  138.155606] value:0x0
[  138.155614] m_can_read reg:0x18, val:0x0
[  138.155616] m_can_pci 0000:00:18.1 can0: m_can_config_endisable success
[  138.155618] m_can_chip_config done.-----
[  138.155619] m_can_start ok
[  138.155620] m_can_write:0x5c,val:0x1
[  138.155622] after netif_start_queue
[  138.155665] m_can_read reg:0x40, val:0x0
[  138.155712] IPv6: ADDRCONF(NETDEV_CHANGE): can0: link becomes ready
[  138.155730] m_can_read reg:0x40, val:0x0

from slimbootloader.

Hi Chrysler,

Please check if you have the following override in CfgData_Silicon.yaml or your DLT. If so, please remove your override (i.e., these settings, if enabled, conflict with CAN0)
1. PchPseI2sEnable[0] >= 1
2. PchPseTimedGpioPinEnable[16] = 1
3. PchPseTimedGpioPinEnable[17] = 1
4. PchPseI2cEnable[7] = 2

Linux kernel config should have the settings enabled (note: some might be not required by your product, if so, please ignore it): CONFIG_CAN, CONFIG_CAN_RAW, CONFIG_CAN_BCM, CONFIG_CAN_GW, CONFIG_CAN_DEV, CONFIG_CAN_CALC_BITTIMING, CONFIG_CAN_M_CAN, CONFIG_CAN_M_CAN_PCI, CONFIG_CAN_M_CAN_PLATFORM

In addition, can you check the SBL console log with FSP Debug enabled and focus on the following setting?
(note, the order in the log below might be different)
------------------ PSE Config ------------------
CAN0 Enabled = (check it)
Pin muxing:
Rx = (check it)
Tx = (check it)
...
TGpio_16 Enable = 0 (should be zero)
TGpio_17 Enable = 0 (should be zero)
...
I2S0 Enable = 0 (should be zero)
...
I2C7 Enable = (should not be 2)

from slimbootloader.

Hi Stanley,

  Thanks for your reply. 
  There is a config as you mentioned, PchPseI2cEnable[7] = 2 is modified by us in *.dlt file.

  SILICON_CFG_DATA.PchPseI2cEnable  | { 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02 }

  So I change this line to :
  SILICON_CFG_DATA.PchPseI2cEnable  | { 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }
  
  But the pci device "00:18.1 CANBUS: Intel Corporation Device 4bc1 (rev 11)" will not be found by OS. Thus, not able to access CAN0. 
  If PchPseI2cEnable[7] = 2, then 4bc1 can be found. This might be the conflict point.

  I also checked the kernel config file, 
  except CONFIG_CAN_CALC_BITTIMING = y, all others you mentioned are configured as "m".

  Here is the output with debug fsp, PchPseI2cEnable[7] = 0.
 
     SPI3 DelayRxClk = 0
     ADC Enable     = 0
     CAN0 Enable     = 2
     Pin muxing:
       Rx = No muxing
       Tx = No muxing
    ...
   TGpio_16 Enable = 0
   TGpio_17 Enable = 0
   TGpio_18 Enable = 0
   TGpio_19 Enable = 0
   ... 
   I2S0 Enable     = 0
    Pin muxing:
      Rx = GPIO_GPP_E15
      Tx = GPIO_GPP_E16
   ...
    I2C7 Enable     = 0
  Pin muxing:
    Sda = No muxing
    Scl = No muxing

By the way,

I2C 7 is 4BC0, and is the first function of device 24, if it is not enabled, then pci will skip the whole device. So 4BC1 is skipped.

from slimbootloader.

Hi Chrysler,

You are right, I read again the related source, and confirm PchPseI2cEnable[7] must be 2, if CAN0 wants to owned by host.
From your log, it is possibly the issue is caused by CAN0's pin mux. Please configure GPP_E15 and GPP_E16 to Native Function 7.

from slimbootloader.

Hi Stanley,

I'm not sure if I make the correct change:
I add below code to my *.dlt file:
GPIO_CFG_DATA.GpioPinConfig0_GPP_E15.GPIOPADMode_GPP_E15 | 0xF
GPIO_CFG_DATA.GpioPinConfig0_GPP_E16.GPIOPADMode_GPP_E16 | 0xF

But the output of debug FSP is the same as before.
Would you please help me about the modification?

from slimbootloader.

Hi,

The GPIO configuration is out of Debug FSP, so it will not be shown in the log -- it is okay.
However, you should add other properties, e.g., GPIOHostSoftPadOwn (GpioHostOwnGpio), GPIOInterruptConfig (GpioIntDis), GpioHostDeepReset, GpioTermNone, ...

from slimbootloader.

Hi Stanley,

 Thank you. I find I can change these settings in configEditor. I will try to update these configurations tomorrow.

from slimbootloader.

Hi Stanley,

 I tried many combinations of the GPIO configuration, but still can not receive from PSE_CAN0_RX(candump can0). Through PSE_CAN0_TX, data can be sent out. I check the waveform, they are the same as the picture I posted before.

My configuration for E15 and E16 are as below:

GPIO_CFG_DATA.GpioPinConfig0_GPP_E15.GPIOPADMode_GPP_E15 | 15
GPIO_CFG_DATA.GpioPinConfig0_GPP_E15.GPIOHostSoftPadOwn_GPP_E15 | 3
GPIO_CFG_DATA.GpioPinConfig0_GPP_E15.GPIODirection_GPP_E15 | 5
GPIO_CFG_DATA.GpioPinConfig1_GPP_E15.GPIOSkip_GPP_E15 | 0

GPIO_CFG_DATA.GpioPinConfig0_GPP_E16.GPIOPADMode_GPP_E16 | 15
GPIO_CFG_DATA.GpioPinConfig0_GPP_E16.GPIOHostSoftPadOwn_GPP_E16 | 3
GPIO_CFG_DATA.GpioPinConfig0_GPP_E16.GPIODirection_GPP_E16 | 11
GPIO_CFG_DATA.GpioPinConfig0_GPP_E16.GPIOOutputState_GPP_E16 | 3
GPIO_CFG_DATA.GpioPinConfig0_GPP_E16.GPIOInterruptConfig_GPP_E16 | 33
GPIO_CFG_DATA.GpioPinConfig1_GPP_E16.GPIOSkip_GPP_E16 | 0

from slimbootloader.

Hi,

May you add the following definitions in Silicon/ElkhartlakePkg/Include/Register/GpioPinsVer3.h ?

#define GPIO_VER3_GPP_E15 0x0B10000F
#define GPIO_VER3_GPP_E16 0x0B100010

Which payload does the SBL use? OS Loader or UEFI Payload?

from slimbootloader.

Hi,

I use UEFI payload.

from slimbootloader.

Hi,

You can check the GPP E15 configuration under UEFI shell by,
mm FD6A0B60 -w 4 -mmio # it is for DW0
mm FD6A0B64 -w 4 -mmio # DW1
Please focus on DW0[13:10], which should be 7 (for native function 7)

Also, check GPP E16 (FD6A0B70 and FD6A0B74) in the same way.

from slimbootloader.

Hi,

mm FD6A0B60 -w 4 -mmio
MMIO 0x00000000FD6A0B60 : 0x44001E00 >
mm FD6A0B64 -w 4 -mmio
MMIO 0x00000000FD6A0B64 : 0x0000003B >
mm FD6A0B70 -w 4 -mmio
MMIO 0x00000000FD6A0B70 : 0x40001D03 >
mm FD6A0B74 -w 4 -mmio
MMIO 0x00000000FD6A0B74 : 0x0000003C >

from slimbootloader.

Hi Chrysler,

It looks good. Please file an IPS (Intel® Premier Support) case to get help from our PSE expert with the info attached.

1. full Debug FSP log (with GPIO change made)
2. Linux kernel config
3. your test results

from slimbootloader.

Hi Stanley,

Thank you very much. I will try to do that.

from slimbootloader.

Hi Chrysler,

One more question, in your FSP Debug log, can you see any log starting with "PSE CAN", e.g., "PSE CAN 0 IP set to Host owned" ? If so, please show all logs starting with "PSE CAN"

from slimbootloader.

Hi Stanley,

Here's the log:
7966: PSE CAN0 pins set to Native Mode
7969: PSE CAN 0 IP set to HS owned
7970: PSE CAN 0 interrupt set to S
7971: PSE CAN 1 IP set to NN owned
9011: Set BME for PSE CAN0 and CAN1 devices

from slimbootloader.

Hi Chrysler,

For now, I cannot find other problems from the bootloader side,. Hope PSE expert can give you more help.

In Linux, can you see the can0's PCI device is bound with a driver (e.g., check with "lspci -k")?
Also, you mentioned about TX working, does it mean your external CAN device can successfully read a message from Linux sender?

from slimbootloader.

Hi Stanley,

CAN0 is bound with m_can_pci.
Yes, from linux, I use "cansend can0 123#0102030405060708“ to send message to external CAN device.

I will update this thread if any news.

from slimbootloader.

Hi Chrysler,

Let me update 2 things, according to my test with EHL CRB:

1. no require to add the GPIO configuration. FSP, even no pinmux settings, will configure them correctly.
2. please remove SILICON_CFG_DATA.PchPseCanSbInterruptEnable | { 0x01, 0x00 } from your DLT.

When PchPseCanSbInterruptEnable[0] = 0 it is to set interrupt to MSI mode, which is supported by m_can_pci. Thus, the default MSI mode work well (at least, with your loopback test command).

from slimbootloader.

Hi Stanley,

Sorry for late reply. As you mentioned, I remove the interrupt setting in my DLT file (set PchPseCanSbInterruptEnable[0] = 0). The CAN0 works both in loopback mode and Normal TX/RX mode.

But the bitrate which I set in EHL is 1000 000, the receiver can only receive at 500 000. I will try to find the reason.

Thank you very much.

from slimbootloader.

Hi Chrysler,

Please ignore my previous comment about kernel patch (I have deleted it to prevent any misleading in the future).

According to the latest Linux kernel git history, the mentioned kernel patch was reverted. Thus, the default settings (here should be good.

from slimbootloader.

Hi Stanley,

I'm occupied with other work, I will contine to look into this after jobs done. Thank you very much for your help. Sure I will update this thread if any new.

I also received a patch from Fan1.He: https://github.com/intel-innersource/frameworks.industrial.edge-controls.layers.meta-intel-fieldbus/blob/master/meta-eci-fieldbus-common/recipes-kernel/linux/linux-intel-lts/patches/5.10-y/0001-Changing-the-reference-value-from-100Mhz-to-200Mhz.patch

But it is the same. Plan to look into m_can.c:m_can_set_bittiming(struct net_device *dev).

from slimbootloader.

Hi community,

I come to update the status. Our new board is working well with the CAN bus. I still don't find the reason for old board with 1M/500k speed issue.

Thanks Stanley very much for guiding me to find the correct CAN configuration.

"please remove SILICON_CFG_DATA.PchPseCanSbInterruptEnable | { 0x01, 0x00 } from your DLT."
above is the solution.

from slimbootloader.