[U-Boot] [PATCH] Set ramdisk_addr_r to a higher address location on meson-gxbb.

[Vagrant Cascadian <vagrant@debian.org>]

On 2017-04-12, Vagrant Cascadian wrote:
> On 2017-04-12, Andreas Färber wrote:
>> Am 12.04.2017 um 23:28 schrieb Vagrant Cascadian:
>>> Set ramdisk_addr_r to 0x20000000, otherwise it may conflict with
>>> kernel_addr_r location (0x01080000) with a moderately large kernel.
> ...
>>> diff --git a/include/configs/meson-gxbb-common.h b/include/configs/meson-gxbb-common.h
>>> index cc2b5b61d4..32602cb7c2 100644
>>> --- a/include/configs/meson-gxbb-common.h
>>> +++ b/include/configs/meson-gxbb-common.h
>>> @@ -48,7 +48,7 @@
>>>  	"scriptaddr=0x1f000000\0" \
>>>  	"kernel_addr_r=0x01080000\0" \
>>>  	"pxefile_addr_r=0x01080000\0" \
>>> -	"ramdisk_addr_r=0x10000000\0" \
>>> +	"ramdisk_addr_r=0x20000000\0" \
>>
>> So that's at 512 MiB. Have you checked for any S905 devices (e.g., TV
>> boxes) with little RAM?
>
> I didn't. I just picked a value out of the air and tried it. :)

The other option is to lower the kernel_addr_r and fdt_addr_r locations,
but I'm not sure how much lower they can get, if at all.


> I just now tested with 0x12000000 and it worked, where 0x10000000
> consistantly failed.

After some more experimenting, with ramdisk_addr_r=0x10100000 it still
fails to load, with ramdisk_addr_r=0x10200000 it works, at least with
the current kernel I'm testing with:

=> setenv ramdisk_addr_r 0x10100000
=> boot
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2177 bytes read in 16 ms (132.8 KiB/s)
## Executing script at 1f000000
14819840 bytes read in 737 ms (19.2 MiB/s)
16119 bytes read in 38 ms (414.1 KiB/s)
17551127 bytes read in 873 ms (19.2 MiB/s)
Booting Debian 4.11.0-rc6+ from mmc 0:1...
## Flattened Device Tree blob at 01000000
   Booting using the fdt blob at 0x1000000
   Loading Ramdisk to 7ce9c000, end 7df58f17 ... OK
   Loading Device Tree to 000000007ce95000, end 000000007ce9bef6 ... OK

Starting kernel ...

And then it just hangs.

The kernel image I'm booting is almost 15MB, uncompressed. I'm guessing
if "booti" would support compressed kernels, this would allieviate the
problem, but it will take some time before that's common (on Debian, at
least).


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170416/4bc7e866/attachment.sig>