Puppy on ARM Netbooks

Using applications, configuring, problems
Message
Author
User avatar
swiatmar
Posts: 248
Joined: Sat 09 Aug 2008, 19:33
Location: Danube, AT

Puppy on ARM Netbooks

#1 Post by swiatmar »

Hello!!

I have a simple short question :)

Is puppy running also on netbooks with arm processor?

raffy
Posts: 4798
Joined: Wed 25 May 2005, 12:20
Location: Manila

No

#2 Post by raffy »

Not yet. Nobody has started building Puppy for the ARM CPU variants.
Puppy user since Oct 2004. Want FreeOffice? [url=http://puppylinux.info/topic/freeoffice-2012-sfs]Get the sfs (English only)[/url].

aarf

#3 Post by aarf »

however there is no specific prohibition in the puppy constitution so feel free to start the port to ARM as soon as you like

aarf

#4 Post by aarf »

Alright so i know absolutely zero about this but a bright idea just occurred to me so I too have a question. If you woof build an Arm ported distro eg i think ubuntu has an arm version, do you then have an armed and dangerous puppy?

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#5 Post by Lobster »

Yes Puppy using Woof can be ARM'd

This can be done with Dpup, Spup or Upup
(maybe the others too)

If running one of these next kennel breed of Puppy
(which are still being developed)
you can use the Debian, Slackware or Ubuntu software depositories to build a Puppy Puplet
(or Wooflet in this case) from their ARM compatible files
http://puppylinux.org/wikka/Woof

As our intrepid Puppys develop a whiff of Woof power
expect Puppy on the cell processor - yep some nice ps2's and in time ps3's will be available.
Mainframe Puppy will be in our reach (that just makes me laugh)
The Puppy Phone cometh . . .
:roll:
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

aarf

#6 Post by aarf »

thanks for that Lobster.
so what is the log-jam? i would have though that this prospect would inspire the prime developer resource to drop everything else and move quickly put an armed puppy on a phone. barking phones what next! :P am i missing something?

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#7 Post by Lobster »

so what is the log-jam?
Not that many devices - no single market product
such as the Eeepc - which spawned many puplets

What would you use as the reference device?

If IBM or Sony had a new hardware product
for their cell processor or a manufacturer in China decided to
launch a MIPS based Puppy device, it might do really well

We have Puppy in Intel based products such as this
Image

Puppy is ready to be ARM'd.
Woof Woof
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

jamesjeffries2
Posts: 196
Joined: Mon 28 Apr 2008, 00:50

#8 Post by jamesjeffries2 »

A while back I played around with porting puppy to MIPS and ARM, but we ended up using debian instead because there more support and more readily available packages.

I'm pretty sure it could be done pretty easily with puppy, but it was just easier at the time to go with debian.

The only problem we ever had with linux on MIPS was that it didnt handle large amounts of threads very well - not really what it was deisigned for though.

jamesjeffries2
Posts: 196
Joined: Mon 28 Apr 2008, 00:50

#9 Post by jamesjeffries2 »

PS i have puppy running well on this little x86 box
Attachments
st166_overview.jpg
(25.85 KiB) Downloaded 6264 times

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

#10 Post by amigo »

Yeah, the first trouble is that 'arm' is not 'arm'. There are many flavors of arm architecture and only a few are compatible with each other. I saw, somewhere, that someone had calcualted the number of builds necessary to provide 'blanket' coverage of arm arch and it was in the thousands!
Still, the other problem, which is the same for building Puppy for *any* other architecture is that there is no orderly system for building puppy. Even at its' best -straight from Barry, the sources are spread all over, it includes binaries which were not compiled on any Puppy system, or on some other Puppy system than the one being built; it depends on the use of multiple kernel patches -some of which are pretty diificult to keep synced with current kernel sources.

I have been making a big effort to create a set of build scripts which use my src2pkg tool to create a full distro from scratch. The scripts are arch-agnostic, which means that once all the scripts are done, they can be used to build a system for another arch without having to edit a bunch of scripts. My system even derives the build-order for you. And my 'cheat' method of bootstrapping a new toolchain allows you to start off with nearly any sort of Linux system you are used to running.

Even if you use the woof build system to create a base system for arm, ppc or whatever, you are still going to have the work of compiling all the extras that Puppy uses which is probably at least 200 programs. And many of these will be resistant to building on certain arches. In the end, the only way to be able to maintain any Puppy distro, or create new distros for other arches, is going to require the creation of a real build system -not a 'rob-it-from-wherever-you-find-it' system. If Puppy really is much different from other distros, then its' particular needs at built-time will always be distinct enough to warrant and require that the libs and programs be built *for*, *by* and *on* a Puppy build system.

I am building such a system, but it will not be called puppy. It is called kiss-linux. Puppy needs its' own toolchain -not one grabbed from somewhere else. Just run the command 'gcc -dumpmachine' and see what it says -it says 'i486-t2-linux' or something like that. Until you get a system which returns 'i486-puppy-linux', there is not a chance of creating a real distro at all -even for a single architecture. If the devs have, in the past, gone to the trouble of building a 't2' toolchain, why didn't they go ahead and brand the thing so it would really be 'puppy-linux'. The difference will appear trivial to anyone who knows nothing about these things, but is really an indicator of where you stand vis-a-vis any other distro.
A distro is much more than a collection of files or packages gathered from wherever. The only way for Puppy to really become the thing it proposes to be, is to go all the way and do things the right way -I mean 'right' enough to take full advantage of all that is possible. Puppy is not, and never was, a re-invention of the wheel, nor should it be. At best, it should 'round' some spots which some see as being square. But being different just for the sake of being different means you'll not be able to leverage the efforts of other people -the more different you try to be, the more important it is to build and maintain everything yourself without being dependent on others.

aarf

#11 Post by aarf »

Lobster wrote:
What would you use as the reference device?
i would have thought that ubuntu and debian had already been there so just follow them along for now. still have my eye on Linux Openmoko/Neo FreeRunner mobile phone one step closer would be it capable of running puppy.

aarf

#12 Post by aarf »

amigo wrote:Yeah, the first trouble is that 'arm' is not 'arm'. There are many flavors of arm architecture and only a few are compatible with each other. I saw, somewhere, that someone had calcualted the number of builds necessary to provide 'blanket' coverage of arm arch and it was in the thousands!
Still, the other problem, which is the same for building Puppy for *any* other architecture is that there is no orderly system for building puppy. Even at its' best -straight from Barry, the sources are spread all over, it includes binaries which were not compiled on any Puppy system, or on some other Puppy system than the one being built; it depends on the use of multiple kernel patches -some of which are pretty diificult to keep synced with current kernel sources.

I have been making a big effort to create a set of build scripts which use my src2pkg tool to create a full distro from scratch. The scripts are arch-agnostic, which means that once all the scripts are done, they can be used to build a system for another arch without having to edit a bunch of scripts. My system even derives the build-order for you. And my 'cheat' method of bootstrapping a new toolchain allows you to start off with nearly any sort of Linux system you are used to running.

Even if you use the woof build system to create a base system for arm, ppc or whatever, you are still going to have the work of compiling all the extras that Puppy uses which is probably at least 200 programs. And many of these will be resistant to building on certain arches. In the end, the only way to be able to maintain any Puppy distro, or create new distros for other arches, is going to require the creation of a real build system -not a 'rob-it-from-wherever-you-find-it' system. If Puppy really is much different from other distros, then its' particular needs at built-time will always be distinct enough to warrant and require that the libs and programs be built *for*, *by* and *on* a Puppy build system.

I am building such a system, but it will not be called puppy. It is called kiss-linux. Puppy needs its' own toolchain -not one grabbed from somewhere else. Just run the command 'gcc -dumpmachine' and see what it says -it says 'i486-t2-linux' or something like that. Until you get a system which returns 'i486-puppy-linux', there is not a chance of creating a real distro at all -even for a single architecture. If the devs have, in the past, gone to the trouble of building a 't2' toolchain, why didn't they go ahead and brand the thing so it would really be 'puppy-linux'. The difference will appear trivial to anyone who knows nothing about these things, but is really an indicator of where you stand vis-a-vis any other distro.
A distro is much more than a collection of files or packages gathered from wherever. The only way for Puppy to really become the thing it proposes to be, is to go all the way and do things the right way -I mean 'right' enough to take full advantage of all that is possible. Puppy is not, and never was, a re-invention of the wheel, nor should it be. At best, it should 'round' some spots which some see as being square. But being different just for the sake of being different means you'll not be able to leverage the efforts of other people -the more different you try to be, the more important it is to build and maintain everything yourself without being dependent on others.

ok amigo, i was hoping you would show up and give us the benefit of your extensive knowledge of arm and point us in the right direction.
I am building such a system, but it will not be called puppy. It is called kiss-linux
can you give a pie in the sky time frame of when you expect to be up and going.
'blanket' coverage of arm arch and it was in the thousands!
is/are there already thousands of different arm products on the market??

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

#13 Post by amigo »

I don't mean to discount the attractiveness of arm targets. I just wanted to point out that it is not so straightforward.
To me the best approach to take is to target certain devices -pick a tablet, PDA, netbook or whatever which is popular or looks like it will become so. Take into account the specific version of arm chip it is using and try to maximize your fire-power by finding several devices which are using the same arch. then, bulding for each device is mostly a matter of changing the kernel drivers included, or even do a 'blanket build' which includes all the modules needed for those devices.
Two popular arm flavors which cover quite a few devices are armv4 and armv4t. armv4 is compatible with 'xscale' devices, which you may have heard of. One of those is also compatible with these tiny computers which just look like a wall plugin power convertor -can't remember the name of the things off-hand...

As for a timetable on my work, I am quite close to finishing the basic system for x86, but the builds are already setup for use on x86_64 as well, and with an eye on a couple of arm targets. I have already used my build system on ppc long ago, so I know that is working too. The pace is 'deliberate', because the real work is mostly done up-front. Once I have the whole set of scripts for a complete base-system, building the other arches becomes pretty straightforward.

I'm not planning to build any LiveCD version of kiss, but others have expressed an inetrest in doing so. Personally, I think that running in RAM is not the way to go for netbooks and other small devices. Boot-times can be reduced by not using such large initrds. The penalty for not running in RAM is longer starup times for applications -the first time they run. But there are sane ways of improving that without having to resort to drastic measures.

I also prefer to not rely on kernel features from third-party patches. Doing so means you are always dependent on the developer keeping the patches up-to-date, having a co-developer who does so, or doing it yourself. I do sometimes use third-party kernel features, but they should not be central to the functionality of your system -notice the problems getting puppy features into later kernels or combining them with other third-party features (OLPC).

In general, resorting to drastic measures or using drastic criterion will only bring you more trouble down the road. KISS linux will be 'compact', but not tiny. Trying to restrict the size to any arbitrary figure simply means that you are going to sacrifice loads of usability with included software, and loss of compatibility with extra software.

My work is advancing on several fronts -particularly with regard to the packaging software which is central to the project. That also is being co-ordinated with a new package format and package database, but that format and database retain compatibility with existing tools such as slapt-get/gslapt. The package database provides information whihc makes development of the system easier -automatically generating compile-order lists and such.

I just last week got all the 300+ packages for X building using src2pkg -that includes all the scim-related stuff for use with japanese, russing, korean, chinese and other asian languages.

And the week before, I worked out a way to split the i18n components of glibc, so that I can provide internationalization without having to install ~300MB of i18n files, as supplied with glibc. But, I had to come up with code to find the needed files for each language and those it depends on, and a bit of fanciness to split that 300MB into 425 packages -whew! But now, it's done and the whole lot can be rebuilt for another architecture, or updated to a newer version by running *a single command*. That is the magic of having everything scripted. It takes more work up front, but once done it saves you loads of time and hair-brained effort later.

So now, back to work as I still have lots to do...

User avatar
Aitch
Posts: 6518
Joined: Wed 04 Apr 2007, 15:57
Location: Chatham, Kent, UK

#14 Post by Aitch »

amigo

You may want to have a re-think about calling it Kiss-linux

googling brings up

Kiss linux server

Kiss Technology, now defunct and pointing to Linksys/Cisco

Klik Kiss

and several others

If you really want that name, may I suggest blocking it out while it IS available? [i.e. buy all domains with that name, and park them :wink: ]

http://www.whois.net/whois/kiss-linux.com

http://www.whois.net/whois/kisslinux.com

However, I wish you well with whatever you end up calling it :D

Good Luck

Aitch :)

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

