This makes the backlight on teh 7" LCD cape work again. Also add a patch to
print the hardware revision of the cape.
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
This fixes most PM operations: cpufreq, cpuidle and suspend. Resume does not
work on beaglebone, but 3 out of 4 ain't bad :)
The M3 firmware needed for suspend/resume is used as a binary, building it
from source and including it from sysroots is planned for future commits.
Beaglebone patches have been forward ported and runtime tested.
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
The function get_kernelversion uses generated header files to extract the
version number. But those files are not available until do_compile, and
do_compileconfigs is injected before that, hence the version becomes None
and breaks in several places.
Introduce a new task do_preparekernel that calls "make prepare" in the
kernel tree to generate all the necessary files. It's also safer to call
do_configure early on.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
And move it to a separate .inc for other kernels to use.
Signed-off-by: Denys Dmytriyenko <denis@denix.org>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Backport Nishants OPP/hwmod fix to get more than 600MHz out of 37xx, but don't
activate it yet. 3630ES1.2 derived silicon gets misdetected:
xM revision A:
[ 0.000000] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk )
new xM revision C:
[ 0.000000] OMAP3630 ES1.2 (l2cache neon isp 192mhz_clk )
Since the iva hwmod is missing the OPP tables will fail and clock it back to
600MHz. But with the patch the kernel hangs in early init. This problem isn't
specific to this kernel update, it just coincided with ES1.2 silicon arriving
on my desk.
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Also add script used to generate patches and SRC_URI
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
This fixes below error found on some distros (Gentoo and Fedora):
*** No rule to make target `lib/firmware/./', needed by `lib/firmware/ti_3410.fw'. Stop.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
It has been completely replaced with the 'pandaboard' machine config.
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
BitBake's fetch2 unpack() seems to be picky about multi-kernel's
file://configs/* and defaults to only looking into machine-specific
location. This fixes the issue, as tested by building these platforms:
beaglebone, am335x-evm and am180x-evm.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
* Added a defconfig file for the am335x-evm and moved the common
configs directory from the beaglebone directory to the top
of the kernel files tree.
Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
The production tester breaks with DMA disabled, so enable it again. Any breakage due to this should get reported to TI PSP so they can fix it.
This effectively reverts aa209df889
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
There is a conflict with eglibc headers since
new headers added the defines that compiler.h
was redefining without undefining them
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Acked-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
When a recipe is being parsed which will be skipped due to an incompatible
machine, no local defconfig will exist for the current machine. It seems that
the fetch localpath code doesn't error in that case, so we need to check for an
IOError on the attempted open. Without this, we can hit parse errors.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Koen Kooi
Denys Dmytriyenko
Denys Dmytriyenko
Chase Maupin
Khem Raj
Christopher Larson