> I finished the centos 7 instalation in my CubieTruck, but at the first boot > I saw that the network is not runing. This isn't the right place to come for Centos support. I have no idea what kernel etc they use. > Somebody knows which the correct drive? > > CubieTruck > Centos 7 - Fedora-Minimal-armhfp-22-3 > > > Tks > > Att. > Franciscon P. dos Santos > > _______________________________________________ > arm mailing list > arm(a)lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/arm

On Fedora you should just be able to install the appropriate firmware for the ap6210 driver and have it work, I don't believe Fedora currently has the ability to redistribute it currently otherwise it would be in the linux-firmware package which its not.

On Thu, 2015-08-06 at 18:04 +0100, Peter Robinson wrote: > On Fedora you should just be able to install the appropriate firmware > for the ap6210 driver and have it work, I don't believe Fedora > currently has the ability to redistribute it currently otherwise it > would be in the linux-firmware package which its not. Even with the right firmware available, I'm not sure things have progressed from earlier in the year, where the issues with the brcmfmac driver "stopping" on BPi/Cubietruck, with AP6210 hardware, needed resolution. ISTR, some discussion on the sunxi mailing list about this again recently where they were talking about error recovery on the sdio/mmc side of things.... Not sure any of this made it upstream to the kernel yet. Hans would probably be able to say what should be working now. ;)

NB. I had both a Cubietruck and BananaPro running F22. Both of those I ended up disabling the onboard Broadcom wifi and stuck a dongle in a USB port due to the issues with the brcmfmac driver. Unless Hans can say that the issues are now resolved, I think this is very much a case of "suck it and see". ;)

On Thu, 2015-08-06 at 20:19 +0200, Hans de Goede wrote: > When dropping the right nvram file into place, and adding this: > > https://github.com/jwrdegoede/linux-sunxi/commit/08c7babbb4bd0f9521a6 > 713799a84349cb9dac92 > > patch to the kernel the cubietruck wifi should work reliable. > > Although this patch fixes things, and is safe, we may end > up with a slightly different fix upstream, that is currently > being discussed. Perhaps a different "fix" would be preferable. ;) That patch results in issues with sdcard access....

[ 67.063958] mmcblk0: error -5 sending status command, retrying[ 67.069848] mmcblk0: error -5 sending status command, retrying[ 67.075721] mmcblk0: error -5 sending status command, aborting[ 67.081600] blk_update_request: I/O error, dev mmcblk0, sector 2270354[ 67.088156] Buffer I/O error on dev mmcblk0p3, logical block 33550, lost async page write Regards Clive

On Fri, 2015-08-07 at 10:46 +0200, Hans de Goede wrote: > I've been running with that fix for a while now and I'm seeing no > such issues. Patch was applied to F22 4.1.3-201. Didn't managed to boot that successfully due to problems reading/writing sdcard and timeouts. No such issues booting with a "stock" 4.1.3-201. That was on BananaPro. I'll try again with Cubietruck today. (And apart from the fsck required, no problems immediately booting the stock kernel after the boot failures due to mmc timeouts with the patched kernel.)

