Patchset related to hibernation resume: one enhancement to make the use
of an existing file more general and one documentation update.
Both patches are based on the 3.11-rc6 tag. This was tested on a
Pandaboard with partial hibernation support, and compiled on x86.
Further testing is needed on other platforms. Please let me know if
you're able to verify this on any other systems.
[PATCH RFC 1/2] PM / Hibernate: use name_to_dev_t to parse resume
Use name_to_dev_t to parse the /sys/power/resume file making the
syntax more flexible. It supports the previous use syntax
and additionally can support other formats such as
/dev/devicenode and UUID= formats.
By changing /sys/debug/resume to accept the same syntax as
the resume=device parameter, we can parse the resume=device
in the initrd init script and use the resume device directly
from the kernel command line.
kernel/power/hibernate.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
[PATCH RFC 2/2] PM / Hibernate: add section for resume options
This adds a small section to the swsusp.txt file to address the
options for resuming. This comments on the manual resume
option which is used when resorting to an initrd or initramfs
for resuming. Resuming from late init is discussed later in
the document, but it seemed appropriate to list them together.
Documentation/power/swsusp.txt | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
Thanks,
Sebastian
Hi Mark -
I have some small practical questions about LSK. I was able to make a
tree with our linux-linaro-core-tracking(a)v3.10 LT patches on LSK basis
work well (so far).
I found this repo (it needs its ./description updating)
https://git.linaro.org/gitweb?p=kernel/linux-linaro-stable.git;a=summary
1) There seems to be two choices, linux-linaro-lsk and linux-linaro-lsk-android.
I chose the android one, I assume it has the same "androidization"
series on top that linux-linaro-core-tracking used at 3.10? Are there
any other differences?
2) I saw the vexpress integration stuff from ARM LT was included
already which is good, is there a wiki page (or README.html or the
gitweb is also good) explaining the composition?
3) In our LT tree we patch mainline to remove all warnings coming with
our defconfig. Then if we see any warnings coming, we know it's our
fault and we need to go fix it. Are you interested in taking a
similar approach?
4) Maybe this is too much thinking ahead, but shouldn't these lsk
branches be versioned, like linux-linaro-lsk-3.10? Otherwise when the
next lsk version is announced there'll be a problem.
-Andy
Hi, I have just installed the Linaro Ubuntu 11.10 image onto an sdcard for
my Pandaboard (at
https://releases.linaro.org/images/11.10/oneiric/ubuntu-desktop). Upon
booting up, the monitor connected to it (via HDMI) doesn't show anything,
and the serial output continually logs, and the board doesn't boot up.
[ 83.858856] (stk) :line disc installation timed out
[ 83.860595] (stk) :ldisc_install = 0
[ 84.967651] (stk) :ldisc_install = 1
[ 85.968322] (stk) :line disc installation timed out
[ 85.971618] (stk) :ldisc_install = 0
I read on some forums that this is an issue with the bluetooth module, but
couldn't find a solution. Is there a workaround? Would using a newer image
be of use?
Thanks.
Varad
hi there,
first of all, we are building dylan branch with oe-core +
meta-linaro-toolchain, not using external toolchain, hence the cross post
on OE and linaro lists.
we've been debugging some nasty build issues over the last few days on our
Jenkins server. and i'd like to bring our findings up to the list... i
suspect there could be a bug in OE gcc-cross, but i'd like to hear from you
about that.
our bug appeared because we were 'wrongly' unsetting the CFLAGS from OE in
one of our recipe, so we would loose the following from our compilation
command line
-march=armv7-a
-marm
-mthumb-interwork
-mfloat-abi=hard
-mfpu=neon
--sysroot=/work/rdk/build-genericarmv7a/tmp/sysroots/genericarmv7a
The compilation error was that stdlib.h was not found.
as a matter of fact, we build for several different machines (.conf file),
*but* we share the same sstate and downloads for all machines. We don't do
parallel builds, each machine is built sequentially in its own build folder
(.../workspace/machines/<MACHINE>/build), and all build folder are deleted
before each build (of course sstate and downloads aren't deleted).
What we noticed is that we end up pulling the compiler (gcc-cross) from
sstate as expected. However we pull the same 'blob' from sstate for
gcc-cross for *all* machines we build. It does seem that the compiler does
not use $MACHINE for the sstate checksum.
When the gcc-cross package was built and pushed in sstate, it was being
built for a specific machine (let's say MACHINE-A), hence the compiler has
the 'builtin' sysroot set to 'tmp/sysroots/MACHINE-A'.
Now when building our image for MACHINE-B, we pull gcc-cross from sstate,
and we get the default builtin sysroot for MACHINE-A!! That's why our build
failed, because we tried to build MACHINE-B before MACHINE-A, so stdlib.h
wasn't there yet on Jenkins..
To me the problem is that gcc-cross 'embedds' some $MACHINE data in its
package, but it is not marked as 'machine specific, but arch specific. So
several machines will end up sharing the same gcc-cross package.
So, of course we shouldn't ignore the CFLAGS from OE, and the CFLAGS would
set the right sysroot, and of course we fixed our software so that we don't
ignore CFLAGS anymore... but that still looks like a bug to me.
cheers
nico
Hi Linaro
I am a software engineer from Qualcomm. I want to know that if Linaro can change its memory page size in kernel ?
As my CPU is arm-v7, it supports 4k/64k/1M/16M page size translation, but in my linux kernel whose version is 2.6.38, the page size is always 4K,
Do the linux-linaro support different page size in kernel?
Hi All,
I find out that building a project (make file and then some .c files)
is real slow on the Foundation system.
How people do build their own package (project, makefile oriented set
of compile) on Foundation armv8 system ?
Cheers,
Phi