pUPnGO - 6Mb ISO - Basic Building Block Puplet

A home for all kinds of Puppy related projects
Message
Author
amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#826 Post by amigo »

If used alone, mtune sets both the upper and lower limit of hardware support. To have things support a range of hardware, you should use -march as well, like this:
-march=i486 -mtune=i686
This means that i486 will be supported, but when used on a newer machines, then features up to i686 will also be supported. In theory, you could use an even newer arch for mtune, but this is probably not recommended -no one else does it that way.
for my system, I use -march=i586 -mtune=i686, but this is done for everything on the system -and the kernels are compiled with i586 as the arch.
It never makes any sense to compile software for use on an arch which is less than that supported by glibc. If you have a glibc compiled for i686, then the system(OS) will not work on a lesser system -even if you use a kernel which is compiled for i486, for example.

Also, the , --build=??, --host=?? and --target=?? directives are meant to help configure routines find a *toolchain* -they don'T directly enable any features at all. Using them keeps confiure from having to guess and possibly guess wrong about which toolchain to use. Also, the build directive tells configure which machine the software is being compiled on. The host directive tells configure which machine the software will be running on. Of course, when compiling natively, build will be equal to host. When compiling natively, none of these directives are needed (target only ever makes sense in the context of building a compiler or binutils.)

As I mentioned before, the biggest single jump in hardware support is that from i386 to i486. Later jumps provide less benefits for each jump.

To build a system, one should decide from the outset what should be the minimum system to supprt and then use the appropriate (and same) flags for compiling *everything*. Repeating, the flags used to compile glibc will set the lower limit for everything (except for anything which is statically compiled). None of these limit the upper range of what the system can run on. When you use march=i486 -mtune=i686, then the system will still run on i786- it just won't use any of the extra features available for i786.

Finally, 99% of all software is completely indifferent to these directives. The exceptions are things like video players, sound and video editing programs and high-performance libs like boost. Some of these will detect and use features automatically, but most require that options be specified. For instance, to use SSE, a lib or program will provide the --enable-sse option to configure. Some things, like mplayer, will try to detect which kernel is being used and whether such hardware features are available. In such cases, you'll want to definitely specify the hardware level to support. Otherwise, the software will be compiled to support the machine on which it is being built. For instance, if you don't turn off automatic CPU-detection when building mplayer, then it will pick up that you are building on an i786 machine and only support that arch -instead of your bottom limit of i486 or whatever.

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

#827 Post by technosaurus »

486 is the mimimum, there are a couple of non-FPU boards we don't support (vortex86SX ... any 486SX processors for that matter)
586 is not a significant jump as far as instructions only cmpxchg (it was mostly architectural improvement)
586mmx _is_ a significant jump and is almost required to get decent video playback
686 adds cmov which is 1)technically wrong 2)not widely supported 3)not very useful. See Linus's comments on the subject

Current CPUs should work with 586mmx (including the vortex86MX in Barry's gecko) all the way back to 2nd gen pentiums and amd k6 circa 1997 ... so if we want to support 20+ yr old computers and the vortex86DX, then we would need to do 486 for a few more years otherwise I am all for 586mmx
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:

#828 Post by goingnuts »

Thank you so much guys! I think I got it now :)

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

#829 Post by amigo »

One more detail I didn't fill in. When using --build=??, --host=?? --target=?? configure is expecting host-triplet style input. In other words they should be valid targets, like i486-slackware-linux or -i486-t2-linux. You can find the (build) triplet for your gcc with the command:
gcc -dumpversion

In src2pkg I have an option which lets you pass build&Co. when desired. But, since very few sources need or use this, it is not used by default. Slackware's SlackBuild build scripts always pass the option, but in a different way. Instead of
"--build=i486-slackware-linux, --host=i486-slackware-linux"
a single option is passed at the end of other options like tghis:
"i486-slackware-linux"
This is interpreted to mean --host=i486-slackware-linux, but it also triggers warnings about improper use of --host=??.

