[U-Boot] mips port

[U-Boot] mips port

[Dmytro Milinevskyy]

Hi,
I'm new to uboot mips port and first decided to try it with qemu.
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?

Thanks,
-- dmytro

[U-Boot] mips port

[Jerry Van Baren]

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

[U-Boot] mips port

[Dmytro Milinevskyy]

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>

[U-Boot] mips port

[Dmytro Milinevskyy]

Hi,
I'm new to uboot mips port and first decided to try it with qemu.
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?

Thanks,
-- dmytro
-------------- 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/20120929/8950ca7d/attachment-0001.obj>

[U-Boot] mips port

[Dmytro Milinevskyy]

Hi,
I'm new to uboot mips port and first decided to try it with qemu.
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?

Thanks,
-- dmytro
-------------- 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/20121001/05d5c563/attachment.obj>