#15 Post by amigo »

Yeah, your right about that. I have some domain renewals coming up anyway, so I probably oughtta reserve some for kiss. Actually, it is still gonna come under the broader project name of amigolinux. kiss is such a generic word -I could have chosen something unique like:whatcha-ma-call-it-linux or neither-here-nor-there-linux or damnsimplelinux LOL
I thought you were gonna say: use another name cause it doesn't sound too simple... making things simple for users means things are more complicated for the devs...

aarf

#16 Post by aarf »

some arm resources
http://www.keil.com/dd/parms/arm.htm
http://www.arm.com/products/CPUs/
http://en.wikipedia.org/wiki/ARM_architecture#ARM_cores
http://en.wikipedia.org/wiki/X86
and yes there are many many flavours.

however i am not able to determine if
jamesjeffries2 wrote:PS i have puppy running well on this little x86 box
is what we are looking for. if it is then pleased do post the .iso somewhere and give us look, and tell us what you did.

User avatar
technowomble
Posts: 74
Joined: Thu 11 Oct 2007, 17:04
Location: West Gloucestershire, UK

ARM netbook

#17 Post by technowomble »

I just found this thread, having picked up a refurbished Datawind Ubisurfer ( which uses a Samsung ARM processor ) for 45GBP ( Price new 160GBP! ). It seems to be running a Debian based distro, but I'm having wifi issues - sees my access point but doesn't connect. I've e-mailed tech. support, maybe I should suggest they take a look at jermimah's Pwireless2!

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#18 Post by Lobster »

