FatdogArm Alpha3 - 2 October 2013 [CLOSED]

[Ted Dog]

Request for compile for ARM pov-ray 3.6, or 3.7 (harder to compile 4 ARM)

I'll look into this.

Thanks, its does have a good use as a test for advanced cpu settings, It for all its complexity, it is a well developed C code, that input and outputs are the same regardless of hardware/OS etc. The only things that change is the TIME to complete task.
I would have expected a simple card game would compile cleanly and easily but NO!
I expected a large complex program like this to be a nightmare, but it was just the standard 3 step simple configure,make,make install. :
Also expected the compile to take a long time, but with FD621 all expanded RAM took 4 minutes, FD630RC about 7 minutes (not sure why, but I think dev was still compressed and running on a slow USB)

[Ted Dog]

I'm going to take a stab at compiling POVRAY with My Mele, my testing of FD630RC hit a large road block without a simple work around. I'm sure it may only me the Unique way I use FD, but I'm not setup to test without major shuffle of equipment, I've boxed myself in by not completing a harddrive backup and data shuffle that is needed, since I wanted to have multiple new tests on optical drive support when FD630 was released.
Will let you know if its hard/easy and time. may need your help on the CPU settings used for gcc if configure does not.

[jamesbond]

Request for compile for ARM pov-ray 3.6, or 3.7 (harder to compile 4 ARM)

I'll look into this.

I haven't tried 3.7RC2, but 3.6 has problems. FatdogArm comes with latest libpng (1.6); and povray 3.6 will only work with 1.4 or or earlier. I'm looking for patch that would enable povray 3.6 building with new libpng, if I can't find that I'll try 3.7RC2 instead.

But seriously, isn't povray a very compute-intensive application? Why run it on the Mele (or ARM for that matter)? Mele's FPU performance (A10) isn't that stellar and I doubt that povray comes with NEON optimisation.

Povray isn't the only one with this issue, I am trying to build netpbm too and the latest "super-stable" version of netpbm has exactly the same issue. I'm going to try newer version of netpbm (from svn).

[Ted Dog]

Yes, povray is VERY number crunching intensive, but its a watts to results and use of a planned always on 'computer.'
As you may have guessed my internet offering is 3rd world at best, so a small wattage machine could spend hours just wget-ing a single small iso.
I'm using POVray as a visual feedback of engineering changes to space frames, the space frame itself is usually fast to render, but that space-frame is used as a roof for family home sized buildings. I construct the roof first and build a home to match it.
Then pass those ideas to others for feedback. The more polished the 'homes' look the more likely the 'plan' would be approved. Some people can 'see' the results at the simple block stage better, others can't. It takes weeks for each new design to be 'thunk' so if the last design is sent to the always on Mele for those extra photon passes and flair the more photo realistic the better.

google: roof first nez

[starhawk]

Hey, jamesbond, would FatDogARM support the A20? I know it runs (at least somewhat) on A10 now...

I'm working with a very nifty project, actually found out about it through something Barry bought to support them -- EOMA-68. Basically a "cartridge motherboard" sort of thing -- the CPU/SoC, RAM, graphics, and some storage (microSD) is in a "CPU Card" with the physical form factor of a PCMCIA card (totally different pinout, though). The CPU card goes into a carrier board (my personal term, not the group's) that has ports and such on it.

More here --> http://elinux.org/Embedded_Open_Modular ... re/EOMA-68

*IF* FatDogARM could be made to work with this I'd just about dance in the streets.

Another question -- would it be possible to create a "mini-OS" that ran eg QEMU to emulate an x86 environment, on such a CPU, "under" the regular OS but also transparent to that OS? In other words --

base hardware
"mini-OS" emulation layer
some sort of x86 *nix OS
user

