AM6548: AM6548 SR2.0 Unhandled Exception from EL1

Hi Ben,

In many cases, this type of errors are caused by kernel accessing a hardware module which is not powered on or clock gated.

Do you see this issue when you boot the IDK EVM with the default SD card image provided in the processor SDK?

Hi Bin,

I actually nailed it down to the mcu_cpsw module, if I disable it, I am able to boot into my kernel! Which is strange, because I thought there were no differences between the CPSW in SR1.0 and SR2.0. 

When looking at the device tree for the Linux PDK version 08_02_00_02, I see that the mcu_cpsw is configured differently than my device tree (I think it is from an older version of the Linux PDK). 

I tried copy and pasting the configurations from 08_02_00_02, but those do not seem to work. Are there any other differences in CPSW configuration I should be aware of between silicon revisions?

What is interesting is within U-boot the CPSW is 100% working, it is how I actually load software onto the IDK (over TFTP), so not sure why it is causing issues in the kernel. 

Hi Ben,

I am routing your query to our Network expert for comments.

Hi,

I will check into SR issue that you are seeing and get back to you. Probably late tomorrow central US time.

Best Regards,

Schuyler

Hi Schuyler, just checking in, are there any updates to this?

What is your overall goal, are you writing a custom kernel? Something close to Linux but not exactly Linux? What is your boot sequence and boot mode and what versions of software from TI is this based on?

My general suggestion is to take the latest SDK (9.1) uboot, and port your modifications incrementally there.

  Pekka

Hi Pekka, no this is not a custom kernel, it is VxWorks, so something pretty close to Linux. My boot sequence is very similar to Linux, in that I am using U-boot to upload software and then boot into the kernel.

As to what versions of TI software this is based on, I am not sure, but I know it is before 08_02_00_02, as the device tree data is different.

My goal is to just be able to initialize the CPSW ethernet in kernel space, and as to the SDK U-boot, I actually already am using the U-boot version 08_02_00_02 from TI mostly unmodified, and the ethernet works within U-boot, it is just in the kernel space that I am having this exception.

I can post the device tree configuration of the CPSW here if that is helpful.  

So you are using https://bsp.windriver.com/bsps/3358 ? To my knowledge that should work including CPSW. Did you contact them? Or are you trying to add something beyond what VxWorks supports?

Currently using 22.09, I did contact VxWorks support, and they said they currently do not support SR2.0 (which the IDK EVM includes)

Does 23.03 have support for CPSW? 

I guess the part that confuses me the most is that the CPSW should not be different from SR1.0 to SR2.0 (based on previous errata I have read, I could be wrong), so why would it break like this?

I do not think this is something beyond what VxWorks supports, I am not trying to enable the ICSSG or anything. 

The VxWorks customers on AM65x that I'm aware of are using exclusively the latest silicon revision (2.1) which is the only one we also support. And they use CPSW. I agree superficially there is now major change but looking at the errata https://www.ti.com/lit/pdf/sprz452 I see several CPSW errata fixes and also UDMA-P fixes that are critical to the product quality operation. Investigating why something worked with old SW and old silicon, is wasted effort, the 2.1 is the only silicon supported.

Are you able to disclose what version of VxWorks your customers are using? Is it 23.03?

I've asked a Wind River contact to comment here. But I'd recommend contacting them again to clarify, SR2.1 is the only silicon supported in production.

Hello Pekka,

I'm involved with two projects using AM6548 on VxWorks, both of which are using SR2.x.  One is on an older version of VxWorks, SR0660, and the other is on 23.09.  Both include support for CPSW as standard.  I believe 24.03 will "officially" support SR 2.x, though I don't know specifically what will change in that release.

With reference to the original question: I'm aware of a problem with support for CPSW IEEE1588 which can cause VxWorks to fail to start properly.  Disabling the CPSW IEEE1588 node (cpts) from the device tree works around that problem.

Ian

Thank you for the insight Ian! Unfortunately this still appears to not be working for me, how exactly did you disable the CPTS node? I am trying to disable it within k3-am654-base-board.dts by changing the mcu_cpsw device from:

&mcu_cpsw {

	pinctrl-names = "default";
	pinctrl-0 = <&mcu_cpsw_pins_default &mcu_mdio_pins_default>;

	cpts {
		ti,pps = <3 1>;
	};
};

to

&mcu_cpsw {

	pinctrl-names = "default";
	pinctrl-0 = <&mcu_cpsw_pins_default &mcu_mdio_pins_default>;

	cpts {
		status = "disabled";
	};
};

But I still get that EL1 exception, do I also need to disable it within the U-boot device tree as well? I am not an expert in device trees so I may be missing exactly what I need to do to disable this component. 

Ian Willats said:

CPSW IEEE1588 which can cause VxWorks to fail to start properly.

Ian, is this issue something that happens sometimes or always? Benjamin is your EL1 exception 100% reproducible type issue, every boot?

Overall I would say use the VxWorks that supports the silicon we support (2.1). We support the bootloaders in https://www.ti.com/tool/PROCESSOR-SDK-AM65X , modified bootloaders and other OSes are not generally supported by TI. If you need custom support or something beyond I suggest start with the field team (FAE or sales) you are working with.

If CPSW is enabled, this issue is reproduceable every boot. 

Even if I disable CPTS, or just flat out delete it from the device tree. It seems to me that only disabling mcu_cpsw allows VxWorks to boot. 

Ian Willats said:

I believe 24.03 will "officially" support SR 2.x,

I would suggest you get 24.03 (or whatever version VxWorks says) if you want to run VxWorks on 2.1.