Hey Nico,
As posted in https://bugs.launchpad.net/linux-linaro/+bug/802693 the
following commit has been causing boot hangs on some panda boards:
arm: omap4: support pmu - 4fefbe94a77c3d3b5e75d386628c36298c72c57f
Reverting it seems to resolve the hang. Avik doesn't see the problem on
his board, but Zach and I both have hit it with ours. We have not gotten
any traction on resolving the hang and its blocking Linaro Android
Platform Images for panda.
Since its been a week with no solution, I wanted to propose we revert
that patch.
How does that sound?
thanks
-john
I'm trying to work out what compile time checks I can do determine which
ARM architecture the kernel binary may be run on.
Is __LINUX_ARM_ARCH__ the architecture that the kernel is being built to
support, or is it the instruction set being used by the compiler? (If
these aren't always the same.)
Also, when a kernel is built for ARMv6 and ARMv7, I assume that
__LINUX_ARM_ARCH__ == 6 ?
Finally, is it safe to assume that a single kernel binary will never
support both v5 and v6 hardware? What about v4 and v5?
My ultimate goal is to correctly simulate ARM instructions which behave
differently on different architectures, for this, there will also need
to be some runtime checking. I can do this by running some test code at
boot time, but does the kernel already have some CPU architecture or
feature detection that I can make use of?
I was also looking at the Instruction Set Attribute Register in CP15,
these give me the exact information I want, but I suspect that
determining their availability will be as difficult as writing code to
probe the features I'm interested in (ARM/Thumb interworking).
--
Tixy
== Dave Martin <dmart> ==
=== General Activity ===
* Some kernel patch work:
* CPU info declaration macros -- No dissent upstream.
These patches are now sitting in Will Deacon's tree
waiting for him to send a pull request to Russell.
* Will Deacon's Generic MMU off code -- helped fix an off-
by-one type bug which was preventing the temporary
stack's identity mapping from being installed properly.
* More activity on minor bugs in gas:
* http://sourceware.org/bugzilla/show_bug.cgi?id=12931 (ARM:
gas fails to set the proper alignment on code sections,
causing broken output)
This is the issue which is contributing to the WebM codec
failures in Firefox on ARM.
Simple workaround proposed and merged upstream.
* http://sourceware.org/bugzilla/show_bug.cgi?id=12848 (ARM:
Thumb-2: Range check on b.w is off by a factor of 2)
This issue is actually affecting virtually all branches in
Thumb, including BL.
Tidy-up/fix proposed upstream.
=== linaro-kernel-o-standard-arch ===
* Started an experimental merge of Catalin Marinas' LPAE (ARM
Large Physical Address Extension) patches with linux-
linaro-2.6.39.
I now have a booting kernel on the ARM VExpress-CA15x4 model
making use of physical memory beyond 4GB, but still having
problems with SMP (probably a separate issue from LPAE / A15
support).
=== Plans ===
* Check whether the new kernel trees work in Thumb-2 on mx51evk
and follow up with Freescale landing team.
* Try merging the basic A15 / VExpress new memory map support
from the AEL tree with linux-linaro-2.6.39 (i.e., no LPAE sup-
port). These are likely to merge upstream sooner than LPAE,
and may make sense in the linaro tree.
* Follow up on Cortex-A15 FPGA platform availability.
* Suggest we disable aligment fixups for linaro images, since
gtk-sharp2 is now the only thing known to be affected.
=== Device Tree ===
* I stop posting board level dt patches (just keep it local for
testing drivers), as it's still going to be a while before it can
be merged due to a few unresolved issues. Instead I'm trying to
get a few driver patches hit v3.1 merge window. Just sent out
patches for serial, fec, gpio, and esdhc. Thanks Grant for the
review and comments. Will respin for v2 soon.
=== ARM/imx consolidation ===
* None
=== Misc ===
* Sent a mxs-dma patch to skip request_irq for NO_IRQ, so that gpmi
which gets multiple dma channels sharing one IRQ can work with
mxs-dma too.
* Co-worked with Troy Kisky to send a patch fix the issue that fec
driver can not work with mii phy on imx53.
=== Plan ===
* v2 of serial, fec, gpio, esdhc dt support
* spi, i2c, sdma dt support
--
Regards,
Shawn
== Niklas Hernaeus <nhe> ==
=== General activity ===
* Got some real hardware, the Snowball.
* Booted Snowball, without DT.
* Changing dev environment, update of compiler necessary, again.
The Sourcery G++ Lite 2011.03-41 for ARM GNU/Linux may generate unaligned
function pointers, it would seem. Have not made any deep investigation,
just want it to work. Thanks for the help Per, I would not have expected
that kind of problem.
=== Issues ===
* Can not flash the Snowball eMMC, that is U-Boot.
* Inherited from last week:
What about hierarchy of devices in DT. What can/should be made
common? Or flat file? gcl?
== Manjunath GK <manjugk> ==
=== Highlights ===
* Posted initial patches for migrating omap board file into DT.
- i2c driver is converted to DT data structures.
- patches created for omap4 panda and omap3 beagle boards.
* The patches has dependency on omap HWMOD which needs to be aligned with
OMAP SoC mainitainers
* Working on modifying DT helper functions for code optimization.
=== Plans ===
* OMAP SoC mainitainers should revert back on the queries and dependencies
posted to linux-omap and device tree
mailing lists.
* Continue to work on received comments.
* Need to check other content in omap board file for DT migration.
--
Manjunatha GK
Linaro.org <http://www.linaro.org/>* **│ *Open source software for ARM SoCs
Follow *Linaro: *Facebook <http://www.facebook.com/pages/Linaro> |
Twitter<http://twitter.com/#%21/linaroorg>|
Blog <http://www.linaro.org/linaro-blog/>
== Per Forlin <perfor> ==
=== Highlights ===
* Rebased mmc non-blocking patchset v8 on to of mmc-next for 3.1. The
patchset has received a couple of acked-by and will hopefully be
merged for 3.1.
* Run mmc test on on ARM real view and U300 with help from Linus W.
Made minor adjustments in the mmc_test as a result of realview and
U300 testing
* Helped Niklas H to get started on snowball (flash/build/boot).
* Investigated why the eMMC on snowball is slow compared to U8500. I
thought it might be a SW issue but it turned out that Snowball has a
relatively slow eMMC.
=== Completed work items ===
* https://blueprints.edge.launchpad.net/linux-linaro/+spec/mmc-async-request
* mmc-next linux 3.1 mmc async req, rebase and test: DONE
* mmc-next linux 3.1 mmc async req, submit and review: DONE
=== Plans ===
Vacation 4 weeks in July. I will only follow up on mmc non-blocking
during my vacation.
== Highlights == ( * Was on a training program for most of the working week)
* Review / test MMC async request patches
* Design for MMC-HPI implementation
== Plans ==
* Continue with HPI implementation
* Review / analyze adding flash media information to CFQ
=== Highlights ===
* Kprobe work items from blueprint "Finish Thumb2 Support"
* Make ARM ALU and LDR instruction emulation interwork with Thumb:
DONE
* Tidyup and document kprobe changes: DONE
* Add decoding table self consistency, and test case coverage
checks: DONE
=== Plans ===
* Get patches for Thumb2 kprobes work submitted for review
* Tidyup and document kprobe test code
* Start work on blueprint "Investigate block allocation in FS"
