Linux Kernel 6.7.5 Kirkwood package and Debian rootfs

Hi bodhi,

somebody did already a kernel bisect and perhaps found the guilty commit,

see here:

http://www.spinics.net/lists/arm-kernel/msg413993.html

I am just testing the patch and recompile

best wishes pbg4

p.s. the kernel compile with multi_v5_defconfig was also not successfull as already expected

Hi bodhi,

success, that patch did it,!!

wlan via pcie is back in my iconnect with 4.1-rc1 and the small
config, i.e. multi_v5_defconfig, see:

pci 0000:00:01.0: enabling device (0140 -> 0142)
ath: phy0: Enable LNA combining
ath: EEPROM regdomain: 0x60
ath: EEPROM indicates we should expect a direct regpair map
ath: Country alpha2 being used: 00
ath: Regpair used: 0x60
ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
ieee80211 phy0: Atheros AR9285 Rev:2 mem=0xd1c80000, irq=83
ath9k 0000:01:00.0 wlan1: renamed from wlan0

best wishes pbg4

Hi pbg4,

Cool! I'm going to try that on the latest kernel with Pogo V4 and NSA325.

Thanks

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

pbg4,

Yes, it did fix the USB 3.0 problem. This is on the Pogo V4:

[    2.607375] xhci_hcd 0000:01:00.0: enabling bus mastering
[    2.607394] xhci_hcd 0000:01:00.0: xHCI Host Controller
[    2.611336] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 1
[    2.618848] xhci_hcd 0000:01:00.0: hcc params 0x200073a1 hci version 0x100 quirks 0x00000010
[    2.625963] xhci_hcd 0000:01:00.0: enabling Mem-Wr-Inval
[    2.627151] hub 1-0:1.0: USB hub found
[    2.629888] hub 1-0:1.0: 2 ports detected
[    2.632986] xhci_hcd 0000:01:00.0: xHCI Host Controller
[    2.636912] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus number 2

[    3.017321] usb 3-1: new high-speed USB device number 2 using orion-ehci
[    3.170328] usb-storage 3-1:1.0: USB Mass Storage device detected

I'm going to release another kernel 4.0 version.

Reminder: for future kernel 4.1+, I will need the patch for drivers/media/usb/dvb-usb/dw2102.c from you :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

at the moment my recompile is running for 4.1-rc1 where I adopted your patch,
hopefully I can get it working now with the full config, as it is already working now with multi_v5_defconfig,

because in the merge window of 4.1 there was a git pull from linux-media done
everything is contained already, this makes my old patch superfluous, the tt-s2-4600 is
from 4.1 onwards supported in mainline land, as part of the supported devices from dvb-usb-dw2102,

also the frontend driver ts2022 is than merged with ts2020, and the ds3103 demodulator driver
becomes m88ds3103, also the remote control is working via rc-tt-1500,

once you come to release 4.1 you can skip the patch alltogether,
that was also the reason to drop in here in doozan forum again the last few days
more frequently and test with 4.1-rc1, just to let you now that the patch is not needed from 4.1 on,.. :)

best wishes pbg4



Edited 1 time(s). Last edit at 04/30/2015 08:50AM by pbg4.

pbg4,

Thanks for letting me know, I see now why that file did not compile. OK, that's the plan for 4.1 then :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Kernel linux-4.0.0-kirkwood-tld-2 package has been uploaded. Please see 1st post for description and download link.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Thanks bodhi and pbg4, the wlan device seems to wirk fine with 4.0.0-kirkwood-tld2.
I'm using various DVB-T sticks on the iconnect and the trouble with some af9015 based DVB-T sticks is gone, but now, all realtek based DVB-T sticks doesn't work anymore (terratec cinnergy tstick+, msi digivox mini deluxe).
Both sticks are working fine with kernel 3.18.5.

...
[ 1830.267975] rtl2832 1-0010: i2c reg read failed -32
[ 1830.272903] i2c i2c-2: fc2580: i2c wr failed=-32 reg=00 len=1
[ 1830.282969] rtl2832 1-0010: i2c reg read failed -32
[ 1832.279975] rtl2832 1-0010: i2c reg read failed -32
[ 1832.285645] i2c i2c-2: fc2580: i2c wr failed=-32 reg=02 len=1
[ 1832.295678] rtl2832 1-0010: i2c reg read failed -32
[ 1832.303441] rtl2832 1-0010: i2c reg read failed -32
[ 1846.304718] rtl2832 1-0010: i2c reg read failed -32
[ 1846.309649] i2c i2c-2: fc2580: i2c wr failed=-32 reg=02 len=1
...

I can reproduce this with kernel 4.0.1 on my gentoo x86_64 machine.
With up-to-date drivers from media_build git (http://git.linuxtv.org/media_build.git)
this issue seems to be fixed and all mentioned realtek based DVB-T sticks are working fine.


@bodhi:
Is it possible to integrate this drivers in the next release?

pengu,

> I can reproduce this with kernel 4.0.1 on my
> gentoo x86_64 machine.
> With up-to-date drivers from media_build git
> (http://git.linuxtv.org/media_build.git)
> this issue seems to be fixed and all mentioned
> realtek based DVB-T sticks are working fine.
>
>
> @bodhi:
> Is it possible to integrate this drivers in the
> next release?

Did they submit a patch to mainline Linux? Or did you get the updated drivers by cloing their Git and compile? Usually, if the drivers code is organized in the same structure as the kernel source tree, then it is easy to integrate it. But if the code tree is different, then it will take more works to do.

It would be best if you can give me a patch like pbg4 have been doing for DVB. Otherwise, the other alternative would be pointing me to a commit in their Git that I can use to generate the difference.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Note on an observed issue, I was able to compile this driver https://github.com/gnab/rtl8812au on a Pogoplug V4-A3 for use with a Edimax EW-7811UTC AC600 adapter in Debian 3.18.5 but for some reason it won't compile once I upgraded to 4.0 both with tld-1 and tld-2. Not sure why it fails on the most recent updates.

@bodhi:
there is a script included in the media_build guit which compiles all related modules against the running kernel.
so this could be the way

@LeggoMyEggo
I'm running into problems with a D-Link DWA131 REV B1 (rtl8192cu)
The drivers is included but on both kernels (3.18.5, 4.0.0) it isn't possible to use it.

Ralink driver has TIME and DATE macro which was removed from the kernel . You need to remove it and the driver will compile

Thanks for the info moonman!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

@bodhi,

Is there a way to enable systemd without having to change the uboot env? What impact will it have when booting ARCH or a older Debian rootfs without systemd?

Do you have plans to enabler systemd by default in the near future? I would like to start using systemd on Debian so that it's consistent with Arch.

-grayman4hire
======================================
Pogoplug V2 and V3 Serial Connection
Tutorial - Pogoplug v4 (Series 4 and Mobile) with Linux (Debian or Arch)
OpenWRT on Pogoplug Mobile
Tutorial - Pogoplug E02/V4 with Arch Linux ARM
Hacking the Pogoplug v3/Oxnas (Pro/Classic) with Debian
OpenWRT on Pogoplug v3/Oxnas (Pro/Classic)

@grayman4hire,

> Is there a way to enable systemd without having to
> change the uboot env? What impact will it have
> when booting ARCH or a older Debian rootfs without
> systemd?

The easiest way to run systemd is if you have the latest u-boot installed, use uEnv.txt to change the bootargs on the fly. For example, add these 2 lines in uEnv.txt (assuming set_bootarg is currently defined in your u-boot envs this way)

custom_params=init=/bin/systemd
set_bootargs=setenv bootargs console=$console root=LABEL=rootfs rootdelay=10 $mtdparts $custom_params

>
> Do you have plans to enabler systemd by default in
> the near future? I would like to start using
> systemd on Debian so that it's consistent with
> Arch.

I'm on the fence about this. I think we'll gain something and loose something switching to systemd. For me personally, I hate binary log (paraphasing Linus, it is f.. stupid :)) when you have a system crash for whatever reason, you're screwed. otoh, text log saved my projects countless times in the real world. So I kept the rootfs dedault to sysvinit. But eventually we will have to bite the bullet and switch to keep up with Debian standard.

So perhaps some next rootfs we'll switch to systemd? anybody have strong feeling about it?

-----
Edit: fixed typo

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 01/24/2017 02:43AM by bodhi.

bodhi Wrote:
-------------------------------------------------------
> anybody have strong feeling about it?

Total Linux geek thing = no comprende = whatever you say boss :)

bodhi Wrote:
-------------------------------------------------------
> So perhaps some next rootfs we'll switch to
> systemd? anybody have strong feeling about it?

My vote is to switch to systemd. It's here to stay and everyone should get use to is sooner or later.

-grayman4hire
======================================
Pogoplug V2 and V3 Serial Connection
Tutorial - Pogoplug v4 (Series 4 and Mobile) with Linux (Debian or Arch)
OpenWRT on Pogoplug Mobile
Tutorial - Pogoplug E02/V4 with Arch Linux ARM
Hacking the Pogoplug v3/Oxnas (Pro/Classic) with Debian
OpenWRT on Pogoplug v3/Oxnas (Pro/Classic)

Same thing here, even if don't like all aspects of it. Im using it on one of my other plugs with arch and it's ok. And as workaround for the binary log bullshit, it writes all log messages into a text file too ;)

Hi,

concerning systemd I have the same mixed feelings about it as bodhi has, so I am not holding
my breath to see it arrive in armv5 kirkwood mainline land, perhaps we should wait a little bit,

sometime things get more mature that way, and than it's easier to adopt and integrate it,
but of course its the way it goes, as debian is following that path,..

best wishes pbg4

Hi,

@bodhi

some news about the dvb driver situation, especially dvb-usb-dw2102,

in the last days I have received emails from Olli Salonen, one of the devs
from linux-media, he has finally found the last bug of the tt-s2-4600 driver (inside
dvb-usb-dw2102) which has found its way in linux kernel 4.1-rc1 in the merge window
and asked me to make tests,

my tests today of these commits were succesfull, so Olli Salonen told me he is going to commit the final patches
to linux media,..

the commits are to be found in:

https://github.com/trsqr/media_tree/commits/tt_s2-4600

if they dont arrive in time for 4.1 I have prepared some patches which I am going to send to you bodhi,
but at the moment I am still waiting if its necessary, the best would be the inclusion in 4.1 natively,..

below is a dmesg exerpt from one of the iConnects here running the test to show that the
driver is working,

best wishes pbg4

dmesg:

Linux iconnect 4.1.0-rc1-kirkwood-tld-3 #5 PREEMPT Thu Apr 30 17:55:58 CEST 2015 armv5tel GNU/Linux

