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

[Robert Crowston]

You can generate a test file with something like
head -c 8000000000 /dev/random > yourfile
md5 before and after to see if they are unchanged. That was how I did my testing.

[As for MicroSD wear&tear: I keep hearing people talk about how unreliable these cards are, but when you ask for hard numbers about lifetime, no one has any. I've had one SD card out of dozens fail on me, despite regularly dd'ing out entire cards -- this is a better failure rate than my mechanical hard disks. SD cards are also very cheap. To me it seems like an irrelevant concern, unless you don't keep backups.]

— RHC.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, 7 March 2021 16:46, Mark Millard via freebsd-arm <freebsd-arm at freebsd.org> wrote:

>
>
> On 2021-Mar-7, at 07:55, bob prohaska <fbsd atwww.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)
>
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"