RE: Boot from 64-bit memory address?

2023-02-24 Thread Bernard, Philip
Hi Rick,

Thanks for the feedback! I did make those changes to binman.dtsi. Ultimately, I 
think the issue is with the "ERROR: Out of memory" error which comes from the 
EFI loader (lib/efi_loader) because there's no conventional memory (i.e. 
something with a memory address below 4GB). The allocation error afterward 
(from boot/image_board.c::boot_ramdisk_high) is a knock-on effect since there's 
no location available to move initramfs to. 

As I've dug into this more today though, it seems like so many backend things 
for RISC-V in U-Boot are set up to only support 32-bit DRAM. I think there will 
be quite a lot of adjustments to be made to support the memory map I have.

Thanks,
Phil

-Original Message-
From: Rick Chen  
Sent: Thursday, February 23, 2023 10:33 PM
To: Bernard, Philip 
Cc: U-Boot Mailing List ; Leo Liang 
; peter...@andestech.com; rick 
Subject: Re: Boot from 64-bit memory address?

Hi Philip,

> From: U-Boot  On Behalf Of Bernard, 
> Philip
> Sent: Thursday, February 23, 2023 9:21 AM
> To: u-boot@lists.denx.de
> Subject: Boot from 64-bit memory address?
>
> Hi,
>
> Is it possible to boot from a DRAM memory address beyond the 32-bit 
> boundary? I'm trying to configure a new RISC-V board which has 2GB of 
> DRAM starting at offset 0x40__. I started from the settings 
> for an existing RISC-V board and made

I think it is possible to boot from a DRAM memory beyond the 32-bit boundary. 
But maybe you need to modify some code to achieve that.
I have tried to boot an internal AE350-like platform whose DRAM base is at 
0x4.

adjustments for my HW, but when I try to boot, I run into an "out of memory" 
error.
>
> From 
> https://u-boot.readthedocs.io/en/latest/develop/uefi/u-boot_on_efi.html#tables
>  I noticed that U-Boot will only use "conventional" memory which is 4GB and 
> below, so it seems like this may not be possible? Looking through the repo, I 
> also noticed that nearly every device is configuring settings like 
> CONFIG_SYS_LOAD_ADDR with a 32-bit value, so I haven't found any examples to 
> emulate for my use case.

CONFIG_SYS_LOAD_ADDR is not important. Maybe you shall notice 
CONFIG_SYS_TEXT_BASE and CONFIG_SPL_OPENSBI_LOAD_ADDR which will be parsed from 
binman.dtsi You can change them like this:
load = /bits/64 ;
load = /bits/64 ;

>
> I'm hoping someone knows the mistake I'm making or can confirm that this 
> isn't possible. Appreciate the help.
>
> Best,
> Phil
>
>
> Below is the output from U-Boot:
>
> U-Boot SPL 2022.07 (Feb 23 2023 - 00:50:44 +) Trying to boot from 
> RAM
>
> OpenSBI v1.1
>_  _
>   / __ \  / |  _ \_   _|
> | |  | |_ __   ___ _ __ | (___ | |_) || |
> | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | | __| | |_) |  __/ | | |) 
> | | |
> | ||_) || |_
>   \/| .__/ \___|_| |_|_/|/_|
> | |
> |_|
>
> Platform Name : test,test
> Platform Features : medeleg
> Platform HART Count   : 1
> Platform IPI Device   : aclint-mswi
> Platform Timer Device : aclint-mtimer @ 100Hz
> Platform Console Device   : uart8250
> Platform HSM Device   : ---
> Platform Reboot Device: ---
> Platform Shutdown Device  : ---
> Firmware Base : 0x8000
> Firmware Size : 276 KB
> Runtime SBI Version   : 1.0
>
> Domain0 Name  : root
> Domain0 Boot HART : 0
> Domain0 HARTs : 0*
> Domain0 Region00  : 0x0200-0x0200 (I)
> Domain0 Region01  : 0x8000-0x8007 ()
> Domain0 Region02  : 0x-0x (R,W,X)
> Domain0 Next Address  : 0x00400120
> Domain0 Next Arg1 : 0x004001267830
> Domain0 Next Mode : S-mode
> Domain0 SysReset  : yes
>
> Boot HART ID  : 0
> Boot HART Domain  : root
> Boot HART Priv Version: v1.10
> Boot HART Base ISA: rv64imafdcb
> Boot HART ISA Extensions  : time
> Boot HART PMP Count   : 8
> Boot HART PMP Granularity : 4
> Boot HART PMP Address Bits: 54
> Boot HART MHPM Count  : 0
> Boot HART MIDELEG : 0x0222
> Boot HART MEDELEG : 0xb109
>
>
> U-Boot 2022.07 (Feb 23 2023 - 00:50:44 +)
>
> CPU:   rv64imafdc
> Model: test,test
> DRAM:  2 GiB
> Core:  11 devices, 8 uclasses, devicetree: separate
> ERROR: Out of memory
> Loading Environment from nowhere... OK
> In:serial@13140
> Out:   serial@13140
> Err:   serial@13140
> Model: test,test
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> Moving Image from 0x400600 to 0x400020, end=4000b01c8c ## Flattened 
> Device Tree blob at ff76a1d0
>Booting using the fdt blob at 0xff76a1d0
> ERROR: Failed to allocate 0x100 bytes below 0x1.

