On 7 July 2010 06:27, Hai Nguyen Dang wrote:
> Hi Christoph,
> Just sharing. I tried the automatic process but failed, too. It doesn't
> detect any USB or external USB HDD that I have. So I've gone through the
> manual installation and it works fine. I really don't know what is the
> problem with
Hi Christoph,
Just sharing. I tried the automatic process but failed, too. It doesn't
detect any USB or external USB HDD that I have. So I've gone through the
manual installation and it works fine. I really don't know what is the
problem with the automatic installer, but never mind, you can install
Hi,
I think you have to cross compile debian ln your machine before place
it into an sd card, usb stick, or the flash memory of the sheevaplug.
Cordialement,
zerros.
Le 6 juil. 2010 à 23:59, "Christoph A." a écrit :
Hi,
I'm trying to install debian (stable or testing) on a sheevaplug,
Hi,
I'm trying to install debian (stable or testing) on a sheevaplug, but
both fail to detect the 'disk' - see attachment.
I used the well known howto for that task:
http://www.cyrius.com/debian/kirkwood/sheevaplug/install.html
Is there a way around that problem?
best regards,
Christoph
<>
On Tue, Jul 06, 2010, Joey Hess wrote:
> Could the targeted CPU be used in the name? Ie, armelv7.
I would be a bit scared that this has a chance of getting out of date,
or be confusing because other ports might be v7 as well, or also
because this only reflects a subset of the ports' requirement
On Tue, Jul 06, 2010, Wookey wrote:
> The reason is that softfp will work on devices with and without FPUs.
> hardfp only works on devices with fpus, whilst still allowing the
> optional use of FPU units when present. So for a binary distribution
> it makes sense as the most general option.
To c
Brian Szymanski wrote:
> This seems like the right move, particularly since int-heavy code won't
> benefit at all from this change. IMHO, what we really want is to take
> advantage of features on more "modern" arm cpus - the user shouldn't
> have to care if that's because of hardfp or thumb-2 or wh
On 07/06/2010 03:43 PM, Sune Vuorela wrote:
> On 2010-07-06, Brian Szymanski wrote:
>
>> Suggested arch names: armfast / armfull ?
>>
> to later be superceded by armfaster, armsuperfast, armmegafast ?
>
Heh, no. What I meant was a moving target that has a higher threshold
than armel -
+++ Wookey [2010-07-06 19:36 +0100]:
> +++ Hector Oron [2010-07-06 19:30 +0200]:
oops - unhelpful typo in my mail:
> There are fields in the elf headers to indicate cababilities used in a
> binary which are not currently used by the compiler which would help
> in automatically ensuring that CPUs
On 2010-07-06, Brian Szymanski wrote:
> Suggested arch names: armfast / armfull ?
to later be superceded by armfaster, armsuperfast, armmegafast ?
/Sune
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.or
On 07/06/2010 02:38 PM, Loïc Minier wrote:
> During these chats, I heard other suggestions around a new port
> notably, optimizing for much more recent CPUs such as armv7+. Ubuntu
> did see quite a difference by moving all the way up to armv7 + thumb-2.
>
This seems like the right move, par
+++ Hector Oron [2010-07-06 19:30 +0200]:
> " There are 3 ABIs in armel right now, regarding the use of the fpu: a) soft
> (no
> fpu used, all fpu math is done software only, using libgcc fallback
> functions), b) softfp (the fpu is used, but function arguments are passed
> through the integer re
On Tue, Jul 06, 2010, Hector Oron wrote:
> On the other hand, one can imagine providing only a set of optimized
> softfp libraries in addition to the default soft one, that are selected
> at runtime. "
> -- Aurelien
So we tried this in Ubuntu, and it doesn't yield much; we had a vfp
libc6, gtk
On Tuesday 06 July 2010 20:45:33 Paul Brook wrote:
> Debian is pure soft-float (i.e. -mfloat-abi=soft).
Right, all the more reason for a new flavour then :)
> -mfloat-abi=soft and -mfloat-abi=softfp are binary compatible (objects and
> libraries can be freely mixed). Obviously softfp code will wi
On Tue, Jul 06, 2010 at 07:30:13PM +0200, Hector Oron wrote:
> I would also like to comment that genesi-usa has been kind enough to
> provide with hardware (EfikaMX [2]) to some of the leading people on
> Debian projects as Live, Emdebian and Edu. If you want to work on the
> port, there might be a
On Tuesday 06 July 2010 20:30:13 Hector Oron wrote:
...
> some preliminary results gave me 20-25% speed increase on exactly the same
> software/hardware configuration (eg. glxgears on software mesa reports 145
> fps vs 120 fps).
Just one comment, some more benchmarking [1] revealed ~35% speed
A couple of inaccuracies:
> These are configured by the gcc flags: -mfloat-abi={soft,softfp,hard}.
> Softfp is the default in pretty much every distro out there (incl. Ubuntu,
> Debian, etc). Only some OpenEmbedded builds have enabled hardfp, but these
> are too specialized.
Debian is pure soft-f
Dear armel porters,
I am writting this letter to you by out concern of having to pick
up a name for a new armel architecture variant optimized for hard
floating point, instead soft floating point.
Konstantinos (and I shall be also supporting him) is willing to
maintain a new architecture fo
I'd like to share approved contacts with you on Boxbe
Here's the link: https://www.boxbe.com/register?tc=3568600541_1371774368
-Mike
This message was sent at the request of genkstar...@yahoo.com.
If you want to opt-out of invitations from Boxbe members, use this link:
https://www.boxbe.com/
19 matches
Mail list logo