In any case, --build is the one you'd only need to specify when cross-compiling or using an alternate compiler. Otherwise the configure system will simply find your compiler anyway.

To make clear the meanings of build, host and target, it's helpful to consider (strangely) the most complex cross-build -called the canadian cross. For a canadian-cross build, host and target are all different. Consider this case:
I have an ix86 machine which I am using to build stuff with. But, I have an old PPC iMac which I wish to use build binaries for an ARM system. I need to build a compiuler which runs on PPC, but produces machine code for an ARM. And I need to build the compiler on my ix86 machine beacuse the PPC machine has no compiler. In this case, I would configure gcc using:
--build=i486-slackware-linux --host=ppc-slackware-linux --target=arm-slackware-linux

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

#830 Post by technosaurus »

amigo wrote:I have an ix86 machine which I am using to build stuff with. But, I have an old PPC iMac which I wish to use build binaries for an ARM system. I need to build a compiuler which runs on PPC, but produces machine code for an ARM. And I need to build the compiler on my ix86 machine beacuse the PPC machine has no compiler. In this case, I would configure gcc using:
--build=i486-slackware-linux --host=ppc-slackware-linux --target=arm-slackware-linux
So you are the one they invented canadian cross compilation for...
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].

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

#831 Post by amigo »

Well, no. But I personally invented the cannibal-cross. That's where you take an existing system and hijack it and then slowly consume it until the whole system is yours.

User avatar
Keef
Posts: 987
Joined: Thu 20 Dec 2007, 22:12
Location: Staffordshire

#832 Post by Keef »

Great idea for the next CE: "Pup Will Eat Itself".




Obscure music reference explained here

PANZERKOPF
Posts: 282
Joined: Wed 16 Dec 2009, 21:38
Location: Earth

#833 Post by PANZERKOPF »

amigo wrote:' i686 means a minimum of Pentium II
IMHO i686 means a minimum of Pentium Pro.
It was first in i686 family. Next was Pentium II, then Pentium III etc..
SUUM CUIQUE.

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

#834 Post by amigo »

"Pup Will Eat Itself" -except that Pup has never first been itself.

starhawk
Posts: 4906
Joined: Mon 22 Nov 2010, 06:04
Location: Everybody knows this is nowhere...

#835 Post by starhawk »

PANZERKOPF wrote:
amigo wrote:' i686 means a minimum of Pentium II
IMHO i686 means a minimum of Pentium Pro.
It was first in i686 family. Next was Pentium II, then Pentium III etc..
This is correct, according to Wikipedia as well. Most people are confused because they've never heard of a Pentium Pro -- it was a spectacular flop! Too expensive for what little improvement it had (on-the-chip cache in a time when that drove up the production costs to insane levels, and therefore drove sales prices up even higher) -- note that performance was not significantly improved really at all -- and it was a bad sell because Intel did it wrong (they marketed it as a server CPU back in the earliest days of such) and IIRC the matching socket (Socket 8, one of the very few rectangular CPU sockets [most are square] in CPU history -- note, not counting DIP sockets in that!) had some electrical issues as well, not unlike Socket 423 (for Willamette Pentium 4's) later on...

A note about Socket 423 and the matching Willamette-core P4's -- I've seen three Socket 423 CPUs (they're long since gone off to recycling, as they're neither functional to me, nor are they particularly pretty) and it looks like Intel's idea was to put the CPU on a carrier board. Probably the issue, therefore, was crosstalk -- above a certain speed of data communication, electromagnetism did its thing and each wire acted like an antenna, transmitting and receiving signals to/from neighboring wires. The Willamette P4's were (in)famous for two other things: producing tremendous amounts of heat, and having very poor performance. Intel actually revived the last-gen P3's (Tualatin, IIRC) and crippled them by sticking half the L2 cache in that they were supposed to get -- and THOSE were better! Intel did that basically to stay alive at the time. Socket 423 and the Willamette P4's were horrible indeed.

But I'm rambling so I'll shut up now :P

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

#836 Post by goingnuts »

My web server is a Compaq Deskpro 4000, 200mhz Pentium Pro - and it identify itself as i686.
I own a Compaq Proliant 2500 which can hold 2xPentium Pro processors - but I only have one in it. Never really used it - sounds like a minor jet when running - and quite critical on which OS it allow me to boot. Should have got rid of it many years ago - but it looks like new - and the size and weight is impressing...found an image

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

#837 Post by amigo »

He He, that looks like one of those weighted sleds that they use at the Tractor Pulls!

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

#838 Post by technosaurus »

Pentium Pro: 686 with CMOV, without mmx and max clock of 200Mhz
Pentium MMX: 586 without CMOV, with mmx and max clock of 233Mhz
AMD k6: 586 without CMOV, with mmx and max clock of 300Mhz
(all of those are out of production for 10+ years)

Vortex86MX: 586 without CMOV. with mmx and max clock of 1000Mhz
AMD geode GX2: 686* without CMOV, with mmx and max clock of 400Mhz
Via C3: 686* without CMOV, with mmx and max clock of 1400Mhz
Via C7: 686* without CMOV, with mmx and max clock of 2000Mhz
(these are still in production)

*CMOV is _supposed_ to be optional in 686 it theory, but in practice it is not. OTOH mmx is not required to be considered 686, but is more useful and more prevalent but requires additional -mmmx CFLAG to produce native mmx code. This is why I suggest 586MMX as a sane default.
wikipedia wrote:Code intended for i686 may fail due to the lack of a Conditional Move (CMOV) instruction. This is an instruction that combines the effect of a conditional branch and a move instruction. Compilers asked to optimize code for a more advanced CPU (for example the GNU Compiler with its -march=i686 option) generate code that uses CMOV. Linux systems intended for to run on i686 are generally not runnable on Vortex86 because the GNU C Library, when built for i686, uses a CMOV instruction in its assembly language strcmp function, which its dynamic loader (ld.so) uses. Hence, no program that uses shared libraries can even start up.

Technically, CMOV is optional in the i686 architecture. But Intel's i686 product, the Pentium Pro, had it, and consequently things that generate code typically consider CMOV to be available when you ask them to generate code for i686.
Its amazing how cool went from the giant frankenstein cases to an octocore arm that fits in an altoid tin. I finally recycled my cases about a year ago.
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].

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#839 Post by wanderer »

sorry to ask
but i have been reading the pupngo thread and it is hard going for me

is there a summary of the development of pupngo so i can have an overview of the process and what is the current state and last iso of pupnogo

anyone who has the patience to answer will be much appreciated

wanderer

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

#840 Post by goingnuts »

is there a summary of the development of pupngo so i can have an overview of the process and what is the current state and last iso of pupnogo
Best summary still the one on page 1. Latest pupngo iso is from summer 2011 although latest modifications can be found in the pupngo2012 thread.
There are no deadlines for - or targeted new release - although I have worked towards a 2013 version. That wont come. Now I work towards a 2014 version. Focus shifts - as I would like to bring some improvements rather than just a rebuild/re-master. The 2011 (and/or the 2012) are quite mature in my eyes. With little effort it can be remastered to run most official Puppys main sfs-file - and a range of other Distros as well - not to say that is a good purpose in it self - more as a statement of the level of maturity I think it has.

You can convert an official Puppys main sfs-file to squashfs3.0 or 3.1 and after boot of pupngo run the otf_sfs_loader.sh to add the squashfs-file to the aufs branch. Run xwin and there you go. You can fine tune by removing specific modules or applications already provided by pupngo to reduce size or customize the build.

Same procedure with other Distros - make a squashfs-fielsystem of all the files - and use otf_sfs_loader.sh to run them.

