I used today's rawhide image from https://dl.fedoraproject.org/pub/fedora/linux/releases/32/Workstation/aarch64/images/ and get to the Welcome screen but then neither USB keyboard nor mouse work and I am stuck on my RPi4/8GB.
cma=256M@704M has no effect. On Mon, Aug 3, 2020 at 9:28 AM Peter Robinson <[email protected]> wrote: > On Sun, Aug 2, 2020 at 9:20 PM <[email protected]> wrote: > > > > Further to those Fedora32 efforts described as below. I have been quite > happily using the > > > > EFI/fedora/grub.cfg > > EFI/fedora/grubenv > > cma=256M@704M > > > > settings on my RPi4 w/ 4GB. Now that I purchased a new RPi4 w/ 8GB they > seem not to work any more (I get onto Gnome Desktop but moving the move > blanks the screen) because I think that this space needs to be reserved at > another address. > > > > Any advice? Thanks! > > You'll likely need the 5.8 kernel, there's been massive issues around > DMA/CMA upstream due to the "architecture" of the rpi4 with 4+gb of > RAM, there was a fix that was very nearly reverted in 5.8 but luckily > they found the issue at the last minute. > > > Regards, Thomas B > > > > ---------- Forwarded message --------- > > From: Thomas H.P. Andersen <[email protected]> > > Date: Thu, May 7, 2020 at 4:03 PM > > Subject: [fedora-arm] Re: CMA on raspberry pi 4 > > To: Peter Robinson <[email protected]> > > Cc: Fedora List <[email protected]> > > > > On Thu, May 7, 2020 at 11:23 AM Peter Robinson <[email protected]> > wrote: > >> > >> Hi Thomas, > >> > >> >> > 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. > >> >> > >> >> Right, because of this it may be able to be set in config.txt, I seem > >> >> to remember seeing this somewhere but as we don't support accelerated > >> >> graphics on the RPi4 I've not looked. I don't believe the > >> >> unaccelerated graphics uses the CMA so for the current situation you > >> >> may be able to drop it. > >> >> > >> >> If it's an option to set it in config.txt we need to work out if this > >> >> is a general option that works for all the rpi models or if it's > >> >> explicitly for the RPi4, if the later we really need to report and > get > >> >> the bug fixed because we aim to produce generic images which "just > >> >> work" across all the rpi devices, anything else just makes it a > >> >> support nightmare for people like myself that attempt to support it > >> >> and it would be less work just not to support the RPi4 at all TBH. > >> >> > >> >> > 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. > >> >> > >> >> Not sure what you mean by "upstream" here, we use an almost pure > >> >> upstream Linus kernel, if you mean the "Raspberry Pi Foundation" and > >> >> their kernel, that's a downstream fork of Linus's kernel. They also > >> >> have a lot of other patches and use a different desktop, GNOME from > >> >> experience and working with them then RPi upstream GPU maintainer we > >> >> worked out GNOME needed the 256Mb allocation but desktops like XFCE > >> >> use a lot less (~192Mb if memory serves) and Raspbian uses a light > >> >> desktop so I suspect they allocate a lot less. > >> > > >> > > >> > I meant upstream as in linus tree. I noticed some comments in the > review of rpi4 ustreaming patches where various cma sizes were tested. Thus > I suspected that it could be related to downstream patches. If we do not > carry any relevant then perhaps the issue could related to setting the cma > both in config.txt and on the commandline? > >> > > >> > Raspbian uses 256MB via kernel commandline and the config.txt in > /boot does not have any setting for cma. The cma starts at 0x1ec00000 so in > the lower 1gb. But it is a 4.19 kernel + patches so not really useful to > look at for this specific issue. > >> > >> Just as a follow up to this it looks like Raspbian has just (finally?) > >> rebased to the 5.4 LTS kernel [1] in their downstream kernel and > >> looking through the change they've done what I thought would be needed > >> and provided a means of dealing with CMA via dt-overlays, I wasn't > >> sure whether they would have done it via a config.txt cma=XX or a > >> dt-overlay option, I've literally just looked at the diff but it looks > >> like for F-33 we can investigate dealing with this in the config.txt > >> rather than kernel command line. > >> > >> I've literally just looked at the diff here and won't have time to > >> investigate this until later this month, which actually is probably > >> just fine to give a few more firmware releases to settle the rebase > >> down, but if someone wants to start looking further do reach out. > > > > > > That is quite a commit to dive into :) I will take a look at it. > > > > For info here is what I have found since my last email: > > > > I attached the serial console to check what happens when we hang at boot > with the cma setting. We allocate the 256 MB at 0xEC000000. That again > leaves 64MB at the end but at the end of the 4GB this time. > > With [3] the logic is that users should have full control of the cma > allocation when using the setting on the commandline. The idea makes sense > but it is unfortunate that specifying only a cma size also leads to > ignoring the valid allocation range specified in dt for rpi4. The commit > was introduced in 5.6 and thus is not in the raspberrypi kernel. I guess > this will still be a problem then if we continue to set the cma on the > commandline? > > > > [3] > https://github.com/torvalds/linux/commit/8c8c5a4994a306c217fd061cbfc5903399fd4c1c#diff-84340431a63cf47e087c08b7f81bab49 > > > >> > >> Peter > >> > >> [1] > https://github.com/raspberrypi/firmware/commit/7eff9f6774bb43bfd61e749a0b45ffddc98c2311 > >> [2] > https://github.com/raspberrypi/firmware/commit/7eff9f6774bb43bfd61e749a0b45ffddc98c2311#diff-32265084aeae5fd34fbaf894f22fb20fR553 > > > > _______________________________________________ > > arm mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > 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/[email protected] > > _______________________________________________ > > arm mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > 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/[email protected] >
_______________________________________________ arm mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