On Fri, 2015-08-07 at 17:15 +0200, Hans de Goede wrote: > Hi, > > On 07-08-15 12:19, Clive Messer wrote: >> On Fri, 2015-08-07 at 10:46 +0200, Hans de Goede wrote: >> >>> I've been running with that fix for a while now and I'm seeing no >>> such issues. >> Patch was applied to F22 4.1.3-201. Didn't managed to boot that >> successfully due to problems reading/writing sdcard and timeouts. >> No >> such issues booting with a "stock" 4.1.3-201. That was on >> BananaPro. >> I'll try again with Cubietruck today. (And apart from the fsck >> required, no problems immediately booting the stock kernel after >> the >> boot failures due to mmc timeouts with the patched kernel.) > Weird. I'll keep this in mind when there is more clarity about a > "proper" fix for this upstream. Hans, I've also booted the kernel with your sunxi-mmc patch on CubieTruck and BananaPi, since my initial testing with BananaPro. Even if it doesn't hang on boot, while accessing SDCARD, sooner or later.... ** 61 printk messages dropped ** [ 105.010500] mmcblk0: error -5 sending status command, retrying ** 36 printk messages dropped ** [ 105.020100] mmcblk0: error -5 sending status command, aborting ** 31 printk messages dropped ** [ 105.028429] mmcblk0: error -5 sending status command, retrying ** 43 printk messages dropped ** [ 105.037543] mmcblk0: error -5 sending status command, retrying ** 38 printk messages dropped ** [ 105.046260] mmcblk0: error -5 sending status command, retrying ** 38 printk messages dropped ** [ 105.055028] mmcblk0: error -5 sending status command, retrying ** 33 printk messages dropped ** [ 105.063290] mmcblk0: error -5 sending status command, retrying I rebuilt with original sigint patch ( https://groups.google.com/forum/#!topic/linux-sunxi/v6Ktt8lAnw0) where the check is only being performed for sdio access from wifi driver rather than everything that goes through sunxi mmc driver.... No issues. Have put many Gigs of data through the wifi connection on the BananaPro. Sorry, don't have any more time to look into this and as you say, probably a non-issue, if neither is the actual "fix" that will make it upstream anyway. Clive

On Tue, Aug 18, 2015 at 10:13 PM, Robert Moskowitz <rgm(a)htt-consult.com&gt; wrote: > I have not done any Fedora-arm testing for many weeks and am behind on > developments. Correct me if I missed something in past threads. > > I am trying to make sense of this thread, though. > > I am running the lastest F23 build (Fedora-Xfce-armhfp-23-20150818-sda) and > no Wifi (or Bluetooth) flashing LEDs. On the serial console on firstboot I > do see: > > [ 28.134790] cfg80211: World regulatory domain updated: > [ 28.134804] cfg80211: DFS Master region: unset > [ 28.134805] cfg80211: (start_freq - end_freq @ bandwidth), > (max_antenna_gain, max_eirp), (dfs_cac_time) > [ 28.134818] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, > 2000 mBm), (N/A) > [ 28.134824] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (N/A, > 2000 mBm), (N/A) > [ 28.134829] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (N/A, > 2000 mBm), (N/A) > [ 28.134837] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, 160000 > KHz AUTO), (N/A, 2000 mBm), (N/A) > [ 28.134954] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, 160000 > KHz AUTO), (N/A, 2000 mBm), (0 s) > [ 28.134961] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 KHz), (N/A, > 2000 mBm), (0 s) > [ 28.134967] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, > 2000 mBm), (N/A) > [ 28.134973] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), > (N/A, 0 mBm), (N/A) > > So one might THINK that the WiFi was seen. > > But nothing shows for WiFi in NetworkManager. Did you add a firmware? At the moment you need to get the firmware from elsewhere as we don't have the ability to legally redistribute it directly.

You might also want to check the output of lsmod, "ip link" and "iw list"

