On Wed, Apr 13, 2016 at 1:44 PM, Grant Likely <grant.likely@linaro.org> wrote:

On Wed, Apr 13, 2016 at 4:18 AM, Marcin Juszkiewicz
<marcin.juszkiewicz@linaro.org> wrote:
> W dniu 13.04.2016 o 13:12, Thomas B. Rücker pisze:
>>
>> On 04/04/2016 12:28 PM, Thomas B. Rücker wrote:
>>>
>>> On 03/24/2016 01:43 PM, Thomas B. Rücker wrote:
>
>
>>>> So, LC BKK came and went, and now I'm back, sounding like a broken
>>>> record:
>>>>
>>>> - Compliance report: HiKey (CCo)
>>>> - Compliance report: HiKey (LeMaker)
>>>> - Compliance report: Dragonboard410c
>>>> - Compliance report: Bubblegum
>>>> - Compliance report: Cello
>>>> - Compliance report: Husky
>>>> - Compliance Check-List
>>>> - Other latest work (cf. mail on this list 2016-02-05T11:11)
>>>> - Anything of significance at LCBKK?
>
>
> I would love to see them too. And patches for mainline kernel too ;D

I would love to have them published also, but we're simply not there yet.

However, we've made a lot more progress than Thomas' comments give us
credit for. The latest reference platform build supports Dragonboard,
Hikey, as well as 5 EE boards, all with the same v4.4 kernel binary.
Production of a compliance test kit is in progress -- which includes a
test mezzanine adapter. Patches for Dragonboard and HiKey are flowing
into mainline.

On hikey we've got free software firmware right from
first instruction outside the masked rom (arm trusted firmware, UEFI,
and OP-TEE). And besides, we got 64-bit ARM hardware into the hands of
developers a year before any of the other platforms became available.

Very true. I think we can all be proud of the work that has been accomplished with HiKey especially ;) and I certainly hope that patches can flow upstream even faster ;)

This said, I really wish there were more reference documentation for the Hi6220 SoC. The publicly avaiable TRM [1] is severely lacking in many, many areas, including security (hardware crypto accelerator? TrustZone DRAM protection?). This is a big issue IMO. For instance, I recently discovered that the OP-TEE memory protection set in ARM-TF [2] can be reverted by non-secure kernel code :(

It is all the more problematic since it gives a false impression of security. When I wrote the code in [2] I had no reference manual at hand, and had to figure out a couple of things from a few lines of C code provided by some internal contact in Huawei. I did check that secure memory is not accessible from non-secure world once the DDR controller is set up. But, I wrongly assumed that the "DDRC security" registers could be accessed from secure world only -- alas, it's not the case, as a recent test proved. I have raised this issue in Huawei and I hope I can get a fix.

Bottom line: if by any mean you can get us a better TRM, please do ;)

[1] https://github.com/96boards/documentation/blob/master/hikey/Hi6220V100_Multi-Mode_Application_Processor_Function_Description.pdf

[2] https://github.com/linaro-swg/arm-trusted-firmware/blob/hikey_gendrv/plat/hikey/plat_security.c#L88-L124

Regards,

Jerome

In the absence of the formal compliance report, Linaro has reserved
the right from day one to say which boards we will allow to be
marketed as a 96Boards compatible project. There are boards that we
have rejected due to lack of commitment from the vendor. It isn't the
free-for-all that has been implied.

g.

_______________________________________________
Dev mailing list
Dev@lists.96boards.org
https://lists.96boards.org/mailman/listinfo/dev