[U-Boot] Command unit test failure?

[U-Boot] Command unit test failure?

[Simon Glass]

Hi Stephen,

I am seeing the failure below when I run the unit tests. I noticed it
a while ago but thought I might be doing something wrong. Any ideas?


$ b/sandbox/u-boot -c "ut_cmd"


U-Boot 2014.07-rc2-00002-gf23adc9 (May 30 2014 - 12:05:36)

DRAM:  128 MiB
Using default environment

In:    serial
Out:   lcd
Err:   lcd
do_ut_cmd: Testing commands
## Resetting to default environment
** No device specified **
** No device specified **
** No device specified **
/usr/local/google/c/cosarm/src/third_party/u-boot/files/test/command_ut.c:165:
do_ut_cmd: Assertion `!strcmp("y", getenv("e" "_" "y"))' failed.

Regards,
Simon

[U-Boot] Command unit test failure?

[Stephen Warren]

On 05/30/2014 12:07 PM, Simon Glass wrote:
> Hi Stephen,
> 
> I am seeing the failure below when I run the unit tests. I noticed it
> a while ago but thought I might be doing something wrong. Any ideas?

git bisect says:

> git bisect bad
> 95fac6ab4589ec0767b1eac662577866e2b2f423 is the first bad commit
> commit 95fac6ab4589ec0767b1eac662577866e2b2f423
> Author: Simon Glass <sjg@chromium.org>
> Date:   Thu Feb 27 13:25:58 2014 -0700
> 
>     sandbox: Use os functions to read host device tree
>     
>     At present we use U-Boot's filesystem layer to read the sandbox device tree,
>     but this is problematic since it relies on a temporary feauture added
>     there. Since we plan to implement proper block layer support for sandbox,
>     change this code to use the os layer functions instead. Also use the new
>     fdt_create_empty_tree() instead of our own code.
>     
>     Signed-off-by: Simon Glass <sjg@chromium.org>
> 
> :040000 040000 02b649e6f0c3f84f8aff31938ec869ec6ccd964c 1d48977cfbcbb855b2ee2de2bd20b43a39db7837 M	common
> :040000 040000 7982835c46f491ed54f289b79f2ad1567e8f135b a543335107459fb1a759b262573904fd18b8c683 M	disk

No doubt the change to disk/part.c in that commit broke the syntax "host
- $filename" for the "sb save" and "test -e" commands. Is there some
alternate syntax that sandbox should use to access the filesystem, and
hence the unit test commands should be using?

[U-Boot] Command unit test failure?

[Simon Glass]

Hi Stephen,

On 30 May 2014 13:18, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 05/30/2014 12:07 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> I am seeing the failure below when I run the unit tests. I noticed it
>> a while ago but thought I might be doing something wrong. Any ideas?
>
> git bisect says:
>
>> git bisect bad
>> 95fac6ab4589ec0767b1eac662577866e2b2f423 is the first bad commit
>> commit 95fac6ab4589ec0767b1eac662577866e2b2f423
>> Author: Simon Glass <sjg@chromium.org>
>> Date:   Thu Feb 27 13:25:58 2014 -0700
>>
>>     sandbox: Use os functions to read host device tree
>>
>>     At present we use U-Boot's filesystem layer to read the sandbox device tree,
>>     but this is problematic since it relies on a temporary feauture added
>>     there. Since we plan to implement proper block layer support for sandbox,
>>     change this code to use the os layer functions instead. Also use the new
>>     fdt_create_empty_tree() instead of our own code.
>>
>>     Signed-off-by: Simon Glass <sjg@chromium.org>
>>
>> :040000 040000 02b649e6f0c3f84f8aff31938ec869ec6ccd964c 1d48977cfbcbb855b2ee2de2bd20b43a39db7837 M    common
>> :040000 040000 7982835c46f491ed54f289b79f2ad1567e8f135b a543335107459fb1a759b262573904fd18b8c683 M    disk
>
> No doubt the change to disk/part.c in that commit broke the syntax "host
> - $filename" for the "sb save" and "test -e" commands. Is there some
> alternate syntax that sandbox should use to access the filesystem, and
> hence the unit test commands should be using?

OK thanks for digging. The alternative feature is the block device
framework, which sandbox now supports - see f4d8de48. This allows us
to see host files as block devices, potentially containing filesystems
that U-Boot supports. It enables sandbox to use filesystems,  One day
we might have a filesystem test that uses this.

Having said that it seems clear that host file access is a useful
feature for testing in sandbox (at least!), and we really need it
independently of the block device interface. The implementation that
was dropped was just a work-around and we don't have a full
replacement yet.

But we really shouldn't use the same name 'host' for the host device.
I'm not actually sure if that would work.

If you have time to take a look please do (I have a bit of a queue),
otherwise I'll see if I can come up with something that keeps both
features enabled.

Regards,
Simon