That way I could run, say, FatDog or Upup Raring or whatever, on this thing, as if it had eg an Atom CPU in it. ARM's great for power consumption but I don't think the codebase (set of compatible applications and packages, in this case) is anywhere near as big for *nix ARM as it is for *nix x86... x86 is very much PlugNPlay with software because it's been around since 1981 or so and it's been *nix-able since Linus Torvalds started mucking with Unix memory management in the early 1990s (don't remember if it was '92 or '93...). Can't really say the same for ARM.

[jamesbond]

Hey, jamesbond, would FatDogARM support the A20? I know it runs (at least somewhat) on A10 now...

Not in alpha3, but yes it does, see my post here http://murga-linux.com/puppy/viewtopic. ... 419#729419 - Cubieboard2 uses A20. All it needs is a new kernel, a new bootloader, and a new script.bin (what else is new ). I'll probably cobble it together and make an release soon since I've got other things to attend and may disappear for a while. (My goals for "beta" release isn't going to be met so it will just be another alpha).

I'm working with a very nifty project, actually found out about it through something Barry bought to support them -- EOMA-68. Basically a "cartridge motherboard" sort of thing -- the CPU/SoC, RAM, graphics, and some storage (microSD) is in a "CPU Card" with the physical form factor of a PCMCIA card (totally different pinout, though). The CPU card goes into a carrier board (my personal term, not the group's) that has ports and such on it.

More here --> http://elinux.org/Embedded_Open_Modular ... re/EOMA-68

*IF* FatDogARM could be made to work with this I'd just about dance in the streets.

The answer is a qualified yes. Bootloader support is there (but you need to compile it); kernel support is probably there unless EOMA does very exotic things; the only thing missing is the script.bin - but I'm sure you can get it from EOMA devs.

Another question -- would it be possible to create a "mini-OS" that ran eg QEMU to emulate an x86 environment, on such a CPU, "under" the regular OS but also transparent to that OS? In other words --

base hardware
"mini-OS" emulation layer
some sort of x86 *nix OS
user

That way I could run, say, FatDog or Upup Raring or whatever, on this thing, as if it had eg an Atom CPU in it.

Yes you can, but I doubt how practical it would be due to (low-)speed. You can even do this on your existing x86 machine - you can run qemu-system-x86 (or qemu-system-x86_64 if you want to run Fatdog64) on the real x86 and then boot Puppy in it - and figure out the speed yourself.

ARM's great for power consumption but I don't think the codebase (set of compatible applications and packages, in this case) is anywhere near as big for *nix ARM as it is for *nix x86...

Not really. Many applications are portable; just look at the number packages supported for the ARM architecture.

