Messages in this thread | | | Date | Mon, 7 Mar 2022 21:32:24 +0100 | Subject | Re: Regression: memory corruption on Atmel SAMA5D31 | From | Peter Rosin <> |
| |
On 2022-03-07 12:32, Peter Rosin wrote: > On 2022-03-07 10:45, Tudor.Ambarus@microchip.com wrote: >> Peter, would it worth to do on your board a similar test to what I did? >> I'm thinking whether the source of interrupts matters or not. So can you >> disable your USB and use a mtd NAND stress test as a source of interrupts? >> mtd_stresstest together with scp or hexdump. > > That's not a quick test for me, since I don't have modules enabled. > I have located my SAMA5D31 evaluation kit, and I think I will try > to get that running instead.
Hi again!
I got my SAMA5D31EK board running, using a freshly built at91bootstrap and u-boot according to linux4sam.org and using the cross compiler I have used from buildroot 2021.08, i.e. gcc 10.3.0, then using the dtb for the ME20 from the original post and the same kernel and userspace as I have used previously. Now, that dtb describes things that may not actually be there etc etc, and I will try with a proper dtb as well tomorrow, so this was just a quick-n-dirty test. I also added mem=64MB to the kernel command line, to mimic our "Linea" CPU module and get a bit quicker turnaround in the page cache.
Anyway, with that setup I can reproduce the problem on the EK board.
$ while :; do cat testfile | sha256sum; done 5a939c69dd60a1f991e43d278d2e824a0e7376600a6b20c8e8b347871c546f9b - 7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d - 7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d - 250556db0a6ac3c3e101ae2845da48ebb39a0c12d4c9b9eec5ea229c426bcce9 - 874c694ed002b04b67bf354a95ee521effd07e198f363e02cd63069a94fd4df8 - 7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d - c3a918a923ff2d504a45ffa51289e69fb6d8aa1140cca3fd9f30703b18d9e509 - 1577ed72d2f296f9adc50707e0e56547ecb311fa21ad875a3d55ca908c440307 - 7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d - 7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d -
But apparently only if I have an FTDI usb-serial adapter attached while I boot. I also start to get good hashes if I remove and reinsert the FTDI adapter, which is interesting.
$ while :; do cat testfile | sha256sum; done 7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d - 7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d - 7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d - ... *snip many dozens of lines* ... 7bf74cf37c8bf81ad4f8e86da8eb129a8ae0ee0f5a22ac584ad39233b97acb4d -
It's of course hard to prove the absence of trouble, but it feels like it is working from both of those latter cases...
(for the "real" case the FTDI usb-serial adapter is soldered in, with no easy way to make it go away, so it is not as easy to do the same test there.)
I'll try to reduce the number of local parts of the setup further tomorrow, such as the dtb mentioned above and the rootfs. I was hoping for a binary download of prebuilt parts, but some links on
https://www.linux4sam.org/bin/view/Linux4SAM/Sama5d3xekMainPage
are bogus. E.g.
ftp://twiki.lnx4mchp_backend/pub/demo/linux4sam_4.7/linux4sam-poky-sama5d3xek-4.7.zip
What's up with that twiki.lnx4mchp_backend "host"?
Cheers, Peter
| |