On Thu, Apr 18, 2013 at 12:06:47PM -0700, Simon Glass wrote:
> Hi,
>
> On Thu, Apr 18, 2013 at 11:43 AM, Albert ARIBAUD
> wrote:
> > Hi Tom,
> >
> > On Thu, 18 Apr 2013 12:58:54 -0400, Tom Rini wrote:
> >
> >> On Thu, Apr 18, 2013 at 06:39:29PM +0200, Albert ARIBAUD wrote:
> >> > Hi Wolfgang,
>
Hi,
On Thu, Apr 18, 2013 at 11:43 AM, Albert ARIBAUD
wrote:
> Hi Tom,
>
> On Thu, 18 Apr 2013 12:58:54 -0400, Tom Rini wrote:
>
>> On Thu, Apr 18, 2013 at 06:39:29PM +0200, Albert ARIBAUD wrote:
>> > Hi Wolfgang,
>> >
>> > On Thu, 18 Apr 2013 16:39:09 +0200, Wolfgang Denk wrote:
>> >
>> > > > S
Hi Tom,
On Thu, 18 Apr 2013 12:58:54 -0400, Tom Rini wrote:
> On Thu, Apr 18, 2013 at 06:39:29PM +0200, Albert ARIBAUD wrote:
> > Hi Wolfgang,
> >
> > On Thu, 18 Apr 2013 16:39:09 +0200, Wolfgang Denk wrote:
> >
> > > > So how about changing the element type of output in the definition of
> >
On Thu, Apr 18, 2013 at 06:39:29PM +0200, Albert ARIBAUD wrote:
> Hi Wolfgang,
>
> On Thu, 18 Apr 2013 16:39:09 +0200, Wolfgang Denk wrote:
>
> > > So how about changing the element type of output in the definition of
> > > hash_func_ws, adapting the corresponding implementations sha1_csum_wd,
>
Hi Wolfgang,
On Thu, 18 Apr 2013 16:39:09 +0200, Wolfgang Denk wrote:
> > So how about changing the element type of output in the definition of
> > hash_func_ws, adapting the corresponding implementations sha1_csum_wd,
> > sha256_csum_wd and crc32_wd_buf, and adapting the output argument
> > of
Dear Albert,
In message <20130418131810.38c916b8@lilith> you wrote:
>
> > OK - and what about the other architectures that suffer from the same
> > issues?
>
> They should/could provide their own optimized versions, obviously.
Well, if this was a generally needed or even useful service, that
mi
Hi Wolfgang,
On Thu, 18 Apr 2013 12:36:00 +0200, Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
>
> In message <20130418082027.4b5ea191@lilith> you wrote:
> >
> > > #ifdef USE_HOSTCC
> > >crc = htobe32(crc);
> > >memcpy(output, &crc, sizeof(crc));
> > > #else
> > >crc = cpu_to_be32(cr
Dear Albert ARIBAUD,
In message <20130418082027.4b5ea191@lilith> you wrote:
>
> > #ifdef USE_HOSTCC
> >crc = htobe32(crc);
> >memcpy(output, &crc, sizeof(crc));
> > #else
> >crc = cpu_to_be32(crc);
> >put_unaligned(crc, (uint32_t *)output);
> > #endif
> >
> > This produces the sa
Hi Simon,
On Wed, 17 Apr 2013 13:59:48 -0700, Simon Glass
wrote:
> Hi Albert,
>
> On Wed, Apr 17, 2013 at 12:23 PM, Albert ARIBAUD
> wrote:
> > Hi Simon -- and sorry for the dupe.
> >
> > On Wed, 17 Apr 2013 11:28:07 -0700, Simon Glass
> > wrote:
> >
> >> I tried using:
> >>
> >> #ifdef USE_H
Hi Albert,
On Wed, Apr 17, 2013 at 12:23 PM, Albert ARIBAUD
wrote:
> Hi Simon -- and sorry for the dupe.
>
> On Wed, 17 Apr 2013 11:28:07 -0700, Simon Glass
> wrote:
>
>> I tried using:
>>
>> #ifdef USE_HOSTCC
>>crc = htobe32(crc);
>> #else
>>crc = cpu_to_be32(crc);
>> #endif
>>memcp
Hi Simon -- and sorry for the dupe.
On Wed, 17 Apr 2013 11:28:07 -0700, Simon Glass
wrote:
> I tried using:
>
> #ifdef USE_HOSTCC
>crc = htobe32(crc);
> #else
>crc = cpu_to_be32(crc);
> #endif
>memcpy(output, &crc, sizeof(crc));
>
>
> This is one instruction (4 bytes, 16%) smaller
Hi Wolfgang,
On Tue, Apr 16, 2013 at 10:40 PM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message
> you
> wrote:
>>
>> >> +#ifdef USE_HOSTCC
>> >> + crc = htobe32(crc);
>> >> memcpy(output, &crc, sizeof(crc));
>> >> +#else
>> >> + put_unaligned_be32(crc, output);
>> >> +#end
Dear Simon Glass,
In message
you wrote:
>
> >> +#ifdef USE_HOSTCC
> >> + crc = htobe32(crc);
> >> memcpy(output, &crc, sizeof(crc));
> >> +#else
> >> + put_unaligned_be32(crc, output);
> >> +#endif
> >
> > Why is this depending on USE_HOSTCC, and not on the endianess?
>
> We alwa
Hi Tom,
On Tue, Apr 16, 2013 at 4:00 PM, Tom Rini wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/16/2013 05:57 PM, Simon Glass wrote:
>> Hi Wolfgang,
>>
>> On Sat, Apr 6, 2013 at 12:04 AM, Wolfgang Denk wrote:
>>> Dear Simon Glass,
>>>
>>> In message <1365203470-9099-1-git-se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/16/2013 05:57 PM, Simon Glass wrote:
> Hi Wolfgang,
>
> On Sat, Apr 6, 2013 at 12:04 AM, Wolfgang Denk wrote:
>> Dear Simon Glass,
>>
>> In message <1365203470-9099-1-git-send-email-...@chromium.org>
>> you wrote:
>>> When crc32 is handled by
Hi Wolfgang,
On Sat, Apr 6, 2013 at 12:04 AM, Wolfgang Denk wrote:
> Dear Simon Glass,
>
> In message <1365203470-9099-1-git-send-email-...@chromium.org> you wrote:
>> When crc32 is handled by the hash library, it requires the data to be in
>> big-endian format, since it reads it byte-wise. Thus
Dear Simon Glass,
In message <1365203470-9099-1-git-send-email-...@chromium.org> you wrote:
> When crc32 is handled by the hash library, it requires the data to be in
> big-endian format, since it reads it byte-wise. Thus at present the 'crc32'
> command reports incorrect data. For example, previo
On Fri, Apr 05, 2013 at 04:11:10PM -0700, Simon Glass wrote:
> When crc32 is handled by the hash library, it requires the data to be in
> big-endian format, since it reads it byte-wise. Thus at present the 'crc32'
> command reports incorrect data. For example, previously we might see:
>
> Peach #
When crc32 is handled by the hash library, it requires the data to be in
big-endian format, since it reads it byte-wise. Thus at present the 'crc32'
command reports incorrect data. For example, previously we might see:
Peach # crc32 4000 100
CRC32 for 4000 ... 40ff ==> 0d968558
but in
19 matches
Mail list logo
