Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1559298 > unrolled thread
| Started by | Andreas Färber <afaerber@suse.de> |
|---|---|
| First post | 2017-01-15 16:50 +0100 |
| Last post | 2017-01-16 15:10 +0100 |
| Articles | 3 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range Andreas Färber <afaerber@suse.de> - 2017-01-15 16:50 +0100
Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range Neil Armstrong <narmstrong@baylibre.com> - 2017-01-16 11:30 +0100
Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range Andreas Färber <afaerber@suse.de> - 2017-01-16 15:10 +0100
| From | Andreas Färber <afaerber@suse.de> |
|---|---|
| Date | 2017-01-15 16:50 +0100 |
| Subject | Re: [RFT PATCH] ARM64: dts: meson-gxbb: Add reserved memory zone and usable memory range |
| Message-ID | <sZVeb-4eg-21@gated-at.bofh.it> |
Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt:
> it really makes a difference if we write
>
> memory@0 {
> device_type = "memory";
> linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
> };
>
> or
>
> memory@0 {
> device_type = "memory";
> reg = <0x0 0x1000000 0x0 0x7f000000>;
> };
>
> The second version leads to failure of the Odroid C2.
>
> When I looked at /sys/firmware/fdt I saw this difference:
>
> --- fails
> +++ works
>
> memory@0 {
> - device_type = "memory";
> reg = <0x0 0x0 0x0 0x78000000>;
> + device_type = "memory";
> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
> };
>
> I found the following sentence in the NXP forum:
> In case you want to overwrite the memory usage passed from u-boot, you
> can use "linux,usable-memory".
> https://community.nxp.com/thread/382284
The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot
instead of forcing the creation of unnecessary new .dts files onto
everyone due to hardcoded linux,usable-memory properties. In fact, it
already reserves 0x1000000, so it seems you are merely using an older
U-Boot.
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39
I would bet that the upper limit is unrelated here.
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
[toc] | [next] | [standalone]
| From | Neil Armstrong <narmstrong@baylibre.com> |
|---|---|
| Date | 2017-01-16 11:30 +0100 |
| Message-ID | <t0cI2-7wv-11@gated-at.bofh.it> |
| In reply to | #1559298 |
On 01/15/2017 04:44 PM, Andreas Färber wrote:
> Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt:
>> it really makes a difference if we write
>>
>> memory@0 {
>> device_type = "memory";
>> linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>> };
>>
>> or
>>
>> memory@0 {
>> device_type = "memory";
>> reg = <0x0 0x1000000 0x0 0x7f000000>;
>> };
>>
>> The second version leads to failure of the Odroid C2.
>>
>> When I looked at /sys/firmware/fdt I saw this difference:
>>
>> --- fails
>> +++ works
>>
>> memory@0 {
>> - device_type = "memory";
>> reg = <0x0 0x0 0x0 0x78000000>;
>> + device_type = "memory";
>> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>> };
>>
>> I found the following sentence in the NXP forum:
>> In case you want to overwrite the memory usage passed from u-boot, you
>> can use "linux,usable-memory".
>> https://community.nxp.com/thread/382284
>
> The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot
> instead of forcing the creation of unnecessary new .dts files onto
> everyone due to hardcoded linux,usable-memory properties. In fact, it
> already reserves 0x1000000, so it seems you are merely using an older
> U-Boot.
>
> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39
>
> I would bet that the upper limit is unrelated here.
>
> Regards,
> Andreas
>
Hi Andreas,
I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has
a lot of u-boot version in the field, and the Odroid-C2 is part of this.
Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel should work using
any U-boot version even with the one provided by Amlogic on their openlinux distribution channel.
Neil
[toc] | [prev] | [next] | [standalone]
| From | Andreas Färber <afaerber@suse.de> |
|---|---|
| Date | 2017-01-16 15:10 +0100 |
| Message-ID | <t0g8W-1qX-7@gated-at.bofh.it> |
| In reply to | #1559604 |
Am 16.01.2017 um 11:26 schrieb Neil Armstrong:
> On 01/15/2017 04:44 PM, Andreas Färber wrote:
>> Am 23.12.2016 um 10:42 schrieb Heinrich Schuchardt:
>>> it really makes a difference if we write
>>>
>>> memory@0 {
>>> device_type = "memory";
>>> linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>>> };
>>>
>>> or
>>>
>>> memory@0 {
>>> device_type = "memory";
>>> reg = <0x0 0x1000000 0x0 0x7f000000>;
>>> };
>>>
>>> The second version leads to failure of the Odroid C2.
>>>
>>> When I looked at /sys/firmware/fdt I saw this difference:
>>>
>>> --- fails
>>> +++ works
>>>
>>> memory@0 {
>>> - device_type = "memory";
>>> reg = <0x0 0x0 0x0 0x78000000>;
>>> + device_type = "memory";
>>> + linux,usable-memory = <0x0 0x1000000 0x0 0x7f000000>;
>>> };
>>>
>>> I found the following sentence in the NXP forum:
>>> In case you want to overwrite the memory usage passed from u-boot, you
>>> can use "linux,usable-memory".
>>> https://community.nxp.com/thread/382284
>>
>> The Odroid-C2 is in mainline U-Boot. Please submit a patch to U-Boot
>> instead of forcing the creation of unnecessary new .dts files onto
>> everyone due to hardcoded linux,usable-memory properties. In fact, it
>> already reserves 0x1000000, so it seems you are merely using an older
>> U-Boot.
>>
>> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-meson/board.c;h=f159cbf849f75ab046e6f3a025bbc97c0bcfd59d;hb=HEAD#l39
>>
>> I would bet that the upper limit is unrelated here.
>>
>> Regards,
>> Andreas
>>
>
> Hi Andreas,
>
> I really disagree about relying on any work or properties added by any bootloader here, Amlogic SoCs has
> a lot of u-boot version in the field, and the Odroid-C2 is part of this.
>
> Even if Odroid-c2 is in mainline U-Boot or not, the mainline Linux kernel should work using
> any U-boot version even with the one provided by Amlogic on their openlinux distribution channel.
That is not the position of the kernel maintainers though. They
deliberately rely on timers being enabled before entering Linux, which
broke my afboot-stm32 (which I could fix) as well as s5pv210 and vf610
based platforms by F+S (which remain broken to date).
And I documented how to chainload mainline U-Boot from downstream
Amlogic U-Boot, so it is easily fixable on Meson. The only thing missing
is Carlo resubmitting his MMC patches.
A bug somewhere does not justify breaking the whole Meson-gx* .dts
design for everyone, especially not without CC'ing me as the original
creator!
Regards,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web