2008-09-26 10:49:58 BF526: u-boot startup problem
der knut (GERMANY)
I just try to boot our new BF526 Rev 0.0 custom board and encounter some problems. For now I just load u-boot via JTAG/GDB to the board, following the instructions at
I load the SDRAM initcode different, because the code should load to internal RAM. This does not work for me if I only
so I am do
(gdb)load init.elf 0xFFA00000 // After that the SEQSTAT register is 0xC000 (HWERR: 3).
This work, the SDRAM look fine.
Then I load u-boot and start stepping.
Immediatly after cpu.c/irq_init unmask the HWERR-Except. it occur and panic.
I tried different SRAM Banks, but always the same problem.
If I ignore the exception (just rti or do not unmask it) everything looks fine, u-boot starts and SDRAM-Test show no error.
Where is my mistake? How can I locate init.elf to internal RAM so I can load it directly?
Thanks a lot and greetings from sunny Germany
2008-09-26 11:15:00 Re: BF526: u-boot startup problem
Martin Strubel (SWITZERLAND)
We've talked on the phone, just read about your u-boot problem, replying here, for the benefit of the community :-)
I haven't tried yet to load the init code with an offset, but, assuming you're using the ICEbear, you can just initialize the memory manually, as listed here: http://section5.ch/appnotes#adv_loaduboot
(check the 'set *$EBIU...' statements). You have to determine these values for your board though, either you guess them from an existing board that is similar, or you go through the awkward procedure to calculate everything from the data sheet. Note that these are the bootup values for a not yet configured PLL. If in doubt what settings are current, you can use the 'dump_pll' command from the dump.gdb support script (it's normally in /usr/share/gdbscripts) right after a "monitor reset".
Then the 'load' command should work fine and u-boot should recognize the SDRAM being configured and outputting the boot sequence countdown after a 'continue'. At least that should apply to a 1.1.6 2008R1 release u-boot, I hope nothing has changed there.
2008-09-26 13:33:49 Re: BF526: u-boot startup problem
Mike Frysinger (UNITED STATES)
check the CEC/sequencer status at each step to see when the hardware error is generated. because IRQs are all masked until that point in irq_init, a HWERR could have been generated at any point before.
when using gdb as an interface, you have to remember you cannot set any breakpoints on external memory as gdb itself will attempt to access it and cause the HWERR
2008-09-29 04:50:36 Re: BF526: u-boot startup problem
der knut (GERMANY)
thanks a lot for help. With both informations I found myself guilty for using ddd. The well known problem (now also to me =:-( with graphical gdb frontend and loading of information in background accessing illegal memory. If I do my necessary steps with gdb only no HWERR occure.
Thanks a lot