Can you dig in where to print this ERROR ?

Thanks,
Rick

> ramdisk - allocation error


Re: Boot from 64-bit memory address?

2023-02-23 Thread Rick Chen
Hi Philip,

> From: U-Boot  On Behalf Of Bernard, Philip
> Sent: Thursday, February 23, 2023 9:21 AM
> To: u-boot@lists.denx.de
> Subject: Boot from 64-bit memory address?
>
> Hi,
>
> Is it possible to boot from a DRAM memory address beyond the 32-bit boundary? 
> I'm trying to configure a new RISC-V board which has 2GB of DRAM starting at 
> offset 0x40__. I started from the settings for an existing RISC-V 
> board and made

I think it is possible to boot from a DRAM memory beyond the 32-bit
boundary. But maybe you need to modify some code to achieve that.
I have tried to boot an internal AE350-like platform whose DRAM base
is at 0x4.

adjustments for my HW, but when I try to boot, I run into an "out of
memory" error.
>
> From 
> https://u-boot.readthedocs.io/en/latest/develop/uefi/u-boot_on_efi.html#tables
>  I noticed that U-Boot will only use "conventional" memory which is 4GB and 
> below, so it seems like this may not be possible? Looking through the repo, I 
> also noticed that nearly every device is configuring settings like 
> CONFIG_SYS_LOAD_ADDR with a 32-bit value, so I haven't found any examples to 
> emulate for my use case.

CONFIG_SYS_LOAD_ADDR is not important. Maybe you shall notice
CONFIG_SYS_TEXT_BASE and CONFIG_SPL_OPENSBI_LOAD_ADDR which will be
parsed from binman.dtsi
You can change them like this:
load = /bits/64 ;
load = /bits/64 ;

>
> I'm hoping someone knows the mistake I'm making or can confirm that this 
> isn't possible. Appreciate the help.
>
> Best,
> Phil
>
>
> Below is the output from U-Boot:
>
> U-Boot SPL 2022.07 (Feb 23 2023 - 00:50:44 +) Trying to boot from RAM
>
> OpenSBI v1.1
>_  _
>   / __ \  / |  _ \_   _|
> | |  | |_ __   ___ _ __ | (___ | |_) || |
> | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | | __| | |_) |  __/ | | |) |
> | ||_) || |_
>   \/| .__/ \___|_| |_|_/|/_|
> | |
> |_|
>
> Platform Name : test,test
> Platform Features : medeleg
> Platform HART Count   : 1
> Platform IPI Device   : aclint-mswi
> Platform Timer Device : aclint-mtimer @ 100Hz
> Platform Console Device   : uart8250
> Platform HSM Device   : ---
> Platform Reboot Device: ---
> Platform Shutdown Device  : ---
> Firmware Base : 0x8000
> Firmware Size : 276 KB
> Runtime SBI Version   : 1.0
>
> Domain0 Name  : root
> Domain0 Boot HART : 0
> Domain0 HARTs : 0*
> Domain0 Region00  : 0x0200-0x0200 (I)
> Domain0 Region01  : 0x8000-0x8007 ()
> Domain0 Region02  : 0x-0x (R,W,X)
> Domain0 Next Address  : 0x00400120
> Domain0 Next Arg1 : 0x004001267830
> Domain0 Next Mode : S-mode
> Domain0 SysReset  : yes
>
> Boot HART ID  : 0
> Boot HART Domain  : root
> Boot HART Priv Version: v1.10
> Boot HART Base ISA: rv64imafdcb
> Boot HART ISA Extensions  : time
> Boot HART PMP Count   : 8
> Boot HART PMP Granularity : 4
> Boot HART PMP Address Bits: 54
> Boot HART MHPM Count  : 0
> Boot HART MIDELEG : 0x0222
> Boot HART MEDELEG : 0xb109
>
>
> U-Boot 2022.07 (Feb 23 2023 - 00:50:44 +)
>
> CPU:   rv64imafdc
> Model: test,test
> DRAM:  2 GiB
> Core:  11 devices, 8 uclasses, devicetree: separate
> ERROR: Out of memory
> Loading Environment from nowhere... OK
> In:serial@13140
> Out:   serial@13140
> Err:   serial@13140
> Model: test,test
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> Moving Image from 0x400600 to 0x400020, end=4000b01c8c ## Flattened 
> Device Tree blob at ff76a1d0
>Booting using the fdt blob at 0xff76a1d0
> ERROR: Failed to allocate 0x100 bytes below 0x1.

