I am still trying to figure out how to write to the LCD on an Embest SCB210-II. Now I am trying to compile and Xlib tutorial program I downloaded. But when I do the compile, I get link errors because of missing libraries. Here is the program:
#include // Every Xlib program must include this #include // I include this to test return values the lazy way #include // So we got the profile for 10 seconds #define NIL (0) // A name for the void pointer
----------------------------------------------------------------- Here are the errors: /tmp/cckio3Hm.o: In function `main': /tmp/cckio3Hm.o(.text+0x14): undefined reference to `XOpenDisplay' /tmp/cckio3Hm.o(.text+0xf8): undefined reference to `XCreateSimpleWindow' /tmp/cckio3Hm.o(.text+0x110): undefined reference to `XSelectInput' /tmp/cckio3Hm.o(.text+0x11c): undefined reference to `XMapWindow' /tmp/cckio3Hm.o(.text+0x130): undefined reference to `XCreateGC' /tmp/cckio3Hm.o(.text+0x148): undefined reference to `XSetForeground' /tmp/cckio3Hm.o(.text+0x158): undefined reference to `XNextEvent' /tmp/cckio3Hm.o(.text+0x1a4): undefined reference to `XDrawLine' /tmp/cckio3Hm.o(.text+0x1ac): undefined reference to `XFlush' collect2: ld returned 1 exit status make: *** [wer] Error 1
The arm gcc cross compiler supplied by Embest searches the /usr/local/arm/2.95.3/.../inlcude directory for include files. But there was no Xlib.h in that path. So I used the -I option to force it to look at /usr/local/include where I have an Xlib from a desktop GTK+ installation. Of course I can't use the desktop libraries as well since my target is ARM and the desktop libraries are for a Pentium. So where should I look in my ARM files for a library that will satisfy the linker errors?
There are hundreds of files there and it is not clear to me which ones I need to build Xlib.
Besides, at some point Xlib is going to have to depend on something I have here that is unique to the specific board and Linux build that I have on this board. I also have hundreds of source files from Embest. Do you have any hints as to what files and what functions those might be?
you have to add -L in addition to -I. This instructs the linker to search for additional library.
I think you have to compile the full X sources (from X.org) using your cross compiler to get libraries that match your ARM system. You
*could* successfully take libX11.so etc. from e.g. the Sharp Zaurus but probability is low that it matches all other dependencies. Or, you can look at Open Embedded.
You need a full cross compile environment to do so. This means a cross toolchain, cross glibc and (most of) the X libs (also cross compiled). You should try to get another build environment for your ARM that support all these components. If you know your hardware and how to handle kernels for it, you can try to adapt one of our BSPs (for example
formatting link
It offers all components you need and is hardware independent. Contact me if you need help.
I don't understand how it could all be hardware independent. The functionality of Xlib has to be hardware dependent at the lowest level. This Embest board has certain address assignments for its peripherals. What I am trying to determine is where that connection is made (between the hardware-independent and the hardware-specific). What I am looking for is the equivalent of the BIOS on a PC.
Regarding knowing my hardware, no I do not know it beyond what little documentation is provided to me by Embest. Somewhere in the vast collection of files that they supplied must be the include files and libraries that will make this connection. I am not in a position to build the kernel from scratch.
Part of the problem is my unfamiliarity with embedded Linux. I am used to programming PICs without an OS, and Pocket PCs using MS tools. I find this whole open-source world a little disconcerting. There is so much information available that I can't sift through it all. But thanks for your advice. I will try to follow up on it.
Xlib is hardware independent. The X driver for the lowest level is hardware dependent. Xlib and the hardware driver are two different layers.
Should be defined in the BSP.
One hardware dependent part is the Linux kernel itself. The second is the Xorg driver. This is the main feature of the BSP (board support package) All other parts are hardware independent. You are going to program against Xlib (not against the Embest board).
? How does your board currently boots? U-Boot?
Without knowledge about the hardware you are going to do a hard job.
Do you have a link for some files and information?
On Fri, 04 Jan 2008 11:07:15 +0100, Juergen Beisert wrote:
And how do I recognize a Board Support Package? I have a support CD that is full of files and no guide as to what those files are for.
That should not be a problem because the board comes with Linux pre-installed, and I have no wish to modify the kernel. It has a flash file system where I intend to install my application.
The boot process shows up on a serial port as a console. Here is a capture of that serial port:
VIVI version 0.1.4 ( snipped-for-privacy@localhost.localdomain) (gcc version 2.95.3 20010315 (release)) #0.1.4 Sun Jul 2 18:43:06 EDT 2006 MMU table base address = 0x33FBC000 Succeed memory mapping.
+---------------------------------------------+ | S3C2410X USB Downloader ver R1.11 SEP/03/02 |
+---------------------------------------------+ FCLK=200MHz,DMA mode USB: IN_ENDPOINT:1 OUT_ENDPOINT:3 FORMAT: +++ NAND device: Manufacture ID: 0xec, Chip ID: 0x76 (Samsung K9D1208V0M) Could not found stored vivi parameters. Use default vivi parameters. Press Return to start the LINUX/Wince now, any other key for vivi Copy linux kernel from 0x00050000 to 0x30008000, size = 0x00100000 ... done zImage magic = 0x016f2818 Setup linux parameters at 0x30000100 linux command line is: "noinitrd root=/dev/mtdblock/0 init=/linuxrc console=ttyS0" MACH_TYPE = 193 NOW, Booting Linux...... Uncompressing Linux................................................................ done, booting the kernel. Linux version 2.4.18-rmk7-pxa1 ( snipped-for-privacy@localhost.localdomain) (gcc version 2.95.3
20010315 (release)) #1 Thu Nov 2 17:15:00 CST 2006 CPU: ARM/CIRRUS Arm920Tsid(wb) revision 0 Machine: Samsung-SMDK2410 Security risk: creating user accessible mapping for 0x08000000 at 0xe0000000 Security risk: creating user accessible mapping for 0x10000000 at 0xe0100000 On node 0 totalpages: 16384 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: noinitrd root=/dev/mtdblock/0 init=/linuxrc console=ttyS0 DEBUG: timer count 15626 Console: colour dummy device 80x30 Calibrating delay loop... 99.94 BogoMIPS Memory: 64MB = 64MB total Memory: 62360KB available (1545K code, 415K data, 144K init) Dentry-cache hash table entries: 8192 (order: 4, 65536 bytes) Inode-cache hash table entries: 4096 (order: 3, 32768 bytes) Mount-cache hash table entries: 1024 (order: 1, 8192 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket CPU clock = 200.000 Mhz, HCLK = 100.000 Mhz, PCLK = 50.000 Mhz Initializing S3C2410 buffer pool for DMA workaround S3C2410 USB Controller Core Initialized USB Function Character Driver Interface - 0.5, (C) 2001, Extenex Corp. usbctl: Opened for usb-char usbctl: Started for usb-char Starting kswapd devfs: v1.10 (20020120) Richard Gooch ( snipped-for-privacy@atnf.csiro.au) devfs: boot_options: 0x1 ttyS%d0 at I/O 0x50000000 (irq = 52) is a S3C2410 ttyS%d1 at I/O 0x50004000 (irq = 55) is a S3C2410 ttyS%d2 at I/O 0x50008000 (irq = 58) is a S3C2410 Samsung 320x240 LCD Samsung 320x240 LCD Console: switching to colour frame buffer device 40x30 Installed S3C2410 frame buffer pty: 256 Unix98 ptys configured leds initialized touchpanel: installed S3C2410 Real Time Clock Driver v0.1 block: 128 slots per queue, batch=32 Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 50MHz system bus speed for PIO modes; override with idebus=xx eth0: cs8900 rev K(3.3 Volts) found at 0xd0000300 cs89x0 media RJ-45, IRQ 37 PPP generic driver version 2.4.1 Linux video capture interface: v1.00 SCSI subsystem driver Revision: 1.00 scsi0 : SCSI host adapter emulation for IDE ATAPI devices UDA1341 audio driver initialized NAND device: Manufacture ID: 0xec, Chip ID: 0x76 (Samsung K9D1208V0M) bon0: 00000000-00030000 (00030000) 00000000 bon1: 00030000-00130000 (00100000) 00000000 bon2: 00130000-03ffc000 (03ecc000) 00000000 usb.c: registered new driver usbdevfs usb.c: registered new driver hub usb-ohci.c: USB OHCI at membase 0xe9000000, IRQ 26 usb.c: new USB bus registered, assigned bus number 1 hub.c: USB hub found port #1 suspened! port #0 alived! hub.c: 1 port detected usb.c: registered new driver usblp printer.c: v0.8:USB Printer Device Class driver usb.c: registered new driver ov511 ov511.c: v1.48a for Linux 2.4 : OV511 USB Camera Driver usb.c: registered new driver serial usbserial.c: USB Serial support registered for Generic usbserial.c: USB Serial Driver core v1.4 Initializing USB Mass Storage driver... usb.c: registered new driver usb-storage USB Mass Storage support registered. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 4096) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NetWinder Floating Point Emulator V0.95 (c) 1998-1999 Rebel.com yaffs: dev is 7936 name is "1f:00" VFS: Mounted root (yaffs filesystem). Mounted devfs on /dev Freeing init memory: 144K Using /lib/mmcsd_core.o Warning: loading mmcsd_core will taint the kernel: non-GPL license - Not GPL, Proprietary License See
formatting link
for information about tainted modules Using /lib/mmcsd_slot.o Warning: loading mmcsd_slot willMtaint the kerneM: non-GPL licenCe - Not GPL, Pr/prietary LicensS See
formatting link
#export-taintedSfor informationlabout tainted modules ot initialized Using /lib/mmcsd_disk.o Warning: loading mmcsd_disk will taint the kernel: non-GPL license - Not GPL, Proprietary License See
formatting link
for information about tainted modules
Please press Enter to activate this console. [11/Jan/2031:15:58:15 +0000] boa: server version Boa/0.94.13 [11/Jan/2031:15:58:15 +0000] boa: server built Feb 28 2004 at 21:47:23. [11/Jan/2031:15:58:15 +0000] boa: starting server pid=32, port 80
That is provided for too. I have an image of the pre-installed kernel and a JTAG programmer to re-flash the initial file system from scratch if needed.
Here is the proc/ directory:
[root@Embest /]$ cd proc [root@Embest /proc]$ ls
1 5 devices ioports mounts sys
2 6 driver kcore mtd sysvipc
29 7 execdomains kmsg net tty
3 8 fb ksyms partitions uptime
32 bon filesystems loadavg scsi usb
34 bus fs locks self version
4 cmdline ide meminfo slabinfo video
40 cpu interrupts misc stat yaffs
44 cpuinfo iomem modules swaps
All right. But if you clobber your filesystem while you test your application you must find a way to restore it to a well known working state.
VIVI? Never heard of yet.
Uhhh. Proprietary modules...
Note: You are root at your system. You can do what you want to do and destroying everything!
Take a look into the "files" in the proc/ directory. Their content tell you many things about your system you should know (in the case you must recover your system after a huge disaster).
find / -name libX11.* -print on your board. If it shows a file, you are lucky and already have the binary X-lib. You can then copy it to your host system where the cross-compiler runs and configure (-L) the cross-linker to search for it.
If not, you still have to cross-compile X11 yourself, although the Xlib itself is hardware independent, there are still dependencies with the Linux sytem and the processor. E.g. does it use OABI or EABI? Which byte-order? Which alignment for char in structs. All this is (unfortunately different between different ARM based systems).
Then, you nedd an X server to run on your hardware. This is more hardware dependent to get touchs screen events and control the frame buffer. But if you find an Xlib on your system you probably will also find an X-server (Xfbdev).
On Fri, 4 Jan 2008 08:55:20 -0800 (PST), hns wrote:
Guess I'm not lucky. The "find" found nothing. In fact there are no hits on X*.* or x*.* either. And I know I've got the syntax right because there are hits on A*.*, for example.
If it is of any use, here is the results of find / -name lib*.*:
Ups, the file content is more interesting than the directory content. For example "iomem" shows what physical hardware area is assigned to what kind of hardware. "interrupts" shows what interrupts are used by what hardware.
The wish to modify the Kernel (usually that means to write drivers that are linked to the main Kernel) might come up once you want to access your own hardware attached to the board. So you should make sure that the Kernel sources, the Kernel build system and the tools to upgrade the board to a newly built Kernel are provided with the board (best before you pay :) ). BTW: this is _necessary_ for the seller not to violate the GPL.
QTOPIA sounds for embedded QT. And embedded QT is for framebuffer usage and no X. To test your graphic you should try Trolltech's QT examples instead of X examples. Welcome in the world of C++... ;-)
Ah, it has Qt. You may then be lucky that X/Qt runs. It will then use the hardware dependent drivers that Qt provides. It has been developed for the Sharp Zaurus:
Casting my lot with QT means commiting to eventually paying for a commerial development seat ($5000). Besides, our application would use so little of QT, it hardly seems worthwhile. The application is an upgrade to an existing
68HC11-based oil-film measurement instrument. The instrument has a 4 x 4 keypad, a 2-line text LCD, some general-purpose I/O to flash an ultraviolet light source, and a SPI-connected A/D chip to read the photo detector. Moving from a 68HC11 to a Linux board will give us better connectivity with the outside world (removable USB flash drive), and a slightly sexier display. But there is no mouse or other pointing device, no touchscreen, no dialog boxes, no graphic pushbuttons, etc. Xlib really would be a more appropriate level on which to operate.
So there is no real use for X anyway (unless you want to use remote X to allow for a real GUI on a PC for your device). I think there are several much lighter libraries that can help writing to the framebuffer.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.