[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