One of the unique strengths is still the static linking of all binaries in the core pupngo in combination with the full (I think...) toolset from the real Puppy (boot from whatever, save to whatever, various cli setting wizards etc).
Last edited by goingnuts on Mon 23 Dec 2013, 10:07, edited 2 times in total.

wanderer
Posts: 1098
Joined: Sat 20 Oct 2007, 23:17

#841 Post by wanderer »

thanks goingnuts
i appreciate you taking the time
fantastic project
a real advance

wanderer

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

#842 Post by goingnuts »

Thanks. Although I gave up a 2013 version a snapshot of current state of the core pupngo - with kernel from P216 - and holding 4 Original Puppy versions (P216, P300, P413 and Wary5.3) as sfs-extensions to run after boot can be downloaded here [download removed 20140117]. Note that iso size is approx. 350 Mb and that this is an old kernel. Used on a modern pc you might lack driver support for some of your hardware.
After boot use command "firstboot" - choose "Configure now" to set network/keybord/time - an ethernet connection is most likely to work (wireless can not be configured here). After that choose "Install programs from bootcd" to choose which version of Puppy to load. Exit and run xwin (note for wary run startx). If you don't do things that block the appended sfs for umount (like running xorgwizard) - you should be able to exit to prompt and run otf_sfs_loader.sh and unload the Puppy-sfs currently loaded. After that run "firstboot" again to load a different Puppy version. This is just a quick compilation and none of the different versions loads of applications has been tested. So expect bugs and nonfunctional applications. One could even think of loading several Puppy versions at the same time - just to see what happens...
Last edited by goingnuts on Fri 17 Jan 2014, 15:18, edited 1 time in total.

User avatar
Ted Dog
Posts: 3965
Joined: Wed 14 Sep 2005, 02:35
Location: Heart of Texas

#843 Post by Ted Dog »

ever think about this as a highly functional boot loader? with KEXEC patch you could launch other linux isos Instead of adding sfs support like you are. Also care to help me port this to ARM? :shock:

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

#844 Post by goingnuts »

Ted Dog: I would like to help but have no ARM knowledge, hardware or what else is needed.

A question was asked if P412 support ext4.
* Seems that it should be partly supported by loading module ext4dev (modprobe ext4dev) - but not handled in initrd so no boot from ext4.
* Need e2fsprogs-1.41.or later to create ext4 (need update of /etc/mke2fs.conf to work).
* To create

Code: Select all

mke2fs -T ext4dev /dev/sdc9
.
* need ext4 capable version of guess_fstype
* Need patch of /sbin/pup_event_frontend_d - add ext4 2 places in code to have deskdrive icon shown.
* Need util-linux-2.19 or later - to mount

Code: Select all

mount -t ext4dev /dev/sdc9 /mnt/sdc9
but even then mount fails. dmesg says
EXT4-fs: sdc9: Filesystem with huge files cannot be mounted read-write without CONFIG_LSF
Kernel must be compiled with "Support for Large Single Files"

So might be possible to get ext4dev working but need kernel recompile, initrd modifications and other upgrades.

Added: P431 should have a better chance - seems that ext4 support is build in kernel. But included mount-FULL version seems too old (util-linux 2.13-pre7) - but has mkfs.ext4 and guess_fstype is also allright - although I have not tested P431 in respect to create & mount an ext4 partition.

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

#845 Post by technosaurus »

@TD - I would recommend starting with one of the aboriginal linux toolchains and building from source. ... We really need to get the core tools onto github.

@goingnuts - would you be able to push your toolchain to github or possibly a fossil repo on goingnuts.dk?

I would really like to set up the build as a combo of busybox/toybox multicall build with ffmpeg's license white/blacklist options added on... so that if needed we could build a permissive license only build. X+hazewm+st+tcl/tk instead of X+jwm+rxvt+gtkdialog ... but this is in part because I would like to support BSD in addition to Linux (still doing research) ... this means using $CC instead of hardcoding gcc as well as weaning ourselves from using GNUisms, but I have most of that under control already
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].

Post Reply