Category: Linux

转载请注明出处:http://ganquan.org,谢谢。本文链接是http://ganquan.org/blog/2009/12/2-6-32-port-to-mini2440/

过程非常简单,麻烦的是如果出问题,就要要一遍又一遍的编译。

先上图:

友善官方的Qtopia系统我早就看烦了,直接启动进入字符界面

img_3676

下面是移植步骤,

1.www.kernel.org下载内核代码,修改构架和编译器

2.修改时钟频率,mini2440开发板用的是12M晶振,修改arch/arm/mach-s3c2440/mach-smdk2440.c

把下面代码中的16934400改为12000000,如果不改串口会出现乱码

static void __init smdk2440_map_io(void)
{
s3c24xx_init_io(smdk2440_iodesc, ARRAY_SIZE(smdk2440_iodesc));
s3c24xx_init_clocks(12000000);
s3c24xx_init_uarts(smdk2440_uartcfgs, ARRAY_SIZE(smdk2440_uartcfgs));
}

3.修改mini2440的lcd配置,有两个地方要修改,第一是修改LCD屏幕的参数,第二是修改fbi

修改LCD屏幕参数,mini2440使用的是3.5寸的屏幕,在arch/arm/mach-s3c2440/mach-smdk2440.c中,写入

  • 3.1修改LCD参数结构。

#define LCD_WIDTH 240
#define LCD_HEIGHT 320
#define LCD_PIXCLOCK 170000

#define LCD_RIGHT_MARGIN 25
#define LCD_LEFT_MARGIN 0
#define LCD_HSYNC_LEN 4

#define LCD_UPPER_MARGIN 1
#define LCD_LOWER_MARGIN 4
#define LCD_VSYNC_LEN 1

修改lcd参数结构为:

static struct s3c2410fb_display mini2440_lcd_cfg __initdata = {

#if !defined (LCD_CON5)
.lcdcon5    = S3C2410_LCDCON5_FRM565 |
S3C2410_LCDCON5_INVVLINE |
S3C2410_LCDCON5_INVVFRAME |
S3C2410_LCDCON5_PWREN |
S3C2410_LCDCON5_HWSWP,
#else
.lcdcon5    = LCD_CON5,
#endif

.type        = S3C2410_LCDCON1_TFT,

.width        = LCD_WIDTH,
.height        = LCD_HEIGHT,

.pixclock    = LCD_PIXCLOCK,
.xres        = LCD_WIDTH,
.yres        = LCD_HEIGHT,
.bpp        = 16,
.left_margin    = LCD_LEFT_MARGIN + 1,
.right_margin    = LCD_RIGHT_MARGIN + 1,
.hsync_len    = LCD_HSYNC_LEN + 1,
.upper_margin    = LCD_UPPER_MARGIN + 1,
.lower_margin    = LCD_LOWER_MARGIN + 1,
.vsync_len    = LCD_VSYNC_LEN + 1,
};

  • 3.2修改fbi

static struct s3c2410fb_mach_info smdk2440_fb_info __initdata = {
.displays    = &smdk2440_lcd_cfg,
.num_displays    = 1,
.default_display = 0,

.gpccon =       0xaa955699,
.gpccon_mask =  0xffc003cc,
.gpcup =        0x0000ffff,
.gpcup_mask =   0xffffffff,

.gpdcon =       0xaa95aaa1,
.gpdcon_mask =  0xffc0fff0,
.gpdup =        0x0000faff,
.gpdup_mask =   0xffffffff,

.lpcsel        = 0xf82,
};

4.修改nand分区表,修改arch/arm/plat-s3c24xx/common-smdk.c,这个根据自己的情况来写,照抄是没用滴。

static struct mtd_partition smdk_default_nand_part[] = {
[0] = {
.name    = “bootloader”,
.size    = 0×00060000,
.offset    = 0,
},
[1] = {
.name    = “kernel”,
.offset = 0×00060000,
.size    = 0×00200000,
},
[2] = {
.name    = “root”,
.offset = 0×00260000,
.size    = 0x3fd80000,
}
};