Can you dig in where to print this ERROR ?

Thanks,
Rick

> ramdisk - allocation error


Re: Boot from 64-bit memory address?

2023-02-22 Thread Conor Dooley



On 23 February 2023 01:21:01 GMT, "Bernard, Philip"  
wrote:
>Hi,
>
>Is it possible to boot from a DRAM memory address beyond the 32-bit boundary? 
>I'm trying to configure a new RISC-V board which has 2GB of DRAM starting at 
>offset 0x40__. I started from the settings for an existing RISC-V 
>board and made adjustments for my HW, but when I try to boot, I run into an 
>"out of memory" error.
>
>From 
>https://u-boot.readthedocs.io/en/latest/develop/uefi/u-boot_on_efi.html#tables 
>I noticed that U-Boot will only use "conventional" memory which is 4GB and 
>below, so it seems like this may not be possible? Looking through the repo, I 
>also noticed that nearly every device is configuring settings like 
>CONFIG_SYS_LOAD_ADDR with a 32-bit value, so I haven't found any examples to 
>emulate for my use case.
>
>I'm hoping someone knows the mistake I'm making or can confirm that this isn't 
>possible. Appreciate the help.

Whether you get u-boot working or not is one thing,
but there's a load of knock on from not having any
32-bit ddr. 
If you're using the generic CPU, check out its dram.c, there's a check there 
that forces ram_top
to 32-bit.
Other than that, it's mainly a case of swapping the config options to suitable 
values.
We've been doing 64-bit only for a while out of tree for icicle kit, and it 
does just work.
The caveat is if you intend using Linux, the dma code and some pci devices
are not going to appreciate it!
(Apologies for the formatting, mobile makes it hard)

>
>Best,
>Phil
>
>
>Below is the output from U-Boot:
>
>U-Boot SPL 2022.07 (Feb 23 2023 - 00:50:44 +)
>Trying to boot from RAM
>
>OpenSBI v1.1
>   _  _
>  / __ \  / |  _ \_   _|
>| |  | |_ __   ___ _ __ | (___ | |_) || |
>| |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
>| |__| | |_) |  __/ | | |) | |_) || |_
>  \/| .__/ \___|_| |_|_/|/_|
>| |
>|_|
>
>Platform Name : test,test
>Platform Features : medeleg
>Platform HART Count   : 1
>Platform IPI Device   : aclint-mswi
>Platform Timer Device : aclint-mtimer @ 100Hz
>Platform Console Device   : uart8250
>Platform HSM Device   : ---
>Platform Reboot Device: ---
>Platform Shutdown Device  : ---
>Firmware Base : 0x8000
>Firmware Size : 276 KB
>Runtime SBI Version   : 1.0
>
>Domain0 Name  : root
>Domain0 Boot HART : 0
>Domain0 HARTs : 0*
>Domain0 Region00  : 0x0200-0x0200 (I)
>Domain0 Region01  : 0x8000-0x8007 ()
>Domain0 Region02  : 0x-0x (R,W,X)
>Domain0 Next Address  : 0x00400120
>Domain0 Next Arg1 : 0x004001267830
>Domain0 Next Mode : S-mode
>Domain0 SysReset  : yes
>
>Boot HART ID  : 0
>Boot HART Domain  : root
>Boot HART Priv Version: v1.10
>Boot HART Base ISA: rv64imafdcb
>Boot HART ISA Extensions  : time
>Boot HART PMP Count   : 8
>Boot HART PMP Granularity : 4
>Boot HART PMP Address Bits: 54
>Boot HART MHPM Count  : 0
>Boot HART MIDELEG : 0x0222
>Boot HART MEDELEG : 0xb109
>
>
>U-Boot 2022.07 (Feb 23 2023 - 00:50:44 +)
>
>CPU:   rv64imafdc
>Model: test,test
>DRAM:  2 GiB
>Core:  11 devices, 8 uclasses, devicetree: separate
>ERROR: Out of memory
>Loading Environment from nowhere... OK
>In:serial@13140
>Out:   serial@13140
>Err:   serial@13140
>Model: test,test
>Net:   No ethernet found.
>Hit any key to stop autoboot:  0
>Moving Image from 0x400600 to 0x400020, end=4000b01c8c
>## Flattened Device Tree blob at ff76a1d0
>   Booting using the fdt blob at 0xff76a1d0
>ERROR: Failed to allocate 0x100 bytes below 0x1.
>ramdisk - allocation error


