Google
 

Archive for January, 2008

2008-01
17

薛兆丰的精辟语录

Filed under: 闲言碎语 — woojar @ 11:13 am

[tag]薛兆丰[/tag]

摘自http://www.stevenxue.com/st_195.htm

受过不充分教育的人的傲慢,就是夸夸其谈,佯装具有我们所不具有的智慧。它的诀窍是:同义反复和琐屑之事再加上自相矛盾的胡言。另一个诀窃是:写下一些几乎无法理解的夸大的言词,不时添加一些琐屑之事。这会受到高兴地在如此”深奥”的书中发现自己原也具有这样的思想的读者的喜爱。(现在任何人都能看到皇帝的新装正在流行!)

学生进入大学,由于不知道应该使用什么标准,于是就采用他所发现的标准。因为大多数哲学系(尤其社会学系)的智力标准流于浮夸和纵容虚假的知识(这些人似乎都极渊博),甚至健全的头脑也会完全发晕。


Technorati :

2008-01
16

遮挡物与视力

Filed under: 闲言碎语 — woojar @ 5:35 pm

[tag]电脑, 遮挡物, 视力[/tag]

前两天看中央4套《走遍中国》,讲的是在青藏高原上寻找千里眼的纪实片,最后在一个比较封闭的草原学校里找到一个可以在20多米看到国际视力表的4.8栏。据相关人士分析,这是因为他们那里的生活环境视野很开阔,蓝天白云草原什么的,几乎没什么遮挡物,久而久之他们那里的种群视力就普便较好!

想一想,确实也就是那么回事。我不禁为我们这些生活在城市里的人感到悲哀。我们整天看到的是高楼大厦,我们放眼望去,几十米就肯定有遮挡物了,这还算是一个人在街道上,象我们整日在办公室里,在一个个隔栏里,面对的也是个近在咫尺的电脑屏幕,上下班也只是在公车上或地铁里或呆在家里。我们的视野怎么能开阔呢?久而久之我想我们现代人的视力肯定会越来越钝化,因为我们不需要看到远处的东西,我们只需要看到近的地方,从近的地方获取信息。

视力的钝化使们生活在模糊的世界里,我们也只能靠外物来了解远处的东西。

有时确实有点厌烦这种整天对着电脑的日子,但离开电脑我们又能做什么呢?我们对电脑的依赖越越来严重,电脑在主宰着我们的生活,至少是在主宰我的生活。我多么想让我的眼前出现一望无际的原野,让我的周围不在有人流和电磁波。。。


Technorati : , ,

2008-01
15

PowerPC JTAG pin out specification

Filed under: Tech articles — woojar @ 2:57 pm

[tag]powerpc, Jtag, pin[/tag]

For General embedded pcb board, there is one standard 20-pin JTAG interface for debugging. But for PowerPC serial, the following 16-pin JTAG interface is common used.

JTAG Connector Pin-Outs for popular devices

PowerPC 52XX, 74XX, 7XX, 82XX, 83XX, 85XX JTAG
Pin Signal Name
1 1 TDO
JTAG Test Data Out
2 2 Not Used (QACK -7XX only)
3 3 TDI
JTAG Test Data In
4 4 TRST
JTAG Test Reset
5 5 Not used
6 6 Vcc Target
1.8 - 5.0V:
This is the target reference voltage.
7 7 TCL Clock
8 8 CHK_STP_IN
9 9 TMS
JTAG Test Mode Select
10 10 Not Used
11 11 /SRESET
12 12 Not Used
13 13 /HRESET
14 14 Not Used
15 15 CHK_STP_OUT
16 16 GROUND
System Ground
PowerPC 4XX JTAG
Pin Signal name
1 TDO
JTAG Test Data Out
2 2 Not Used
3 TDI
JTAG Test Data In
4 4 /TRST
JTAG Test Reset
5 5 Not used
6 6 Vcc Target
1.8 - 5.0V:
This is the target reference voltage.
7 7 TCK
JTAG Test Clock
8 8 Not Used
9 9 TMS
JTAG Test Mode Select
10 10 Not Used
11 11 /SYS_HALT

