I have a Beagleboard Rev. C2. I fired it up after not using it for a couple of years. It booted the Always Innovating image I had installed. I decided to try to put Debian on it. I used the flasher script to try to update u-boot (thank you RobertCNelson). U-boot would lock up just after printing out DRAM on the serial console.
I tried a bunch of different things and managed to get the flasher MLO flashed to the NAND but nothing else got flashed.
I had been have better luck with x-loader so I downloaded x-loader source version 1.5.1. It correctly identifies the revision of the board but will not load u-boot. Hacking up x-loader source I have been able to figure out that anything that gets loaded to the DRAM gets read back as all zeros.
My question is, is there anything that could happen in a bad write to NAND that would interfere with DRAM? I had already hard coded the memory configuration in x-loader so it was not relying on the configuration values in NAND. I am thinking the DRAM is probably bad.
If it booted the Always image, then the DRAM is working. Code executes out of DRAM.
Gerald
Which is why I was thinking maybe a bad flash to NAND had caused a problem. The DRAM is definitely not working now.
When x-loader goes to load u-boot.bin off of MMC, it passes a file name to a function in fat.c. The function copies the filename into DRAM and then parses the copy of the name. It never finds a name because the contents of DRAM are zeros. If I modify the function so that the copy of the filename and the contents read from the MMC card are both in SRAM, then I get a message of loading u-boot.bin from MMC but then it locks up.
My next step I am planning to modify x-loader so it can properly wipe the NAND clean. I just didn't want to waste my time if a bad flash would not be a possible cause.
Thanks.
On the the BeagleBoard we booted form SD. Not NAND. So I am not sure where the support for booting from Flash comes from. We only implemented Flash (eMMC) on the BeagleBone Black.
Gerald
Why in the world are you still evening using "x-loader"? everything
useful has been re-merged back into mainline u-boot as the generic
"SPL"..
Regards,
In my first message I stated that I started having problems when I tried to update using your flasher script. u-boot would hang after printing DRAM and before printing the size of the DRAM. I am using x-loader at this point because it gets further than SPL MLO and because it seemed a little easier for me to hack in order to try to find where the issue is. If I manage to get this straightened out then I will be trying your script again.
Just run "nand erase.chip" and ignore nand on the classic beagle's
The flasher script hasn't been updated in more then a year and it more
useful when users manually messed up the nand. Now day's it's just
easier and painliess to ignore the nand..
Regards,
Can't get that far.New u-boot, from the flasher script, was locking up at printing the DRAM size. Older u-boot was able to start but usually froze at a command prompt. Now SPL does not get past MLO stage before locking up.
The more I think about it the more it seems like the problem is flaky DRAM that got progressively worse.
Original question was if there is some way that DRAM could be rendered non operational by the system locking up during start up with an SD card prepared with the flasher script.
If see no way for the SW to damage the DRAM. But, if you believe that the DRAM is bad, then an RMA can be used to have your board checked out.
Gerald