5.修改machine ID,修改arch/arm/tools/mach-types,填写自己的machine ID

s3c2440            ARCH_S3C2440        S3C2440            1999

6.给内核打yaffs文件系统的补丁。去http://www.aleph1.co.uk/cgi-bin/viewcvs.cgi/下载GNU tarball,解压后进入yaffs2目录,给内核打补丁

./patch-ker.sh c ~/kernel/linux-2.6.32

补丁打好后,在内核代码目录下的fs目录新增了yaffs2目录和相关配置文件

7.因为2410和2440很多地方是一样的,可以用2410的配置文件为基础来配置内核。在内核代码主目录下执行:

make s3c2410_defconfig

这个命令其实就是把arch/arm/configs/s3c2410_defconfig文件拷贝过来命名为.config,所以也可以自己cp。其实在2.6.31版内核中就已经加入了对mini2440开发板的支持,但是我没有选。

配置内核这里没有什么好说的,按照自己的需求来配置。

注意两个问题:

(1)编译后的镜像大小不要超过分区配额

(2)不要裁剪太狠了,把一些基本支持都去掉了,这样一些设备就用不了啦

开始编译。我的机器配置是Core 2 T5500 1.66G,2.5G 内存,运行Debian Lenny 5.0.3,编译10分钟左右就OK了。

网卡驱动我一直没有移植成功。后面弄好了再写上来。

EOF

今天邮件列表里面讨论了一件事情:

在以后的内核中,PATA(IDE)驱动将会逐步过渡到基于libata的驱动,基于libata的驱动会把ATA/ATAPI设备描述为SCSI设备,这样的话硬盘分区就会由原来的/dev/hdX变成/dev/sdX,那么一些配置文件也会产生变化,例如/etc/fstab。

有人提议为了方便升级新内核,方便自动修改配置文件,让内核依赖python包好啦。提议者说python已经成为标准配置了,基本上所有用户都安装了,所以用户不会感到有什么变化的。同时他也意识到了这样会使得安装内核的空间增大,这样会招来嵌入式平台的一致反对,所以他提出让内核依赖python-minimal包。

立马有个家伙说如果那些搞嵌入式的反对,那可以用perl来重写,他可以出力。(我感觉这家伙就像是楼上的马甲。)

结果却招来楼下一致的反对。

有个分析比较深刻的说,修改配置文件这样的事情应该算是“维护系统”操作,而不是内核的直接依赖,所以没必要让内核依赖python,并且内核也不应该跟这些“维护性质”的事情搅和到一起去。同时这哥还指出即使是python-minimal,下载也要用掉1.2M,解压后有4M,这在嵌入式来看是不可以的,而且也不可能在嵌入式平台上内核依赖python或者perl。

后面有人直接指出python-minimal是从ubuntu那里来的东西。啥都不要依赖python-minimal,除了python自己。反正不管怎么说都是不应该让内核依赖python或者是perl。
我觉得其实对于普通用户来看,python确实已经是标配了,内核增加一个依赖用户不会感觉什么差别,当然嵌入式平台另当别论,但是关键的是这样破坏了各个模块之间的独立性,增加了耦合度,“高耦合”的系统肯定不利于扩展和维护。我是不赞同让内核依赖python的,如果需要修改,可以通知用户让用户来决定,当然不是所有的用户都知道接下来自己的决定意味着什么,这样也就增添了系统的复杂性,降低用户体验了。

真是一个麻烦的问题。

有人说这个问题将会在开发大会上讨论决定是否自动修改配置文件,期待最终结论。

用id3删除mp3的id3信息

aptitude install id3
id3 -l * #查看id3信息
id3 -d * #删除

EOF

ftp备份神器

正打算动手写脚本,突然闪现一道亮光,这下不写了。

mirror ./ ~/BLOG_BAK

-n  就是newer

-R 就是reverse ,第一个写local directory,第二个写remote directory

反正文件不大,没必要压缩,这样将来如果-R了还比较方便。Hoho~

EOF

Linux下制作ISO镜像的方法

刚用mkisofs做了个镜像,其实下面这些方法都可以:

