[U-Boot] [FAT/EXT4/SANDBOX] files > 2GB

[Simon Glass]

Hi,

On 8 October 2014 07:07, Suriyan Ramasami <suriyan.r at gmail.com> wrote:
> Hello,
>    I recently saw a post about fat commands such as fatls returning
> -ve values under u-boot for files whose sizes are >=2GB. fatsize would
> also not set up filesize in this case.
>
>    This also effects ext4/sandbox commands. I just looked at the ones
> which are handled by fs/fs.c
>
>     I am thinking of cleaning this up a bit.
>
>     My question is, is there some kind of preexisting automated test
> that I can build into u-boot which adds a command which does the test
> for me?
> For example, it could use the FS/read/write commands to create files
> with some pattern that it knows of, reads them for various sizes to
> check if they are correct etc. Same procedure for the [FS]size command
> as well.
>
>    I do have made the changes to correct the behavior. The code change
> touches the [FS]read part of the code, hence, I want to test it
> extensively to assure me that I haven't broken anything else.
>   I am nervous about the sandbox related code as I do not know how to
> even use them!

It's quite ad-hoc at present, but there are several things you can follow:

- test/cmd_repeat.sh shows how to run sandbox, pass it a command and
check the output
- test/command_ut.c and test/compression.c shows how to create a new
command for testing purposes
- test/dm contains driver model tests - there is framework but it is
driver-model-specific
- test/image shows a python script that creates tests files and runs
sandbox to check them
- test/vboot is similar for verified boot, although it is a shell script

I feel that python is probably best for non-trivial tests. Probably
you want to create a filesystem using a loopback device and mkfs, then
run sandbox U-Boot to perform various operations. Then you could check
the output from U-Boot and/or the resulting filesystem when U-Boot is
finished.

It would be great to have even a basic test for filesystems. I suggest
you try to make it filesystem-agnostic - i.e. implement it for ext4
but make it extensible later for other filesystems.

Regards,
Simon