x86 is very much PlugNPlay with software because it's been around since 1981 or so and it's been *nix-able since Linus Torvalds started mucking with Unix memory management in the early 1990s (don't remember if it was '92 or '93...).

True, but it has been a long time since Linux moved from being 386-only OS. The main problem with ARM is not the apps or the OS, but with the lack of discoverable bus (like USB or PCI) resulting in OS fragmentation (the analogy would be: a different kernel for every different motherboard).

[Ted Dog]

Could really use PovRay, would you tell me how you compiled it on ARM, how long it took to get to the stage you reported back. I think it can compile without 3rd party image support libraries, I could feed the raw bitmap into an existing ARM graphic editor to compress.

Just came up with a new idea, and am off to model it, so, will not be testing releases for a few days,

Oh, one more thing is the distributed compile code stuff in FDAa3 and/or hopefully FD630rc? If not please add the pair in next rollouts, sounds like you are close on the FD64-630b2.

[jamesbond]

Could really use PovRay, would you tell me how you compiled it on ARM, how long it took to get to the stage you reported back.

I didn't get 3.6 to compile yet because of libpng16 conflicts and can't seem to find any patches around it. I haven't tried 3.7RC due to lack of time I have a ton of stuff I want to compile there too but Reality (tm) is taking over at the moment.

I think it can compile without 3rd party image support libraries, I could feed the raw bitmap into an existing ARM graphic editor to compress.

Yes you can I think, but it's really annoying to compile it withouth tiff/png support. On another news, I've got netpbm to compile and it is now on the repo.

Oh, one more thing is the distributed compile code stuff in FDAa3 and/or hopefully FD630rc? If not please add the pair in next rollouts, sounds like you are close on the FD64-630b2.

They are both in FatdogArm repo (distcc and distcc-helper) and Fatdog64 repo (distcc and cross-gcc), instruction here.

[Sage]

FatdogArm meta-distribution can be used for any ARM platform/device capable of ARMv7-A, VFPv3-d32 and NEON.

The original Raspbian distribution contained a Puppy version. It works well. Rpi is ARM11, v6 compatible.
Rpi is the market leader by an huge margin, worldwide with massive development of peripherals and co-developments with Arduino and Beagleboard interfacing. Expect to read a lot more - it has legs!
Why focus on the Mele?

[jamesbond]

Why focus on the Mele?

The focus isn't on Mele. Mele was just a development platform (to compile stuff, etc). It would be impossibly slow to compile stuff on Raspi. As you have quoted, the target platform for FatdogArm is:

FatdogArm meta-distribution can be used for any ARM platform/device capable of ARMv7-A, VFPv3-d32 and NEON.

Mele is one of those, but FatdogArm is not only for Mele. We have it running on Qemu, Cubieboard2 (A20), OLPC XO-4 (Marvell PXA2128 SoC), some forums members have it running for MK802ii, etc. In the future I will lower the bar to VFPv3-d16 without NEON to support lesser endowed platforms, but I won't go lower than ARMv7, not for FatdogArm.

The original Raspbian distribution contained a Puppy version. It works well. Rpi is ARM11, v6 compatible.
Rpi is the market leader by an huge margin, worldwide with massive development of peripherals and co-developments with Arduino and Beagleboard interfacing. Expect to read a lot more - it has legs!

I have technical and philosophical concerns with Raspi.
The technical concerns:
- Raspi is mainly a (closed-source) GPU, with an weak, low-end ARM CPU tacked onto it.
- The ARM CPU is ARMv6, which is an older generation architecture. All newer performance-targeted ARM SoCs designs are ARMv7 (Cortex, Snapdragon, Kraith, Armada, PXA, etc) for good reason. Sure SoC companies still design and make a lot of ARMv6 (or even ARMv5) chips as well, but they aren't meant for performance applications; they are meant for embedded stuff (routers, NAS controllers, etc).
- The ARM CPU on Raspi is running at 700MHz - this is *slow*. (Don't compare it with Pentium 3 running at 700MHz - clock per clock, ARMv6 is far much slower than Pentium 3).
- The initial version of Raspi had only 256MB RAM.

All in all this makes Raspi a very weak platform for desktop replacement (which is FatdogArm's target). Sure it may be able to play 1080p HD video or run 3D Quake3 because of its excellent GPU, but that has nothing to do with its general purpose computing performance (which is performed by its ARM part) - which is poor.

[Sage]

Thanks for all that, jb. What puzzled me was that BK had already done the porting/compiling for Rpi which must've been some considerable effort. You are right about lack of performance, but Rpi is focussing on HW development like sensors, switching and general IF-ing along with coding-for-kids, including machine level. We desperately need to educate a new generation of binary-capable & assembler writers as those skills are disappearing fast now that 60's & 70's wannabes are retiring!
Bonus if one can get a squint at the Interweb with these devices. Maybe leave the consumer end of the biz for Android, though?
Rpi is now being issued with 512Mb. 700 is slow but the boot process allows modest overclocking. More aggressive performance may be possible by fitting the custom HS. Should be OK as the ARMs have plenty of thermal headroom.

[JackWagon]

I have my Mele A2000 loaded with FatdogArm. The network configuration is slower than my android network connection.

terminal command:
dmesg | grep -i duplex
reports:

[ 30.850000] wemac wemac.0: eth0: link up, 10Mbps, half-duplex, lpa 0x0021

how can I get to: 100Mbps full-duplex?

thanks,
JW

[jamesbond]

JW,

Install ethtool from the repo then try this:

Code: Select all

ethtool -s eth0 speed 100 duplex full

[jamesbond]

Alpha4 release: http://murga-linux.com/puppy/viewtopic. ... 069#734069