Introduction.
Given that TianoCore is open source and now supporting the ARM architecture, it may be a given that someone may wish to play around with it on their device of choice. Most likely, it's an Android phone, or perhaps some other Linux-using device. That also might imply that you don't have access to boot-loader sources, or the bootloader is "secure", or you simply don't wish to have the possibility of bricking the device totally... It almost likely implies that you might know which SOC chipset is inside, but have no idea for all the power regulators, display controllers, and other logic in the device, so nuking the firmware is definitively not the right option. Better to keep it around so it initializes all the hardware enough that you can interact with it purely by manipulating SoC devices...
So what do you do?
Monday, March 28, 2011
Tuesday, March 15, 2011
Writing data correctly...
Shamelessly lifting these links from the Android blog. It's just that important.
Flourish
Looking forward to the Flourish conference this year at my alma mater, the University of Illinois at Chicago. Flourish is an Open Source Conference initially started by one of my friends, Roberto, who has since moved back to Spain. Although, there is definite room to grow to reach the level of Reflections/Projections, there are some interesting speakers.
The Scala talk could be interesting, and I'd attend Icculus's talk... I wish I'd remember about Flourish earlier, maybe I would have presented something interesting as well...
The Scala talk could be interesting, and I'd attend Icculus's talk... I wish I'd remember about Flourish earlier, maybe I would have presented something interesting as well...
FIQ debugger KGDB support.
ARM-based Android devices in their development life cycle often have a kernel compiled with FIQ debugger support. FIQ debugger allows a developer to gather some data on a hung system via one of the UARTs, even if the system is wedged inside an interrupt handler, by using a FIQ handler.
The FIQ debugger owns the UART port, and allows enabling a console on the port as well (like here https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=commitdiff;h=df5ac72e83df9fd8d735d40d5be464d4b66d6074). A break exits back to the debugger prompt, and a developer can get a backtrace, or run a sysrq action. It would be great, of course, to make this cooperate with KGDB/KDB...
The FIQ debugger owns the UART port, and allows enabling a console on the port as well (like here https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=commitdiff;h=df5ac72e83df9fd8d735d40d5be464d4b66d6074). A break exits back to the debugger prompt, and a developer can get a backtrace, or run a sysrq action. It would be great, of course, to make this cooperate with KGDB/KDB...
MMC block quirks.
So I'm secretly working on some block MMC quirks for some eMMC devices. It's not that big of a secret, but I'll keep the specifics to myself until I have collected enough data to post to linux-mmc. I already posted there the conclusions I reached based on other people's partial data, but that tends to be insufficient when it comes to convincing others of taking weird-looking code...
Anyway, the point is that occasionally you might wish the generic MMC code to act differently for various devices, whether as a workaround for not complying to the spec, or as a workaround for some smart proprietary intellectual property running inside these devices. The linux-next tree contains a quirks layer by Pierre Tardy, with a slight slant towards SDIO devices, as it was added to resolve some SDIO issue. Here is a patch against that tree that extends the quirk support to MMC/SD devices, allowing matching on CID fields. If any luck has it, it will be merged eventually. It would probably help if I hurried on the MMC block quirks actually using this ;-)... Data collection and analysis is a pain.
Anyway, the point is that occasionally you might wish the generic MMC code to act differently for various devices, whether as a workaround for not complying to the spec, or as a workaround for some smart proprietary intellectual property running inside these devices. The linux-next tree contains a quirks layer by Pierre Tardy, with a slight slant towards SDIO devices, as it was added to resolve some SDIO issue. Here is a patch against that tree that extends the quirk support to MMC/SD devices, allowing matching on CID fields. If any luck has it, it will be merged eventually. It would probably help if I hurried on the MMC block quirks actually using this ;-)... Data collection and analysis is a pain.
Measuring SQLite performance on MMC
I needed (still need to, gah) collect data on how a particular change to the Linux kernel MMC block layer ultimately affects write performance in SQLite. Android tends to use SQLite databases quite a bit, so a simple test on how long it takes to insert some large number of records is probably fair.
I exposed a couple of tunables through debugfs and started collecting data.
Of course, the first set of data was collected using specific synthetic benchmarks that did various kinds of O_SYNC+O_DIRECT I/O to the MMC, but it's nice to be able to see the real-life effect of a particular change, especially in combination with file systems. The problem is that you can get data, but that data is not repeatable within the same configuration. That makes comparing data across different configurations tedious at best.
Some things are pretty obvious - ensuring all mounted file systems are read-only. Ensuring there are no other processes running, etc. Other items don't come immediately to mind (to me at least :-()...
For example, running the same 5000 insertions x 50 times about 10 times on the same file system yields progressively slower data.
Current steps to ensure more-or-less repeatable data gathering:
0) Turn off CPU frequency scaling, RAM frequency scaling, etc, all
power savings off.
1) Unmount partition containing files on which the SQLite test operates.
2) Perform BLKDISCARD over the partition.
3) Format with desired file system.
4) Mount.
6) Sync && echo 3 > /proc/sys/vm/drop_caches
7) Perform test.
8) Umount.
9) Repeat from (1)
Anything else I could have missed?
I exposed a couple of tunables through debugfs and started collecting data.
Of course, the first set of data was collected using specific synthetic benchmarks that did various kinds of O_SYNC+O_DIRECT I/O to the MMC, but it's nice to be able to see the real-life effect of a particular change, especially in combination with file systems. The problem is that you can get data, but that data is not repeatable within the same configuration. That makes comparing data across different configurations tedious at best.
Some things are pretty obvious - ensuring all mounted file systems are read-only. Ensuring there are no other processes running, etc. Other items don't come immediately to mind (to me at least :-()...
For example, running the same 5000 insertions x 50 times about 10 times on the same file system yields progressively slower data.
Current steps to ensure more-or-less repeatable data gathering:
0) Turn off CPU frequency scaling, RAM frequency scaling, etc, all
power savings off.
1) Unmount partition containing files on which the SQLite test operates.
2) Perform BLKDISCARD over the partition.
3) Format with desired file system.
4) Mount.
6) Sync && echo 3 > /proc/sys/vm/drop_caches
7) Perform test.
8) Umount.
9) Repeat from (1)
Anything else I could have missed?
Algorithms and Data Structures.
I haven't posted in a while. Unfortunately, not because I hadn't had anything interesting to write lately about, but because of too much interesting stuff happening :-).
In no particular order, some interesting algorithmic links...
In no particular order, some interesting algorithmic links...
- Bit twiddling hacks at http://graphics.stanford.edu/~seander/bithacks.html
- Judy Arrays consumed my imagination, hopefully I'll get to play with them soon.
Subscribe to:
Posts (Atom)