> The thought of pacthing nvram leaves me a little worried. I would like to > get WiFi working on the F23 build. > > > On 08/10/2015 02:55 PM, Clive Messer wrote: >> On Fri, 2015-08-07 at 17:15 +0200, Hans de Goede wrote: >>> Hi, >>> >>> On 07-08-15 12:19, Clive Messer wrote: >>>> On Fri, 2015-08-07 at 10:46 +0200, Hans de Goede wrote: >>>> >>>>> I've been running with that fix for a while now and I'm seeing no >>>>> such issues. >>>> Patch was applied to F22 4.1.3-201. Didn't managed to boot that >>>> successfully due to problems reading/writing sdcard and timeouts. >>>> No >>>> such issues booting with a "stock" 4.1.3-201. That was on >>>> BananaPro. >>>> I'll try again with Cubietruck today. (And apart from the fsck >>>> required, no problems immediately booting the stock kernel after >>>> the >>>> boot failures due to mmc timeouts with the patched kernel.) >>> Weird. I'll keep this in mind when there is more clarity about a >>> "proper" fix for this upstream. >> Hans, >> >> I've also booted the kernel with your sunxi-mmc patch on CubieTruck and >> BananaPi, since my initial testing with BananaPro. Even if it doesn't >> hang on boot, while accessing SDCARD, sooner or later.... >> >> ** 61 printk messages dropped ** [ 105.010500] mmcblk0: error -5 >> sending status command, retrying >> ** 36 printk messages dropped ** [ 105.020100] mmcblk0: error -5 >> sending status command, aborting >> ** 31 printk messages dropped ** [ 105.028429] mmcblk0: error -5 >> sending status command, retrying >> ** 43 printk messages dropped ** [ 105.037543] mmcblk0: error -5 >> sending status command, retrying >> ** 38 printk messages dropped ** [ 105.046260] mmcblk0: error -5 >> sending status command, retrying >> ** 38 printk messages dropped ** [ 105.055028] mmcblk0: error -5 >> sending status command, retrying >> ** 33 printk messages dropped ** [ 105.063290] mmcblk0: error -5 >> sending status command, retrying >> >> I rebuilt with original sigint patch ( >> https://groups.google.com/forum/#!topic/linux-sunxi/v6Ktt8lAnw0) where >> the check is only being performed for sdio access from wifi driver >> rather than everything that goes through sunxi mmc driver.... No >> issues. Have put many Gigs of data through the wifi connection on the >> BananaPro. >> >> Sorry, don't have any more time to look into this and as you say, >> probably a non-issue, if neither is the actual "fix" that will make it >> upstream anyway. >> >> Clive >

Hi, On 19-08-15 00:04, Robert Moskowitz wrote: > > > On 08/18/2015 05:31 PM, Peter Robinson wrote: >> On Tue, Aug 18, 2015 at 10:13 PM, Robert Moskowitz >> <rgm(a)htt-consult.com&gt; wrote: >>> I have not done any Fedora-arm testing for many weeks and am behind on >>> developments. Correct me if I missed something in past threads. >>> >>> I am trying to make sense of this thread, though. >>> >>> I am running the lastest F23 build >>> (Fedora-Xfce-armhfp-23-20150818-sda) and >>> no Wifi (or Bluetooth) flashing LEDs. On the serial console on >>> firstboot I >>> do see: >>> >>> [ 28.134790] cfg80211: World regulatory domain updated: >>> [ 28.134804] cfg80211: DFS Master region: unset >>> [ 28.134805] cfg80211: (start_freq - end_freq @ bandwidth), >>> (max_antenna_gain, max_eirp), (dfs_cac_time) >>> [ 28.134818] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), >>> (N/A, >>> 2000 mBm), (N/A) >>> [ 28.134824] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), >>> (N/A, >>> 2000 mBm), (N/A) >>> [ 28.134829] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), >>> (N/A, >>> 2000 mBm), (N/A) >>> [ 28.134837] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz, >>> 160000 >>> KHz AUTO), (N/A, 2000 mBm), (N/A) >>> [ 28.134954] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz, >>> 160000 >>> KHz AUTO), (N/A, 2000 mBm), (0 s) >>> [ 28.134961] cfg80211: (5490000 KHz - 5730000 KHz @ 160000 >>> KHz), (N/A, >>> 2000 mBm), (0 s) >>> [ 28.134967] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), >>> (N/A, >>> 2000 mBm), (N/A) >>> [ 28.134973] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 >>> KHz), >>> (N/A, 0 mBm), (N/A) >>> >>> So one might THINK that the WiFi was seen. >>> >>> But nothing shows for WiFi in NetworkManager. >> Did you add a firmware? At the moment you need to get the firmware >> from elsewhere as we don't have the ability to legally redistribute it >> directly. > > ??? For some time, it seemed that Cubietruck working WiFi was based > on Hans getting things connected, not also a vendor's firmware. Plus > Clive's and Han's messages seem to say that they have gotten the WiFi > working with an nvram patch. Right the actual firmware is part of linux-firmware, but you do need a board specific nvram file and drop that under /lib/firmware, see the dmesg output when the module loads.

