[PATCH v4 1/3] cmd: bcb: introduce optional interface parameter to bcb

Andrii Chepurnyi Andrii_Chepurnyi at epam.com
Fri Sep 9 15:11:47 CEST 2022


Hello Tom,

I've used a doker from mentioned job to reproduce issue.
I am able to see same errors and test fail as in jobs/490627.

Here is my investigation:

The error that appeared is not related to AVB:

fs_devread read outside partition 2
Failed to mount ext2 filesystem...
BTRFS: superblock end 69632 is larger than device size 512
fs_devread read outside partition 0
fs_devread read outside partition 2
Failed to mount ext2 filesystem...
BTRFS: superblock end 69632 is larger than device size 512
fs_devread read outside partition 0

I found a test case that caused this situation: dm_test_part.
So if you run all tests with -k "not dm_test_part" - all tests will 
pass, including AVB tests.

dm_test_part  modify GPT (during testing used mmc1.img for emulation, as 
I understand), and after if some part of code touch blk you may see a 
mentioned error. I.e. run only dm_test_part test, start u-boot and run 
"part list mmc 1" you will see the same error.
So I suppose this problem(if it is a problem since I see it like a test 
case that didn't restore the environment back) was present prior to my 
patches.

But why it appears after my patches?
Because I've changed the internal logic of avb command and now on avb 
init will interact with blk(blk_get_device_by_str) which causes those 
prints. In the previous versions of avb commands "avb init" and "avb 
read_rb " will not touch blk, so no error is present.

So from my point of view, this is more like dm_test_part problem, but 
not bcb or avb patches.

Andrii.

On 03.09.22 04:55, Tom Rini wrote:
> On Mon, Aug 01, 2022 at 11:07:15AM +0300, Andrii Chepurnyi wrote:
>
>> From: Andrii Chepurnyi <andrii.chepurnyi82 at gmail.com>
>>
>> From: Andrii Chepurnyi <andrii_chepurnyi at epam.com>
>>
>> Originally, bcb implementation relay on mmc block devices.
>> The interface parameter will give the ability to use bcb with
>> various block devices by choosing the exact interface type.
>> By default (if no interface parameter is provided) mmc interface
>> will be used.
>>
>> Reviewed-by: Igor Opaniuk <igor.opaniuk at gmail.com>
>> Signed-off-by: Andrii Chepurnyi <andrii_chepurnyi at epam.com>
> The tests now fail:
> https://source.denx.de/u-boot/u-boot/-/jobs/490627
>


More information about the U-Boot mailing list