RPi4 Status and sysutils/rpi-firmware (and rng)

[Mark Millard]

On 2021-Mar-7, at 07:55, bob prohaska <fbsd at www.zefox.net> wrote:

> On Sat, Mar 06, 2021 at 09:30:33PM -0800, Mark Millard wrote:
>> 
>> I've not done the huge-file copy-corruption testing
>> recently, and never with stable/13 or releng/13.0 or
>> a 13.0-BETA*/RC* . I probably should try, booting
>> a 13.0-RC* image as the context (other than the
>> rpi-firmware replacements). I use a file that is
>> notably bigger than the RAM.
>> 
> 
> This is -current, chosen to be the latest offered.
> 
>> Historically, if the corruption problems show up
>> the technique to get a reliable environment was to
>> restrict it to using 3 GiBytes, possibly via some
>> text in config.txt . This also applied to the
>> RPi4B 4 GiByte models.
>> 
> 
> Might it be useful to attempt the huge-file corruption test?
> This is a microSD-only setup, but it's a 32 GB card so there's
> enough space for a file bigger than the 8 GB RAM. The most obvious
> sticking point is need to manufacture a test file since there's
> no ethernet. The second issue would be reporting; all I can
> do is look at the screen and make manual notes. Enough for a
> go/no-go test, not so good for details. 
> 

For u-boot based booting the expected result with 8 GiBytes
of RAM in use is that it would work fine: the problem was
addressed for that kind of context. It is the ACPI type of
booting that still has the known problem. For 13.0-RC1
my u-boot booting based testing would be that the code has
not reverted somehow.

I tested 13.0-RC1 using the normal u-boot style of booting
and it worked fine: no differences found.

I tested my main c113740f266e based non-debug build (about
4 days old) and it worked fine as well.

I do not see that you would gain much from repeating the
tests on a microsd card. The wear-and-tear on the microsd
media used and time might not be worth it. Sneakernet of a
microsd card prepared elsewhere would be one technique
of getting a large file in place. Another would be to
compile a program and run it. What I did was to make a tar
of an already huge directory tree that I had.

Given the initial file, the test is simple: cp the file
then diff the files. If the diff finds the files are
different, then some problem happened, possibly the old
DMA handling issue. If the diff finds the files are the
same, then there is no evidence of the DMA handling
problem.

(cmp or the like could be used to see some about the
differences if there were some.)

I happened to use a file that was 11570948096 bytes
long. (It was a tar of a dirrectory tree.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)