[fedora-arm] Re: RPi Kernel memory leak leads to OOM killer running on idle system.
On Thu, 9 May 2024, 09:42 Barry Scott, wrote: > A number of us are seeing a reproducible kernel memory leak on RPi. > > There is a bug https://bugzilla.redhat.com/show_bug.cgi?id=2279327 > and a thread in discuss about it with additional > details: > https://discussion.fedoraproject.org/t/high-memory-usage-in-f40-on-rpi-4-unable-to-find-which-process-used-them/114598 > > Kernel 6.5.6 does not have a leak, but current kernels do. > Can you specify what you mean by "current kernels", I believe there is a aarch64 memory leak fix in 6.8.9, which is currently in testing. There's more info in the following bug: https://bugzilla.redhat.com/show_bug.cgi?id=2275290 > Anyone know if this is being looked at? > > Barry > -- > ___ > arm mailing list -- arm@lists.fedoraproject.org > To unsubscribe send an email to arm-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Issues with RPi4 and newer kernels
> I agree with that, until it de-escalets into finger pointing (your fault, my > fault) nonsense.. very little to be gained there! Doesn't matter who F'd up > . Get several eyes on it and fix it . ... I'm sorry, I'm not sure what you mean by finger pointing, I wasn't pointing any fingers, people are busy, I was was just asking you if you could detail issues in bug reports so we could improve things for all users and have improvements for all. > On Mon, Apr 29, 2024, 16:01 Peter Robinson wrote: >> >> Adding arm@lists.fedoraproject.org back as it was dropped at some point. >> >> > I've never filed bug report. This is free, open source software. WiFi >> > failing to stay connected, failing to route to anything that's not in its >> > own subnet Bind losing it's mind about what subnet it's on GUI Begins >> > coming up, only to black and leave you with virtual terminals. >> >> We use a primarily upstream linus kernel, we've never had reports from >> users of key things like this, and I've never seen it in my own >> testing, so I would be interested in your usecase/configuration. >> >> > There's so much I could say. Rather than gripe about it, i'd much rather >> > just roll up my sleeves and find a way to help as best as I can. Been >> > writing C/C++ on UNIX/Linux for almost 25 years now. I think that's a >> > more productive approach.. . >> >> To some degree report bugs is helping because it means we can fix it >> for all Fedora users, even if your coding ends up fixing it, because >> it means we can ensure the fixes are in place for all users, not just >> a single user, I feel that's a productive approach hence the request >> for bug reports :-) >> >> Peter >> >> > >> > On Mon, Apr 29, 2024, 15:39 Peter Robinson wrote: >> >> >> >> > I'm curious now. I use ethernet on mine and almost always build custom >> >> > kernels. In the absence of anything more useful, I feel motivated to >> >> > play with this and see what I can see. Had plenty of other issues with >> >> > RPi (4b) and Fedora tho'. Contemplating migration to Manjaro.. >> >> >> >> What sort of issues? Can you provide some details or links to some bug >> >> reports please? >> >> >> >> > On Mon, Apr 29, 2024 at 12:33 PM Peter Robinson >> >> > wrote: >> >> >> >> >> >> Hi, >> >> >> >> >> >> > I have a couple of Raspberry Pi 4 systems running Fedora 39 (as >> >> >> > headless >> >> >> > servers), but I'm now hitting kernel update issues with both of them. >> >> >> > I've opened RHBZs on both but haven't gotten any response (they're >> >> >> > niche >> >> >> > issues on a somewhat niche platform, so probably not much >> >> >> > attention). I >> >> >> > was wondering if anybody here might have any suggestions for working >> >> >> > on >> >> >> > getting these fixed. >> >> >> > >> >> >> > One issue started with kernel 6.7 on one Pi - about 30-60 seconds >> >> >> > after >> >> >> > boot, it crashes back to a uboot screen (had to hook up a monitor to >> >> >> > see >> >> >> > it). I have netconsole set up but it doesn't show anything. This Pi >> >> >> > has a GPS HAT set up with PPS for a time source... I suspect it may >> >> >> > be >> >> >> > related to that? The boot-to-crash delay is probably around the time >> >> >> > that it takes for the GPS/PPS to start up after boot. Kernel 6.6.13 >> >> >> > still works fine. >> >> >> > >> >> >> > https://bugzilla.redhat.com/show_bug.cgi?id=2264560 >> >> >> > >> >> >> > The other issue started with kernel 6.8 on another Pi - this one >> >> >> > loses >> >> >> > the ability to connect to a WPA3-PSK wifi network. It can still >> >> >> > connect >> >> >> > to a WPA2-PSK network, and kernel 6.7 can connect to WPA3-PSK. I >> >> >> > have >> >> >> > other (x86_64) Fedora systems that can connect to the WPA3-PSK >> >> >> > network >> >> >> > with kernel 6.8. >> >> >> > >
[fedora-arm] Re: Issues with RPi4 and newer kernels
Adding arm@lists.fedoraproject.org back as it was dropped at some point. > I've never filed bug report. This is free, open source software. WiFi > failing to stay connected, failing to route to anything that's not in its own > subnet Bind losing it's mind about what subnet it's on GUI Begins coming up, > only to black and leave you with virtual terminals. We use a primarily upstream linus kernel, we've never had reports from users of key things like this, and I've never seen it in my own testing, so I would be interested in your usecase/configuration. > There's so much I could say. Rather than gripe about it, i'd much rather > just roll up my sleeves and find a way to help as best as I can. Been > writing C/C++ on UNIX/Linux for almost 25 years now. I think that's a more > productive approach.. . To some degree report bugs is helping because it means we can fix it for all Fedora users, even if your coding ends up fixing it, because it means we can ensure the fixes are in place for all users, not just a single user, I feel that's a productive approach hence the request for bug reports :-) Peter > > On Mon, Apr 29, 2024, 15:39 Peter Robinson wrote: >> >> > I'm curious now. I use ethernet on mine and almost always build custom >> > kernels. In the absence of anything more useful, I feel motivated to play >> > with this and see what I can see. Had plenty of other issues with RPi >> > (4b) and Fedora tho'. Contemplating migration to Manjaro.. >> >> What sort of issues? Can you provide some details or links to some bug >> reports please? >> >> > On Mon, Apr 29, 2024 at 12:33 PM Peter Robinson >> > wrote: >> >> >> >> Hi, >> >> >> >> > I have a couple of Raspberry Pi 4 systems running Fedora 39 (as headless >> >> > servers), but I'm now hitting kernel update issues with both of them. >> >> > I've opened RHBZs on both but haven't gotten any response (they're niche >> >> > issues on a somewhat niche platform, so probably not much attention). I >> >> > was wondering if anybody here might have any suggestions for working on >> >> > getting these fixed. >> >> > >> >> > One issue started with kernel 6.7 on one Pi - about 30-60 seconds after >> >> > boot, it crashes back to a uboot screen (had to hook up a monitor to see >> >> > it). I have netconsole set up but it doesn't show anything. This Pi >> >> > has a GPS HAT set up with PPS for a time source... I suspect it may be >> >> > related to that? The boot-to-crash delay is probably around the time >> >> > that it takes for the GPS/PPS to start up after boot. Kernel 6.6.13 >> >> > still works fine. >> >> > >> >> > https://bugzilla.redhat.com/show_bug.cgi?id=2264560 >> >> > >> >> > The other issue started with kernel 6.8 on another Pi - this one loses >> >> > the ability to connect to a WPA3-PSK wifi network. It can still connect >> >> > to a WPA2-PSK network, and kernel 6.7 can connect to WPA3-PSK. I have >> >> > other (x86_64) Fedora systems that can connect to the WPA3-PSK network >> >> > with kernel 6.8. >> >> > >> >> > https://bugzilla.redhat.com/show_bug.cgi?id=2275835 >> >> >> >> I replied on both of those bugs. While I maintain various pieces of >> >> arm kernel I don't follow all kernel bugs as I don't have the >> >> bandwidth so it's useful to ping here as you've done for awareness to >> >> problems. >> >> >> >> P >> >> -- >> >> ___ >> >> arm mailing list -- arm@lists.fedoraproject.org >> >> To unsubscribe send an email to arm-le...@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 >> >> Do not reply to spam, report it: >> >> https://pagure.io/fedora-infrastructure/new_issue >> > >> > >> > >> > -- >> > Randall DuCharme (Radio AD5GB) >> > Powered by Open Source software. >> > -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Issues with RPi4 and newer kernels
On Mon, 29 Apr 2024 at 18:45, Chris Adams wrote: > > Once upon a time, Peter Robinson said: > > I replied on both of those bugs. While I maintain various pieces of > > arm kernel I don't follow all kernel bugs as I don't have the > > bandwidth so it's useful to ping here as you've done for awareness to > > problems. > > Thanks, I'll get those both updated after work today when I can gather > some more info. Probably worthwhile checking to see if 6.9-rc6 works for either of the issues. > I generally try to avoid pinging in multiple places; I know everybody > has lots going on, and try to respect that time. But I know that also > Bugzilla can be a LOT for someone/groups to track. > -- > Chris Adams > -- > ___ > arm mailing list -- arm@lists.fedoraproject.org > To unsubscribe send an email to arm-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Issues with RPi4 and newer kernels
Hi, > I have a couple of Raspberry Pi 4 systems running Fedora 39 (as headless > servers), but I'm now hitting kernel update issues with both of them. > I've opened RHBZs on both but haven't gotten any response (they're niche > issues on a somewhat niche platform, so probably not much attention). I > was wondering if anybody here might have any suggestions for working on > getting these fixed. > > One issue started with kernel 6.7 on one Pi - about 30-60 seconds after > boot, it crashes back to a uboot screen (had to hook up a monitor to see > it). I have netconsole set up but it doesn't show anything. This Pi > has a GPS HAT set up with PPS for a time source... I suspect it may be > related to that? The boot-to-crash delay is probably around the time > that it takes for the GPS/PPS to start up after boot. Kernel 6.6.13 > still works fine. > > https://bugzilla.redhat.com/show_bug.cgi?id=2264560 > > The other issue started with kernel 6.8 on another Pi - this one loses > the ability to connect to a WPA3-PSK wifi network. It can still connect > to a WPA2-PSK network, and kernel 6.7 can connect to WPA3-PSK. I have > other (x86_64) Fedora systems that can connect to the WPA3-PSK network > with kernel 6.8. > > https://bugzilla.redhat.com/show_bug.cgi?id=2275835 I replied on both of those bugs. While I maintain various pieces of arm kernel I don't follow all kernel bugs as I don't have the bandwidth so it's useful to ping here as you've done for awareness to problems. P -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Mapping GPIO Pins from Wandboard to Fedora/libpiod
On Mon, 15 Apr 2024 at 21:38, Derek Atkins wrote: > > Hi, > > On Mon, April 15, 2024 4:21 pm, Peter Robinson wrote: > > >> >> >> me that the JP4 header connects to GPIO3_12, GPIO3_27, GPIO6_31, > >> >> >> CPIO1_24, > >> >> >> GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19. > >> >> >> > >> [snip] > > > I've not dug out a pdf to work out the physical pins and how they map > > to the SOC and hence the DT, I've left that up to you, I was just > > answering your questions about why some appear to be in use and trying > > to help you understand as you requested. > > I've read the docs; the pins on the header map to the above-listed lanes. > What I need to figure out are: > > 1) How do these map to gpiochipN X -- e.g. if GPIO_18 maps to gpiochip0,18 > and GPIO3_12 maps to gpiochip3,12 -- what does GPIO7_8 map to? > > 2) How to figure out which ones are available? I presume I can just look > at the output of gpioinfo for the aforementioned mappings? In both cases above it should be in the docs, or at the very least the DT in combination with the docs. In the later case they should document what GPIOs are available for use and what the pins on the header do similar to how the RPi document the 40 pin header there. -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Mapping GPIO Pins from Wandboard to Fedora/libpiod
On Mon, 15 Apr 2024 at 19:39, Derek Atkins wrote: > > Hi again, > I just went and cracked open the case. > According the chip ID, it's an IMX6 Dual. Although cpuinfo only reports > cpu 0. > The main board says revision A1; the baseboard says revision A0. I guess > this is one of my older units. Makes sense, there was either dual or quad models, as to why it's not finding the other core I am not sure, it might be a DT issue, might be a kernel issue, unfortunately with F-36 EOL there's no a lot I can do to help you there, all my imx6 devices are packed away in a box somewhere. > -derek > > On Mon, April 15, 2024 2:12 pm, Derek Atkins wrote: > > Hi Peter, > > > > On Mon, April 15, 2024 1:47 pm, Peter Robinson wrote: > > > >>> >> I'm using > >>> >> https://download.technexion.com/development_resources/wandboard/wbquad-revb1-userguide.pdf > >>> >> as a reference for the board layout. Specifically, on page 27, it > >>> shows > >>> >> me that the JP4 header connects to GPIO3_12, GPIO3_27, GPIO6_31, > >>> >> CPIO1_24, > >>> >> GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19. > >>> >> > > [snip] > > > >>> Being only ancillarily associated with Arm/Embedded HW -- what does it > >>> mean for a GPIO to be "used for other things"? And more importantly, > >>> why > >>> would it be wired to a header if it's being used for something else? > >> > >> So in the case I mention below the GPIO pin is used for i2c and it's > >> on that header so you could add say a i2c based temp sensor or other > >> i2c device. > >> > >> Also board designers may use a GPIO to hook up a mSD card detect pin, > >> or a WiFi interface reset pin, or something else on the board layout. > > > > I guess I don't understand why they would expose GPIO-x on a header and > > ALSO use it elsewhere on the board. In my case, I just need to find 4 > > open "button" inputs. > > > >> You can see the default pin allocation here from line 152-195: > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/nxp/imx/imx6qdl-wandboard.dtsi#n152 > >> > >> And the GPIOs mapped to i2c here on lines 103-104 and again 113-114, > >> and then as a camera enable/reset at 139-140: > >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/nxp/imx/imx6qdl-wandboard.dtsi#n103 > > > > Thanks. I see the duplication of scl-gpois and sda-gpios names in those > > two sections, but in the first section it uses gpio3 21/28 and in the > > second section is used gpio4 13/14. > > > > I also don't see the specific bindings for the pins on the JP4 header > > (e.g. I don't see gpio3 12 being specified here). > > > >>> > A quick look at the dtsi for the wandboards some of the GPIOs re used > >>> > for SCL/SDA pins on two of the i2c buses. The i2c1 seems to not have > >>> > anything attached so I guess in on a pin header for end user use, and > >>> > i2c12 has a audio codec and for the camera connector. > >>> > >>> How exactly is this done? Is the pin wired to two places on the PCB? > >> > >> It depends, for example on a RPi header you can use a DT overlay to > >> change the default use of a PIN, by default is might be a standard > >> GPIO but you apply an overlay that remaps it so it routes a i2s audio > >> interface so you can use a DAC to output sound. So it's generally more > >> about being able to use the reduced amounts of external pins for > >> different usecases, someone might want it in a robot, someone else > >> might want it to output audio. > > > > How would an end-user do that without building a custom kernel? Like I > > said, all I need is to read from four input GPIOs for a water-detection > > system, so instead of using a 'sleep' after opening the relay, it waits > > for the appropriate gpio to turn on based on a water detector connected to > > it (so it will turn off the relay as soon as it detects the water tank is > > full). > > > > So really I just need to choose 4 pins that I can use, and map those to an > > event manager to wait for the pin to go on. JP4 seems to be the only > > layout with GPIO labeled, so I just need to figure out which pins to use > > and how to read those inputs in this brave new world. > > > > Thanks, > > > > -derek > > > > -- > >Derek Atk
[fedora-arm] Re: Mapping GPIO Pins from Wandboard to Fedora/libpiod
On Mon, 15 Apr 2024 at 19:12, Derek Atkins wrote: > > Hi Peter, > > On Mon, April 15, 2024 1:47 pm, Peter Robinson wrote: > > >> >> I'm using > >> >> https://download.technexion.com/development_resources/wandboard/wbquad-revb1-userguide.pdf > >> >> as a reference for the board layout. Specifically, on page 27, it > >> shows > >> >> me that the JP4 header connects to GPIO3_12, GPIO3_27, GPIO6_31, > >> >> CPIO1_24, > >> >> GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19. > >> >> > [snip] > > >> Being only ancillarily associated with Arm/Embedded HW -- what does it > >> mean for a GPIO to be "used for other things"? And more importantly, > >> why > >> would it be wired to a header if it's being used for something else? > > > > So in the case I mention below the GPIO pin is used for i2c and it's > > on that header so you could add say a i2c based temp sensor or other > > i2c device. > > > > Also board designers may use a GPIO to hook up a mSD card detect pin, > > or a WiFi interface reset pin, or something else on the board layout. > > I guess I don't understand why they would expose GPIO-x on a header and > ALSO use it elsewhere on the board. In my case, I just need to find 4 > open "button" inputs. They're not, eg to use the i2c example, they are changing those GPIOs to be i2c and exposing it on the header as an i2c interface (and hence they are not usable as a generic GPIO interface). To use 4 GPIOs to use for buttons you just need to work out where the open GPIOs as documented on the header map as open unused GPIO PINs. > > You can see the default pin allocation here from line 152-195: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/nxp/imx/imx6qdl-wandboard.dtsi#n152 > > > > And the GPIOs mapped to i2c here on lines 103-104 and again 113-114, > > and then as a camera enable/reset at 139-140: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/nxp/imx/imx6qdl-wandboard.dtsi#n103 > > Thanks. I see the duplication of scl-gpois and sda-gpios names in those > two sections, but in the first section it uses gpio3 21/28 and in the > second section is used gpio4 13/14. That's two different i2c interfaces, one I suspect is mapped out to the PIN headers, the other is used for audio codec and camera elsewhere on the board. > I also don't see the specific bindings for the pins on the JP4 header > (e.g. I don't see gpio3 12 being specified here). You need to follow the docs, I am not looking at that, I was purely explaining how the mappings are happening, not how they're routed on the HW. > >> > A quick look at the dtsi for the wandboards some of the GPIOs re used > >> > for SCL/SDA pins on two of the i2c buses. The i2c1 seems to not have > >> > anything attached so I guess in on a pin header for end user use, and > >> > i2c12 has a audio codec and for the camera connector. > >> > >> How exactly is this done? Is the pin wired to two places on the PCB? > > > > It depends, for example on a RPi header you can use a DT overlay to > > change the default use of a PIN, by default is might be a standard > > GPIO but you apply an overlay that remaps it so it routes a i2s audio > > interface so you can use a DAC to output sound. So it's generally more > > about being able to use the reduced amounts of external pins for > > different usecases, someone might want it in a robot, someone else > > might want it to output audio. > > How would an end-user do that without building a custom kernel? Like I > said, all I need is to read from four input GPIOs for a water-detection > system, so instead of using a 'sleep' after opening the relay, it waits > for the appropriate gpio to turn on based on a water detector connected to > it (so it will turn off the relay as soon as it detects the water tank is > full). Basically read the docs and map that through to free GPIO PINS. > So really I just need to choose 4 pins that I can use, and map those to an > event manager to wait for the pin to go on. JP4 seems to be the only > layout with GPIO labeled, so I just need to figure out which pins to use > and how to read those inputs in this brave new world. I've not dug out a pdf to work out the physical pins and how they map to the SOC and hence the DT, I've left that up to you, I was just answering your questions about why some appear to be in use and trying to help you understand as you requested. -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Mapping GPIO Pins from Wandboard to Fedora/libpiod
> >> I have a Wandboard (yeah, I know, OLD Hardware) currently running a > > > > As in the imx6 based Wandboard? Which model/rev? What release of > > Fedora, what kernel etc? > > Yes, an imx6 Wandboard. I'll have to go upstairs and open the case to see > the EXACT model/rev printed on the PCB. Running "cat /proc/cpuinfo" only > shows a single core. And it's running Fedora 36, currently running > 5.18.9-200.fc36.armv7hl and libgpiod-1.6.3-7.fc36.armv7hl > > >> project, and I'm trying to add some GPIO inputs to it. In previous GPIO > >> handling (on a different platform) I used the /sys/class/gpio interfaces > >> to set up the GPIO, but I've discovered this is now deprecated and > >> removed > >> from Fedora. So I installed libgpiod and am trying to use it. > > > > Yes, we stopped supporting that because it was deprecated and upstream > > asked us to. > > > >> I'm using > >> https://download.technexion.com/development_resources/wandboard/wbquad-revb1-userguide.pdf > >> as a reference for the board layout. Specifically, on page 27, it shows > >> me that the JP4 header connects to GPIO3_12, GPIO3_27, GPIO6_31, > >> CPIO1_24, > >> GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19. > >> > >> I figure that GPIO_18 is going to be gpiochip0 line 18, and GPIO3_12 > >> will > >> be gpiochip3 line 12.. Except that gpiodetect only tells me I have > >> gpiochip0 through gpiochip6, so I'm not sure where GPIO7_8 would get > >> mapped. That's the first issue I have. > > > > You'd likely need to look at the device tree and pinmappings to see > > how they're mapped out. > > I was trying to follow the device tree, and found a dts in the > wandboard-org tree that seemed to match the settings from that PDF I > pointed to. Of course, that may or may not be correct to the actual > hardware I have running upstairs. Best ones are probably the upstream ones: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/nxp/imx > >> The second issue is that the kernel does not have any named mappings, so > >> running gpioinfo just displays generic data, like: > >> > >> gpiochip6 - 32 lines: > >> line 0: unnamed unused input active-high > >> line 1: unnamed unused input active-high > >> > >> Except, of course, looking at gpiochip3 line 12 shows me: > >> > >> gpiochip3 - 32 lines: > >> ... > >> line 12: unnamed"scl" output active-high [used > >> open-drain] > >> > >> Which seems to imply that that GPIO3_12 is actually used for something > >> else -- or my mapping strategy is off. > > > > Probably a kernel device, often GPIOs are used for other things. > > Being only ancillarily associated with Arm/Embedded HW -- what does it > mean for a GPIO to be "used for other things"? And more importantly, why > would it be wired to a header if it's being used for something else? So in the case I mention below the GPIO pin is used for i2c and it's on that header so you could add say a i2c based temp sensor or other i2c device. Also board designers may use a GPIO to hook up a mSD card detect pin, or a WiFi interface reset pin, or something else on the board layout. You can see the default pin allocation here from line 152-195: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/nxp/imx/imx6qdl-wandboard.dtsi#n152 And the GPIOs mapped to i2c here on lines 103-104 and again 113-114, and then as a camera enable/reset at 139-140: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/nxp/imx/imx6qdl-wandboard.dtsi#n103 > > A quick look at the dtsi for the wandboards some of the GPIOs re used > > for SCL/SDA pins on two of the i2c buses. The i2c1 seems to not have > > anything attached so I guess in on a pin header for end user use, and > > i2c12 has a audio codec and for the camera connector. > > How exactly is this done? Is the pin wired to two places on the PCB? It depends, for example on a RPi header you can use a DT overlay to change the default use of a PIN, by default is might be a standard GPIO but you apply an overlay that remaps it so it routes a i2s audio interface so you can use a DAC to output sound. So it's generally more about being able to use the reduced amounts of external pins for different usecases, someone might want it in a robot, someone else might want it to output audio. > >> I'd appreciate any guidance anyone might have on this subject. > > > > If it's a iMX6 based Wandboard the guidance will be limted as the > > support for ARMv7 went EOL when F-36 did so I have no recollection of > > what kernel, libgpiod version etc was shipped there. > > Understood. I just happen to have bought into the Wandboard platform a > long time ago, so this is what I've been using for the project. It uses a > USB Relay, leveraging CRelay, so theoretically I could swap the system out > for a different board in order to get 4 GPIOs for external switch > detction, but
[fedora-arm] Re: Mapping GPIO Pins from Wandboard to Fedora/libpiod
Hi Derek, > I have a Wandboard (yeah, I know, OLD Hardware) currently running a As in the imx6 based Wandboard? Which model/rev? What release of Fedora, what kernel etc? > project, and I'm trying to add some GPIO inputs to it. In previous GPIO > handling (on a different platform) I used the /sys/class/gpio interfaces > to set up the GPIO, but I've discovered this is now deprecated and removed > from Fedora. So I installed libgpiod and am trying to use it. Yes, we stopped supporting that because it was deprecated and upstream asked us to. > I'm using > https://download.technexion.com/development_resources/wandboard/wbquad-revb1-userguide.pdf > as a reference for the board layout. Specifically, on page 27, it shows > me that the JP4 header connects to GPIO3_12, GPIO3_27, GPIO6_31, CPIO1_24, > GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19. > > I figure that GPIO_18 is going to be gpiochip0 line 18, and GPIO3_12 will > be gpiochip3 line 12.. Except that gpiodetect only tells me I have > gpiochip0 through gpiochip6, so I'm not sure where GPIO7_8 would get > mapped. That's the first issue I have. You'd likely need to look at the device tree and pinmappings to see how they're mapped out. > The second issue is that the kernel does not have any named mappings, so > running gpioinfo just displays generic data, like: > > gpiochip6 - 32 lines: > line 0: unnamed unused input active-high > line 1: unnamed unused input active-high > > Except, of course, looking at gpiochip3 line 12 shows me: > > gpiochip3 - 32 lines: > ... > line 12: unnamed"scl" output active-high [used > open-drain] > > Which seems to imply that that GPIO3_12 is actually used for something > else -- or my mapping strategy is off. Probably a kernel device, often GPIOs are used for other things. A quick look at the dtsi for the wandboards some of the GPIOs re used for SCL/SDA pins on two of the i2c buses. The i2c1 seems to not have anything attached so I guess in on a pin header for end user use, and i2c12 has a audio codec and for the camera connector. > I'd appreciate any guidance anyone might have on this subject. If it's a iMX6 based Wandboard the guidance will be limted as the support for ARMv7 went EOL when F-36 did so I have no recollection of what kernel, libgpiod version etc was shipped there. Peter -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: no /dev/mtd* devices in Fedora 40 beta on Rock 5B
> I have my Rock 5B booting Fedora 40 Beta on NVMe, using EDK2 on an SD card. > I would like to flash the EDK2 image to SPI, but this requires access to > /dev/mtdblock* devices. > There appear to be none. > > Could this be related to the ACPI vs DTB setting in the EDK2? It could be that, it could be also that edk2 doesn't expose the mtd devices as EDK2 treats them as owned by the firmware but then I don't know if edk2 for that platform would support something like EFI capsule updates. > Fedora 40 Beta will not boot in DTB mode, and possibly this is required > for automatically creating /dev/mtdblock* devices. I am purely looking at supporting the Rock5B with a U-Boot firmware stack so that's where I am testing, the problem with ACPI on this platform is that the vast majority of the drivers don't currently support ACPI so even if the mtd is in the ACPI tables the drivers may not support it. -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Fedora on ROCK 5 Model B
> Questions: > > 1. GPU: > root@rockpi5:~# inxi -Gx > Graphics: > Message: No PCI device data found. > Display: server: X.Org v: 23.2.2 with: Xwayland v: 23.2.2 driver: X: >loaded: modesetting dri: swrast gpu: N/A resolution: 1920x1080~60Hz > API: EGL v: 1.5 drivers: kms_swrast,swrast platforms: >active: gbm,x11,surfaceless,device inactive: wayland > API: OpenGL v: 4.5 vendor: mesa v: 23.3.0 glx-v: 1.4 direct-render: yes >renderer: llvmpipe (LLVM 17.0.4 128 bits) > API: Vulkan v: 1.3.268 drivers: llvmpipe surfaces: xcb,xlib devices: 1 > root@rockpi5:~# > > How can I improve GPU Performance ? Mali / Panfrost Driver are available but > not loaded /used The hardware support isn't fully upstream in released versions as yet so it's not expected to work. The firmware is upstream in linux-firmware 20240220 and later, the kernel support is due to land in 6.10 and the mesa support is under review. We should be able to support it all later in the summer, so probably officially in F-41. > Creating a custom xorg.conf doesn't make sense while using Wayland ? Nope, if the support was upstream it would "just work" > 2. Boot > > Is there any way to boot Fedora direct from NVME instead using > rock-5b_UEFI_Release_v0.9.1.img on SD-Card ? Write it to the SPI flash or eMMC, the SoC only supports SPL (the very very early part of the boot process) on SPI flash, eMMC or mSD. The docs explain how to do that on the various devices :) -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Fedora on ROCK 5 Model B
> I can confirm this method works fine for Fedora Beta 40. That's great, I > will be able to use standard Fedora 40 next month. > > I had to overcome two problems: > - My keyboard behind a USB switch would not work in UEFI, I had to > directly connect it. In Fedora it would work again behind the switch. By UEFI do you mean the EDK2 builds? > - The ACPI/DTB setting needed to be set on "ACPI". "DTB" or "Both" would > not work for me. That's in the EDK2 menu? In both cases if it's EDK2 you should look at the bug reports for that project and maybe file bugs there. > Thanks, > Pim > > > On 12/8/23 19:28, Andreas Reschke wrote: > > Hello, > > > > I've installed Fedora 40 Rawhide on my Rock 5 > > > > Short howto: > > > > What you need: > > 1) > > https://github.com/edk2-porting/edk2-rk3588/releases/download/v0.9.1/rock-5b_UEFI_Release_v0.9.1.img > > dd this Image on a SD-Card > > > > 2) > > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/iso/Fedora-Everything-netinst-aarch64-Rawhide-20231113.n.0.iso > > > > dd this Image on a USB stick > > > > Put both in your Rock 5B and boot. I've done the Net-install > > installation with KDE Wayland. The SD-Card with UEFI is needed for booting. > > > > > > Questions: > > > > 1. GPU: > > root(a)rockpi5:~# inxi -Gx > > Graphics: > > Message:No PCI device data found. > > Display:server:X.Org v:23.2.2 with:Xwayland v:23.2.2 driver:X: > > loaded:modesetting dri:swrast gpu:N/A resolution:1920x1080~60Hz > > API:EGL v:1.5 drivers:kms_swrast,swrast platforms: > > active:gbm,x11,surfaceless,device inactive:wayland > > API:OpenGL v:4.5 vendor:mesa v:23.3.0 glx-v:1.4 direct-render:yes > > renderer:llvmpipe (LLVM 17.0.4 128 bits) > > API:Vulkan v:1.3.268 drivers:llvmpipe surfaces:xcb,xlib devices:1 > > root(a)rockpi5:~# > > > > How can I improve GPU Performance ? Mali / Panfrost Driver are available > > but not loaded /used > > > > root(a)rockpi5:~# rpm -ql mesa-dri-drivers-23.3.0-1.fc40.aarch64 | grep -i > > pan > > /usr/lib64/dri/panfrost_dri.so > > root(a)rockpi5:~# rpm -ql mesa-dri-drivers-23.3.0-1.fc40.aarch64 | grep -i > > mali > > /usr/lib64/dri/mali-dp_dri.so > > root(a)rockpi5:~# > > > > Creating a custom xorg.conf doesn't make sense while using Wayland ? > > > > > > 2. Boot > > > > Is there any way to boot Fedora direct from NVME instead using > > rock-5b_UEFI_Release_v0.9.1.img on SD-Card ? > > > > Thanks > > Andreas > -- > ___ > arm mailing list -- arm@lists.fedoraproject.org > To unsubscribe send an email to arm-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Details on Raspberry Pi 5 support timelines
On Sun, 17 Mar 2024 at 21:38, Sally A.haj wrote: > > Hi Peter, > Thank you for all your efforts. > > I just thought about rpmfusion's images for RPix, while they are using > the downstream kernel, they might consider adding the support for RPi5, > this one instead of make a new remix, if that make sense. I have no idea what RPix is. My intention is to ultimately get everything into Fedora, the remix is intended to be short lived and assist in moving forward the upstreaming. > Sally > > On Sun, 2024-03-17 at 18:21 +, Peter Robinson wrote: > > Hi Folks, > > > > I finally got some time over the weekend to dig into Fedora on the > > RPi5. > > > > The TL;DR is that there won't be any way of even basic support > > officially for F-40 GA. > > > > For those interested in more details. > > > > The main pieces missing from the upstream kernel to boot to a login > > prompt over serial is appear to be the following: > > * The SoC pinctrl driver > > * Support in the mmc storage driver for the SoC variant > > * Minor bits for the gpio driver > > > > I'm not aware of any efforts to get anything upstream, I've not seen > > patches on lists etc. > > > > We have the firmware (bcm/u-boot) pieces in place in Fedora 40 and > > the > > kernel will start to boot and you get serial console output except > > you > > end up at a dracut prompt due to lack of storage. > > > > I am considering doing a Fedora kernel with patches in copr, and > > probably a F-40 remix minimal image, to enable minimal boot so other > > low level developers can use it as a basis for further investigation > > for things like upstream development. I don't have a timeline for > > this > > yet but I suspect late April. At the moment this looks like it'll be > > mSD, WiFi, serial console support and not much else. I've not looked > > at PCIe, the RP1 chip, or any other peripherals at all. > > > > I'll reply to this thread if/when I have any further updates, feel > > free to reference it elsewhere. > > > > Until there's either a kernel or kernel+image unless you can > > contribute to upstream kernel pieces there's probably nothing that > > can > > be done like "testing". If you can do kernel and would like to assist > > me feel free to reachout outside of this thread. > > > > Peter > > -- > > ___ > > arm mailing list -- arm@lists.fedoraproject.org > > To unsubscribe send an email to arm-le...@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 > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue > -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Details on Raspberry Pi 5 support timelines
Hi Folks, I finally got some time over the weekend to dig into Fedora on the RPi5. The TL;DR is that there won't be any way of even basic support officially for F-40 GA. For those interested in more details. The main pieces missing from the upstream kernel to boot to a login prompt over serial is appear to be the following: * The SoC pinctrl driver * Support in the mmc storage driver for the SoC variant * Minor bits for the gpio driver I'm not aware of any efforts to get anything upstream, I've not seen patches on lists etc. We have the firmware (bcm/u-boot) pieces in place in Fedora 40 and the kernel will start to boot and you get serial console output except you end up at a dracut prompt due to lack of storage. I am considering doing a Fedora kernel with patches in copr, and probably a F-40 remix minimal image, to enable minimal boot so other low level developers can use it as a basis for further investigation for things like upstream development. I don't have a timeline for this yet but I suspect late April. At the moment this looks like it'll be mSD, WiFi, serial console support and not much else. I've not looked at PCIe, the RP1 chip, or any other peripherals at all. I'll reply to this thread if/when I have any further updates, feel free to reference it elsewhere. Until there's either a kernel or kernel+image unless you can contribute to upstream kernel pieces there's probably nothing that can be done like "testing". If you can do kernel and would like to assist me feel free to reachout outside of this thread. Peter -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Update U-Boot on Pinebook Pro ?
On Wed, 13 Mar 2024 at 19:24, Andreas Reschke wrote:
>
> Thanks Peter,
>
> I will try it on Friday.
There will no doubt be a newer build by Friday but use at least
2024.04-0.5.rc4 as I pushed a build there that fixes NVME auto boot to
rawhide, I expect a newer build in the next day or so.
uboot-tools-2024.04-0.5.rc4.fc41
> Andreas
>
> Am 13.03.24 um 16:17 schrieb Peter Robinson:
> > Hi,
> >
> >>> Hello together, hello Peter,
> >>>
> >>> I've on my Pinebook Pro U-Boot 2022.10.
> >>>
> >>> Howto: https://nullr0ute.com/2021/05/fedora-on-the-pinebook-pro/
> >>>
> >>> Does it make sence to update U-Boot to up2date Version from Fedora 39
> >>> (uboot-images-armv8-2023-07-3.fc39.noarch) ? Are there any significant
> >>> changes ?
> >> Whatever you decide, don't install 2023.10-rc3. It's broken. I still
> >> haven't found the time to disassemble my PBP and put it into maskrom
> >> mode to recover. I'll probably have some time next week and will try
> >> to install 2023.10 final.
> > So I finally got time to look into this on my PBP and what's happened
> > is they're moved the offsets the u-boot.itb needs to be written.
> >
> > So if you do the following for the SPI flash rather than the previous
> > one it should work:
> > sf update ${fdt_addr_r} E ${filesize}
> >
> > A nasty hack that may work is if you use the spi-flashing-disk to
> > setup a mSD card with the same version that's on the SPI flash it may
> > boot with that to a U-Boot prompt to save taking it to pieces.
> >
> > spi-flashing-disk --media=/dev/sda --target=pinebook-pro-rk3399
> >
> > I am going to update the details in the blog post to cover this, also
> > we can likely now move to a single command for flashing a combined
> > blob in F-40. Note I've also discovered a bug in the U-Boot menu if
> > booting off NVME, I am looking into that currently.
> >
> > Peter
> > --
> > ___
> > arm mailing list -- arm@lists.fedoraproject.org
> > To unsubscribe send an email to arm-le...@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
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> --
> ___
> arm mailing list -- arm@lists.fedoraproject.org
> To unsubscribe send an email to arm-le...@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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
--
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Update U-Boot on Pinebook Pro ?
On Wed, 13 Mar 2024 at 21:19, Dominik 'Rathann' Mierzejewski
wrote:
>
> Hi!
>
> On Wednesday, 13 March 2024 at 16:17, Peter Robinson wrote:
> > > Whatever you decide, don't install 2023.10-rc3. It's broken. I still
> > > haven't found the time to disassemble my PBP and put it into maskrom
> > > mode to recover. I'll probably have some time next week and will try
> > > to install 2023.10 final.
> >
> > So I finally got time to look into this on my PBP and what's happened
> > is they're moved the offsets the u-boot.itb needs to be written.
> >
> > So if you do the following for the SPI flash rather than the previous
> > one it should work:
> > sf update ${fdt_addr_r} E ${filesize}
> >
> > A nasty hack that may work is if you use the spi-flashing-disk to
> > setup a mSD card with the same version that's on the SPI flash it may
> > boot with that to a U-Boot prompt to save taking it to pieces.
> >
> > spi-flashing-disk --media=/dev/sda --target=pinebook-pro-rk3399
>
> Unfortunately, the above doesn't help. I still get:
I did say it might work, sorry, you'll probably have to do the hard recovery.
--
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Update U-Boot on Pinebook Pro ?
Hi,
> > Hello together, hello Peter,
> >
> > I've on my Pinebook Pro U-Boot 2022.10.
> >
> > Howto: https://nullr0ute.com/2021/05/fedora-on-the-pinebook-pro/
> >
> > Does it make sence to update U-Boot to up2date Version from Fedora 39
> > (uboot-images-armv8-2023-07-3.fc39.noarch) ? Are there any significant
> > changes ?
>
> Whatever you decide, don't install 2023.10-rc3. It's broken. I still
> haven't found the time to disassemble my PBP and put it into maskrom
> mode to recover. I'll probably have some time next week and will try
> to install 2023.10 final.
So I finally got time to look into this on my PBP and what's happened
is they're moved the offsets the u-boot.itb needs to be written.
So if you do the following for the SPI flash rather than the previous
one it should work:
sf update ${fdt_addr_r} E ${filesize}
A nasty hack that may work is if you use the spi-flashing-disk to
setup a mSD card with the same version that's on the SPI flash it may
boot with that to a U-Boot prompt to save taking it to pieces.
spi-flashing-disk --media=/dev/sda --target=pinebook-pro-rk3399
I am going to update the details in the blog post to cover this, also
we can likely now move to a single command for flashing a combined
blob in F-40. Note I've also discovered a bug in the U-Boot menu if
booting off NVME, I am looking into that currently.
Peter
--
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@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
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Fedora on Rock 5B
> What's not working at the moment: > - accelerate GPU > > - sound via 3,5 mm Headphone Both of the above are known. > - Bluetooth via Realtek RTL8852BE PCIe 802.11ax Wireless Network (Radxa > wireless A8) And I think that is too because the USB isn't plumbed through to the M2-E slot yet (see the link I referenced). > > Greetings > > Andreas > > Am 16.02.24 um 7:12 PM schrieb Peter Robinson: > > Hi Folks, > > It's in my backlog of devices to play with for F-39. > > It looks like it's not finding the storage, you don't mention what sort of > storage you're trying to run Fedora from, is it the SD card or do you have > the firmware on SD and Fedora on something else? > > So I've finally started to look at this and yes, it looks like there's > issues with the SD card in Linux although apparently it should be > supported. I will be looking at that over the weekend. > > I need to find a spare NVME drive to put in it. > > The plan is to have some level of support in Fedora 40. > > The upstream status as documented here is a pretty good overview of > where we're at upstream: > https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md > > On Sun, 30 Jul 2023, 13:18 Andreas Reschke, wrote: > > Hi there, > I've tried to install Fedora on my Rock 5 without success. > > Booting with > https://github.com/edk2-porting/edk2-rk3588/releases/download/v0.7.1/rock-5b_UEFI_Release_v0.7.1.img > on SD-Card and source from > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/iso/Fedora-Everything-netinst-aarch64-Rawhide-20230730.n.0.iso. > > Board boots up fine but later starting in loop with > 350.456154] dracut-initqueue[1065]: Warning: # Anaconda > installer errors end ### > [ 352.156835] dracut-initqueue[1065]: Warning: dracut-initqueue: > timeout, still waiting for following initqueue hooks: > [ 352.161387] dracut-initqueue[1065]: Warning: > /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2froot.sh: "[ -e > "/dev/root" ]" > [ 352.164564] dracut-initqueue[1065]: Warning: > /lib/dracut/hooks/initqueue/finished/wait_for_disks.sh: "[ "$main_loop" > -ge "10" ]" > [ 352.167716] dracut-initqueue[1065]: Warning: > /lib/dracut/hooks/initqueue/finished/wait_for_settle.sh: "[ -f > /tmp/settle.done ]" > [ 352.171999] dracut-initqueue[1065]: Warning: dracut-initqueue: > starting timeout scripts > [ 352.172610] dracut-initqueue[1065]: Warning: # Anaconda > installer errors begin # > [ 352.172852] dracut-initqueue[1065]: Warning: # > # > [ 352.173097] dracut-initqueue[1065]: Warning: It seems that the boot > has failed. Possible causes include > [ 352.173296] dracut-initqueue[1065]: Warning: missing inst.stage2 or > inst.repo boot parameters on the > [ 352.173537] dracut-initqueue[1065]: Warning: kernel cmdline. Please > verify that you have specified > [ 352.173731] dracut-initqueue[1065]: Warning: inst.stage2 or inst.repo. > [ 352.173918] dracut-initqueue[1065]: Warning: Please also note that > the 'inst.' prefix is now mandatory. > [ 352.174156] dracut-initqueue[1065]: Warning: # > # > [ 352.174354] dracut-initqueue[1065]: Warning: Installer > errors encountered during boot: > [ 352.174543] dracut-initqueue[1065]: Warning: # > # > [ 352.174775] dracut-initqueue[1065]: Warning: Reason unknown > [ 352.174970] dracut-initqueue[1065]: Warning: # > # > > Full log file: see rock.txt > > Has anybody more succcess ? > > Greetings > Andreas___ > arm mailing list -- arm@lists.fedoraproject.org > To unsubscribe send an email to arm-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > > -- > ___ > arm mailing list -- arm@lists.fedoraproject.org > To unsubscribe send an email to arm-le...@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@lis
[fedora-arm] Re: Fedora on Rock 5B
Hi Folks, > It's in my backlog of devices to play with for F-39. > > It looks like it's not finding the storage, you don't mention what sort of > storage you're trying to run Fedora from, is it the SD card or do you have > the firmware on SD and Fedora on something else? So I've finally started to look at this and yes, it looks like there's issues with the SD card in Linux although apparently it should be supported. I will be looking at that over the weekend. I need to find a spare NVME drive to put in it. The plan is to have some level of support in Fedora 40. The upstream status as documented here is a pretty good overview of where we're at upstream: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md > On Sun, 30 Jul 2023, 13:18 Andreas Reschke, wrote: >> >> Hi there, >> I've tried to install Fedora on my Rock 5 without success. >> >> Booting with >> https://github.com/edk2-porting/edk2-rk3588/releases/download/v0.7.1/rock-5b_UEFI_Release_v0.7.1.img >> on SD-Card and source from >> https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/iso/Fedora-Everything-netinst-aarch64-Rawhide-20230730.n.0.iso. >> >> Board boots up fine but later starting in loop with >> 350.456154] dracut-initqueue[1065]: Warning: # Anaconda >> installer errors end ### >> [ 352.156835] dracut-initqueue[1065]: Warning: dracut-initqueue: >> timeout, still waiting for following initqueue hooks: >> [ 352.161387] dracut-initqueue[1065]: Warning: >> /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2froot.sh: "[ -e >> "/dev/root" ]" >> [ 352.164564] dracut-initqueue[1065]: Warning: >> /lib/dracut/hooks/initqueue/finished/wait_for_disks.sh: "[ "$main_loop" >> -ge "10" ]" >> [ 352.167716] dracut-initqueue[1065]: Warning: >> /lib/dracut/hooks/initqueue/finished/wait_for_settle.sh: "[ -f >> /tmp/settle.done ]" >> [ 352.171999] dracut-initqueue[1065]: Warning: dracut-initqueue: >> starting timeout scripts >> [ 352.172610] dracut-initqueue[1065]: Warning: # Anaconda >> installer errors begin # >> [ 352.172852] dracut-initqueue[1065]: Warning: # >> # >> [ 352.173097] dracut-initqueue[1065]: Warning: It seems that the boot >> has failed. Possible causes include >> [ 352.173296] dracut-initqueue[1065]: Warning: missing inst.stage2 or >> inst.repo boot parameters on the >> [ 352.173537] dracut-initqueue[1065]: Warning: kernel cmdline. Please >> verify that you have specified >> [ 352.173731] dracut-initqueue[1065]: Warning: inst.stage2 or inst.repo. >> [ 352.173918] dracut-initqueue[1065]: Warning: Please also note that >> the 'inst.' prefix is now mandatory. >> [ 352.174156] dracut-initqueue[1065]: Warning: # >> # >> [ 352.174354] dracut-initqueue[1065]: Warning: Installer >> errors encountered during boot: >> [ 352.174543] dracut-initqueue[1065]: Warning: # >> # >> [ 352.174775] dracut-initqueue[1065]: Warning: Reason unknown >> [ 352.174970] dracut-initqueue[1065]: Warning: # >> # >> >> Full log file: see rock.txt >> >> Has anybody more succcess ? >> >> Greetings >> Andreas___ >> arm mailing list -- arm@lists.fedoraproject.org >> To unsubscribe send an email to arm-le...@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 >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: How to install on soldered eMMC storage?
> Nowadays several SBC devices provide eMMC storage soldered and no longer > removable. How to install on this? This is not a new thing. > My first idea was to first install on mSD card, boot, and from this repeat > the installation with the eMMC target. But this doesn’t work at least with > Server. It complains about duplicate UUID partition and aborts. What do you mean by "repeat the installation" in this context. I have used this way in the past, but at times the way I deal with this on weird devices I am boot strapping may not what we want to propose. > Do we need an additional target, e.g. (configured)disk.img that we can push > via OTG to the eMMC? What do you mean by this? > Or any other, better, easier idea? This can be very device, or at the very least SoC specific. There are some devices where you can put it into a mode where the eMMC can be exported as a USB gadget storage device where you can just use arm-image-installer to write directly to eMMC over USB. There's others where you can use a special tool to basically dd something to the storage using their special protocol over USB. Because there's no one single way to do it I always just put it on the back burner because I've never had the time to look at a holistic way of making all the options available to users via a single tool front end. Peter -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Update U-Boot on Pinebook Pro ?
On Fri, 12 Jan 2024 at 10:28, Dominik 'Rathann' Mierzejewski wrote: > > On Friday, 12 January 2024 at 09:57, Andreas Reschke wrote: > > Hello together, hello Peter, > > > > I've on my Pinebook Pro U-Boot 2022.10. > > > > Howto: https://nullr0ute.com/2021/05/fedora-on-the-pinebook-pro/ > > > > Does it make sence to update U-Boot to up2date Version from Fedora 39 > > (uboot-images-armv8-2023-07-3.fc39.noarch) ? Are there any significant > > changes ? ATM probably not, there's not been a lot of changes upstream in terms of features for the PBP for a few cycles. > Whatever you decide, don't install 2023.10-rc3. It's broken. I still > haven't found the time to disassemble my PBP and put it into maskrom > mode to recover. I'll probably have some time next week and will try > to install 2023.10 final. I suggest holding out for the moment, we rolled back to 2023.07 for Fedora 39 GA due to problems. I updated my PBP to 2024.01 this week and it also has problems, I too also need to take mine to pieces. I think upstream has changed the way needed to flash it and I need to work out what that is and either fix it upstream or update the post. There's also some other general fixes needed for F-40 I'm working with upstream to resolve. In short, watch this space, I'll update when I have something more concrete. Peter -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: F38->F39
On Sat, Dec 30, 2023 at 4:31 PM David Legg wrote: > > Thanks, Gents. I used Peter Robinson's command (below) and it worked > fine, performing the upgrade from F38 to F39 in about half an hour. Good news. > The only thing that 'broke' was gpiofind, which has disappeared. On > closer inspection, it is not really needed in F39, but I did have to > rework all my gpioset commands. Yes, we moved to the new libgpiod v2, I believe the gpiofind functionality was rolled into something else (the README or upstream notes may help there). > I noticed that commands of the kind, > > gpioset -p 5s line=0 > > (to assert a line for, say, 5 seconds) do not really work. Such a > command just asserts the line for ever rather than for just 5 seconds. > The man page does say that the -p flag gives you "at least" the time > specified, but just asserting the line for ever does not really seem in > the spirit of the command (to me). Interesting, may be worth feeding this back to upstream. Let me know if I can help. > Thanks for you help Brad and Peter, > > :D > > On 30/12/2023 13:21, Peter Robinson wrote: > > On Sat, Dec 30, 2023 at 11:16 AM David Legg wrote: > >> Is this likely to work, please? > >> > >> dnf install dnf-plugin-system-upgrade > >> dnf system-upgrade download --releasever=39 > >> dnf system-upgrade reboot > >> > >> I have the Fedora 38 minimal installed on a Raspberry Pi 4 with a few > >> extra packages. Thanks. > > You are probably likely to be better off doing a distro-sync because > > it happens online, the new rpm gpg process has issues with the rpi4 > > due to the lack of a battery backed RTC. > > > > dnf --releasever=39 --setopt=deltarpm=false distro-sync -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: F38->F39
On Sun, Dec 31, 2023 at 3:14 AM Gregory Carter wrote: > > Wait another month or two. Otherwise make sure you have a bugzilla account > and be prepared to write a bug report if it does not. > > I did what you suggested for F37-F38. It mostly worked. > > It broke my USB Ethernet which was fixed about a month later after I wrote a > fairly detailed bug report. Do you have a link to the bug report, I was not aware of any breakages and never saw any with the USB eth on the older RPi units. > > > On Sat, Dec 30, 2023 at 4:16 AM David Legg wrote: >> >> Is this likely to work, please? >> >> dnf install dnf-plugin-system-upgrade >> dnf system-upgrade download --releasever=39 >> dnf system-upgrade reboot >> >> I have the Fedora 38 minimal installed on a Raspberry Pi 4 with a few extra >> packages. Thanks. >> >> :D >> >> >> -- >> ___ >> arm mailing list -- arm@lists.fedoraproject.org >> To unsubscribe send an email to arm-le...@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 >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue > > -- > ___ > arm mailing list -- arm@lists.fedoraproject.org > To unsubscribe send an email to arm-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: F38->F39
On Sat, Dec 30, 2023 at 11:16 AM David Legg wrote: > > Is this likely to work, please? > > dnf install dnf-plugin-system-upgrade > dnf system-upgrade download --releasever=39 > dnf system-upgrade reboot > > I have the Fedora 38 minimal installed on a Raspberry Pi 4 with a few extra > packages. Thanks. You are probably likely to be better off doing a distro-sync because it happens online, the new rpm gpg process has issues with the rpi4 due to the lack of a battery backed RTC. dnf --releasever=39 --setopt=deltarpm=false distro-sync -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Raspberry Pi 5 support - how to contribute?
On Fri, Dec 29, 2023 at 11:32 AM Barry Scott wrote: > > Peter, > > I just received my Pi 5 8GB board and wondered what the current situation is > regarding > Pi 5 state of kernels etc. No change from my last update > If I can usefully help test anything I am happy to help out. > > Barry > -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: State of the mibility SIG, dec 2023
One other thing I had meant to bring up to mobility meetings, which I had been missing which I think I now realise is probably because they moved to matrix. Is handheld gaming consoles a possible focus or interest for mobility SIG? I've seen a bunch of devices, in particular the Anbernic RGXX3 ones, landing upstream so it's possible they could be a much easier target but TBH I have not looked extremely closely here. https://anbernic.com/collections/handheld-game-console On Thu, Dec 14, 2023 at 8:47 AM Peter Robinson wrote: > > Hi Kevin, > > Thanks for the update. Comments inline. > > Firstly I'd like to apologise for my lack of public participation in > the SIG, the last year or two has proven quite problematic for me > personally, I've had a lot of "higher priorities" which has reduced my > available hacking time, and that seems to quickly get gobbled up with > things like RPi regressions and release blocker bugs. Throw in a whole > bunch of mental health issues and something had to give. > > That being said, in the last few weeks I have been actually back to > some hacking projects... more on that below. > > > This will be a bit long, but I hope it will explain the current unfortunate > > state > > of the mobility sig. > > > > First a bit of history. The mobility sig was originally formed back in 2010. > > The goal then was “… a group of Fedora contributors that are interested in > > Fedora on small devices. Initially aimed at supporting NetBooks, Mobile > > Internet devices” > > A good deal of progress on small devices like netbooks and tablets was made, > > but then the members of the SIG moved on to other concerns. Then, in 2020 > > the > > most recent version of the SIG formed. The goal was focused on getting > > Fedora > > working well on the new pine64 pinephone, and then later when announced the > > new > > pine64 pinephone pro. > > > > In the last 3 years we have accomplished a lot: > > > > The phosh stack has been packaged up > > We have been producing Fedora Remixes with 3rd party kernels to provide > > support > > for pinephone and pinephone pro. > > a Phosh spin has been created and officially produced > > There was a effort to get a remix working for the oneplus 6, but > > still requiring a lot of manual tweaking. > > > > Unfortunately, the active members of the sig are not able to move things > > forward right now. > > The pinephone and pinephone pro are both old devices at this point. They > > were slow > > when released, and thats not improved. Worse, upstreaming of patches to get > > either > > of them working with a Fedora/Mainline kernel seems unlikely to us for a lot > > of reasons, including that many of the 3rd party patches aren’t in a state > > that > > upstream would accept and many authors of them have no particular desire to > > upstream them. > > > > The phosh spin is largely not useful in the current situation as the > > Fedora mainline kernel barely boots on the pinephone pro (not at all on the > > pinephone) and has no wireless or display. The image could be of use to > > other aarch64 single board style devices, but since they usually don’t have > > displays or modems, the phosh interface isn’t of particular insterest. > > So I have been booting the original Pinephone on Fedora 39, display > works so I'd be interested in the issues you're seeing there. I'm > booting the original PP because of the Wireless, I've been looking at > some of the realtek modules for another project but hoping the side > effect is actually the rtl8723 series devices should be upstream > soon(ish). This should also resolve the issue on the original PineTab > although I don't remember who has that as I don't (the people that do > please reach out if you want to help testing). > > The PPP is also on my list to look at again soon, initially it'll be > around U-Boot due to the F-39 blocker issues as I'm working to resolve > that upstream for once so I'll be testing that on my PPP, I thought we > had the wireless and screen there, I do need to circle back more to > this one though TBH. > > > Until the advent of some performant mobile device to target or more > > contributors who wish to drive things forward, I think we should just > > mark the Mobility sig inactive at this point, including: > > I think marking the SIG as inactive probably makes sense. > > > Retire the Phosh spin in f40 > > What's currently produced here? > > > Hopefully find new maintainers for the phosh stack if there’s folks > > that want to keep them alive. > >
[fedora-arm] Re: State of the mibility SIG, dec 2023
Hi Kevin, Thanks for the update. Comments inline. Firstly I'd like to apologise for my lack of public participation in the SIG, the last year or two has proven quite problematic for me personally, I've had a lot of "higher priorities" which has reduced my available hacking time, and that seems to quickly get gobbled up with things like RPi regressions and release blocker bugs. Throw in a whole bunch of mental health issues and something had to give. That being said, in the last few weeks I have been actually back to some hacking projects... more on that below. > This will be a bit long, but I hope it will explain the current unfortunate > state > of the mobility sig. > > First a bit of history. The mobility sig was originally formed back in 2010. > The goal then was “… a group of Fedora contributors that are interested in > Fedora on small devices. Initially aimed at supporting NetBooks, Mobile > Internet devices” > A good deal of progress on small devices like netbooks and tablets was made, > but then the members of the SIG moved on to other concerns. Then, in 2020 the > most recent version of the SIG formed. The goal was focused on getting Fedora > working well on the new pine64 pinephone, and then later when announced the > new > pine64 pinephone pro. > > In the last 3 years we have accomplished a lot: > > The phosh stack has been packaged up > We have been producing Fedora Remixes with 3rd party kernels to provide > support > for pinephone and pinephone pro. > a Phosh spin has been created and officially produced > There was a effort to get a remix working for the oneplus 6, but > still requiring a lot of manual tweaking. > > Unfortunately, the active members of the sig are not able to move things > forward right now. > The pinephone and pinephone pro are both old devices at this point. They were > slow > when released, and thats not improved. Worse, upstreaming of patches to get > either > of them working with a Fedora/Mainline kernel seems unlikely to us for a lot > of reasons, including that many of the 3rd party patches aren’t in a state > that > upstream would accept and many authors of them have no particular desire to > upstream them. > > The phosh spin is largely not useful in the current situation as the > Fedora mainline kernel barely boots on the pinephone pro (not at all on the > pinephone) and has no wireless or display. The image could be of use to > other aarch64 single board style devices, but since they usually don’t have > displays or modems, the phosh interface isn’t of particular insterest. So I have been booting the original Pinephone on Fedora 39, display works so I'd be interested in the issues you're seeing there. I'm booting the original PP because of the Wireless, I've been looking at some of the realtek modules for another project but hoping the side effect is actually the rtl8723 series devices should be upstream soon(ish). This should also resolve the issue on the original PineTab although I don't remember who has that as I don't (the people that do please reach out if you want to help testing). The PPP is also on my list to look at again soon, initially it'll be around U-Boot due to the F-39 blocker issues as I'm working to resolve that upstream for once so I'll be testing that on my PPP, I thought we had the wireless and screen there, I do need to circle back more to this one though TBH. > Until the advent of some performant mobile device to target or more > contributors who wish to drive things forward, I think we should just > mark the Mobility sig inactive at this point, including: I think marking the SIG as inactive probably makes sense. > Retire the Phosh spin in f40 What's currently produced here? > Hopefully find new maintainers for the phosh stack if there’s folks that > want to keep them alive. How much work is this? How many packages? > Mark the sig inactive on wiki and matrix. Just as I actually get the energy to setup matrix :-P although I am yet to find the SIG there > respins will move to against a stable fedora release once a week or so, > instead of against rawhide and more often. What's in the respins? Is that basically Fedora and custom kernel? > Hopefully there is someday a brighter day for Fedora mobile devices. > Folks that want to try and revive the SIG and/or are able to see a good > path forward are invited to join #mobility:fedoraproject.org. Peter -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Fedora on ROCK 5 Model B
Hi, > I've installed Fedora 40 Rawhide on my Rock 5 > > Short howto: > > What you need: > 1) > https://github.com/edk2-porting/edk2-rk3588/releases/download/v0.9.1/rock-5b_UEFI_Release_v0.9.1.img > dd this Image on a SD-Card > > 2) > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/iso/Fedora-Everything-netinst-aarch64-Rawhide-20231113.n.0.iso > > dd this Image on a USB stick > > Put both in your Rock 5B and boot. I've done the Net-install installation > with KDE Wayland. The SD-Card with UEFI is needed for booting. > > > Questions: > > 1. GPU: > root@rockpi5:~# inxi -Gx > Graphics: > Message: No PCI device data found. > Display: server: X.Org v: 23.2.2 with: Xwayland v: 23.2.2 driver: X: >loaded: modesetting dri: swrast gpu: N/A resolution: 1920x1080~60Hz > API: EGL v: 1.5 drivers: kms_swrast,swrast platforms: >active: gbm,x11,surfaceless,device inactive: wayland > API: OpenGL v: 4.5 vendor: mesa v: 23.3.0 glx-v: 1.4 direct-render: yes >renderer: llvmpipe (LLVM 17.0.4 128 bits) > API: Vulkan v: 1.3.268 drivers: llvmpipe surfaces: xcb,xlib devices: 1 > root@rockpi5:~# > > How can I improve GPU Performance ? Mali / Panfrost Driver are available but > not loaded /used > > root@rockpi5:~# rpm -ql mesa-dri-drivers-23.3.0-1.fc40.aarch64 | grep -i pan > /usr/lib64/dri/panfrost_dri.so > root@rockpi5:~# rpm -ql mesa-dri-drivers-23.3.0-1.fc40.aarch64 | grep -i mali > /usr/lib64/dri/mali-dp_dri.so > root@rockpi5:~# > > Creating a custom xorg.conf doesn't make sense while using Wayland ? That won't make any difference. The support for accelerated graphics isn't upstream yet. There's a few series of patches that would need to land, at least this one [1], and one to support HDMI, possibly more. Looking at [1] I doubt that will now land for 6.8, the rule of thumb is usually it has to be accepted by rc5 of the previous cycle, so we'd be looking at 6.9 at the earliest assuming any other patch series also land, it'll also need patches for device tree. You could collect the patch series together and build a kernel if you want it before then. > 2. Boot > > Is there any way to boot Fedora direct from NVME instead using > rock-5b_UEFI_Release_v0.9.1.img on SD-Card ? You need to put the FW on the SPI flash, not sure if the firmware supports that yet, but there's confirmation it'll work at some point in their FAQ: https://wiki.radxa.com/Rock5/FAQs#Q:_Without_eMMC_and_TF_card.2C_can_ROCK_5B_boot_from_PCIe_M.2_NVME_SSD.3F [1] https://lists.freedesktop.org/archives/dri-devel/2023-December/434211.html -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: GPIO @ Fedora38 WS
Hi René, I've copied the Fedora arm list, please email the list or post on the Fedora forumus in the future, it allows others to reply as well as learn from replied. On Mon, Nov 27, 2023 at 12:06 PM René Kummer wrote: > > Dear Peter Robinson, > > I read your post on the internet > (https://fedoraproject.org/wiki/Changes/RaspberryPi4). > > I am using fedora 38 on my Raspberry Pi4. > > I would say I like it running fedora on my Pi. > > It fits all my needs up to now except one thing. > > I wanted to use the GPIO ports but I can't figure out how to do so. > > So, the first step was trying to install pigpio library via dnf. But > there seem to be no such package. > > Mhh I ended up confused and not knowing how to install pigpio. > > The next step was to compile pigpio library by my own, that was also not > successful. TBH I had never heard of pigpio until you just mentioned it now. > My question is, is it possible to use the GPIO Ports with fedora > workstation 38. The main way we support GPIO on any device in Fedora is via the gpiod character interface: /dev/gpiochip* The main userspace libaries for this is libgpiod and python3-libgpiod but anything that supports the kernel gpiod character interfaces should work. The problem with a lot of the RPi specific interfaces for GPIO is that the RPi has uses an old deprecated GPIO interface with their own custom set of patches on top. We don't support those. > The pigpio library would be a good choice in my humble opinion, but if > it is not supported, could you tell me a system package or a way for > using GPIO? > > So I tried my best to address the issue in English. > > I look forward to getting a response :) > > So have a nice day. > > Best regards > > -- > beste Grüße René Kummer > -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: CoreOS on NanoPC-T6 (RK3588)
On Sat, Nov 25, 2023 at 3:35 PM Waldemar Kornewald wrote: > > Hi, > did anyone succeed booting a FriendlyElec NanoPC-T6? Since there was some > success report with Radxa Rock 5B recently, I was hoping that the NanoPC-T6 > wouldn't be too different. > > So, I tried CoreOS 40 with EDK2 (https://github.com/edk2-porting/edk2-rk3588) > and the Linux 6.7-rc2 rk3588-nanopc-t6 device tree placed in the ESP. While > ACPI didn't want to boot at all, the device tree boot at least spits out some > more logs. However, the system just abruptly disappears in the end: > https://pastebin.com/zqs7nQ8L > > I also tried Fedora 40 (Minimal), but that runs into a CPU lockup: > https://pastebin.com/aafvP6du > > In both cases the OS image was copied to eMMC while EDK2 was on an SD card. > > Any ideas why the NanoPC-T6 doesn't want to boot? What storage are you using? Overall the support for the T6 upstream is still prerry rudimentary when I looked last week because someone else asked. -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Raspberry Pi 5 support - how to contribute?
Hi Folks, Just thought I'd post an update here now I've got one and spent a few hours today poking around with a vanilla RPiOS minimal image. > > I've recently - and somewhat surprisingly - already got my hands into a > > Raspberry Pi 5. I would like to contribute to make it supported , as the > > Pi4 is. > > I'm still awaiting mine, apparently it's due "soon" > > > I have extensive Fedora experience, but not with ARM, and how the whole > > ecosystem works. What would be useful to get started with a test image for > > the Pi5? Or if that's not yet possible, what information or resources can > > be of use to get to that points? > > So TBH I'm not 100% sure what needs to be done as yet until my device arrives. > > The biggest problem with the RPi5 is the new RP1 chip as a LOT of > things hang off that. Looking at the chip design [1] a lot of the > peripherals now hang off what is basically a PCIe-EP <-> AXI bridge. > Most of the rest of the peripheral IP appears to be off the shelf, > USB, Sound etc, and should just work once that first driver lands > upstream. I am not sure who is looking at that driver and if there are > any plans in place to push that upstream. > > The graphics and other pieces are already headed upstream. > > The other piece of the pie (pun intended) is the early boot process, > I'll look at that once I get a device. AFAICT that actually looks > quite similar to existing bits, but again it depends on how things > like mSD are placed on the system and what dependencies are needed. So a quick look indicates there will be quite a bit of work to do. Some general notes: * The graphics for acceleration via HDMI is headed upstream * The mSD card and WiFi uses the sdhci-brcmstb driver, for both linux and U-Boot which is upstream but needs patches * The PCIe uses the upstream pcie-brcmstb driver, like in the rpi4, but again needs some patches * The vast majority of everything else hangs of the RP1 chip which is a uses a weird PCIe-EP to AXI bus bridge thing which AFAICT needs a MFD driver to be upstreamed to unlock the fairly generic IP that provides the rest. * The rest of the main generic IP that makes up the RP1 chip that the vast majority of users care about are mostly upstream drivers that just need minor patches to deal with the quirks that make up the RP1 chip. * Wired network: macb driver NIC with broadcom PHY - upstream needs patches * dw-axi-dmac DMA controller needs patches * USB is dwc3 needs patches * Sound upstream needs patches * RP1 embedded GPIO/SPI/I2C/sdhci/TTL upstream needs patches * Things like MIPI (DSI and CSI), video offload, pwm and a bunch of other IP don't have enough detail to know as yet So the long story short is ATM nothing will work with vanilla upstream kernel yet unless you could serial console and display. I'm hoping that various kernel people will start to poke around and get pieces upstream, the biggest individual piece of work is definitely the PCIe end point to AXI bridge driver piece as without that nothing on the RP1 chip will work. But getting a basic device booting with serial console, mSD for storage and WiFi and PCIe, for a HAT shouldn't be too hard, I'll likely start to play with a kernel in copr and do a basic minimal image (via the new osbuild support) for those that want something to start to play with but that will be as time permits. Peter -- ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Raspberry Pi 5 support - how to contribute?
Hi Daniel, > I've recently - and somewhat surprisingly - already got my hands into a > Raspberry Pi 5. I would like to contribute to make it supported , as the Pi4 > is. I'm still awaiting mine, apparently it's due "soon" > I have extensive Fedora experience, but not with ARM, and how the whole > ecosystem works. What would be useful to get started with a test image for > the Pi5? Or if that's not yet possible, what information or resources can be > of use to get to that points? So TBH I'm not 100% sure what needs to be done as yet until my device arrives. The biggest problem with the RPi5 is the new RP1 chip as a LOT of things hang off that. Looking at the chip design [1] a lot of the peripherals now hang off what is basically a PCIe-EP <-> AXI bridge. Most of the rest of the peripheral IP appears to be off the shelf, USB, Sound etc, and should just work once that first driver lands upstream. I am not sure who is looking at that driver and if there are any plans in place to push that upstream. The graphics and other pieces are already headed upstream. The other piece of the pie (pun intended) is the early boot process, I'll look at that once I get a device. AFAICT that actually looks quite similar to existing bits, but again it depends on how things like mSD are placed on the system and what dependencies are needed. Long story short most of the work required will be low level kernel pieces, and while I've had a little look at patches I've not got a full plan yet. Let me know what pieces you're interested in looking at. Peter [1] https://datasheets.raspberrypi.com/rp1/rp1-peripherals.pdf ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: No devices with F39 on Raspberry Pi
On Sun, Oct 29, 2023 at 7:26 PM Peter Boy wrote: > > > > > Am 29.10.2023 um 19:39 schrieb Peter Robinson : > > > >>> > >>> > >>> > >>> The bottom line is that Server Edition is still unusable on Raspi4 and > >>> any other SBC, unfortunately. What to do and how to proceed (the next > >>> go/no-go meeting is in 4 days expecting rc 1.4 tomorrow or shortly after) > >>> ? > >> > >> Did you file a bug so it can be tracked and discussed in a central > >> location? Please reference it here too. > > I’m about to do, but I’m unsure which component to select. U-boot seems > wrong, because it is most likely the image generation, I guess. > > Do you know which component I should select? > > > > > > > BTW have you tested with the new arm-image-installer > > (arm-image-installer-3.9-2.fc39) ? I've just added that to the update, > > it fixes some bits with LVM. > > > I used version 3.8 which is part of the rc 1.2. How do I get version 3.9-2? I > simple def update does not do it. Grab the rpm from koji? ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: No devices with F39 on Raspberry Pi
On Sun, Oct 29, 2023 at 6:22 PM Peter Robinson wrote: > > On Sun, Oct 29, 2023 at 4:24 PM Peter Boy wrote: > > > > Just checked the F39 rc1.2 on an raspi4 with Server Edition. > > > > The fix for the display issue > > (https://bugzilla.redhat.com/show_bug.cgi?id=2241252) does work for Server, > > too. > > Can you update the RHBZ and add karma so that can go stable. > > > But there is a next issue: > > > > If I try to adjust the LVM volume to the size of the SD card, I can enlarge > > the partition mmcblk0p3 using cfdisk as usual without issues. But with > > pvresize I get > > > > > $ sudo pvresize /dev/mmcblk0p3 > > > [sudo] password for pb: > > > Cannot use /dev/mmcblk0p3: device is not in devices file > > > 0 physical volume(s) resized or updated / 0 physical volume(s) not resized > > > > > > A lsblk > > > > > # lsblk > > > NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINTS > > > mmcblk0 179:00 59.5G 0 disk > > > ├─mmcblk0p1 179:10 600M 0 part /boot/efi > > > ├─mmcblk0p2 179:201G 0 part /boot > > > └─mmcblk0p3 179:30 57.9G 0 part > > > └─fedora-root 253:00 5.4G 0 lvm / > > > zram0 252:00 3.7G 0 disk [SWAP] > > > > > > looks fine and as expected. > > > > And with cockpit -> storage the category „devices“ is empty (instead of > > listing a LVM volume fedora as to expect). It seems, there is something > > badly wrong with the image. Hence the error message with arm-installer > > after writing the image onto disk: > > > > > = Writing image complete! > > > mount: /tmp/root: unknown filesystem type 'LVM2_member'. > > > dmesg(1) may have more information after failed mount system call. > > > > as mentioned in an earlier mail and as discussed at the go/no-go meeting > > (https://meetbot.fedoraproject.org/fedora-meeting/2023-10-26/f39-final-go_no_go-meeting.2023-10-26-17.00.log.html > > ) > > > > > > The bottom line is that Server Edition is still unusable on Raspi4 and any > > other SBC, unfortunately. What to do and how to proceed (the next go/no-go > > meeting is in 4 days expecting rc 1.4 tomorrow or shortly after) ? > > Did you file a bug so it can be tracked and discussed in a central > location? Please reference it here too. BTW have you tested with the new arm-image-installer (arm-image-installer-3.9-2.fc39) ? I've just added that to the update, it fixes some bits with LVM. Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: No devices with F39 on Raspberry Pi
On Sun, Oct 29, 2023 at 4:24 PM Peter Boy wrote: > > Just checked the F39 rc1.2 on an raspi4 with Server Edition. > > The fix for the display issue > (https://bugzilla.redhat.com/show_bug.cgi?id=2241252) does work for Server, > too. Can you update the RHBZ and add karma so that can go stable. > But there is a next issue: > > If I try to adjust the LVM volume to the size of the SD card, I can enlarge > the partition mmcblk0p3 using cfdisk as usual without issues. But with > pvresize I get > > > $ sudo pvresize /dev/mmcblk0p3 > > [sudo] password for pb: > > Cannot use /dev/mmcblk0p3: device is not in devices file > > 0 physical volume(s) resized or updated / 0 physical volume(s) not resized > > > A lsblk > > > # lsblk > > NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINTS > > mmcblk0 179:00 59.5G 0 disk > > ├─mmcblk0p1 179:10 600M 0 part /boot/efi > > ├─mmcblk0p2 179:201G 0 part /boot > > └─mmcblk0p3 179:30 57.9G 0 part > > └─fedora-root 253:00 5.4G 0 lvm / > > zram0 252:00 3.7G 0 disk [SWAP] > > > looks fine and as expected. > > And with cockpit -> storage the category „devices“ is empty (instead of > listing a LVM volume fedora as to expect). It seems, there is something badly > wrong with the image. Hence the error message with arm-installer after > writing the image onto disk: > > > = Writing image complete! > > mount: /tmp/root: unknown filesystem type 'LVM2_member'. > > dmesg(1) may have more information after failed mount system call. > > as mentioned in an earlier mail and as discussed at the go/no-go meeting > (https://meetbot.fedoraproject.org/fedora-meeting/2023-10-26/f39-final-go_no_go-meeting.2023-10-26-17.00.log.html > ) > > > The bottom line is that Server Edition is still unusable on Raspi4 and any > other SBC, unfortunately. What to do and how to proceed (the next go/no-go > meeting is in 4 days expecting rc 1.4 tomorrow or shortly after) ? Did you file a bug so it can be tracked and discussed in a central location? Please reference it here too. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Do we have a chance to get a fix vor the Server variant?
> Just a question: Now, that the f39 release is delayed by a week, do we have a > chance of a fix for the server variant? I will en devour to fix it. > For one thing, the problem of the failed mount of the image would have to be > fixed on the server variant. As far as I understand the arm installation > script, either something is wrong with the disk image or it has been changed > and that needs to be addressed in the script now. Is there a RHBZ for this? We would need it for blocker/FE process. From the reply from Adam on the thread there it's not clear what the exact problem is. Help as always is appreciated. > And furthermore it would be very helpful if the workaround for the black > screen could also be done transitionally with the script. I'm not sure what you mean here. Could you elaborate. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Fwd: [Call for Action] Help Testing F39 ARM
For arm testers too -- Forwarded message - From: Geoffrey Marr Date: Thu, Oct 26, 2023 at 5:05 AM Subject: [Call for Action] Help Testing F39 ARM To: Fedora discussions about the Internet of Things Hi IoT Testers, Tomorrow will be the Fedora 39 Go/No-Go (26 October 2023). Currently, there are several Raspberry Pi-related blockers that will be up for consideration at the meeting. There is a plan to attempt to get sufficient testing on an RC that was spun up several hours ago, and then vote to ship this as F39 with a notice that RPi is not supported at launch and that users should not upgrade from F38 until the issue is fixed. Because of the widespread use of RPi hardware in IoT and ARM testing however, and these bugs affecting the ability of users to test with the RPi, the F39 ARM version specifically is lacking in test results. I am reaching out to the IoT list in the hope that some of you might have ARM hardware *other than* RPi that could be used to help fill in the test matrix [0]. This could be the Jetson Nano, Odroid XU4, or any other ARM board that can boot F39 ARM and help with testing. You can find a list of other supported hardware here: [1]. This approach is a bit unorthodox, but the commonalities between Fedora IoT and Fedora ARM are such that some of the IoT users might have ARM hardware laying around that could be used for testing. Your test results will help us ship F39 without slipping again! Thanks everyone! Geoff Marr IRC: coremodule [0] https://fedoraproject.org/wiki/Test_Results:Fedora_39_RC_1.2_Summary [1] https://fedoraproject.org/wiki/Architectures/ARM#Supported_Hardware_and_Devices ___ IoT mailing list -- i...@lists.fedoraproject.org To unsubscribe send an email to iot-le...@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/i...@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: [Fedocal] Reminder meeting : Fedora ARM & AArch64 status meeting
On Tue, Oct 24, 2023 at 5:08 PM Adam Williamson wrote: > > On Mon, 2023-10-23 at 16:00 +, coremod...@fedoraproject.org wrote: > > Dear all, > > > > You are kindly invited to the meeting: > >Fedora ARM & AArch64 status meeting on 2023-10-24 from 16:00:00 to > > 17:00:00 UTC > > Er. From the logs, it appears this meeting happened at 15:00 UTC? > > I was hoping to attend and emphasize we really need something done > about the outstanding blockers today to avoid yet another slip :( I am working on it as best as I can in between all my other responsibilities and a steaming cold. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: RPi4 and support for RTC DS3231
> You'll need to follow the general section for HAT support (it's > basically any HW that needs an overlay) and reboot and it should work: > https://fedoraproject.org/w/index.php?title=Architectures/ARM/Raspberry_Pi/HATs#General_configuration > > That RTC is supported by the rtc-ds1307 driver. > > > I missed the link at the end of the config.txt that was Fedora specific. > Maybe you could put that Fedora specific comment at the start of config.txt > in a future release? What a fantastic suggestion, I've changed it locally. It used to a be lot higher up but with various changes it slipped down. > I have followed the steps and the RTC is working. > I would like to add a section on the RTC to the docs. If that is useful how > do I go about doing that? Sure, it's a wiki so feel free to just add it, maybe make it generic to cover all RTCs. Let me know how you get on. > But I have lost the HDMI console. I can ssh into the system and it is > otherwise working. > > I see the boot sequence, u-boot, grub, last message on screen is the Fedoara > kernel line > announcing its version. After a few seconds where I would expect to see > systemd messages > instead the monitor goes into standby. > > Do I need to change setting in config.txt to make the HDMI work? Nothing, it's actually broken ATM, it's a F-39 blocker and I'm hoping to get it fixed today. There's a U-Boot thread on the mailing list and once I have a fix I'll be posting a reply on that so keep an eye out on the list for an update. Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: RPi4 and support for RTC DS3231
On Thu, Oct 19, 2023 at 4:22 PM Barry Scott wrote: > > I have an RPi4 running Fedora 38 with kernel 6.5.6-200.fc38.aarch64. > > So far I figured out that I have to add this line to the config.txt > > [pi4] > dtoverlay=i2c-rtc,ds3231 > > But after a reboot I am not seeing any /dev/rtc* devices. > Also I'm not seeing any rtc drivers load in lsmod output. > > Should this work with the Fedora kernel? > If so what do I need to do to make the RTC show up? You'll need to follow the general section for HAT support (it's basically any HW that needs an overlay) and reboot and it should work: https://fedoraproject.org/w/index.php?title=Architectures/ARM/Raspberry_Pi/HATs#General_configuration That RTC is supported by the rtc-ds1307 driver. Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: U-Boot testing request - 2023.10 series
Hi Nicolas, > > > Hi Folks, > > > > > > The 2023.10 RC series are now landing in F-39 and rawhide. There's > > > been the beginnings of a few enhancements. > > ... > > > least be no different than the usual process but I'd like to hear any > > > feedback. > > > > I have an issue on jetson-tx1 (L4T 32.7.4) with this f39 u-boot build: > > Everything operates correctly under u-boot, but then after entering > > initramfs the CPU hard lockup. > > Just some follow-up about this issue. I've tested again recently (with > 2023.10 GA rebased from f39 packages). > And the issue still arises with me. But it could be because of some > mess with /boot/dtb symlink and device-tree location expectation. (my > /boot/dtb wasn't updated There was a bug with grub2 here, but it never made it to GA, of course with updates-testing enabled by default anyone running pre freeze F-39 got it: https://bugzilla.redhat.com/show_bug.cgi?id=2243060 > When I tried to report to #u-boot upstream, it's the first question > that was raised (is device-tree rightly found ?). > Of course our distro patch might help The Jetson (pre Xavier) devices won't boot without the kernel DT, the DT provided by U-Boot has some issue around the global timer and the kernel crashes in very early boot. It's something that I've been meaning to look into but haven't had the time. > The problem is that in-between I've broken my micro-usb port, so I > cannot update u-boot anymore on the jetson-tx1 (and I'm stuck with > fedora based u-boot 2023.07 there). 2023.07? That's still quite new. > Anyway, I don't think it's a blocker for F39 GA, so if anyone is able > to reproduce (or not) it is worth mentioning in the wiki. I can reproduce, and I have been looking into it along with the issues with the RPi4. I have currently 5 or 6 issues on my list including 3 with the RPi, these ones and possibly more. The issues for some reason which I'm unsure about are proving very difficult to bisect which is causing me issues around timing but overall I am hoping to get to the bottom of them all tomorrow and a new official build done, I was planning on replying on this thread when I have a new package for testing. Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: wireless-tools
Adding back arm list: > It took a bit of fiddling to get the RPI 4 wireless up, > so here are the requisite commands for use by anyone else who is doing a > headless, wireless pi with Fedora 38 aarch64: > > # iw dev wlan0 info > > # nmcli device wifi list # Get SSID > # nmcli device wifi connect "SSID" password "whatever" Yes, these two commands are really all you need: nmcli device wifi list nmcli device wifi connect SSID --ask > # nmcli -p -f general,wifi-properties device show wlan0 > > # find /etc -name SSID.nmconnection -print # to locate config file > automatically created by nmcli commands. > ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: wireless-tools
> Just installed Fedora 38 (minimal) on an RPI 4 and found that the > wireless-tools package is not available. Anybody know where to get > iwconfig etc from, please? wireless-tools have been obsolete for over 15 years, you should be using iw and related tools. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: PCIe slot on Raspberry Pi CM4
On Mon, Sep 4, 2023 at 3:34 AM James Clark wrote: > > I am trying to connect an i210-T1 to the PCIe slot on a Raspberry Pi CM4 with > the official IO board. The problem is it won't boot. I tried this in Fedora > 38 initially. Now I've installed a recent nightly > (Fedora-Server-39-20230828.n.0.aarch64.raw.xz) and I've connected a USB TTL > adapter. It appears to be a U-Boot problem. I get the following over and over > again The PCIe does work because the USB-3 is a VIA PCIe attached device on the RPi4, I wonder what interesting things this card is doing to cause this error. Do you have more details like make/model of the card, is it single or multiport etc? > U-Boot 2023.10-rc3 (Aug 21 2023 - 00:00:00 +) > > DRAM: 992 MiB (effective 7.9 GiB) > RPI Compute Module 4 (0xd03141) > Core: 212 devices, 16 uclasses, devicetree: board > MMC: mmcnr@7e30: 1, mmc@7e34: 0 > Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... > In:serial,usbkbd > Out: serial,vidconsole > Err: serial,vidconsole > Net: eth0: ethernet@7d58 > PCIe BRCM: link up, 2.5 Gbps x1 (SSC) > "Error" handler, esr 0xbf02 > elr: 000b52b0 lr : 000b526c (reloc) > elr: 3df812b0 lr : 3df8126c > x0 : dead x1 : 0010 > x2 : 8000 x3 : fd508000 > x4 : 3db399f0 x5 : 0001 > x6 : 3df82bb8 x7 : 3db39fc0 > x8 : 3df82c90 x9 : 3db3992c > x10: 0002 x11: 0140 > x12: 3db39918 x13: 3db39fc0 > x14: x15: 3db39b78 > x16: 3df82c90 x17: 00c0c0c0 > x18: 3db47d60 x19: 3db399f0 > x20: 0001 x21: 3db53f00 > x22: x23: 0001 > x24: 3dfc58fc x25: 0001ff00 > x26: x27: > x28: 3db53b10 x29: 3db39950 > > Code: 350001f4 f94017e0 3940 92401c00 (d5033fbf) > Resetting CPU ... > > resetting ... > > James > > > ___ > arm mailing list -- arm@lists.fedoraproject.org > To unsubscribe send an email to arm-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Any tablets out there yet?
On Tue, Aug 29, 2023 at 8:05 AM Todd Chester wrote: > > Hi All, > > Sorry if you get asked this question a lot. > > Are there any stable tablets out there running Fedora ARM yet? My wife's > Android tablet is on its last legs and she if furious over the spying and > lack of control. Xfce would be nice. The short answer is no, not really. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Not finding RTC with a different spin?
> Once upon a time, Chris Adams said: > > Ahh, this was indeed it. I switched /boot on the XFCE image to XFS and > > it did indeed follow the config.txt entry for the RTC (so same as > > removing the /boot/dtb symlink). > > Oh, but when I run the XFCE image (with ext4 /boot as shipped) and > remove /boot/dtb... X just errors out with "no screens found". So I > can't do that either, unless there's something to change in config.txt > to match (or at least be close enough) to the kernel-provided device > tree. All the bits for screen enablement using upstream drivers should be there by default. What else have you done to your config.txt? What exactly is the revision of RPi? ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Not finding RTC with a different spin?
On Thu, Aug 24, 2023 at 4:25 PM Chris Adams wrote: > > Once upon a time, Peter Robinson said: > > I suspect the /boot partition on server is XFS and on XFCE it's ext4? > > U-Boot can't load off XFS so it falls back to the FW provided DT and > > hence basically is the same as not having the link there. > > Ahh, this was indeed it. I switched /boot on the XFCE image to XFS and > it did indeed follow the config.txt entry for the RTC (so same as > removing the /boot/dtb symlink). > > Interesting to know... learn more about the oddities of ARM booting all > the time. :) Maybe should the aarch64 images all use an ext4 /boot for > consistency and to avoid confusion? TBH I would sooner just move to firmware provided DT so we don't have to ship DT as part of the kernel at all. I've been slowly working on that but I'm not quite there yet and it's one of those items for "when I have some spare time" which has been very little of late as I've been looking at other things. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Not finding RTC with a different spin?
On Wed, Aug 23, 2023 at 8:10 PM Chris Adams wrote: > > Just to re-test: I wrote the following two images (using the same uSD > card, so not it either): > >Fedora-Server-38-1.6.aarch64.raw.xz >Fedora-Xfce-38-1.6.aarch64.raw.xz > > Wrote them out on a F37 system with arm-image-installer like: > >arm-image-installer --image --media /dev/sda --addkey > ../.ssh/id_ed25519.pub --resizefs --target rpi4 > > then, before moving the card to the Pi, mounted the first partition and > changed config.txt to include "dtoverlay=i2c-rtc,ds1307" (no other > change, so /boot/dtb symlink still present). When I boot the Server > image, it sees the RTC, when I boot the Xfce image, it does not. I suspect the /boot partition on server is XFS and on XFCE it's ext4? U-Boot can't load off XFS so it falls back to the FW provided DT and hence basically is the same as not having the link there. > On the Xfce image, if I also remove the /boot/dtb symlink, it sees the > RTC. > > So there's some inconsistency between images (maybe it's just that the > Server image is not working as expected?), but I guess I have a working > setup. Suspect it's a difference in filesystems for /boot. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Not finding RTC with a different spin?
On Wed, Aug 23, 2023 at 4:41 PM Chris Adams wrote: > > Once upon a time, Peter Robinson said: > > Ddi you follow this section of the HATs/Overlay docs? > > https://fedoraproject.org/w/index.php?title=Architectures/ARM/Raspberry_Pi/HATs#General_configuration > > It's my understand that that section is obsolete. I did not do that on > my "server" uSD card, and it loads the RTC overlay correctly. I don't know where you got that idea from. As the Raspberry Pi maintainer it's currently not. In ostree based systems we don't ship a kernel DT so it automatically uses the firmware DT so if your "server install" you're using ostree that is probably why. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Not finding RTC with a different spin?
On Wed, Aug 23, 2023 at 4:12 PM Chris Adams wrote: > > I have a Raspberry Pi 4B running Fedora 38 (server edition) that I use > as a little occasional server for random things. Since it doesn't > always have NTP available, I added an RTC module, and added > "dtoverlay=i2c-rtc,ds1307" to /boot/efi/config.txt (no other change); > all is good. > > Now I have a short-term need to use it as a desktop, so I put the XFCE > spin on a different uSD card. I made the same edit to config.txt... and > it doesn't work. No RTC. > > I've loaded all the Fedora updates, including the firmware with > "rpi-uboot-update", but it still doesn't work. If I swap back to the > "server" uSD card, it sees the RTC. > > The only difference I can see is that the original card is 32G and the > new card is 64G (so "SDXC")... would that be an issue to the firmware > loader? I doubt it. Ddi you follow this section of the HATs/Overlay docs? https://fedoraproject.org/w/index.php?title=Architectures/ARM/Raspberry_Pi/HATs#General_configuration ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: U-Boot testing request - 2023.10 series
Hi Dominik, > > The 2023.10 RC series are now landing in F-39 and rawhide. There's > > been the beginnings of a few enhancements. > > > > The first one that is noticeable is a bootmenu during the firmware > > init process where it will allow you to select the device/partition > > you wish to boot from, with the default selected and the usual time > > out. It should make things a little easier for things like > > reinstalling off a USB stick for devices that support that sort of > > install. > > > > I've done some testing across a bunch of devices, various RPi, the > > Pinebook pro and numerous SBCs so I think it should work just fine, at > > least be no different than the usual process but I'd like to hear any > > feedback. > > I copied the Pinebook Pro u-boot binaries from > uboot-images-armv8-2023.10-0.4.rc3.fc39.noarch.rpm > (https://koji.fedoraproject.org/koji/buildinfo?buildID=2277261) > from /usr/share/uboot/pinebook-pro-rk3399/ to a μSD card (previously > formatted using spi-flashing disk script). Then I did the steps from > https://nullr0ute.com/2021/05/fedora-on-the-pinebook-pro/ "Write the > firmware to flash" section. > > Unfortunately, after reset (or power-off/power-on cycle), I get this: > ... > U-Boot SPL 2023.10-rc3 (Aug 21 2023 - 00:00:00 +) > Trying to boot from SPI > Trying to boot from MMC1 > mmc_load_image_raw_sector: mmc block read error > Trying to boot from SPI > Trying to boot from MMC2 > Card did not respond to voltage select! : -110 > spl: mmc init failed with error: -95 > SPL: failed to boot from all boot devices > ### ERROR ### Please RESET the board ### > > I checked the spi-flashing-disk script, and all it does is create a vfat > formatted partition and copy the 4 binaries from the directory > corresponding to the board model. I think I did everything correctly, so > is the new u-boot broken on PBP? I've confirmed a similar problem, I was testing some of this on the PBP against RC2 as I was developing it but never tested the RC3. Any chance you can grab one of the RC2 builds from koji [1] and see if you have better luck? Also maybe 2023.07 from koji too. I'll try and get to the bottom of this in the next week or so. [1] https://koji.fedoraproject.org/koji/packageinfo?packageID=10432 ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Rebase IoT to Silverblue
Hi Alessio, > You know, Fedora Silverblue is available for aarch64, but it is not > provided as a raw image. > As far as I see around, in order to install Silverblue on a Raspberry > Pi, a lot of trickies are needed in order to boot the ISO from an USB > stick etc. > So. I tried to install Fedora IoT, then I added the Silverblue remotes > and rebased the system to it. > Well. It worked. Do you see any contraindications? Is the last word meant to be contradictions? If so, no I don't think so, that's one of the great things of ostree. Did you have any other queries or problems from your experiment or is this more a heads up and to start a discussion? I actually have on my to-do list to add a silverblue raw image but I've not got around to it as it doesn't come up as a request that often, but it also shouldn't be too hard so if there's lurkers here that are interested in this use case do all feel to reply to this thread. P ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: system-upgrade on RPi fails
On Mon, Aug 21, 2023 at 2:06 PM Alessio wrote: > > Hello. > I don't remember if it has always been this way. > I was trying to upgrade from Fedora 38 to 39 on a Raspberry. > sudo dnf system-upgrade download --releasever=39 > > The point is that on the subsequent boot, following > dnf system-upgrade reboot > the operation fails because the signature verification fails, due to > the fact that the date/time of the RPi is incorrect. You know, each > time the RPi is rebooted, it lose the date/time. > > So, has it always been this way and I don't remember that? Or in the > past, system-upgrade was performed after the clock was synchronized > with some source? We've had reports of it working in the past. I've upgraded systems using distro-sync (dnf --releasever=39 --setopt=install_weak_deps=False --setopt=deltarpm=false distro-sync) without issues from F-38 -> F-39). ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] U-Boot testing request - 2023.10 series
Hi Folks, The 2023.10 RC series are now landing in F-39 and rawhide. There's been the beginnings of a few enhancements. The first one that is noticeable is a bootmenu during the firmware init process where it will allow you to select the device/partition you wish to boot from, with the default selected and the usual time out. It should make things a little easier for things like reinstalling off a USB stick for devices that support that sort of install. I've done some testing across a bunch of devices, various RPi, the Pinebook pro and numerous SBCs so I think it should work just fine, at least be no different than the usual process but I'd like to hear any feedback. Regards, Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Khadas vim 4 Support?
On Fri, Aug 18, 2023 at 4:32 PM Peter Boy wrote: > > > > Am 17.08.2023 um 12:47 schrieb Peter Robinson : > > On Mon, Aug 14, 2023 at 8:47 AM Peter Boy wrote: > > > > We are in the process to gather information about probably suitable SBC for > Fedora Server > > Khadas vim3 is supported, the vim4 uses the same processor family, it it by > chance supported by vim3 drivers? > > > I don't see any DT upstream for it (arch/arm64/boot/dts/amlogic/*vim*) > nor do a I see reference to the A311D2 where the origins A311D2 > (meson-g12b-a311d) is there so I'm not sure. > > Given the device has SPI memory if the firmware provides an > appropriate DT it may just work but I've not seen any reports either > way. > > > > Thanks for the info. Looking at Vim 4’s price tag it is currently a bit too > risky for me. > > I checked th rk3588 (Radxa rock Pi 5 a, FriendlyElec Nanopc-T6) as an > alternative. They seem to be supported (at least Rock Pi 5) > (https://github.com/u-boot/u-boot/blob/master/doc/board/rockchip/rockchip.rst) > but other posts say it’s currently missing some important features. Would > this probably be something for the „near future“ in Fedora (i.e. f40 or so) > or is that not at all foreseeable at present? The rk3588 is still a bit early, I had a quick check the other day and it was basically mmc/network upstream, there's patches out for things like usb/pcie and other pieces but that won't be in place for F-39 at least, which will be shipping with the 6.5.x kernel. What's your budget so I can suggest something in the right range. Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Khadas vim 4 Support?
On Mon, Aug 14, 2023 at 8:47 AM Peter Boy wrote: > > > We are in the process to gather information about probably suitable SBC for > Fedora Server > > Khadas vim3 is supported, the vim4 uses the same processor family, it it by > chance supported by vim3 drivers? I don't see any DT upstream for it (arch/arm64/boot/dts/amlogic/*vim*) nor do a I see reference to the A311D2 where the origins A311D2 (meson-g12b-a311d) is there so I'm not sure. Given the device has SPI memory if the firmware provides an appropriate DT it may just work but I've not seen any reports either way. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Add gpiomem device in fedora 37 aarch64
Hi, > Hi I am trying to add a device which is '/dev/gpiomem' in Fedora IOT 37 > aarch64. But I can only see '/dev/gpiochip0' and '/dev/gpiochip1' how can I > add gpiomem device because the software I am installing is using this device > in their code. The /dev/gpiomem interface is a Raspberry Pi downstream driver (drivers/char/broadcom/bcm2835-gpiomem.c) that isn't upstream so it's not something we will support in Fedora. The only interface for interfacing with GPIOs in Fedora is the upstream non deprecated character interface (/dev/gpiochipX) and the assoicated libgpiod library and associated language bindings. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Fedora on Rock 5B
Hi Andreas, > > It's in my backlog of devices to play with for F-39. > > > > It looks like it's not finding the storage, you don't mention what > > sort of storage you're trying to run Fedora from, is it the SD card or > > do you have the firmware on SD and Fedora on something else? > > > > Peter > > Hello Peter, > UEFI is on SD-Card, Fedora iso is on USB-Stick, another empty USB-Stick > and NVME disc are available for storage. So a quick look on upstream lists it doesn't look like USB [1] or either of the PCI controllers [2][3], there's two different ones, have yet made it upstream as yet. so ATM without a custom kernel I wouldn't expect it to work for either USB or NVME storage. The patch set for the USB support isn't upstream yet and it'll only support the upper USB3 port until they land another driver. On the plus side it looks like both the pcie patch sets are headed towards the 6.6 merge window. Looking at upstream DTs for the Rock5B it looks like it's just the mSD/eMMC storage that's enabled as of 6.5-rc4, it doesn't look like even the ethernet works. I think out of the box we probably won't be usable until F-40 for this device. I have seen a lot posted upstream, it seems a lot of that hasn't actually landed yet though. Peter [1] https://www.spinics.net/lists/linux-usb/msg244163.html [2] https://www.spinics.net/lists/linux-pci/msg141988.html [3] https://www.spinics.net/lists/linux-pci/msg141465.html > > On Sun, 30 Jul 2023, 13:18 Andreas Reschke, > > wrote: > > > >> Hi there, > >> I've tried to install Fedora on my Rock 5 without success. > >> > >> Booting with > >> > > https://github.com/edk2-porting/edk2-rk3588/releases/download/v0.7.1/rock-5b_UEFI_Release_v0.7.1.img > >> > >> on SD-Card and source from > >> > > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/iso/Fedora-Everything-netinst-aarch64-Rawhide-20230730.n.0.iso. > >> > >> Board boots up fine but later starting in loop with > >> 350.456154] dracut-initqueue[1065]: Warning: # Anaconda > >> installer errors end ### > >> [ 352.156835] dracut-initqueue[1065]: Warning: dracut-initqueue: > >> timeout, still waiting for following initqueue hooks: > >> [ 352.161387] dracut-initqueue[1065]: Warning: > >> /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2froot.sh: > >> "[ -e > >> "/dev/root" ]" > >> [ 352.164564] dracut-initqueue[1065]: Warning: > >> /lib/dracut/hooks/initqueue/finished/wait_for_disks.sh: "[ > >> "$main_loop" > >> -ge "10" ]" > >> [ 352.167716] dracut-initqueue[1065]: Warning: > >> /lib/dracut/hooks/initqueue/finished/wait_for_settle.sh: "[ -f > >> /tmp/settle.done ]" > >> [ 352.171999] dracut-initqueue[1065]: Warning: dracut-initqueue: > >> starting timeout scripts > >> [ 352.172610] dracut-initqueue[1065]: Warning: # > >> Anaconda > >> installer errors begin # > >> [ 352.172852] dracut-initqueue[1065]: Warning: # > >> # > >> [ 352.173097] dracut-initqueue[1065]: Warning: It seems that the > >> boot > >> has failed. Possible causes include > >> [ 352.173296] dracut-initqueue[1065]: Warning: missing inst.stage2 > >> or > >> inst.repo boot parameters on the > >> [ 352.173537] dracut-initqueue[1065]: Warning: kernel cmdline. > >> Please > >> verify that you have specified > >> [ 352.173731] dracut-initqueue[1065]: Warning: inst.stage2 or > >> inst.repo. > >> [ 352.173918] dracut-initqueue[1065]: Warning: Please also note > >> that > >> the 'inst.' prefix is now mandatory. > >> [ 352.174156] dracut-initqueue[1065]: Warning: # > >> # > >> [ 352.174354] dracut-initqueue[1065]: Warning: Installer > >> errors encountered during boot: > >> [ 352.174543] dracut-initqueue[1065]: Warning: # > >> # > >> [ 352.174775] dracut-initqueue[1065]: Warning: Reason unknown > >> [ 352.174970] dracut-initqueue[1065]: Warning: # > >> # > >> > >> Full log file: see rock.txt > >> > >> Has anybody more succcess ? > >> > >> Greetings > >> Andreas___ > >> arm mailing list -- arm@lists.fedoraproject.org > >> To unsubscribe send an email to arm-le...@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 > >> Do not reply to spam, report it: > >> https://pagure.io/fedora-infrastructure/new_issue ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it:
[fedora-arm] Re: Fedora on Rock 5B
Hi, It's in my backlog of devices to play with for F-39. It looks like it's not finding the storage, you don't mention what sort of storage you're trying to run Fedora from, is it the SD card or do you have the firmware on SD and Fedora on something else? Peter On Sun, 30 Jul 2023, 13:18 Andreas Reschke, wrote: > Hi there, > I've tried to install Fedora on my Rock 5 without success. > > Booting with > > https://github.com/edk2-porting/edk2-rk3588/releases/download/v0.7.1/rock-5b_UEFI_Release_v0.7.1.img > on SD-Card and source from > > https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/aarch64/iso/Fedora-Everything-netinst-aarch64-Rawhide-20230730.n.0.iso > . > > Board boots up fine but later starting in loop with > 350.456154] dracut-initqueue[1065]: Warning: # Anaconda > installer errors end ### > [ 352.156835] dracut-initqueue[1065]: Warning: dracut-initqueue: > timeout, still waiting for following initqueue hooks: > [ 352.161387] dracut-initqueue[1065]: Warning: > /lib/dracut/hooks/initqueue/finished/devexists-\x2fdev\x2froot.sh: "[ -e > "/dev/root" ]" > [ 352.164564] dracut-initqueue[1065]: Warning: > /lib/dracut/hooks/initqueue/finished/wait_for_disks.sh: "[ "$main_loop" > -ge "10" ]" > [ 352.167716] dracut-initqueue[1065]: Warning: > /lib/dracut/hooks/initqueue/finished/wait_for_settle.sh: "[ -f > /tmp/settle.done ]" > [ 352.171999] dracut-initqueue[1065]: Warning: dracut-initqueue: > starting timeout scripts > [ 352.172610] dracut-initqueue[1065]: Warning: # Anaconda > installer errors begin # > [ 352.172852] dracut-initqueue[1065]: Warning: # > # > [ 352.173097] dracut-initqueue[1065]: Warning: It seems that the boot > has failed. Possible causes include > [ 352.173296] dracut-initqueue[1065]: Warning: missing inst.stage2 or > inst.repo boot parameters on the > [ 352.173537] dracut-initqueue[1065]: Warning: kernel cmdline. Please > verify that you have specified > [ 352.173731] dracut-initqueue[1065]: Warning: inst.stage2 or inst.repo. > [ 352.173918] dracut-initqueue[1065]: Warning: Please also note that > the 'inst.' prefix is now mandatory. > [ 352.174156] dracut-initqueue[1065]: Warning: # > # > [ 352.174354] dracut-initqueue[1065]: Warning: Installer > errors encountered during boot: > [ 352.174543] dracut-initqueue[1065]: Warning: # > # > [ 352.174775] dracut-initqueue[1065]: Warning: Reason unknown > [ 352.174970] dracut-initqueue[1065]: Warning: # > # > > Full log file: see rock.txt > > Has anybody more succcess ? > > Greetings > Andreas___ > arm mailing list -- arm@lists.fedoraproject.org > To unsubscribe send an email to arm-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Fedora for Tegra / jetson nano : how good is it ?
On Sat, May 13, 2023 at 9:32 PM Nicolas Chauvet wrote: > > Le ven. 12 mai 2023 à 14:31, Mario Marietto a écrit : > > > > The Nvidia Jetson Nano. was announced as a development system in mid-March > > 2019. Only 4 years have passed. Not 8. I'm an end user,that's how I count. > > I may agree that,generally . > > I've even requested that nvidia to better support upstream on tegra210 > (nano) on this thread > https://forums.developer.nvidia.com/t/efi-support-for-jetson-tx1-and-running-upstream-kernel/187945 > > Maybe if more interested nano end-users would come with this concern > on their forum, it would make them change this behavior. > I'm more into thinking that nvidia uses this lack of upstream support > to force EOL on these devices... So that's a kind of vendor locking. > But upstream concern on jetson forum isn't that common for some reason... They have improved a LOT with their upstream work but they view the SoC that the nano is based upon as now basically EOL so it's more if the work also aligns with the newer SoCs they're focused on. The newer Jetpack releases use much newer kernels with a lot more things that are upstream but the 5.x and later releases only support Xavier/Orin. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Fedora for Tegra / jetson nano : how good is it ?
Mario, Firstly probably best to start a new topic thread On Sat, 13 May 2023, 13:18 Mario Marietto, wrote: > I still have the old "Samsung / Google Nexus 10" tablet. I don't like > Android. Any help to install Fedora instead of Android on this device is > appreciated. Thanks. > It's an exynos 5 series chip, they were never particularly well supported upstream, it's also 32 bit which Fedora ended support of with F-36. I suspect start with a lineage OS release and you can probably use some of their process to get Fedora onto it but you'll need your own kernel too. Peter On Fri, May 12, 2023 at 2:48 PM Peter Robinson wrote: > >> On Fri, May 12, 2023 at 1:32 PM Mario Marietto >> wrote: >> > >> > Errata corrige : >> > >> > "This kind of treatment of the end user who spent money" >> >> You have spent money with NVIDIA not with Fedora, go and engage with >> them about their support not with Fedora, Fedora has no direct >> relationship with NVIDIA. >> >> > On Fri, May 12, 2023 at 2:29 PM Mario Marietto >> wrote: >> >> >> >> The Nvidia Jetson Nano. was announced as a development system in >> mid-March 2019. Only 4 years have passed. Not 8. I'm an end user,that's how >> I count. I may agree that,generally speaking, 4 years are enough,but this >> is not always true. The Jetson nano is today a good product in relation to >> cost / benefit ratio for a lot of users that don't need to buy the new >> Jetson Orin. What I care about (and not only for me) is to enable the >> graphic stack with some decent new linux distro. Nvidia supports only >> Ubuntu 18,that's the end of life. I've been criticized in the ubuntu forums >> for asking for help solving some technical problems with ubuntu 18. The >> developers tried hard to convince me that they weren't called to help me >> with a distro that went EOL. I insisted that I had to, because nVidia only >> supports 18.04. So they told me that they have no relationship with nVidia >> and they don't give a damn. This kind of treatment of the end user who has >> made money and loves an operating system is unacceptable. I have upgraded >> Ubuntu 18.04 to 22.04 on the Jetson nano. Everything works ok,but not the >> graphic stack because I'm not able to install CUDA 11. The nVidia >> developers say that only Orin supports it. So,should I spend more money to >> buy Orin ? I don't think so. Because I think that CUDA 11 is not supported >> on the Nano not 'cause insurmountable technical problems,but because of the >> business plans of nvidia. Business plans that aren't compatible with my >> finances. With the finances of a lot of end / hobbyist users. >> >> >> >> On Fri, May 12, 2023 at 2:13 PM Peter Robinson >> wrote: >> >>> >> >>> Hi Mario, >> >>> >> >>> > I dont hide my interest in the installation of fedora on the Jetson >> nano. I would like to understand what works and what not. Can I have a more >> modern OS than Ubuntu 18.04 ? help me to understand. >> >>> >> >>> The upstream support for nano is OK outside of the graphics stack. >> >>> NVIDIA is now more focused on newer generations of the hardware, being >> >>> Xavier and Orin primarily, They have effectively end of lifed pretty >> >>> much anything prior to that, the TX1 SoC which the nano is based upon >> >>> was released in 2015 so 8 years support isn't too bad IMO compared to >> >>> a lot of other vendors. >> >>> >> >>> They are still upstreaming pieces of the tegra HW drivers for the t210 >> >>> series where it makes sense with their work on the newer HW as a lot >> >>> of the IP blocks are related. >> >>> >> >>> In terms of their userspace based on releases of Ubuntu that's pretty >> >>> out of scope from a Fedora perspective. You may be able to look at the >> >>> newer NVIDIA Jetpack 5.x releases which are designed to run on >> >>> Xavier/Orin as they're based on a 5.10 kernel and a newer L4T >> >>> userspace but I have no idea what version of Ubuntu that is, this is >> >>> the wrong forum for those questions, I'm not sure if they've actively >> >>> torn out < Xavier support there or just defocused it. >> >>> >> >>> Regards, >> >>> Peter >> >> >> >> >> >> >> >> -- >> >> Mario. >> > >> > >> > >> > -- >> > Mario. >> > > > -- > Mario. > ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Fedora for Tegra / jetson nano : how good is it ?
On Fri, May 12, 2023 at 1:32 PM Mario Marietto wrote: > > Errata corrige : > > "This kind of treatment of the end user who spent money" You have spent money with NVIDIA not with Fedora, go and engage with them about their support not with Fedora, Fedora has no direct relationship with NVIDIA. > On Fri, May 12, 2023 at 2:29 PM Mario Marietto wrote: >> >> The Nvidia Jetson Nano. was announced as a development system in mid-March >> 2019. Only 4 years have passed. Not 8. I'm an end user,that's how I count. I >> may agree that,generally speaking, 4 years are enough,but this is not always >> true. The Jetson nano is today a good product in relation to cost / benefit >> ratio for a lot of users that don't need to buy the new Jetson Orin. What I >> care about (and not only for me) is to enable the graphic stack with some >> decent new linux distro. Nvidia supports only Ubuntu 18,that's the end of >> life. I've been criticized in the ubuntu forums for asking for help solving >> some technical problems with ubuntu 18. The developers tried hard to >> convince me that they weren't called to help me with a distro that went EOL. >> I insisted that I had to, because nVidia only supports 18.04. So they told >> me that they have no relationship with nVidia and they don't give a damn. >> This kind of treatment of the end user who has made money and loves an >> operating system is unacceptable. I have upgraded Ubuntu 18.04 to 22.04 on >> the Jetson nano. Everything works ok,but not the graphic stack because I'm >> not able to install CUDA 11. The nVidia developers say that only Orin >> supports it. So,should I spend more money to buy Orin ? I don't think so. >> Because I think that CUDA 11 is not supported on the Nano not 'cause >> insurmountable technical problems,but because of the business plans of >> nvidia. Business plans that aren't compatible with my finances. With the >> finances of a lot of end / hobbyist users. >> >> On Fri, May 12, 2023 at 2:13 PM Peter Robinson wrote: >>> >>> Hi Mario, >>> >>> > I dont hide my interest in the installation of fedora on the Jetson nano. >>> > I would like to understand what works and what not. Can I have a more >>> > modern OS than Ubuntu 18.04 ? help me to understand. >>> >>> The upstream support for nano is OK outside of the graphics stack. >>> NVIDIA is now more focused on newer generations of the hardware, being >>> Xavier and Orin primarily, They have effectively end of lifed pretty >>> much anything prior to that, the TX1 SoC which the nano is based upon >>> was released in 2015 so 8 years support isn't too bad IMO compared to >>> a lot of other vendors. >>> >>> They are still upstreaming pieces of the tegra HW drivers for the t210 >>> series where it makes sense with their work on the newer HW as a lot >>> of the IP blocks are related. >>> >>> In terms of their userspace based on releases of Ubuntu that's pretty >>> out of scope from a Fedora perspective. You may be able to look at the >>> newer NVIDIA Jetpack 5.x releases which are designed to run on >>> Xavier/Orin as they're based on a 5.10 kernel and a newer L4T >>> userspace but I have no idea what version of Ubuntu that is, this is >>> the wrong forum for those questions, I'm not sure if they've actively >>> torn out < Xavier support there or just defocused it. >>> >>> Regards, >>> Peter >> >> >> >> -- >> Mario. > > > > -- > Mario. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Fedora for Tegra / jetson nano : how good is it ?
Hi Mario, > I dont hide my interest in the installation of fedora on the Jetson nano. I > would like to understand what works and what not. Can I have a more modern OS > than Ubuntu 18.04 ? help me to understand. The upstream support for nano is OK outside of the graphics stack. NVIDIA is now more focused on newer generations of the hardware, being Xavier and Orin primarily, They have effectively end of lifed pretty much anything prior to that, the TX1 SoC which the nano is based upon was released in 2015 so 8 years support isn't too bad IMO compared to a lot of other vendors. They are still upstreaming pieces of the tegra HW drivers for the t210 series where it makes sense with their work on the newer HW as a lot of the IP blocks are related. In terms of their userspace based on releases of Ubuntu that's pretty out of scope from a Fedora perspective. You may be able to look at the newer NVIDIA Jetpack 5.x releases which are designed to run on Xavier/Orin as they're based on a 5.10 kernel and a newer L4T userspace but I have no idea what version of Ubuntu that is, this is the wrong forum for those questions, I'm not sure if they've actively torn out < Xavier support there or just defocused it. Regards, Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Questions about supported hdmi display
Hi, > as shown in > https://discussion.fedoraproject.org/t/research-and-updating-of-docs-for-hdmi-display-supported-supported-hdmi-driver-by-rasp-pi-4-in-fedora-workstation/80059 > it would be great to update the docs which tell users which drivers or > display is supported. > or how to get the driver required to support some device. > > To find which drivers are not supported in fedora wrokstation. > - ARM with Fedora Workstation connected to HDMI projector works.(which means > the OS works and some HDMI driver/display is supported) > - The custom display works with windows silverblue(which means its > something probably only fedora ARM havent supported or at least not included > in stock OS) > > I see other suggest>supply EDID data via the kernel command line.however my > device is on 1st boot and of course there is that process that needs display > more than anything. > OS personalization setup at 1st successful boot. These days we support most of the actual 3D accelerated displays on arm hardware, the one that isn't there yet, but is coming, is PowerVR, and the company is working on an open source upstream driver. In the case of displays it's near on impossible to document the combinations of displays supported. In a lost of cases I've found with Raspberry Pi devices if they swap out a HDMI cable, or in some cases even just replug them on both ends they will sometimes just work fine. The vast majority of native HDMI displays "just work" these days. The ones that have tendencies to cause problems are non native HDMI where there's some form of converter in the middle and some projectors, but in the later category often swapping to a different cable has again helped. So even if people had the actual time to test a wide variety of displays against a wide variety of devices the information would likely be out of date the following week due to a kernel update. I feel it's a near on impossible task but I am welcome to suggestions on how to do some form of light weight documentation to help users debug the situation. Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: F38 on RPi4-8G
On Tue, Apr 25, 2023 at 10:40 PM Randy DuCharme wrote: > > Am I the only one having difficulties with this? It's worse than half > as fast as f37 was, NTP/Chrony refuses to work. I could go on. > Afraid I'm going to have to ditch this. Kernel's been building for 7 > hours now. Clocking, over-clocking, governors, schedulers make no > difference. Btrace, strace points to nothing. CPU load through the roof > though yet I don't see anything especially noteworthy. > > Thoughts? I've not seen regressions like that, but I've also not had the time to look at performance, but then time sync seems to work fine. Maybe check kernel major versions, what did you have prior to the upgrade from F-37, you don't give any real details, like when you upgraded, whether you're running wired or wireless network. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Pine64 RockPro doesn't boot with F38 Beta 1 nor branched 20230326 nightly composed
On Mon, Apr 3, 2023 at 1:01 PM Peter Boy wrote: > > > > > Am 03.04.2023 um 10:10 schrieb Peter Boy : > > > >> That is fixed with the rc5 build that's in updates-testing, you need > >> to have uboot-images-armv8-2023.04-0.4.rc5.fc38, > > Do yo have a direct link to the rpm? Sorry, for some reason all my searches > and links end up with the uboot-tools rpm It's a subpackage of the uboot-tools package so if you go there and look down the list you will find it: uboot-tools-2023.04-0.4.rc5.fc38 -> https://koji.fedoraproject.org/koji/buildinfo?buildID=2180089 It's in the noarch section > > > > > -- > Peter Boy > https://fedoraproject.org/wiki/User:Pboy > p...@fedoraproject.org > > Timezone: CET (UTC+1) / CEST (UTC+2) > > > Fedora Server Edition Working Group member > Fedora docs team contributor > Java developer and enthusiast > > > ___ > arm mailing list -- arm@lists.fedoraproject.org > To unsubscribe send an email to arm-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Pine64 RockPro doesn't boot with F38 Beta 1 nor branched 20230326 nightly composed
On Mon, Apr 3, 2023 at 9:10 AM Peter Boy wrote: > > > > > Am 03.04.2023 um 09:53 schrieb Peter Robinson : > > > >>> Nothing. In most cases these days the utilities in uboot-tools are > >>> only needed for advanced use. > >> > >> > >> OK, but with the currently distributed version (branched 2023-03-31 / > >> u-boot 2023.04-rc4) I still get the message > >>> Hit any key to stop autoboot: 0 > >>> ## Error: "distro_bootcmd" not definded > >> > >> if I remember correctly and didn’t mess my notes and testing procedures. > >> > >> Will that get fixed with / before F38 release? > > > > That is fixed with the rc5 build that's in updates-testing, you need > > to have uboot-images-armv8-2023.04-0.4.rc5.fc38, you're testing with > > rc4. > > Well, I’m testing Fedora 38 release (beta / branched). Do you plan to get rc5 > into the (initial) release media or will we start with a not-working arm > installer in F38? Or what needs to be done to get in into the release media? > Do we need testing? karma? …? I asked for karma and testing when I replied linking to the update in this thread. I've already stated that I intend it to go into stable, which was why I asked for testing. In fact we will ship with the GA release which is due out today or tomorrow, we will request a FE to ensure this lands (which we've done basically every release due to the upstream GA generally landing on freeze day). ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Pine64 RockPro doesn't boot with F38 Beta 1 nor branched 20230326 nightly composed
> > Nothing. In most cases these days the utilities in uboot-tools are > > only needed for advanced use. > > > OK, but with the currently distributed version (branched 2023-03-31 / u-boot > 2023.04-rc4) I still get the message > > Hit any key to stop autoboot: 0 > > ## Error: "distro_bootcmd" not definded > > if I remember correctly and didn’t mess my notes and testing procedures. > > Will that get fixed with / before F38 release? That is fixed with the rc5 build that's in updates-testing, you need to have uboot-images-armv8-2023.04-0.4.rc5.fc38, you're testing with rc4. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Pine64 RockPro doesn't boot with F38 Beta 1 nor branched 20230326 nightly composed
On Mon, Apr 3, 2023 at 8:10 AM Peter Boy wrote: > > > > > Am 03.04.2023 um 00:35 schrieb Peter Robinson : > > > > On Tue, Mar 28, 2023 at 1:08 PM Peter Boy wrote: > >> > >> Fedora 37 aarch64 Server edition works just fine. > >> > >> > >> With F38 beta 1 & branched 20230326 it starts: > >> > >> ... > >> > >> Sorry to be so late with testing. Would be nice to get it work, > >> nevertheless. > > > > The F-38 build should now be fixed: > > > > https://bodhi.fedoraproject.org/updates/FEDORA-2023-8ba62c0e8c > > > > If people could test and add karma that would be great. > > > I hope, my question is not too uninitiated. With your link I get > uboot-tools-2023.04-0.4.rc5.fc38.x86_64.rpm as far as I can see. But I didn’t > (and didn’t need to) install uboot-tools on my x86-64 box to create the > Fedora mSD using arm-image-installer so far. > > What I’m missing here? Nothing. In most cases these days the utilities in uboot-tools are only needed for advanced use. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Pine64 RockPro doesn't boot with F38 Beta 1 nor branched 20230326 nightly composed
On Tue, Mar 28, 2023 at 1:08 PM Peter Boy wrote: > > Fedora 37 aarch64 Server edition works just fine. > > > With F38 beta 1 & branched 20230326 it starts: > > U-Boot 2023.04-rc2 (Feb 17 2023) > SoC: Rockchip rk 3399 > Reset cause: POR > Model: Pine64 RockPro64 v2.1 > ... > Core: 394 devices, 33 uclasses, devicetree: separate > MMC: mmc@fe31: 3, mmc@fe32: 1, mmc@fe33: 0 > Loading environment from SPIFlash... SF: Detected total 16 MiB > *** Warning - bad CRC, using default evironment > > In: serial > ... > > scanning usb for storage devices... 0 Storage Devices found > Hit any key to stop autoboot: 0 > ## Error: "distro_bootcmd" not definded > => > > > With F37 the first part is the same: > but at the end > >scanning for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 2 - 1 - 0 > switch to partitions #0, OK > mmc1 us current device > Scanning mmc 1:1 … > … > > and continues to boot. > > > Sorry to be so late with testing. Would be nice to get it work, nevertheless. The F-38 build should now be fixed: https://bodhi.fedoraproject.org/updates/FEDORA-2023-8ba62c0e8c If people could test and add karma that would be great. P ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Pine64 RockPro doesn't boot with F38 Beta 1 nor branched 20230326 nightly composed
On Fri, Mar 31, 2023 at 4:44 PM Peter Boy wrote: > > > > > Am 29.03.2023 um 19:42 schrieb Dennis Gilmore : > > > > > > > > On Wed, Mar 29, 2023 at 12:38 PM Peter Robinson > > wrote: > > > > On Wed, Mar 29, 2023 at 6:18 PM Peter Boy wrote: > > > > > > Just another question: How do I get the Fedora spi image onto the device? > > > As I found on the internet, the description at > > > https://nullr0ute.com/2021/05/fedora-on-the-pinebook-pro/ for the > > > Pinebook doesn’t work for the RockPro64. And indeed, it still does not. > > > In another thread was noted that you are about to update the > > > documentation to describe the process for RockPro64. Unfortunately, I > > > couldn’t find it in my internet researches. > > > > The process is the same as the PBP you just have to adjust the names > > so for example "sudo spi-flashing-disk --target=rockpro64-rk3399 > > --media=/dev/XXX". I have has reports from a number of people it works > > just fine. > > > > I can confirm that this works just fine. I have 2 RockPro64's running > > Fedora 37 here and using u-boot on SPI from there. > > It did some experimentation and internet search that took its time. > > For me, it doesn’t work, unfortunately. > > I get: > > > U-Boot (2022.10 (Oct 10 2022...) > > > > Soc: Rockchiop rk3399 > > Reset cause: POR > > Model: Pine64 RockPro64 v2.1 > > … > > MMC: mmc@fe31: 3, mmc@fe32: 1, mmc@fe33: 0 > > Loading Environment from SPIFlash... SF: Detected gd25q128 … > > *** Warning - bad CRC, using default environment > > > > In: serial > > Out: vidconsole > > starting USB... > > > > scanning usb for storage devices...0 found > > Hit any key to stop autoboot: > > switch to partitions #0, OK > > mmc1 is current device > > Scanning mmc 1:1... > > Card did not respond to voltage select! : -110 > > rockship_pcie pcie@f800: failed to find ep-gpios property > > scanning bus for devices > > > > Device 0: unknown device > > Device 0: unknown device > > rockship_pcie pcie@f800: failed to find ep-gpios property > > Speed: 1000, full duplex > > BOOTP broadcast 1 > > DHCP client bound to address 192.168.158.150 (6 ms) > > *** Warning: no boot file name: using 'COA89E98.img‘ > > … > > > Any idea what I might have missed? That is working fine, it's not finding the storage/OS, what are you trying to boot off, what image are you trying to boot? > I noticed that a booted F37 shows no SPI storage, only mSD mmcblk0. When I > boot the Armbian included in the board delivery, lsblk additionally shows a > mtd 0, size 16m. > > I found an SPI flash at > https://github.com/sigmaris/u-boot/releases/download/v2021.04-rockpro64-ci/flash_spi.img.gz > > The SPI storage was written with it and the board does boot from it. However, > Fedora cannot be booted with it, a lack of an EFI partition is complained > about and the file system is not recognized. > > Any help appreciated. > > > @Dennis Gilmore > > It reminds me I should document how I built a Fedora based NAS with 10 > > drives using a RockPro64. It is not the most performant but suits me > > I would appreciate that, too. And just in case that you used Fedora Server, I > would like to publish it as part of the Fedora Server documentation (). I can > help with the technical part. I'm making an effort to give more consideration > to SBCs right now. > > > Peter > > > > > > > > > -- > Peter Boy > https://fedoraproject.org/wiki/User:Pboy > p...@fedoraproject.org > > Timezone: CET (UTC+1) / CEST (UTC+2) > > > Fedora Server Edition Working Group member > Fedora docs team contributor > Java developer and enthusiast > > > ___ > arm mailing list -- arm@lists.fedoraproject.org > To unsubscribe send an email to arm-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Le Potato?
On Wed, Mar 29, 2023 at 7:03 PM Richard Shaw wrote: > > Google has failed me. Can I run Fedora on a Le Potato? If so, what target do > I use? > > Anything I need to do before writing the image? > > I plan to use eMMC if I can get it cheap enough due to the failure rate of SD > cards. So it doesn't look like the DT is upstream, but LibreComputer used to do a very good firmware that likely provides an appropriate firmware. I'm not sure of the recent state of their firmwares. We don't currently build firmware for amlogic devices because "It's complicated". But if the LibreComputer have a quality firmware for the Le Potato it likely should just work as we have the vast majority of the kernel side enabled, if there's something missing from the kernel that will be easy enough to fix. Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Pine64 RockPro doesn't boot with F38 Beta 1 nor branched 20230326 nightly composed
On Thu, Mar 30, 2023 at 9:53 PM Dominik 'Rathann' Mierzejewski wrote: > > On Wednesday, 29 March 2023 at 19:42, Dennis Gilmore wrote: > [...] > > I can confirm that this works just fine. I have 2 RockPro64's running > > Fedora 37 here and using u-boot on SPI from there. It reminds me I should > > document how I built a Fedora based NAS with 10 drives using a RockPro64. > > It is not the most performant but suits me > > Yes, please do that. I'm keeping an eye out for a replacement of my > current Atom-based NAS and this could be it. Please include some > benchmarks and power consumption info. Depending on how much of a rush you're in I would look for something based on the rk3568 [1], as it has 3x sata, 2x NIC and 2x pcie options, or the rk3588 series. We don't support them fully as yet, especially the later, but they'll be more performant and will quickly start to replace the venerable rk3399. F-38 should support the rk356x series pretty well outside of the firmware support which still needs improvement. [1] https://www.cnx-software.com/2020/12/16/rockchip-rk3566-and-rk3568-datasheets-and-features-comparison/ ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Pine64 RockPro doesn't boot with F38 Beta 1 nor branched 20230326 nightly composed
On Thu, Mar 30, 2023 at 10:04 PM Gregory Carter wrote: > > Have you tried any HAT's with those systems? I am looking to move away from > PI as it is giving me supply chain issues and would like to settle on > something a bit more plentiful and not made in China. Pine64, and most things rockchip, are made in China, and Rockchip is a Chinese silicon vendor. > On Thu, Mar 30, 2023 at 1:53 PM Dominik 'Rathann' Mierzejewski > wrote: >> >> On Wednesday, 29 March 2023 at 19:42, Dennis Gilmore wrote: >> [...] >> > I can confirm that this works just fine. I have 2 RockPro64's running >> > Fedora 37 here and using u-boot on SPI from there. It reminds me I should >> > document how I built a Fedora based NAS with 10 drives using a RockPro64. >> > It is not the most performant but suits me >> >> Yes, please do that. I'm keeping an eye out for a replacement of my >> current Atom-based NAS and this could be it. Please include some >> benchmarks and power consumption info. >> >> Regards, >> Dominik >> -- >> Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org >> There should be a science of discontent. People need hard times and >> oppression to develop psychic muscles. >> -- from "Collected Sayings of Muad'Dib" by the Princess Irulan >> ___ >> arm mailing list -- arm@lists.fedoraproject.org >> To unsubscribe send an email to arm-le...@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 >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue > > ___ > arm mailing list -- arm@lists.fedoraproject.org > To unsubscribe send an email to arm-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Pine64 RockPro doesn't boot with F38 Beta 1 nor branched 20230326 nightly composed
" On Wed, Mar 29, 2023 at 6:18 PM Peter Boy wrote: > > > > > Am 28.03.2023 um 14:09 schrieb Peter Robinson : > > > > Yes, it's a known problem, it will be fixed with the U-Boot rc5 build > > which should be done later today. > > > thanks for the info. I just checked, today’s built 20230329 is rc4. looking > forward. > > > Just another question: How do I get the Fedora spi image onto the device? As > I found on the internet, the description at > https://nullr0ute.com/2021/05/fedora-on-the-pinebook-pro/ for the Pinebook > doesn’t work for the RockPro64. And indeed, it still does not. In another > thread was noted that you are about to update the documentation to describe > the process for RockPro64. Unfortunately, I couldn’t find it in my internet > researches. The process is the same as the PBP you just have to adjust the names so for example "sudo spi-flashing-disk --target=rockpro64-rk3399 --media=/dev/XXX". I have has reports from a number of people it works just fine. Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Pine64 RockPro doesn't boot with F38 Beta 1 nor branched 20230326 nightly composed
Yes, it's a known problem, it will be fixed with the U-Boot rc5 build which should be done later today. Peter On Tue, Mar 28, 2023 at 1:08 PM Peter Boy wrote: > > Fedora 37 aarch64 Server edition works just fine. > > > With F38 beta 1 & branched 20230326 it starts: > > U-Boot 2023.04-rc2 (Feb 17 2023) > SoC: Rockchip rk 3399 > Reset cause: POR > Model: Pine64 RockPro64 v2.1 > ... > Core: 394 devices, 33 uclasses, devicetree: separate > MMC: mmc@fe31: 3, mmc@fe32: 1, mmc@fe33: 0 > Loading environment from SPIFlash... SF: Detected total 16 MiB > *** Warning - bad CRC, using default evironment > > In: serial > ... > > scanning usb for storage devices... 0 Storage Devices found > Hit any key to stop autoboot: 0 > ## Error: "distro_bootcmd" not definded > => > > > With F37 the first part is the same: > but at the end > >scanning for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot: 2 - 1 - 0 > switch to partitions #0, OK > mmc1 us current device > Scanning mmc 1:1 … > … > > and continues to boot. > > > Sorry to be so late with testing. Would be nice to get it work, nevertheless. > > > > > > > > > -- > Peter Boy > https://fedoraproject.org/wiki/User:Pboy > p...@fedoraproject.org > > Timezone: CET (UTC+1) / CEST (UTC+2) > > > Fedora Server Edition Working Group member > Fedora docs team contributor > Java developer and enthusiast > > > ___ > arm mailing list -- arm@lists.fedoraproject.org > To unsubscribe send an email to arm-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Fedora-Minimal-36-1.5 on raspberry pi 2B
On Fri, Jan 20, 2023 at 10:42 PM Irene Diez wrote: > > Hello there, > > I'm trying to install Fedora-Minimal-36-1.5.armhfp.raw on my raspberry > pi 2B. Installation was a success but the device runs out of memory > when trying to install anything via dnf and I get kicked out of the > shell. We ship microdnf with the minimal image so try "microdnf update" or "microdnf install blah" and it should be fine > I've followed the installation instructions in > https://fedoraproject.org/wiki/Architectures/ARM/Raspberry_Pi#Manual, > which specify that this model is supported since Fedora 29; so, is > there anything that I'm missing for Fedora to work? That is the process for creating the initial image on another machine so it appears unrelated to the above problem. Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Watchdog and raspberrypi
Hi Pierre-Francois, > I am running 6 RPI4s with fedora 37. K3S is powering this cluster and it > is working well :) > > But from time to time, 1 RPI is randomly hanging. > > I am thinking about implementing a watchdog : > > - software based, using embeded linux kernel If the RPi itself is locking up I'm not sure how a SW based approach would work, how would it trigger if the kernel isn't working? Also not sure what you mean here but "embeded linux kernel", care to explain some more? > - hardware based such as https://www.omzlo.com/articles/the-piwatcher The RPI4 already has a HW watchdog onboard, the driver is bcm2835_wdt, maybe you could start by investigating the use of the Linux watchfog stack with that. systemd has support for HW WDTs and we enable all the pieces in Fedora already, I suspect that will be a good start for you. > > Do you have any experience on one of theses two solutions ? Do you have > alternatives ? > > > By the way your job is fantastic and it is a great pleasure to be able > to run F37 on aarch64 so easily ! > > > Thanks a lot > > ___ > arm mailing list -- arm@lists.fedoraproject.org > To unsubscribe send an email to arm-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Rawhide nodebug kernel for armhfp
On Tue, Jan 3, 2023 at 1:28 PM Nicolas Chauvet wrote: > > Hi, > > With the removal of the armhfp koji target in rawhide, the > kernel-rawhide-nodebug kernel repository is missing an armhfp build. I'm not sure where the nodebug kernels are published but Justin does f36 build of up coming rebases explicitly for armhfp testing. Peter > As building an armhfp kernel on copr natively is inefficient (it would > use an x86_64 builder with qemu-system-arm emulation), I've setup a > copr repository that will cross-compile an armhfp kernel on a x86_64 > host. > > Currently available is a (normal) kernel package (and kernel-lpae) > tracking once a week the fedora kernel distgit repository unmodified > (aka 6.2-rc1). > (tested on trimslice) > > I also plan to switch a kernel-longterm package from 5.15 to 6.1 in > the next few weeks. > > Please see https://copr.fedorainfracloud.org/coprs/kwizart/cross-armhfp/ > > Hopefully the fc36 EOL kernel will be in a good shape to shutdown the > armhfp architecture in Fedora. > Hope this helps. > > -- > - > > Nicolas (kwizart) > ___ > arm mailing list -- arm@lists.fedoraproject.org > To unsubscribe send an email to arm-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Raspberry Pi 4b + F-37
> I'm not kidding. I was concerned at first about the Fedora + RPi 4b > union since it was a rocky start - for me anyway. On F-36 I got stuck > on a 5.17 kernel and could NOT move forward. Didn't have the time cycles Could you give more details on why you got got stuck on 5.17? > to dig in myself and was contemplating switching to Arch or Manjaro. I > decided to give the new F-37 release a spin before doing that and was > surprised at how well it runs. I realize that the ARM/aarch64 platform > is secondary to x86_64 so I do understand the lag. Further, the RPi has aarch64 is not secondary to x86, they're both primary architectures. > some uniqueness with regard to I/O options that are not found on x86 > workstations and servers, so there was some effort put in here that is But yes, the rpi as a whole is very dependent on upstream status and where/when they choose to land that so a lot of it is out of our control. The architecture as a whole is very much at feature parity generally with x86. > noteworthy. Y'all have done some good work here. Wish I had the time to > help out! > > Once again, kudos!!! > > > > On 12/1/2022 6:56 AM, Peter Robinson wrote: > > Hi Randy, > > > >> Nothing short of amazing work. Kudos+ to the devs and all that made > >> this work. I've been a UNIX/Linux C/C++ developer (professionally) for > >> 23 years now; I recognize excellence when I see it. My Pi-4 never ran > >> this good. Clocked to 2100 MHz it runs triple duty as an internal > >> web/media server, secondary name server and primary caching proxy via > >> Apache Traffic Server at speeds I wouldn't have expected from such a > >> modest device. > >> > >> Again, Kudos (hats off, bow down) to the developers that made this happen! > > Thanks for the feedback, it was a nice start to the day. We of course > > still have a way to go but I felt it's got to a great space! > > > > Peter > > -- > Randall DuCharme (Radio AD5GB) > Powered entirely by Open Source software. > ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Raspberry Pi 4b + F-37
Hi Randy, > Nothing short of amazing work. Kudos+ to the devs and all that made > this work. I've been a UNIX/Linux C/C++ developer (professionally) for > 23 years now; I recognize excellence when I see it. My Pi-4 never ran > this good. Clocked to 2100 MHz it runs triple duty as an internal > web/media server, secondary name server and primary caching proxy via > Apache Traffic Server at speeds I wouldn't have expected from such a > modest device. > > Again, Kudos (hats off, bow down) to the developers that made this happen! Thanks for the feedback, it was a nice start to the day. We of course still have a way to go but I felt it's got to a great space! Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Thinkpad X13s, a wikipage about support development
On Tue, Nov 29, 2022 at 4:38 PM Germano Massullo wrote: > > > > If you find it useful that great, but myself and others working on it > > likely won't update it. The problem with wiki pages is they're > > basically constantly out of date and things are moving fast. > > Yes I understand. I just added some infos in the page > > > Basically we're aiming for it being supportable/usable in time for > > Fedora 38, at some point before that I'm going to produce consumable > > images. Some things that are blocking us are currently under NDA so > > aren't publishable on a wiki or anywhere else. > > I guess the NDA part concerns the virtualization support It covers a number of things, none of which I can comment on either way. > > When there's a a consumable image it will be published and there will > > be notification in places like here and IRC for people to test and > > feedback. Until that point there's two options 1) hack something > > together yourseslf if you are capable 2) wait for some who is to > > publish consumable pieces. > > Thank you for the update! ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Thinkpad X13s, a wikipage about support development
On Tue, Nov 22, 2022 at 1:15 AM Germano Massullo wrote: > > > > +1 Germano. > > I just purchased the x13s and would love a place to collaborate > > I created page > https://fedoraproject.org/wiki/Thinkpad_X13s > tomorrow I will start filling it with some informations. If you find it useful that great, but myself and others working on it likely won't update it. The problem with wiki pages is they're basically constantly out of date and things are moving fast. Basically we're aiming for it being supportable/usable in time for Fedora 38, at some point before that I'm going to produce consumable images. Some things that are blocking us are currently under NDA so aren't publishable on a wiki or anywhere else. When there's a a consumable image it will be published and there will be notification in places like here and IRC for people to test and feedback. Until that point there's two options 1) hack something together yourseslf if you are capable 2) wait for some who is to publish consumable pieces. Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Could not initialise OpenGL support
On Sat, Nov 19, 2022 at 9:07 PM Arpad Jordan wrote: > > Thank you Peter > > In fact I have followed Sally's hints and now I have video playback from > Youtube and BBC iPlayer in Firefox. Pity that didn't actually make the list for others to be able to also use. > However I experience issues with colors of videos when streaming via Firefox. > In case I download Youtube video and play it with mpv the colors are good. > > Is this a known issue? Yes, it will be fixed when mesa 22.3.4 lands in Fedora. Details in bug: https://bugzilla.redhat.com/show_bug.cgi?id=2131724 ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Fedora on Odroid M1
On Fri, Nov 18, 2022 at 5:42 PM Andreas Reschke wrote: > > > Am 18.11.22 um 18:01 schrieb Peter Robinson: > > On Fri, Nov 18, 2022 at 4:31 PM Andreas Reschke wrote: > >> Am 27.07.22 um 16:03 schrieb Peter Robinson: > >>> Hi, > >>> > >>>> I would like to buy a Odroid M1 (CPU RK3568B2, petitboot as bootloader). > >>>> Is there any change to install Fedora on it? Even a headless > >>>> installation would be nice. > >>> So there's a couple of bits here: > >>> 1) Never dealt with petitboot on arm (I have on POWER) but the only > >>> boot interface Fedora arm officially supports is UEFI so if petitboot > >>> implements that and also provides a DT to the kernel it may work. > >>> Essentially any device firmware should comply with the Arm SystemReady > >>> IR spec and it should be good. > >>> 2) The rk356x support is maturing upstream, all the upstream pieces > >>> are available in Fedora display may even work > >>> 3) Device tree (DT), if the firmware provides a DT and it's compatible > >>> with the upstream kernel it should work, else there currently needs to > >>> be > >>> > >>> Generally Odroid has been pretty hostile to the wider open source > >>> community so it's a best effort means of support, no one I'm aware of > >>> that regularly helps out on Fedora Arm has any Odroid devices so it's > >>> fix things we explicitly get reported from the community where we can. > >>> > >>> If you explicitly want something with the rk356x SoCs in it I would > >>> look at some of the others like the Pine64 Quartz64 or another similar > >>> more community friendly vendor > >> > >> Hello together, Hello Peter, > >> > >> I've a look at the Pine64 store and didn't found what I'm looking for. > >> > >> Requirements: > >> > >> - CPU: min 4 core @ 2 GHz > >> > >> - RAM: min 8 GB > >> > >> - Storage: PCIe M.2 M-KEY (SSD) Socket, eMMC + SD-Card > >> > >> - Ethernet: Gigabit > >> > >> - USB3 + USB2 > >> > >> I've found Orange Pi 5 > >> (http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5.html) > >> but it's not available yet. > >> > >> Will this device work with Fedora? Are there other devices with this > >> requirements ? > > It will eventually, the support upstream isn't complete yet for the > > rk3588, hardware with that SoC is only just starting to ship. I am > > getting a Rock5 board which is based on the same SoC which I ordered > > back in May and I got a shipping notification yesterday. > > Hello Peter, > > thanks for that info, Please keep the list up2date with that board. I generally don't post updates about board or SoC support to the list, it's not my job to send status emails, sorry I have better things to do than remember what devices/SoCs may or may not be interested in. We have weekly arm meetings, you can follow upstream, and occasionally for important devices like the RPi4 we will do a feature. Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Could not initialise OpenGL support
On Fri, Nov 18, 2022 at 9:07 PM Arpad Jordan wrote: > > Hello, > > I have a freshly installed and updated Fedora 37 running on my Raspberry Pi > 4G. > > [jordana@pi4g ~]$ uname -a > Linux pi4g 6.0.8-300.fc37.aarch64 #1 SMP PREEMPT_DYNAMIC Fri Nov 11 14:38:11 > UTC 2022 aarch64 aarch64 aarch64 GNU/Linux > > I happily use it as my daily workstation driver but I am starting to miss my > occasional video playback. I can not really make any videos working via > Firefox from Youtube or BBC iPlayer. > > But even the stock Videos application is giving me the error in the subject > on the Apple trailer videos shipping with the build. > > Is video playback supported on Raspberry Pi please? Video playback is but accelerated offload support is not ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Fedora on Odroid M1
On Fri, Nov 18, 2022 at 4:31 PM Andreas Reschke wrote: > > Am 27.07.22 um 16:03 schrieb Peter Robinson: > > Hi, > > > >> I would like to buy a Odroid M1 (CPU RK3568B2, petitboot as bootloader). > >> Is there any change to install Fedora on it? Even a headless > >> installation would be nice. > > So there's a couple of bits here: > > 1) Never dealt with petitboot on arm (I have on POWER) but the only > > boot interface Fedora arm officially supports is UEFI so if petitboot > > implements that and also provides a DT to the kernel it may work. > > Essentially any device firmware should comply with the Arm SystemReady > > IR spec and it should be good. > > 2) The rk356x support is maturing upstream, all the upstream pieces > > are available in Fedora display may even work > > 3) Device tree (DT), if the firmware provides a DT and it's compatible > > with the upstream kernel it should work, else there currently needs to > > be > > > > Generally Odroid has been pretty hostile to the wider open source > > community so it's a best effort means of support, no one I'm aware of > > that regularly helps out on Fedora Arm has any Odroid devices so it's > > fix things we explicitly get reported from the community where we can. > > > > If you explicitly want something with the rk356x SoCs in it I would > > look at some of the others like the Pine64 Quartz64 or another similar > > more community friendly vendor > > > Hello together, Hello Peter, > > I've a look at the Pine64 store and didn't found what I'm looking for. > > Requirements: > > - CPU: min 4 core @ 2 GHz > > - RAM: min 8 GB > > - Storage: PCIe M.2 M-KEY (SSD) Socket, eMMC + SD-Card > > - Ethernet: Gigabit > > - USB3 + USB2 > > I've found Orange Pi 5 > (http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5.html) > but it's not available yet. > > Will this device work with Fedora? Are there other devices with this > requirements ? It will eventually, the support upstream isn't complete yet for the rk3588, hardware with that SoC is only just starting to ship. I am getting a Rock5 board which is based on the same SoC which I ordered back in May and I got a shipping notification yesterday. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: NanoPC-t4 does not boot with branch 20221008
On Tue, Oct 18, 2022 at 11:33 AM Peter Robinson wrote: > > On Tue, Oct 18, 2022 at 11:31 AM Peter Boy wrote: > > > > Hi, > > > > > Am 14.10.2022 um 08:54 schrieb Peter Robinson : > > > > > > On Wed, Oct 12, 2022 at 6:14 PM Peter Robinson > > > wrote: > > >> > > >> Peter, > > >> > > >> Can you try adding modprobe.blacklist=phy_rockchip_inno_usb2 to the > > >> kernel command line and see if that works for you? > > > > > > So I'm pretty sure this is now fixed with kernel 5.19.15-301.fc37 or > > > 5.19.15-201.fc36 so if you could give it a test that would be fab. It > > > should be stable into F-37 RSN but you could also deploy a default > > > F-36 image and update to the F-36 kernel as I think you said F-36 GA > > > worked. > > > > > > > sorry for the delay, there was so much to do … > > > > Kernel 5.19.15-201.fc36 works superb. Everything I tested works without any > > issue on my nanopc-t4, including the NVMe board. > > > > Unfortunately, I couldn’t fetch a suitable image for f37, yet. > > > > Branch 20221017 includes an older kernel, the rawhide build of today failed > > (https://koji.fedoraproject.org/koji/taskinfo?taskID=93172623), and rc 1.1 > > includes an even older kernel. > > RC 1.1 should have had the fixed kernel because it was a blocker. ah, no this is an issue https://pagure.io/releng/issue/11094 ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: NanoPC-t4 does not boot with branch 20221008
On Tue, Oct 18, 2022 at 11:31 AM Peter Boy wrote: > > Hi, > > > Am 14.10.2022 um 08:54 schrieb Peter Robinson : > > > > On Wed, Oct 12, 2022 at 6:14 PM Peter Robinson wrote: > >> > >> Peter, > >> > >> Can you try adding modprobe.blacklist=phy_rockchip_inno_usb2 to the > >> kernel command line and see if that works for you? > > > > So I'm pretty sure this is now fixed with kernel 5.19.15-301.fc37 or > > 5.19.15-201.fc36 so if you could give it a test that would be fab. It > > should be stable into F-37 RSN but you could also deploy a default > > F-36 image and update to the F-36 kernel as I think you said F-36 GA > > worked. > > > > sorry for the delay, there was so much to do … > > Kernel 5.19.15-201.fc36 works superb. Everything I tested works without any > issue on my nanopc-t4, including the NVMe board. > > Unfortunately, I couldn’t fetch a suitable image for f37, yet. > > Branch 20221017 includes an older kernel, the rawhide build of today failed > (https://koji.fedoraproject.org/koji/taskinfo?taskID=93172623), and rc 1.1 > includes an even older kernel. RC 1.1 should have had the fixed kernel because it was a blocker. Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Heads-up: Planning to have LXQt spin images on aarch64 since Fedora 38
> Just a heads-up, since aarch64 is more and more easily available in > laptop and workstation form, I'm planning to request for generating LXQt > images for aarch64. In order to unify the workflow, I've filed a > self-contained change[1] and also the corresponding ticket to > rel-eng[2]. If there are any other tickets I should create, feel free to > let me know. Looks fine to me, let me know if you need any other assistance or have any queries. > [1] https://fedoraproject.org/wiki/Changes/LXQt_image_for_aarch64 > [2] https://pagure.io/releng/issue/11086 > -- > Zamir SUN > Fedora user > GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E > ___ > arm mailing list -- arm@lists.fedoraproject.org > To unsubscribe send an email to arm-le...@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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: NanoPC-t4 does not boot with branch 20221008
On Wed, Oct 12, 2022 at 6:14 PM Peter Robinson wrote: > > Peter, > > Can you try adding modprobe.blacklist=phy_rockchip_inno_usb2 to the > kernel command line and see if that works for you? So I'm pretty sure this is now fixed with kernel 5.19.15-301.fc37 or 5.19.15-201.fc36 so if you could give it a test that would be fab. It should be stable into F-37 RSN but you could also deploy a default F-36 image and update to the F-36 kernel as I think you said F-36 GA worked. > Peter > > On Mon, Oct 10, 2022 at 8:21 AM Peter Robinson wrote: > > > > On Sun, Oct 9, 2022 at 1:10 PM Peter Boy wrote: > > > > > > Last week I got my hands on a FriendlyElec NanoPC-t4 > > > > > > I tried to boot branch 20221008, but the boot process stopped at: > > > > > > [OK] Reached target basic.target - Basic System > > > [14.886445] dracut-initqueue[696]: WARNING: File locking is disabled. > > > Starting dbs-broker.serv…ice - D-Bus System Message Bus … > > > [OK] Found device dev-mapper-fe…ice - /dev/mapper/fedora-root. > > > [OK] Reached target initrd-root...e.target – Initrd Root Device. > > > [OK] Started dbus-broker.service – D-Bus System Message Bus. > > > > > > The same is true with Beta 1.5 and with Fedora 36. > > > > The above isn't particularly useful for debug, can you put the entire > > output of the boot process (U-Boot through dmesg) into a paste service > > somewhere. > > > > > It looks similar to an error I had with my Radxa Rock Pi 4a which was > > > resolved (the Rock Pi boots that branch without any problems, even from > > > NVMe disk using Armbian SPI Flash, by the way). > > > > > > Some branches earlier the process stopped at the same line, but after > > > about 15 mins continued repeatedly showing the same error message again > > > and again, and finally an emergency mode shell prompt. > > > > > > Unfortunately I didn’t noted any details because I run out of time. So I > > > retried today with the current branch. It it helps I can try to find the > > > branch with the latter behaviour. > > > > I'm not sure what you mean by branches in this context. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: NanoPC-t4 does not boot with branch 20221008
Peter, Can you try adding modprobe.blacklist=phy_rockchip_inno_usb2 to the kernel command line and see if that works for you? Peter On Mon, Oct 10, 2022 at 8:21 AM Peter Robinson wrote: > > On Sun, Oct 9, 2022 at 1:10 PM Peter Boy wrote: > > > > Last week I got my hands on a FriendlyElec NanoPC-t4 > > > > I tried to boot branch 20221008, but the boot process stopped at: > > > > [OK] Reached target basic.target - Basic System > > [14.886445] dracut-initqueue[696]: WARNING: File locking is disabled. > > Starting dbs-broker.serv…ice - D-Bus System Message Bus … > > [OK] Found device dev-mapper-fe…ice - /dev/mapper/fedora-root. > > [OK] Reached target initrd-root...e.target – Initrd Root Device. > > [OK] Started dbus-broker.service – D-Bus System Message Bus. > > > > The same is true with Beta 1.5 and with Fedora 36. > > The above isn't particularly useful for debug, can you put the entire > output of the boot process (U-Boot through dmesg) into a paste service > somewhere. > > > It looks similar to an error I had with my Radxa Rock Pi 4a which was > > resolved (the Rock Pi boots that branch without any problems, even from > > NVMe disk using Armbian SPI Flash, by the way). > > > > Some branches earlier the process stopped at the same line, but after about > > 15 mins continued repeatedly showing the same error message again and > > again, and finally an emergency mode shell prompt. > > > > Unfortunately I didn’t noted any details because I run out of time. So I > > retried today with the current branch. It it helps I can try to find the > > branch with the latter behaviour. > > I'm not sure what you mean by branches in this context. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: NanoPC-t4 does not boot with branch 20221008
On Sun, Oct 9, 2022 at 1:10 PM Peter Boy wrote: > > Last week I got my hands on a FriendlyElec NanoPC-t4 > > I tried to boot branch 20221008, but the boot process stopped at: > > [OK] Reached target basic.target - Basic System > [14.886445] dracut-initqueue[696]: WARNING: File locking is disabled. > Starting dbs-broker.serv…ice - D-Bus System Message Bus … > [OK] Found device dev-mapper-fe…ice - /dev/mapper/fedora-root. > [OK] Reached target initrd-root...e.target – Initrd Root Device. > [OK] Started dbus-broker.service – D-Bus System Message Bus. > > The same is true with Beta 1.5 and with Fedora 36. The above isn't particularly useful for debug, can you put the entire output of the boot process (U-Boot through dmesg) into a paste service somewhere. > It looks similar to an error I had with my Radxa Rock Pi 4a which was > resolved (the Rock Pi boots that branch without any problems, even from NVMe > disk using Armbian SPI Flash, by the way). > > Some branches earlier the process stopped at the same line, but after about > 15 mins continued repeatedly showing the same error message again and again, > and finally an emergency mode shell prompt. > > Unfortunately I didn’t noted any details because I run out of time. So I > retried today with the current branch. It it helps I can try to find the > branch with the latter behaviour. I'm not sure what you mean by branches in this context. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: Question about release upgrade
> When you upgrade a SBC from one release to the next using the dnf upgrade > method, it updates all the files in the filesystem in the same way as with a > standard installation - I guess. So it would be fine to use that method on a > SBC installed by arm-image-installer. > > But what about the files idbloader.img and u-boot.itb which > arm-image-installer copies to the boot media in a separate dd step? Does the > dnf method upgrades those, too, or do I have to do it manually afterwards? Or > is there something else to do? You need to update it separately, it's a device firmware so it's treated separately. For the firmwares that reside on the same storage as the OS (mSD etc) there's a update-uboot tool that works similarly to arm-image-installer and is part of the same package. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: System no longer bootable after latest update.
On Mon, Sep 5, 2022 at 8:28 AM Peter Boy wrote: > > > Just as an addition: I made an update with kernel excluded and everything > went fine. All the update issues I reported seem to be related to the kernel. > > There is on exception: certmonger, issues a message: „No CA with name > „certmaster“ found. That should be reported to the component as per normal process. > By the way, there are a lot of differences in installed packages between the > SBC image and Fedora Server Installation DVD for x86 that are probably not > architecture or hardware specific. For example, the image installs flatpack > items that we don't really want on Fedora Server. That should be taken to the Server SIG. ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: System no longer bootable after latest update.
> > So Fedora doesn't include a SPI version of it because neither of the > > Rock Pi 4 devices, rock-pi-4-rk3399 and rock-pi-4c-rk3399, have > > support for SPI in upstream U-Boot even with upstream master ATM. I > > have neither of those devices so I can't test any patches I could do > > to be able to send that support upstream. > > So the Armbian docu pretends something that doesn’t exist - not nice. So looking at this post I don't believe they claim to not be using patches, looking at the following forum post [1] I read it as basing their builds on the upstream code vs basing it on the Raxda vendor fork, which I suspect is based on Rockchip's ancient vendor fork, so it's nuanced but not necessarily incorrect. Also when trying to find their source I find this message which is more troubling [2]. > > So you get output from U-Boot before you get a grub menu? If so what > > version string does the Armbian firmware return? > > It says: U-Boot 2020.10 - Armbian May 06 2011 > > > > I may have found something, but I'm still bisecting some pieces down. > > Gives ma hope. So the thing that I've found is a regression in U-Boot between 2022.07 rc5 and rc6 for the devices I've seen the issue on. I've filed a bug [3] so for the Fedora builds we can do a blocker but I don't know if your build would have that patch pulled in or not so it's hard to tell but I've no been able to find the Armbian source for their U-Boot builds, see [2]. If you could find their sources/patches it would be useful there. Looking at [4] it seems they at least patch the configs which indicates they do more. Also from that post the RockPi4 has XTX SPI flash so it might not be hard for me to create a patch for upstream to support it but without one of these boards the round trips of remote low level debug of boot issues with firmware is probably too time consuming for me to do at the moment. Peter [1] https://forum.armbian.com/topic/16195-booting-rock-pi-4abc-with-mainline-u-boot-in-spi-nvme-and-armbian-v2011x/ [2] https://forum.armbian.com/topic/21024-rock-pi-4-does-armbian-build-their-own-u-boot-and-tf-a-binaries/ [3] https://bugzilla.redhat.com/show_bug.cgi?id=2124127 [4] https://forum.armbian.com/topic/16195-booting-rock-pi-4abc-with-mainline-u-boot-in-spi-nvme-and-armbian-v2011x/?do=findComment=114327 ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: System no longer bootable after latest update.
> >> Before that I got the EFI screen and could select a kernel, but the > >> keyboard is not initialised so the system does respond to the cursor keys > >> at all. > > > > Is it the firmware shipped by Fedora or does it come from elsewhere? > > Fedora doesn’t include a spi Version, so I used spi firmware from Armbian > late 2020, which is according to Arabian docu mainline U-Boot. And > everything worked since then. So Fedora doesn't include a SPI version of it because neither of the Rock Pi 4 devices, rock-pi-4-rk3399 and rock-pi-4c-rk3399, have support for SPI in upstream U-Boot even with upstream master ATM. I have neither of those devices so I can't test any patches I could do to be able to send that support upstream. > But when the kernel issue arises, the system is already running from NVMe > device, isn’t it? It could be because something had changed in the firmware and the kernel isn't powering up a regulator that is needed by PCI or similar that was previously powered up by firmware. > > Which model of Rock Pi 4 is it? > It is the Rock Pi 4a (without wifi), Board revision 1.4 which is the first > revision with a soldered SPI module. > > > > Do you get all the early displayoutput? > > I get after the update the same output as with the installation kernel. That > is the EFI selection screen, the the display goes blank so some seconds, then > the online message in the first line „BootingFedora …, then the display goes > blank again for some seconds, and the output as I wrote in my previous mail. > The keyboard is with both kernels not operational when the EDI screen is > displayed. So you get output from U-Boot before you get a grub menu? If so what version string does the Armbian firmware return? I may have found something, but I'm still bisecting some pieces down. Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: System no longer bootable after latest update.
> >> Yesterday I (re-)installed my Rock Pi4 with F36 and then did an update. > >> > >> During the update there showed up various messages listed below. > >> Afterwards the system didn’t boot anymore. > >> > >> Last messages on screen: > >> > >> Started Plymouth-start.ser?e - Show Plymouth Boot Screen > >> Started systems-ask-passw*uests to Plymouth Directory Watch. > >> Reached target paths.target - Path Units. > >> Reached target basic.target - Basic System. > > > > What were the messages before that, there could well be a lot of other > > things that happen in the boot process prior to that that causes it to > > stop there. > > Before that I got the EFI screen and could select a kernel, but the keyboard > is not initialised so the system does respond to the cursor keys at all. Is it the firmware shipped by Fedora or does it come from elsewhere? Which model of Rock Pi 4 is it? Do you get all the early display output? What device is the firmware running off? A cheap USB TTL is often useful although I've send patches upstream for numerous devices to fix things like keyboard/display. > Kernel: > 15.19.6-200.fc36 default selection and obviously installed by update > 15.17.5-300.fc36 I guess the kernel install by installation image > > It follows the message in 1 line > Booting ‚Fedora Linux (5.19.6-200.fc36.aarch64) 36 (Server Edition)‘ > > Displays several seconds, then a screen refresh and just the 4 lines By "displays several seconds" do you mean kernel output or something else? > >> Then nothing happened anymore. > > > > Does it just hang there? Does it eventually drop you to an emergency shell? > > Just hanging there, no emergency shell, unfortunately. I've tried two > 1 time (out of several tries) I got additional output: > > 10.951731. Unable zu handle kernel execute from non-executable memory at > virtual address (16 x 0) > > and 27 lines of messages. I was able to take a picture with my phone which I > am happy to send you if if helps. > > > > >> One question is, how to fix it. > > > > Hard tell tell. Can you start by selecting the previous booting kernel > > from the grub2 menu and see if that works. Debugging problems on arm > > is no different to debugging on x86. > > For my case here it was a fresh installation, so there is no loss of data > (though of course I'd like it up and running so I can use it productively. It > runs my server monitoring software). But I think it is urgent to find the > cause and fix it, before other users may be severely impaired. > > > > > > >> The other question is how can such a disaster happen? With an item that is > >> offered for download on the Fedora Server page, something like this should > >> not happen. > > > > Fedora is a complex system of software with a lot of moving parts and > > a lot of updates frrom F-36 GA -> latest updates. > > > Yes, indeed. But we managed for years now to find such issues before we > published an update - at least as far as I remember the updates of all our > servers. > > >> Update messages > >> > >> Updating:selinux-policy-36.14-1.fc36.noarch > >> 240/670 > > > > You've included a very small part of the update, it shows there's 670 > > update transactions happening, you've included a random selection > > between 240-248, then 251-255 then to 351-354 and then back to the > > 250s. Why this selection? I'm guessing in here there's at least a new > > kernel. What was the previously booting kernel and what was the one > > you were trying to boot? > > > > I selected all item with an „unusual“ message expecting one of those being > the culprit. But obviously, it is the kernel. > > I can attach the m2 board to another machine and try to reconfigure grub to > use the old kernel, if that helps. So you're running it off a NVME card? I've tested my Pinebook Pro which has a NVME in it and is a rk399 device and it's booting OK with the latest 5.19.6 F-37 kernel. Peter ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[fedora-arm] Re: System no longer bootable after latest update.
> Yesterday I (re-)installed my Rock Pi4 with F36 and then did an update. > > During the update there showed up various messages listed below. Afterwards > the system didn’t boot anymore. > > Last messages on screen: > > Started Plymouth-start.ser?e - Show Plymouth Boot Screen > Started systems-ask-passw*uests to Plymouth Directory Watch. > Reached target paths.target - Path Units. > Reached target basic.target - Basic System. What were the messages before that, there could well be a lot of other things that happen in the boot process prior to that that causes it to stop there. > Then nothing happened anymore. Does it just hang there? Does it eventually drop you to an emergency shell? > One question is, how to fix it. Hard tell tell. Can you start by selecting the previous booting kernel from the grub2 menu and see if that works. Debugging problems on arm is no different to debugging on x86. > The other question is how can such a disaster happen? With an item that is > offered for download on the Fedora Server page, something like this should > not happen. Fedora is a complex system of software with a lot of moving parts and a lot of updates frrom F-36 GA -> latest updates. > > > > > Update messages > > Updating:selinux-policy-36.14-1.fc36.noarch > 240/670 You've included a very small part of the update, it shows there's 670 update transactions happening, you've included a random selection between 240-248, then 251-255 then to 351-354 and then back to the 250s. Why this selection? I'm guessing in here there's at least a new kernel. What was the previously booting kernel and what was the one you were trying to boot? > Scriptlet: selinux-policy-36.14-1.fc36.noarch > 240/670 > Updating:selinux-policy-targeted-36.14-1.fc36.noarch > 241/670 > Scriptlet: selinux-policy-targeted-36.14-1.fc36.noarch > 241/670 > uavc: op=load_policy lsm=selinux seqno=2 res=1Regex version mismatch, > expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 > Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 > > Scriptlet: container-selinux-2:2.188.0-1.fc36.noarch > 242/670 > Updating:container-selinux-2:2.188.0-1.fc36.noarch > 242/670 > Scriptlet: container-selinux-2:2.188.0-1.fc36.noarch > 242/670 > uavc: op=load_policy lsm=selinux seqno=3 res=1Regex version mismatch, > expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 > Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 > Updating:containers-common-4:1-59.fc36.noarch > 243/670 > Scriptlet: freeipa-selinux-4.9.10-4.fc36.noarch > 244/670 > > Updating:freeipa-selinux-4.9.10-4.fc36.noarch > 244/670 > Ausgeführtes Scriptlet: freeipa-selinux-4.9.10-4.fc36.noarch > 244/670 > uavc: op=load_policy lsm=selinux seqno=4 res=1Regex version mismatch, > expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 > Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 > Updating:freeipa-common-4.9.10-4.fc36.noarch > 246/670 > Scriptlet: smartmontools-selinux-1:7.3-2.fc36.noarch > 246/670 > uavc: op=load_policy lsm=selinux seqno=5 res=1Regex version mismatch, > expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 > Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 > Updating:krb5-pkinit-1.19.2-11.fc36.aarch64 > 247/670 > Updating:krb5-workstation-1.19.2-11.fc36.aarch64 > 248/670 > ... > Updating:cockpit-ws-275-1.fc36.aarch64 > 251/670 > Scriptlet: cockpit-ws-275-1.fc36.aarch64 > 251/670 > uavc: op=load_policy lsm=selinux seqno=6 res=1Regex version mismatch, > expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 > Regex version mismatch, expected: 10.39 2021-10-29 actual: 10.40 2022-04-14 > … > Updating:nss-3.81.0-1.fc36.aarch64 > 253/670 > Scriptlet: nss-3.81.0-1.fc36.aarch64 > 253/670 > Updating:certmonger-0.79.15-3.fc36.aarch64 > 254/670 > Scriptlet: certmonger-0.79.15-3.fc36.aarch64 > 254/670 > No CA with name "certmaster" found. > > Updating: libblockdev-crypto-2.27-1.fc36.aarch64 > 255/670 > ... > Scriptlet: certmonger-0.79.15-2.fc36.aarch64 > 351/670 > Scriptlet:
