am335x resume from suspend.

Hi Kenneth,

Have you seen section 8.1.4.3.4 in the AM335X TRM Rev. J?

if you mean this section.

"Upon wakeup, the boot ROM executes and checks to see if it has resumed from a DeepSleep0 state. If so, it

redirects to the DDR to continue the resume process."

So that paragraph is wrong. as far as I understand the ROM code is not taking the DRAM out of self refresh mode. if it does why are there code in the linux side that does it again.

and why is the code in linux storing a pointer to am33xx_resume_from_deep_sleep() in ipc register 0. this is the address of the copied code that is in sram not the version in DRAM.

so it looks like the ROM code reads out ipc.reg0 and jumps there.

problem is this is not even hinted in the manual. nothing mention that the resume address is in ipc reg 0.

and the code in the M3 is never even reading ipc reg 0 ever so the only conclusion I can make is that its the ROM code that do it but that should really be documented somewhere.

Can you explain what is the purpose of this investigation, perhaps then we can better help you.

I'm trying to make suspend/resume work on a custom board and it helps if I can first understand how it is supposed to work but the documentation is a bit hard to understand as it is mixing hardware/ROM behavior with what is coded in software in the M3 and and Ti linux patches. 

So it's not entirely clear what the chip is actually doing and what we can change with software. the resume path is more or less not described at all and what we have is misleading.

Can you describe the hardware - there may be a hardware issue. Are you using DDR3?

it might be but I would prefer if we could concentrate on the question as that is something that is not described in the documentation. 

basically what do the ROM code look at when it decides what to do. There is description of this for power on and how it selects boot device but it's not clear how it decides that its not a normal boot and that it should use the ipc.reg0 as a start vector. I guess this is what it does as things stops working if ipc.reg0 is empty and I cant find anything in the M3 code that actually even reads ipc.reg0 so it has to be some code somewhere else.

The ROM code is not publicly disclosed. The Cortex-M3 firmware that comes with the TI distributed Linux EZSDK is responsible for low-power modes management. There have been no issues reported with this. There have been quite a few suspend/resume problems that have come up on this forum and they all had to do with hardware problems around the external memory, which has to be put in self-refresh during suspend. This is the reason I am asking about hardware.

I just want the behavior to be explained. what if I was doing this for another OS and not on linux where it already works in the SDK that TI deliver. how would that be done when parts of the sequence is not documented.

I have asked the factory team to provide further information if available. Response may be delayed due to holiday in the USA.

Hi Kenneth,

The factory team suggested this wiki page for more details: http://processors.wiki.ti.com/index.php/AM335x_StarterWare_Power_management

So its not really that clear. ipc.reg0 is at least mentioned to contain the A8 resume address. the fact that this seems to be used by the ROM code and not the M3 code is not mentioned.

I'm not so concerned with what the linux part and m3 part is doing as we have code for that, its the stuff the chip does itself automatically and I include the ROM code here that needs to be documented.

ROM code is TI internal information and is not disclosed.

again I'm not asking for the code but what it does do. Surely the function can't be secret as its included in every chip you deliver. large part of what it does is described just not how it relates to resuming from suspend. don't see any reason to not described this other than it simply got missed during the documentation review process.

Kenneth,

I have asked the factory team for support on this and today I have posted the link they gave me. I am sorry, but there is nothing more I can do to support this thread. If you require further support please contact your local TI representative.

yes the Figure 26-27. explains this.