- Dec 23, 2021
-
-
Robert Nelson authored
5.10.87-ti-r33 bb.org_defconfig 5.10 TI Delta: https://github.com/RobertCNelson/ti-linux-kernel/compare/4575f9eb57c262823be0258cc9b08ea8b8d9b839...af8d45d947327131c662f7c9804e1b24b05336f5 AUFS: https://github.com/sfjro/aufs5-standalone/commit/699f36528140b978db40f9216d263adaca7607cd BBDTBS: https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/c7f7ee1f2ed1522d5857c7e21c0069508eb341f8 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=e0612994444d5fc21ba0f08877e367a2b3de431b KSMBD: https://github.com/cifsd-team/ksmbd/commit/ea4274db5c323d5c3b8a0d7f02c122dd2869e09e Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
-
http://gfnd.rcn-ee.org:8080Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
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>
-
Robert Nelson authored
already default on BBB/X15, just calcuated everybootup Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Jason Kridner authored
Original 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 <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
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 <robertcnelson@gmail.com>
-
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 <robertcnelson@gmail.com>
-
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 <robertcnelson@gmail.com>
-
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 <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
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 <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
This reverts commit 956b200a . Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
This reverts commit 26c7295b . Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
v5.10.9-2021_1020 Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Reference: v5.10.9 Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Reference: v5.15.11 Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Reference: v5.13.19 Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Reference: v5.13.19 Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Reference: v5.12.19 Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-
Robert Nelson authored
Signed-off-by:
Robert Nelson <robertcnelson@gmail.com>
-