Re: Fwd: Re: CMA on raspberry pi 4
by ng0177＠gmail.com
I used today's rawhide image from
https://dl.fedoraproject.org/pub/fedora/linux/releases/32/Workstation/aar...
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 <pbrobinson(a)gmail.com> wrote:
> On Sun, Aug 2, 2020 at 9:20 PM <ng0177(a)gmail.com> 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 <phomes(a)gmail.com>
> > Date: Thu, May 7, 2020 at 4:03 PM
> > Subject: [fedora-arm] Re: CMA on raspberry pi 4
> > To: Peter Robinson <pbrobinson(a)gmail.com>
> > Cc: Fedora List <arm(a)lists.fedoraproject.org>
> >
> > On Thu, May 7, 2020 at 11:23 AM Peter Robinson <pbrobinson(a)gmail.com>
> 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/8c8c5a4994a306c217fd061cbfc59033...
> >
> >>
> >> Peter
> >>
> >> [1]
> https://github.com/raspberrypi/firmware/commit/7eff9f6774bb43bfd61e749a0b...
> >> [2]
> https://github.com/raspberrypi/firmware/commit/7eff9f6774bb43bfd61e749a0b...
> >
> > _______________________________________________
> > 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
>
3 years, 9 months
Re: Fwd: Re: CMA on raspberry pi 4
by Peter Robinson
On Sun, Aug 2, 2020 at 9:20 PM <ng0177(a)gmail.com> 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 <phomes(a)gmail.com>
> Date: Thu, May 7, 2020 at 4:03 PM
> Subject: [fedora-arm] Re: CMA on raspberry pi 4
> To: Peter Robinson <pbrobinson(a)gmail.com>
> Cc: Fedora List <arm(a)lists.fedoraproject.org>
>
> On Thu, May 7, 2020 at 11:23 AM Peter Robinson <pbrobinson(a)gmail.com> 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/8c8c5a4994a306c217fd061cbfc59033...
>
>>
>> Peter
>>
>> [1] https://github.com/raspberrypi/firmware/commit/7eff9f6774bb43bfd61e749a0b...
>> [2] https://github.com/raspberrypi/firmware/commit/7eff9f6774bb43bfd61e749a0b...
>
> _______________________________________________
> 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
3 years, 9 months
Fwd: Re: CMA on raspberry pi 4
by ng0177＠gmail.com
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!
Regards, Thomas B
---------- Forwarded message ---------
From: Thomas H.P. Andersen <phomes(a)gmail.com>
Date: Thu, May 7, 2020 at 4:03 PM
Subject: [fedora-arm] Re: CMA on raspberry pi 4
To: Peter Robinson <pbrobinson(a)gmail.com>
Cc: Fedora List <arm(a)lists.fedoraproject.org>
On Thu, May 7, 2020 at 11:23 AM Peter Robinson <pbrobinson(a)gmail.com> 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/8c8c5a4994a306c217fd061cbfc59033...
> Peter
>
> [1]
> https://github.com/raspberrypi/firmware/commit/7eff9f6774bb43bfd61e749a0b...
> [2]
> https://github.com/raspberrypi/firmware/commit/7eff9f6774bb43bfd61e749a0b...
>
_______________________________________________
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
3 years, 9 months
Re: Fedora 32 Raspberry pi 4 status
by berend
I'm running two of them without GUI without a problem, using a
straightforward F32 install, and planning to install another.
During the betas not all live images worked, I assume all the latest
live images work.
I'm running one of SSD, but it still uses a SD card for /boot and grub.
The other is all on SD card. There is a beta firmware update to boot
of USB instead, and I'd like to try that.
I have run the GUI, but it wasn't always stable at 1920x1080. It
frequently came up slightly wrong (from memory: 1800x900 or something)
I believe Fedora doesn't come with some of the closed drivers, and so
video performance suffers. That doesn't bother me for my use case.
So basically similar to the Pi 3.
3 years, 9 months
Re: arm-image-installer with a qemu disk image
by Sam Varshavchik
Peter Robinson writes:
> On Tue, Jul 28, 2020 at 12:01 AM Sam Varshavchik <mrsam(a)courier-mta.com>
> wrote:
> >
> > Paul Whalen writes:
> >
> > >
> > >
> > > ----- Original Message -----
> > > > > I'm trying to install an aarch64 guest VM on F32 x86-64 host.
> > > > >
> > > > > I created a suitably large disk image, then proceeded to:
> > > >
> > > > <snip>
> > > >
> > > > > I surmize that arm-image-installer expected a real /dev to write to,
> > > > > instead of what is effectively a plain fie, so it failed to mount the
> > > disk
> > > > > image. I suppose that what it needs to do is a loopback mount,
> instead.
> > > Is
> > > > > there a way to do this?
> > > >
> > > > The sole reason for arm-image-installer is to set up the device
> > > > specific firmware if the devices require it to been on the same media
> > > > as the OS. This is not the case with virt as it has dedicated
> > > > tianocore firmware which is in a completely separate location to the
> > > > OS virtual disk image.
> >
> > virt-manager politely offered me an option to set up a raspberry pi 2 and 3
> > VM, which seems like a perfect match for the corresponding options to arm-
> > image-installer.
>
> You definitely don't want that option, you want one of the virt ones,
> it's likely easier to do it via cmd line
I didn't, I chose the "virt" VM to create, but, as I said, I wound up with
VM with no video hardware, no Spice server, and no X, and the following in
/var/log/Xorg.0.log:
352.678] (EE)
Fatal server error:
[ 352.683] (EE) no screens found(EE)
[ 352.688] (EE)
Please consult the Fedora Project support
at http://wiki.x.org
for help.
[ 352.692] (EE) Please also check the log file at "/var/log/Xorg.0.log"
for additional information.
[ 352.695] (EE)
[ 352.743] (EE) Server terminated with error (1). Closing log file.
I'm trying various combinations to see if this can be fixed. If anyone is
successfully running X on arm, in a qemu VM, can you share your
configuration?
3 years, 9 months
Re: arm-image-installer with a qemu disk image
by Peter Robinson
On Tue, Jul 28, 2020 at 12:01 AM Sam Varshavchik <mrsam(a)courier-mta.com> wrote:
>
> Paul Whalen writes:
>
> >
> >
> > ----- Original Message -----
> > > > I'm trying to install an aarch64 guest VM on F32 x86-64 host.
> > > >
> > > > I created a suitably large disk image, then proceeded to:
> > >
> > > <snip>
> > >
> > > > I surmize that arm-image-installer expected a real /dev to write to,
> > > > instead of what is effectively a plain fie, so it failed to mount the
> > disk
> > > > image. I suppose that what it needs to do is a loopback mount, instead.
> > Is
> > > > there a way to do this?
> > >
> > > The sole reason for arm-image-installer is to set up the device
> > > specific firmware if the devices require it to been on the same media
> > > as the OS. This is not the case with virt as it has dedicated
> > > tianocore firmware which is in a completely separate location to the
> > > OS virtual disk image.
>
> virt-manager politely offered me an option to set up a raspberry pi 2 and 3
> VM, which seems like a perfect match for the corresponding options to arm-
> image-installer.
You definitely don't want that option, you want one of the virt ones,
it's likely easier to do it via cmd line
> > >
> > > https://fedoraproject.org/wiki/QA:Testcase_Virt_ARM_on_x86
> >
> > The AArch64 page is here:
> > https://fedoraproject.org/wiki/QA:Testcase_Virt_AArch64_on_x86
>
> Both arm and aarch64 pages didn't quite match what happened to me.
>
> The download image for Fedora Workstation is a raw image, not an iso image:
>
> https://alt.fedoraproject.org/alt/
>
> Because of that the documentation on the arm page was a closer match to
> this, then the aarch64 page.
>
> Creating a new VM, based on the raw image, eventually concludes with the VM
> booting to a login prompt, without going into setup or prompting me to set
> up the root password, then the console demands the root login.
>
> Tried to boot to a rescue shell via a direct kernel boot, the instructions
> on the arm page for setting up a direct kernel boot mostly worked. virt-get-
> kernel worked. virt-cat didn't, whatever file currently has the kernel boot
> args it's no longer /etc/extlinux.conf. Using the suggested default of
> "console=ttyAMA0 rw root=LABEL=_/ rootwait" ended up booting the system
> about halfway until "Reached target Basic System", and the direct boot hangs
> at that point. Same results with "console=ttyAMA0 rw root=LABEL=_/ rd.break
> enforcing=0". The boot hangs with virt-manager showing a flatlined CPU
> utilization at about the 30% mark.
>
> Turned off direct kernel boot, and booted the VM normally, and the boot
> proceeds past that point, but then again I get the login prompt, without
> giving me the opportunity to set the root password.
>
> After some attempts, I was able to interrupt the grub menu. I never liked
> how, X years ago, the default timeout for grub was changed to be, basically,
> no timeout. Eventually, hitting cursor down as soon as the grub menu appears
> worked. I added 'rd.break enforcing=0' to the kernel command line, as per
> Google's instructions.
>
> This gave me a dracut shell. I remounted /sysroot read-write, ran passwd to
> change the root password, then retraced my steps.
>
> This allowed me to login as root, at the console. Once. After a subsequent
> reboot, I could not log in again, my password got rejected. To make a long
> story short, eventually I got to the root of it (pun intended):
>
> [root@arm ~]# ls -alZ /etc/shadow
> ----------. 1 root root system_u:object_r:unlabeled_t:s0 1240 Jul 27 15:53 /etc/shadow
> [root@arm ~]# restorecon /etc/shadow
> [root@arm ~]# ls -alZ /etc/shadow
> ----------. 1 root root system_u:object_r:shadow_t:s0 1240 Jul 27 15:53 /etc/shadow
>
> Looks like the first time I managed to get a rescue shell, in order to be
> able to set the root password, I ended up blowing away the context
> on /etc/shadow. That was the issue.
>
> Getting back on track, shouldn't the workstation image boot to X? Why, yes,
> "systemctl get-default" comes back with "graphical.target", but it boots to
> the console. I created the VM by following the instructions, but it appears
> that selecting "Fedora 32" as the OS to install, together with the aarch64
> image (and architecture), resulted in a VM without a a graphical device.
>
> I added the Spice driver. This resulted in a blank screen showing "Guest
> disabled display." Additionally, the keyboard no longer worked, on the grub
> menu.
>
> I tried to replicate the config from my other Windows VM, which has both
> spice and the video qxl drivers. The only video driver that the aarch64 vm
> accepted was virtio, and the result was the same, "Guest disabled display."
> I had to remove them both, in order to be able to use the grub menu.
>
> So, right now my bottom line is:
>
> Direct kernel boot hangs, possibly due to wrong command line options, and
> the instruction for extracting the ones that the image uses are out of date.
>
> Installing the raw image does not result in the setup wizard running, and
> letting me set the root password. I had to use a rescue shell to set the
> root password, and fix SELinux issues.
>
> The new VM did not have support for X, adding Spice and Video to the VM only
> had the result of losing the system console, entirely. This might be related
> to the issue of the setup wizard not getting run, since, IIRC, it's an X
> app; and it's possible that something that it should do, but never happened,
> ends up breaking console logins.
>
> So, what is needed to get X up and running, in a qemu VM? I'm going to
> install all the updates, and see if it makes any difference.
>
> _______________________________________________
> 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
3 years, 9 months
Re: arm-image-installer with a qemu disk image
by Sam Varshavchik
Paul Whalen writes:
>
>
> ----- Original Message -----
> > > I'm trying to install an aarch64 guest VM on F32 x86-64 host.
> > >
> > > I created a suitably large disk image, then proceeded to:
> >
> > <snip>
> >
> > > I surmize that arm-image-installer expected a real /dev to write to,
> > > instead of what is effectively a plain fie, so it failed to mount the
> disk
> > > image. I suppose that what it needs to do is a loopback mount, instead.
> Is
> > > there a way to do this?
> >
> > The sole reason for arm-image-installer is to set up the device
> > specific firmware if the devices require it to been on the same media
> > as the OS. This is not the case with virt as it has dedicated
> > tianocore firmware which is in a completely separate location to the
> > OS virtual disk image.
virt-manager politely offered me an option to set up a raspberry pi 2 and 3
VM, which seems like a perfect match for the corresponding options to arm-
image-installer.
> >
> > https://fedoraproject.org/wiki/QA:Testcase_Virt_ARM_on_x86
>
> The AArch64 page is here:
> https://fedoraproject.org/wiki/QA:Testcase_Virt_AArch64_on_x86
Both arm and aarch64 pages didn't quite match what happened to me.
The download image for Fedora Workstation is a raw image, not an iso image:
https://alt.fedoraproject.org/alt/
Because of that the documentation on the arm page was a closer match to
this, then the aarch64 page.
Creating a new VM, based on the raw image, eventually concludes with the VM
booting to a login prompt, without going into setup or prompting me to set
up the root password, then the console demands the root login.
Tried to boot to a rescue shell via a direct kernel boot, the instructions
on the arm page for setting up a direct kernel boot mostly worked. virt-get-
kernel worked. virt-cat didn't, whatever file currently has the kernel boot
args it's no longer /etc/extlinux.conf. Using the suggested default of
"console=ttyAMA0 rw root=LABEL=_/ rootwait" ended up booting the system
about halfway until "Reached target Basic System", and the direct boot hangs
at that point. Same results with "console=ttyAMA0 rw root=LABEL=_/ rd.break
enforcing=0". The boot hangs with virt-manager showing a flatlined CPU
utilization at about the 30% mark.
Turned off direct kernel boot, and booted the VM normally, and the boot
proceeds past that point, but then again I get the login prompt, without
giving me the opportunity to set the root password.
After some attempts, I was able to interrupt the grub menu. I never liked
how, X years ago, the default timeout for grub was changed to be, basically,
no timeout. Eventually, hitting cursor down as soon as the grub menu appears
worked. I added 'rd.break enforcing=0' to the kernel command line, as per
Google's instructions.
This gave me a dracut shell. I remounted /sysroot read-write, ran passwd to
change the root password, then retraced my steps.
This allowed me to login as root, at the console. Once. After a subsequent
reboot, I could not log in again, my password got rejected. To make a long
story short, eventually I got to the root of it (pun intended):
[root@arm ~]# ls -alZ /etc/shadow
----------. 1 root root system_u:object_r:unlabeled_t:s0 1240 Jul 27 15:53 /etc/shadow
[root@arm ~]# restorecon /etc/shadow
[root@arm ~]# ls -alZ /etc/shadow
----------. 1 root root system_u:object_r:shadow_t:s0 1240 Jul 27 15:53 /etc/shadow
Looks like the first time I managed to get a rescue shell, in order to be
able to set the root password, I ended up blowing away the context
on /etc/shadow. That was the issue.
Getting back on track, shouldn't the workstation image boot to X? Why, yes,
"systemctl get-default" comes back with "graphical.target", but it boots to
the console. I created the VM by following the instructions, but it appears
that selecting "Fedora 32" as the OS to install, together with the aarch64
image (and architecture), resulted in a VM without a a graphical device.
I added the Spice driver. This resulted in a blank screen showing "Guest
disabled display." Additionally, the keyboard no longer worked, on the grub
menu.
I tried to replicate the config from my other Windows VM, which has both
spice and the video qxl drivers. The only video driver that the aarch64 vm
accepted was virtio, and the result was the same, "Guest disabled display."
I had to remove them both, in order to be able to use the grub menu.
So, right now my bottom line is:
Direct kernel boot hangs, possibly due to wrong command line options, and
the instruction for extracting the ones that the image uses are out of date.
Installing the raw image does not result in the setup wizard running, and
letting me set the root password. I had to use a rescue shell to set the
root password, and fix SELinux issues.
The new VM did not have support for X, adding Spice and Video to the VM only
had the result of losing the system console, entirely. This might be related
to the issue of the setup wizard not getting run, since, IIRC, it's an X
app; and it's possible that something that it should do, but never happened,
ends up breaking console logins.
So, what is needed to get X up and running, in a qemu VM? I'm going to
install all the updates, and see if it makes any difference.
3 years, 9 months
Fedora ARM & AArch64 Status Meeting Minutes 2020-06-02
by Paul Whalen
========================================================
#fedora-meeting-2: Fedora ARM and AArch64 Status Meeting
========================================================
Meeting started by pwhalen at 15:02:37 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting-2/2020-06-02/fedora_arm_...
.
Meeting summary
---------------
* roll call (pwhalen, 15:02:37)
* 1) ==== Userspace Status ==== (pwhalen, 15:05:54)
* No new issues reported. (pwhalen, 15:07:48)
* 2) ==== Kernel Status ==== (pwhalen, 15:08:03)
* Latest kernel-5.7.0-1.fc33 (pwhalen, 15:08:03)
* LINK: https://koji.fedoraproject.org/koji/buildinfo?buildID=1519014
(pwhalen, 15:08:04)
* Please test and report any issues to the list or #fedora-arm.
(pwhalen, 15:10:41)
* 3) ==== Bootloader Status ==== (pwhalen, 15:12:27)
* New uboot expected this week, time permitting. (pwhalen, 15:16:12)
* 4) ==== Fedora 33 ==== (pwhalen, 15:17:03)
* systemd crashes when booting rawhide on armhfp (pwhalen, 15:17:18)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1831239
(pwhalen, 15:17:18)
* Aarch64 Pointer Authentication Change for Fedora 33 (pwhalen,
15:21:46)
* LINK:
https://fedoraproject.org/wiki/Changes/Aarch64_PointerAuthentication
(pwhalen, 15:21:47)
* 5) == Open Floor == (pwhalen, 15:29:25)
* LINK:
https://www.raspberrypi.org/blog/8gb-raspberry-pi-4-on-sale-now-at-75/
(pwhalen, 15:30:03)
Meeting ended at 15:34:37 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* pwhalen (41)
* jlinton (15)
* pbrobinson (7)
* zodbot (6)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
3 years, 11 months
Getting U-Boot after uart is enabled and trying to connect pollution sensors to my RPI 3 B+ running Fedora IoT 32 (latest update)
by Andrea Battaglia
Hi all,
I'm investigating and trying to make this work for a week now.
I wouldn't bother if I wasn't sure that digging deeper into this issue would take much more time than I have available at the moment.
So this is the scenario:
Hardware:
- Platform: RPi 3 B+
- Sensor (on the board): Pimoroni Enviro+
- Particulate Matter Sensor (connected to Enviro+): PMS5003
- SD Card: Sandisk 64Gb
Software: Fedora IoT 32 (just updated to the latest)
State of art:
I've successfully enabled and tested I2C and SPI. Drivers for the Enviro+ board run like a charm on a container manager by Podman.
The particulate Matter Sensor needs urat to be enabled, so I've made the fedora arm installer tool to enable uart for me.
Below the command issued to setup the SD card:
sudo fedora-arm-image-installer -y --image=/home/abattagl/Downloads/OS/Fedora-IoT-32-20200429.0.aarch64.raw.xz --target=rpi3 --media=/dev/sde --resizefs --addkey=/home/abattagl/.ssh/id_rsa.pub --norootpass --addconsole
I started testing uart from a fresh install and "rpm-ostree update" to avoid previous changes to the system affect the proper fuctioning of the serial port.
After the first boot of Fedora IoT and the system update I've shout id down and connected the Enviro+ sensors board.
The system booted properly after and I could see that both /dev/ttyS1 and /dev/ttyAMA0 are working at a boud rate of 9600:
[root@localhost ~]# stat /dev/ttyAMA0
File: /dev/ttyAMA0
Size: 0 Blocks: 0 IO Block: 4096 character special file
Device: 6h/6d Inode: 178 Links: 1 Device type: cc,40
Access: (0660/crw-rw----) Uid: ( 0/ root) Gid: ( 18/ dialout)
Context: system_u:object_r:tty_device_t:s0
Access: 2020-04-01 17:24:15.499999987 +0000
Modify: 2020-04-01 17:24:15.499999987 +0000
Change: 2020-04-01 17:24:15.499999987 +0000
Birth: -
[root@localhost ~]# stat /dev/ttyS0
File: /dev/ttyS0
Size: 0 Blocks: 0 IO Block: 4096 character special file
Device: 6h/6d Inode: 1113 Links: 1 Device type: 4,40
Access: (0660/crw-rw----) Uid: ( 0/ root) Gid: ( 18/ dialout)
Context: system_u:object_r:tty_device_t:s0
Access: 2020-04-01 17:24:15.249999987 +0000
Modify: 2020-04-01 17:24:15.249999987 +0000
Change: 2020-04-01 17:24:15.249999987 +0000
Birth: -
[root@localhost ~]# stat /dev/ttyS1
File: /dev/ttyS1
Size: 0 Blocks: 0 IO Block: 4096 character special file
Device: 6h/6d Inode: 1145 Links: 1 Device type: 4,41
Access: (0660/crw-rw----) Uid: ( 0/ root) Gid: ( 18/ dialout)
Context: system_u:object_r:tty_device_t:s0
Access: 2020-04-01 17:24:15.599999987 +0000
Modify: 2020-04-01 17:24:15.599999987 +0000
Change: 2020-04-01 17:24:15.599999987 +0000
Birth: -
The big issues happens when I connect the particulate matter sensor to the sensors board.
The RPi startup phase stops showing the U-Boot command prompt. and, of course, I haven't got the skills to debug/investigate that.
I can just guess I'm missing something.
A side note: using raspbian and the Pimoroni installation script, which, in turn, uses raspi-config to set up the system as the sensor expect, everything works fine and I'm able to query the particulate matter sensor using the python drivers.
I've tried to read the bash code of the raspi-config tool, but I'm not capable to understand ad deeply as I would.
The official documentation for the sensors says (quote):
"Note that if you're using this sensor with Raspberry Pi, then you'll need to make a couple of changes to its configuration. Type sudo raspi-config in the terminal and then under "Interfacing options" and "Serial" disable the login shell and enable the serial port hardware. Edit your /boot/config.txt file and add the lines enable_uart=1 and dtoverlay=pi3-miniuart-bt to the bottom of the file."
https://shop.pimoroni.com/products/pms5003-particulate-matter-sensor-with...
here is my config.txt file:
[root@localhost ~]# cat /boot/efi/config.txt
[pi3]
kernel=rpi3-u-boot.bin
[pi4]
kernel=rpi4-u-boot.bin
[all]
arm_64bit=1
dtparam=i2c_arm=on
dtparam=spi=on
bootcode_delay=1
gpu_mem=32
start_x=1
upstream_kernel=1
dtoverlay=upstream
dtoverlay=pi3-miniuart-bt
dtoverlay=adau7002-simple
mask_gpu_interrupt1=0x100
audio_pwm_mode=0
enable_uart=1
And the kernel args:
[root@localhost ~]# rpm-ostree kargs
net.ifnames=0 modprobe.blacklist=vc4 root=UUID=3111a58e-40ce-4a5d-9314-90d7993c97f9 ostree=/ostree/boot.1/fedora-iot/82e3a6b60b9e57a232d7bcc53ea00d8f7ec28eacc454f0391f8e5c29d671d2ed/0
Could you please provide support on this topic? It's a very interesting and technical detail to me and it's a compulsory step for a meaningful, big project I'm currently running for my company.
Many thanks in advance,
Andrea
3 years, 11 months
Re: CMA on raspberry pi 4
by Thomas H.P. Andersen
On Thu, May 7, 2020 at 4:10 PM Peter Robinson <pbrobinson(a)gmail.com> wrote:
> >> >> > 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?
>
> Hence my explicit mention of the cma DT overlay option they provide
> and looking at how we can move it from the cmdline to config.txt ;-)
>
Yep. I was not disagreeing on that :) I just wanted to write what I had
found in case it was valuable or interesting for anyone else looking into
this.
Two questions.
Is the cma=256MB default on the arm image only for the sake of the
raspberry pi's? Can we just drop if this config.txt options works?
Is there an easy way (a script?) to get the firmware from master to my sd
card or should I copy the files manually? Will that even work? I can test
the new options over the weekend I think.
> > [3]
> https://github.com/torvalds/linux/commit/8c8c5a4994a306c217fd061cbfc59033...
> >
> >>
> >> Peter
> >>
> >> [1]
> https://github.com/raspberrypi/firmware/commit/7eff9f6774bb43bfd61e749a0b...
> >> [2]
> https://github.com/raspberrypi/firmware/commit/7eff9f6774bb43bfd61e749a0b...
>
4 years