Re: [U-Boot] [PATCH 0/8] Initial integration of AVB2.0

2018-05-15 Thread Eugeniu Rosca
Hi Igor, On Tue, May 15, 2018 at 07:58:51PM +0300, Igor Opaniuk wrote: > Hi Eugeniu, > > You're totally right regarding avb internal headers, they all > should remain in lib/libavb. > v2 patchset (planning to send it by the end of this week) will > include these changes you're talking about (+ wi

Re: [U-Boot] [PATCH 0/8] Initial integration of AVB2.0

2018-05-15 Thread Igor Opaniuk
Hi Eugeniu, You're totally right regarding avb internal headers, they all should remain in lib/libavb. v2 patchset (planning to send it by the end of this week) will include these changes you're talking about (+ will include libavb updates from [1]). > My final question is what's your opinion abo

Re: [U-Boot] [PATCH 0/8] Initial integration of AVB2.0

2018-05-15 Thread Eugeniu Rosca
On Sun, May 06, 2018 at 01:31:18PM +0200, Eugeniu Rosca wrote: > Hello Igor, Alex, Kever, > > I wonder if it would be possible to keep the internal libavb headers in > lib/libavb (similar to how it's done by NXP in [4]), since this would > allow not rewriting the original include paths for such he

Re: [U-Boot] [PATCH 0/8] Initial integration of AVB2.0

2018-05-06 Thread Eugeniu Rosca
Hello Igor, Alex, Kever, Having these patches in mainline would be great, as this would reduce the delta between our own and community U-boot trees. After having a quick look at this series, I have some questions/review findings. These patches appear to be slightly older than what is available in

Re: [U-Boot] [PATCH 0/8] Initial integration of AVB2.0

2018-04-27 Thread Igor Opaniuk
Hi Alex, I've replaced licence texts in source file headers to SPDX short identifiers (suggestion from Tom Rini). As far as I know that was the only one major change I introduced to libavb/libavb_ab. I also did remove crc32() implementation and used existing in U-boot because of licence ambiguity,

Re: [U-Boot] [PATCH 0/8] Initial integration of AVB2.0

2018-04-26 Thread Alex Deymo
Hi Kever, libavb and libavb_ab are different things, and we split them for a reason. Adding libavb is great, but you don't need to add libavb_ab as an A/B implementation. The boot_android command referenced by Igor doesn't use that as an A/B implementation, but uses the structs already defined in

Re: [U-Boot] [PATCH 0/8] Initial integration of AVB2.0

2018-04-26 Thread Igor Opaniuk
On 26 April 2018 at 06:05, Kever Yang wrote: > Hi Igor, > > It's great to see the patch set to support AVB2.0, the upstream > libavb(from aosp) combine the AVB with A/B which I think should be > two separate feature, are you going to split them? Hi Kever, Right, support of verification of A/

Re: [U-Boot] [PATCH 0/8] Initial integration of AVB2.0

2018-04-25 Thread Kever Yang
Hi Igor,     It's great to see the patch set to support AVB2.0, the upstream libavb(from aosp) combine the AVB with A/B which I think should be two separate feature, are you going to split them?     BTW, do you have plan to update boot_android cmd to support avb? the command is too weak for use n

[U-Boot] [PATCH 0/8] Initial integration of AVB2.0

2018-04-25 Thread Igor Opaniuk
This series of patches introduces support of Android Verified Boot 2.0, which provides integrity checking of Android partitions on MMC. It integrates libavb/libavb_ab into the U-boot, provides implementation of AvbOps, subset of `avb` commands to run verification chain (and for debugging purposes)