I'm looking for a copy of the ddeb (ie the debug info) for the omap
kernel in the 1105 release. That used to be here:
http://ddebs.ubuntu.com/pool/universe/l/linux-linaro-omap/linux-image-2.6.3…
but unfortunately the archive expired it last night.
Does anybody happen to have a copy lying around that they could
send me?
(Also can we sort this out so we stop expiring the ddebs,
at least for our release kernels?)
Thanks in advance
-- PMM
Hi,
We've been thinking about adding support for the built-in functions for 64bit
atomic memory access and I'd like to know if this is of any interest.
Currently the main use of these functions seems to be to implement (SMP safe)
locking mechanisms where the existent 32bit memory ops are sufficient.
However, there might be code out there that implements a parallel algorithm
using 64bit atomic memory operations.
Currently the GCC ARM backend doesn't provide a pattern to inline 64bit
__sync_* functions but the compiler emits __sync_*_8 function calls [1]. The
libgcc does not provide these symbols via the usual thin wrapper around the
kernel helper [2] because the ARM Linux __kernel_cmpxchg supports 32bit only.
My understanding is that for ARMv7 the GCC backend could be enhanced to inline
the __sync_* functions by using the LDREXD and STREXD instructions. But for
ARMv5 we would still rely on a new kernel helper.
Any ideas/thoughts are appreciated.
[1] https://wiki.linaro.org/WorkingGroups/ToolChain/AtomicMemoryOperations#GCC
[2]
https://wiki.linaro.org/WorkingGroups/ToolChain/AtomicMemoryOperations#impl…
Regards
Ken
I have a few inter-related issues:
- Why would one kernel boot a card that another kernel can't?
- Why would a card's disk geometry matter for boot?
- Who is a good manufacturer for getting hardware-identical cards in
bulk?
- How can I probe the actual "disk geometry" of an sd card?
I bought 100 Transcend SD cards a little while ago and duplicated them with
an OpenEmbedded-based filesystem (linux-2.6.36).
There were a few "bad" cards that I threw out, but the success rate was
acceptable.
In the next round of 40 SD cards I used a Linaro-based filesystem
(linux-2.6.39) and had about a 50% failure rate when testing that the cards
would boot, which is absurd.
There kernel reports: [ 1.003204] mmcblk0: unknown partition table
However, the cards would mount and show files just fine.
I reduplicated one of the non-booting cards with an OpenEmbedded filesystem
and then it booted. Weird!
After some investigation I found that using `gparted` (instead of `fdisk`)
to create a new partition table and then `rsync`ing the contents of the
original filesystem resulted in a booting Linaro card.
Rinse and repeat and I ended up with 3 images which only vary by the disk
geometry as reported by `fdisk -l`:
- 50% -- 255 heads, 63 sectors/track, 974 cylinders
- 40% -- 2 heads, 4 sectors/track, 1957632 cylinders
- 10% -- 247 heads, 62 sectors/track, 1022 cylinders
- 1 card still didn't boot
I'm lost. Please advise.
AJ ONeal
Non-booting kernel message
[ 0.923309] Waiting for root device /dev/mmcblk0p2...
[ 0.957885] mmc0: host does not support reading read-only switch.
assuming write-enable.
[ 0.982025] mmc0: new high speed SDHC card at address b368
[ 0.988494] mmcblk0: mmc0:b368 USD 7.46 GiB
[ 0.993957] mmcblk0: detected capacity change from 0 to 8018460672
[ 1.003204] mmcblk0: unknown partition table
[ 1.036926] VFS: Cannot open root device "mmcblk0p2" or
unknown-block(179,2)
[ 1.044433] Please append a correct "root=" boot option; here are the
available partitions:
[ 1.053344] b300 7830528 mmcblk0 driver: mmcblk
[ 1.058959] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(179,2)
Booting kernel message
[ 1.122070] mmc0: host does not support reading read-only switch.
assuming write-enable.
[ 1.146087] mmc0: new high speed SDHC card at address b368
[ 1.152557] mmcblk0: mmc0:b368 USD 7.46 GiB
[ 1.158020] mmcblk0: detected capacity change from 0 to 8018460672
[ 1.166351] mmcblk0: p1 p2 p3
[ 1.259674] EXT3-fs: barriers not enabled
[ 1.265411] kjournald starting. Commit interval 5 seconds
[ 1.271331] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data
mode
[ 1.278686] VFS: Mounted root (ext3 filesystem) readonly on device 179:2.
Hi Zach,
We have a request in the queue to set up Gerrit for the Android team,
and I know it's something that you consider very important. We haven't
yet talked specifics of the configuration of Gerrit, and so I don't yet
have a solid idea of what work there is for the Infrastructure team
there. I'd like to rectify that and create an implementation plan for
the first steps to where you want to go.
To that end, if we had a vanilla Gerrit instance up and running
tomorrow, what would be the first things that you would want to do to it
before it would be useful to you?
Thanks,
James