Re: Students and engineers interested in contributing to Fedora Linux on Raspberry Pi
by Joel Savitz
>
> Have you had any engagement with upstream (not Fedora) maintainer of
> RPi.GPIO?
>
As our project is a total rewrite of RPi.GPIO we have not yet
interacted with the original upstream maintainer, but that's a good
suggestion. I'll reach out to Ben Croston and see what he thinks of our
project.
> I have a number of ideas how high/low end sort of projects are you
> interested in? Is kernel or other low level stuff of interest? Is
> there particular areas that the group is interested in?
>
The group is interested in doing something low level such as kernel, but we
are still trying to figure out an area of work with an appropriate scope.
Do you have any recommendations for a low level area of improvement in
which a group of students could reasonably make progress over the next 3-4
months?
Joel
3 years, 3 months
Re: Students and engineers interested in contributing to Fedora Linux on Raspberry Pi
by Jeremy Linton
Hi,
Welcome!
On 1/13/21 3:42 PM, Joel Savitz wrote:
> Good afternoon,
>
> A group of computer science undergraduates and I are interested in
> contributing to the usability of Fedora Linux on the Raspberry Pi 4.
>
> I was a part of this group as an undergrad and we developed a compatibility
> layer for translating RPi.GPIO syntax into calls to libgpiod. It is
> currently available on PyPi and under review for inclusion in Fedora:
> https://github.com/underground-software/RPi.GPIO2
> https://pypi.org/project/RPi.GPIO2/
>
> The maintainer of the (broken) RPi.GPIO fedora package agreed to obsolete
> it in favor of our new package, which is a drop in replacement for RPi.GPIO
> (hence the 2), however I have not heard from him since September.
>
> Anyway, we are looking for a new project or area of Fedora on the Raspberry
> Pi to improve over the upcoming semester. Does anyone have any suggestions?
From my perspective, the main issues with the rpi4 and fedora surround
low level firmware/driver problems. That is what keeps it from "just
working" as expected with a standard fedora image.
As such you might want to take a look at:
https://github.com/lategoodbye/rpi-zero/issues/43
which is the running conversation about upstream kernel features that
need work.
On the firmware side you might look at
https://github.com/pftf/RPI4/issues which is a mix of bugs and future
features required to make the platform behave as expected.
There is probably a uboot related list too, but I don't know where it
is. Peter can probably comment.
Finally besides Trusted Firmware, there is a project that seeks to
replace the videocore firmware as well
https://github.com/librerpi/rpi-open-firmware. If that happens it would
remove another longstanding binary blob used to boot the platform.
There are of course others, but that should provide a few starting places.
Welcome again!
3 years, 3 months
Re: Any update on suggested devices?
by Dan Čermák
Hi Matthew & ARM & IOT SIGs,
I have a Raspberry Pi 4 (8GB) and a Pinebook Pro as of now and would be
more than happy to test anything that you throw at me.
In case there is some simpler development task to be done, I'd love to
help out.
Cheers,
Dan
Matthew Miller <mattdm(a)fedoraproject.org> writes:
> In the meeting right after the F33 release, we talked about identifying a
> handful of key devices and making sure anyone with a serious interest in
> testing or enablement work has what they need. I've talked with Marie, and
> while we're not overflowing with cash, Fedora does have unspent budget which
> would normally have gone to travel sponsorships and this seems to be a
> reasonable thing to use some of it on. IoT is a Fedora Edition, after all,
> and worth investing in.
>
> At that meeting, we talked about y'all coming up with a list of specific
> hardware we can order for people. Because reimbursements are a mess right
> now for unrelated reasons, it's easiest when it's something Marie can
> actually go to a web store, click some buttons, and have shipped direct. Can
> y'all (IoT WG and ARM SIG) come up with a formal list with prices and URLs?
> (Also, if other things like microsd cards need to be included?)
>
> Of course, once we have a list of hardware, I'd also like to send it to
> people. I know there's some worry about people volunteering, getting stuff,
> and not actually doing anything. We want to make sure the devices are going
> to people who will actually be able to make use of them. But I also don't
> want that to be a blocker, so, if you're new but serious I am willing to
> consider including you too. (Perhaps with the promise that if your best
> intentions don't work out, you find someone else to pass the hardware on
> to.)
>
> Rather than people emailing me at random, which is easy for me to drop, can
> the WG and/or SIG come up with a list of people? I'm thinking something like
> a dozen people and 1-3 devices each depending on commitment level.
>
>
> --
> Matthew Miller
> <mattdm(a)fedoraproject.org>
> Fedora Project Leader
> _______________________________________________
> 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, 5 months
Re: Raspberry Pi 3B/3B+ USB
by Peter Robinson
> I'm trying to set up a Raspberry Pi 3B (or a 3B+) to run an Elgato Stream Deck (if you've never heard of that it's basically a fancy macro keyboard). I've had no problems using the Stream Deck on my x86_64 desktop (Fedora 32) and on a Raspberry Pi 3B or 3B+ running Raspbian (kernel 5.4.51-v7+).
>
> However all of my attempts trying to run my code on Fedora (tried using both 32 and 33 alpha 64-bit) result in the USB bus on the Raspberry Pi locking up after a minute or so. It appears to be the whole bus as unplugging the Stream Deck and plugging it back in have no effect. Only a full reboot appears to restore functionality. The following messages appear in the kernel:
>
> dwc2 3f980000.usb: dwc2_hc_halt() Channel can't be halted
>
> So it would seem to me that Raspbian still has some secret sauce for the USB bus on the Raspberry Pi that hasn't been upstreamed yet. Googling around appears to confirm this. Raspbian uses dwc_otg_hcd, a highly optimized driver for host-only mode (despite the name). The upstream kernel offers dwc2 which can switch between host mode and OTG mode and is also apparently buggy as well.
>
> This isn't really a call for help or action as there's probably not much the Fedora community can do. Really it's more of an opportunity to vent my frustration at the Raspberry Pi Foundation developers that haven't worked harder at upstreaming all of their changes.
The USB on the RPi 0-3 devices is somewhat broken, and there's issues
that make it extremely slow which the RPi foundation hacks around with
their completely different driver. It was clear from the outset that
the hacks for that driver would never go upstream and as a result the
upstream driver on the RPi basically runs at half speed and has issues
with devices that need high bandwidth.
I've seen some devices that also manage to hit USB in such a way on
the RPi to cause issues too, we had a wifi adapter that did this, and
it's also sometimes a bug in the device driver that just happens to
trigger on the RPi due to the issues. You can see one example in the
following two links, I wonder if the Stream Deck driver has similar
issues:
https://marc.info/?t=154971423200001&r=1&w=2
https://patchwork.kernel.org/cover/10807911/
3 years, 7 months
Re: Question: kernelopts on raspberry pi
by Steven A. Falco
I tried adding:
GRUB_CMDLINE_LINUX="selinux=0"
to /etc/default/grub, then ran:
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
That successfully added the following to grub.cfg:
if [ -z "${kernelopts}" ]; then
set kernelopts="root=UUID=36a097ba-7577-4cc9-977e-df76c6590c48 ro selinux=0 "
fi
However, /boot/efi/EFI/fedora/grubenv didn't contain "selinux=0". So I manually added that via:
grub2-editenv - set "kernelopts=BOOT_IMAGE=(hd1,msdos2)/vmlinuz-5.8.0-1.fc33.aarch64 root=UUID=36a097ba-7577-4cc9-977e-df76c6590c48 ro selinux=0 "
But that doesn't seem to have any effect. After booting, I still see:
# cat /proc/cmdline
BOOT_IMAGE=(hd1,msdos2)/vmlinuz-5.8.0-1.fc33.aarch64 root=UUID=36a097ba-7577-4cc9-977e-df76c6590c48 ro
Where does the kernel get its command line on RPi?
Steve
On 9/8/20 3:56 PM, Steven A. Falco wrote:
> I'd like to add a kernel command line option (selinux=0) on a raspberry pi.
>
> Normally, I'd edit /etc/default/grub and append that setting to the GRUB_CMDLINE_LINUX variable, then run grub2-mkconfig to regenerate the /boot/efi/EFI/fedora/grub.cfg file.
>
> However, on the pi, /etc/default/grub doesn't have a GRUB_CMDLINE_LINUX variable defined. Yet, I do see this line in /boot/efi/EFI/fedora/grub.cfg:
>
> set kernelopts="root=UUID=36a097ba-7577-4cc9-977e-df76c6590c48 ro "
>
> To accomplish what I want, should I add a new GRUB_CMDLINE_LINUX variable to /etc/default/grub, for example:
>
> GRUB_CMDLINE_LINUX="root=UUID=36a097ba-7577-4cc9-977e-df76c6590c48 ro selinux=0"
>
> Or is there a more correct way to do this?
>
> Steve
3 years, 7 months
Re: The server images are not working with Fedora 31
by Peter Hjalmarsson
Hi,
I have until now just used the workaround of copying the "dtb"
directory to the efi directory so uboot can find it during boot, but
had the last days a reason to revisit this, when I had to re-setup one
of the raspberries.
I found out I was mistaken in that it did not boot, and the real
problem lies in a "regression" for the Server image in the handling of
auto configured serial console output.
I am using the SBCs headless and configure them over serial console
during first boot.
It turns out that this console works differently if uboot finds and
uses the kernel provided device-tree or if it uses its own built-in
device tree (or maybe firmware provided for the rpi?).
And uboot + grub only seems to auto-configure output on serial console
if it finds the kernel provided device tree and loads it.
So with older versions of Fedora Server using ext4 on the boot
partition uboot find the kernel provided device tree, loads it, and
serial console output "just works".
On newer images where boot is XFS uboot uses its builtin (or
firmware-provided on raspberry?) and uboot+grub fails to
auto-configure serial console output.
The two workarounds on raspberry pi are to:
1. "cp -rL /boot/dtb /boot/efi/"
or
2. add "console=tty0 console=ttyS0,115200" to the kernel command line in grub
The difference in configuration between the two device trees can also
be spotted in dmesg after successfully bootup.
How to reproduce:
1. Write the Fedora 32 aarch64 "server" image to an sd-card.
2. edit /boot/efi/config.txt and set "enable_uart=1"
3. pop the sd-card into a rpi3, connect a serial console, and connect a monitor
4. boot
You will during uboot notice that it fails to find any dtb (as uboot
cannot load a file from xfs), and proceeds to boot and show grub.
After grub you vill notice that the serial console outputs the
following and then nothing more:
```
EFI stub: Booting Linux Kernel...
EFI stub: EFI_RNG_PROTOCOL unavailable, no randomness supplied
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
```
The output on the monitor will pause with the same for a second, then
continue with printk, and the output from dracut and systemd during
the rest of the bootup.
On the monitor will start initial-setup during bootup, and after that
present login prompt. No login prompt will present itself on the
serial console.
Run the following after you have logged into the system:
```
# dmesg | grep tty
[ 0.001030] printk: console [tty0] enabled
[ 4.725695] 3f215040.serial: ttyS0 at MMIO 0x3f215040 (irq = 61,
base_baud = 31250000) is a 16550
[ 5.254904] 3f201000.serial: ttyAMA1 at MMIO 0x3f201000 (irq = 66,
base_baud = 0) is a PL011 rev2
[ 28.776063] systemd[1]: Created slice system-getty.slice.
# copy -rL /boot/dtb /boot/efi/
# systemctl reboot
```
You will now notice that uboot tells you it found a dtb on the
vfat-formatted efi partition and loaded it, and you will also see grub
and the kernel outputs everything from bootup on both the serial
console and on the monitor, and end it with a login prompt on both.
```
# dmesg | grep tty
[ 0.000897] printk: console [tty0] enabled
[ 4.495976] 3f215040.serial: ttyS1 at MMIO 0x3f215040 (irq = 61,
base_baud = 31250000) is a 16550
[ 5.492585] printk: console [ttyS1] enabled
[ 6.204865] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 66,
base_baud = 0) is a PL011 rev2
[ 6.224175] serial serial0: tty port ttyAMA0 registered
[ 31.499803] systemd[1]: Created slice system-getty.slice.
[ 31.668768] systemd[1]: Created slice system-serial\x2dgetty.slice.
```
So there is a kind of "regression" in that the serial console output
are not any longer auto configured on the Server-image.
It is also hard to document as the correct tty to use for serial
console is different between images depending on the FS for /boot
Best Regards,
Peter Hjalmarsson
3 years, 9 months
Re: Fwd: Re: CMA on raspberry pi 4
by Stefan Wahren
Am 04.08.20 um 21:46 schrieb ng0177(a)gmail.com:
> Thanks. Just out of curiosity, how can I use "dmesg" w/o keyboard?
In general there are two options
1) connect via SSH (not sure this a real option because this service
could be disabled per default)
2) connect via debug UART (requires serial to USB adapter)
An alternative solution would be try to mount the SD card on a PC and
look for the kernel messages in /var/log
Regards
>
> Appreciate, Thomas
>
> On Mon, Aug 3, 2020 at 7:37 PM Stefan Wahren <stefan.wahren(a)i2se.com
> <mailto:stefan.wahren@i2se.com>> wrote:
>
> Hi,
>
> Am 03.08.20 um 12:04 schrieb Peter Robinson:
> > On Mon, Aug 3, 2020 at 10:57 AM <ng0177(a)gmail.com
> <mailto:ng0177@gmail.com>> wrote:
> >> 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.
> > I don't think the support for loading the USB firmware on the 8Gb
> > model has made it upstream yet. In the 1/2/4gb models it was
> loaded by
> > the Raspberry Pi firmware from SPI flash, in the 8Gb model they
> > dropped the SPI flash and there has to be kernel patches to load it.
> > That problem is unrelated to the CMA/DMA issue.
>
> the USB quirk is available in Linux 5.8 [1], but there is a related
> report [2].
>
> It seems to be related to the board revision and possibly arm64.
>
> A dmesg output might be helpful.
>
> Regards
> Stefan
>
> [1] -
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
>
> [2] - https://github.com/raspberrypi/linux/issues/3747
>
>
>
3 years, 9 months
Re: Fwd: Re: CMA on raspberry pi 4
by ng0177＠gmail.com
Thanks. Just out of curiosity, how can I use "dmesg" w/o keyboard?
Appreciate, Thomas
On Mon, Aug 3, 2020 at 7:37 PM Stefan Wahren <stefan.wahren(a)i2se.com> wrote:
> Hi,
>
> Am 03.08.20 um 12:04 schrieb Peter Robinson:
> > On Mon, Aug 3, 2020 at 10:57 AM <ng0177(a)gmail.com> wrote:
> >> 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.
> > I don't think the support for loading the USB firmware on the 8Gb
> > model has made it upstream yet. In the 1/2/4gb models it was loaded by
> > the Raspberry Pi firmware from SPI flash, in the 8Gb model they
> > dropped the SPI flash and there has to be kernel patches to load it.
> > That problem is unrelated to the CMA/DMA issue.
>
> the USB quirk is available in Linux 5.8 [1], but there is a related
> report [2].
>
> It seems to be related to the board revision and possibly arm64.
>
> A dmesg output might be helpful.
>
> Regards
> Stefan
>
> [1] -
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
>
> [2] - https://github.com/raspberrypi/linux/issues/3747
>
>
>
>
3 years, 9 months
Re: Fwd: Re: CMA on raspberry pi 4
by Peter Robinson
On Mon, Aug 3, 2020 at 10:57 AM <ng0177(a)gmail.com> wrote:
>
> 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.
I don't think the support for loading the USB firmware on the 8Gb
model has made it upstream yet. In the 1/2/4gb models it was loaded by
the Raspberry Pi firmware from SPI flash, in the 8Gb model they
dropped the SPI flash and there has to be kernel patches to load it.
That problem is unrelated to the CMA/DMA issue.
> 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