# dd if=/dev/cdrom of=/root/rh1.iso
# cat /dev/cdrom > /root/1.iso
# cp -r /home/user name.iso
# mkisofs -J -r -o filename.iso /directory

EOF

推荐一个游戏 Danger from the deep

转载请注明出处,谢谢。http://imganquan.org

这个帖子其实应该在昨天发,今天补上。

目前还没有中文翻译,我就叫做《深海危机》吧(请无视我这个拙劣的翻译)。

时光回到20世纪二战时期,玩家扮演德军潜水艇的艇长,操纵潜水艇完成一系列军事行动。目前只支持单机游戏,将来会支持联机对战。

初次试玩,感觉游戏操作难度还是比较大,好在官方已经把游戏手册写好了:),手册有整整35页,很详细并且有很棒的配图(看看外国人是怎么写文档的,光用户文档都足够让我学习的),英语不太差的人都能搞定。游戏中画面效果非常棒,可以点击这里查看游戏截图。Danger from the deep是一个开源项目,根据官网的开发活跃度来看,这个项目属于缓慢但是稳定的那种,另外这个游戏采用的是OpenGL开发的,有能力的人可以直接去参与开发,开发文档目前只写了4节,主要是一些框架性描述和Code-Style,目前这个项目急缺维护者,在开发文档最后醒目地写了Janitors wanted,有精力的朋友请积极参与。目前游戏有部分功能还没有实现,依旧还在开发中。但是现在已经有一定的可玩性了,将来应该是一个非常不错的游戏,非常值得期待。

最后,这个游戏是多平台的,目前已经能在以下平台成功运行。

  • Windows (2000/XP/98)
  • Linux (i386/x86-64/sparc64)
  • FreeBSD (x86-64/sparc64/IA64)
  • MacOS X (ppc64)

游戏需求如下:

  • A OpenGL 1.5 Compliant graphics card (OpenGL 2.0 or greater is recommended)
  • A fairly fast CPU, anything from 1.0ghz to 1.5ghz or greater should work
  • 256mb RAM (512mb or more would be much better)
  • The usual suspects; Keyboard, monitor, mouse and some speakers or headphones

简单说一下在Debian下安装这个游戏的方法:

1.下载dangerdeep_0.3.0.1_i386.deb(这个是目前Deb的最新版本,截止到2009.11.12),安装这个包

2.下载dangerdeep-data-0.3.0.zip,解压后将data目录中所有内容都放到/usr/share/games/dangerdeep目录中

3.运行dangerdeep即可启动游戏

其他发行版的安装方法详见官网。

目前游戏已经被翻译成了多种语言,就是还没有中文,翻译需要一定的二战历史基础和航海/潜水/仪表专业词汇知识,有能力的英语达人赶紧跟进吧。

我的笔记本情况如下:Core2 T5500 1.66GHz ,内存2.5G, 显卡GeForce Go 7300, 显存128MB。游戏中设置分辨率为1280×800,一点也不卡,效果非常棒,本本发热量一点也不大。BTW,我的系统是Debian 5.0.3 stable。

这里就是Danger from the deep的官方网站。

Enjoy it!

Debian Lenny安装XvidCap

去sf获取最新版xvidcap_1.1.7_i386.deb。

安装时依赖liblame0,这个库在lenny官方源中没有,不过可以在这里找到。

Just for convenience

1.can not type with scim-python in OOo 3.1

sudo ln -snf /usr/lib/gcc/i486-linux-gnu/4.3.2/libstdc++.so /opt/openoffice.org/ure/lib/libstdc++.so.6

sudo ln -snf /usr/lib/gcc/i486-linux-gnu/4.3.2/libgcc_s.so /opt/openoffice.org/ure/lib/libgcc_s.so.1

2.ruijieclient.conf
authentication mode 1
echo interval 4
intelligent reconnect 1
auto connect 0
fake version 3.35
dhcp mode 2

Debian挂载Windows分区