12 12 Not Used
13 13 Not Used
14 14 Not Used
15 15 Not Used
16 16 GROUND
System Ground


Technorati : , ,

2008-01
14

从无线音乐说起(二)

Filed under: 闲言碎语 — woojar @ 10:09 pm

[tag]互联网,3G, web 2.0[/tag]

说到互联网的盈利模式,我们可能会想到这年头比较火的一个概念”web 2.0″。究竟什么是web 2.0呢?”Web 2.0″的概念开始于一个会议中,展开于O’Reilly公司和MediaLive国际公司之间的头脑风暴部分。详细的介绍可以看这里。归纳起来有以下几个特点:

  1. 互联网作为平台
  2. 利用集体智慧
  3. 数据是下一个Intel Inside, 以数据为驱动
  4. 软件发布周期的终结,更快的更新
  5. 轻量型编程模型,易于被更多用户的参与
  6. 软件超越单一设备
  7. 丰富的用户体验

综合来看,也没有什么新的技术含量,只不过是一种新的互联网思想的诞生。这就需要有前瞻性的眼光去发搅这里面的商机,这样它就不仅仅停留在一个概念或噱头中。因为我们不仅仅需要的是互联网只是一种工具,而是它确确实实象无线音乐下载一样实实在在的盈利模式。我们等待着一个斩新的互联网时代的到来!

我们还是回到无线业务上来吧,单靠彩铃彩信什么的,确实有点单一,但是别忘了,我们现在的手机业务是缺乏3G这样的高速网络做载体,所以就少了很多有趣的东西。一旦3G或者4G上马,那么手持设备将会异常盛行,这样的话互联网也会借助于这个平台再来一次飞跃。现在的移动网络虽然已从GPRS升级到EDGE,但是速度明显还是不能跟PC相提并论,资费也蛮高,所以也不可能有太多的其它业务。但是这上面的前景应该会是一片光明。类似3G(wap.3g.cn)这样的网站,也只能在这慢速的移动网络时代称个王吧。


Technorati : , ,

2008-01
14

Flash Filesystems for Embedded Linux Systems

Filed under: Tech articles — woojar @ 2:33 pm
[tag]embedded, linux, filesystem[/tag]
本文转载自: http://linuxdevices.com/articles/AT7478621147.html

Flash isn’t only a hard disk with no moving parts. This article shows you how to combine filesystem technologies to make the best use of Flash.

With the falling cost of 32-bit processors containing a memory management unit (MMU), Flash memory and SDRAM, a new class of embedded devices is evolving in the networking, internet appliance and PDA markets. Typically consisting of a 32-bit processor with an MMU, 4-32MB of Flash memory and 8-32MB of SDRAM, these devices now have the storage capacity needed to take advantage of the many advanced features applications require. The popular Compaq iPaq handheld computer is a good example of such a system.

When implementing a Linux operating system on these devices, the critical issue of how to create a filesystem without a hard drive arises. A number of different types of Flash memory are designed specifically for data storage, such as NAND Flash devices and disk-on-chip devices. However, this article will focus on NOR Flash-based solutions for the iPaq system mentioned above.

Since NOR Flash is usually required for code storage, implementing a filesystem in existing NOR Flash devices is often the most cost-effective solution and conserves PCB board real estate. Several technologies are available for efficiently implementing filesystems on NOR Flash. Before examining these technologies, however, let us examine the critical issues driving the design of NOR Flash filesystems.

