1. Home
  2. Embedded Linux
  3. Is this board usable?

Is this board usable?

I am faced with the possibility of using an ARM-based board from Embest, a Chinese company, for an embedded linux job, and I don't know if I can proceed. The board is the SBC2410II, if you are interested.

Ideally, the board manufacturer would be the source of my help, but they have been totally unresponsive to my queries, and for reasons that are irrelevant to my question, I may have to figure this out without any further help from them. Also, I am relatively new to linux, so maybe the fault is my inexperience. Anyway, here is how far I've gotten.

The board comes from Embest with linux pre-flashed, including a file system. The linux console presents itself on a serial port. The manufacturer supplies a CD with some minimal documentation on loading an adapted ARM version of gcc into my desktop linux, which I have done. Using these supplied tools, I was able to cross-compile the "hello, world" console program on my desktop linux, move it to a flash memory stick, plug the memory stick into a USB host port on the embedded board, mount the memory stick from the linux console on the embedded board, copy the compiled hello world to the /bin directory and run it. It runs fine.

The board also connects to a small LCD color graphic screen on which the Embest logo currently appears. For my application I need to put text on that display, but none of the supplied sample programs deal with the LCD display. I have not been able to find documents on how to interface to that display. The CD with development tools from Embest has a lot of stuff on it - various libraries and include files. I have browsed many of the include files for hints on what the API looks like to interface to the LCD, but nothing makes sense to me, possibly because I don't know what to look for.

Several of the directories on the CD deal with Qt and Qtopia, which would imply that Qt has been ported to this board. Of course the Embest-supplied tools do not include a complete Qt development package. I have inquired with Trolltech and they tell me a single seat for developing embedded linux for a commercial product is $5000. This is beyond my budget. Besides, my graphics needs are few. I don't need fancy dialog boxes or push buttons. The application is an update for an existing application that I wrote 13 years ago on a 68HC11 with a

2-line LCD text display and no RTOS. I just need a low-level interface to the new LCD. I would even consider writing my own font-rendering functions, because only one fixed-width font is needed. Even Qt has to sit on top of something, but I have not found anything in the Embest documentation or include files that gives a hint as to what that something might be.

On another front, the Embest documentation gives a memory address of 0x56000054 for some general-purpose I/O that I will also need. So I tried to access it from within a modified "Hello world" console program as follows:

int *p = (int*)0x56000054; printf("%x",*p);

and I get a segmentation error with a dump of the ARM registers. So I assume that my linux program is not allowed to touch hardware directly. I need to use a library to do that. Once again, I have failed to find such a library.

So what should I be looking for?

Robert Scott Ypsilanti, Michigan

Reply to
Robert Scott
Loading thread data ...

The LCD is probably just sitting off an I2C or serial bus. If you look in the /dev directory on your target you might be able to figure out which device file belongs to the LCD. If it has a separate driver it should appear in the lsmod listing. That should give you a hint where to find the source code. If the driver is built into the kernel then do a make menuconfig to see if you can find where the LCD is enabled.

As for the segmentation fault, you need to look up the mmap command. This allows you to map physical memory locations so that your user space programs can access them. Without telling the kernel that you want to access physical memory it assumes you mean virtual memory which then triggers an error because your process is only allowed to access its own memory space.

-Clark

Reply to
cpope

From his post, I understood he is not configuring kernel, therefore I doubt he has access to kernel's configuration.

He hasn't mention the kernel version, therefore mmap might not be available. Also, he has to know what is he writing. Writing random addresses can cause random behavior like he got with that code dump

Reply to
anon

The LCD is connected to the board by a 50-pin ribbon cable.

out which

The /dev directory has many entries, but none of them say "LCD" or "display" to me.

The lsmod command yields:

mmcsd_disk 3572 (unused) mmcsd_slot 3964 (unused) mmcsd_core 8712 (used by mmcsd_disk mmcsd_slot)

As anon said, I am not building the kernel. Is that what make menuconfig does?

I see. It was a long-shot effort anyway. I didn't really expect that I would be writing code at that level. I'm certainly not going to try to interface to the LCD at this level.

If it helps, the kernel version is 2.4.18-rmk7-pxa1

Robert Scott Ypsilanti, Michigan

Reply to
Robert Scott

I think you only chance is to figure out their examples

Reply to
anon

figure out which

"display" to

source

does?

programs

physical

would

interface to

I guess if it is a color graphic display with such a large cable it is probably more complicated than a simple 2x20 LCD. Most of the simple ones are either spi, i2c, or serial.

Do you ever see the graphics change during the board boot or is it statically the logo? If it is static it may mean that the image is coming from the LCD's micro and there may not be any driver on the main board. Especially, if they have no examples that affect the lcd.

One other thing to check is the init scripts in /etc/rc.d. If the screen changes during boot something in there must be getting executed to make the change happen. If so you can reverse engineer it.

Is this the board:

formatting link
That claims to have a color_lcd_test program on it?

-Clark

Reply to
cpope

On Tue, 18 Dec 2007 11:58:55 -0500, "cpope" wrote:

