From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/9] Switch internal registers address to 0xF1 on Armada 370/XP
Date: Fri, 24 May 2013 09:43:13 +0200 [thread overview]
Message-ID: <20130524094313.669ab838@skate> (raw)
In-Reply-To: <201305240915.27847.arnd@arndb.de>
Dear Arnd Bergmann,
On Fri, 24 May 2013 09:15:27 +0200, Arnd Bergmann wrote:
> But there is no problem on those boards /yet/. So far, the two boards
> always come with the known 0xd0 configuration that match the DTs
> we have, independent of where they come from.
>
> Thomas wants to be prepared for them to do something stupid, and he
> anticipates that they are going to do it in a particular way, but
> he says that he has no control over them, so it's all speculation
> at this point,
Speculation? The new bootloaders that change the address to 0xf1000000
are already shipping on all new Marvell evaluation platforms, they are
the ones currently available to Marvell customers for their
developments, and I'm running such a new bootloader on an evaluation
board.
I wouldn't call speculation something that I have in front of my eyes
today. But maybe we don't have the same definition of speculation.
> unless we do something stupid and change the dts
> files in the kernel to no longer match the current hardware.
You are again making the same mistake again. You make the association
between a given hardware platform and the location of the internal
registers, but this is completely false. Current OpenBlocks are shipped
with a old bootloader, but new OpenBlocks will most likely be shipped
with a new bootloader, or existing users of OpenBlocks may upgrade
their bootloader. So you can't make the assumption that OpenBlocks ==
old register address.
Again, we do *NOT* want to make this address configurable. All boards
should use 0xf1000000, and the kernel should assume that this a fixed
location for the internal registers.
All what we're trying to achieve here is to provide some temporary
workaround to help people using old bootloaders move smoothly to newer
bootloaders version without having a completely silent kernel at boot
time in the mean time.
So, while we are seeking for a workaround for a mistake of the past,
you are trying to force us to generalize the mechanism of customizing
the internal register address, which we do not want to do.
If all you're willing to accept is a very complex generalization of the
internal register base address handling, then I believe what we're
going to do is just move all Device Tree sources to use 0xf1, and we'll
tell users to upgrade their bootloader.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
next prev parent reply other threads:[~2013-05-24 7:43 UTC|newest]
Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-21 10:33 [PATCH 0/9] Switch internal registers address to 0xF1 on Armada 370/XP Thomas Petazzoni
2013-05-21 10:33 ` [PATCH 1/9] arm: mvebu: fix length of SATA registers area in .dtsi Thomas Petazzoni
2013-05-21 13:42 ` Jason Cooper
2013-05-21 10:33 ` [PATCH 2/9] arm: mvebu: fix length of Ethernet " Thomas Petazzoni
2013-05-21 13:43 ` Jason Cooper
2013-05-21 10:33 ` [PATCH 3/9] arm: mvebu: mark functions of armada-370-xp.c as static Thomas Petazzoni
2013-05-21 13:45 ` Jason Cooper
2013-05-21 10:33 ` [PATCH 4/9] arm: mvebu: remove dependency of SMP init on static I/O mapping Thomas Petazzoni
2013-05-21 10:33 ` [PATCH 5/9] arm: mvebu: avoid hardcoded virtual address in coherency code Thomas Petazzoni
2013-05-21 10:33 ` [PATCH 6/9] arm: mvebu: move cache and mvebu-mbus initialization later Thomas Petazzoni
2013-05-21 14:16 ` Jason Cooper
2013-05-21 15:37 ` Thomas Petazzoni
2013-05-21 15:43 ` Jason Cooper
2013-05-21 16:10 ` Thomas Petazzoni
2013-05-21 16:37 ` Jason Cooper
2013-05-21 16:44 ` Thomas Petazzoni
2013-05-21 10:33 ` [PATCH 7/9] arm: mvebu: remove hardcoded static I/O mapping Thomas Petazzoni
2013-05-21 10:33 ` [PATCH 8/9] arm: mvebu: don't hardcode a physical address in headsmp.S Thomas Petazzoni
2013-05-21 10:33 ` [PATCH 9/9] arm: mvebu: switch internal register address at runtime if needed Thomas Petazzoni
2013-05-22 13:27 ` Thomas Petazzoni
2013-05-22 14:04 ` Andrew Lunn
2013-05-22 14:16 ` Thomas Petazzoni
2013-05-22 14:17 ` Sebastian Hesselbarth
2013-05-22 17:42 ` Andrew Lunn
2013-05-22 17:59 ` Thomas Petazzoni
2013-05-22 18:31 ` Andrew Lunn
2013-05-21 19:38 ` [PATCH 0/9] Switch internal registers address to 0xF1 on Armada 370/XP Willy Tarreau
2013-05-21 20:12 ` Thomas Petazzoni
2013-05-21 20:26 ` Willy Tarreau
2013-05-22 10:01 ` Sebastian Hesselbarth
2013-05-22 11:46 ` Greg
2013-05-22 13:43 ` Russell King - ARM Linux
2013-05-22 13:52 ` Thomas Petazzoni
2013-05-22 14:11 ` Arnd Bergmann
2013-05-22 14:17 ` Russell King - ARM Linux
2013-05-22 14:23 ` Sebastian Hesselbarth
2013-05-22 14:33 ` Arnd Bergmann
2013-05-22 14:41 ` Gregory CLEMENT
2013-05-22 15:18 ` Arnd Bergmann
2013-05-22 15:37 ` Gregory CLEMENT
2013-05-22 15:43 ` Arnd Bergmann
2013-05-22 15:56 ` Gregory CLEMENT
2013-05-22 20:30 ` Arnd Bergmann
2013-05-22 15:06 ` Thomas Petazzoni
2013-05-22 15:35 ` Arnd Bergmann
2013-05-22 15:51 ` Andrew Lunn
2013-05-22 16:22 ` Thomas Petazzoni
2013-05-22 20:36 ` Arnd Bergmann
2013-05-23 10:02 ` Thomas Petazzoni
2013-05-23 14:12 ` Arnd Bergmann
2013-05-23 14:47 ` Thomas Petazzoni
2013-05-23 17:39 ` Arnd Bergmann
2013-05-22 16:08 ` Thomas Petazzoni
2013-05-22 16:35 ` Willy Tarreau
2013-05-22 16:42 ` Thomas Petazzoni
2013-05-22 16:49 ` Willy Tarreau
2013-05-22 17:00 ` Thomas Petazzoni
2013-05-22 17:08 ` Willy Tarreau
2013-05-22 17:14 ` Thomas Petazzoni
2013-05-22 20:47 ` Sebastian Hesselbarth
2013-05-22 16:49 ` Jason Cooper
2013-05-22 16:57 ` Thomas Petazzoni
2013-05-22 17:13 ` Jason Cooper
2013-05-22 18:05 ` Thomas Petazzoni
2013-05-22 18:09 ` Jason Cooper
2013-05-22 18:13 ` Thomas Petazzoni
2013-05-22 18:19 ` Jason Gunthorpe
2013-05-22 18:55 ` Andrew Lunn
2013-05-22 19:36 ` Jason Gunthorpe
2013-05-22 20:31 ` Andrew Lunn
2013-05-23 9:53 ` Thomas Petazzoni
2013-05-23 17:27 ` Jason Gunthorpe
2013-05-22 20:40 ` Arnd Bergmann
2013-05-22 21:31 ` Thomas Petazzoni
2013-05-23 5:53 ` Andrew Lunn
2013-05-23 7:53 ` Russell King - ARM Linux
2013-05-23 12:23 ` Thomas Petazzoni
2013-05-23 14:14 ` Arnd Bergmann
2013-05-23 14:50 ` Thomas Petazzoni
2013-05-23 20:26 ` Russell King - ARM Linux
2013-05-23 20:40 ` Arnd Bergmann
2013-05-23 23:09 ` Russell King - ARM Linux
2013-05-23 23:17 ` Thomas Petazzoni
2013-05-23 23:40 ` Russell King - ARM Linux
2013-05-24 10:25 ` Greg
2013-05-24 7:15 ` Arnd Bergmann
2013-05-24 7:43 ` Thomas Petazzoni [this message]
2013-05-24 9:16 ` Arnd Bergmann
2013-05-24 7:46 ` Russell King - ARM Linux
2013-05-24 8:07 ` Thomas Petazzoni
2013-05-24 10:57 ` Arnd Bergmann
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=20130524094313.669ab838@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).