MPC8358 Console problem

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

MPC8358 Console problem

Jump to solution
1,228 Views
rade
Contributor I

Hallo,

We have been designed, five years ago, a board with MPC8358ECVVAGDGA and Linux 2.6.11 with ADEOS support.  The latest boards from production we"ve got with  MPC8358CVVAGDGA device (no E option for security engine and actually we do not using it) and board works fine in terms of real time requirements etc. The difference between old and new cards is that after a booting the kernel, console port goes off. The latest message we can see at console port comes from U-boot, Uncomperssing Linux kernel .... and that's all. After that console port does not respond. So, if anybody have idea what went wrong or have a clue about where we can try to find a solution it will help us a lot. Thanks in advance.

Best Regards

Rade Radjenovic

0 Kudos
Reply
1 Solution
1,068 Views
alexander_yakov
NXP Employee
NXP Employee

Moving from "E" to non-"E" device should not be a reason, if you are not using encryption block, that is correct. However, you should keep in mind - non-"E" device has another set of SVR/PVR identification values, so if Linux kernel verify these values at startup (it definitely does that) and this part of code is not designed to support non-"E" device, than any erratic behavior may occur.

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

View solution in original post

2 Replies
1,069 Views
alexander_yakov
NXP Employee
NXP Employee

Moving from "E" to non-"E" device should not be a reason, if you are not using encryption block, that is correct. However, you should keep in mind - non-"E" device has another set of SVR/PVR identification values, so if Linux kernel verify these values at startup (it definitely does that) and this part of code is not designed to support non-"E" device, than any erratic behavior may occur.

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

1,068 Views
rade
Contributor I

Hi Alexander,

Thanks for the tip. Yes,problem was with SVR value. Actually in file mpc83xx_sys.c there is structure ppc_sys_specs[] which defines different platforms. I order to support our platform we defined

...

#if defined(CONFIG_IRITEL8358)

  {

  .ppc_sys_name = "8358E",

  .mask = 0xFFFF0000,

  .value = 0x80480000,

  .num_devices = 8,

  .device_list = (enum ppc_sys_devices[])

  {

  MPC83xx_QE_UCC3,

  MPC83xx_QE_SPI1, MPC83xx_QE_SPI2,MPC83xx_QE_USB,MPC83xx_QE_PTP,

  MPC83xx_IIC1, MPC83xx_IIC2, MPC83xx_DUART,

  },

...

Board with device without E, fails to initialize because .value from our definition does not comply with actual SVR value which is  0x80490000.

So after adding a new structure member

  {

  .ppc_sys_name = "8358",

  .mask = 0xFFFF0000,

  .value = 0x80490000,

  .num_devices = 8,

  .device_list = (enum ppc_sys_devices[])

  {

  MPC83xx_QE_UCC3,

  MPC83xx_QE_SPI1, MPC83xx_QE_SPI2,MPC83xx_QE_USB,MPC83xx_QE_PTP,

  MPC83xx_IIC1, MPC83xx_IIC2, MPC83xx_DUART,

  },

console works fine.

So, thanks again for the help.

BR

Rade

0 Kudos
Reply