Almost. Your reference is for the SBC2410-I. Mine is the SBC2410-II, which does not advertize such a test program for it. I have looked at the scripts in /etc/rc.d, but nothing looks like it obviously initializes the display. Here is a capture of the entire boot-up sequence, as seen on the console port. The LCD shows the logo somewhere in the last 1/3 of the following text. It goes by so fast it is hard to say exactly.......

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

[root@Embest /]$

Robert Scott Ypsilanti, Michigan

Reply to
Robert Scott

Looks like based on these lines that the LCD driver is built into the kernel. I also see that the LCD interface is built into the S3C2410 ARM chip. Which means the relevant code is probably in the /arch/arm or /linux/drivers/video directory in the kernel source. They're required by GPL to provide you their source code but I'm sure you can find basically the same source on the internet.

I've never worked with video, but it looks to me like the lcd controller just copies the contents of a frame buffer to the display and it's up to you to manage the contents of the buffer. Maybe it gets initialized with that splash screen initially and maybe you can just write to that shared memory to change it.

I googled a bit and it seems like s3c2410 lcd controller is in the kernel configuration (at least for 2.6) and I found a paper about the driver:

formatting link

I expect though it is like any other driver, you open the file in /dev, you send ioctrls to it and read/write to it to use it. You'll probably have to poke around the source of the driver for more clues.

-Clark

Reply to
cpope

Well, you've given me a lot to chew on. Thanks for the help. Now I know the keyword to look for in file names and functions in include files: "fb".

Robert Scott Ypsilanti, Michigan

Reply to
Robert Scott

Which means that the maintenance of the board stopped somewhere during

2003... Should give you a clue!

You can get a late 2.6 kernel with a lot of graphics support for free at buildroot.uclibc.org. You can probably use that with any ARM9 board but there is a lot of support for AT91 based chips.

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
Reply to
Ulf Samuelsson

I have no interest in spending months of my time building a new kernel for a board I barely understand. I just want an off-the-shelf board into which I can load my application. And there is no reason to move to a newer kernel if the old kernel adequately supports all the hardware on the board. Sure, the board has been around for a while, but if it ain't broke, don't fix it.

Robert Scott Ypsilanti, Michigan

Reply to
Robert Scott

According to embest...

formatting link

So I would assume your answer is somewhere in your software package. Somewhere in the sources you will find out how they send the logo to the screen... clip it out... study... modify... deploy.

The suppliers of MOST arm sbc's tend to keep documentation very tight and example software is probably out there, but under lock and key until you fork over the dev money...

On my desktop, under /usr/src/linux/Documentation/arm/Samsung-S3C24XX/ is a file named EB2410ITX.txt. It contains the url's to two sites that support the lcd driver that you need to access.

It seems as though you just need to access the port via a write to /dev/xxx...

A few questions for you, please? Is your sbc sample branded samsung by chance or does it actually say embest? Also, what was the cost with lcd panel?

Just so we all know, also, the SBC2410III mentioned elsewhere is a SBC2410II with the addition of an ide interface.

Cheers, I hope I helped you. If I find something else... I'll be back.

--

Jerry McBride (jmcbride@mail-on.us)
Reply to
Jerry McBride

You would think so. Any maybe if I was more familiar with what I was looking for, I might find the relevant files among the thousands of files in the Embest package.

I have found this file on the Internet (not on my desktop) and the URLs do not seem to be relevant.

Sorry, I don't know what that means.

The spash screen says "Embest" in large letters.

We purchased from

formatting link
where the price is $319 USD for the SBC and $220 USD for the 3.5" TFT LCD (LTV350QV-R040).

Thanks for checking for me.

Robert Scott Ypsilanti, Michigan

Reply to
Robert Scott

Hmmm... what you could do... if you have locate/slocate, run the updatedb tool... then start tracking down sourcode with something simple like "locate .c" and buildup from there. You could also look in /usr/src as a possible location for source repositories...

Send me a copy of the cd/dvd tools/sources, whatever, I could look for you. :')

My pleasure, I really wish I could have helped you more.

Cheers.

--

Jerry McBride (jmcbride@mail-on.us)
Reply to
Jerry McBride

Thanks to all who offered advice on writing to a graphic LCD. I finally found the way to a solution in a 2000 article in Linux Magazine. Here is the test program, slightly modified to work on my board:

#include #include #include #include #include #include #include #include

main() {

// open framebuffer device and read out info int fd = open("/dev/fb0", O_RDWR);

struct fb_var_screeninfo screeninfo; ioctl(fd, FBIOGET_VSCREENINFO, &screeninfo);

// continue only if 16 bit color depth

if (screeninfo.bits_per_pixel == 16) {

// determine size int width = screeninfo.xres; int height = screeninfo.yres; // embed framebuffer into memory

unsigned short int *data = (unsigned short int*) mmap(0, width * height * sizeof(unsigned short int) , PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);

// process screen content line by line

for(int row=0; row

Reply to
Robert Scott

While you can write pixels on the screen that way, if you want to do something that is remotely similar to a GUI you should use an appropriate library, to save a huge bunch of work.

-Michael

Reply to
Michael Schnell

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.