- Apr 14, 2022
-
-
Robert Nelson authored
5.10.109-ti-rt-r42 bb.org_defconfig 5.10 TI Delta: https://github.com/RobertCNelson/ti-linux-kernel/compare/889f3543f82bef1b829db4671be4a47ee33e0e92...f5bfe6804bb2f40045ca15db46533220292a12eb AUFS: https://github.com/sfjro/aufs5-standalone/commit/19ba863e92709d8b21915752565a146fd8620eaa BBDTBS: https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/583eb19c082241bda7b4e49da64ac238cc8709fb RT: patch-5.10.109-rt65.patch.xz TI_AMX3_CM3: http://git.ti.com/gitweb/?p=processor-firmware/ti-amx3-cm3-pm-firmware.git;a=commit;h=fb484c5e54f2e31cf0a338d2927a06a2870bcc2c WPANUSB: https://github.com/statropy/wpanusb/commit/251f0167545bf2dcaa3cad991a59dbf5ab05490a BCFSERIAL: https://github.com/statropy/bcfserial/commit/aded88429a8a00143596b41f4c1f50d9ae3d4069 WIRELESS_REGDB: https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/commit/?id=166fbddc84ba13f17b133073331e015e0f52f0da KSMBD: https://github.com/cifsd-team/ksmbd/commit/fc1c6308ceb02282f5386c1f264b07e901bf31f2 Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
-
http://gfnd.rcn-ee.org:8080Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Juerg Haefliger authored
GCC 11 on ARM now complains like the following when trying to determine if an arch is supported. Presumably because it enforces the default option '--with-float=hard' which GCC 10 didn't do? $ arm-linux-gnueabihf-gcc-11 -march=armv7-a -c -x c /dev/null cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU Due to that, the kernel build system selects the wrong compiler options which throws errros like this during the build: /tmp/ccrHfZPj.s: Assembler messages: /tmp/ccrHfZPj.s:116: Error: selected processor does not support `dmb ish' in ARM mode /tmp/ccrHfZPj.s:150: Error: selected processor does not support `isb ' in ARM mode /tmp/ccrHfZPj.s:160: Error: selected processor does not support `mrrc p15,1,r4,r5,c14' in ARM mode /tmp/ccrHfZPj.s:245: Error: selected processor does not support `dmb ish' in ARM mode /tmp/ccrHfZPj.s:503: Error: selected processor does not support `dmb ish' in ARM mode /tmp/ccrHfZPj.s:527: Error: selected processor does not support `dmb ish' in ARM mode /tmp/ccrHfZPj.s:698: Error: selected processor does not support `dmb ish' in ARM mode /tmp/ccrHfZPj.s:731: Error: selected processor does not support `isb ' in ARM mode Fix that by adding '-msoft-float' to KBUILD_CFLAGS before the definition of the 'arch-$(CONFIG_CPU_<foo>)' instruction selection macros. Signed-off-by:Juerg Haefliger <juergh@canonical.com>
-
Matthijs van Duin authored
"uio" for generic use "ti,pruss-shmem" for backwards compatibility the of_id module parameter is still supported to add another id
-
Matthijs van Duin authored
-
Robert Nelson authored
already default on BBB/X15, just calcuated everybootup Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Paul Barker authored
Taken from commit 8e407b62f2ed89fe41c40a976669df1693cf7027 in https://github.com/boundarydevices/linux-imx6 . Ref: BSP-65 Signed-off-by:
Paul Barker <paul.barker@sancloud.com>
-
Paul Barker authored
Taken from commit 8e407b62f2ed89fe41c40a976669df1693cf7027 in https://github.com/boundarydevices/linux-imx6 . Ref: BSP-65 Signed-off-by:
-
Paul Barker authored
Taken from commit 8e407b62f2ed89fe41c40a976669df1693cf7027 in https://github.com/boundarydevices/linux-imx6 . cfg80211: Using new wiphy flag WIPHY_FLAG_DFS_OFFLOAD When flag WIPHY_FLAG_DFS_OFFLOAD is defined, the driver would handle all the DFS related operations. Therefore the kernel needs to ignore the DFS state that it uses to block the userspace calls to the driver through cfg8021 APIs. Also it should treat the userspace calls to start radar detection as a no-op. Ref: BSP-65 Signed-off-by:
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Jason Kridner authoredOriginal Commit : https://github.com/beagleboard/linux/commit/8884f22a6b3a5217177c2f843e5c83d613bc6676 Signed-off-by:
Jason Kridner <jkridner@beagleboard.org>
-
Robert Nelson authored
#<Daulity> is there a kernel option to not reset gpio state at linux boot ? #<zmatt> Daulity: the kernel does not reset any gpio unless explicitly requested to by a driver #<zmatt> though by default if cape-universal is enabled then a gpio-of-helper device gets set up which configures all gpios as input... though that is normally the state they are in anyway after reset #<zmatt> Daulity: why? are you setting gpios in u-boot? #<Daulity> yes u-boot sets a few gpio's before it boots the kernel they get reset to a certain state not certain if u-boot or linux kernel #<Daulity> was just wondering #<zmatt> the annoying bit is that this isn't really fixable by applying an overlay on top of cape-universal due the the limitations of overlays and the fact that status="disabled"; doesn't work on individual gpios of a gpio-of-helper device node #<zmatt> so your options are to modify the cape-universal overlay or disable cape-universal entirely and use an overlay to declare/export gpios (with initialization of your choice) #<Daulity> i see #<zmatt> (or fix the gpio-of-helper drivers to respect the status property of individual gpios... which is probably a 2-line patch) #<zmatt> *driver #<zmatt> interesting, if CONFIG_OF_KOBJ=n then nodes with non-okay status property don't even get deserialized, however in practice CONFIG_OF_KOBJ is always y (specifically, it is only n in kernels that lack sysfs support) #<zmatt> yeah it's definitely a 2-line fix #<zmatt> https://pastebin.com/f8V8pz1V #<Daulity> thanks :) #<zmatt> rcn-ee: can you include that patch? that way overlays can disable cape-universal's gpio export for individual gpios used by the overlay #<zmatt> e.g. &ocp { cape-universal { P9_14 { status = "disabled"; }; }; }; #<zmatt> Daulity: you can use that in an overlay and then if you still want the gpio exported you can just declare your own gpio-of-helper ... unfortunately it doesn't support exporting a gpio without initializing it, but at least you can choose *how* to initialize it (input, output-low, output-high) and whether or not linux userspace is allowed to change the direction of the gpio Signed-off-by:
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
hack: gpiolib: yes we have drivers stomping on each other, we need to find a better way to share gpio... Signed-off-by: -
Robert Nelson authored
Authors: Pantelis Antoniou <panto@antoniou-consulting.com> Charles Steinkuehler <charles@steinkuehler.net> Jason Kridner <jdk@ti.com> Robert Nelson <robertcnelson@gmail.com> Tobias Müller <Tobias_Mueller@twam.info> Matthijs van Duin <matthijsvanduin@gmail.com> This patch was derived from 19 commits: https://github.com/RobertCNelson/linux-dev/tree/35e301ae8436e9f56f65bf1a7440021eda42f948/patches/drivers/ti/gpio Signed-off-by:
-
Robert Nelson authored
Authors: Pantelis Antoniou <panto@antoniou-consulting.com> Charles Steinkuehler <charles@steinkuehler.net> Jason Kridner <jdk@ti.com> Robert Nelson <robertcnelson@gmail.com> Tobias Müller <Tobias_Mueller@twam.info> Matthijs van Duin <matthijsvanduin@gmail.com> This patch was derived from 19 commits: https://github.com/RobertCNelson/linux-dev/tree/35e301ae8436e9f56f65bf1a7440021eda42f948/patches/drivers/ti/gpio Signed-off-by:
-
frost authored
-
bigguiness@gmail.com authored
------=_Part_422_1349561576.1515022447432 Content-Type: text/plain; charset="UTF-8" Hello all, The TI touch screen driver does not work _right_ with the libts-bin package in the jessie image. $ cat /etc/dogtag BeagleBoard.org Debian Image 2018-01-01 $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 8.10 (jessie) Release: 8.10 Codename: jessie $ dpkg -l | grep libts-bin ii libts-bin 1.14-1rcnee0~jessie+20171122 armhf touch screen library utilities $ sudo ts_calibrate ts_setup: No such file or directory It is possible to make it work by setting the TSLIB_TSDEVICE environment variable: $ sudo su # export TSLIB_TSDEVICE=/dev/input/event2 # ts_calibrate But, that's a bit of a pain since the environment variable always needs to be set in order to use the touchscreen. It appears that this version of the utilities uses the INPUT_PROP_DIRECT propbit to automatically detect which /dev/input/event device is the touchscreen. It looks like the following is the only change needed to make it work. Unfortunately, I don't have currently have a way to build a custom kernel for the BeagleBone in order to test it. If there is anyone that could I would appreciate it. Regards, Hartley -
Robert Nelson authored
This reverts commit 3c9dc275 . Signed-off-by:
-
Robert Nelson authored
Signed-off-by: -
Will Eccles authored
When CONFIG_PM is not enabled, the function davinci_mdio_update_dt_from_phymask is not defined. This patch fixes this so that the build does not fail with CONFIG_PM disabled. Signed-off-by:Will Eccles <will@eccles.dev>
-
Jay at Control Module Industries authored
I have encountered the same issue(s) on A6A boards. I couldn't find a patch, so I wrote this patch to update the device tree in the davinci_mdio driver in the 3.15.1 tree, it seems to correct it. I would welcome any input on a different approach. https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/SRlnumt0LoMJ v4.1-rcX: added hack around CONFIG_OF_OVERLAY v4.2-rc3+: added if (of_machine_is_compatible("ti,am335x-bone")) so we do not break dual ethernet am335x devices Signed-off-by:
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
This reverts commit 956b200a . Signed-off-by:
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
This reverts commit 26c7295b . Signed-off-by:
-
Robert Nelson authored
Signed-off-by: -
Robert Nelson authored
v5.10.9-2021_1020 Signed-off-by: -
Robert Nelson authored
Reference: v5.10.9 Signed-off-by: -
Robert Nelson authored
Reference: v5.15.34 Signed-off-by: -
Robert Nelson authored
Reference: v5.10.111 Signed-off-by: -
Robert Nelson authored
Reference: v5.13.19 Signed-off-by: -
Robert Nelson authored
Reference: v5.13.19 Signed-off-by: -
-
