Jerry, thanks for your answer. So far nobody commented my remark regarding the address of board_init_r after the relocation so I would like to raise it again. Maybe it's my fault as I forgot to attach the patch. In the patch the address is correctly computed which allows u-boot to run after relocation.
thanks, -- dmytro On Tue, Oct 9, 2012 at 2:48 AM, Jerry Van Baren <gvb.ub...@gmail.com> wrote: > On 10/06/2012 09:11 PM, Dmytro Milinevskyy wrote: >> Hi, >> I'm new to uboot mips port and first decided to try it with qemu. > > Welcome. :-) > >> I've encountered some problems with UART, but I guess that's more qemu >> issue(lsr reg is not updated when the line is available). >> >> Another issue I faced was code execution after the relocation is done. The >> address of board_init_r is not computed correctly(it was relative to boot >> ROM address space/bfc00000). >> Is it specific to qemu(I don't see the reference here though) or is it a >> generic mips port issue? Attached patch allows me to proceed with the boot >> in qemu. >> >> And last - why do we need relocation at all with u-boot? Performance >> constraints? > > Generally, yes. Flash is very often slower than RAM (often 8 bits width > vs. 32 bits or more, generally doesn't support bursting, the processor > cache may not work with it, etc.). > > A side benefit of running out of RAM is that it makes it much easier to > write to flash... you don't have to worry about writing to the chip you > are executing out of (when you erase/write flash, the chip returns a > "programming in progress" status until it is done - that will crash your > program if you are running out of that chip). > >> Thanks, >> -- dmytro > > Best regards, > gvb >
0001-mips-qemu-correctly-compute-start-board_init_r-addre.patch
Description: Binary data
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot