zImage格式的kernel是否能带调试信息？lcd fo

dengyl

我编译的pxa的kernel vmlinux有8M大，zImage却只有700K，kernel的编译教本好像在生成zImage时，没有将调试信息放到zImage中？

另外，skyeye的ftp上有没有for pxa的kernel source？

为什么skyeye主页不更新啊，好多信息好像只能在论坛中才能找到。很不方便。

lubbock的lcd支持进展如何？我看了一下skyeye代码，认为加入lcd的支持大概需要这些工作，请指点：
1. skyeye.conf中加入0x44000000段IO空间的描述；
2. 在函数 pxa_io_write_word()中，添加对LCD各寄存器以及FrameBuffer操作的判定，然后作出相应的响应动作――设置适当的显示模式或者描绘要显示的内容。
我以前写过LCD的驱动，我认为完全模拟LCD控制器的特征是很难的，但是只模拟某些特征是很容易做到的，比如只关心lcd的X，y分辨率，颜色数，等。忽略与硬件实现有关的侦前后停止位，行前后停止位等信息。
或者可以先出来一个版本，只支持一种显示模式，根本忽略对lcd的设置，直接将指定内存空间的数据按默认的显示格式显示出来。比如，按照lubbock的默认显示模式，这样，lubbock的framebuffer驱动就直接能用了。也就可以在上面跑各种GUI了。
我现在非常需要一个lubbock的kernel代码，以及一个支持pxa lcd的skyeye。我可以做上面我说的那个简单版本的对pxa lcd的支持，基于0.7.4的skyeye。希望斑竹能给予支持！

lblaze

我也觉得0.7.4对LCD的支持并没有完成。好象只有skyeye_mach_ep7312.c中有支持（是这样吗），和你一样我也对framebuffer感兴趣，找个机会看能否向你请教请教?357743498或lblazeATpeopleDOTcomDOTcn

chyyuu

zImage中没有调试信息。
ftp://166.111.68.183/pub/embed/armlinux下有源码。
主页一般放置一些软件发布信息，如果把这里的信息也放到主页上，工作量较大，人力有限。
个人认为论坛上讨论比较方便。如果还嫌慢，可直接给我或skyeye核心开发成员发email。

dengyl,欢迎加入skyeye的开发，其实LCD的仿真和对于的驱动我们一直在做。昨天尹文超已经在skyeye上跑起了minigui的几个例子，它们运行在skyeye for ep7312上。你说的有道理。我觉得在lubbock上实现LCD仿真最简单的方法是把ep7312上的LCD仿真移植到pxa上的LCD仿真。虽然不能对应PXA2xx的LCD控制器，但由于已经有相关的framebuffer驱动和touchscreen驱动（尹文超刚完成），所以不太难。只要关注lcd 的ram地址和size，以及touch screen的中断号。

建议你直接给尹文超联系  [email protected]

dengyl

那对于用zImage的skyeye.conf，比如下面提到的：
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
然后编译内核，生成zImage, 用testsuit提供的文件系统initrd4M.img

skyeye.conf 内容如下：


cpu: xscale
mach: pxa_lubbock
mem_bank: map=I, type=RW, addr=0x40000000, size=0x0c000000
mem_bank: map=M, type=RW, addr=0xa0000000, size=0x00200000
mem_bank: map=M, type=RW, addr=0xa0200000, size=0x00100000, file=zImage, boot=yes
mem_bank: map=M, type=RW, addr=0xa0300000, size=0x00d00000
mem_bank: map=M, type=RW, addr=0xa1000000, size=0x00800000, file=./initrd4M.img
mem_bank: map=M, type=RW, addr=0xa1800000, size=0x02800000

然后运行skyeye
target sim
run
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

应该如何修改才能用vmlinux启动呢？

chyyuu

一个老外 Marc Britten   写的howto，我还没有加入到skyeye中，供参考：
filename="skyeye-howto.txt"

Full kernel source debugging with Skyeye.

Skyeye was designed not only to emulate an ARM core processor, but to allow you to use it as a source debugger.  This allows you to suspend the kernel at any time, trace its location view the source, set breakpoints, etc.  Just like debugging a normal userspace program.

When you first get started running skyeye you may be unsure how to get started using it as a source debugger, so here is a brief overview.

When compiling the kernel, under "Kernel hacking" make sure to in set the option that gives you the Debugging info.

In Linux 2.4 this is called "Include debugging information in kernel binary" and in Linux 2.6 it's called "Include GDB debugging information in kernel binary".

There are two ways to use skyeye and get full source debugging.

1) drop skyeye.conf inside the kernel source tree and run from there
2) configure gdb to look for source elsewhere.

First off is the easiest way to get up and running

1) debugging from the kernel source tree.

skyeye.conf needs to exist in the kernel source directory. The skyeye.conf line pointing to the file used to boot should point to arch/arm/boot/zImage.

Now run "skyeye vmlinux" from the top of the kernel source tree, and issue the commands to get started.

target sim
load
run

The kernel should begin booting.

2) configuring gdb to look for the source.

Not as hard as it sounds but adds typing.
instead of executing skyeye vmlinux you execute "skyeye --directory=/path/to/kernel/source vmlinux"

The nice part about doing it this way is the source tree remains clean of your configuration and ramdisk files.

I like to symlink both zImage and vmlinux from the kernel source directory to a seperate directory and run skyeye this way.

ln -sf /path/to/linux-2.6.6/        linux-src
ln -sf linux-src/vmlinux vmlinux
ln -sf linux-src/arch/arm/boot/zImage zImage

and run skyeye --directory=./linux-src vmlinux

If you forget to specify the --directory argument when starting skyeye, just execute "dir linux-src" while at the SkyEye prompt.


-- Source Level debugging --

Once you start seeing the kernel boot you can hit ctrl+c.  This drops you out of the running process (aka the kernel) and into the GDB interface.  You should notice that a number and a line of code has been printed out.

Type list and hit return.  This shows you the source code surrounding the line of code currently being executed along with the GDB line numbers for these lines.  You'll notice the line that was printed out after you hit ctrl+c somewhere near the middle of these lines.

Type backtrace and hit return.  This will show you a list of functions with 0 being the the function that you are currently inside, 1 being the function that called that, etc.

You have to be careful because the kernel calls many things out of order, etc and you can (at least at this time) easily confuse the debugger.


http://www.delorie.com/gnu/docs/gdb/gdb_toc.html

Is a mirror for the GDB manual that has the GDB 5.3 version which is what skyeye is based on.  I highly recommend reading this to understand using the debugger.

cosix_MMX

只要关注lcd 的ram地址和size，以及touch screen的中断号

更正一下，像触摸屏、键盘、鼠标等这一类输入设备，驱动中一般采用轮询的方式而不是中断的方式。我不清楚skyeye中的touch screen如何，但是我所做过的3个触摸屏驱动中（芯片分别是ADS7843、ADS7846、UCB1400），都是用的轮询。驱动中注册了中断，但不是为触摸屏服务的，而是响应同步串行总线（SSI或SSP）用的。

dengyl

用skyeye vmlinux命令可以调试了，但是实际运行的好像还是zImage，还是需要
Uncompressing Linux。。。。。。
如果，在skyeye.conf中，不指定将zImage载入，run命令就没有显示。

还有一问，skyeye.conf中定义的内存空间都在0xa0000000附近，而kernel的Start address 在0xc0008000,为什么？
skyeye.conf中的地址是物理地址吗？0xc0008000应该是虚拟地址？

cosix_MMX

而kernel的Start address 在0xc0008000,为什么？

你nm一下vmlinux，看看导出的符号的地址就明白了，全是0xc0000000以上的地址。
在32位系统中，CPU的寻址范围从0x00000000-0xFFFFFFFF，共4G。内存管理将其分为高端内存和低端内存。
linux设备驱动开发一书的第13章mmap和DMA中有这么一段：

在 i386 系统上，低端内存和高端内存的之间的界限通常设置为1GB。 这个界限与最初的 PC上老的640KB限制没有任何关系，相反它是内核本身设置的限制，用于将 32 位地址空间分割为内核空间和用户空间。

一般CPU的0x00000000地址用于Static Chip Select 0（静态存储片选0，即flash或boot地址），不能改变。所以kernel的低端内存选择了位于0xC0000000-0xFFFFFFFF的1GB空间内。
这就是为何kernel的函数、符号都位于0xC0000000以上的地址。

halfyear

在触摸屏驱动程序中一般注册两个中断：
笔触中断和SPI中断(我们参考的是mc68328digi.c)

100%忠实于真实硬件，没有必要也不可能，为了提高效率，对触摸屏的仿真进行了简化
，只用到了笔触中断，且“无中生有”一块缓冲区来存放上一次鼠标事件对应的坐标，
事件类型及键的状态。

另一款模拟器xcopilot的触摸屏仿真中也绕过了所有的spi中断，仿真思路大同小异