Boot from 64-bit memory address?

2023-02-22 Thread Bernard, Philip
Hi,

Is it possible to boot from a DRAM memory address beyond the 32-bit boundary? 
I'm trying to configure a new RISC-V board which has 2GB of DRAM starting at 
offset 0x40__. I started from the settings for an existing RISC-V board 
and made adjustments for my HW, but when I try to boot, I run into an "out of 
memory" error.

>From 
>https://u-boot.readthedocs.io/en/latest/develop/uefi/u-boot_on_efi.html#tables 
>I noticed that U-Boot will only use "conventional" memory which is 4GB and 
>below, so it seems like this may not be possible? Looking through the repo, I 
>also noticed that nearly every device is configuring settings like 
>CONFIG_SYS_LOAD_ADDR with a 32-bit value, so I haven't found any examples to 
>emulate for my use case.

I'm hoping someone knows the mistake I'm making or can confirm that this isn't 
possible. Appreciate the help.

Best,
Phil


Below is the output from U-Boot:

U-Boot SPL 2022.07 (Feb 23 2023 - 00:50:44 +)
Trying to boot from RAM

OpenSBI v1.1
   _  _
  / __ \  / |  _ \_   _|
| |  | |_ __   ___ _ __ | (___ | |_) || |
| |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
| |__| | |_) |  __/ | | |) | |_) || |_
  \/| .__/ \___|_| |_|_/|/_|
| |
|_|

Platform Name : test,test
Platform Features : medeleg
Platform HART Count   : 1
Platform IPI Device   : aclint-mswi
Platform Timer Device : aclint-mtimer @ 100Hz
Platform Console Device   : uart8250
Platform HSM Device   : ---
Platform Reboot Device: ---
Platform Shutdown Device  : ---
Firmware Base : 0x8000
Firmware Size : 276 KB
Runtime SBI Version   : 1.0

Domain0 Name  : root
Domain0 Boot HART : 0
Domain0 HARTs : 0*
Domain0 Region00  : 0x0200-0x0200 (I)
Domain0 Region01  : 0x8000-0x8007 ()
Domain0 Region02  : 0x-0x (R,W,X)
Domain0 Next Address  : 0x00400120
Domain0 Next Arg1 : 0x004001267830
Domain0 Next Mode : S-mode
Domain0 SysReset  : yes

Boot HART ID  : 0
Boot HART Domain  : root
Boot HART Priv Version: v1.10
Boot HART Base ISA: rv64imafdcb
Boot HART ISA Extensions  : time
Boot HART PMP Count   : 8
Boot HART PMP Granularity : 4
Boot HART PMP Address Bits: 54
Boot HART MHPM Count  : 0
Boot HART MIDELEG : 0x0222
Boot HART MEDELEG : 0xb109


U-Boot 2022.07 (Feb 23 2023 - 00:50:44 +)

CPU:   rv64imafdc
Model: test,test
DRAM:  2 GiB
Core:  11 devices, 8 uclasses, devicetree: separate
ERROR: Out of memory
Loading Environment from nowhere... OK
In:serial@13140
Out:   serial@13140
Err:   serial@13140
Model: test,test
Net:   No ethernet found.
Hit any key to stop autoboot:  0
Moving Image from 0x400600 to 0x400020, end=4000b01c8c
## Flattened Device Tree blob at ff76a1d0
   Booting using the fdt blob at 0xff76a1d0
ERROR: Failed to allocate 0x100 bytes below 0x1.
ramdisk - allocation error