The first of these issues is that conventional filesystems, such as the default Linux standard ext2, cannot be efficiently used on Flash because the block size of a Flash device is relatively large (64K to 256K), compared to the 4k block size typically used for ext2 filesystems. Additionally, NOR Flash has a limited number of erase cycles per block, typically in the range of 100,000. Secondly, the cost of NOR Flash is prohibitive, about three times as expensive as SDRAM. For this reason a filesystem with compression is highly desirable. Finally, journaling is an issue with a Flash filesystem, if file writes are to be supported, because it eliminates the need to go through a lengthy power-down procedure.

Another frequently discussed topic related to Flash filesystems is execute in place (XIP), which is often used in embedded operating systems. XIP is a mode of operation where the processor maps pages from the application in Flash directly to its virtual address space, without coping the pages to RAM first. This process can reduce the amount of RAM required in a system. The problem with XIP is that compression cannot be used, and it is very difficult to make a filesystem that is writable. The fact that the processor will only load the working set of pages into RAM for an application also reduces the need for XIP.

There are a number of Linux technologies that work together to implement a filesystem in a Flash-based embedded Linux system. Figure 1 illustrates the relationships between some of the standard components.

figure

Figure 1. Components of a Filesystem in a Flash-Based System

initrd


In the early days of embedded Linux, the initrd (initial ram disk) mechanism was often used to store a compressed filesystem in Flash. The initrd mechanism was originally developed so a small Linux system could be booted from a floppy disk that, in turn, would install a full-featured Linux system to a hard disk. The boot sequence of a system using an initrd is:
  1. Bootloader copies compressed Linux kernel and initrd image from Flash to RAM and jumps to kernel.
  2. The kernel decompresses itself to the correct location and starts the initialization sequence.
  3. The kernel decompresses the initrd image in RAM and mounts it using the ramdisk driver.

Compared with current technologies, there are several disadvantages with the initrd approach. First, the size of the initrd is fixed. It wastes system RAM when it is not full, and the size cannot be increased when additional storage is required. Second, changes made are lost on the next reboot.

Even with its limitations, the initrd mechanism is useful for booting a system before a true Flash filesystem is working. More information on the initrd mechanism can be found in the Documentation/initrd.txt file in the Linux kernel source.

cramfs


cramfs is a compressed read-only filesytem originally developed by Linus Torvalds and included in recent Linux kernels. In the cramfs filesystem, each page is individually compressed, allowing random page access.

A cramfs image is usually placed in system Flash but can also be placed on another filesystem and mounted using the loopback device. cramfs is useful in its efficiency, and it often is desirable to have system files in a read-only partition to prevent file corruption and improve system reliability.

A cramfs image is created using the mkcramfs utility, which creates an image from the contents of a specified directory. mkcramfs can be found in the scripts/cramfs directory of the Linux source tree.

ramfs


ramfs is a filesystem that keeps all files in RAM and is often used with a Flash filesystem to store temporary data or data that changes often. The major advantage of ramfs is it grows and shrinks to accommodate the files it contains, unlike a ramdisk, which is fixed in size. The ramfs filesystem was originally written by Linus Torvalds and is included in recent kernels.

jffs2


jffs2 is a read/write, compressed, journaling Flash filesystem that is designed to be used on Flash memory devices rather than RAM devices. The jffs2 filesystem is currently in development but is extremely useful; it should be stable by publication of this article.

The jffs filesystem was originally developed for the 2.0 kernel by Axix Communications in Sweden. David Woodhouse and others improved jffs and developed jffs2, which supports compression. jffs2 addresses most of the issues of Flash filesystems, in that it provides compression, read/write access, automatic leveling and a hard power-down safe filesystem.

The journaling aspect of jffs2 is quite dynamic and works very well on Flash. The jffs2 filesystem is simply a list of nodes or log entries that contain information about a file. Each node may contain data to be inserted into a file or instructions to be deleted from a file. When a jffs2 filesystem is mounted, the entire log is scanned to determine how a file is to be created. Nodes are written to Flash sequentially starting at the first block. If additional writes are needed, blocks are consecutively written to until the end of Flash is reached, then starts at the beginning again. jffs2 includes a garbage collection thread that combines and copies valid nodes in one block to another block, then erases partially used blocks. Valid data is never erased until it has been copied to another block, which keeps existing data from ever being lost or corrupted. The process of sequentially erasing and writing Flash blocks provides wear-leveling, as it distributes the Flash writes over the entire Flash device.