On Wed, 2015-08-19 at 05:53 -0400, Robert Moskowitz wrote: > OK. I will look into what is involved and give it a go today. There > was > your earlier message on this. Robert, You've probably already got past this point, but if you haven't.... http://www.squeezecommunity.org/repo/fedora/22/armhfp/ap6210-firmware-1 .0-1.fc22.noarch.rpm contains binary firmware and nvram file.... http://www3.squeezecommunity.org/repo/fedora/22/unstable/armhfp/ Contains a patched Fedora 4.1.6 kernel build for F22.... (Hans original mmc patch, plus the 250->750 timeout patch, most recently being discussed on sunxi Google group.) This works just fine for both wifi and sdcard (without the timeouts and SDCARD corruption I experienced, last time I tried) on the BananaPro. Not actually tested on Cubietruck but expect it will "just work", if you installed the ap6210 firmware rpm and this patched 4.1.6 kernel on top of F22. I can't offer any support, other than to say, it works for me on BananaPro. ;)

On Wed, 2015-08-19 at 13:45 -0400, Robert Moskowitz wrote: > thanks. But I am 'skipping forward' from F22 on to F23. I am not > looking at having a box up and running all the time. Yet. That f22 firmware rpm should install fine on F23. (Can't see why it wouldn't, not that I've tried.) > So I need f23 rpms (http://www.squeezecommunity.org/repo/fedora/ does > not have any yet) and a newer kernel... What's F23 using for kernel, a 4.2 rc? The two relevant patches might apply cleanly to 4.2. You could try applying.... http://www3.squeezecommunity.org/patches/0001-mmc-sunxi-Don-t-start-comma... and http://www3.squeezecommunity.org/patches/mmc__sunxi__fix_timeout_in_sunxi...

Hi, On 06-08-15 20:08, Clive Messer wrote: > On Thu, 2015-08-06 at 18:04 +0100, Peter Robinson wrote: > >> On Fedora you should just be able to install the appropriate firmware >> for the ap6210 driver and have it work, I don't believe Fedora >> currently has the ability to redistribute it currently otherwise it >> would be in the linux-firmware package which its not. > > Even with the right firmware available, I'm not sure things have > progressed from earlier in the year, where the issues with the brcmfmac > driver "stopping" on BPi/Cubietruck, with AP6210 hardware, needed > resolution. > > ISTR, some discussion on the sunxi mailing list about this again > recently where they were talking about error recovery on the sdio/mmc > side of things.... Not sure any of this made it upstream to the kernel > yet. > > Hans would probably be able to say what should be working now. ;) When dropping the right nvram file into place, and adding this: https://github.com/jwrdegoede/linux-sunxi/commit/08c7babbb4bd0f9521a67137... patch to the kernel the cubietruck wifi should work reliable. Although this patch fixes things, and is safe, we may end up with a slightly different fix upstream, that is currently being discussed.

> NB. I had both a Cubietruck and BananaPro running F22. Both of those I > ended up disabling the onboard Broadcom wifi and stuck a dongle in a > USB port due to the issues with the brcmfmac driver. Unless Hans can > say that the issues are now resolved, I think this is very much a case > of "suck it and see". ;) The issues are now resolved, the cubietruck nvram file should also work fine on the bananapro. Hint if you use multiple boards with the brcm wifi, edid the MAC in the nvram file, or all systems end up with the same MAC, fixing the MAC issue and a solution for distributing the nvram file as part of linux-firmware are in my sunxi projects list: https://revspace.nl/KernelDriverProjects

