Reset A5 without interfering on M4

[bfac]

Hello!

Our customer has a somehow tricky question, I couldnt find an obvious answer:

Imagining the core configuration on the TWR card, where cortex A5 is master and M4 is slave.

Would it be possible to reset the operation of Cortex A5 (running Linux from external DDR), without interfering on the operation of Cortex M4 (running MQX from internal RAM) ?

Do you see a good approach to achieve that?

Thanks!

Bruno

[bfac]

Hello team!

Just for your review, after discussing this with customer, we got to the following architecture, our main concerns are: independent reset and watchdog behavior.

First some definitions:

1) A5 is the hardware master (pin configuration) and will run u-boot.

2) M4 is the operation master on software perspective though.

3) A5 runs Linux and M4 runs MQX.

4) If operation on A5 (Linux) freezes, but not on M4 (MQX), M4 should assert a soft reset on A5, without interfering with M4 operation.

5) If operation on M4 freezes, everything must reset asap, so a hardware reset should be asserted.

The watchdog implementation is being thought as:

1) The hardware watchdog is fed by M4 only, in case this core freezes, everything is reset.

2) M4 (MQX) will implement a software WTD to monitor A5 (Linux) operation, in case needed it will assert a soft reset on A5 operation only.

3) A5 will implement a software WTD feed function, probably over the MCC stack, to communicate with the SW WTD master MQX on M4.

The needed changes we see:

A) u-boot

     1) needs to change the way it initializes peripherals, it should not touch anything that is being used by M4. M4 peripheral initialization should be done my MQX only.

     2) should somehow identify if MQX is already running on M4, and in case it is running healthy, shouldn't touch anything related to it.

          2.1) In case M4 isn't already running MQX healthily, should proceed copying MQX image asap and starting that core operation.

     3) should normally initialize any peripherals that are in use only by A5 and Linux.

     4) should boot Linux and rootfs normally, being sure nothing affects M4 operation.

B) linux/rootfs

     1) should implement a SW WTD feed task, in order to communicate to SW master M4 it is running ok. To be done probably with MCC calls.

     2) should not touch any peripherals used by M4 and MQX.

C) MQX

     1) should initialize all the peripherals it needs, as u-boot / linux will not do it.

          1.1) need to understand having both cores initializing different peripherals at any given time can cause unexpected behaviors. Comments are very welcome.

     2) should implement a SW WTD function to receive WTD feeds from A5/Linux.

          2.1) In case A5 stops feeds, should proceed with a soft reset of A5 core.

          2.2) we still need to better understand, during a soft reset, what exact address the A5 Program Counter should point to inside u-boot, not sure if the very first address is the best idea. Comments are very welcome.

What do you think about this solution architecture?

Thanks!

Bruno

[ioseph_martinez]

Agree with Ross, especially on A 2.1)

I am not sure if you want A5 to mess with the M4. You already have a HW reset to handle a problem with the M4/MQX sub-system.

I would remove points 2 and 2.1 from the A proposal. The less you change U-boot to do specialized tasks the better to maintain.

Another comment on C:

Basically you will need to imitate ROM code, so copying the code will be needed and then having the A5 to jump to that location.

[bfac]

Thanks Ioseph, Ross!

But I didn't follow the comment on 2.1 (should be removed).

If u-boot does not start the MQX application, then how should we do to run it (MQX on M4) the first time?

Maybe have 2 different u-boot images on memory?

Tks!

Bruno

[ioseph_martinez]

Hi Bruno,

Yes you are right, at some point the A5 needs to start the M4 and that can be with uboot. I guess I forgot of that point.

I guess what confuses me is having the A5 as HW master but the M4 as system/software master. Adds a bit more complexity to the system.

One point different from MQX and Linux is (if I am not mistaken) MQX can boot without uboot, like a standalone application. So you could have the M4 to be master in HW and SW and boot MQX and just at the beginning start the A5 to run uboot and boot linux.

Ioseph

[dry]

Any reference to how you would do this, how would you first start MQX on M4 and then start Linux on A5?

My VF61 is configured to have A5 as primary core, so it starts with it and needs to kick-off the M4. I don't know if Bruno's configuration was same. Suppose it was. Then if I understand you correct,  one needs to boot MQX on A5 and kick start another MQX image on the M4. Then MQX on A5 needs to load Linux somehow, but as far as I know it can't load it directly. May be it can load U-boot image to RAM and run it.

Was that the idea ?

[RossMcLuckie]

Hi Bruno,

Guess this is both the positive and negative aspects of having a very open system, you can try to do pretty much what you want, but you have to make sure you do it correctly, lots of scope for problems.

I'm not really a software architect, so maybe get some more comments from some more software focuses people, but I've tried to add some pointers that might help.

For A -

Determining if M4 is running, should be plenty of options for that, check the status of the PC or clock gate registers, use one of the semaphores to indicate the M4 is running, memory location, etc, whether that is enough to indicate healthy is up to you, can look to do something like a handshake if you want a better check, or maybe not that important if the M4 will generate a hardware reset if it gets into trouble in any case, if just to avoid writing/initialising the M4 memory space then checking the clock gate status is probably enough.

For C -

Should be no issue both cores initialising separate peripherals in parallel, you could of course consider using semaphores if you want to add a little extra precaution.

For restarting uBoot/Linux you might need to check with some Linux guru's on those implications, but regards actually doing this you could read the IVT table for the specific address, or look to use the SRC general purpose registers to program/determine an appropriate software reset address, read the SRC and Boot chapters in the RM for further details.

Hope this helps.

Ross

[karina_valencia]

ioseph_martinez can you review this case and provide follow up?

[ioseph_martinez]

Bruno,

Since you are visiting the customer very soon (as you told me on a separated message) I will answer without the proper knowledge so the answer could be wrong:

I don't think you can "reset" as the term means (resetting peripherals, clocks, etc) a single core because everything is shared.

I think you should be able to control the operation of one core with another core, but I would need to confirm that.

Best Regards,

Ioseph

[anthony_huereca · Accepted solution]

Ioseph is correct. There is no independent core reset due to the complexity of everything being shared.

A semi-workaround would be to jump back to a specific address at the start of your code, but you would have to keep in mind that the clocks/registers/memory would already be all setup, and your code would need to handle that case.

[dry]

This thread is probably long forgotten... But how would you do this semi-workaround?  Resetting one core and kinda semi-resetting the other.