[PATCH] i.MX: HABv4: Improve HAB event printing
robin
robin at protonic.nl
Tue Nov 24 04:34:42 EST 2020
On 2020-11-24 10:12, Sascha Hauer wrote:
> On Tue, Nov 24, 2020 at 09:32:14AM +0100, robin wrote:
>> Hi Sascha,
>>
>> On 2020-11-24 08:57, robin wrote:
>> > Hi Sascha,
>> >
>> > On 2020-11-23 17:38, Sascha Hauer wrote:
>> > > Instead of using a fixed sized buffer for the report_event function,
>> > > let's call it two times, once with a NULL pointer to get the size of
>> > > the
>> > > event and a second time with a buffer of that size.
>> > > Also, instead of separating the events into warning and error type,
>> > > iterate over all events in one single loop. This helps to get the
>> > > events
>> > > in the order they occured which probably helps the reader to make more
>> > > sense of them.
>> > >
>> > > Signed-off-by: Sascha Hauer <s.hauer at pengutronix.de>
>> >
>> > Even better!
>> >
>> > Is it worth mentioning that this also fixes the unjustified
>> > 'Recompile with larger event data buffer' error?
>> >
>> > Acked-by: Robin van der Gracht
>>
>> I just noticed your previous email. I'll test this today.
>
> Rouven just told me that testing this is actually very simple. I was
> was
> afraid I had to bring up a full HAB stack, but actually all I had to do
> is to enable HAB in barebox, start it on a non HAB enabled board and be
> done.
>
> Here's the output which looks sane to me:
>
> HABv4: Status: Operation failed (0x33)
> HABv4: Config: Non-secure IC (0xf0)
> HABv4: State: Non-secure state (0x66)
> HABv4: -------- HAB Event 0 --------
> HABv4: event data:
> HABv4: db 00 08 41 33 22 0a 00
>
> HABv4: Status: Operation failed (0x33)
> HABv4: Reason: Invalid address: access denied (0x22)
> HABv4: Context: Logged in hab_rvt.authenticate_image() (0x0a)
> HABv4: Engine: Select first compatible engine (0x00)
> HABv4: -------- HAB Event 1 --------
> HABv4: event data:
> HABv4: db 00 14 41 33 0c a0 00
> HABv4: 00 00 00 00 10 00 04 00
> HABv4: 00 00 00 20
> HABv4: Status: Operation failed (0x33)
> HABv4: Reason: Invalid assertion (0x0c)
> HABv4: Context: Event logged in hab_rvt.assert() (0xa0)
> HABv4: Engine: Select first compatible engine (0x00)
> HABv4: -------- HAB Event 2 --------
> HABv4: event data:
> HABv4: db 00 14 41 33 0c a0 00
> HABv4: 00 00 00 00 10 00 04 2c
> HABv4: 00 00 03 00
> HABv4: Status: Operation failed (0x33)
> HABv4: Reason: Invalid assertion (0x0c)
> HABv4: Context: Event logged in hab_rvt.assert() (0xa0)
> HABv4: Engine: Select first compatible engine (0x00)
> HABv4: -------- HAB Event 3 --------
> HABv4: event data:
> HABv4: db 00 14 41 33 0c a0 00
> HABv4: 00 00 00 00 10 00 04 20
> HABv4: 00 00 00 01
> HABv4: Status: Operation failed (0x33)
> HABv4: Reason: Invalid assertion (0x0c)
> HABv4: Context: Event logged in hab_rvt.assert() (0xa0)
> HABv4: Engine: Select first compatible engine (0x00)
> HABv4: -------- HAB Event 4 --------
> HABv4: event data:
> HABv4: db 00 14 41 33 0c a0 00
> HABv4: 00 00 00 00 10 00 10 00
> HABv4: 00 00 00 04
> HABv4: Status: Operation failed (0x33)
> HABv4: Reason: Invalid assertion (0x0c)
> HABv4: Context: Event logged in hab_rvt.assert() (0xa0)
> HABv4: Engine: Select first compatible engine (0x00)
>
> Anyway, it won't hurt when you give it a test as well.
I would have done the same test. So I think its OK like this. I just
realized I only have access to locked chips atm. so you testing this
is great :P.
I did run this on a locked unit (just to be sure) but no issues there.
Robin
More information about the barebox
mailing list