昨天给笔记本换个320G的硬盘,昨天晚上把Windows装好了。鉴于手中Debian 5.0的光盘升级量会比较大,索性重新下载Debian 5.0.3,结束后立马刻盘安装,安装过程中找不到一个包。镜像下载之后我检查过md5,那么问题肯定出在刻录速度过快,看来是刻费了一张碟。第二次控制刻录速度,重新刻盘安装。非常顺利。

我的分区计划是让Windows和Debian都能够同时使用一个120G的分区,用来存放文档,多媒体之类的文件。可惜Debian Lenny不能双击挂载Windows分区,算了,双击我也省了,让它自动挂载吧。

ganquan@debian:~$ sudo fdisk -l
Disk /dev/sda: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xf601f601

Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1        5099    40957686    7  HPFS/NTFS
/dev/sda2            5100       12748    61440592+   7  HPFS/NTFS
/dev/sda3           12749       28046   122881185    7  HPFS/NTFS
/dev/sda4           28047       38913    87289177+   5  Extended
/dev/sda5           30406       38913    68340478+  83  Linux
/dev/sda6           28047       30356    18555012   83  Linux
/dev/sda7           30357       30405      393561   82  Linux swap / Solaris

ganquan@debian:~$ sudo mkdir /mnt/WINC /mnt/WINE /mnt/WINF

ganquan@debian:~$ sudo vi /etc/fstab

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>           <dump>  <pass>
proc            /proc           proc    defaults                0       0
/dev/sda6       /               ext3    errors=remount-ro     0       1
/dev/sda5       /home           ext3    defaults                0       2
/dev/sda7       none            swap    sw                      0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto         0       0
/dev/sda1        /mnt/WINC        ntfs-3g    default                 0         0
/dev/sda2        /mnt/WINE        ntfs-3g    default                 0         0
/dev/sda3        /mnt/WINF        ntfs-3g    default                 0         0

完事,挂载参数只要default就行,不必单个指定编码,掩码之类的

redhat网站查到下面的信息,说是因为内存不够的原因。我觉得这个可以当作出现这个问题的解释,但是却解释得不够“完美”,我仍旧还在疑惑中:如果是是因为内存不够的原因,那么在每次测试之前,只要保证机器状态一样,那么TCP: time wait bucket table overflow这条信息的输出次数就应该是一样的,或者差的不是很多,因为每次有一个socket来了,就给一个数据结构,直到内存用完输出TCP: time wait bucket table overflow信息,但是我测试的结果是差异不小,这就让我感觉疑惑了,莫非每次分配的数据结构不一样大?这不可能。我每次单独测试都是重启开发板,然后不运行任何其他程序就进行测试的,这样应该可以保证每次测试机器的状态不是差的很多吧。

The “TCP: time wait bucket table overflow” message shows when the kernel is unable to allocate a data structure to put a socket in the TIME_WAIT state.

This is happening according to linux/net/ipv4/tcp_minisocks.c:

if (tcp_tw_count < sysctl_tcp_max_tw_buckets)
tw = kmem_cache_alloc(tcp_timewait_cachep, SLAB_ATOMIC);

if(tw != NULL) {
(..)
} else {
/* Sorry, if we’re out of memory, just CLOSE this
* socket up. We’ve got bigger problems than
* non-graceful socket closings.
*/
if (net_ratelimit())
printk(KERN_INFO “TCP: time wait bucket table overflow\\n”);
}

This problem is more likely to happen on systems creating a lot of TCP connections at a fast pace. RFC 793 decided that those sockets should stay in the TIME_WAIT state for 2*MSL (Maximum Segment Life), but the Linux implementation seems to make the TIME_WAIT state last for 1 minute.

Monitor the resources used by those time wait buckets by watching:

# cat /proc/slabinfo | grep tcp_tw_bucket

The size of the time wait bucket can be adjusted by writing to /proc/sys/net/ipv4/tcp_max_tw_buckets. However, the link between the client and the server cannot cause packets to arrive out of order, then the TIME_WAIT state can be skipped and sockets can be recycled immediately. Socket recycling can be configured in /proc/sys/net/ipv4/tcp_tw_recycle, but check with your network administrator to verify whether it’s safe to do so.