Unable to read firmware registers on crash?

[Michal Kazior]

On 3 February 2015 at 14:57, Ben Greear <greearb at candelatech.com> wrote:
> On 02/02/2015 10:31 PM, Michal Kazior wrote:
>> On 2 February 2015 at 18:03, Ben Greear <greearb at candelatech.com> wrote:
[...]
>>> If I were to use MMIO, what sort of things could I get
>>> access to?  Just registers you think?  I might could tweak
>>> the firmware assert routine to scribble the crash register
>>> contents into a specific place, perhaps a bit at a time
>>> so that the host could read it if normal crash dump read
>>> fails?
>>
>> I was thinking that instead of doing a while (1) {} loop towards the
>> end of the assert routine you could instead put a busy loop and
>> introduce a simple interaction within it via a bunch of MMIO registers
>> that are software writable (e.g. scratch registers) and aren't used by
>> the MAC related hw. With that you could have a fallback way to
>> "stream" the crash dump data by putting each data word in a register
>> at a time and host ACKing each one.
>
> That sounds reasonable.  Do you know of any example code that accesses
> a target register or two with the MMIO logic on the host?  I think firmware
> has some examples of how
> to fiddle with registers, so I think I can make a stab at that part....

>From what I understand the MMIO space is shared between host and
target program so there's no need for any special handling. You can
look for FW_IND_EVENT_PENDING and FW_INDICATOR_ADDRESS usage both in
firmware and ath10k - it's already used to notify host about a crash.
It should be pretty straightforward. The indicator address itself
seems to be a scratch register already and there are a few more so you
should be able to design a ping-pong protocol to pass data.


Michał