[SOLVED] which component i have to add in root filesystem to enable GUI?

Hi,

Do i have to add any special component in the root filesystem to enable GUI to browse through filesystem, open terminal editor like that in the embedded display board just like desktop? I think i have drivers for embedded touch display with me.

Please help!

I think a lot depends on the distribution. For myself running Angstrom on like a Beagleboard I needed to install xserver-xorg. It also depends what display manager, if any; you intend to run. I run with no display manger and just run UI programs off of the XServer, therefore I install xserver-nodm-init. Ultimately one of those gets me startx where I can then set up /etc/X11/xorg.conf and /usr/lib/X11/xinit/xinitrc.

Might be helpful to state the board, kernel and/or distribution you're running, as well as what you want to display; i.e. full desktop or just get an XServer session running, and then next what screen size/orientation.

Hi rtmistler,

I dont just need the info for my board alone. I need info extensively as much as possible for GUI configuration in Linux os for embedded boards. Where can i get that source?

Please help!

Not really sure, try sourceforge or a web search for the XServer code. This is a fairly huge topic and I manage to get things working on a "per system/per processor type" basis versus looking more broadly at the topic as you're trying to do.

Hi rtmistler,

Do the X Window system currently supported only by X org code?
And do the xserver, xdm and xinit all supported by X org?
Is there any other simpler framework that can be used for display management
that can be used by Linux desktop or embedded environment?

Please let me know!

There's always a simpler framework, including not using any display manager at all.

The most common lightweight display managers I'm familiar with are: Xfce, TWM, and XFCE; but there are others and with most cases it depends what you're doing for displays; I've heard some praise for NanoX (sp), but haven't tried it. They each have different requirements and in my understanding, Xorg is for the XServer, not the display manager.

I've said before, it depends on what you're doing, what board you're working with, and so forth. The best I can recommend is if you're developing stuff to show on a screen, that to develop it on a regular Linux desktop which supports a full display manager, get the "content" to waht you want, and then move that towards whatever embedded boards you have and try different display managers to achieve the results you wish.

Not being specific about board or what you've tried, it's then just general questions which you're asking and there aren't general answers IMHO. You may design something with graphics which requires certain levels of display support which certain mininmal display managers do not provide. A choice there is to reduce your graphical requirements, or try a different display manager. If you're using a board provided by a manufacturer, they may have reference code available, or provide distribution support sufficient to answer more specific questions.

I can say that having played with various boards, hobby type ones that are near free such as the Beagle Board and Raspberry Pi, the pathways to getting minimal, no display manager configurations are different, because the native distributions are different. Many will tell you to use either Debian or Ubuntu on those boards; I don't disagree, but I do say that I've had the best success with the supported distributions which those boards provide.

Hi,

As an attempt to use xfce I downloaded the libxfce4util-4.10.1 library source and went through the makefile, INSTALL, Readme file of it.
I could not find how to cross compile it. I have s3c2440 processor using arm920T core. Can you help me how to cross compile it? Also a general instructions how to cross compile the libraries/utilities found in Beyond Linux From Scratch will be helpful as i see the packages you mentioned xfce, TWM etc,.. are found in BLFS.

Please help!

A good first attempt would be to try and build directly on the target. Or to try and install via a package manager.

To cross compile, I'd install the GCC ARM cross compiler, the package name is gcc-arm-linux-gnueabi and then the make line would be something like this:

make ARCH=arm CROSS_COMPILE=gcc-arm-linux-gnueabi-

You may have to create a config spec for that processor but I'd start with a default and see where that gets you.

Bear in mind that's a 10 year old chip. Go to Samsung's site and see what they recommend and what tools they support.

Hi,

By using

make ARCH=arm CROSS_COMPILE=gcc-arm-linux-gnueabi-

for the cross compiling packages, dont there is the need that the make file in the packages written to process the command line args like ARCH, CROSS_COMPILE and its values?

And it might not be possible to build directly on the target as the embedded boards will be low of memory for making it capable for development enviroment within the target to build.
Then what will be the general practice for this kind of building?

And you said to install via a package manager. Are you saying that the package manager should reside in target?

Please reply!

Originally Posted by ayyasprings By using make ARCH=arm CROSS_COMPILE=gcc-arm-linux-gnueabi- for the cross compiling packages, dont there is the need that the make file in the packages written to process the command line args like ARCH, CROSS_COMPILE and its values?

No those options are recognized by the cross compilation toolkit.

