[fedora-arm] Error with arm-image-installer F39 Rpi4 IoT image on F38 Host
I just tried to use arm-image-installer to build an Rpi4 IoT image using the Fedora-39 IoT release image: Fedora-IoT-39.20231103.1-20231103.1.aarch64.raw.xz I asked the installer to resize the partition. At the end of the run, I get: The partition table has been altered. Calling ioctl() to re-read partition table. Syncing disks. e2fsck 1.46.5 (30-Dec-2021) /dev/sdb3 has unsupported feature(s): FEATURE_C12 e2fsck: Get a newer version of e2fsck! root: ** WARNING: Filesystem still has errors ** resize2fs 1.46.5 (30-Dec-2021) Please run 'e2fsck -f /dev/sdb3' first. I'm guessing the file system was created with a newer version of e2fsprogs than that supported in F38 (and there is no update on F38) and it created a new default feature in the filesystem, which isn't supported in the older version. According to google, this might be the orphan_file feature, but I have not verified that. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- ___ 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
Hi, First, thank you for all the time you're putting into helping me. I really do appreciate it, especially since the platform is not currently supported. (More below) On Mon, April 15, 2024 4:49 pm, Peter Robinson wrote: > 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. By "docs", I am looking at the schematics. Starting at JP4, we have: JP4 4 -> GPIO3_12 -> MXM Pin 256 -> EIM_DA11 -> IMX6 NVCC_EIM2 EIM_DA11 (M20) JP4 6 -> GPIO3_27 -> MXM Pin 258 -> GPIO3_27 -> IMX6 NVCC_EIM0 EIM_D27 (E25) JP4 8 -> GPIO6_31 -> MXM Pin 260 -> GPIO6_31 -> IMX6 NVCC_EIM2 EIM_BCLK (N22) JP4 10-> GPIO1_24 -> MXM Pin 262 -> MIC_DET -> IMX6 NVCC_ENET ENET_RX_ER (W23) JP4 12-> GPIO7_8 -> MXM Pin 264 -> SD3_RST -> IMX6 NVCC_SD3 SD3_RST (D15) JP4 14-> GPIO3_26 -> MXM Pin 259 -> GPIO3_26 -> IMX6 NVCC_EIM0 EIM_D26 (E24) JP4 16-> GPIO_18 -> MXM Pin 261 -> EIM_DA8 -> IMX6 NVCC_EIM2 EIM_DA8 (L24) JP4 18-> GPIO_19 -> MXM Pin 263 -> GPIO_19 -> IMX6 NVCC_GPIO GPIO_19 (P5) So clearly some of the JP4 pins get "renamed" when crossing the MXM connector boundary, and some get renamed again when connecting to the IMX6. However, I still don't know how to map the e.g. IMX6 NVCC_GPIO to a libgpiod gpiochipN. > 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. One would expect that, but I'm having a heck of a time tracking that down. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- ___ 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
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? Thanks, -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- ___ 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
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. -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 Atkins 617-623-3745 >de...@ihtfp.com www.ihtfp.com >Computer and Internet Security Consultant > > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- ___ 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
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 Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- ___ 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
Hi, Thank you the response! My replies inline below... On Mon, April 15, 2024 11:14 am, Peter Robinson wrote: > 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? 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. >> 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? > 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? >> 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 honestly I'd rather not spend the money... :) > Peter -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- ___ 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] Mapping GPIO Pins from Wandboard to Fedora/libpiod
Hi Arm Team, I have a Wandboard (yeah, I know, OLD Hardware) currently running a 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. 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. 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. I'd appreciate any guidance anyone might have on this subject. Thanks, -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant -- ___ 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 support for NanoPi-R1?
On Tue, November 30, 2021 9:19 am, Derek Atkins wrote: > [snip] > Granted, it works here, but I'd like to "update" from the old version of > Fedora running there onto a newer version, but the main issue is the > unifi > controller. The issue was with mongodb-server, where I had to rebuild it > myself to get it to work on the platform. If I'm going to upgrade to F35 > on the WB I might need to do that again (unless it will continue to > support mongodb 4.0.3). > > Unfortunately there is still not an armhfp build of mongo -- although > there is one for aarch64, so if I stay with that (instead of aarch64) > I'll > still have to rebuild mongo again -- so I guess to replace this system > I'd > want an aarch64 board with sufficient RAM to run mongo and unifi. I > don't > mind using an SD for storage (certainly for mongo). The system currently > uses 6G of storage, which would fill most of the 8G eMMC devices. But I > am concerned about the 1G. Actually, looking at Mongo's site, they only started supporting AArch64 for mongodb 4.4, and it's unclear if Unifi Controller supports that! I built 4.0 and have been running with that, so even going to an aarch64 platform might not suffice. So it might not even matter. :-( -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[fedora-arm] Re: Fedora support for NanoPi-R1?
On Tue, November 30, 2021 8:53 am, Peter Robinson wrote: >> I've been using Wandboards, which I've liked, but I discovered that what >> I >> was using just wasn't powerful enough to do what I wanted to do.. So I >> was looking for replacements for my wandboards. I have a handful of >> these >> R1 devices from work, so I've been able to play with them and verify >> that, >> yes, it can do what I want and perform much better than the wandboard >> quad >> did. > > The R1 is based on a Allwinner H3, it's a quad core Cortex-A7, it's > not really any more powerful than the quad core Wandboard TBH. Perhaps, but it IS faster/more powerful. Not that you can trust the "bogomips" results, but the R1 definitely reports a "higher" number ;) Specifically, the WB reports 6, and the R1 reports 64. And I was able to get more audio streams through the R1 than the Wandboard running shairport-sync. On the other hand, I do need to go verify that I *WAS* running a quad wandboard for that server; I honestly don't recall now (and the device is now offline) so I can't quickly check. >> Let me turn this around; what board (with case) would *YOU* recommend >> for >> some small, low-power arm-based server platforms? > > I always reply to that with the question what are you doing with them? > What are your feature requirements? Eth? Dual eth? WiFi, etc. I've got three ARM systems deployed right now: 1) DHCP/DNS/Unifi Controller 2) Asterisk 3) My shairport-sync server (~16 streams) Right now I've got #3 on an R1 with Armbian Buster -- the only non-RPM-based distro I'm running! #2 is fine as a wandboard quad. I'm not having issues there. #1 is running on a Wandboard Quad, which has 2GB RAM. Currently it is reporting: [~]# free totalusedfree shared buff/cache available Mem:2061172 871612 140692 804 1048868 1162612 Swap:982420 11008 971412 Granted, it works here, but I'd like to "update" from the old version of Fedora running there onto a newer version, but the main issue is the unifi controller. The issue was with mongodb-server, where I had to rebuild it myself to get it to work on the platform. If I'm going to upgrade to F35 on the WB I might need to do that again (unless it will continue to support mongodb 4.0.3). Unfortunately there is still not an armhfp build of mongo -- although there is one for aarch64, so if I stay with that (instead of aarch64) I'll still have to rebuild mongo again -- so I guess to replace this system I'd want an aarch64 board with sufficient RAM to run mongo and unifi. I don't mind using an SD for storage (certainly for mongo). The system currently uses 6G of storage, which would fill most of the 8G eMMC devices. But I am concerned about the 1G. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[fedora-arm] Re: Fedora support for NanoPi-R1?
Thanks Peter, On Tue, November 30, 2021 8:32 am, Peter Robinson wrote: >> Looking at the --supported list in arm-image-installer I see a bunch of >> the NanoPi variations, except for the one I have (from work), the >> NanoPi-R1. >> >> I was able to get Armbian running on it without any issue, and it's >> running quite happily. However, I would certainly much prefer to run >> Fedora. >> >> To that end, what would it take to get Fedora onto the device? > > There's no upstream support in U-Boot for the device, in the upstream > Linux kernel there is a device tree, so you may be able to use a 3rd > party U-Boot but YMMV. Well, I do have a "working" u-boot for the platform... But yeah, it would certainly be "better" to have it upstream. *sigh* I've been using Wandboards, which I've liked, but I discovered that what I was using just wasn't powerful enough to do what I wanted to do.. So I was looking for replacements for my wandboards. I have a handful of these R1 devices from work, so I've been able to play with them and verify that, yes, it can do what I want and perform much better than the wandboard quad did. Let me turn this around; what board (with case) would *YOU* recommend for some small, low-power arm-based server platforms? -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[fedora-arm] Fedora support for NanoPi-R1?
Hi, Looking at the --supported list in arm-image-installer I see a bunch of the NanoPi variations, except for the one I have (from work), the NanoPi-R1. I was able to get Armbian running on it without any issue, and it's running quite happily. However, I would certainly much prefer to run Fedora. To that end, what would it take to get Fedora onto the device? -derek PS: I realize I could look at the Neo+ or M1+ which are supported, but those all appear to be a bare board and I can't (quickly) find those in a nice container like the R1 comes with. -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[fedora-arm] Re: What if Fedora stopped building for 32-bit ARM (armv7hl) in F36+?
All my ARM boards (basically WandBoard) are, as far as I know, 32-bit-only. Losing 32-bit support would effectively mean I need to find a different distribution for all my devices that I have deployed. -derek PS: If I am wrong and the wandboards can run Arm64, I am happy to be corrected. On Wed, August 18, 2021 12:03 pm, RENARD Pierre-Francois wrote: > Hello Miro, > > I did not use 32-bit ARM version since many years :) > Do we have an idea on how many people are downloading 32-bit and 64-bit > ARM images ? > > it is about time I guess, especially if it is a pain to maintain :) > > Fox > > On 8/18/21 10:27 AM, Miro Hrončok wrote: >> Hello, an interesting discussion is happening on the Fedora devel >> mailing list about possibly dropping 32-bit ARM (armv7hl) support: >> >> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/OIE27O74U4H4JJOCJJBRTZS7AFNXDL44/ >> >> Before proceeding with the idea, I'd like to know what do the ARM people >> on this list think about it. >> >> Is it crazy, or is it about time? >> > ___ > 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 on the list, report it: > https://pagure.io/fedora-infrastructure > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[fedora-arm] Re: Logging in after an install
Connect a USB keyabord and HDMI monitor and login via console. -derek On Fri, December 11, 2020 7:31 am, Sam Varshavchik wrote: > I put it aside for a few months, but I picked up my attempt to get Fedora > up > and running on a PI 3B. > > I used arm-image-installer to install the F32 image I prepared: > > fedora-arm-image-installer > --image=Fedora-Workstation-32-1.6.aarch64.raw.xz > --media=/dev/sdc --target=rpi3 --resizefs --norootpass > > The PI boots up until the message, this is the last message that appears > on > the console: > > fb0: switching to vc4drmfb from EFI VGA > > No more messages appear, no console login. > > But there is apparently a new DHCP assignment on my network. However > ssh-ing > to that IP address prompts for the root password, and it does not accept > an > empty password. > > I suppose I could pull the SD card out, mount it, and copy over an ssh > into > /root, but what exactly did --norootpass do, and what about not being able > to log in through the console? I didn't have a keyboard attached yet, I > would think I'd get at least a prompt. > > ___ > 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 > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Wandboard Quad RevD1 has no Ethernet in Fedora F31?
On Wed, April 22, 2020 6:47 am, Peter Robinson wrote: >> > Yep, I've seen the upstream discussion, I'll test the patches on my >> > revB1 when I get a moment, I've asked in the community if there's >> > someone with a revC to test. I suspect with the delays we might well >> > have another U-Boot build. Any chance you could do a bug report for me >> > here? >> >> FYI, I've got an old Rev C1 Wandboard-Dual and I can verify that this >> u-boot works there: > > FYI this is fixed in the uboot-tools-2020.04-2.fc32 and will in in > F-32. Available now for testing. Thanks, Peter! > P -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Upgrading Uboot is insufficient to migrate my F31 system from WB Dual-C1 to Quad-D1
Peter,
On Fri, April 17, 2020 12:09 pm, Derek Atkins wrote:
[snip]
>
> Could be. I can try that. Right now I'm upgrading the "older" system to
> 5.5.16, so I'll test that first, but if that fails then I can go your
> route and "dnf reinstall" the kernel package after adding the
> dracut-config-generic package.
>
>> To do this install the dracut-config-generic package and reinstall or
>> upgrade the kernel, it'll be slower to boot, make sure it boots on the
>> current device, move to the new one.
>>
>> Once it's running on the new one remove the package and the next
>> kernel will go back to a host specific initrd with the specific initrd
>> for the new HW.
So I had to dnf reinstall kernel{,-core,-modules}-5.5.16-200.fc31.armv7hl
to get it to rebuild the initramfs. Just reinstalling 'kernel-..' was not
sufficient.
However it was also not sufficient to get past this issue. I still have
the same failure, same oops, and the system doesn't come up. So there
must be something with the old disk or something about upgrading from F25
-> F31 that leaves something behind that this device doesn't like. If
nothing else, it does not come up on the network using the old disk in the
new board.
So the generic initramfs is not sufficient. I guess if I want to swap
hardware I need to start from a fresh SD card F31-Minimal and migrate all
my configuration. :-(
Any other suggestions?
-derek
--
Derek Atkins 617-623-3745
de...@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
___
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
[fedora-arm] Re: Upgrading Uboot is insufficient to migrate my F31 system from WB Dual-C1 to Quad-D1
On Fri, April 17, 2020 11:47 am, Peter Robinson wrote: [snip] >> I'll let you know in a couple hours how the testing goes -- unless >> you've >> seen this before and have an easy fix? Upgrading the Fedora-Minimal-31 system to 5.5.16-200.fc31.armv7hl and it's still working. > I've not seen it before but what I recommend is to go to a generic > initrd so it pulls in all the drivers, move over to the new device and > then allow it to go back to a host specific initrd. See https://bugzilla.redhat.com/show_bug.cgi?id=1698208 > I suspect there's slightly different HW requirements. Could be. I can try that. Right now I'm upgrading the "older" system to 5.5.16, so I'll test that first, but if that fails then I can go your route and "dnf reinstall" the kernel package after adding the dracut-config-generic package. > To do this install the dracut-config-generic package and reinstall or > upgrade the kernel, it'll be slower to boot, make sure it boots on the > current device, move to the new one. > > Once it's running on the new one remove the package and the next > kernel will go back to a host specific initrd with the specific initrd > for the new HW. > > Peter Thanks, -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Upgrading Uboot is insufficient to migrate my F31 system from WB Dual-C1 to Quad-D1
Hi, All this talk about Wandboard Quad D1 is because I'm trying to upgrade an existing device currently running on a Wandboard Dual C1. It's a system that started as Fedora 25 and was upgraded to Fedora 31 (via dnf system-upgrade). It's been running fine on the Dual. I upgraded the U-boot and it still runs fine on the C1, however if I try to use this SD card in the Quad-D1 I get this during boot: [6.841555] Freeing unused kernel memory: 2048K [6.848283] [ cut here ] [6.852985] WARNING: CPU: 2 PID: 1 at arch/arm/mm/dump.c:248 note_page+0x1604 [6.860609] arm/mm: Found insecure W+X mapping at address 0xf0879000 [6.866994] Modules linked in: [6.870093] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.4.17-200.fc31.armv7h1 [6.877494] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [6.884062] [] (unwind_backtrace) from [] (show_stack+0x) [6.891825] [] (show_stack) from [] (dump_stack+0xb4/0xd) [6.899068] [] (dump_stack) from [] (__warn+0xdc/0xf8) [6.905958] [] (__warn) from [] (warn_slowpath_fmt+0x70/) [6.913455] [] (warn_slowpath_fmt) from [] (note_page+0x) [6.921383] [] (note_page) from [] (walk_pgd+0xc8/0xe0) [6.928357] [] (walk_pgd) from [] (ptdump_check_wx+0x58/) [6.935858] [] (ptdump_check_wx) from [] (kernel_init+0x) [6.943706] [] (kernel_init) from [] (ret_from_fork+0x14) [6.951281] Exception stack(0xee943fb0 to 0xee943ff8) [6.956339] 3fa0: 0 [6.964524] 3fc0: 0 [6.972708] 3fe0: 0013 [6.979365] ---[ end trace eb98c3200f90d0b6 ]--- [6.984352] Checked W+X mappings: FAILED, 1 W+X pages found [6.989965] rodata_test: test data was not read only and the system doesn't come up completely. If I used a fresh Fedora-Minimal-31 on the Quad-D1 (or the Dual-C1) it works fine. Currently the main difference, as far as I can see, is that there is a different kernel. The working system is running 5.3.7-301.fc31.armv7hl whereas the non-working is running 5.4.17-200.fc31.armv7hl. I am currently working on upgrading the Fedora-Minimal to a more recent kernel to try to reproduce the problem; if it doesn't reproduce I will also try to upgrade the existing system. If it DOES reproduce then clearly there's something with the F25->F31 filesystem, and I will have to migrate everything to a fresh install :( I'll let you know in a couple hours how the testing goes -- unless you've seen this before and have an easy fix? -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Wandboard Quad RevD1 has no Ethernet in Fedora F31?
Hi, On Fri, April 17, 2020 9:07 am, Peter Robinson wrote: > > Yep, I've seen the upstream discussion, I'll test the patches on my > revB1 when I get a moment, I've asked in the community if there's > someone with a revC to test. I suspect with the delays we might well > have another U-Boot build. Any chance you could do a bug report for me > here? FYI, I've got an old Rev C1 Wandboard-Dual and I can verify that this u-boot works there: U-Boot SPL 2020.04-5-g081df7dca7 (Apr 17 2020 - 09:00:31 -0300) Trying to boot from MMC1 U-Boot 2020.04-5-g081df7dca7 (Apr 17 2020 - 09:00:31 -0300) CPU: Freescale i.MX6DL rev1.1 at 792 MHz Reset cause: POR DRAM: 1 GiB MMC: FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0 Loading Environment from MMC... OK No panel detected: default to HDMI Display: HDMI (1024x768) In:serial Out: serial Err: serial Board: Wandboard rev C1 Net: Warning: ethernet@2188000 using MAC address from ROM eth0: ethernet@2188000 -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Wandboard Quad RevD1 has no Ethernet in Fedora F31?
Peter, On Fri, April 17, 2020 9:07 am, Peter Robinson wrote: > Yep, I've seen the upstream discussion, I'll test the patches on my > revB1 when I get a moment, I've asked in the community if there's > someone with a revC to test. I suspect with the delays we might well > have another U-Boot build. Any chance you could do a bug report for me > here? > > https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora=32=uboot-tools Done: https://bugzilla.redhat.com/show_bug.cgi?id=1825247 > Peter -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Wandboard Quad RevD1 has no Ethernet in Fedora F31?
Hi, On Fri, April 17, 2020 8:33 am, Peter Robinson wrote: >> >> >> He saved me hours and sent me files to test and they worked. So he's >> preparing a patch to send to the u-boot list. Hopefully that patch can >> get pulled into Fedora 32? > > We don't tend to build U-Boot once a release goes GA, primarily just > due to lack of resources. That said U-Boot is firmware and completely > independent of the OS, we only build it due to convenience so using a > f33/rawhide build with F-32 OS is completely stable and works just > fine. Understood. Indeed, I pulled down the F32-beta package to run on F31. It's just a bit of a pain that it's not available "immediately" so I will have to remember to manually fix the uboot install ex-post-facto until it gets pulled in.. Actually, not too bad because I only have this one D1 device, so it's just this one time that I will need to do it. But at least we know it'll get into upstream "soon". -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Wandboard Quad RevD1 has no Ethernet in Fedora F31?
Hi, On Thu, April 16, 2020 4:38 pm, Derek Atkins wrote: > Hi, > [snip] >> Actually I suspect that's because it's a different config and hence >> the issue, I suspect once the detection bit is fixed that issue may >> just go away. > > Could be. I'm working with a U-Boot dev right now who sent me two patches > to u-boot to try to fix the detection. So now I get to figure out how to > build u-boot to test it out. > > Pulling down 2020.04 from F32-beta was easy. Building it We'll see! > Can I build it on my x86_64? ;) He saved me hours and sent me files to test and they worked. So he's preparing a patch to send to the u-boot list. Hopefully that patch can get pulled into Fedora 32? -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Wandboard Quad RevD1 has no Ethernet in Fedora F31?
Hi, On Thu, April 16, 2020 3:50 pm, Peter Robinson wrote: >> >> One more thing I just noticed from the uboot output: >> >> >> >> PMIC: pmic_get() ret -19 >> >> >> >> Looking at the commit I sent earlier, this appears to be part of the >> D1 >> >> detection. So what does return code -19 mean? >> > >> > Probably -ENODEV. >> >> Maybe. >> >> Interestingly, I just came across >> https://gitlab.denx.de/u-boot/u-boot/-/tree/master/board%2Fwandboard >> which >> has the following commit message: >> >> Only the wandboard revD1 boards have PMIC, so when running on a >> wandboard >> of different revision the following error is always shown on every boot: >> >> pmic_get() ret -19 >> >> Instead of printing this error message, move it to debug level instead. > > Actually I suspect that's because it's a different config and hence > the issue, I suspect once the detection bit is fixed that issue may > just go away. Could be. I'm working with a U-Boot dev right now who sent me two patches to u-boot to try to fix the detection. So now I get to figure out how to build u-boot to test it out. Pulling down 2020.04 from F32-beta was easy. Building it We'll see! Can I build it on my x86_64? ;) -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Wandboard Quad RevD1 has no Ethernet in Fedora F31?
On Thu, April 16, 2020 2:31 pm, Jeffrey Walton wrote: > On Thu, Apr 16, 2020 at 10:55 AM Derek Atkins wrote: >> >> One more thing I just noticed from the uboot output: >> >> PMIC: pmic_get() ret -19 >> >> Looking at the commit I sent earlier, this appears to be part of the D1 >> detection. So what does return code -19 mean? > > Probably -ENODEV. Maybe. Interestingly, I just came across https://gitlab.denx.de/u-boot/u-boot/-/tree/master/board%2Fwandboard which has the following commit message: Only the wandboard revD1 boards have PMIC, so when running on a wandboard of different revision the following error is always shown on every boot: pmic_get() ret -19 Instead of printing this error message, move it to debug level instead. However, the board is labelled as D1 but isn't acting like a D1. *cries* I wonder if I should email that author directly? > Jeff -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Wandboard Quad RevD1 has no Ethernet in Fedora F31?
Thanks Peter, I've emailed wandboard and I registered for the forum and responded to that thread, so HOPEFULLY I'll get an answer. Very disappointing :( (not with you -- you've been great!) -derek On Thu, April 16, 2020 1:02 pm, Peter Robinson wrote: > On Thu, Apr 16, 2020 at 3:54 PM Derek Atkins wrote: >> >> Peter, >> >> Sorry for inundating your email box! >> One more thing I just noticed from the uboot output: >> >> PMIC: pmic_get() ret -19 >> >> Looking at the commit I sent earlier, this appears to be part of the D1 >> detection. So what does return code -19 mean? > > TBH no idea. > >> -derek >> >> -- >>Derek Atkins 617-623-3745 >>de...@ihtfp.com www.ihtfp.com >>Computer and Internet Security Consultant >> > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Wandboard Quad RevD1 has no Ethernet in Fedora F31?
Peter, Sorry for inundating your email box! One more thing I just noticed from the uboot output: PMIC: pmic_get() ret -19 Looking at the commit I sent earlier, this appears to be part of the D1 detection. So what does return code -19 mean? -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Wandboard Quad RevD1 has no Ethernet in Fedora F31?
Taking a look at the u-boot I've got (running "strings" on the dd image from the first 20MB /dev/mmcblk) I see: strings /tmp/mmc.dat | grep -i wand | grep -i d1 imx6qp-wandboard-revd1 _imx6qp-wandboard-revd1 _imx6qp-wandboard-revd1 imx6qp-wandboard-revd1 Board: Wandboard rev D1 ... So clearly there is some D1 detection going on in u-boot, but it's not working for my instance of the board. :-( -derek On Thu, April 16, 2020 10:30 am, Derek Atkins wrote: > > On Thu, April 16, 2020 10:19 am, Peter Robinson wrote: > >> The proper question is why is Wandboard hostile to upstream by not >> sending their device support upstream. The original commit was by a >> NXP maintainer, but there's been little on the Wandboard stuff at all >> since the addition of the D1 support. > > Another good question. But even looking at the wandboard github stuff, > there doesn't appear to have been any changes since 2015 to the uboot-imx > tree or the u-boot-fslc tree. C.f. https://github.com/wandboard-org > > I feel like they used to be so much better about pushing upstream. Or > maybe the hardware manufacturer made a change without telling the > wandboard crew? > > I find it odd that github is showing 2015 when there were clearly changed > in 2017? I'm confused. > > Okay, I was looking at an old branch. There is a 2017 branch which has a > commit to add D1 to u-boot: > https://github.com/wandboard-org/uboot-imx/commit/978c09eb0d49dba37b86c23e61bc50fb1b72dc00 > > Of course I don't know if this commit ever made it upstream? > > -derek > > -- >Derek Atkins 617-623-3745 >de...@ihtfp.com www.ihtfp.com >Computer and Internet Security Consultant > ___ > 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 > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Wandboard Quad RevD1 has no Ethernet in Fedora F31?
On Thu, April 16, 2020 10:19 am, Peter Robinson wrote: > The proper question is why is Wandboard hostile to upstream by not > sending their device support upstream. The original commit was by a > NXP maintainer, but there's been little on the Wandboard stuff at all > since the addition of the D1 support. Another good question. But even looking at the wandboard github stuff, there doesn't appear to have been any changes since 2015 to the uboot-imx tree or the u-boot-fslc tree. C.f. https://github.com/wandboard-org I feel like they used to be so much better about pushing upstream. Or maybe the hardware manufacturer made a change without telling the wandboard crew? I find it odd that github is showing 2015 when there were clearly changed in 2017? I'm confused. Okay, I was looking at an old branch. There is a 2017 branch which has a commit to add D1 to u-boot: https://github.com/wandboard-org/uboot-imx/commit/978c09eb0d49dba37b86c23e61bc50fb1b72dc00 Of course I don't know if this commit ever made it upstream? -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Wandboard Quad RevD1 has no Ethernet in Fedora F31?
On Thu, April 16, 2020 10:01 am, Peter Robinson wrote: >> >> So where is this Rev B1 coming from? Why does it not know it's a Rev D1 >> board? This is clearly causing it to pull in the wrong DTB file, which >> explains why it isn't working. > > It's the last option in the statement check in board detection which > means it's basically the board of last resort. so it seems your rev of > the D1 isn't being detected, there was initial support for the revD1 > land upstream in U-Boot in Oct 2017. *sigh* I acquired this board only a few months ago. I tried doing a "setenv" within uboot to change the board-name from B1 to D1 but obviously that didn't do anything since I think it needs to be detected earlier than that. So this requires a change to u-boot? I must admit that I've never looked at uboot code so not even sure where to start to see where I would need to add something for my board, let along figure out what it is I need to add. (Well, I suppose once I figure out what it's looking for I can hopefully probe the board to figure out what it's saying). Why can't they make this easy? :( -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Wandboard Quad RevD1 has no Ethernet in Fedora F31?
AHA. The plot thickens.. The board says "D1" written on it, but when I boot it up I get this output which seems to say it thinks its a B1 board: U-Boot SPL 2019.10 (Oct 09 2019 - 00:00:00 +) Trying to boot from MMC1 U-Boot 2019.10 (Oct 09 2019 - 00:00:00 +) CPU: Freescale i.MX6Q rev1.3 at 792 MHz Reset cause: POR DRAM: 2 GiB PMIC: pmic_get() ret -19 MMC: FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment No panel detected: default to HDMI Display: HDMI (1024x768) In:serial Out: serial Err: serial Model: Wandboard i.MX6 Quad Board rev B1 Board: Wandboard rev B1 Net: Board Net Initialization Failed No ethernet found. . [snip] append: console=ttymxc0,115200 console=tty0 ro root=UUID=b0abeeb4-7c58-4b29-9c8 Retrieving file: /dtb-5.3.7-301.fc31.armv7hl/imx6q-wandboard-revb1.dtb So where is this Rev B1 coming from? Why does it not know it's a Rev D1 board? This is clearly causing it to pull in the wrong DTB file, which explains why it isn't working. -derek On Thu, April 16, 2020 9:17 am, Derek Atkins wrote: > From that website I posted, I found this in a post by Jaime » Wed May 31, > 2017 3:59 pm: > > There is a new dtsi "imx6qdl-wandboard-revd1.dtsi" what contents pinout > changes, ethernet power driving, and others > https://github.com/TechNexion/linux/blo ... revd1.dtsi > https://github.com/wandboard-org/linux/ ... revd1.dtsi > > Apparently on the RevD1 you have to explicitly power on the Ethernet, > which apparently isn't happening? > > NB: these two links are: > https://github.com/TechNexion/linux/blob/tn-imx_4.1.15_2.0.0_ga/arch/arm/boot/dts/imx6qdl-wandboard-revd1.dtsi > https://github.com/wandboard-org/linux/blob/wandboard_imx_4.1.15_1.1.0_ga/arch/arm/boot/dts/imx6qdl-wandboard-revd1.dtsi > > -derek > > On Thu, April 16, 2020 9:10 am, Derek Atkins wrote: >> HI, >> >> On Thu, April 16, 2020 4:21 am, Peter Robinson wrote: >>> Hi Derek, >>> >>>> I just acquired a wandboard quad rev d1 (to replace an older >>>> dual-core >>>> model), but apparently even though there is a revd1 DTB tree, the >>>> ethernet >>>> still isn't working. >>> >>> I have a Wandboard Quad B1 and ethernet works, I know others have >>> other >>> revs. >> >> Me too. It's the D1 that doesn't work. Strangely I can plug the same >> SD >> card into the B1 and it works, whereas in the D1 it does not. So there >> is >> something strange going on. >> >>>> According to http://forums.wandboard.org/viewtopic.php?t=1460 this >>>> issue >>>> should have been fixed a couple years ago. Is there something >>>> special >>>> I >>>> need to do to get fedora working on this board? >>> >>> I'm not sure the context of where that is fixed as I wasn't sure of >>> where it was fixed. I suspect it was maybe in their downstream kernel >>> fork. We only use upstream/mainline kernels. >> >> I dont know. >> >>> So for the vast majority of device support we rely on things being >>> upstream, both in the linux kernel and in firmware like U-Boot. We >>> don't have the resources to upstream everything and follow downstream >>> problems/fixes for every random device. >> >> Right, as we should expect. I'm surprised that a proposed change from >> 2017/2018 hasn't made it into mainline in 2-3 years! >> >>> Looking at the upstream changes for the D1 specific rev I see the >>> following since the D1 one support landed, nothing about network >>> issues. >>> >>> So looking quickly at the post you mention, and looking at the >>> upstream kernel commits back to when D1 support landed to 5.7-rc1 >>> there doesn't look to be anything network related: >>> 404c0c9314f4 ARM: dts: imx6qdl: Fix memory node duplication >>> d9359f580797 ARM: dts: imx6qdl-wandboard: Switch to SPDX identifier >>> 5dda6159aaab ARM: dts: imx6qdl-wandboard: Switch to SPDX identifier >>> 6e1386b2ee68 ARM: dts: imx6qdl-wandboard: Let the codec control MCLK >>> pinctrl >>> ad00e080eb75 ARM: dts: imx: Add memory node unit name >>> 74fe676cb518 ARM: dts: imx6qdl-wandboard-revd1: Make EDID functional >>> 7721dce68a30 ARM: dts: imx6qp-wandboard-revd1: Add sata support >>> d016b46ac959 ARM: dts: imx6qdl-wandboard: Add support for the revd1 >>> variants >> >> So where does this leave us? I am not at all sure where the problem >> lays. >> I don't know if it's a GPIO issue or something else?
[fedora-arm] Re: Wandboard Quad RevD1 has no Ethernet in Fedora F31?
From that website I posted, I found this in a post by Jaime » Wed May 31, 2017 3:59 pm: There is a new dtsi "imx6qdl-wandboard-revd1.dtsi" what contents pinout changes, ethernet power driving, and others https://github.com/TechNexion/linux/blo ... revd1.dtsi https://github.com/wandboard-org/linux/ ... revd1.dtsi Apparently on the RevD1 you have to explicitly power on the Ethernet, which apparently isn't happening? NB: these two links are: https://github.com/TechNexion/linux/blob/tn-imx_4.1.15_2.0.0_ga/arch/arm/boot/dts/imx6qdl-wandboard-revd1.dtsi https://github.com/wandboard-org/linux/blob/wandboard_imx_4.1.15_1.1.0_ga/arch/arm/boot/dts/imx6qdl-wandboard-revd1.dtsi -derek On Thu, April 16, 2020 9:10 am, Derek Atkins wrote: > HI, > > On Thu, April 16, 2020 4:21 am, Peter Robinson wrote: >> Hi Derek, >> >>> I just acquired a wandboard quad rev d1 (to replace an older dual-core >>> model), but apparently even though there is a revd1 DTB tree, the >>> ethernet >>> still isn't working. >> >> I have a Wandboard Quad B1 and ethernet works, I know others have other >> revs. > > Me too. It's the D1 that doesn't work. Strangely I can plug the same SD > card into the B1 and it works, whereas in the D1 it does not. So there > is > something strange going on. > >>> According to http://forums.wandboard.org/viewtopic.php?t=1460 this >>> issue >>> should have been fixed a couple years ago. Is there something special >>> I >>> need to do to get fedora working on this board? >> >> I'm not sure the context of where that is fixed as I wasn't sure of >> where it was fixed. I suspect it was maybe in their downstream kernel >> fork. We only use upstream/mainline kernels. > > I dont know. > >> So for the vast majority of device support we rely on things being >> upstream, both in the linux kernel and in firmware like U-Boot. We >> don't have the resources to upstream everything and follow downstream >> problems/fixes for every random device. > > Right, as we should expect. I'm surprised that a proposed change from > 2017/2018 hasn't made it into mainline in 2-3 years! > >> Looking at the upstream changes for the D1 specific rev I see the >> following since the D1 one support landed, nothing about network >> issues. >> >> So looking quickly at the post you mention, and looking at the >> upstream kernel commits back to when D1 support landed to 5.7-rc1 >> there doesn't look to be anything network related: >> 404c0c9314f4 ARM: dts: imx6qdl: Fix memory node duplication >> d9359f580797 ARM: dts: imx6qdl-wandboard: Switch to SPDX identifier >> 5dda6159aaab ARM: dts: imx6qdl-wandboard: Switch to SPDX identifier >> 6e1386b2ee68 ARM: dts: imx6qdl-wandboard: Let the codec control MCLK >> pinctrl >> ad00e080eb75 ARM: dts: imx: Add memory node unit name >> 74fe676cb518 ARM: dts: imx6qdl-wandboard-revd1: Make EDID functional >> 7721dce68a30 ARM: dts: imx6qp-wandboard-revd1: Add sata support >> d016b46ac959 ARM: dts: imx6qdl-wandboard: Add support for the revd1 >> variants > > So where does this leave us? I am not at all sure where the problem > lays. > I don't know if it's a GPIO issue or something else? But when I plug > the > Rev D1 board in the ethernet lights do not light up at all, as if it's > not > being powered on. And of course "ip addr" claims "NO CARRIER" for eth0. > > Any idea how I can (help) debug this? > > -derek > > -- >Derek Atkins 617-623-3745 >de...@ihtfp.com www.ihtfp.com >Computer and Internet Security Consultant > ___ > 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 > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Wandboard Quad RevD1 has no Ethernet in Fedora F31?
HI, On Thu, April 16, 2020 4:21 am, Peter Robinson wrote: > Hi Derek, > >> I just acquired a wandboard quad rev d1 (to replace an older dual-core >> model), but apparently even though there is a revd1 DTB tree, the >> ethernet >> still isn't working. > > I have a Wandboard Quad B1 and ethernet works, I know others have other > revs. Me too. It's the D1 that doesn't work. Strangely I can plug the same SD card into the B1 and it works, whereas in the D1 it does not. So there is something strange going on. >> According to http://forums.wandboard.org/viewtopic.php?t=1460 this issue >> should have been fixed a couple years ago. Is there something special I >> need to do to get fedora working on this board? > > I'm not sure the context of where that is fixed as I wasn't sure of > where it was fixed. I suspect it was maybe in their downstream kernel > fork. We only use upstream/mainline kernels. I dont know. > So for the vast majority of device support we rely on things being > upstream, both in the linux kernel and in firmware like U-Boot. We > don't have the resources to upstream everything and follow downstream > problems/fixes for every random device. Right, as we should expect. I'm surprised that a proposed change from 2017/2018 hasn't made it into mainline in 2-3 years! > Looking at the upstream changes for the D1 specific rev I see the > following since the D1 one support landed, nothing about network > issues. > > So looking quickly at the post you mention, and looking at the > upstream kernel commits back to when D1 support landed to 5.7-rc1 > there doesn't look to be anything network related: > 404c0c9314f4 ARM: dts: imx6qdl: Fix memory node duplication > d9359f580797 ARM: dts: imx6qdl-wandboard: Switch to SPDX identifier > 5dda6159aaab ARM: dts: imx6qdl-wandboard: Switch to SPDX identifier > 6e1386b2ee68 ARM: dts: imx6qdl-wandboard: Let the codec control MCLK > pinctrl > ad00e080eb75 ARM: dts: imx: Add memory node unit name > 74fe676cb518 ARM: dts: imx6qdl-wandboard-revd1: Make EDID functional > 7721dce68a30 ARM: dts: imx6qp-wandboard-revd1: Add sata support > d016b46ac959 ARM: dts: imx6qdl-wandboard: Add support for the revd1 > variants So where does this leave us? I am not at all sure where the problem lays. I don't know if it's a GPIO issue or something else? But when I plug the Rev D1 board in the ethernet lights do not light up at all, as if it's not being powered on. And of course "ip addr" claims "NO CARRIER" for eth0. Any idea how I can (help) debug this? -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Wandboard Quad RevD1 has no Ethernet in Fedora F31?
Hi, I just acquired a wandboard quad rev d1 (to replace an older dual-core model), but apparently even though there is a revd1 DTB tree, the ethernet still isn't working. According to http://forums.wandboard.org/viewtopic.php?t=1460 this issue should have been fixed a couple years ago. Is there something special I need to do to get fedora working on this board? I installed Fedora-Minimal-armhfp-31-1.9-sda.raw.xz and it boots but the ethernet shows "no carrier" when I run "ip addr". :-( -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: [fedora-arm](resend) Trying to run Fedora-Minimal-31 under QEMU on Fedora 29
Paul, Paul Whalen writes: > Refreshed the files used for F31 (image name and kernel version). It > should now just work but do let us know if I missed anything. The page looks good, and it appears to be working. Unfortunately (for me) a compile is slower on qemu on my x86_64 than it is on my Wandboard (quad-core) hardware! However the build takes more space than I have on the wandboard, so I have to live with it running slower in qemu. Even more unfortunately for me, my office lost power overnight and my laptop crashed, which means I needed to restart the build again. Maybe I'll get this build completed by the end of the week!!! Quick question: it appears that my qemu device never sees more than 3GB of RAM, regardless of what I have configured in virt-manager. Is there a way to get the kernel to recognize more RAM? Thanks, -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: [fedora-arm](resend) Trying to run Fedora-Minimal-31 under QEMU on Fedora 29
OOOH, never mind! I was just impatient! I just got the Initial Boot menu and was able to set the root password. YAY. Thanks! -derek On Fri, February 7, 2020 12:04 pm, Derek Atkins wrote: > Paul, > > On Fri, February 7, 2020 11:42 am, Paul Whalen wrote: >> Hi Derek, >> > [snip] >>> I never get asked to set a password. I never get a login screen. >>> >>> I just found a reference to an older web page about QEMU and ARM: >>> https://fedoraproject.org/wiki/Architectures/ARM/HowToQemu but this >>> page >>> was last touched in 2016. >>> >>> Any assistance would be grand. >> >> This page should still work - >> https://fedoraproject.org/wiki/QA:Testcase_Virt_ARM_on_x86 >> >> It was updated last year so it needs a refresh- but I dont think >> anything >> has changed. > > Aha, thanks. I changed to virt-2.11 (there's a virt-2.12 which I believe > I could have used as well according to > https://bugzilla.redhat.com/show_bug.cgi?id=1633328 > > Now it seems to get a LITTLE further. It goes to "Reached target Basic > System" and then it started: > NTP > firewalld > "Iniital Setup configuration program" > Hardware RNG EGD > OpenSSH key gen (ecdsa, ed25519, rsa) > System Security Services Daemon > > But now it appears to be hanging. I don't see anything else now. :( > > I suppose I can reset the image again and see if that makes a difference? > Do I *NEED* the console=ttyAMA0 to get a login prompt on the virt-manager > console? > > Thanks, > >> Paul > > -derek > > -- >Derek Atkins 617-623-3745 >de...@ihtfp.com www.ihtfp.com >Computer and Internet Security Consultant > > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: [fedora-arm](resend) Trying to run Fedora-Minimal-31 under QEMU on Fedora 29
Paul, On Fri, February 7, 2020 11:42 am, Paul Whalen wrote: > Hi Derek, > [snip] >> I never get asked to set a password. I never get a login screen. >> >> I just found a reference to an older web page about QEMU and ARM: >> https://fedoraproject.org/wiki/Architectures/ARM/HowToQemu but this >> page >> was last touched in 2016. >> >> Any assistance would be grand. > > This page should still work - > https://fedoraproject.org/wiki/QA:Testcase_Virt_ARM_on_x86 > > It was updated last year so it needs a refresh- but I dont think anything > has changed. Aha, thanks. I changed to virt-2.11 (there's a virt-2.12 which I believe I could have used as well according to https://bugzilla.redhat.com/show_bug.cgi?id=1633328 Now it seems to get a LITTLE further. It goes to "Reached target Basic System" and then it started: NTP firewalld "Iniital Setup configuration program" Hardware RNG EGD OpenSSH key gen (ecdsa, ed25519, rsa) System Security Services Daemon But now it appears to be hanging. I don't see anything else now. :( I suppose I can reset the image again and see if that makes a difference? Do I *NEED* the console=ttyAMA0 to get a login prompt on the virt-manager console? Thanks, > Paul -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm](resend) Trying to run Fedora-Minimal-31 under QEMU on Fedora 29
(sorry if you get this twice -- I wasn't subscribed with this address so I think my message was held for moderation or just blocked) Hi, I've got an x86_64 F29 desktop and I'm trying to run Fedora-Minimal-31 ARM on QEMU. I was following the instructions in the various F25/26/27 "run on QEMU" pages and I've been able to get the system to boot under virt-manager, but once it gets to "Reached Basic System" in the virt-manager console, it stops and never reaches the first-boot setting. I never get asked to set a password. I never get a login screen. I just found a reference to an older web page about QEMU and ARM: https://fedoraproject.org/wiki/Architectures/ARM/HowToQemu but this page was last touched in 2016. Any assistance would be grand. Thanks! -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ 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
[fedora-arm] Re: Random entropy difference between F26 workstation and minimal server
Robert Moskowitz <r...@htt-consult.com> writes: >>> What is different between these two images? It is the same Cubieboard. >> Different images have different services enabled by default, is >> rng-tools intsalled by default on server image? > > Just checked and > > Package rng-tools-5-9.fc26.armv7hl is already installed But is rngd actually running? > And after running dnf, entropy dropped to 324 Hmm. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org
[fedora-arm] Cross-compiling to Fedora ARM using mock on x86_64?
Hi, I'm looking at building some packages for Fedora ARM. Is there any way I can use mock on my x86_64 system to cross-compile a package for ARM? I'm on Fedora 25, but I'm not seeing any cross-compiler options in mock. If I set arch or target I still get an error that x86_64 is not a valid platform to build for arm. A good search seems to show some work done back in 2010 for Fedora 10, but that's 7-year-old code which I suspect wont work with modern stuff. So what's the best way (short of building the packages on my poor low-powered ARM system) to get some packages built. E.g. python-crcmod. Thanks, -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list -- arm@lists.fedoraproject.org To unsubscribe send an email to arm-le...@lists.fedoraproject.org
[fedora-arm] Sound issue on Wandboard Quad: snd_soc_register_card failed (-517)
Hi, I've got a few wandboards in production, but recently one of my boards starting having issues with the onboard sound card/port. I'm no longer getting any sound out of it (although my USB sound device works fine). The dmesg logs report: # dmesg | grep snd [ 11.207229] fsl-asoc-card sound: snd_soc_register_card failed (-517) [ 11.220649] imx-spdif sound-spdif: snd_soc_register_card failed: -517 [ 11.220667] fsl-asoc-card sound: snd_soc_register_card failed (-517) [ 11.292754] imx-spdif sound-spdif: snd_soc_register_card failed: -517 [ 11.339059] imx-spdif sound-spdif: snd_soc_register_card failed: -517 [ 11.357732] imx-spdif sound-spdif: snd_soc_register_card failed: -517 [ 11.384978] imx-spdif sound-spdif: snd-soc-dummy-dai <-> 2004000.spdif mapping ok I just updated to current FC22, now running 4.4.4-200.fc22.armv7hl (from 4.1.6), and after rebooting the system I get the same dmesg results. I tried power-cycling and I still got the same results. For the record, my wandboard single, also running FC22 (but running kernel 4.1.7) does not appear to be having this same issue. Strangely, the system in question had been working a while ago, but I only noticed the issue recently. A quick google talks about the clock not being started or a race condition of some sort? Anyone have any ideas? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: Wandboard Quad network dies under load?
Hi Sean, Sean Omalley <omalle...@rocketmail.com> writes: > Hi Derek, > >>Well, I'm (now) running the current F23 release .. and I'm testing it >>now. I should know in an hour or two if there's an issue. Is there >>something I need to turn on to see the debug log issue? I should note > >>this is wired ethernet, not wifi, where it stops talking to the net. > > I saw a bug with the atheros ethernet driver as well, which had > different symptoms. > The portion of the code that goes into an infinite loop for me has > debugging that spews to the log files. (bool > ath9k_hw_stopdmarecv(struct ath_hw *ah, bool *reset)) > However, if your driver doesn't do that, it would not show up anywhere.. :) > > >>I doubt it's a cabling issue -- I have this issue on two different >>boards located different places in my house connected via different >>cables to different switches. The only common factor is Wandboard Quad >>and high data transmission from the WB-Q. > > It may not be. In fact, it all might be a red herring... > > It might be a bad setting in the device tree between the version of > the wandboard you have, they apparently use two different FEC chips. > > Also, you might take a poke at this too if you haven't seen it: > > https://boundarydevices.com/i-mx6-ethernet/ > > I am leaning toward something that changed that broke a few things and > I am guessing it isn't arm specific. As I just mentioned in my response to Peter, upgrading to 4.4.3-300.fc23.armv7hl significantly helped. My backup lasted 18+ hours before it died, and it only died because I ran a "du -sh" simultaneously. Granted, that shouldn't have put it over the edge either, but when I was running 4.2.3 backup only lasted 2-4 hours before dying on its own. So 4.4.3 is definitely an improvement. > Sean -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: Wandboard Quad network dies under load?
Hi Peter, Peter Robinson <pbrobin...@gmail.com> writes: >> I'm having an issue with two different wandboard quad systems; one is >> running F22, the other is running F23. When the system is under high >> network load, specifically high transmit load, after a while the network >> just gives up. Technically it's not VERY high load, only about 2MB/s, >> but it's high transmit load -- high download load seems to be fine as >> far as I can tell. I know that "gives up" isn't a very technical term, >> but I frankly don't know what else to call it. > > Rev B or C? The one I'm working on right now says Rev C1. I don't know the rev of the other one -- I'd have to go open it up to see. I can do that if you want the answer, but it's actually my production mythtv backend (and still running F22) so I can't really run a bunch of tests on that. >> After I do this the system has network again. However it's quite >> frustrating that I have to go through all these hoops. Note that just >> pulling the network cable by itself does not seem sufficient to reset >> the network. > > what happens if you "rmmod fec; sleep 5; modprobe fec" does that have > the same effect as all of the above? Mostly, yes. I had to run: ifconfig eth0 down; rmmod fec; sleep 5; modprove fec (without the ifconfig down the rmmod didn't work). But that did bring it back to life. I should note that as of about 5:30am I was going to respond to Sean and say that "the upgrade to 4.4.3-300.fc23.armv7hl fixed it." However while it IS better (lasting about 18 hours versus 2-4) , it did eventually die around 6:30am (when I manually ran a du -sh to see how much of the backup had completed in 18 hours). So clearly something between 4.2.3 and 4.4.3 improved the situation, but didn't completely correct it. >> Is this a hardware problem or a software problem (or a combination of >> the two)? I've had it happen on this one system three times today; I >> can definitely reliably repeat it (although it does take a couple hours >> until it dies). It's also happened on another system, but I've not seen >> it happen since I stopped pulling data from it. > > If it's the former it should be able to be worked around with the > later. I've not seen it but then I don't use my WBQ for high load. The > i.MX6 onboard NICs do have a through put issue in that they can't do > line speed Gbit, but rather top out around 450mbps (if memory serves) > but that shouldn't affect stability. Right now I think I'm CPU bound via encfs running AES so I think it's fine that I can't hit the full 1Gbps. However I suspect the current set of ARM solutions available might not be the right platform for my backup server. Although openssl speed on my Wandboard says I should be getting 20MB/s, I appear to only be getting about 1MB/s. (My laptop seems to be able to do about 100MB/s according to openssl -- strangely "openssl engine" does not report "aesni" on my F23 x86_64 laptop). > Peter -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: Wandboard Quad network dies under load?
Hi Sean, Well, I'm (now) running the current F23 release .. and I'm testing it now. I should know in an hour or two if there's an issue. Is there something I need to turn on to see the debug log issue? I should note this is wired ethernet, not wifi, where it stops talking to the net. I doubt it's a cabling issue -- I have this issue on two different boards located different places in my house connected via different cables to different switches. The only common factor is Wandboard Quad and high data transmission from the WB-Q. Thanks, -derek Sean Omalley <omalle...@rocketmail.com> writes: > Derek, > > I was/am having similar issues with the atheros wireless drivers on x86_64. > The DMA stuff was kicking in for some reason. Yesterdays update mostly cleared > it up for me (it was once every 45 minutes, it is down to once a day) as near > as I can tell. My issue sounds very similar to yours, but it has been going on > for like 6 kernel updates. > > I was lucky, there is a patch for debugging they added to the dma stop > function, which actually logged. There may not be the equivalent in your > driver. > > Otherwise, IIRC, when I was working with the pogoplug, I did have an issue > with duplex settings that kept flaking out. Where the switch would go into > half duplex mode on a whim. Changing the cable, even though it worked, fixed > it. I think it was like "microfractures" in the wire. It may also have ended > up on a different port on the switch. That is the type of stuff that usually > happens under high loads. I haven't looked at the freescale FEC chip or > driver. > > Sean > > ------ > From: Derek Atkins <warl...@mit.edu> > To: arm@lists.fedoraproject.org > Sent: Friday, March 4, 2016 11:01 PM > Subject: [fedora-arm] Wandboard Quad network dies under load? > > Hi, > > I'm having an issue with two different wandboard quad systems; one is > running F22, the other is running F23. When the system is under high > network load, specifically high transmit load, after a while the network > just gives up. Technically it's not VERY high load, only about 2MB/s, > but it's high transmit load -- high download load seems to be fine as > far as I can tell. I know that "gives up" isn't a very technical term, > but I frankly don't know what else to call it. > > * dmesg doesn't say anything about the link going down > * ifconfig shows the interface still has an IP address > * arp, however, seems to start failing (and my NFS server has an > incomplete arp address) > * ping doesn't work to anywhere (regardless of the contents of the arp > table) > * DNS doesn't work (obviously -- no packets are coming or going). > > I can usually recover by doing: > > nmcli con down "Wired connection 1" > nmcli con up "Wired connection 1" > > (the 'up' results in the message "Error: Connection activation failed.") > After that I need to pull the ethernet plug, count to 5-10, and then > plug it in again. Then I'll get the messages: > > [30540.554006] fec 2188000.ethernet eth0: Link is Down > [30553.558837] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow > contro > > (sorry for the cut messages; minicom serial console doesn't wrap lines) > > After I do this the system has network again. However it's quite > frustrating that I have to go through all these hoops. Note that just > pulling the network cable by itself does not seem sufficient to reset > the network. > > Is this a hardware problem or a software problem (or a combination of > the two)? I've had it happen on this one system three times today; I > can definitely reliably repeat it (although it does take a couple hours > until it dies). It's also happened on another system, but I've not seen > it happen since I stopped pulling data from it. > > Any suggestions? I'd like to not have to go out and spend more money to > buy an Atom-based solution, even though it might be better for my use > case due to AES-NI. > > Thanks, > > -derek > > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IAN1NWH > warl...@mit.eduPGP key available > ___ > arm mailing list > arm@lists.fedoraproject.org >
[fedora-arm] Re: F23 on Wandboard Quad -- kernel doesn't start?
"Jared K. Smith" <jsm...@fedoraproject.org> writes: > On Fri, Mar 4, 2016 at 10:40 AM, Derek Atkins <warl...@mit.edu> wrote: > > I guess it serves me right for not updating that script. I'm still > using 0.06 (plus some changes to support wandboard on f23). But it > still would've been nice to have at least a one-liner on the wiki :) > > The wiki is just that -- a wiki. if you think something needs to be added to > it, do it! That implies having a FAS account, which I don't. Faster for me to suggest a change than get one set up. > Jared Smith -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Wandboard Quad network dies under load?
Hi, I'm having an issue with two different wandboard quad systems; one is running F22, the other is running F23. When the system is under high network load, specifically high transmit load, after a while the network just gives up. Technically it's not VERY high load, only about 2MB/s, but it's high transmit load -- high download load seems to be fine as far as I can tell. I know that "gives up" isn't a very technical term, but I frankly don't know what else to call it. * dmesg doesn't say anything about the link going down * ifconfig shows the interface still has an IP address * arp, however, seems to start failing (and my NFS server has an incomplete arp address) * ping doesn't work to anywhere (regardless of the contents of the arp table) * DNS doesn't work (obviously -- no packets are coming or going). I can usually recover by doing: nmcli con down "Wired connection 1" nmcli con up "Wired connection 1" (the 'up' results in the message "Error: Connection activation failed.") After that I need to pull the ethernet plug, count to 5-10, and then plug it in again. Then I'll get the messages: [30540.554006] fec 2188000.ethernet eth0: Link is Down [30553.558837] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full - flow contro (sorry for the cut messages; minicom serial console doesn't wrap lines) After I do this the system has network again. However it's quite frustrating that I have to go through all these hoops. Note that just pulling the network cable by itself does not seem sufficient to reset the network. Is this a hardware problem or a software problem (or a combination of the two)? I've had it happen on this one system three times today; I can definitely reliably repeat it (although it does take a couple hours until it dies). It's also happened on another system, but I've not seen it happen since I stopped pulling data from it. Any suggestions? I'd like to not have to go out and spend more money to buy an Atom-based solution, even though it might be better for my use case due to AES-NI. Thanks, -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: F23 on Wandboard Quad -- kernel doesn't start?
Hi Peter, Peter Robinson <pbrobin...@gmail.com> writes: > On Thu, Mar 3, 2016 at 9:53 PM, Nicolas Chauvet <kwiz...@gmail.com> wrote: > >> If you are on serial you might need to add console=ttymxc0,115200 to the >> kernel bootlinux in extlinux.conf >> I never tried to boot using hdmi output, so I usually need to add console >> > > Recent arm-image-installer has a --addconsole option to do that for you. I guess it serves me right for not updating that script. I'm still using 0.06 (plus some changes to support wandboard on f23). But it still would've been nice to have at least a one-liner on the wiki :) > Peter -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: F23 on Wandboard Quad -- kernel doesn't start?
Nicolas Chauvet <kwiz...@gmail.com> writes: > 2016-03-03 21:51 GMT+01:00 Derek Atkins <warl...@mit.edu>: > > Hi, > > I'm trying to run F23 on a Wandboard Quad, but it's not booting. It > hangs after the "Starting kernel" output. > > I followed the instructions at > > https://fedoraproject.org/wiki/Architectures/ARM/F23/Installation#For_the_Wandboard_.28Freescale_i.MX6.29 > starting from Fedora-Minimal-armhfp-23-10-sda.raw.xz I installed the > > If you are on serial you might need to add console=ttymxc0,115200 to the > kernel bootlinux in extlinux.conf > I never tried to boot using hdmi output, so I usually need to add console > there. Aha. Thank you. This is exactly what I needed. I didn't see this anywhere on the F23 wiki page, and I didn't need it for F22, 21, or 20, so this IS a change in default behavior. Perhaps this suggestion should be added somewhere on the wiki: https://fedoraproject.org/wiki/Architectures/ARM/F23/Installation > Nicolas (kwizart) -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] F23 on Wandboard Quad -- kernel doesn't start?
Hi, I'm trying to run F23 on a Wandboard Quad, but it's not booting. It hangs after the "Starting kernel" output. I followed the instructions at https://fedoraproject.org/wiki/Architectures/ARM/F23/Installation#For_the_Wandboard_.28Freescale_i.MX6.29 starting from Fedora-Minimal-armhfp-23-10-sda.raw.xz I installed the image, then copied in the SPL and u-boot.img. But when I try to boot my wandboard I get: U-Boot SPL 2015.07 (Sep 12 2015 - 11:53:19) U-Boot 2015.07 (Sep 12 2015 - 11:53:19 +) CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) Reset cause: POR Board: Wandboard rev C1 I2C: ready DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 *** Warning - bad CRC, using default environment No panel detected: default to HDMI Display: HDMI (1024x768) In:serial Out: serial Err: serial Net: FEC [PRIME] Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found /extlinux/extlinux.conf Retrieving file: /extlinux/extlinux.conf 518 bytes read in 49 ms (9.8 KiB/s) Ignoring unknown command: ui Ignoring malformed menu command: autoboot Ignoring malformed menu command: hidden Ignoring unknown command: totaltimeout Fedora-Minimal-armhfp-23-10 Boot Options. 1: Fedora-Minimal-armhfp-23-10 (4.2.3-300.fc23.armv7hl) Enter choice: 1:Fedora-Minimal-armhfp-23-10 (4.2.3-300.fc23.armv7hl) Retrieving file: /initramfs-4.2.3-300.fc23.armv7hl.img 38958034 bytes read in 1833 ms (20.3 MiB/s) Retrieving file: /vmlinuz-4.2.3-300.fc23.armv7hl 5811776 bytes read in 307 ms (18.1 MiB/s) append: enforcing=0 ro root=UUID=b2c019d9-2401-4a22-9a40-36a92a00cdfe Retrieving file: /dtb-4.2.3-300.fc23.armv7hl/imx6q-wandboard.dtb 30792 bytes read in 1235 ms (23.4 KiB/s) Kernel image @ 0x1100 [ 0x00 - 0x58ae40 ] ## Flattened Device Tree blob at 1800 Booting using the fdt blob at 0x1800 Loading Ramdisk to 2dad8000, end 23d2 ... OK Loading Device Tree to 2dacd000, end 2dad7847 ... OK Starting kernel ... And then the system just sits and hangs.. Is this a known problem? I tried with two different SD cards and both fail. I could certainly revert back to F22, but why start 6-months behind? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Re: NFS server processes spinning?
FYI, I reported this as https://bugzilla.redhat.com/show_bug.cgi?id=1313480 -derek Derek Atkins <warl...@mit.edu> writes: > Hi, > > I've got a Wandboard Quad running Fedora 22 (current as of yesterday). > This box is a MythTV backend. It's also running an NFS server to serve > the 2 TB Sata drive connected to store my recordings. > > I noticed that the nfs server processes are spinning, even when there > are no clients attached. Here's an output from top: > > top - 16:19:30 up 23:36, 1 user, load average: 2.79, 2.75, 2.66 > Tasks: 118 total, 5 running, 113 sleeping, 0 stopped, 0 zombie > %Cpu(s): 0.3 us, 38.5 sy, 0.0 ni, 40.7 id, 0.0 wa, 0.0 hi, 20.6 si, 0.0 > st > KiB Mem : 2064876 total,62132 free,73572 used, 1929172 buff/cache > KiB Swap: 249852 total, 249432 free, 420 used. 1935800 avail Mem > > PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND > > 1024 root 20 0 0 0 0 R 77.6 0.0 1154:25 nfsd > > 1023 root 20 0 0 0 0 R 76.6 0.0 1150:27 nfsd > > 3 root 20 0 0 0 0 R 47.4 0.0 602:37.59 > ksoftirqd/0 >60 root 20 0 0 0 0 R 13.8 0.0 36:23.26 kswapd0 > > 981 root 20 0 356948 29000 18440 S 4.6 1.4 158:47.23 > mythbackend >13 root 20 0 0 0 0 S 1.0 0.0 10:25.97 > ksoftirqd/1 >18 root 20 0 0 0 0 S 1.0 0.0 9:19.12 > ksoftirqd/2 > 8556 root 20 08908 3556 3060 R 1.0 0.2 0:00.16 top > > > Any idea why NFS is spinning like this? I haven't noticed this on my > x86-based Fedora servers. > > -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] NFS server processes spinning?
Hi, I've got a Wandboard Quad running Fedora 22 (current as of yesterday). This box is a MythTV backend. It's also running an NFS server to serve the 2 TB Sata drive connected to store my recordings. I noticed that the nfs server processes are spinning, even when there are no clients attached. Here's an output from top: top - 16:19:30 up 23:36, 1 user, load average: 2.79, 2.75, 2.66 Tasks: 118 total, 5 running, 113 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.3 us, 38.5 sy, 0.0 ni, 40.7 id, 0.0 wa, 0.0 hi, 20.6 si, 0.0 st KiB Mem : 2064876 total,62132 free,73572 used, 1929172 buff/cache KiB Swap: 249852 total, 249432 free, 420 used. 1935800 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 1024 root 20 0 0 0 0 R 77.6 0.0 1154:25 nfsd 1023 root 20 0 0 0 0 R 76.6 0.0 1150:27 nfsd 3 root 20 0 0 0 0 R 47.4 0.0 602:37.59 ksoftirqd/0 60 root 20 0 0 0 0 R 13.8 0.0 36:23.26 kswapd0 981 root 20 0 356948 29000 18440 S 4.6 1.4 158:47.23 mythbackend 13 root 20 0 0 0 0 S 1.0 0.0 10:25.97 ksoftirqd/1 18 root 20 0 0 0 0 S 1.0 0.0 9:19.12 ksoftirqd/2 8556 root 20 08908 3556 3060 R 1.0 0.2 0:00.16 top Any idea why NFS is spinning like this? I haven't noticed this on my x86-based Fedora servers. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ arm mailing list arm@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org
[fedora-arm] Upgrading ARM system from F20 to F21 via yum?
Okay, here's a stupid question: Can one upgrade an ARM box (Wandboard, in my case) from Fedora 20 to Fedora 21 using yum? The standard Fedora pages have an empty ARM section so it's unclear if there are just no issues or if nobody has tested it. For my new boxes (I just acquired 3 new ones) I'll just install F21 at the start, but I do have some older systems running F20 that I'd like to upgrade without reflashing the full microSD. Thanks, -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Bug in fedora-arm-installer-0.06 on wandboard-dual
Hi, Just tried using Mr Whalen's fedora-arm-installer (0.06) script for F21 on my Wandboard Dual and noticed a small bug.. The script is set up to use wandboard_dual, but in the image the directory is actually wandboard_dl -- so the uboot copy fails. This is probably fixed by simply renaming the link in boards.d and fixing the help usage output. I didn't test that; I just copied the uboot image by hand. Thanks, -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] disk size and networking on a wandboard?
Hi, So I just started to play with Fedora on my Wandboard. I connected via serial cable and booted it up for the first time. It booted nicely immediately and asked me to assign timezone and root password, which I did. I didn't create a user; I figure I can do that later. So far so good. However, I quickly noticed two things: 1) It did not resize the root filesystem. I thought it was supposed to do that automatically? Did something not run correctly the first time or is this a bug in F20? 2) Networking doesn't work. I plug it into a network cable and it tries to run DHCP but my DHCP server doesn't see any packets and the wandboard doesn't come up. I tried to configure it manually and it doesn't work. I've tried with multiple cables and it doesn't seem to help. I even pulled the cable out of a working machine, plugged it into the wandboard, and still nothing (it worked fine again when I plugged it back into the original machine). The wandboard seems to notice that there is link, but it cannot properly transmit anything. In support of #2, running tcpdump -i eth0 on the wandboard I don't see very much (I know I have much more broadcast traffic on my network): 16:15:16.924043 IP6 localhost ff02::2: ICMP6, router solicitation, length 8 16:15:24.092095 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP, Request0 16:15:26.924618 IP6 localhost ff02::2: ICMP6, router solicitation, length 8 16:15:36.924020 IP6 localhost ff02::2: ICMP6, router solicitation, length 8 16:15:37.821455 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP, Request0 Could I have a bad board? :( Or could this still be a software issue? Thanks, -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Best hardware for Fedora/ARM Audio Server?
Peter Robinson pbrobin...@gmail.com writes: The trick is to use something like this: https://bugzilla.redhat.com/show_bug.cgi?id=223722 Sadly, that ticket has been rotting for 5 years. Not sure if it achieves the same thing but there's means of basically doing something very similar with systemd with RO filesystems for pretty much everything and tmpfs for quite a bit of the other bits like .pid stuff and things that need to be preserved (like /etc) but RW in a separate location. Maybe I'm missing something, but on my F18 x86-64 laptop /dev, /run (which is /var/run here), /tmp, and /sys/fs/cgroup are all in tmpfs... So what exactly is the issue here? Peter -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Best hardware for Fedora/ARM Audio Server?
Hi, Gordan Bobic gor...@bobich.net writes: IIRC DreamPlug also has optical audio port. True, but it's a v5, isn't it? That's not supported at all. One thing to consider is CPU generation. Don't know about Wandaboard, but Pi is ARMv6 and Trimslice is ARMv7. AFAIK support for everything before ARMv7 has been dropped from Fedora. Yes, but there is PiDora, which is a respin for v6. However you're right that something like the Wandboard is more powerful. Looks like I can get a Wandboard Solo + Case + Power for about $100, not quite double the cost of the RPi for about 2x the performance. Robert Moskowitz r...@htt-consult.com writes: Hey, Derek! Look at: http://www.thingiverse.com/search?q=cubieboard For people that have built cases for Cubieboard2 and particularly: http://www.thingiverse.com/thing:151160 I am thinking this for a NAS etc box. If you go with the Cubietruck, the Ewell case posted on cubieboard.org not only supports the 2.5 drive, but also a battery if you want! I'm specifically looking for single-use boxes here. It would be *nice* if I could get one box to drive multiple audio zones, but if they are cheap enough then having one box per zone would be fine. But I'm not looking for NAS or anything else today (actually I plan to build a large multi-TB NAS server, but it's not going to be ARM-based). The CT doesn't look like it has audio, but more importantly it doesn't look as-well-supported as the Wandboard. The cubox-i looks amazing for what it provides, but it doesn't have analog audio. Alas, the amps I'm currently looking at don't have SPIDF input so that wouldn't work well for me. So thanks, all. I think I'll order a Wandboard Solo to test this out. I can always select different hardware later, or upgrade to the Dual or Quad if I find I need more CPU power. But audio processing doesn't really require lots of CPU. I was able to do basic DSP functions on my 8-bit 6502-based Atari 800 back in the mid-1980s, with only 48K of RAM. I'm sure 512MB on an ARM can do much better, provided there is sufficient design of the board so we don't get electrical interference. I just need to find a good 5V power supply. ;) Thanks everyone!! -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Best hardware for Fedora/ARM Audio Server?
Gordan Bobic gor...@bobich.net writes: However you're right that something like the Wandboard is more powerful. Looks like I can get a Wandboard Solo + Case + Power for about $100, not quite double the cost of the RPi for about 2x the performance. Indeed. Do you have a form factor preference, though? Most solutions like this have some uglyness associated, e.g. an external power brick. D2Plug is a single brick, just plug into power socket. But performance could conceivably be an issue. No, the boxes are going to be hidden in closets. Having an external power brick is actually better for heat dissipation, IMHO. cheap enough then having one box per zone would be fine. But I'm not looking for NAS or anything else today (actually I plan to build a large multi-TB NAS server, but it's not going to be ARM-based). ARM based multi-TB NAS is actually quite doable: http://www.altechnative.net/2014/02/23/qnap-ts-421-review-modification-and-redsleeve-linux/ I have it running with 4x4TB HGST drives and ZFS (fuse) RAIDZ2. Sorry, but multi-TB I mean starting with something like 24TB and expanding out to ~100. I was planning to build a FreeNAS box for this using a 4U 24-bay case which requires ~3 PCIe slots. So thanks, all. I think I'll order a Wandboard Solo to test this out. I can always select different hardware later, or upgrade to the Dual or Quad if I find I need more CPU power. But audio processing doesn't really require lots of CPU. I was able to do basic DSP functions on my 8-bit 6502-based Atari 800 back in the mid-1980s, with only 48K of RAM. I'm sure 512MB on an ARM can do much better, provided there is sufficient design of the board so we don't get electrical interference. Depending on the form factor you are looking for, there are ARM boards out there with PCI/PCIe slots. You could get one of those and use a PCI/PCIe sound card in it. It would be a lot more expensive, though. On the cheap, there are always USB audio options. A USB sound dongle can be had for about £2, and you could plug that into any ARM device featuring a USB port (i.e. most of them these days). Do you have a reference for these USB sound dongles (that are also supported by Linux/ARM)? I've not found anything that inexpensive. I also wonder how hard it will be to build Shairport? I suspect there isn't already an RPM for it. *ponders actually signing up again for a fedora account to donate the SPEC if I have to write one* Gordan -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Best hardware for Fedora/ARM Audio Server?
Andrew Gillis and...@vortexbox.org writes: The Solo is fine unless you need WiFi. Also if you want multi zones why not just get a bunch of cheap USB DACs. nope, don't need wifi. I've already got Cat-6a run to all my closets. And yes, some USB DACs are definitely an option, assuming I can run multiple instances of the audio server on each box (and find a good enough USB DAC, and a good enough power supply to drive it all). Thanks! -Andrew -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] kernel-headers and kernel-headers-extra install problem
Sid, Sid Boyce sbo...@blueyonder.co.uk writes: On 26/03/14 13:13, Michal Toman wrote: Hi, you are not providing the key error message - remove --skip-broken and post the results. Looking at the package list I would say that you have exclude=kernel* somewhere in yum config, which prevents you from installing kernel-headers. Michal Without --skip-broken and I also have tried rpm -VA --nofiles --nodigest -- Finished Dependency Resolution Error: Package: glibc-headers-2.18-12.fc20.armv7hl (updates) Requires: kernel-headers = 2.2.1 Error: Package: glibc-headers-2.18-12.fc20.armv7hl (updates) Requires: kernel-headers You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Regards Sid. I believe this is exactly what Michal was talking about. Based on this error it would appear that you have an exclude=kernel* somewhere in your yum config. Check /etc/yum.conf and everything under /etc/yum and /etc/yum.repos.d/ and look for such an exclude configuration. That would prevent you from finding and installing kernel-headers = 2.2.1 which is the dependency failure here. Thanks, -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 20 for Raspberry Pi????
Gordan Bobic gor...@bobich.net writes: (e.g. (but not limited to) a large number of packages make little or no effort to ensure memory accesses are aligned - including the likes of e2fsprogs, and transparent alignment fixup in hardware is only available on armv7 and later). I'm surprised that Ted isn't willing to fix issues in e2fsprogs. If you can point me to the upstream bug reports I can ping him to see what's up? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Cubieboards - Re: Announcing Fedora 19 ARM remix for Allwinner SOCs release 1, now with A20 support
Robert Moskowitz r...@htt-consult.com writes: On 07/18/2013 06:12 PM, Hans de Goede wrote: Hi All, I'm very happy to announce the first release (r1) of my Fedora 19 ARM remix images for Allwinner A10, A10s, A13 and A20 based devices. This release is based on the official Fedora 19 Final for ARM images, with u-boot and kernel(s) from the linux-sunxi project: http://linux-sunxi.org/ So I am looking hard at the cubieboards. Either the cb2 or cb3 (cubietruck). I found the following remixs: http://dl.cubieboard.org/software/a20-cubieboard/fedora/ Is production f19 available for the cb2; or is 'based on final' good enough with yum updates? What about the cb3? My understanding is that the only issue you'll have with the remix is that you cannot 'yum update' into a non-remix kernel. Perhaps my understanding is off? -derek, who eventually needs to replace his F12 SheevaPlug with a more recent system... -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] arm software floating point support going forward
Jon, Thanks for the reply. I certainly don't have the hardware to host a v5 koji. All I own are 2 Sheevas and 2 Gurus (and not even the Server Plus models). Moreover, one of my Sheevas is in critical production on my network so I can't really pull it away to perform other duties. I was actually looking at a Cubieboard to get some newer, more powerful hardware, because the Guru is way too low powered to run my MySQL instance. I may even find that the Cubie is too low-powered, but obviously cannot test that until I have one or have access to one. Regardless, right now I don't have the budget to acquire new hardware, which is why I'd like to continue using what I already own. Not being intimately familiar with the various changes in the hardware I guess I just don't understand why we need so many target-specific distributions? I thought the only issue was the floating point ABI issue, which would lead me to believe that we only would need two, FP and non-FP? Is there really a significant speed improvement with e.g. v7 or v8 when compiled specifically vs. running e.g. v6 on a v7 or v8? ISTR that measurements showed some but relatively insignificant speed differences, so why not just stay at the lowest level to support more hardware? Thanks, -derek Jon Masters j...@redhat.com writes: Derek, It is less powers that be than a collaborative effort/decision. We do not have resources to justify keeping v5 alive but you are free to coordinate with others and pick it up, in the same way that Seneca are to own v6 support (maybe Seneca can even help with build system setup if you ask them). Do you have any interest in driving that? You will find the ominous powers that be are in fact a bunch of us doing the work who are overloaded enough to keep just v7 and v8 on track :) For those who are devastated and have no v7 hardware, ping me off list and maybe I can look into getting a couple of v7 boards out there. Jon. -- Sent from my phone. Please excuse brevity. Derek Atkins warl...@mit.edu wrote: Quentin Armitage quen...@armitage.org.uk writes: since there has been no major objection i will disable building armv5tel rpms in rawhide before the mass rebuild. Dennis I guess it's too late now, but I got a few days behind on my list emails. I use 2 * Sheevaplugs and 2 * Dreamplugs with Fedora, and would be very disappointed to see support for them being dropped from Fedora. For me, I still see quite a lifetime in them for what they are doing. I've mentioned multiple times my hope to keep kirkwood support in Fedora, but alas it feels like the powers that be just don't care about us *plug users. :( If I want to continue using my plugs I guess I'll have to learn Debuntu. :( Quentin Armitage -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] arm software floating point support going forward
Quentin Armitage quen...@armitage.org.uk writes: since there has been no major objection i will disable building armv5tel rpms in rawhide before the mass rebuild. Dennis I guess it's too late now, but I got a few days behind on my list emails. I use 2 * Sheevaplugs and 2 * Dreamplugs with Fedora, and would be very disappointed to see support for them being dropped from Fedora. For me, I still see quite a lifetime in them for what they are doing. I've mentioned multiple times my hope to keep kirkwood support in Fedora, but alas it feels like the powers that be just don't care about us *plug users. :( If I want to continue using my plugs I guess I'll have to learn Debuntu. :( Quentin Armitage -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F18 ARM Beta Test Candidate 2
David A. Marlin dmar...@redhat.com writes: On 12/13/2012 06:57 PM, Sean Omalley wrote: Update your uBoot? http://loginroot.com/installing-uboot-to-guruplug-server-plus/ While updating U-Boot is always an option, the images we make _should_ work with existing firmware. We need to look for better ways to make the images. I did update U-Boot and was able to get further, both with F18 and F17. However, F18 still doesn't work. First, the image names are different than what's used in F17, so even if we change the boot directory from ext2 to FAT it would still require a change to uboot. Also, when I try to 'ext2load' the image it just hangs: Marvell usb start (Re)start USB... USB: Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 3 USB Device(s) found scanning bus for storage devices... 1 Storage Device(s) found Marvell ext2load usb 0 0x740 uInitrd-kirkwood Loading file uInitrd-kirkwood from usb device 0:1 (usbda1) ** File not found uInitrd-kirkwood Marvell ext2ls usb 0 DIR 1024 . DIR 1024 .. DIR 12288 lost+found DIR 1024 grub2 24 initrd-plymouth.img 267 boot.scr 14570951 initramfs-3.6.9-4.fc18.armv5tel.kirkwood.img 175 .vmlinuz-3.6.9-4.fc18.armv5tel.kirkwood.hmac 1480164 System.map-3.6.9-4.fc18.armv5tel.kirkwood 115680 config-3.6.9-4.fc18.armv5tel.kirkwood 3373264 vmlinuz-3.6.9-4.fc18.armv5tel.kirkwood 3373328 uImage-3.6.9-4.fc18.armv5tel.kirkwood 14571015 uInitrd-3.6.9-4.fc18.armv5tel.kirkwood 3373328 uImage 14571015 uInitrd 31 klist.txt 195 boot.cmd.mmc 195 boot.cmd.usb 267 boot.scr.mmc 267 boot.scr.usb Marvell ext2load usb 0 0x740 uInitrd Loading file uInitrd from usb device 0:1 (usbda1) [ HANGS HERE ] This is using this version of uboot: U-Boot 2012.04.01 (Jun 01 2012 - 02:19:51) Marvell-GuruPlug SoC: Kirkwood 88F6281_A1 DRAM: 512 MiB WARNING: Caches not enabled NAND: 512 MiB -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F18 ARM Beta Test Candidate 2
David Marlin dmar...@redhat.com writes: Sean Omalley wrote: That was part of the series, that if you didn't have the correct firmware you had to set the arcnumber, and kernels wouldn't work, and a few other issues. I think ext2 support and zlib both were buggy straight from the manufacturer. Both Arch and Debian, I believe, require updating the firmware, rather then trying to program around broken software that has already been fixed. You even have to update the firmware on x86 before you can get support from anyone. If guruplug users don't mind updating the firmware, I'm OK with it. Do you know the minimum version that should be good (so people know if they need to upgrade)? As a user I don't object to updating uboot, but if that's a requirement it would be nice to have that recorded in the instructions (as well as instructions for how to upgrade uboot). -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
[fedora-arm] Issue with F17 Kirkwood 3.5.6-1.fc17.armv5tel kernel
Hi, I finally got F17 working on my Guruplug after I upgraded Uboot. (Note, the Wiki should get updates to specify that this is required). Anyways, after I got the system up I dutifully did a yum update, but unfortunately the kernel update that got installed doesn't boot. When it tries to boot it hangs after setting the clock but before it would try to initialize the network drop monitor service: [ 10.388830] mip6: Mobile IPv6 [ 10.391810] NET: Registered protocol family 17 [ 10.396312] Key type dns_resolver registered [ 10.401156] registered taskstats version 1 [ 10.405570] rtc-mv rtc-mv: setting system clock to 2012-05-02 23:02:19 UTC ( 1335999739) ---HANGS HERE--- (next line should be): [ 10.615585] Initializing network drop monitor service Is there somewhere to file a bug report on this? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F18 ARM Beta Test Candidate 2
David, David A. Marlin dmar...@redhat.com writes: There are a number of pre-created F18 ARM Beta TC2 (Test Candidate 2) images available for testing, including: PandaBoard, Trim Slice, Versatile Express (QEMU) and Kirkwood. Images can be downloaded from: http://scotland.proximity.on.ca/arm-nightlies/vault/f18-beta-tc2/ I just tried the Kirkwood image and it didn't work because the 1st partition is EXT and not FAT. UBoot on my GuruPlug doesn't support that. Also note that I suspect I'm also running into a known kernel bug with the F17 release: https://bugzilla.kernel.org/show_bug.cgi?id=42680 Unfortunately I don't know if there is a workaround for this, especially considering that uImage-kirkwood reports that it is not compressed: /media/boot/uImage-kirkwood: u-boot legacy uImage, 3.4.2-3.fc17.armv5tel.kirkwood, Linux/ARM, OS Kernel Image (Not compressed), 3291832 bytes, Mon Jun 18 00:58:01 2012, Load Address: 0x8000, Entry Point: 0x8000, Header CRC: 0xCDB8004D, Data CRC: 0x6C6E299A Any ideas? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] building F18 Kirkwood images
David, I would be happy to help, however I have been unable to get the F17-GA image to run on my Guruplug.. If I could get that running then I could attempt to help with the F18 work. -derek David Marlin dmar...@redhat.com writes: It was brought to my attention that the F18 Alpha lacked a Kirkwood image, which we had for F17. We have been creating images for F18 using livemedia-creator (anaconda and lorax), where the F17 images were manually created using a custom script. The process we use is described on the wiki: http://fedoraproject.org/wiki/Architectures/ARM/Installer All the builders we have used for creating the F18 images are F17 armv7hl (hard-fp) systems. I personally have no experience with the Kirkwood devices, so I don't know what is needed to set up the image or configure the bootloader. We would appreciate volunteers running F17 on Kirkwood devices to help in creating an F18 image for those devices. The only development involved would be customizing the kickstart file to 1) include any special packages required for the device, and 2) set up any bootloader specific files/scripts needed for the device. The remainder of the effort would be to build and test the image. The hardware requirements include an ARMv5 device running F17-GA or later with access to external storage (requires space for the packages being installed and the resulting image) and swap (requires 1GB total memory). We have created v7hl images using a Trim Slice (1GB memory plus 500MB swap) with external (USB) hard drive, so something similar would probably work. I am willing to provide assistance and answer questions about using the tools and modifying the kickstart config file, but I have no ARMv5 hardware on which to build or test these images. Thank you, d.marlin ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Who's using Kirkwood?
Peter Robinson pbrobin...@gmail.com writes: On Tue, Oct 9, 2012 at 3:36 PM, Derek Atkins warl...@mit.edu wrote: Jon, Jon Masters j...@redhat.com writes: Hi Folks, I'm interested to know who is using Kirkwood, and who would miss it if it went away. For now, we won't kill off ARMv5 because it is used in the official rPi builds but that doesn't mean I'm not interested to know whether we should put testing effort into Kirkwood for F18. My thought is that the latest plugs are moving to ARMv7, and so as the cutting edge Linux distro, we should make plans for deprecating support over the coming releases. This is not a call to drop support today. If I can get numbers on how many people care, that will help. All my Arm devices are Kirkwoods, including Sheeva and Guru Plug devices, and I was considering acquiring some Dreamplug devices, too. I use them in production (with Fedora), and honestly I'd feel very put out if Fedora dropped support for them. I know a bunch of other people who have other kirkwood devices, too. If you read the full thread it's not about dropping the support in the short term. I did read the thread, but our definitions of short term appear to be different. The thread appeared to be a question of support for F18 or F19. IMNSHO I feel Kirkwood support should probably remain until, oh, F25 or 26, at a minimum. There are just too many (IMHO) Kirkwoods out in production. I know that RPi looks interesting, but they are still very hard to acquire. (Limit 1, then wait a few months??) That's no longer the case. In most cases I believe it should now be relatively instant shipping and they're certainly no longer limited to single unit. Glad to hear that. However I'm loathe to throw away my investment of Kirkwoods. I cannot answer you how many others bought them. Have you tried asking them for approximate numbers? The x86 port still supports a Pentium, I don't see any reason to drop support for kirkwood. Is it really that much extra effort? It is surprisingly quite a lot of effort. Oh? Could you elaborate on that? What quite a lot of effort does it take? Fedora no longer supports Pentium actually. It was dropped some time ago (around Fedora 12 from memory). The lowest level of support in Fedora for x86 is now Pentium Pro (Basically i586 + CMOV) which allows support for the OLPC XO-1 (AMD Geode Processor) and the only reason it's still at that level is because there's around 1.5 million XO-1 united deployed and still be actively used and upgraded to current Fedora releases (The just released 12.1.0 is based on Fedora 17, the under development 13.1.0 release is based on Fedora 18). I know mainline Fedora would like to drop the support for that too if they could. So what you're saying is that Fedora *still* supports an x32 CPU that was released well over a decade ago... Peter -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Who's using Kirkwood?
Peter Robinson pbrobin...@gmail.com writes: Might as well wait until the whole 32-bit branch can be dropped. Practically all x86 CPU made in most of the past decade is x86-64. Half decade maybe as Intel first introduced 64 bit CPUs in early 2005 and it took a while to spread through their product set, and there was a lot of Atom CPUs that weren't 64 bit capable. But I agree the reasons for 32 is slowly receding. Sure, but we're a decade later. Kirkwood devices were just released what? 3 years ago? I certainly got mine more recently than that. I admit I've been running F12 on it, but that's only because there hadn't been another fedora release until F17. Peter -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Who's using Kirkwood?
Jon, Jon Masters j...@redhat.com writes: Hi Folks, I'm interested to know who is using Kirkwood, and who would miss it if it went away. For now, we won't kill off ARMv5 because it is used in the official rPi builds but that doesn't mean I'm not interested to know whether we should put testing effort into Kirkwood for F18. My thought is that the latest plugs are moving to ARMv7, and so as the cutting edge Linux distro, we should make plans for deprecating support over the coming releases. This is not a call to drop support today. If I can get numbers on how many people care, that will help. All my Arm devices are Kirkwoods, including Sheeva and Guru Plug devices, and I was considering acquiring some Dreamplug devices, too. I use them in production (with Fedora), and honestly I'd feel very put out if Fedora dropped support for them. I know a bunch of other people who have other kirkwood devices, too. I know that RPi looks interesting, but they are still very hard to acquire. (Limit 1, then wait a few months??) The x86 port still supports a Pentium, I don't see any reason to drop support for kirkwood. Is it really that much extra effort? Jon. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
Chris Tyler ch...@tylers.info writes: 1. Abandon armv5 and move to armv6 where some of the operations we need are available. This will still support the raspberry pi- what about kirkwood *plugs? That would kill the older plugs -- anything below a d2plug. However: do we care? Much? Going to v6 would let us optimize better for the Raspi, which will have greater market penetration than the plugs when existing orders are filled. Otoh, it's a whole 'nuther rebuild. I care. I've got existing plugs that I'd like to continue to use on Fedora. Unless someone wants to buy them off me so I can buy something else? ;) -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] ARMv5 and atomic operations
Chris Tyler ch...@tylers.info writes: Brendan has *just* added the Pi as a target for his nightly rootfs images, but this hasn't been tested yet. This will be a bit different from the final image but will let anyone who wants to play early. (/me toddles off to test that out...) Hmm, I should go figure out how to install F17 on my *plugs, or maybe upgrade my F12 system to F17... -Chris -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Possible File Formats for a Fedora ARM release
Gordan Bobic gor...@bobich.net writes: Kernels are SoC specific. Not quite as narrowly specialized as device specific, but it's still not going to be a one-size-fits all, at least not any time soon (probably years). For example, if you have a Marvell Kirkwood kernel, you could use that kernel on all supported Marvell Kirkwood devices (SheevaPlug, GuruPlug, DreamPlug, etc.). If you have a Marvell Armada kernel, you could boot that on a D2Plug, CuBox, Compulab SBC-A510, etc. If you have a Tegra2 kernel, you could boot that on Toshiba AC100, TrimSlice, etc. Just a pipe-dream, but how hard would it be to take these SoC-specific requirements and move them into a module that could get put into the initramfs? Is there enough generic across all e.g. Armv5 boards that this could happen? Gordan -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] supported hardware
Peter Robinson pbrobin...@gmail.com writes: What about support for the various Marvell plug computers? I would hope that these are supported! They are still Armv5 hardware (Kirkwood?) Peter -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] supported hardware
Peter Robinson pbrobin...@gmail.com writes: On Mon, Jan 23, 2012 at 5:03 PM, Derek Atkins warl...@mit.edu wrote: Peter Robinson pbrobin...@gmail.com writes: What about support for the various Marvell plug computers? I would hope that these are supported! They are still Armv5 hardware (Kirkwood?) The HW will still be supported but there's apparently some interesting changes that need to be made with jtags in some cases. By support we mean here's an image and you do this with livecd-tools to a SD card, plug it in and boot as opposed to devices being able to be made to work by some more complex means. IE Supported devices for basic users. Sure. The Plug computers will never be as easy as devices with a UI. But it would still be nice to at least be able to say install this root FS onto an SD / USB drive and then do X, Y, and Z in your Uboot config to get it to boot. And have the kernel be on the SD/USB instead of nand flash. (I'm pretty sure that the plugs can boot off SD or USB). Peter -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] U-Boot?
DJ Delorie d...@redhat.com writes: Should Fedora for ARM officially support for some well known boards? I think it's important to have some easy-to-use installer for a few popular (and easy to support) ARM platforms. The rest of the questions are harder to answer ;-) Do we have a list of popular (and easy to support) ARM platform? Would this include e.g. the SheevaPlug, GuruPlug, and/or DreamPlug kirkwood-based devices? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] [Fwd: Activity Day June 10th - ARMv7 F15 hardfp bringup]
Jon Masters j...@redhat.com writes: We'll keep v5 around. I think longer term, it probably makes sense to kill it off once people have moved to newer boards/systems (like older versions of IA32 have been killed off over time). But again, that will depend on who is using v5, etc. over time. That kill-off of older x86 models made sense when you could effectively no longer purchase said systems, and couldn't purchase them for several years. When pretty much all you COULD purchase was an i686, and that had been the case for years, *then* it made sense to stop i386 support. I feel the same way about armv5tel. If Sheeva/Kirkwood stops using v5 then sure, I feel dropping v5 support would be fine sometime later. Jon. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] F15 package dependency graph
Jon Masters j...@redhat.com writes: Folks, I would like to see us have alternatives to the Debian xdeb-graph type tools where we can visualize minimal dependencies for bootstrapping. I believe there are several scripts floating around, and that styrene might be able to provide some of what we're looking for...Jon? Failing that, what other options do we have to get away from just looking at the minimal buildroot package lists, etc.? Couldn't one write a python script based around yum to generate this dependency list? Obviously you need to seed the list of known packages (filesystem, basesystem, bash, etc) but you could easily create a list of dependencies from the yum repos, no? Jon. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Hardware Crypto Offload on Kirkwood (SheevaPlug)
omall...@msu.edu writes: Good question. Although I thought dkms support was recently added like F13. Nah, DKMS support has been in Fedora for a while! It's certainly in F12! Installing: dkms noarch 2.1.0.1-1.fc12 fedora 95 k -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Hardware Crypto Offload on Kirkwood (SheevaPlug)
Gordan Bobic gor...@bobich.net writes: I thought there was a phylosophical issue with dkms on fedora, because it tracks the mainline kernel or something like that. Nope, DKMS builds a kernel module as necessary (either at boot time or at kernel update time). It doesn't care what kernel you're using, only that you have the kernel headers and a working compiler. The philosophical issue with DKMS is that it requires a build system and that your end users are plugging stuff into their kernel. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fedora 13 ARM Beta3 Release
Gordan Bobic gor...@bobich.net writes: Paul Whalen wrote: We are pleased to announce the release of Fedora 13 ARM Beta3. This release includes additional software not found in Beta2, most notably Abiword for your word processing needs. Unfortunately at this time we are not able to offer OpenOffice due to some issues with java packages ( java experts we could use your help! ). Considering that Java only accounts for a small amount of seldom used functionality, I would suggest that building LibreOffice --without-java is probably the way forward for the foreseeable future. Or we can just ignore it for F13 and worry about it for F14/15. Considering that F13 is almost EOLed upstream I'd rather see a less-complete F13 release and more work getting up-to-date with F14, F15, and updates. Gordan -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] kernels [WAS: Re: Fedora 13 ARM Beta2]
Jon Masters j...@redhat.com writes: On Sat, 2011-03-26 at 21:10 +, Matthew Wilson wrote: 3. Some kernel build strategy. There are a couple of us looking into this at the moment. The thinking (thus far, only really started pondering recently) goes that we need a kernel RPM but using the F13 kernel is basically certain death in terms of the number of extra patches needed, etc. Therefore, we'll take 2.6.38 and do a rawhide-like kernel RPM that is also installable on F13 to get going. I'm thinking we'll start with an OMAP kernel RPM that works on BeagleBoard-xM and PandaBoard and work from there. Is this something that would also work on a Sheeva or Guru plug? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fat Binaries
Chris Tyler ch...@tylers.info writes: On Wed, 2011-03-02 at 08:15 -0500, Derek Atkins wrote: Chris Tyler ch...@tylers.info writes: Hi Nick, I haven't set up a testing configuration yet but this looks very much like what we need. Before each linking pass, will the script attempt to flip all the libraries to the 'current' API? (Thinking down the road, one ramification is that all of the libraries installed into the mock chroot will need to be writable by the mock user). Why can't the runtime linker make the change when it loads the libraries? Why would it require changing the files on disk? Sorry, to clarify: I meant for static linking (and the fat binary approach is only to bootstrap an optimized armv7hl build). Okay, stupid question but again, why can't the static linker make the changes to the in-core version of the library before it writes out the resulting binary? Actually, shouldn't the static linker write out a fat binary? -Chris -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Fat Binaries
Chris Tyler ch...@tylers.info writes: On Thu, 2011-03-03 at 09:11 -0500, Derek Atkins wrote: Okay, stupid question but again, why can't the static linker make the changes to the in-core version of the library before it writes out the resulting binary? Actually, shouldn't the static linker write out a fat binary? Because we're trying to do this with a wrapper, without any changes to the actual compiler or linker. I guess this is just to bootstrap the build -- we're not trying to make fat systems for installation? So I guess it doesn't matter. I'll shut up now. -Chris -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] SheevaPlug / Fedora 12
Hi, Gordan Bobic gor...@bobich.net writes: That would imply that the kernel acquired from here: http://ftp.linux.org.uk/pub/linux/arm/fedora/platforms/sheevaplug/uImage-2.6.30-sheevaplug I've always acquired by Sheeva kernels from: http://sheeva.with-linux.com/sheeva/ The directions on the wiki works great, and my Sheeva is happily running off an SD card. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Flashing Fedora-12 onto a SheevaPlug?
Henrik Nordström hen...@henriknordstrom.net writes: tor 2010-11-18 klockan 21:58 -0500 skrev Derek Atkins: Luckily my sheeva is still running its original config. uboot is working (albeit with the default version): If you have uboot working and access to it then reflashing is better done from there than using JTAG. Thanks. I've come to that realization and once I test the process I'll update the wiki appropriately. You can use uboot to load the content to be flashed using either TFTP over network or USB stick. Nowhere on the wiki does it really give a full set of instructions for how to do this. I THINK I've found some relevant instructions; once I run through them and test that they work I'll update the wiki with new instructions so the next user can have an easier time. One note is that mkfs.ubifs isn't available in FC12 or 13; only in 14 is it available again. So one needs to backport the mtd-utils package in order to build a UbiFS image. I'll be sure to document this, too, once it's all tested. Thanks! Regards Henrik -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Re: [fedora-arm] Flashing Fedora-12 onto a SheevaPlug?
Hi, omall...@msu.edu writes: Honesty, I have no idea, but i hope this points you in the right direction. It should be very similar to: http://chiana.homelinux.org/~marc/eib_sheeva.html Site is inaccessible at this time. :( I think the important part is under Booting in the final system setenv mainlineLinux yes I guess the kernel from sheeva.with-linux.com is considered a mainline Linux? What would be considered *not* mainline linux? (too many people bricked their plugs so they have have an extra step and the sheeva installer writes a new uboot along with the kernel and filesystem to help prevent this.) Im sure you found the instructions for using the open u-boot. Yeah, my plug isn't bricked. It happily boots the default ubuntu distro installed on the device. I just want to replace the kernel and root with fedora. I don't care where or not I update uboot. However none of the instructions I've found so far say how to do this. The only instruction I found for updating the nand said to use the sheevaplug-installer, which also wants to update uboot. Do note in the instructions they are trying to use UbiFS instead of JFFS. Im not sure I would overwrite the U-boot with what they suggest either. but the procedure for overwriting the nand should be very similar. Okay, n00b question here: what's the difference between UbiFS and JFFS, and why would I want to choose JFFS over UbiFS? (I know what JFFS is to some degree -- I used that back in the TuxScreen, but if the Sheeva wants to use UbiFS, what's wrong with that?) I would try it with jffs first. You may have to compile kernel support to read the rootfs, but you should at least see your kernel boot. (and it will fail with something similar to Kernel panic - not syncing: VFS: Unable to mount root fs.) Ah, see, I'm trying *NOT* to compile anything, if I can avoid it. I don't want to be in the business of building my own kernels; that's what distributions are for. I just want to install the distribution on my system. Is UbiFS part of the default kernel config, usually? And as always if you actually figure it out. Update the wiki :) Of course! -derek Quoting Derek Atkins warl...@mit.edu: Hi, I just received my SheevaPlug shipment yesterday, and today I've been trying (and failing) to install Fedora 12 onto it. I'm trying to set up the plug to boot off nand. Unfortunately the instructions on the wiki are pretty sparse. I'd consider myself a Fedora expert, but I'm definitely new to ARM and embedded systems (modulo some time I spent with a TuxScreen system about a decade ago). I've downloaded the f12 root filesystem and modified it as per the wiki. I also downloaded the 2.6.32.21 kernels from http://sheeva.with-linux.com/sheeva/2.6.32.21/ (as per the wiki), but I have no idea if these are the right packages to use. I only chose this because it's the version of the kernel my F12 laptop is running). Then I downloaded the sheevaplug installer (again, as per the fedora arm wiki), but of course it didn't work on my fedora-12 64 system; the problem was that runme.php needed ?php instead of just ? in order to get php to run... and even when running in an su environment, it still thought I wasn't root. After trying to comprehend the sheevaplug-installer readme, googling to figure out where to find the uboot-custom.txt, and then finally getting the installer running, then I get the dreaded No valid NAND flash driver found: Burning uboot and environment variables ... This will take few minutes ... Open On-Chip Debugger 0.4.0 (2010-02-22-22:59) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html 2000 kHz trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain jtag_nsrst_delay: 200 jtag_ntrst_delay: 200 dcc downloads are enabled Error: No valid NAND flash driver found (0) Available NAND flash controller drivers: nonce davinci lpc3180 orion s3c2410 s3c2412 s3c2440 s3c2443 s3c6400 imx31 at91sam9 openocd FAILED Is the mini USB cable connected? Luckily my sheeva is still running its original config. uboot is working (albeit with the default version): ** MARVELL BOARD: SHEEVA PLUG LE U-Boot 1.1.4 (Jul 14 2009 - 06:46:57) Marvell version: 3.4.16 So... can someone help me wipe out the debian installation and install fedora-12? I think there are enough hits on the web to reflash my uImage, but I can't for the life of me figure out how to flash the rootfs.tar.gz into mtd2. Any help would be greatly appreciated! Thanks, -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available