i would have thought that ubuntu and debian had already been there so just follow them along for now
When talking of a reference device
I was referring to a widespread ARM device
- that has not really emerged
As has been pointed out supporting many devices is
difficult.

The explosion of webpad computers
may well allow an ARM mainstream device

The emergence of Dpup (Debian package base)
and the Ubuntu package base for 'Lucid' Pup
http://puppylinux.org/wikka/Puppy5
will allow us to make use of the wider Linux expertise
and facilities

Puppy is OPEN
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

User avatar
Aitch
Posts: 6518
Joined: Wed 04 Apr 2007, 15:57
Location: Chatham, Kent, UK

#19 Post by Aitch »


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

#20 Post by nooby »

The Guy from Italy explain more about his "port"? Crosscompilation to an ARM computer of MicroCore, the TinyCore smallest version.
http://tinycorelinux.com/forum/index.ph ... c=8863.msg

I know nothing on how to read italian and I barely grasp English and Google is bad at doing Italian to English but if I get it he actually do cross compilation?

What is cross compilation.
http://en.wikipedia.org/wiki/Cross_compiler
A cross compiler is a compiler capable of creating executable code for a platform other than the one on which the compiler is run.

Cross compiler tools are used to generate executables for embedded system or multiple platforms.

It is used to compile for a platform upon which it is not feasible to do the compiling, like microcontrollers that don't support an operating system.

It has become more common to use this tool for paravirtualization where a system may have one or more platforms in use.

Not targeted by this definition are source to source translators, which are often mistakenly called cross compilers.
I use Google Search on Puppy Forum
not an ideal solution though

Post Reply