[U-Boot] mips port

Dmytro Milinevskyy
2012-10-28T17:36:58Z

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.uboot@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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-mips-qemu-correctly-compute-start-board_init_r-addre.patch
Type: application/octet-stream
Size: 686 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20121028/0a7eb5fa/attachment.obj>