I have created a step by step how to create a blueprint, specification and
how to make a Technical Requirement blueprint dependant on the engineering
blueprint.
This is meant to be for new assignees or as a refresher. If you are
comfortable in creating blueprints and know the process, you can ignore this
note.
https://wiki.linaro.org/WorkingGroups/Kernel/GettingStarted/blueprintStepby…
If you need clarification on the steps or recommendation for enhancement to
this step-by-step, please let me know.
Regards,
Mounir
== Per Forlin <perfor> ==
=== Highlights ===
* Discussing mmc nonblock implementation on mmc-mailing list.
* Studied block layer and found out that block read request for mmc
are often added one by one to the mmc blockdev, this is not the case
for scsi disk blockdev.
=== Absence ===
3 days off due to Eastern holiday and chicken pox
=== Plans ===
* Make draft for 11.11 specs
* Try out different configurations for io-sched
== Device Tree ==
* The .dtb support has been available in hwpack daily build and lmc
v0.0.4. Tested it on mx51 babbage and it works out of box.
* With the help from Dave and Nico, the failure of John Bonesio's
append-dtb patch on babbage was killed. It's caused by the use
of static variable in uncompressed.h, which will not be relocated
because it's not in .bss section.
* Caught the problem of babbage.dtb memory node, which misses
'device_type' property.
== Non-blocking MMC testing ==
* Added pre_req and post_req for SDHCI driver, but did not see
performance gain on mx51 esdhc. No comments from Per Forlin on
that so far.
* Added pre_req and post_req for for mxs-mmc driver and saw ~4%
performance improvement at the best case. Per Forlin gave some
comments saying pre_req and post_req were not added correctly. But
I do not completely understand his comments and asked him for
clarification. No further response yet so far.
== Misc ==
* Respond to Wolfram's comments on sdhci-pltfm&of-consolidation patch
set. Will work on the v2 next week.
* Reviewed a few mxs/mxc patches.
--
Regards,
Shawn
== John Stultz <jstultz_vm> ==
=== Highlights ===
* Pushed out updated Linaro Android tree which resolves the omap3 USB
issue and supports HDMI output on PandaBoard, allowing the Android UI to
now function on Panda.
* Sent out the Posix Alarm Timers patch queue to lkml for
review/inclusion.
* Rebuilt the Android Trivial tree from latest Android tree:
http://git.linaro.org/gitweb?p=people/jstultz/android-trivial.git;a=summary
* Sent out an MM patch for review from the Android Trivial Tree.
* Sent out six MMC patches for review from the Android Trivial Tree.
* Sent clocksource cleanup patch to Magnus Damm to follow up on a
conversation we had at ELC.
* Submitted a LPC BoF discussion on Kconfig fragments for internal
review.
* Reviewed and commented on Paul's ASDF presentation
* Sent some background info and links to slides to Andy Green for his
Android talk in Taiwan.
* Synced with Paul about ELC discussions.
=== Plans ===
* Continue working on the trivial tree to send out cpufreq and cgroup
branches.
* Follow up on the trivial tree patches sent out this week.
* Nag tglx to queue the Alarm Timers for 2.6.40
* Try to send the virtual battery driver in linaro+android tree out for
review.
* Try to get time to look at ADB support for Android kernels
=== Issues ===
* None.
== Paul E. McKenney <paulmck> ==
=== Highlights ==
* Working RCU priority boosting bug: Cheng Xu encountered same bug with user-level program, so this is officially a scheduler bug. Fortunately, my workarounds still are working.
* Sent Sedat Dilek two sets of diagnostics thus far, working up a third set. Problem is in wake-up path for per-CPU kthread.
* Email and IRC with Thomas Gleixner, Andrew Morton, and Linus Torvalds on maintainership issue.
* Interviewed two candidates for Kernel WG, both are +1. A third candidate was no-show. Will set up interview with fourth candidate as soon as I receive contact information.
* Pre-Budapest definition/scheduling work.
* Met with the incoming Kernel WG lead to review draft plans (which is only fair, given that he will be leading them up). We will put a transition plan together in Budapest.
* Debriefed John Stultz on his meeting with the Android guys. John's discussions unearthed an additional suspend-blocker requirement, which I added to the list at [[https://wiki.linaro.org/WorkingGroup/KernelConsolidation/Projects/AndroidSu….
== Miscellaneous ==
* Another iteration on Lai Jiangshan's RCU_PREEMPT inlining patches
Hi toolchain, kernel folks,
I'm seeing an interesting thing on .got and .bss sections of
arch/arm/boot/compressed/vmlinux, and really need your expertise to
shed some lights.
I have an uninitialized variable 'uart_base' defined in misc.c.
static unsigned long uart_base;
$ arm-linux-gnueabi-objdump -D arch/arm/boot/compressed/misc.o
Disassembly of section .bss:
00000000 <uart_base>:
0: 00000000 andeq r0, r0, r0
00000004 <__machine_arch_type>:
4: 00000000 andeq r0, r0, r0
[...]
And section layout looks like the following.
$ arm-linux-gnueabi-objdump -h arch/arm/boot/compressed/vmlinux
SECTIOINS {
...
_etext = .;
_got_start = .;
.got : { *(.got) }
_got_end = .;
.got.plt : { *(.got.plt) }
_edata = .;
. = ALIGN(4);
__bss_start = .;
.bss : { *(.bss) }
_end = .;
...
}
$ arm-linux-gnueabi-objdump -h arch/arm/boot/compressed/vmlinux
arch/arm/boot/compressed/vmlinux: file format elf32-littlearm
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 001c474c 00000000 00000000 00008000 2**5
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .got 00000028 001c474c 001c474c 001cc74c 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .got.plt 0000000c 001c4774 001c4774 001cc774 2**2
CONTENTS, ALLOC, LOAD, DATA
3 .bss 00000020 001c4780 001c4780 001cc780 2**2
ALLOC
4 .stack 00001000 001c47a0 001c47a0 001cc780 2**0
ALLOC
5 .comment 0000002a 00000000 00000000 001cc780 2**0
CONTENTS, READONLY
6 .ARM.attributes 00000031 00000000 00000000 001cc7aa 2**0
CONTENTS, READONLY
I'm able to see uart_base in vmlinux objdump ...
$ arm-linux-gnueabi-objdump -t arch/arm/boot/compressed/vmlinux
[relevant only, and sorted]
00000000 l d .text 00000000 .text
001c474c l d .got 00000000 .got
001c4774 l d .got.plt 00000000 .got.plt
001c4780 l d .bss 00000000 .bss
003968e4 g *ABS* 00000000 _image_size
001c474c g *ABS* 00000000 _got_start
001c4774 g *ABS* 00000000 _got_end
001c4780 g *ABS* 00000000 _edata
001c4780 g *ABS* 00000000 __bss_start
001c4780 l O .bss 00000004 uart_base
001c4798 g O .bss 00000004 malloc_ptr
001c478c g O .bss 00000004 output_ptr
001c479c g O .bss 00000004 malloc_count
001c4794 g O .bss 00000004 free_mem_end_ptr
001c4788 g O .bss 00000004 output_data
001c4784 g O .bss 00000004 __machine_arch_type
001c4790 g O .bss 00000004 free_mem_ptr
001c47a0 g *ABS* 00000000 _end
... but I can not see it in the zImage (all others in .bss seem still
there).
$ xxd arch/arm/boot/zImage | tail
01c4740: 3ef1 1400 be52 9f58 e468 3900 4c47 1c00 >....R.X.h9.LG..
^_got_start (why is it?)
01c4750: 9847 1c00 1043 0000 8c47 1c00 9c47 1c00 .G...C...G...G..
^malloc_ptr ^output_ptr
01c4760: 9447 1c00 080a 0000 8847 1c00 8447 1c00 .G.......G...G..
^free_mem_end_ptr ^__machine_arch_type
01c4770: 9047 1c00 0000 0000 0000 0000 0000 0000 .G..............
^free_mem_ptr
The following is a run-time memdump at _got_start.
Before recalculation:
9056304C: 001C474C 001C4798 00004310 001C478C 001C479C 001C4794 00000A08 001C4788
^_got_start (why is it?)
9056306C: 001C4784 001C4790 00000000 00000000 00000000 EDFE0DD0 4C010000 38000000
After recalculation (for .bss entries, the delta is 9039EA50, for
others in .got, delta is 9039E900):
9056304C: 9056304C 905631E8 903A2C10 905631DC 905631EC 905631E4 9039F308 905631D8
9056306C: 905631D4 905631E0 00000000 00000000 00000000 73FBC000 4C010000 38000000
QUESTION: Where is the .bss section of uart_base?
Now, I remove the 'static' to have 'unsigned long uart_base', and
dump the same stuff to compare.
$ arm-linux-gnueabi-objdump -D arch/arm/boot/compressed/misc.o
Disassembly of section .bss:
00000000 <__machine_arch_type>:
0: 00000000 andeq r0, r0, r0
00000004 <uart_base>:
4: 00000000 andeq r0, r0, r0
I'm able to see uart_base in vmlinux objdump ...
$ arm-linux-gnueabi-objdump -t arch/arm/boot/compressed/vmlinux
[relevant only, and sorted]
00000000 l d .text 00000000 .text
001c4720 l d .got 00000000 .got
001c474c l d .got.plt 00000000 .got.plt
001c4758 l d .bss 00000000 .bss
003968e4 g *ABS* 00000000 _image_size
001c4720 g *ABS* 00000000 _got_start
001c474c g *ABS* 00000000 _got_end
001c4758 g *ABS* 00000000 _edata
001c4758 g *ABS* 00000000 __bss_start
001c475c g O .bss 00000004 uart_base
001c4770 g O .bss 00000004 malloc_ptr
001c4764 g O .bss 00000004 output_ptr
001c4774 g O .bss 00000004 malloc_count
001c476c g O .bss 00000004 free_mem_end_ptr
001c4760 g O .bss 00000004 output_data
001c4758 g O .bss 00000004 __machine_arch_type
001c4768 g O .bss 00000004 free_mem_ptr
001c4778 g *ABS* 00000000 _end
... and I can also see it in the final zImage.
$ xxd arch/arm/boot/zImage | tail
01c4710: 221f f1b3 3ef1 1400 be52 9f58 e468 3900 "...>....R.X.h9.
01c4720: 5c47 1c00 2047 1c00 7047 1c00 e442 0000 \G.. G..pG...B..
^uart_base
01c4730: 6447 1c00 7447 1c00 6c47 1c00 140a 0000 dG..tG..lG......
01c4740: 6047 1c00 5847 1c00 6847 1c00 0000 0000 `G..XG..hG......
01c4750: 0000 0000 0000 0000 ........
Surely, it's in the run-time memdump.
Before recalculation:
90563020: 001C475C 001C4720 001C4770 000042E4 001C4764 001C4774 001C476C 00000A14
^uart_base
90563040: 001C4760 001C4758 001C4768 00000000 00000000 00000000 EDFE0DD0 4C010000
After recalculation:
90563020: 905631AC 90563020 905631C0 903A2BE4 905631B4 905631C4 905631BC 9039F314
90563040: 905631B0 905631A8 905631B8 00000000 00000000 00000000 EDFE0DD0 4C010000
So it looks the non-static ('g') uninitialized variable sits in .bss
sections well, while static ('l') one is not there. Is this
expected? How the static one is being addressed? Or ask where the
offset for static one is stored?
Any info or comments are appreciated.
--
Regards,
Shawn
