Page 1 of 2
FatdogArm Alpha3 - 2 October 2013 [CLOSED]
Posted: Wed 02 Oct 2013, 12:07
by jamesbond
Posted: Wed 02 Oct 2013, 15:40
by linux28
What are the hardware can be used? All ARM can use it?
Posted: Thu 03 Oct 2013, 01:06
by tuna1
Hi
Fatdog is very nice, nice work, i just want to report two things but i don't really know if they are fatdog related problems or not
I have a mk802 with 1g ram, it's booting fine but htop says only 490mb as avaiable memory, is this expected?
I have 2 tvs, when i plug the stick on the first one fatdog boots straight to x right away without any problem, but on the other tv it takes a lot of time, it seems like xorg is probing many different resolutions without sucess, sometines i see for a few seconds distorted images. But after a long very long wayting i finally get X to work and the tv reports the image as 1280x720p. 720p is the same resolution my first tv reports so what may be the problem with my other tv?
Thanks
Posted: Thu 03 Oct 2013, 03:39
by jamesbond
linux28 wrote:What are the hardware can be used? All ARM can use it?
That will never happen due to fragmentation of the ARM platform.
FatdogArm meta-distribution can be used for any ARM platform/device capable of ARMv7-A, VFPv3-d32 and NEON. There are images available for Mele A1000 and OLPC XO-4 (XO-4 image is still on the way); and in the future there may be images for Cubieboard2 too.
Please check the release notes for more details.
tuna1 wrote:Hi
Fatdog is very nice, nice work,
Thanks.
i just want to report two things but i don't really know if they are fatdog related problems or not
I have a mk802 with 1g ram, it's booting fine but htop says only 490mb as avaiable memory, is this expected?
You will need to find a script.bin for your 1G mk802; otherwise only 512MB is recognised (and a few megs are taken for video buffer etc). Please try the attached script.bin and tell me whether it works - otherwise, please see the release notes for details.
I have 2 tvs, when i plug the stick on the first one fatdog boots straight to x right away without any problem, but on the other tv it takes a lot of time, it seems like xorg is probing many different resolutions without sucess, sometines i see for a few seconds distorted images. But after a long very long wayting i finally get X to work and the tv reports the image as 1280x720p. 720p is the same resolution my first tv reports so what may be the problem with my other tv?
The Mele image is configured to do EDID readout before setting the resolution; if you TV doesn't support EDID, it may end up taking quite a while for the operation to time-out. If you know what resolution to set, look at the "video" line in uEnv.txt and remove the EDID word, ie change from:
Code: Select all
video=disp.screen0_output_mode=EDID:1280x720p60
to
Code: Select all
video=disp.screen0_output_mode=1280x720p60
For more details please check
http://linux-sunxi.org/Display.
cheers!
Posted: Thu 03 Oct 2013, 16:07
by tuna1
jamesbond wrote:linux28 wrote:What are the hardware can be used? All ARM can use it?
That will never happen due to fragmentation of the ARM platform.
FatdogArm meta-distribution can be used for any ARM platform/device capable of ARMv7-A, VFPv3-d32 and NEON. There are images available for Mele A1000 and OLPC XO-4 (XO-4 image is still on the way); and in the future there may be images for Cubieboard2 too.
Please check the release notes for more details.
tuna1 wrote:Hi
Fatdog is very nice, nice work,
Thanks.
i just want to report two things but i don't really know if they are fatdog related problems or not
I have a mk802 with 1g ram, it's booting fine but htop says only 490mb as avaiable memory, is this expected?
You will need to find a script.bin for your 1G mk802; otherwise only 512MB is recognised (and a few megs are taken for video buffer etc). Please try the attached script.bin and tell me whether it works - otherwise, please see the release notes for details.
I have 2 tvs, when i plug the stick on the first one fatdog boots straight to x right away without any problem, but on the other tv it takes a lot of time, it seems like xorg is probing many different resolutions without sucess, sometines i see for a few seconds distorted images. But after a long very long wayting i finally get X to work and the tv reports the image as 1280x720p. 720p is the same resolution my first tv reports so what may be the problem with my other tv?
The Mele image is configured to do EDID readout before setting the resolution; if you TV doesn't support EDID, it may end up taking quite a while for the operation to time-out. If you know what resolution to set, look at the "video" line in uEnv.txt and remove the EDID word, ie change from:
Code: Select all
video=disp.screen0_output_mode=EDID:1280x720p60
to
Code: Select all
video=disp.screen0_output_mode=1280x720p60
For more details please check
http://linux-sunxi.org/Display.
cheers!
Removing eid worked. Thank you!
I tryed your script.bin but no sucess, the avaiable memory is the same and worst, cpu use is always at 20%, with your original script.bin cpu use is very low.I will read your release notes but i'm not very skilled...
Posted: Thu 03 Oct 2013, 16:56
by jamesbond
tuna1 wrote:Removing eid worked. Thank you!
Yay!
I tryed your script.bin but no sucess, the avaiable memory is the same and worst, cpu use is always at 20%, with your original script.bin cpu use is very low.I will read your release notes but i'm not very skilled...
Try adding "mem=1024" to the extras line in uEnv.txt (with the new script.bin). I can't tell why the new script.bin eat 20% of your CPU, I suggest you try other FEX files available here too:
https://github.com/linux-sunxi/sunxi-bo ... config/a10 - there are a few files for mk802. The new script.bin I gave you is also from there.
cheers!
Posted: Fri 04 Oct 2013, 01:02
by tuna1
jamesbond wrote:tuna1 wrote:Removing eid worked. Thank you!
Yay!
I tryed your script.bin but no sucess, the avaiable memory is the same and worst, cpu use is always at 20%, with your original script.bin cpu use is very low.I will read your release notes but i'm not very skilled...
Try adding "mem=1024" to the extras line in uEnv.txt (with the new script.bin). I can't tell why the new script.bin eat 20% of your CPU, I suggest you try other FEX files available here too:
https://github.com/linux-sunxi/sunxi-bo ... config/a10 - there are a few files for mk802. The new script.bin I gave you is also from there.
cheers!
Sorry, I made you belive i had a mk802 1gb but what i have is a mk802ii, you tryed to help me but that was not possible with my mistake. but there is one good thing with this, i started reading about this and after some time i was able to build my mk802ii script.bin from the link you gave me. The cpu load is now working just fine but still no acess to the full memory. I tryed adding mem=1024 but when i do that it won't boot
Sorry again and thank you, today you helped me learn a few things
Posted: Mon 07 Oct 2013, 14:05
by jamesbond
tuna1 wrote:Sorry, I made you belive i had a mk802 1gb but what i have is a mk802ii, you tryed to help me but that was not possible with my mistake. but there is one good thing with this, i started reading about this and after some time i was able to build my mk802ii script.bin from the link you gave me. The cpu load is now working just fine but still no acess to the full memory. I tryed adding mem=1024 but when i do that it won't boot
Sorry again and thank you, today you helped me learn a few things
I think I may have to build a custom version of u-boot for you. This is the general problem with ARM platforms - the crucial part (bootloader, kernel) can seldom be shared
Running FDAA3 from Mele with hardrive
Posted: Tue 08 Oct 2013, 22:06
by Ted Dog
Here is my method to run both sfs file and savefile from a mele with a harddrive.
copy fs-arm.sfs as fda-arm.sfs to hard drive partition, and use this uEnv.txt
Code: Select all
console=tty0
kernel=uImage-a10
initrd=uInitrd-a10
loglevel=3
audio=hdmi.audio=EDID:0
video=disp.screen0_output_mode=1280x720p60
root=/dev/sda6
rootwait=rootwait
rootwait=waitdev=3
panicargs=panic=10
#coldplug=
basesfs=basesfs=local:fda-arm.sfs
#savefile=savefile=direct:device:mmcblk0p2
extras=sunxi_ve_mem_reserve=0 sunxi_g2d_mem_reserve=0 sunxi_no_mali_mem_reserve sunxi_fb_mem_reserve=8 loadmodules=sw_ahci_platform
causes the sata hard drive to be found
Posted: Wed 09 Oct 2013, 05:44
by jamesbond
jamesbond wrote:tuna1 wrote:Sorry, I made you belive i had a mk802 1gb but what i have is a mk802ii, you tryed to help me but that was not possible with my mistake. but there is one good thing with this, i started reading about this and after some time i was able to build my mk802ii script.bin from the link you gave me. The cpu load is now working just fine but still no acess to the full memory. I tryed adding mem=1024 but when i do that it won't boot
Sorry again and thank you, today you helped me learn a few things
I think I may have to build a custom version of u-boot for you. This is the general problem with ARM platforms - the crucial part (bootloader, kernel) can seldom be shared
Okay, this is a version of uboot for mk802ii. Install it by doing
Code: Select all
dd if=uboot-mk802ii.bin of=/dev/XXX bs=1024 seek=8
where /dev/XXX is your SD Card device (make sure you don't point to your harddisk or your harddisk data will be destroyed beyond repair - since you have already dd-ed the image I suppose you already know about this).
FatdogArm on Cubieboard2
Posted: Wed 09 Oct 2013, 06:35
by jamesbond
I have received a
Cubieboard2 from someone who shall remain anonymous (thank you!).
The board arrived yesterday, and I've got FatdogArm running on it today; here is the mugshot.
It still require a few tweaks, but in general it's running great.
Posted: Fri 11 Oct 2013, 01:01
by tuna1
jamesbond wrote:jamesbond wrote:tuna1 wrote:Sorry, I made you belive i had a mk802 1gb but what i have is a mk802ii, you tryed to help me but that was not possible with my mistake. but there is one good thing with this, i started reading about this and after some time i was able to build my mk802ii script.bin from the link you gave me. The cpu load is now working just fine but still no acess to the full memory. I tryed adding mem=1024 but when i do that it won't boot
Sorry again and thank you, today you helped me learn a few things
I think I may have to build a custom version of u-boot for you. This is the general problem with ARM platforms - the crucial part (bootloader, kernel) can seldom be shared
Okay, this is a version of uboot for mk802ii. Install it by doing
Code: Select all
dd if=uboot-mk802ii.bin of=/dev/XXX bs=1024 seek=8
where /dev/XXX is your SD Card device (make sure you don't point to your harddisk or your harddisk data will be destroyed beyond repair - since you have already dd-ed the image I suppose you already know about this).
It works, full memory being used now, thanks for your help
Posted: Sat 12 Oct 2013, 17:38
by jamesbond
tuna1 wrote:It works, full memory being used now, thanks for your help
No worries, glad that it finally works.
Posted: Mon 14 Oct 2013, 03:21
by Ted Dog
Request for compile for ARM pov-ray 3.6, or 3.7 (harder to compile 4 ARM)
This is a mid to large sized project 4+ hours for/on RasPI without your dccs.
One of the few clean, large, cross platform projects,
I use it a lot for complex math rendering and engineering work (weird hobby, most likely the only NON Phd playing in this field, so shhhh I'm like Howard from the Big Bang Theory )
Posted: Thu 17 Oct 2013, 08:01
by jamesbond
Ted Dog wrote:Request for compile for ARM pov-ray 3.6, or 3.7 (harder to compile 4 ARM)
I'll look into this.
Posted: Thu 17 Oct 2013, 15:37
by Ted Dog
jamesbond wrote:Ted Dog wrote: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)
Posted: Thu 17 Oct 2013, 16:22
by 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.
Posted: Fri 18 Oct 2013, 16:31
by jamesbond
jamesbond wrote:Ted Dog wrote: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).
Posted: Fri 18 Oct 2013, 19:41
by 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
Posted: Thu 24 Oct 2013, 01:21
by 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.