Dear Kim Phillips,
In message 20100720133648.cbb95a9f.kim.phillips@freescale.com you wrote:
I would, however u-boot-testing.git/hashtable currently fails to boot on an 8572:
Hm... one of the boards I don't have access to; can you please help debug the problem?
U-Boot 2010.06-02552-g9895ea5 (Jul 19 2010 - 18:39:19)
CPU0: 8572E, Version: 1.1, (0x80e80011) Core: E500, Version: 3.0, (0x80210030) Clock Configuration: CPU0:1499.985 MHz, CPU1:1499.985 MHz, CCB:599.994 MHz, DDR:399.996 MHz (799.992 MT/s data rate) (Asynchronous), LBC:37.500 MHz L1: D-cache 32 kB enabled I-cache 32 kB enabled Board: MPC8572DS Sys ID: 0x14, Sys Ver: 0x30, FPGA Ver: 0x10, vBank: 0 I2C: ready DRAM: Initializing....
I presume it's related to the issue brought up in this thread?:
Hm... I don't think so, but as it's failing there must be some bug somewhere... My thinking is that all the relevant environment handling that actually uses errno is related to the hash table handling, and all this runs definitely only after relocation to RAM, so this should not be the problem.
What we see here is in the pre-relocation phase, where we are still parsing the original, in-flash copy of the stringified environment. What is strange is that this seems to have worked when accessing "baudrate" (either because the environment was found, or because the default environment was used), but is stopping here.
Can you attach a debugger and check?
Best regards,
Wolfgang Denk