Puppy In-House Development

Under development: PCMCIA, wireless, etc.
Message
Author
User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#61 Post by 01micko »

Now all i need is my kernel

Code: Select all

bash-4.2$ find . -name '*'
.
./usr
./usr/share
./usr/share/doc
./usr/share/doc/.gitignore
./usr/share/man
./usr/share/man/.gitignore
./usr/lib
./usr/bin
./root
./root/.gitignore
./etc
./etc/motd
./etc/passwd
./etc/profile
./etc/hosts
./etc/kmodule.blacklist
./etc/group
./etc/screenrc
./etc/shadow
./etc/issue
./etc/hostname
./etc/rc.d
./etc/rc.d/rc.shutdown
./etc/rc.d/rc.sysinit
./sys
./sys/.gitignore
./var
./var/log
./var/log/.gitignore
./var/run
./var/db
./var/db/.gitignore
./tmp
./tmp/.gitignore
./run
./run/.gitignore
./lib
./lib/libXfont.a
./lib/libXext.a                                                                 
./lib/libXinerama.a                                                             
./lib/libpthread.a                                                              
./lib/crtn.o
./lib/libutil.a
./lib/libxnet.a
./lib/libXss.a
./lib/libXcursor.a
./lib/pkgconfig
./lib/pkgconfig/zlib.pc
./lib/libXau.a
./lib/libXi.a
./lib/libm.a
./lib/crti.o
./lib/libz.a
./lib/musl-gcc.specs
./lib/libICE.a
./lib/libXmu.a
./lib/libcrypt.a
./lib/libX11.a
./lib/libXmuu.a
./lib/libXfixes.a
./lib/Scrt1.o
./lib/.gitignore
./lib/libXdmcp.a
./lib/crt1.o
./lib/libdl.a
./lib/librt.a
./lib/libXpm.a
./lib/libXt.a
./lib/libXtst.a
./lib/libXv.a
./lib/libresolv.a
./lib/libSM.a
./lib/libXaw.a
./lib/libc.a
./lib/libXrender.a
./dev
./dev/.gitignore
./bin
./bin/reboot
./bin/syslogd
./bin/init
./bin/depmod
./bin/mkdir
./bin/kill
./bin/dmesg
./bin/pivot_root
./bin/poweroff
./bin/client
./bin/mkfifo
./bin/ls
./bin/mount
./bin/vi
./bin/touch
./bin/sulogin
./bin/loksh
./bin/pwd
./bin/attach
./bin/rmdir
./bin/devd
./bin/relayd
./bin/sh
./bin/which
./bin/man
./bin/mknod
./bin/modinfo
./bin/ln
./bin/suspend
./bin/pidof
./bin/killall
./bin/cttyhack
./bin/modprobe
./bin/umount
./bin/logd
./bin/guess_fstype
./bin/lsmod
./bin/rmmod
./bin/ps
./bin/detachd
./bin/mktemp
./bin/cat
./bin/insmod
./bin/logger
./bin/sleep
./bin/hostname
./bin/chroot
./bin/Xfbdev
./bin/musl-gcc
./bin/grep
./bin/uname
./bin/sync
./proc
./proc/.gitignore
That's the populated initramfs (all built against musl except loksh, was i supposed to do that? no CC= in the readme)

Edit 1: build is actually smaller with real cc anyway, about ~30k

Edit 2: What options to Xfbdev (made link to X) ???

Edit 3: "Failed to execute /init" ... that's where it stops for me :roll: .. maybe my loksh is stuffed up somehow. Anyway, I'll leave it for those who know what they're doing with this low level stuff :P
Puppy Linux Blog - contact me for access

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#62 Post by Ibidem »

