"workaround" is a slight understatement. The RPi works and
performs very well with it on Fedora 32!
Please keep the thread on topic. If you think it performs "very well"
you've either got very low expectations or will be thrilled when it's
got accelerated graphics. There's a LONG way to go!
> On Tue, Apr 28, 2020 at 2:54 PM Thomas H.P. Andersen <phomes(a)gmail.com> wrote:
>>
>>
>>
>> On Mon, Apr 27, 2020 at 6:49 PM <ng0177(a)gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> Thomas A's advice works on my RPi 4B and is prerequisite for using the
Workstation 32 edition on it.
>>
>>
>> Thanks for testing it. It is still just a work-around and we need to find a real
fix for this. It does hint to what real problem could be though. Debugging further is
difficult as the usb controller is one of the things that break. I have a ordered a cable
for serial connection and will continue to look into it when it arrives.
>>
>>>
>>> Here is my cookbook:
>>>
>>>
https://dl.fedoraproject.org/pub/fedora-secondary/development/32/Workstat...
>>>
>>> xzcat ./ | sudo dd status=progress bs=1M of=/dev/sdx && sync
>>
>>
>> Consider taking a look at arm-image-installer. I does mostly the same but has
some convenient extra features.
>>>
>>>
>>> EFI/fedora/grub.cfg
>>> EFI/fedora/grubenv
>>> cma=256M@704M
>>>
>>> I end up with an apparenlty fully functional Fedora and after deactivation of
animation effects using Tweaks, Gnome is not (very) sluggish and works fine for me.
>>>
>>> Cheers, Thomas B
>>>
>>>
>>> On Thu, Apr 23, 2020 at 5:46 PM Thomas H.P. Andersen <phomes(a)gmail.com>
wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have looked into the CMA setting issue a bit. This is what I have found
so far.
>>>>
>>>> The rpi4 needs CMA to be in ZONE_DMA (lower 1GB of memory) as this is the
only area that the peripherals on the rpi4 can address.
>>>>
>>>> The DT sets the allowed range to allocate the CMA from
(arch/arm/boot/dts/bcm2711.dtsi#L869), but it seems to not work here. What does work is
instead to set the offset manually. I replaced "cma=256MB" with
"cma=256M@704M" and then it boots. Note that it has to be 256M instead of
256MB.
>>>>
>>>> Removing the cma option on the command line was known as a workaround.
Without that we would fall back to the build config of 64MB cma which was located at
offset 0x38000000. This left 64MB at the end of ZONE_DMA, and I chose offset 704M so that
those 64MB would still be free. Not sure if that is needed or not. The crashkernel needs
to be in ZONE_DMA as well but it seems to be set to 0 size.
>>>>
>>>> I have tested on 5.7 rc2 from rawhide.
>>>>
>>>> This probably belongs in a bug report. What would be the correct place to
file that? From what I can tell upstream has been tested with cma settings without
problems (as long as the requested CMA size can fit in ZONE_DMA). From that it seems like
fedora-specific issue. Not sure though.
>>>>
>>>> Cheers,
>>>> Thomas
>>>> _______________________________________________
>>>> arm mailing list -- arm(a)lists.fedoraproject.org
>>>> To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org
>>>> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>> List Archives:
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org
>
> _______________________________________________
> arm mailing list -- arm(a)lists.fedoraproject.org
> To unsubscribe send an email to arm-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org