Re: [U-Boot] i.MX286 U-Boot fails with code HTLLCL0x8050100b
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". -- Stuart Longland Systems Engineer _ ___ \ /|_) | T: +61 7 3535 9619 \/ | \ | 38b Douglas StreetF: +61 7 3535 9699 SYSTEMSMilton QLD 4064 http://www.vrt.com.au ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] i.MX286 U-Boot fails with code HTLLCL0x8050100b
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, -- _ ___ Stuart Longland - Systems Engineer \ /|_) | T: +61 7 3535 9619 \/ | \ | 38b Douglas StreetF: +61 7 3535 9699 SYSTEMSMilton QLD 4064 http://www.vrt.com.au ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[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-gnueabi/ 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, -- _ ___ Stuart Longland - Systems Engineer \ /|_) | T: +61 7 3535 9619 \/ | \ | 38b Douglas StreetF: +61 7 3535 9699 SYSTEMSMilton QLD 4064 http://www.vrt.com.au ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Silly question regarding mx28_adjust_mac and MAC OUIs?
Hi all, Apoligies if this has been asked before. I'm very new to U-Boot, and did look around but found nothing on the topic. I've been doing some porting of U-Boot to a board based around a Freescale i.MX286 CPU. So far thing are working, but I was wondering how one specifies the MAC OUI? As I understand it on this platform, the hardware fuses only store the lower 32-bits of the MAC, with the upper 16-bits intended to be hardcoded into device firmware. Looking through U-Boot, I see this is done in mx28_adjust_mac (arch/arm/cpu/arm926ejs/mxs/mxs.c +237). If I wanted to set a different OUI, is there a way to specify an alternate one without patching mx28_adjust_mac directly? Regards, -- Stuart Longland Systems Engineer _ ___ \ /|_) | T: +61 7 3535 9619 \/ | \ | 38b Douglas StreetF: +61 7 3535 9699 SYSTEMSMilton QLD 4064 http://www.vrt.com.au ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
