Thanks for your work on this, Martin. I was able to install Debian to a
sandisc 8gb USB flash drive. I am using the uboot ext2load command at
startup.
Here is what I did:
1) Boot loader
>You will need a boot loader that actually works. :)
I flashed flipflip's custom uboot image over tftp (
Dear porters, dpkg maintainers and developers,
It seems that `armhf' and `arm-hardfloat-linux-gnueabi' are the winners.
We are starting to work on Debian new port based on those names.
Thanks all for your contributions!
Best regards,
--
Héctor Orón
19:57 < markos_> ostable: armhf
> > On ARM one could have armelv5, armelv6, armelv7, armelv7neon, .., all
> > subarchs armel and crossinstallable. Before someone jumps "what about a
> > ARMv6 with NEON but no VFP", obviously some discretion must be used when
> > selecting subarchs to be supported.
>
> I don't think NEON without
On Fri, Jul 16, 2010 at 4:11 AM, Riku Voipio wrote:
> On Tue, Jul 13, 2010 at 03:24:35PM +0200, Loïc Minier wrote:
>> On Tue, Jul 13, 2010, Riku Voipio wrote:
>> > If dpkg had subarchitecture support, lpia wouldn't have been as big
>> > a issue. Ubuntu decided to shortcut and not add support for c
On Fri, Jul 16, 2010 at 9:23 AM, Wookey wrote:
> +++ Konstantinos Margaritis [2010-07-16 16:04 +0300]:
>> On Friday 16 July 2010 15:36:26 Wookey wrote:
>> > Just to save others a bit of time:
>> >
>> > The summary from that lot is that hardfp is about 4% faster on average
>> > (between 0 and 11% o
+++ Konstantinos Margaritis [2010-07-16 16:04 +0300]:
> On Friday 16 July 2010 15:36:26 Wookey wrote:
> > Just to save others a bit of time:
> >
> > The summary from that lot is that hardfp is about 4% faster on average
> > (between 0 and 11% on various tests). So definitely faster for
> > real-wo
I have use 1:1 in bootcmd_sata instead of 0:1 as you have suggested to me...
Now it works.
I can boot from my esata disk.
Those are my fully working u-boot settings:
setenv bootargs_console console=ttyS0,115200
setenv bootcmd_sata 'ide reset; ext2load ide 1:1 0x0110 /uInitrd; ext2load
ide
On Friday 16 July 2010 15:36:26 Wookey wrote:
> Just to save others a bit of time:
>
> The summary from that lot is that hardfp is about 4% faster on average
> (between 0 and 11% on various tests). So definitely faster for
> real-world stuff, but 4% won't justify a new port from Debian's POV.
4%
+++ Konstantinos Margaritis [2010-07-16 14:56 +0300]:
> Ok, here are Arora Sunspider (javascript) benchmarks
Handy benchmark. I didn't know about that before (just found out my
desktop is 2.8 times faster than my laptop on this).
Just to save others a bit of time:
The summary from that lot i
Hello,
2010/7/16 Aurelien Jarno :
>> So, the same question: what is the measured speed up for users of ARM
>> architectures >=5, and is it worth excluding the significant number of
>> users of armv4t boards, from using "the universal operating system"
>> Debian?
>
> I was not aware of that. If the
Martin Guy a écrit :
> On 7/16/10, Martin Michlmayr wrote:
>> * Aurelien Jarno [2010-07-16 09:38]:
>>
>>> BTW, has anybody thought about increasing the minimum requirement for
>> > the armel port, for example to armv5? Available machines has evolved,
>> > maybe the port should do the same.
>>
>
On Fri, Jul 16, 2010, Konstantinos Margaritis wrote:
> Ok, here are Arora Sunspider (javascript) benchmarks
> for softfp:
http://bit.ly/a4bS0V
> for hardfp:
http://bit.ly/9M0OPo
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe".
On Fri, Jul 16, 2010, Riku Voipio wrote:
> On ARM one could have armelv5, armelv6, armelv7, armelv7neon
Hmm ok, I kind of prefer the Features/Capabilities idea: encoding that
this is an armel package which requires this or that feature at
runtime, exposing that in APT, and patching APT to prefe
On Friday 16 July 2010 14:30:38 Paul Brook wrote:
> Based on what evidence?
>
> The G4 has an single cycle pipelined out-of-order FPU. The A8 has a
> non-pipelined FPU that takes between 5 and 20 (normal single precision is
> 10) cycles to give a result. A 9x slowdown sounds right on the ball.
O
Ok, here are Arora Sunspider (javascript) benchmarks
for softfp:
http://www2.webkit.org/perf/sunspider-0.9/sunspider-results.html?{%223d-cube%22:[649,737,722,721,720],%223d-morph%22:[1050,1070,1058,1058,1053],%223d-
raytrace%22:[630,674,659,668,667],%22access-binary-trees%22:[254,254,254,265,245],
> > One way to check how well softfp performs would be to run povray in
> > Ubuntu versus in Debian; this will mix noise in the results, but I
> > don't expect the minor sourceful differences to make the biggest
> > impact, but rather the toolchain opts would. (You're speaking of a
> > 3-fold
On 7/16/10, Martin Michlmayr wrote:
> * Aurelien Jarno [2010-07-16 09:38]:
>
> > BTW, has anybody thought about increasing the minimum requirement for
> > the armel port, for example to armv5? Available machines has evolved,
> > maybe the port should do the same.
>
>
> Indeed. From Paul's emai
> hardfp 5% faster than softfp
> hardfp 3% faster than softfp
> hardfp: 5% faster than softfp
But these are negligable differences!
M
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
h
On Fri, Jul 16, 2010 at 09:55:49AM +0100, Martin Michlmayr wrote:
> * Aurelien Jarno [2010-07-16 09:38]:
> > BTW, has anybody thought about increasing the minimum requirement for
> > the armel port, for example to armv5? Available machines has evolved,
> > maybe the port should do the same.
> In
Hello Loic,
2010/7/16 Loïc Minier :
> still need a new port. We also need a different triplet for the
> multiarch use case; I know you're not too interested in multiarch
> yourself anymore, but it's safer to pick a different triplet
> nevertheless IMHO, using the vendor field.
Excuse me! Do
On Tue, Jul 13, 2010 at 03:24:35PM +0200, Loïc Minier wrote:
> On Tue, Jul 13, 2010, Riku Voipio wrote:
> > If dpkg had subarchitecture support, lpia wouldn't have been as big
> > a issue. Ubuntu decided to shortcut and not add support for compatible
> > subarchs in dpkg, and the result was what it
* Martin Hänsel [2010-07-15 23:26]:
> i would like to boot my Thecus N2100 NAS from USB-Flash-Drive.
> Maybe somebody could explain me how to customize the boot images etc.
>
> The advantage I see is that I could spin down the data hard disks
> during they are not in use.
>
> Maybe it would be g
* Aurelien Jarno [2010-07-16 09:38]:
> BTW, has anybody thought about increasing the minimum requirement for
> the armel port, for example to armv5? Available machines has evolved,
> maybe the port should do the same.
Indeed. From Paul's emails, I'm getting the feeling that moving the
armel port
On Fri, Jul 16, 2010, Konstantinos Margaritis wrote:
> softfp:
I wonder what you built with softfp exactly? Did you rebuild
libc6, libpng12-0 for instance? Not that I expect that most of the
time is spent in libpng12-0, but still.
As I understand it, we have these options:
- keep Debian ar
On Friday 16 July 2010 11:11:24 Loïc Minier wrote:
> On Fri, Jul 16, 2010, Konstantinos Margaritis wrote:
> > softfp:
>
> I wonder what you built with softfp exactly? Did you rebuild
> libc6, libpng12-0 for instance? Not that I expect that most of the
> time is spent in libpng12-0, but still.
On Friday 16 July 2010 11:11:39 Aurelien Jarno wrote:
> Why are we comparing softfp vs hardfp? We should compare the existing
> armel port, that is soft, vs both softfp and hardfp.
Er, that's the whole point of the discussion. There is no question about
having a new soft port, but a hardfp port -
Loïc Minier a écrit :
> On Fri, Jul 16, 2010, Konstantinos Margaritis wrote:
>> softfp:
>
> I wonder what you built with softfp exactly? Did you rebuild
> libc6, libpng12-0 for instance? Not that I expect that most of the
> time is spent in libpng12-0, but still.
>
> As I understand it, we
Konstantinos Margaritis a écrit :
> On Friday 16 July 2010 10:47:40 Aurelien Jarno wrote:
>> Have this 30% have actually been measured on such applications?
>
> how can I benchmark the desktop? It feels faster, that's definite.
>
>> If softfp is already 10x faster, does the additional 30% betwee
On Friday 16 July 2010 10:47:40 Aurelien Jarno wrote:
> Have this 30% have actually been measured on such applications?
how can I benchmark the desktop? It feels faster, that's definite.
> If softfp is already 10x faster, does the additional 30% between softfp
> and hardfp really worth it? Do we
On Friday 16 July 2010 10:38:19 Aurelien Jarno wrote:
> I don't say a hardfp port should not be done, but that starting such a
> port should be done based on solid *facts*, benchmarks, tests and so on.
Ok, I just couldn't help it and ran another benchmark, this time I chose
povray (3.6.1-12), fi
Konstantinos Margaritis a écrit :
> On Thursday 15 July 2010 17:34:01 Martin Guy wrote:
>> I still doubt that the disruption and extra work for the community of
>> Debian package maintainers, and the lower quality of the resulting
>> archive, is worth the small increment in speed that is promised.
On Fri, Jul 16, 2010, Hector Oron wrote:
>In that case, Debian was clear
> to take it as another architecture, but, nowadays,
> arm-none-linux-gnueabi supports hard, soft and softfp. Bringing old
> discussions up to front, would not make sense to have ABI sup
On Thu, Jul 15, 2010, Paul Brook wrote:
> A simple benchmark confirms this hypothesis.
> softfp is actually faster in many cases.
Could we consider it a gcc bug that when hardfp is turned on, it could
still pick a faster soft float code path and doesn't?
--
Loïc Minier
--
To UNSUBSCRIBE, em
Matt Sealey a écrit :
> I am fairly sure (oh you did!) find a contrived benchmark to show that
> some code is faster on softfp in some cases, but taking a holistic
> approach I find it hard to believe that every time a floating point
> function is called across any of 20,000 packages possibly runni
34 matches
Mail list logo
