Re: [PATCH] i.MX: HABv4: Improve HAB event printing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx>
>
> 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

_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox



[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux