Hi guys!
I can see Robert offers 3 kernel vesions for bbb:
- v3.8.x
- v3.13.x
- v3.15.x
who can tell pros and cons for each of them? I need one to prepare something stable/reliable for my client.
Thanks!
Hi guys!
I can see Robert offers 3 kernel vesions for bbb:
- v3.8.x
- v3.13.x
- v3.15.x
They all seem to work fine. I think v3.15 seems to have better USB and Ethernet stability. Given that there is no Cape Manager after v3.8, there is a little more work required to get a cape to work. Other than that, they all seem to be pretty stable.
Regards,
John
v3.8.x = capemgr
v3.13.x = working sgx
v3.15.x = it's going to be short lived, planing to moving to v3.16.x
pretty soon, as that'll have a "rt" and it should be the default for
"jessie"
Regards,
Hi guys!
I can see Robert offers 3 kernel vesions for bbb:
1) v3.8.x
2) v3.13.x
3) v3.15.xwho can tell pros and cons for each of them? I need one to prepare
something
stable/reliable for my client.v3.8.x = capemgr
v3.13.x = working sgx
v3.15.x = it's going to be short lived, planing to moving to v3.16.x
pretty soon, as that'll have a "rt" and it should be the default for
"jessie"
That is good to know. Thanks for the info. Oh, one more thing, V3.15
doesn¹t shutdown fully. Still got to work on this. Been distracted with
getting NFS and Audio working on V3.15.
Regards,
John
I don't see any mention of 3.14. I have been using 3.14.8-bone5 for quite a few weeks now. I could never get USB to work on 3.15.x. Should I revert to 3.13.x??
Dave.
I don't see any mention of 3.14. I have been using 3.14.8-bone5 for
quite a few weeks now. I could never get USB to work on 3.15.x. Should I
revert to 3.13.x??
USB is working fine for me on V3.15.4-bone4. What is it that you are
trying to do that does not work?
Here is an example of USB working on V3.15:
I have a Ortek Wireless keyboard and mouse connected to a powered USB Hub.
root@arm:~# lsusb
Bus 002 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 003: ID 05a4:2000 Ortek Technology, Inc. WKB-2000 Wireless
Keyboard with Touchpad
Now I insert a SanDisk USB flash drive:
root@arm:~# [23389.316005] usb 2-1.2: new high-speed USB device number 4
using musb-hdrc
[23389.416641] usb 2-1.2: device v0781 p5575 is not supported
[23389.422448] usb 2-1.2: New USB device found, idVendor=0781,
idProduct=5575
[23389.429756] usb 2-1.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[23389.437477] usb 2-1.2: Product: Cruzer Glide
[23389.441974] usb 2-1.2: Manufacturer: SanDisk
[23389.446499] usb 2-1.2: SerialNumber: 20043515931AE20186C5
[23389.454569] usb-storage 2-1.2:1.0: USB Mass Storage device detected
[23389.462767] scsi0 : usb-storage 2-1.2:1.0
[23390.467381] scsi 0:0:0:0: Direct-Access
SanDisk Cruzer Glide
1.26 PQ: 0 ANSI: 5
[23390.481964] sd 0:0:0:0: [sda] 15633408 512-byte logical blocks: (8.00
GB/7.45 GiB)
[23390.502368] sd 0:0:0:0: [sda] Write Protect is off
[23390.515109] sd 0:0:0:0: [sda] Write cache: disabled, read cache:
enabled, doesn't support DPO or FUA
[23390.551041] sda: sda1 sda2
[23390.565653] sd 0:0:0:0: [sda] Attached SCSI removable disk
So plug&play works fine. Confirm the SanDisk drive was recognized
correctly:
root@arm:~# lsusb
Bus 002 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 0781:5575 SanDisk Corp.
Bus 002 Device 003: ID 05a4:2000 Ortek Technology, Inc. WKB-2000 Wireless
Keyboard with Touchpad
Mount the Drive:
root@arm:/media# mount /dev/sda1 diska
mount: block device /dev/sda1 is write-protected, mounting read-only
Display drive contents:
root@arm:/media# ls diska
autorun.inf doc
install
pool
README.txt
boot
efi
install.amd README.html
setup.exe
css
firmware isolinux
README.mirrors.html tools
debian
g2ldr
md5sum.txt README.mirrors.txt win32-loader.ini
dists
g2ldr.mbr pics
README.source
Regards,
John
Thanks John. Further investigation revealed that something has changed that causes my cape dtb to interfere with USB 
Dave.
I think the usb node address register changed in v3.15.x.
Regards,
Thanks so much Robert - I think you nailed it! Unfortunately I did not inherit this change as I could not import am335x-bone-common.dtsi due to the clash:
/* pinctrl-0 = <&clkout2_pin>; clash with argus-ups */
Regards,
Dave.
I'll clean that up in a bit and push it.. I have another patch from
John for audio too, so i'll get a new bone tag released this evening..
Regards,
Also I found this one.
/* pinctrl-0 = <&ecap0_pin_p9_42>; clash with Argus */
Not sure of the best way to handle these sort of situations. Currently I am just copying then editing the contents of am335x-bone-common.dtsi into my dts. This is obviously a very messy hack. Maybe am335x-bone-common.dtsi could be subdivided into smaller chunks???
Regards,
Thanks so much Robert - I think you nailed it! Unfortunately I did not
inherit this change as I could not import am335x-bone-common.dtsi due to
the
clash:/* pinctrl-0 = <&clkout2_pin>; clash with argus-ups */
I'll clean that up in a bit and push it.. I have another patch from
John for audio too, so i'll get a new bone tag released this evening..Regards,
Also I found this one.
/* pinctrl-0 = <&ecap0_pin_p9_42>; clash with Argus */
Here's what i came up for the v3.15.x branch. This should make usb work now..
Not sure of the best way to handle these sort of situations. Currently I am
just copying then editing the contents of am335x-bone-common.dtsi into my
dts. This is obviously a very messy hack. Maybe am335x-bone-common.dtsi
could be subdivided into smaller chunks???
Yeah, it needs to be cleaned up badly.. It's only getting worse with
more patches on linux-omap.. We just need a weekend, few kegs and do a
cleanup..
1: am335x-bone-common.dtsi (only common stuff and all pinmux's)
2: am335x-boneblack-common.dtsi (no eMMC/HDMI/HDMI Audio)
3: am335x-boneblack-eMMC.dtsi
4: am335x-boneblack-HDMI.dtsi
5: am335x-boneblack-HDMIA.dtsi
am335x-bone.dtb = (1)
am335x-boneblack.dtb = (1+2+3+4+5)
Then it should be easy to expand on "am335x-boneblack-common.dtsi" and
enable your cape.
Regards,
Thanks so much Robert - I think you nailed it! Unfortunately I did not
inherit this change as I could not import am335x-bone-common.dtsi due
to
the
clash:/* pinctrl-0 = <&clkout2_pin>; clash with argus-ups */
I'll clean that up in a bit and push it.. I have another patch from
John for audio too, so i'll get a new bone tag released this evening..Regards,
Also I found this one.
/* pinctrl-0 = <&ecap0_pin_p9_42>; clash with Argus */Here's what i came up for the v3.15.x branch. This should make usb work
now..dts: bone argus: fix usb · RobertCNelson/bb-kernel@e34510a · GitHub
ba84e8ea8752f7f0Not sure of the best way to handle these sort of situations. Currently
I am
just copying then editing the contents of am335x-bone-common.dtsi into
my
dts. This is obviously a very messy hack. Maybe am335x-bone-common.dtsi
could be subdivided into smaller chunks???Yeah, it needs to be cleaned up badly.. It's only getting worse with
more patches on linux-omap.. We just need a weekend, few kegs and do a
cleanup..1: am335x-bone-common.dtsi (only common stuff and all pinmux's)
2: am335x-boneblack-common.dtsi (no eMMC/HDMI/HDMI Audio)
3: am335x-boneblack-eMMC.dtsi
4: am335x-boneblack-HDMI.dtsi
5: am335x-boneblack-HDMIA.dtsiam335x-bone.dtb = (1)
am335x-boneblack.dtb = (1+2+3+4+5)
I¹m not sure this is going to be that easy. Some sections such as I2C
cross multiple boundaries. I¹m not sure this can be done until we have
mainline DT overlays.
It’s only getting worse with more patches on linux-omap…
Wow! Previously the device tree was invented because of the craziness in the arm architecture, especially in the omap tree. Now we see another craziness in the device tree. The world is not perfect, right?
Robert,
What is a "rt"?
Regards,
Dave.
Thanks Robert. That works fine!
Regards,
Dave.
Robert,
I seem to have an issue with my am335x-boneblack-cape-bone-argus.dts in 3.16.0-rc7-bone1. This time it appears that there is a clash with the Ethernet subsystem. Has something changed in this area from 3.15?
Regards,
Dave.
Robert,
For your perusal, I have attached my patch to get my cape peacefully coexisting (I hope) with the changes in 3.16.
Best regards,
Dave.
0001-Updated-dts-to-be-in-line-with-3.16-changes.patch (6.62 KB)