<ukky>
how can I ensure that unit test is run in sandbox environmentt only? i.e. I want to fail the test on real HW
<ukky>
found it, config SANDBOX
mmu_man has quit [Ping timeout: 255 seconds]
prabhakarlad has quit [Quit: Client closed]
mmu_man has joined #u-boot
jclsn has quit [Ping timeout: 260 seconds]
jclsn has joined #u-boot
<marex>
ukky: why fail on real hw ?
<marex>
real hardware also contains block devices
<ukky>
marex: I would like to write a test case, but want to fail it on real HW as it actually screws up MBR record.
<marex>
yes it does, use a throw-away drive then ?
<marex>
or SD card or whatever
<marex>
you do need to explicitly run the test anyway, so if you're concerned it corrupts a drive content, dont run it
<marex>
I think the uboot-test-hooks already have something where you can specify which tests to skip
<marex>
sjg1: ^
<ukky>
we don't need a test case in this situation plus sandbox. On real HW we can just test with real 'mbr write' command, and then 'mbr verify'
<marex>
ukky: the test should be identical and hardware independent, right ?
<ukky>
imho, I was thinking about test case to test U-Boot code, not the real 'mbr write' functionality
<marex>
have you had a look into test/cmd/ directory ?
<Forty-Bot>
isn't there UT_TESTF_MANUAL
<marex>
those tests invoke U-Boot commands (from code)
<ukky>
'mbr write' and 'mbr verify' are fully functional commands
<Forty-Bot>
but I guess that wouldn't be automatic on sandbox...
<marex>
ukky: except they dont work if you feed them 4 partitions, so, not really fully functional, right ?
<marex>
I think that's the testcase you want to write here
<ukky>
marex: yes, I checked test/cmd directory to see how/where a test would fit
<ukky>
my idea of a test: declare single MBR partition, then 'mbr write', then 'mbr verify' and expect 'success' after all commands
<ukky>
then declare two MBR partitions and repeat the test.
<ukky>
then three MBR partitions and repeat.
<marex>
you can always 'mbr write' and then read the first block of disk into memory and dump it (or run crc32 on it and compare the crc)
<ukky>
with four MBR partitions current U-Boot will fail
<marex>
that way you only test one code path at a time (assuming crc works)
<marex>
ukky: that's why you wanna test the 4 partition thing with a fix in place, so it never gets broken again
stefanro has joined #u-boot
<ukky>
what should I call a test then? 'ut test_mmc_mbr_write'?
<marex>
test/cmd/mbr.c and then define whatever sub-tests using UNIT_TEST(...) , see fdt.c for examples
<ukky>
in sandbox, there are 3 MMC devices declared: mmc0: 1MiB, mmc1: NNNMiB, and mmc2: 1MiB. Can I access any of those. mmc1 seems like refers mmc1.img external file.
<marex>
=> mmc list
<marex>
=> mmc dev N
<ukky>
yes, I know, but any of those are available for 'ut' command?
<marex>
ut just runs commands and collects their output
<marex>
there is little difference in that aspect
<marex>
whatever you can run in shell, you can also run within ut