Originally Posted by ayyasprings And it might not be possible to build directly on the target as the embedded boards will be low of memory for making it capable for development enviroment within the target to build. Then what will be the general practice for this kind of building?

If possible configure a target with more memory and disk space to support the build then only copy the binaries and libraries to a real target.

Originally Posted by ayyasprings And you said to install via a package manager. Are you saying that the package manager should reside in target?

Yes.

Hi,

your first answer for cross compiling solution might be wrong.

When i looked into the main makefile of a kernel it looked like this:

231# Cross compiling and selecting different set of gcc/bin-utils 
232# --------------------------------------------------------------------------- 
233# 
234# When performing cross compilation for other architectures ARCH shall be set 
235# to the target architecture. (See arch/* for the possibilities). 
236# ARCH can be set during invocation of make: 
237# make ARCH=ia64 
238# Another way is to have ARCH set in the environment. 
239# The default ARCH is the host where make is executed. 
240
241# CROSS_COMPILE specify the prefix used for all executables used 
242# during compilation. Only gcc and related bin-utils executables 
243# are prefixed with $(CROSS_COMPILE). 
244# CROSS_COMPILE can be set on the command line 
245# make CROSS_COMPILE=ia64-linux- 
246# Alternatively CROSS_COMPILE can be set in the environment. 
247# A third alternative is to store a setting in .config so that plain 
248# "make" in the configured kernel build directory always uses that. 
249# Default value for CROSS_COMPILE is not to prefix executables 
250# Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile 

251 ARCH		?= $(SUBARCH) 
252 CROSS_COMPILE	?= $(CONFIG_CROSS_COMPILE:"%"=%) 
253
254# Architecture as present in compile.h 
255  UTS_MACHINE 	:= $(ARCH) 
256  SRCARCH 	:= $(ARCH) 
257
258# Additional ARCH settings for x86 
259  ifeq ($(ARCH),i386) 
260        SRCARCH := x86 
261  endif 
262  ifeq ($(ARCH),x86_64) 
263        SRCARCH := x86 
264  endif 
265
266# Additional ARCH settings for sparc 
267  ifeq ($(ARCH),sparc32) 
268       SRCARCH := sparc 
269  endif 
270  ifeq ($(ARCH),sparc64) 
271      SRCARCH := sparc 
272  endif 
273
274# Additional ARCH settings for sh 
275  ifeq ($(ARCH),sh64) 
276       SRCARCH := sh 
277  endif 
278
279# Additional ARCH settings for tile 
280  ifeq ($(ARCH),tilepro) 
281       SRCARCH := tile 
282  endif 
283  ifeq ($(ARCH),tilegx) 
284       SRCARCH := tile 
285  endif 
286
287# Where to locate arch specific headers 
288  hdr-arch  := $(SRCARCH)

If you look that above the make file process command line arguments and its options while compiling.

Please clarify this!

Those exact comments are pretty much in every kernel Makefile.

The original suggestion was to review the available documentation for that specific chip from either the manufacturer or a source which supplies a devkit. That is also NOT a 64-bit processor, it is 10 years old and, depending on the specific model either 16 or more likely 32-bit architecture.

If you have one of the common dev boards like the friendly arm, then here's a link to their information about kernel compilation: https://code.google.com/p/friendlyarm/wiki/Linux. As part of their recommendations for the kernel they state:

    export PATH=/home/user/mini2440-bootstrap/arm-2008q3/bin:$PATH 

    CROSS_COMPILE=arm-none-linux-gnueabi-
    CC=”${CROSS_COMPILE}gcc –march=armv4t –mtune=arm920t”
    export CROSS_COMPILE
    export CC

You'll have to experiment since you're not building the kernel; however the tools to install and the configuration options as well as arguments for them are likely similar to how you'd do the kernel compile.

I haven't done projects with that specific processor, therefore all I really can provide is suggestions towards a solution, you'll have to research some on your own, or perhaps another person may notice the thread an offer more direct recommendations.

Hi,

I got better idea when seeing this following segment you pasted:

CROSS_COMPILE=arm-none-linux-gnueabi-
    CC=”${CROSS_COMPILE}gcc –march=armv4t –mtune=arm920t”
    export CROSS_COMPILE
    export CC

By executing this as script or separate commands in terminal,I can substitute CC in make file given in packages to invoke cross compilation toolchain.
Now I have to experiment with packages which goes without problems for my board. If my understanding is not right, please correct. I am marking this thread as solved.

Thanks for the help!