Differences between kernels?

Daniel Kulp

unread,

Mar 12, 2018, 11:38:47 AM3/12/18

to BeagleBoard

Is there a document or something that describes the differences between the --bone, --armv7, and --ti kernels? Why to choose one over the other? etc....

I've been using the --ti --lts-4_14, but recent versions are completely broken for advanced WIFI use cases so I'm kind of trying to figure out what options I have to replace it. Sometime between 4.14.13-ti-r25 and the current 4.14 version, someone made the boneheaded (pun intended, no offense intended) to include the USB wifi adapters as builtins instead of modules. This completely breaks any usage of external wifi modules that work "better" (or in some cases, actually work). We cannot blacklist the builtin modules (even tried the command line params, didn't work). And even without blacklist, they don't work as the firmwares needed by the wifi adapters are not included in the initial rd. I'm not sure why they are now built in instead of modules, but it's certainly a huge step backwards IMO.

I can stay on 4.14.13-ti-r25 which works fine, but I'm not sure what fixes and such I'd be missing out on going forward. The --bone kernels don't seem to have btrfs which, while not critical, is something we've been looking closer at for the COW and compression. The armv7 kernel seems to work for both btrfs and wifi, but I really don't know what else I'm missing out on with that version.

Robert Nelson

unread,

Mar 12, 2018, 12:04:23 PM3/12/18

to Beagle Board

On Mar 12, 2018 8:39 AM, "Daniel Kulp" <d...@kulp.com> wrote:

Is there a document or something that describes the differences between the --bone, --armv7, and --ti kernels? Why to choose one over the other? etc....

Bone = am335x targets, no smp

armv7 = all armv7 including things that will slow done am335x

Ti = utilizes TI sdk kernel.. aka ti engineers get paid to support that kernel.. patches end up mainline..

I've been using the --ti --lts-4_14, but recent versions are completely broken for advanced WIFI use cases so I'm kind of trying to figure out what options I have to replace it. Sometime between 4.14.13-ti-r25 and the current 4.14 version, someone made the boneheaded (pun intended, no offense intended) to include the USB wifi adapters as builtins instead of modules. This completely breaks any usage of external wifi modules that work "better" (or in some cases, actually work). We cannot blacklist the builtin modules (even tried the command line params, didn't work). And even without blacklist, they don't work as the firmwares needed by the wifi adapters are not included in the initial rd. I'm not sure why they are now built in instead of modules, but it's certainly a huge step backwards IMO.

That's me, was trying to speed up boot times, we can revert it back to modules.

I can stay on 4.14.13-ti-r25 which works fine, but I'm not sure what fixes and such I'd be missing out on going forward. The --bone kernels don't seem to have btrfs which, while not critical, is something we've been looking closer at for the COW and compression. The armv7 kernel seems to work for both btrfs and wifi, but I really don't know what else I'm missing out on with that version.

Let me know which ones have btrfs disabled, as they should be enabled again.

Regards

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/31fc75f9-8fb4-474d-95f9-e0cce232eee2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Daniel Kulp

unread,

Mar 12, 2018, 12:31:01 PM3/12/18

to BeagleBoard

On Monday, March 12, 2018 at 12:04:23 PM UTC-4, RobertCNelson wrote:

Bone = am335x targets, no smp

Ti = utilizes TI sdk kernel.. aka ti engineers get paid to support that kernel.. patches end up mainline..

If I'm ONLY targeting the BeagleBone Blacks and PocketBeagles where we know we don't need SMP, is there a reason to go -ti vs. -bone?

The -bone images seems to boot slightly faster.

I've been using the --ti --lts-4_14, but recent versions are completely broken for advanced WIFI use cases so I'm kind of trying to figure out what options I have to replace it. Sometime between 4.14.13-ti-r25 and the current 4.14 version, someone made the boneheaded (pun intended, no offense intended) to include the USB wifi adapters as builtins instead of modules. This completely breaks any usage of external wifi modules that work "better" (or in some cases, actually work). We cannot blacklist the builtin modules (even tried the command line params, didn't work). And even without blacklist, they don't work as the firmwares needed by the wifi adapters are not included in the initial rd. I'm not sure why they are now built in instead of modules, but it's certainly a huge step backwards IMO.

That's me, was trying to speed up boot times, we can revert it back to modules.

That would be great if we could. They really aren't working as modules. With the -bone kernel, I can easily get the Wifi built onto the SanCloud BeagleBone Enhanced to work. I haven't managed to get it to work at all with the latest -ti 4.14 kernels. wlan0 doesn't even appear due to the lack of firmware.

I'm also getting a strange stack trace in dmsg with 4.14.25-ti-r38. It seems to be ignorable, but it's concerning to see:

[   71.453332] WARNING: CPU: 0 PID: 1119 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x78/0x88
[   71.453338] sysfs: cannot create duplicate filename '/bus/platform/devices/4a300000.pruss'
[   71.453343] Modules linked in: pruss_soc_bus(+) uio_pruss(+) btusb btrtl btbcm btintel bluetooth ecdh_generic 8021q garp mrp stp llc evdev uio_pdrv_genirq uio usb_f_acm u_serial usb_f_ecm usb_f_rndis u_ether libcomposite iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_filter ip_tables x_tables
[   71.453467] CPU: 0 PID: 1119 Comm: systemd-udevd Not tainted 4.14.25-ti-r38 #1
[   71.453472] Hardware name: Generic AM33XX (Flattened Device Tree)
[   71.453516] [<c0113a50>] (unwind_backtrace) from [<c010dcec>] (show_stack+0x20/0x24)
[   71.453537] [<c010dcec>] (show_stack) from [<c0f3d4d0>] (dump_stack+0x8c/0xa0)
[   71.453553] [<c0f3d4d0>] (dump_stack) from [<c013f338>] (__warn+0xf8/0x110)
[   71.453564] [<c013f338>] (__warn) from [<c013f3a8>] (warn_slowpath_fmt+0x58/0x74)
[   71.453576] [<c013f3a8>] (warn_slowpath_fmt) from [<c0385cd0>] (sysfs_warn_dup+0x78/0x88)
[   71.453590] [<c0385cd0>] (sysfs_warn_dup) from [<c0385fe0>] (sysfs_do_create_link_sd+0xc4/0xd4)
[   71.453601] [<c0385fe0>] (sysfs_do_create_link_sd) from [<c0386028>] (sysfs_create_link+0x38/0x44)
[   71.453614] [<c0386028>] (sysfs_create_link) from [<c092db1c>] (bus_add_device+0x78/0x134)
[   71.453637] [<c092db1c>] (bus_add_device) from [<c092b758>] (device_add+0x298/0x5d0)
[   71.453654] [<c092b758>] (device_add) from [<c0c6b894>] (of_device_add+0x44/0x4c)
[   71.453667] [<c0c6b894>] (of_device_add) from [<c0c6be60>] (of_platform_device_create_pdata+0x84/0xb4)
[   71.453678] [<c0c6be60>] (of_platform_device_create_pdata) from [<c0c6c02c>] (of_platform_bus_create+0x178/0x310)
[   71.453689] [<c0c6c02c>] (of_platform_bus_create) from [<c0c6c398>] (of_platform_populate+0x84/0x120)
[   71.453721] [<c0c6c398>] (of_platform_populate) from [<bf32d2e4>] (pruss_soc_bus_probe+0x13c/0x26c [pruss_soc_bus])
[   71.453766] [<bf32d2e4>] (pruss_soc_bus_probe [pruss_soc_bus]) from [<c0931374>] (platform_drv_probe+0x60/0xc0)
[   71.453777] [<c0931374>] (platform_drv_probe) from [<c092ee24>] (driver_probe_device+0x2a8/0x460)
[   71.453787] [<c092ee24>] (driver_probe_device) from [<c092f0dc>] (__driver_attach+0x100/0x10c)
[   71.453799] [<c092f0dc>] (__driver_attach) from [<c092c90c>] (bus_for_each_dev+0x8c/0xd0)
[   71.453810] [<c092c90c>] (bus_for_each_dev) from [<c092e5dc>] (driver_attach+0x2c/0x30)
[   71.453819] [<c092e5dc>] (driver_attach) from [<c092df20>] (bus_add_driver+0x16c/0x26c)
[   71.453828] [<c092df20>] (bus_add_driver) from [<c092fe38>] (driver_register+0x88/0x104)
[   71.453838] [<c092fe38>] (driver_register) from [<c09312c0>] (__platform_driver_register+0x50/0x58)
[   71.453854] [<c09312c0>] (__platform_driver_register) from [<bf332020>] (pruss_soc_bus_driver_init+0x20/0x1000 [pruss_soc_bus])
[   71.453873] [<bf332020>] (pruss_soc_bus_driver_init [pruss_soc_bus]) from [<c0101ca8>] (do_one_initcall+0x64/0x19c)
[   71.453894] [<c0101ca8>] (do_one_initcall) from [<c01e3a88>] (do_init_module+0x74/0x20c)
[   71.453907] [<c01e3a88>] (do_init_module) from [<c01e2a48>] (load_module+0x21c4/0x2890)
[   71.453919] [<c01e2a48>] (load_module) from [<c01e32cc>] (SyS_init_module+0x1b8/0x1d4)
[   71.453936] [<c01e32cc>] (SyS_init_module) from [<c0108f80>] (__sys_trace_return+0x0/0x10)

I can stay on 4.14.13-ti-r25 which works fine, but I'm not sure what fixes and such I'd be missing out on going forward. The --bone kernels don't seem to have btrfs which, while not critical, is something we've been looking closer at for the COW and compression. The armv7 kernel seems to work for both btrfs and wifi, but I really don't know what else I'm missing out on with that version.

Let me know which ones have btrfs disabled, as they should be enabled again.

Hmm.. just tested with 4.15.9-bone4 and it seems to be working there. I'm not sure what version I was using a few weeks ago where it didn't. Not a concern then. :)