Forums » Software Development »
MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot
Added by Anonymous over 10 years ago
We just received one of our units back from the field and it hangs running a "mw.b" command in the u-boot param script. The system will lock up using DDR or internal ARM memory addresses in the mw.b command. If we boot off the mmc sd card with the same image, the mw.b command works fine. We then proceeded to check what was actually burned into NAND. We ran the following scripts on the unit to see if the MLO and u-boot.img's in NAND are the same as our released code on the mmc card. The output seen below shows that the two images are identical. We also checked the u-boot image in NAND by reading it into memory and running the imi command on it. The imi command says that the image is good.
The error is very consistent and we are unsure how to track this issue. If MLO and u-boot both appear correct, and match the released images, how could booting out of NAND vs. the MMC card cause this kind of failure? We are able to boot u-boot from NAND and stop it before we attempt to run our image, but issuing the mw.b command will still cause a lockup. Has Critical Link ever seen this type of behavior?
Any suggestions for what to test/ideas would be appreciated.
John Conover
----------------------------------------------
---Compare released images to NAND------------
U-Boot# mmc rescan
U-Boot# fatload mmc 0 0x8A000000 MLO
reading MLO
40291 bytes read
U-Boot# nandecc hw 2
HW ECC BCH8 Selected
U-Boot# nand read.i 0x8B000000 0x00000000 $filesize
NAND read: device 0 offset 0x0, size 0x9d63
40291 bytes read: OK
U-Boot# cmp.b 8A000000 8B000000 $filesize
Total of 40291 bytes were the same
U-Boot#
Total of 40291 bytes were the same
U-Boot# mmc rescan
U-Boot# fatload mmc 0 0x8C000000 u-boot.img
reading u-boot.img
381964 bytes read
U-Boot# nandecc hw 2
HW ECC BCH8 Selected
U-Boot# nand read.i 0x8D000000 0x00080000 $filesize
NAND read: device 0 offset 0x80000, size 0x5d40c
381964 bytes read: OK
U-Boot# cmp.b 8c000000 8d000000 $filesize
Total of 381964 bytes were the same
U-Boot#
--------------------------------------------------------
----------------------------------------------
--------Image check u-boot in NAND------------
U-Boot# nand read.i 0x8D000000 0x00080000 $filesize
NAND read: device 0 offset 0x80000, size 0x5d40c
381964 bytes read: OK
U-Boot# cmp.b 8c000000 8d000000 $filesize
Total of 381964 bytes were the same
U-Boot# nand read.i 0x8B000000 0x00080000 0x001e0000
NAND read: device 0 offset 0x80000, size 0x1e0000
1966080 bytes read: OK
U-Boot# imi 8c000000
- Checking Image at 8c000000 ...
Legacy image found
Image Name: U-Boot 21401-101.01.00.02-dirty
Image Type: ARM U-Boot Firmware (uncompressed)
Data Size: 381900 Bytes = 372.9 KiB
Load Address: 80800000
Entry Point: 00000000
Verifying Checksum ... OK
U-Boot#
Replies (27)
RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot - Added by Anonymous over 10 years ago
I pulled the AM335XPSP_04.06.00.08 tag and there were a lot of differences. I don't think it matters
that much as we really only modify six files of yours, and most of that is because of the one very
large SPI NOR chip that we need. I'll pull the u-boot-2013.10 tag and check it. As long as it
builds on it's own it should not take me long to modify it.
Thanks again for all the help in fixing this. If you know how I can get rid if the "-dirty" string
at the end of the version number output, that would be a double bonus.
Thanks,
John C.
U-Boot SPL 21401-101.01.00.02-dirty (Nov 06 2013 - 08:59:11)
Y
--------How does this get in the output?
RE: MityARM335x profile 1 - Model No: 3352-GX-X27-RC failing memory writes in u-boot - Added by Jonathan Cormier over 10 years ago
Dirty gets appended to the version string for both u-boot and the kernel when you compile source code that has changes that aren't committed in git. Its a sort of warning to the developer that this version may not be reproducible from a fresh checkout.
- « Previous
- 1
- 2
- Next »