Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: wysiwyg on January 26, 2015, 06:48:55 AM
-
Good morning everyone! This post is to work on a specific issue mentioned from another post:
http://forum.tinycorelinux.net/index.php/topic,17906.0.html
I was having problems booting the x86_64 using FBDev instead of X. I would like to get this working as there are several projects that can utilize the more efficient framebuffer instead of full X.
Basically I was left with a missing /dev/fb0 file. Any thoughts?
Thanks,
Dave
-
Found here - http://lists.mplayerhq.hu/pipermail/mplayer-users/2003-September/037832.html
mknod /dev/fb0 c 29 0
as root often helps.
-
You could try booting to a console (boot code "text"), checking that Xfbdev is loaded and then using the first line of ~/.xsession to start X, rather than "startx" - this might come up with an error message that would give a clue to the problem.
-
@core-user thanks for the info. I actually looked in the /dev directory and see the correct fb0 file being created...
@Juanito I adjusted the boot parameters per your suggestion and this is what I get:
$ ./.xsession
./.xsession: line 1: /usr/local/bin/Xorg: not found
Giving up.
failed in waitforX
I have confirmed that no such file or directory exists. Why would it be looking for Xorg if it should be using XFBDev?
Dave
-
normally when you load the Xvesa, Xfbdev or Xorg-* extensions the first line of ~/.xsession is modified to suit.
Perhaps you need to try startx once and then check ~/.xsession
..but what I meant was to manually type and execute the first line of ~/.xsession, not to execute ~/.xsession itself.
-
@Juanito sorry for the misunderstanding, here's what I got...
$ head -1 .xsession
/usr/local/bin/Xfbdev -mouse /dev/input/mice,5 -nolisten tcp -I >/dev/null 2>&1
$/usr/local/bin/Xfbdev -mouse /dev/input/mice,5 -nolisten tcp -I >/dev/null
Error opening framebuffer /dev/fb0: No such device
Fatal server error:
no screens found
$ ls /dev/fb0
/dev/fb0
It looks like the device file is there, but is unable to be used for some reason. Permissions are 622 and ownership is root:staff.
Dave
-
Is there a reason why Xfbdev wouldn't be able to use the /dev/fb0 file? I don't think there's a permissions issue... Any logs that I can see that might provide a clue as to where the problem is occurring? Could it be a driver issue? I'm loading the firmware-radeon extension first in the onboot.lst file.
Dave
-
Please post your dmesg (pastebin.com, etc). Are you loading graphics- onboot?
-
Please post your dmesg (pastebin.com, etc). Are you loading graphics- onboot?
http://pastebin.com/jcVPCe5s
No sure what you mean regarding the loading of graphics onboot? Here's my current onboot.lst for that boot option:
firmware-radeon.tcz
Xfbdev.tcz
Xlibs.tcz
Xorg-fonts.tcz
Xprogs.tcz
aterm.tcz
fltk-1.3.tcz
flwm.tcz
freetype.tcz
glib2.tcz
harfbuzz.tcz
imlib2-bin.tcz
imlib2.tcz
libICE.tcz
libSM.tcz
libX11.tcz
libXau.tcz
libXdmcp.tcz
libXext.tcz
libXfont.tcz
libXi.tcz
libXmu.tcz
libXpm.tcz
libXrandr.tcz
libXrender.tcz
libXt.tcz
libffi.tcz
libfontenc.tcz
libjpeg-turbo.tcz
libpng.tcz
libxcb.tcz
pcre.tcz
wbar.tcz
Each of those files are also located in the 'optional' directory.
Thanks,
Dave
-
AGP: Checking aperture...
AGP: No AGP bridge found
AGP: Node 0: aperture [bus addr 0x00000000-0x01ffffff] (32MB)
AGP: Your BIOS doesn't leave a aperture memory hole
AGP: Please enable the IOMMU option in the BIOS setup
AGP: This costs you 64MB of RAM
AGP: Mapping aperture over RAM [mem 0x84000000-0x87ffffff] (65536KB)
-
I enabled IOMMU support in the BIOS, rebooted, but no changes. Doing a quick look on IOMMU, it appears that it is related to virtual hardware for VM's. I'm not running anything like that, just one simple OS. :)
Dave
-
Xfbdev requires a framebuffer - either the VESA framebuffer by using the vga=xxx bootcode, or a native one using the radeon module. Your dmesg shows you have neither currently.
So either add the vga bootcode with a suitable resolution, or add the graphics- extension onboot.
-
Thanks curaga, I added the graphics-3.16.6-tinycore64 extension and its i2c dependency and it worked just fine! Is there an advantage to using one way over the other (graphics-? extension or the vga=? boot code)? It appears that using the graphics-? extension provides more resolutions.
Thanks,
Dave
-
The native module can use any resolution, and the framebuffer may be faster. VESA is limited to the standard resolutions and implemented in software only.
edit: Though, the native module only supports a range of hw from a single vendor, while the VESA fb works with most cards.
-
Gotcha, thanks again curaga!
Dave
-
So that's what the VGA boot code does 8)
-
What, you haven't read the book? *shocked*