I'm wondering about some things:
1: is the mode of /tmp drwxrwxrwxt ?
(check with "ls -l -d")
2: If you try someone else's (32-bit) build of Xfbdev, or a 32bit local build, does it work with the binaries?
3: is /tmp/.X11-unix/* showing up?
You should get X1 if you use display 1, I think. Also try stopping the display manager, log into the terminal, and just run Xfbdev.

I'm wondering whether there were some places where it relied on ILP32 instead of LP64.
(ILP32: int, long, and pointer are all 32 bits long; LP64: int is 32 bits, long and pointer are 64 bits)

01micko, you'll need a static musl build of loksh; check with "file" whether it's dynamically linked. A static build will be larger than a regular dynamic build, but it doesn't need any libraries.
Speaking of which, *.a, *.h, and *.o are needed only for compiling things.

Xfbdev needs no options, if you use tinyxserver.

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#63 Post by 01micko »

Ok, fixed (tmp was 755, made it 1777, loksh built with musl) all that, now init works but I get first a fatal server error, Cannot open /dev/tty0, no such file or directory, then a kernel panic... I have a good kernel config according to the readme.

Yeah, realised about the .a,.o,.h and removed beforehand.

Like I said; out a my league! Bit of fun tho'.
Puppy Linux Blog - contact me for access

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#64 Post by Iguleder »

01micko wrote:That's the populated initramfs (all built against musl except loksh, was i supposed to do that? no CC= in the readme)
Yes, but you're not supposed to build things manually - use build.sh (for example: ./build.sh loksh and ./build.sh linux).
01micko wrote:Edit 3: "Failed to execute /init" ... that's where it stops for me :roll: .. maybe my loksh is stuffed up somehow. Anyway, I'll leave it for those who know what they're doing with this low level stuff :P
I guess it's dynamically-linked, because you built it manually.
Ibidem wrote:I'm wondering about some things:
1: is the mode of /tmp drwxrwxrwxt ?
(check with "ls -l -d")
Yes, but it's irrelevant - I run it as root. XOpenDisplay() succeeds.
Ibidem wrote:2: If you try someone else's (32-bit) build of Xfbdev, or a 32bit local build, does it work with the binaries?
I used Debian's X server and 64-bit applications linked against tinyxlib work. I think it's good enough to prove the client-side is OK.
Ibidem wrote:3: is /tmp/.X11-unix/* showing up?
You should get X1 if you use display 1, I think. Also try stopping the display manager, log into the terminal, and just run Xfbdev.
Yes.
Ibidem wrote:I'm wondering whether there were some places where it relied on ILP32 instead of LP64.
(ILP32: int, long, and pointer are all 32 bits long; LP64: int is 32 bits, long and pointer are 64 bits)
I guess that's the problem, I just have no idea where it is - there's so much code.

EDIT: the Tiny Core guys gave me this link. They say they use this X server and it works for them, under x86_64.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#65 Post by 01micko »

Didn't (and still don't) see a build.sh for loksh. Not to worry, managed to build it ok. Probably something wrong with my kernel, init script or something left for me to figure out :wink:
Puppy Linux Blog - contact me for access

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#66 Post by Iguleder »

I think it's your kernel - by default, the kernel runs /sbin/init. If you build the kernel using this building kit (as you should), it will be patched to run /bin/init (see the patches directory).

I don't understand why you build things manually instead of using build.sh.
Last edited by Iguleder on Sat 09 Nov 2013, 11:20, edited 1 time in total.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

nooby
Posts: 10369
Joined: Sun 29 Jun 2008, 19:05
Location: SwedenEurope

#67 Post by nooby »

Iguleder wrote:I
I don't understand why you don't build things manually instead of using build.sh.
Could there be a grammar error there I test to change it to this

"I don't understand why you build things manually instead of using build.sh"

that seems more logical based on that you recommend to use build.sh earlier?

Just a friendly thought
I use Google Search on Puppy Forum
not an ideal solution though

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#68 Post by Iguleder »

Corrected :oops:

I looked at the Tiny Core sources - all the "#ifdef amd64" statements exist in tinyxserver, too.

EDIT: I'm getting sick of this. I haven't checked whether tinyxserver's Xfbdev works under 32 bit, so I'm building 32 bit binary to see whether the problem is specific to 64 bit builds. If it isn't, the solution is a little bit closer.

EDIT 2: a 32-bit build of the same Xfbdev against tinyxlib works well, so it must be a 64-bit portability issue.

EDIT 3: since Xfbdev screws up GDB for some reason, I'm trying to use this trick to see which functions are called - the problem must be in one of those called after JWM is started.

It's getting late and I won't have time to work on this until my next free weekend, so I hope this approach won't take long. :cry:

EDIT 4: add this to main.c:

Code: Select all

#include <stdio.h>

void __cyg_profile_func_enter (void *func,  void *caller) __attribute((no_instrument_function));
void __cyg_profile_func_exit (void *func,  void *caller) __attribute((no_instrument_function));

FILE *trace_log = NULL;
void
__cyg_profile_func_enter (void *func,  void *caller)
{
 if(trace_log == NULL) {
	trace_log = fopen("/tmp/Xfbdev.log", "w");
 }
 if (trace_log != NULL)
	fprintf(trace_log, "e %p %p %lu\n", func, caller, time(NULL) );
}

void
__cyg_profile_func_exit (void *func, void *caller)
{
 if(trace_log == NULL)
	trace_log = fopen("/tmp/Xfbdev.log", "w");

 if (trace_log != NULL)
	fprintf(trace_log, "x %p %p %lu\n", func, caller, time(NULL));
}
Then, build Xfbdev with "-finstrument-functions" in CFLAGS and run it. I ran JWM to see which functions are called - I got a 12 MB log file.

Once it terminates, run this script (pass /tmp/Xfbdev.log and the binary path):

Code: Select all

#!/bin/sh
if test ! -f "$1"
then
 echo "Error: executable $1 does not exist."
 exit 1
fi
if test ! -f "$2"
then
 echo "Error: trace log $2 does not exist."
 exit 1
fi
EXECUTABLE="$1"
TRACELOG="$2"
while read LINETYPE FADDR CADDR CTIME; do
 FNAME="$(addr2line -f -e ${EXECUTABLE} ${FADDR}|head -1)"
 CDATE="$(date -Iseconds -d @${CTIME})"
 if test "${LINETYPE}" = "e"
 then
 CNAME="$(addr2line -f -e ${EXECUTABLE} ${CADDR}|head -1)"
 CLINE="$(addr2line -s -e ${EXECUTABLE} ${CADDR})"
 echo "Enter ${FNAME} at ${CDATE}, called from ${CNAME} (${CLINE})"
 fi
 if test "${LINETYPE}" = "x"
 then
 echo "Exit  ${FNAME} at ${CDATE}"
 fi
done < "${TRACELOG}"
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#69 Post by goingnuts »

Try disable all tinyxserver extensions in standard_definitions.mk. XFree86-4.8.0 might be worth trying. Btw. why is 64bit Xfbdev so important if 32bit works? Would it prevent 64b xapps from running?
xfbdev 32bit runs in fatdog610 (although only fills 1/4 of screen and rxvt/rox/seamonkey runs ok.
Last edited by goingnuts on Sun 10 Nov 2013, 18:45, edited 1 time in total.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#70 Post by technosaurus »

IIRC this older version uses a vm86 syscall http://man7.org/linux/man-pages/man2/vm86.2.html which is specific to 32-bit x86, so it may require a patch from later version.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#71 Post by Ibidem »

@technosaurus: that's only Xvesa (which uses the video bios).
Xfbdev is generic.

@goingnuts: I get the impression it's something about wanting a pure64 system.
X server and X apps can be mixed & matched, thanks to the network transparency part.
So you can run IRIX mips64 applications and display them on x86 linux, or vise versa, or any other combo as long as you can get a network connection.

@01micko:
Do you have /dev?
Does your init include
mount -t devtmpfs devtmpfs /dev ?
Or does your kernel automount devtmpfs (CONFIG_DEVTMPFS_MOUNT=y; initrd support can complicate this)?

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#72 Post by Iguleder »

Finally, it works!

I checked which headers under include contain "#ifdef _XSERVER64" in both tinyxserver and Tiny Core's X.Org server - I found two padded structs and added the padding members to the older code of tinyxserver.

I'm generating a patch against the vanilla tinyxserver - once I commit this change, I want to integrate the whole thing with Lazyux, to form an ISO which boots straight into a JWM desktop.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
01micko
Posts: 8741
Joined: Sat 11 Oct 2008, 13:39
Location: qld
Contact:

#73 Post by 01micko »

Iguleder wrote:Finally, it works!
Awesome news!
Iguleder wrote:I checked which headers under include contain "#ifdef _XSERVER64" in both tinyxserver and Tiny Core's X.Org server - I found two padded structs and added the padding members to the older code of tinyxserver.

I'm generating a patch against the vanilla tinyxserver - once I commit this change, I want to integrate the whole thing with Lazyux, to form an ISO which boots straight into a JWM desktop.
ETA? No rush :)
Puppy Linux Blog - contact me for access

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#74 Post by Iguleder »

I got it to work using an ugly hack, so it will take some time to adjust the code. I want it to work on both x86_64 and x86.

EDIT: here - had to put "-D_XSERVER64=1" in CFLAGS. Now it works fine against JWM and even rxvt-unicode runs well.

EDIT 2: I'll be nice - here's the ugly script I used to run the whole thing, inside a chroot environment:

Code: Select all

#!/bin/sh
for i in linux_headers musl lazy_utils loksh tinyxlib xinit zlib tinyxserver font_cursor_misc font_misc_misc font_alias ttf_bitstream_vera jwm; do sh build.sh $i; done
. ./config
a=`pwd`
cd $SYSROOT/usr/share/fonts/misc
mkfontscale
mkfontdir
cd $a
mkdir $SYSROOT/dev $SYSROOT/tmp $SYSROOT/proc $SYSROOT/sys
mount --bind /dev $SYSROOT/dev
mount --bind /proc $SYSROOT/proc
mount --bind /sys $SYSROOT/sys
chroot $SYSROOT
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#75 Post by amigo »

BTW, you don't need to patch the kernel to use /bin/init instead of /sbin/init, just pass the parameter on the kernel boot line:
init=/bin/init

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#76 Post by Iguleder »

I'm aware of that, but I want it to be clean. I want the whole thing to work without additional parameters, so EFISTUB can be used in the future.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#77 Post by technosaurus »

When I did microsaurus, one of the things that really helped to simplify things was making every executable path a symlink to /bin and every library path a symlink to /lib (and similar things with other common areas: modules, images, xdgdirs...) The kernel with builtin initramfs (static Xvesa, jwm, rxvt and busybox) was less than 1Mb. This worked better than I could have expected for speeding up start times when the prime purpose was size reduction. It turns out that a lot of the time goes to looking in directories for executables and libraries, and even kernel module loads were nearly instant with everything in /lib/modules/<version> rather than in subdirs (though certain programs need to be patched to remove those hardcoded paths - ndiswrapper.c is one example)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#78 Post by Iguleder »

Currently, the file system is very simple - only /bin and /lib, only static libraries.

Since things fail to build against tinyxlib, I'm currently improving it so it gets installed as libX11.a, while other libraries are links to it. This solves unresolved symbol problems which arise when applications assume they need to link only against a single library, without its dependencies.

EDIT: it's awesome! JWM recognizes all available extensions and X libraries now.

EDIT 2: other applications are still messed up because of static linking. Now I understand why pupngo has shared libraries :lol:
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#79 Post by technosaurus »

How are they "messed up by static linking"? I've never had that problem. Is it possible that hardcoded compiled builtin paths need to be fixed? If you build with a standard Puppy, then it will try to put stuff in /usr/... due to $PREFIX env var and many others... for autotools, you need to specify --prefix=, --bindir=, --sysconfdir=, --localstatedir=, etc... and rox requires some xdg dirs to be set.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

goingnuts
Posts: 932
Joined: Sun 07 Dec 2008, 13:33
Contact:

#80 Post by goingnuts »

Iguleder wrote:..Now I understand why pupngo has shared libraries :lol:
:?: you mean no libraries :?: If not you are studying quite old version...
Next step might be to do multi-call binaries of jwm, xfbdev, init, rxvt...

Post Reply