Hi, On 19-08-15 14:07, Robert Moskowitz wrote: > Hans, I found your earlier message on this, but it does not give ME > clear instructions on getting the pieces together: > > On 08/06/2015 02:19 PM, Hans de Goede wrote: >> Hi, >> >> On 06-08-15 20:08, Clive Messer wrote: >>> On Thu, 2015-08-06 at 18:04 +0100, Peter Robinson wrote: >>> >>>> On Fedora you should just be able to install the appropriate firmware >>>> for the ap6210 driver and have it work, I don't believe Fedora >>>> currently has the ability to redistribute it currently otherwise it >>>> would be in the linux-firmware package which its not. >>> >>> Even with the right firmware available, I'm not sure things have >>> progressed from earlier in the year, where the issues with the >>> brcmfmac >>> driver "stopping" on BPi/Cubietruck, with AP6210 hardware, needed >>> resolution. >>> >>> ISTR, some discussion on the sunxi mailing list about this again >>> recently where they were talking about error recovery on the sdio/mmc >>> side of things.... Not sure any of this made it upstream to the kernel >>> yet. >>> >>> Hans would probably be able to say what should be working now. ;) >> >> When dropping the right nvram file into place, and adding this: >> >> https://github.com/jwrdegoede/linux-sunxi/commit/08c7babbb4bd0f9521a67137... >> >> >> patch to the kernel the cubietruck wifi should work reliable. >> >> Although this patch fixes things, and is safe, we may end >> up with a slightly different fix upstream, that is currently >> being discussed. > > Where is the nvram file described and how to put it in place. http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_ap6...

And save it as /lib/firmware/brcm/brcmfmac43362-sdio.txt

> > Is this patch still needed for F23? What specific kernel version is > included? Or do I still have to patch? Still needed, you still need to manually patch your kernel. >>> NB. I had both a Cubietruck and BananaPro running F22. Both of those I >>> ended up disabling the onboard Broadcom wifi and stuck a dongle in a >>> USB port due to the issues with the brcmfmac driver. Unless Hans can >>> say that the issues are now resolved, I think this is very much a case >>> of "suck it and see". ;) >> >> The issues are now resolved, the cubietruck nvram file should also >> work fine on the bananapro. Hint if you use multiple boards with the >> brcm wifi, edid the MAC in the nvram file, or all systems end up >> with the same MAC, fixing the MAC issue and a solution for distributing >> the nvram file as part of linux-firmware are in my sunxi projects list: >> >> https://revspace.nl/KernelDriverProjects > > yuck. And you finally got a stable, unique MAC address working for > the Cubietruck (well, last year, but still). > > How do I do this? Where is the instructions. There are no instructions, these bits are not yet end user ready. Once they are things should just work without needing to follow any instructions.

Hi, On 19-08-15 14:28, Robert Moskowitz wrote: > > > On 08/19/2015 08:20 AM, Hans de Goede wrote: >> Hi, >> >> On 19-08-15 14:07, Robert Moskowitz wrote: >>> Hans, I found your earlier message on this, but it does not give ME >>> clear instructions on getting the pieces together: >>> >>> On 08/06/2015 02:19 PM, Hans de Goede wrote: >>>> Hi, >>>> >>>> On 06-08-15 20:08, Clive Messer wrote: >>>>> On Thu, 2015-08-06 at 18:04 +0100, Peter Robinson wrote: >>>>> >>>>>> On Fedora you should just be able to install the appropriate >>>>>> firmware >>>>>> for the ap6210 driver and have it work, I don't believe Fedora >>>>>> currently has the ability to redistribute it currently otherwise it >>>>>> would be in the linux-firmware package which its not. >>>>> >>>>> Even with the right firmware available, I'm not sure things have >>>>> progressed from earlier in the year, where the issues with the >>>>> brcmfmac >>>>> driver "stopping" on BPi/Cubietruck, with AP6210 hardware, needed >>>>> resolution. >>>>> >>>>> ISTR, some discussion on the sunxi mailing list about this again >>>>> recently where they were talking about error recovery on the >>>>> sdio/mmc >>>>> side of things.... Not sure any of this made it upstream to the >>>>> kernel >>>>> yet. >>>>> >>>>> Hans would probably be able to say what should be working now. ;) >>>> >>>> When dropping the right nvram file into place, and adding this: >>>> >>>> https://github.com/jwrdegoede/linux-sunxi/commit/08c7babbb4bd0f9521a67137... >>>> >>>> >>>> patch to the kernel the cubietruck wifi should work reliable. >>>> >>>> Although this patch fixes things, and is safe, we may end >>>> up with a slightly different fix upstream, that is currently >>>> being discussed. >>> >>> Where is the nvram file described and how to put it in place. >> >> http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_ap6... >> > > I cannot resolve that fqdn. I have had this problem in the past with > dl.cubieboard.org; for some reason it is just not available over here. That is a problem, try using wget from some shell on another box?