[156564.458375] usb 1-1.3: new high-speed USB device number 4 using orion-ehci
[156564.589120] usb 1-1.3: New USB device found, idVendor=0b48, idProduct=3011
[156564.596145] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[156564.604239] usb 1-1.3: Product: dvb-s2
[156564.608142] usb 1-1.3: Manufacturer: geniatech
[156564.612700] usb 1-1.3: SerialNumber: 000000000232
[156564.771716] dvb-usb: found a 'TechnoTrend TT-connect S2-4600' in warm state.
[156564.783543] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
[156564.793229] DVB: registering new adapter (TechnoTrend TT-connect S2-4600)
[156564.804725] dvb-usb: MAC address: bc:ea:2b:46:01:a2
[156565.143117] i2c i2c-1: m88ds3103_attach: chip_id=70
[156565.156241] i2c i2c-1: Added multiplexed i2c bus 2
[156565.232360] ts2020 2-0060: Montage Technology TS2022 successfully identified
[156565.239654] usb 1-1.3: DVB: registering adapter 0 frontend 0 (Montage M88DS3103)...
[156565.288170] Registered IR keymap rc-tt-1500
[156565.295399] input: IR-receiver inside an USB DVB receiver as /devices/platform/ocp@f1000000/f1050000.ehci/usb1/1-1/1-1.3/rc/rc0/input1
[156565.328771] rc0: IR-receiver inside an USB DVB receiver as /devices/platform/ocp@f1000000/f1050000.ehci/usb1/1-1/1-1.3/rc/rc0
[156565.348989] dvb-usb: schedule remote query interval to 250 msecs.
[156565.355240] dvb-usb: TechnoTrend TT-connect S2-4600 successfully initialized and connected.
[156565.365698] usbcore: registered new interface driver dw2102
[156643.439860] i2c i2c-1: m88ds3103: found a 'Montage M88DS3103' in cold state
[156643.455623] i2c i2c-1: m88ds3103: downloading firmware from file 'dvb-demod-m88ds3103.fw'
[156644.522863] i2c i2c-1: m88ds3103: found a 'Montage M88DS3103' in warm state
[156644.529995] i2c i2c-1: m88ds3103: firmware version 3.B

@pbg4,

> if they dont arrive in time for 4.1 I have
> prepared some patches which I am going to send to
> you bodhi,
> but at the moment I am still waiting if its
> necessary, the best would be the inclusion in 4.1
> natively,..
>

Thanks for the info! either way would be OK.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> So perhaps some next rootfs we'll switch to systemd? anybody have strong feeling about it?

I have a strong feeling about it. I switched to Debian from Arch to get away from systemd. I couldn't even get it to set the freaking clock on boot. After spending a few days in systemd hell, I decided it's way, way, way overkill for a simple Plug.

-JT

pbg4,

> concerning systemd I have the same mixed feelings
> about it as bodhi has, so I am not holding
> my breath to see it arrive in armv5 kirkwood
> mainline land

:) exactly. I think dreading is another word for it!

JT,

Whatever we will do, it should be possible to boot either sysvinit or systemd. The only problem is when it's time to do apt-get upgrade and then we see some Debian packages being held back because of systemd dependencies, that's when things get interesting :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> The only problem is when it's time to do apt-get upgrade and then we
> see some Debian packages being held back because
> of systemd dependencies, that's when things get
> interesting :)

With the 4.0 kernel I've already observed some of that, things being held back when I updated, upgraded or added a new program. I didn't know the reason why but now I know.

LeggoMyEggo,

> With the 4.0 kernel I've already observed some of
> that, things being held back when I updated,
> upgraded or added a new program. I didn't know
> the reason why but now I know.

You could boot with systemd temporarily, as I mentioned:
http://forum.doozan.com/read.php?2,12096,21660#msg-21660

then do apt-get upgrade, and then switch back to sysvinit (remove the uEnv.txt). But please do this at your own risk, backup your rootfs first :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Good point....

@renojim

Did you try looking at the arch wiki? its easy to set the time aparently with this:

https://wiki.archlinux.org/index.php/Systemd-timesyncd

And on the systemd thing. I vote for systemd everyone shouldnt be held back on sysv or whatever just because a few people dont know how (or refuse to learn) to use systemd. I have switched all my plugs and linux machines over to systemd and had no issue's at all. (unless you call faster booting an issue)

Reminder: I didn't mean to have a debate about pros/cons :) I think we have enough of that in the net. I guess by now most everybody who's been following the controversy has already formed their opinions.

But of course, if anbody wants to start a new thread to discuss/debate about the issue, please do.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 05/06/2015 04:10AM by bodhi.

Maybe it's time to start a new Debian for Kirkwood thread in general. This is now 34 pages of packed information.

Hi bodhi,

Would it be possible to include qmi_wwan as a module in your next kernel compilations?
I need it to be able to use my LTE USB stick as an ethernet device, using the libqmi-utils package.

Thank you