All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: Matt Turner <mattst88@gmail.com>
Cc: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: Re: what is the purpose of the following LE->BE patch to arch/mips/include/asm/io.h?
Date: Sat, 21 Feb 2015 03:11:51 -0500 (EST)	[thread overview]
Message-ID: <alpine.LFD.2.11.1502210258580.5732@localhost> (raw)
In-Reply-To: <CAEdQ38F5jWX8Ujs4Jj6scxPAqtZw55gn4exL_rj9HCmf5YJgCA@mail.gmail.com>

On Fri, 20 Feb 2015, Matt Turner wrote:

> On Fri, Feb 20, 2015 at 8:00 PM, Matt Turner <mattst88@gmail.com> wrote:
> > On Fri, Feb 20, 2015 at 1:53 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> >>
> >>   was recently handed a MIPS-based dev board (can't name the vendor,
> >> NDA) that *typically* runs in LE mode but, because of a proprietary
> >> binary that must be run on the board and was compiled as BE, has to be
> >> run in BE mode.
> >>
> >>   the vendor supplied a yoctoproject layer that seems to work fine
> >> but, in changing the DEFAULTTUNE to big-endian, the following patch
> >> had to be applied to the 3.14 kernel tree to the file
> >> arch/mips/include/asm/io.h in order to get output from the console
> >> port as the system was booting:
> >>
> >> 326c326,333
> >> <               *__mem = __val;                                         \
> >> ---
> >>>       {                                                                               \
> >>>               if (sizeof(type) == sizeof(u32))                \
> >>>               {                                                                       \
> >>>                       *__mem = __cpu_to_le32(__val);  \
> >
> > They're byte swapping a value if they're in big endian mode.
> >
> >>>               }                                                                       \
> >>>               else                                                            \
> >>>                       *__mem = __val;                                         \
> >
> > And they don't seem to really understand the __cpu_to_le32 macro...
>
> Sorry, I should be more precise. They're byte swapping 32-bit values
> if they're in big endian mode, and copying everything else without
> conversion.

  i understand *in general* what the above is doing ... what i don't
understand is why it's necessary to hack a fundamental kernel header
file this way in order to run this board in BE versus LE mode.

  the kernel was already configured for BE mode, which i would have
thought would be sufficient, so it's a mystery to me why one would
still have to *further* hack the io.h file this way -- if the above is
a necessity, shouldn't it be a conditional change based on selecting
BE configuration?

  has anyone else ever needed to do this? or is this some weird,
one-off hack that perhaps applies *only* to some bizarre feature of
this board?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

  reply	other threads:[~2015-02-21  8:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-20  9:53 what is the purpose of the following LE->BE patch to arch/mips/include/asm/io.h? Robert P. J. Day
2015-02-21  4:00 ` Matt Turner
2015-02-21  4:04   ` Matt Turner
2015-02-21  8:11     ` Robert P. J. Day [this message]
2015-02-21  8:23       ` Manuel Lauss
2015-02-21  8:27         ` Robert P. J. Day
2015-02-21 20:00           ` Maciej W. Rozycki
2015-02-21 21:03 ` Kevin Cernekee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.11.1502210258580.5732@localhost \
    --to=rpjday@crashcourse.ca \
    --cc=linux-mips@linux-mips.org \
    --cc=mattst88@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.