Hi, Kernel WG,
Can recent kernel handle NEON registers in corefiles?
Seems we've had plan for this in "Ensure full NEON debug support" in
https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Specs/BSPInvestig…
Any progress on this piece of work? We want to handle NEON registers in
corefiles from GDB, which required kernel dump them in corefile first.
Hi. I have a question about a detail in the OMAP3 TRM, which I
was hoping some omap-savvy person on this list might be able
to answer.
This is about the GPMC prefetch engine register
GPMC_PREFETCH_STATUS and specifically its FIFOTHRESHOLDSTATUS
bit. I've been using the OMAP35xx TRM (document SPRUF98L, rev L)
as reference.
The register summary on page 1176 says "set when FIFOPointer
exceeds FIFOThreshold value" and is clear that it is 1 if Pointer
> Threshold. However the description on page 1141 says "The
FIFOPOINTER indicates the current number of available data to be
read; FIFOTHRESHOLDSTATUS set to 1 indicates that at least
FIFOTHRESHOLD bytes are available from the FIFO", ie the bit is
set if Pointer >= Threshold. The text on p1143 is similar.
So is the bit set for Pointer > Threshold or Pointer >= Threshold?
(Greater-than-or-equal makes more conceptual sense to me and
would match the condition in which GPMC_IRQSTATUS's
FIFOEVENTSTATUS bit is set.)
(I'm looking at this because I'm implementing the prefetch engine
in qemu.)
thanks in advance
-- PMM
Hi there,
Does anyone know if it's possible to use kdump on an ARM board to capture a
memory image of the kernel (to be later analyzed with crash for example)?
I had a quick look at the kernel config options provided by the linaro-linux
tree and it seems that kexec support (CONFIG_KEXEC) is there. I assume
/sbin/kexec could be used to load a dump-capture kernel. Unfortunately
CONFIG_CRASH_DUMP is not available, so I don't know how to configure such a
kernel. Any pointers or suggestions are appreciated.
Regards
Ken
All,
The weekly report for the Linaro Infrastructure team may be found at:-
Status report:
https://wiki.linaro.org/Platform/Infrastructure/Status/2010-12-09
Burndown chart: This link is awaiting the production of new burndown charts.
The Infrastructure related blueprints from the maverick cycle, of which
currently there are 4 active ones (4 from the last report), are showing
that there are 8 work items in progress (8 last report), and 11 work
items to undertake (11 last report). These are to be moved into the
natty cycle if still required.
* arm-m-validation-dashboard; no change in status from last report; 3 in
progress; 7 to do
* arm-m-image-building-console; no change in status from last report; 3
in progress; 3 to do
* arm-m-automated-testing-framework; no change in status from last
report; 1 in progress; 0 to do
* arm-m-testsuites-and-profilers; no change in status from last report;
1 in progress; 1 to do
In the natty cycle, the following lists the current active Blueprints,
or Blueprints planned and not started. Currently there are 4 active
Blueprints (4 from the last report), which are showing that there are 8
work items in progress (7 last report), 41 work items to undertake (46
last report), 2 work items postponed (0 last report) and 8 work items
added (all items added last report).
* other-linaro-n-improve-linaro-media-create: 5 work items completed
(2 last week); 4 work items in progress (3 last week); 8 work items to
do (8 last week); 2 work items added this week (2 last week).
* other-linaro-n-test-result-display-in-launch-control: 0 work items
completed (8 last week); 1 work item in progress (1 last week); 10 work
items to do (10 last week); 0 work items added (4 last week)
* other-linaro-n-patch-tracking: 0 work item completed (0 last week);
2 work items in progress (2 last week); 9 work items to do (9 last week)
* other-linaro-n-image-building: 2 work items in progress (2 last
week); 5 work items to do (5 last week); 2 work items postponed (2 last
week); 0 work items added (2 last week)
* other-linaro-n-continuous-integration: Not started - awaiting a
Hudson build server (RT#42278).
* other-linaro-n-package-development-tools: Not Started; 9 work items to do
Specifics accomplished this week include:-
* other-linaro-n-image-building: "4.6 Multiple hwpacks": basically
done - needing test and review.
* ImproveLinaroMediaCreate: completed the ports to Python of
"populate_boot" and "create_partitions" - waiting for review on "create
partitions"
* Added blueprint/bug links to the LaunchPad API. This is now landed
and tested.
* Also finished porting the work items tracker to use the launchpad
APIPlease let me know if you have any comments or questions.
Kind Regards,
Ian
The weekly report for the Linaro Foundations team may be found at:
Status report: https://wiki.linaro.org/Platform/Foundations/2010-12-08
Overall status (out of date until workitem tracker for 11.05 is available):
https://wiki.linaro.org/Platform/Foundations/Status
* A first 2.6.37 kernel is now packaged and available in Ubuntu natty for
inclusion in Linaro images.
* Cross-compiler packages have been merged and uploaded to natty, preparing
us for gcc 4.5 as a default cross-compiler.
* Progress on ALIP continues, with all but two of the original ALIP
packages now successfully cross-buildable with patches applied.
Actions:
* npitre to write up more formal documentation of what our kernel tree is
(and isn't): DONE
* slangasek to review armel-cross-toolchain-base merge request: DONE
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek(a)ubuntu.com vorlon(a)debian.org
Hi,
I did some quick ftrace tests using the linaro-vexpress 2.6.35-1010.17 kernel
on an ARM-Versatile Express CA9x4 board. It seems to work pretty good. I
noticed only one issue with the wakeup latency tracer where
/sys/kernel/debug/tracing/trace doesn't show any real information but the
/sys/kernel/debug/tracing/trace_pipe does.
The details can be found at: https://wiki.linaro.org/KenWerner/Sandbox/ftrace
Regards
Ken
Greetings,
Enclosed you'll find a link to the agenda, minutes and actions from the
Linaro kernel working group weekly meeting of Dec 06, 2010.
https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Meetings/2010-12-…<https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Meetings/2010-11-…>
== Summary ==
* Dave Martin & Nico reviewed K2.x blueprints, bp's are Approved now.
* Tool to measure and fix SD card performance. Found a case of excessive
copy-and-paste, gaining unneeded abstraction layers not yet needed for this
non-ARM Unicore architecture.
* Mainlined Flash support, available in git.stericsson.org, also taken into
the linux-arm-kernel tree 2.6.37.
* Implemented USB transceiver driver as drivers/usb/otg. Cleaning up MUSB
BSP for 8500 crossover code. Gadget code sent out for internal ST-Ericsson
review, will post publicly after resolved.
* Posted the five uboot patches to the list, built and tested the first two
on all available platforms. Need additional testing, especially on
big-endian platforms such as PowerPC.
* Reviewing status. A few specifications and blueprints not yet complete,
status lagging on some. Working on New Members wiki page.
* ST-Ericsson Landing team going well. Finding problems, getting fixes.
Waiting on some fixes from internal ST-Ericsson teams. Currently relying on
to-be-written functionality. Team is under NDA, so can pull some patches
from internal teams prior to upstreaming. Some issues with source-tree
organization within ST-Ericsson, which is being resolved by having a single
tree that functionality is added to via topic branches.
* Thumb 2 work progressing. A couple of patches to be merged into 2.6.36
tree. Freescale BSP review progress.
* OMAP4-EHCI support queued up in linux-usb tree for 2.6.38
* Document describing Linaro kernel, will publish on list and ask for
comments.
* Completed blocked-task-list reorganization for RCU_TREE priority
boosting, and started coding up changes needed to move from softirq to
kthread.
Possible RCU energy-consumption issue appearing on lightly loaded
systems with modest numbers of CPUs: RCU prevents entry into dyntick-idle
mode: Examining possible approaches.
Please let me know if you have a question or comment,
Regards,
Mounir
