[U-Boot] [FAT/EXT4/SANDBOX] files > 2GB
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!
Thanks for your help - Suriyan
Hi,
On 8 October 2014 07:07, Suriyan Ramasami suriyan.r@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 testthat 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
Hello Simon,
On Wed, Oct 8, 2014 at 11:16 PM, Simon Glass sjg@chromium.org wrote:
Hi,
On 8 October 2014 07:07, Suriyan Ramasami suriyan.r@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 testthat 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.
Thank you for the specifics and the details. I shall go over them and implement some kind of basic filesystem testing framework.
- Regards - Suriyan
Regards, Simon
participants (2)
-
Simon Glass -
Suriyan Ramasami