The jffs2 filesystem is new and in the process of being integrated into the kernel sources. The most recent copy can be obtained via anonymous CVS at www.linux-mtd.infradead.org.

MTD Driver


The memory technology device (MTD) subsystem for Linux is a generic interface to memory devices such as Flash and RAM, providing simple read, write and erase access to physical memory devices. mtdblock devices can be mounted by jffs, jffs2 and cramfs filesystems. The MTD driver provides extensive support for NOR Flash devices that support common flash interfaces (CFIs), such as Intel, Sharp, AMD and Fujitsu. The width of the Flash bus and number of chips required to implement the bus width can be configured or automatically detected. The MTD driver layer also supports multiple Flash partitions on one set of Flash devices.

System Design Issues


Often, the best solution when designing a system is to divide different parts of the root filesystem into different filesystem partitions. The following is one possible implementation scheme:

  • Put anything that does not need to be updated at runtime in a cramfs filesystem. cramfs typically achieves over a 2:1 compression ratio and is very efficient.
  • Directories that are written to often, such as /var, should be placed in a ramfs filesystem to minimize write cycles to Flash. Note that the contents of the ramfs partition are not preserved between system power cycles or operating system reboots.
  • Any part of the filesystem that requires read/write access and must preserve information between reboots is placed in a jffs2 filesystem.

A 16MB Flash system might be partitioned like the one in Table 1.

PARTITION NAME  DESCRIPTION  FILESYSTEM TYPE  SIZE
-----------------------------------------------------------------------------------------
MTD0   Bootloader  None   256K
-----------------------------------------------------------------------------------------
MTD1   Linux kernel  None   1M
-----------------------------------------------------------------------------------------
MTD2   Root filesystem  cramfs   8M
-----------------------------------------------------------------------------------------
MTD3   /usr/local and  jffs2   6.75M
   home directories
-----------------------------------------------------------------------------------------
Table 1. Sample Partition of a 16MB Flash System


One disadvantage of this configuration is unused space in the MTD1 and MTD2 partitions is wasted. Implementing a system with only jffs2 and ramfs is also efficient if there is no concern about overwriting system files. The normal Linux file access permissions apply to files in a jffs or jffs2 filesystem, so read-only attributes can be assigned to selected files and directories to enhance system integrity.

Table 2 shows the typical Flash space required for implementing a full-featured Linux root filesystem that includes networking support and many system utilities. The jffs implementation is given for reference to illustrate the space required if compression is not used.

FILESYSTEM TYPE   SPACE REQUIRED
------------------------------------------------------------------
jffs    5.93MB
------------------------------------------------------------------
jffs2    3.09MB
------------------------------------------------------------------
cramfs    2.85MB
------------------------------------------------------------------

Table 2. Flash Space for a Full-Featured Root Filesystem


With the recent open-source developments of Flash filesystem technology, Accelent Systems has been able to implement embedded Linux systems that have a very robust read/write filesystem on standard NOR Flash. By using the jffs2 filesystem, the Accelent system software solution allows units to be powered off at any time, yet allows the user to write data to the filesystem that is preserved between reboots.

另外, 可参考下述文章:

1, http://www-128.ibm.com/developerworks/cn/linux/embed/embdev/

2,
http://www-128.ibm.com/developerworks/cn/linux/l-jffs2/

3,
http://www-128.ibm.com/developerworks/cn/linux/l-initrd.html

4,
http://www.cyberguard.info/snapgear/tb20020917.html


Technorati : , ,

 Page 4 of 6  « First  ... « 2  3  4  5  6 »
26 queries. 0.490 seconds. Powered by WordPress