Hello,
I submitted a patch for "flash-kernel" to Ubuntu to solve this problem:
> Kernel /boot/vmlinuz-3.4.0-1-linaro-lt-omap does not match your subarchitecture
> omap4, therefore not writing it to flash.
The problem has been reported as
https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1023952
I submitted a patch, but for the patch to be included in a "stable
release update" (aka SRU), it needs to be tested on a BeagleBoard-xM.
If you are running Ubuntu on a BeagleBoard-xM, will you help me test
this patch?
--
Thank you,
David Cullen
> Date: Tue, 10 Jul 2012 14:12:01 +0000
> From: Arnd Bergmann <arnd(a)arndb.de>
> To: linux-arm-kernel(a)lists.infradead.org
> Cc: linaro-dev(a)lists.linaro.org, linux-kernel(a)vger.kernel.org,
> "Rajanikanth H.V" <rajanikanth.hv(a)stericsson.com>,
patches(a)linaro.org
> Subject: Re: [PATCH] mfd: Implement devicetree support for AB8500
> Btemp
> Message-ID: <201207101412.01561.arnd(a)arndb.de>
> Content-Type: Text/Plain; charset="utf-8"
>
> On Tuesday 10 July 2012, Rajanikanth H.V wrote:
>
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt
>> @@ -0,0 +1,54 @@
>> +AB8500 Battery Termperature Monitor Driver
>> +
>> +AB8500 is a mixed signal multimedia and power management
>> +device comprising: power and energy management module,
>> +WalliCharger and USB charger interface, audio, general
>> +purpose ADC TVOut, clock management and SIM card Interface.
>> +
>> +Battery temperature monitoring support is part of 'energy
>> +management module', the other components of this module
>> +are: 'main and USB Combo charger' and fuel guage.
>> +
>> +The properties below describes the node for battery
>> +temperature monitor driver.
>> +
>> +Required Properties:
>> +- compatible = "stericsson,ab8500-btemp"
>> +
>> +interrupts:
>> + Four battery temperature ranges are be defined
>> + which results in interrupt events as:
>> + - Btemp
>> + - BtempLow
>> + - BtempMedium
>> + - BtempHigh
>> +
>
> These names do not match the five interrupts in the example or in the
> code. When you provide an "interrupt-names" property you have to define
> the exact strings that are permissible for them in the binding.
>
>> +Supplied-to:
>> + This shall be power supply class dependency where in the
runtime battery
>> + properties will be shared across fuel guage and charging
algorithm driver.
>
> I probably don't understand enough of this, but shouldn't the other
devices
> that are supplied by this have a reference to this node rather than doing
> it this way around? Why use strings here instead of phandles?
This is a logical binding w.r.t power supply event change
across energy-management-module drivers where in runtime battery
properties are shared along with uevent notification.
ref: di->btemp_psy.external_power_changed =
ab8500_btemp_external_power_changed;
ref: ab8500_btemp.c
Need for this property:
btemp, fg and charger updates power-supply properties
based on the events listed above.
Event handler invokes power supply change notifier
which in-turn invokes registered power supply class call-back
based on the 'supplied_to' string.
ref:
power_supply_changed_work(..) ./drivers/power/power_supply_core.c
In this case how to approach through phandle?
>
> You are also not listing some of the properties that are in the device
> tree here, like the "interrupts" property itself.
>
>> diff --git a/arch/arm/mach-ux500/board-mop500-bm.c
b/arch/arm/mach-ux500/board-mop500-bm.c
>> new file mode 100644
>> index 0000000..3349ceb
>> --- /dev/null
>> +++ b/arch/arm/mach-ux500/board-mop500-bm.c
>
> Didn't we conclude that this file has no board-specific information in it?
> Either explain why it's still here, or move it into the driver itself.
>
>> +/*
>> + * Note that the batres_vs_temp table must be strictly sorted by falling
>> + * temperature values to work.
>> + */
>> +#ifdef CONFIG_AB8500_9100_LI_ION_BATTERY
>> +#define BATRES 180
>> +#else
>> +#define BATRES 300
>> +#endif
>
> I think I mentioned before that you need to get rid of the
> CONFIG_AB8500_9100_LI_ION_BATTERY symbol. If you have exclusive
> compile-time options, it is impossible to build a kernel that
> runs on all system, so this has to be a run-time option.
>
> Arnd
>
>
>
Hi,
Sorry if I am missing something very obvious, I am building OMAP for the
first time.
I fetched latest kernel from:
http://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=shortlog;…
tried to do following:
make ARCH=arm O=../panda omap2plus_defconfig (After this, OMAP 2/3/4 none
is selected in .config)
make ARCH=arm O=../panda uImage
LD drivers/usb/built-in.o
LD drivers/video/console/built-in.o
LD drivers/video/built-in.o
LD drivers/built-in.o
LINK vmlinux
LD vmlinux.o
MODPOST vmlinux.o
GEN .version
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
LD init/built-in.o
arch/arm/mach-vexpress/built-in.o: In function `v2m_dt_timer_init':
/root/viresh/work/linux/kernel/arch/arm/mach-vexpress/v2m.c:663: undefined
reference to `arch_timer_broken_for_sched_clock'
make[1]: *** [vmlinux] Error 1
make: *** [sub-make] Error 2
Something is wrong: why vexpress??
--
viresh
Hello, linaro-dev,
I am using the instructions in the "adjust kernel config" section at
this link:
> https://wiki.linaro.org/KenWerner/Sandbox/CreateCustomKernelDeb
When I run
# fakeroot debian/rules editconfigs
I get the the following errors:
> Running config-check for all configurations ...
>
> check-config: /tmp/tmp.Sv8FblIPLa/CONFIGS/armel-config.flavour.linaro-lt-omap: loading config
> check-config: /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce: loading checks
> check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y
> check-config: 43/44 checks passed -- exit 1
> check-config: /tmp/tmp.Sv8FblIPLa/CONFIGS/armhf-config.flavour.linaro-lt-omap: loading config
> check-config: /home/work/linux-linaro-lt-omap-3.4-3.4.0/debian.linaro/config/enforce: loading checks
> check-config: FAIL: value CONFIG_INIT_PASS_ALL_PARAMS y
> check-config: 43/44 checks passed -- exit 1
>
> *** ERROR: 2 config-check failures detected
I am using config-3.4.0-1-linaro-lt-omap as my initial .config. A
search for INIT_PASS_ALL_PARAMS in the Kconfig files produces no
results:
find . -name Kconfig -exec grep -H INIT_PASS_ALL_PARAMS '{}' ';'
When I extract the source to a temporary directory and search the
"kernel_build" subdirectory (that John Rigby told me to delete), I
find it in
./init/Kconfig:config INIT_PASS_ALL_PARAMS
So, now I am really confused. Is the real source in the
"kernel_build" subdirectory?
--
Thank you,
David Cullen
Hi all,
Git Location: http://git.linaro.org/gitweb?p=arm/big.LITTLE/mp.git;a=summary
Branch: big-LITTLE-MP-v1
We're announcing a kernel tree to track the various topics of the
big.LITTLE MP project. The aim of this tree is to help consolidate the
various topic patchsets that improve the behaviour of Linux on
asymmetric cores (e.g. big.LITTLE) and make smarter scheduling
decisions possible in order to save power. I'd like to think of it as
a linux-next tree focused on asymmetric support enablement.
Viresh will recreate this tree when new versions of the topic
patchsets are available. IOW, as the patches are reviewed on the lists
and go through iterations, we'll pull each topic patchset into a topic
branch (e.g. per-task-load-average-v2, arm-asymmetric-support-v3).
Then a merge tree will be created (e.g. big-LITTLE-MP-v1) as needed
based on the latest versions of these topics. This should allow users
to track individual topics or leave out some topics if they so desire.
More topics will be added to this tree as the work becomes available.
Linaro platform team will take the merge branch (big-LITTLE-MP-v1,
-v2, etc.) and use it for platform enablement work and testing on real
hardware and models.
Problems should be reported on LKML/LAKML as usual if they are related
to the individual topic trees. If they're related to a bad merge or
config enablement please report on linaro-dev(a)lists.linaro.org.
Regards,
Amit
p.s. People who've shown an interest in this tree have been bcc'ed so
they don't miss the announcement. They are requested to join either
linaro-dev or linaro-sched-sig for future announcements.