>> And save it as /lib/firmware/brcm/brcmfmac43362-sdio.txt > > Does that URL tell how to do this? There is nothing to tell, download the file and save it as /lib/firmware/brcm/brcmfmac43362-sdio.txt on the root partition of your cubietruck.

Hi, On 19-08-15 14:38, Robert Moskowitz wrote: > > > On 08/19/2015 08:31 AM, Hans de Goede wrote: >> Hi, >> >> On 19-08-15 14:28, Robert Moskowitz wrote: >>> >>> >>> On 08/19/2015 08:20 AM, Hans de Goede wrote: >>>> Hi, >>>> >>>> On 19-08-15 14:07, Robert Moskowitz wrote: >>>>> Hans, I found your earlier message on this, but it does not give >>>>> ME clear instructions on getting the pieces together: >>>>> >>>>> On 08/06/2015 02:19 PM, Hans de Goede wrote: >>>>>> Hi, >>>>>> >>>>>> On 06-08-15 20:08, Clive Messer wrote: >>>>>>> On Thu, 2015-08-06 at 18:04 +0100, Peter Robinson wrote: >>>>>>> >>>>>>>> On Fedora you should just be able to install the appropriate >>>>>>>> firmware >>>>>>>> for the ap6210 driver and have it work, I don't believe Fedora >>>>>>>> currently has the ability to redistribute it currently >>>>>>>> otherwise it >>>>>>>> would be in the linux-firmware package which its not. >>>>>>> >>>>>>> Even with the right firmware available, I'm not sure things have >>>>>>> progressed from earlier in the year, where the issues with the >>>>>>> brcmfmac >>>>>>> driver "stopping" on BPi/Cubietruck, with AP6210 hardware, needed >>>>>>> resolution. >>>>>>> >>>>>>> ISTR, some discussion on the sunxi mailing list about this again >>>>>>> recently where they were talking about error recovery on the >>>>>>> sdio/mmc >>>>>>> side of things.... Not sure any of this made it upstream to the >>>>>>> kernel >>>>>>> yet. >>>>>>> >>>>>>> Hans would probably be able to say what should be working now. ;) >>>>>> >>>>>> When dropping the right nvram file into place, and adding this: >>>>>> >>>>>> https://github.com/jwrdegoede/linux-sunxi/commit/08c7babbb4bd0f9521a67137... >>>>>> >>>>>> >>>>>> patch to the kernel the cubietruck wifi should work reliable. >>>>>> >>>>>> Although this patch fixes things, and is safe, we may end >>>>>> up with a slightly different fix upstream, that is currently >>>>>> being discussed. >>>>> >>>>> Where is the nvram file described and how to put it in place. >>>> >>>> http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/nvram_ap6... >>>> >>> >>> I cannot resolve that fqdn. I have had this problem in the past >>> with dl.cubieboard.org; for some reason it is just not available >>> over here. >> >> That is a problem, try using wget from some shell on another box? > > All of my boxes have their DNS connections through Comcast. I don't > have access to any other DNS servers. Well I could easily if I knew > of one that resolved this fqdn. If someone just gives me the IPv4 > addr for it, I can go direct that way. :( The IP is 192.163.232.151 you will have to put this in your /etc/hosts though, going there directly does not work (it likely is a vhost).