Hi,
I am trying to run wl12xx_sdio_test but I get: "mmc1:0001:2: could
not wake up chip". What am I missing?
In Kconfig wl12xx_sdio_test depends on wl12xx_sdio. Does the test
really depend on the wl12xx_sdio driver? The test module is a sdio
driver too.
I use the latest linux-linaro-2.6.38 together with defconfig from
beta-2 (hwpack_linaro-panda_20110426-0_armel_supported.tar.gz):
I downloaded firmware according to
http://elinux.org/Panda_How_to_kernel_2_6_39#Wlan.
On the pandaboard:
rmmod wl12xx_sdio
modprobe wl12xx_sdio_test
wl12xx_sdio_test mmc1:0001:2: could not wake up chip
wl12xx_sdio_test: probe of mmc1:0001:2 failed with error 1
Thanks,
Per
On Tue, Apr 19, 2011 at 12:33 PM, Wolfgang Denk <wd(a)denx.de> wrote:
> Dear Jim Huang,
>
> In message <BANLkTi=yNnA9nBxWNG_1mfwfd6G_O09GOA(a)mail.gmail.com> you wrote:
>>
>> My idea is that we require abstract 'bootloader' component in Android
>> device/linaro/common, and (patched) 'u-boot' would be the provider of
>> 'bootloader' component in
>> device/linaro/Linaro-Evaluation-Build-Hardware. Also, supporting
>
> If you are discussing requirements for U-Boot, and plan to get these
> merged in to mainlineU-Boot one day, it would probably be a good idea
> to discuss these plans on the U-Boot mailing list as well - ideally
> before any design is cast in iron.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de
> The management question ... is not _whether_ to build a pilot system
> and throw it away. You _will_ do that. The only question is whether
> to plan in advance to build a throwaway, or to promise to deliver the
> throwaway to customers. - Fred Brooks, "The Mythical Man Month"
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
>
Wolfgang,
As you can see from this discussion, Linaro is considering applying
resources (probably me) to upstreaming Android Fastboot features into
mainline u-boot. What suggestions do you have for making this process
as painless as possible?
The topic came up briefly here last year:
http://lists.denx.de/pipermail/u-boot/2010-August/076343.html
An implementation exists for omap4/panda on gitorious:
git://gitorious.org/pandaboard/u-boot.git in the omap4_panda_es2.0
branch. There is also a version for omap3 somewhere else on
gitorious.
To bring this to mainline one would have to:
1) Bring code up to current mainline revision.
2) Fix any coding standards issues.
3) Document the new features.
What else? I know one issue maybe why does this need to exist when
other solutions exist. I think that since Android uses it, it is
somewhat of a de facto standard.
All comments welcome,
John
How significant is the cache maintenance over head?
It depends, the eMMC are much faster now
compared to a few years ago and cache maintenance cost more due to
multiple cache levels and speculative cache pre-fetch. In relation the
cost for handling the caches have increased and is now a bottle neck
dealing with fast eMMC together with DMA.
The intention for introducing none blocking mmc requests is to minimize the
time between a mmc request ends and another mmc request starts. In the
current implementation the MMC controller is idle when dma_map_sg and
dma_unmap_sg is processing. Introducing none blocking mmc request makes it
possible to prepare the caches for next job parallel with an active
mmc request.
This is done by making the issue_rw_rq() none blocking.
The increase in throughput is proportional to the time it takes to
prepare (major part of preparations is dma_map_sg and dma_unmap_sg)
a request and how fast the memory is. The faster the MMC/SD is
the more significant the prepare request time becomes. Measurements on U5500
and Panda on eMMC and SD shows significant performance gain for for large
reads when running DMA mode. In the PIO case the performance is unchanged.
There are two optional hooks pre_req() and post_req() that the host driver
may implement in order to move work to before and after the actual mmc_request
function is called. In the DMA case pre_req() may do dma_map_sg() and prepare
the dma descriptor and post_req runs the dma_unmap_sg.
Details on measurements from IOZone and mmc_test:
https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req
Under consideration:
* Make pre_req and post_req private to core.c.
* Generalize implementation and make it available for SDIO.
Changes since v2:
* Fix compile warnings in core.c and block.c
* Simplify max transfer size in mmc_test
* set TASK_RUNNING in queue.c before issue_req()
Per Forlin (12):
mmc: add none blocking mmc request function
mmc: mmc_test: add debugfs file to list all tests
mmc: mmc_test: add test for none blocking transfers
mmc: add member in mmc queue struct to hold request data
mmc: add a block request prepare function
mmc: move error code in mmc_block_issue_rw_rq to a separate function.
mmc: add a second mmc queue request member
mmc: add handling for two parallel block requests in issue_rw_rq
mmc: test: add random fault injection in core.c
omap_hsmmc: use original sg_len for dma_unmap_sg
omap_hsmmc: add support for pre_req and post_req
mmci: implement pre_req() and post_req()
drivers/mmc/card/block.c | 493 +++++++++++++++++++++++++++--------------
drivers/mmc/card/mmc_test.c | 340 +++++++++++++++++++++++++++-
drivers/mmc/card/queue.c | 180 ++++++++++------
drivers/mmc/card/queue.h | 31 ++-
drivers/mmc/core/core.c | 132 ++++++++++-
drivers/mmc/core/debugfs.c | 5 +
drivers/mmc/host/mmci.c | 146 +++++++++++-
drivers/mmc/host/mmci.h | 8 +
drivers/mmc/host/omap_hsmmc.c | 90 +++++++-
include/linux/mmc/core.h | 9 +-
include/linux/mmc/host.h | 13 +-
lib/Kconfig.debug | 11 +
12 files changed, 1174 insertions(+), 284 deletions(-)
--
1.7.4.1
The dtb is passed to the kernel via register r2, which is the same
method that is used to pass an atags pointer. This patch modifies
__vet_atags to not clear r2 when it encounters a dtb image.
v2: fixed bugs pointed out by Nicolas Pitre
Tested-by: Tony Lindgren <tony(a)atomide.com>
Signed-off-by: Grant Likely <grant.likely(a)secretlab.ca>
---
arch/arm/kernel/head-common.S | 24 ++++++++++++++++++------
arch/arm/kernel/head.S | 8 ++++----
2 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
index c84b57d..854bd22 100644
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -15,6 +15,12 @@
#define ATAG_CORE_SIZE ((2*4 + 3*4) >> 2)
#define ATAG_CORE_SIZE_EMPTY ((2*4) >> 2)
+#ifdef CONFIG_CPU_BIG_ENDIAN
+#define OF_DT_MAGIC 0xd00dfeed
+#else
+#define OF_DT_MAGIC 0xedfe0dd0 /* 0xd00dfeed in big-endian */
+#endif
+
/*
* Exception handling. Something went wrong and we can't proceed. We
* ought to tell the user, but since we don't have any guarantee that
@@ -28,20 +34,26 @@
/* Determine validity of the r2 atags pointer. The heuristic requires
* that the pointer be aligned, in the first 16k of physical RAM and
- * that the ATAG_CORE marker is first and present. Future revisions
+ * that the ATAG_CORE marker is first and present. If CONFIG_OF_FLATTREE
+ * is selected, then it will also accept a dtb pointer. Future revisions
* of this function may be more lenient with the physical address and
* may also be able to move the ATAGS block if necessary.
*
* Returns:
- * r2 either valid atags pointer, or zero
+ * r2 either valid atags pointer, valid dtb pointer, or zero
* r5, r6 corrupted
*/
__vet_atags:
tst r2, #0x3 @ aligned?
bne 1f
- ldr r5, [r2, #0] @ is first tag ATAG_CORE?
- cmp r5, #ATAG_CORE_SIZE
+ ldr r5, [r2, #0]
+#ifdef CONFIG_OF_FLATTREE
+ ldr r6, =OF_DT_MAGIC @ is it a DTB?
+ cmp r5, r6
+ beq 2f
+#endif
+ cmp r5, #ATAG_CORE_SIZE @ is first tag ATAG_CORE?
cmpne r5, #ATAG_CORE_SIZE_EMPTY
bne 1f
ldr r5, [r2, #4]
@@ -49,7 +61,7 @@ __vet_atags:
cmp r5, r6
bne 1f
- mov pc, lr @ atag pointer is ok
+2: mov pc, lr @ atag/dtb pointer is ok
1: mov r2, #0
mov pc, lr
@@ -61,7 +73,7 @@ ENDPROC(__vet_atags)
*
* r0 = cp#15 control register
* r1 = machine ID
- * r2 = atags pointer
+ * r2 = atags/dtb pointer
* r9 = processor ID
*/
__INIT
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index c9173cf..a5e5c5b 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -59,7 +59,7 @@
*
* This is normally called from the decompressor code. The requirements
* are: MMU = off, D-cache = off, I-cache = dont care, r0 = 0,
- * r1 = machine nr, r2 = atags pointer.
+ * r1 = machine nr, r2 = atags or dtb pointer.
*
* This code is mostly position independent, so if you link the kernel at
* 0xc0008000, you call this at __pa(0xc0008000).
@@ -91,7 +91,7 @@ ENTRY(stext)
#endif
/*
- * r1 = machine no, r2 = atags,
+ * r1 = machine no, r2 = atags or dtb,
* r8 = phys_offset, r9 = cpuid, r10 = procinfo
*/
bl __vet_atags
@@ -339,7 +339,7 @@ __secondary_data:
*
* r0 = cp#15 control register
* r1 = machine ID
- * r2 = atags pointer
+ * r2 = atags or dtb pointer
* r4 = page table pointer
* r9 = processor ID
* r13 = *virtual* address to jump to upon completion
@@ -376,7 +376,7 @@ ENDPROC(__enable_mmu)
*
* r0 = cp#15 control register
* r1 = machine ID
- * r2 = atags pointer
+ * r2 = atags or dtb pointer
* r9 = processor ID
* r13 = *virtual* address to jump to upon completion
*
Optimize performance for single irq
Changes since v2.
* Rebase on mmc-next, change of line numbers no code changes.
Stefan Nilsson XK (1):
sdio: optimized SDIO IRQ handling for single irq
drivers/mmc/core/sdio_irq.c | 33 ++++++++++++++++++++++++++++++++-
include/linux/mmc/card.h | 1 +
2 files changed, 33 insertions(+), 1 deletions(-)
--
1.7.4.1
Hey
This is a quick heads up that MM summit starts at *2pm* today (in 15mn)
and not at 3pm. The schedule is incorrect because we can't overlap the
plenaries, but discussion will start at 2pm.
See you there!
--
Loïc Minier
Hi All,
As a reminder, please make sure you head to the Linaro Technical Showcase in
the Grand Ballroom on Tuesday from 7pm.
Here are 3 great reasons to be there:
1. Opportunity to see and chat about at least 19 Linaro based demos
(https://wiki.linaro.org/Events/2011-05-LDS/Showcase#Demo_list)
. BTW - if you'd still like to do a demo, its not too late. Just let
me, Arwen or Michael Opdenacker know before 4pm Tuesday
2. Vote for your favourite demo - the first 50 voters get a $50
discount voucher to purchase a Freescale Quick Start board
3. See our illustrious VP Engineering in a tuxedo!
Have a great evening.
Thx
Stephen Doel
Chief Operating Officer
Linaro Ltd
+44 77 66 014 247
(sorry, first time sent from wrong email, don't know if that'll get
thru)
Hello Android team,
I was working on making Android toolchain buildable using Android build
service, and finally I was able to do successful and reproducible
builds - of AOSP pristine bare-matal toolchain so far
(https://android-build.linaro.org/builds/~pfalcon/aosp-toolchain/).
There were few issues which needed to be investigated and resolved,
and which I would like to discuss here:
1. make -jN breakage
Android build service builds on EC2 XLARGE instances with 16
concurrent make jobs (-j16). This invariably leads to build failure
sooner or later (exact location depends on other options and maybe
non-deterministic at all). The failure is "error: Link tests are not
allowed after GCC_NO_EXECUTABLES." which somehow sends issue-hunting
the wrong trail (like sysroot issues, etc.) but after some experiments
I reduced this to exactly -j >1 being used, with -j1 it went past usual
failure points reliably.
2. Lack of DESTDIR support
There's standard GNU autotools variable "DESTDIR" to install package
into other directory besides $prefix. It is supported for gcc,
binutils, etc., but not for Android's own toolchain/build project. The
usual local-use trick is just to pass another prefix just for make
install target, and that's what toolchain/build's README suggests. My
only concern is "cleanroomness" of the results - suppose make install
suddenly wants to rebuild something (libtool used to have such habit),
then new prefix may be embedded into some executable, and then hit
beyond the usual usage pattern (like, with non-English locale). Still,
this is more a theoretical risk, which I as a build engineer should
note, but not something to much worry about.
3. libstdc++v3 build
toolchain/build's README says that the default is not to build
libstdc++v3 and it must be enabled explicitly. But in the current
master I found that not to be the case - it gets enabled by default.
And its build requires sysroot, so I had to disable it explicitly
for bare-metal build.
4. sysroot source
So, to build full-fledged toolchain, we need to supply sysroot.
What should be source of it? Android build service script I started
from extracts it from an official Android SDK release. Is that good
enough source? I guess we'd miss some non-released optimizations that
way (byteswap ARMv6 optimizations come to mind). Otherwise, what should
be used instead? Obvious choice is to build Android target images, then
build toolchain on that tree. But that would be too long and expensive.
Should we prepare and tar sysroot and provide it as extra build
artifact for Android target builds? Also, can there be any
machine-specificity, or it's for sure one generic sysroot for specific
Android version (with arch-specific things handled via #ifdef's)?
Of these 4, first 3 are upstream-related bugreports with known
workarounds. I wanted to write them down, but I'm not sure if more can
be done about them - if you think it would be useful to submit them as
bugs at lp/linaro-android (or directly to upstream?), I can do it.
Sysroot issue of course requires input/discussion - in mail or at some
LDS session.
Thanks,
Paul mailto:pmiscml@gmail.com
--
Best Regards,
Paul
