[U-Boot] i.MX286 U-Boot fails with code HTLLCL0x8050100b
Hi all,
I'm trying to build a previously known working branch of U-Boot that I built some time back which forks from revision e89d623f099c44b0b166ccf46bce2e6a0b99c984.
I previously built this before, the binaries and source for which are here: http://bne.vrt.com.au/technologicsys/
There you'll find the notes on exactly how I built it too.
Since I did development there, I've done a number of system updates on my workstation, and so I suspect one of them has broken something, as when I try to build that U-Boot branch and `dd` the resulting `u-boot.sd` (according to the documentation in doc/README.mxs), I now get the following error code displayed:
HTLLCL0x8050100b
The documentation I found here http://www.denx-cs.de/?q=blogm28mxssb seemed to suggest the following meaning:
.--------------- Valid SB |.-------------- SB tag ||.------------- u-boot-spl.bin loaded |||.------------ IVT loaded ||||.----------- SPL executed |||||.---------- U-Boot binary loaded HTLLCL0x8050100b '--------' CRC Error
I'm guessing "IVT" here means interrupt vector table, and that the lack of a second 'L' suggests it was loading of this interrupt vector table that failed due to a CRC error.
I've tried building u-boot with a number of different toolchains: - binutils-2.25.1, gcc-4.7.3, glibc, EABI, built using Gentoo crossdev - arm-none-eabi toolchain, self-built using sources from https://launchpad.net/gcc-arm-embedded - Linaro arm EABI toolchain from http://releases.linaro.org/14.11/components/toolchain/binaries/arm-linux-gnu...
None of these seem to generate a successfully booting binary, which is perplexing to say the least. Is there somewhere else I should be looking for the cause of the above issue?
Regards,
On 11/02/16 15:34, Stuart Longland wrote:
I now get the following error code displayed:
HTLLCL0x8050100b
The documentation I found here http://www.denx-cs.de/?q=blogm28mxssb seemed to suggest the following meaning:
.--------------- Valid SB |.-------------- SB tag ||.------------- u-boot-spl.bin loaded |||.------------ IVT loaded ||||.----------- SPL executed |||||.---------- U-Boot binary loaded HTLLCL0x8050100b '--------' CRC Error
I'm guessing "IVT" here means interrupt vector table, and that the lack of a second 'L' suggests it was loading of this interrupt vector table that failed due to a CRC error.
I've since read up in the datasheet, I was close, it's "image vector table". I've been trying to hexdump a "known good" image and my broken ones to figure out what's going on.
I can make some sense of the SD image header, but yet to fully figure out the bootstream format itself. Searching for more information on the issue simply reveals copies of my earlier email to this list.
None of these seem to generate a successfully booting binary, which is perplexing to say the least. Is there somewhere else I should be looking for the cause of the above issue?
I've now tried numerous other toolchain version combinations, including building it on a Debian chroot. I don't seem to be able to get SPL debugging going -- even though I've #define'd DEBUG, and CONFIG_SPL_SERIAL_SUPPORT.
I figure if I had the wrong pins configured, I wouldn't even see the error code I've been getting, so clearly that works.
I've been trying to debug this for days now and it's driving me insane.
The code previously worked. I've also tried building images for the mx28evk, which is a very similar board to the one I'm using, and I get the same result.
I ask again: Is there somewhere else I should be looking for the cause of the above issue?
Regards,
On 15/02/16 14:09, Stuart Longland wrote:
I ask again: Is there somewhere else I should be looking for the cause of the above issue?
Well, found my issue in the end I think. In exasperation I dd'ed one of my working SD card images, proved that the machine booted, then dd'ed the newly build U-Boot image over the top of the old U-Boot partition.
It worked.
So I'll put this down to the i.MX286 boot ROM being *exceptionally* picky about partition placement. If things aren't *exactly* right, it'll flatly refuse to work.
I might see if I can reproduce the bad image and hex-dump it to better understand what was "wrong".
participants (1)
-
Stuart Longland