Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On 03/21/2013 10:31 PM, Arnd Bergmann wrote:
On Thursday 21 March 2013, Thomas Petazzoni wrote:
In the mean time can we do something like:
soc {
compatible = "simple-bus";
range =<...>;
[... all the peripherals ...]
};
with the range =<...> property converting the peripheral registers
base address (expressed as offsets in the reg =<...> properties of the
subnodes) into the absolute physical address?
Yes, that is what Rob suggested you do.
Thomas,
have a look at arch/arm/boot/dts/dove.dtsi, it uses ranges-property
and peripherals encoded as offsets.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On 03/21/2013 10:41 PM, Jason Gunthorpe wrote: On Thu, Mar 21, 2013 at 10:15:23PM +0100, Thomas Petazzoni wrote: Dear Jason Gunthorpe, On Thu, 21 Mar 2013 14:55:45 -0600, Jason Gunthorpe wrote: Or, better, locate all the internal registers above 8G and use contiguous DRAM mapping from 0 -> 8GB I see two potential issues with this idea: *) It only works when LPAE is enabled, so we would have to have different internal register addresses depending on whether LPAE is enabled or not. Probably not impossible, but not very straightforward either. Ideally the internal register space address would come from the DT - we are getting very close to that on Marvell, I think.. Things like earlyprintk should ideally early parse the DT, harder I know :( *) It would require Linux to change the internal registers address (for now the kernel relies on the bootloader). The problem is that we can't do it early enough to preserve the earlyprintk functionality. Maybe you have suggestions on how to achieve that? I can't forsee how Linux could do this reprogramming - not only do you have to move the registers, you'd also have to reprogram the DRAM bases, while running from the DRAM. Not only does that have to be done early, but the DT would need to describe the DRAM ranks, and the code would have to parse it.. On top of that it would have to be very careful not to wack any DRAM that has already been touched by the kernel.. Tricky stuff :) Jason, Lior, at least for Dove you are missing one important fact: The Internal Registers Base Address register is within ... the internal registers. You can't even look it up without knowing where it is. That doesn't mean we can parse the DT for the current register base address and move it to where we expect it. But for DRAM, I suggest not to mess with it. The boot loader is there for a reason. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On Thu, Mar 21, 2013 at 10:15:23PM +0100, Thomas Petazzoni wrote: > Dear Jason Gunthorpe, > > On Thu, 21 Mar 2013 14:55:45 -0600, Jason Gunthorpe wrote: > > > Or, better, locate all the internal registers above 8G and use > > contiguous DRAM mapping from 0 -> 8GB > > I see two potential issues with this idea: > > *) It only works when LPAE is enabled, so we would have to have > different internal register addresses depending on whether LPAE is > enabled or not. Probably not impossible, but not very > straightforward either. Ideally the internal register space address would come from the DT - we are getting very close to that on Marvell, I think.. Things like earlyprintk should ideally early parse the DT, harder I know :( > *) It would require Linux to change the internal registers address > (for now the kernel relies on the bootloader). The problem is that > we can't do it early enough to preserve the earlyprintk > functionality. Maybe you have suggestions on how to achieve that? I can't forsee how Linux could do this reprogramming - not only do you have to move the registers, you'd also have to reprogram the DRAM bases, while running from the DRAM. Not only does that have to be done early, but the DT would need to describe the DRAM ranks, and the code would have to parse it.. On top of that it would have to be very careful not to wack any DRAM that has already been touched by the kernel.. Tricky stuff :) Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On Thursday 21 March 2013, Thomas Petazzoni wrote:
> In the mean time can we do something like:
>
> soc {
> compatible = "simple-bus";
> range = <...>;
>
> [... all the peripherals ...]
> };
>
> with the range = <...> property converting the peripheral registers
> base address (expressed as offsets in the reg = <...> properties of the
> subnodes) into the absolute physical address?
Yes, that is what Rob suggested you do.
> I'm planning to work on the DT binding for the mvebu-mbus driver as
> soon as the PCIe driver gets accepted, but it would be good to have an
> intermediate solution to get the LPAE support in.
Sounds good.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
Dear Andrew Lunn, On Thu, 21 Mar 2013 21:37:51 +0100, Andrew Lunn wrote: > > And I'm not sure the SDRAM address decoding windows allows to split the > > first 4 GB of RAM into two areas, one that would be mapped starting at > > physical address 0x0, and another area that would be mapped at a > > different address (above 4 GB). > > So why not map the whole SDRAM above 4GB physical address? As Lior rightly pointed out to me, this would prevent any device from DMA-ing to or from the RAM. Devices can only access the first 32 bits of the physical address space. So there must be some RAM below 4 GB. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
Dear Jason Gunthorpe, On Thu, 21 Mar 2013 14:55:45 -0600, Jason Gunthorpe wrote: > Or, better, locate all the internal registers above 8G and use > contiguous DRAM mapping from 0 -> 8GB I see two potential issues with this idea: *) It only works when LPAE is enabled, so we would have to have different internal register addresses depending on whether LPAE is enabled or not. Probably not impossible, but not very straightforward either. *) It would require Linux to change the internal registers address (for now the kernel relies on the bootloader). The problem is that we can't do it early enough to preserve the earlyprintk functionality. Maybe you have suggestions on how to achieve that? Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
Dear Andrew Lunn, On Thu, 21 Mar 2013 21:37:51 +0100, Andrew Lunn wrote: > > And I'm not sure the SDRAM address decoding windows allows to split the > > first 4 GB of RAM into two areas, one that would be mapped starting at > > physical address 0x0, and another area that would be mapped at a > > different address (above 4 GB). > > So why not map the whole SDRAM above 4GB physical address? That's a good question. The problem is most likely that this would require to synchronize with U-Boot modifications, which is not easy to achieve. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On Thu, Mar 21, 2013 at 09:22:36PM +0100, Thomas Petazzoni wrote: > And I'm not sure the SDRAM address decoding windows allows to split the > first 4 GB of RAM into two areas, one that would be mapped starting at > physical address 0x0, and another area that would be mapped at a > different address (above 4 GB). On prior Marvell chips the SDRAM is mapped on a rank by rank basis, so each rank can be placed in DRAM properly. > However, I'm unsure why 0xC000 was chosen. Why not 0xD000, > where the internal registers currently start? Probably because the 8GB is composed of 4 2GB ranks and what was done is to map like this: Rank 0 -> 0 -> 0x8000 (2G) Rank 1 -> 0x08000 -> 0x0C000 (2G rank, 1G mapped) Rank 2 -> 0x1 -> 0x18000 Rank 3 -> 0x18000 -> 0x3 The ranks must be power of two sizes, and aligned to their size, so it isn't possible to get closer to 0xD000. To recover the lost RAM the entire rank would need to be located above 4G. Or, better, locate all the internal registers above 8G and use contiguous DRAM mapping from 0 -> 8GB Linux is sensitive to the ratio of high/low memory, if that gets too big it struggles, maximizing low memory is desirable - I assume ARM is basically the same as x86 in this regard? > So why not map the whole SDRAM above 4GB physical address? I think the no-MMU boot mode would break if this was done? Jason -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On Thu, Mar 21, 2013 at 09:22:36PM +0100, Thomas Petazzoni wrote: > Dear Andrew Lunn, > > On Thu, 21 Mar 2013 21:15:33 +0100, Andrew Lunn wrote: > > > Could you recommend a document which introduces LPAE. > > > > Only being able to address 7GB seems a bit odd to me. I kind of > > expected you set up the translation tables to map a page in the 32 bit > > address range to any arbitrary page in the 40 bit address range. So > > leaving 0xC000 to 0x in the 32bit address range clear is > > easy. But why do you loose space in the 40bit address range? > > translation tables convert virtual addresses to physical addresses. > Here, we are only talking about physical addresses. There is an overlap > between the physical addresses used by the RAM, and the physical > addresses at which I/O devices are visible. > > And I'm not sure the SDRAM address decoding windows allows to split the > first 4 GB of RAM into two areas, one that would be mapped starting at > physical address 0x0, and another area that would be mapped at a > different address (above 4 GB). So why not map the whole SDRAM above 4GB physical address? Thanks Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On Thu, Mar 21, 2013 at 09:22:36PM +0100, Thomas Petazzoni wrote: > Dear Andrew Lunn, > > On Thu, 21 Mar 2013 21:15:33 +0100, Andrew Lunn wrote: > > > Could you recommend a document which introduces LPAE. > > > > Only being able to address 7GB seems a bit odd to me. I kind of > > expected you set up the translation tables to map a page in the 32 bit > > address range to any arbitrary page in the 40 bit address range. So > > leaving 0xC000 to 0x in the 32bit address range clear is > > easy. But why do you loose space in the 40bit address range? > > translation tables convert virtual addresses to physical addresses. > Here, we are only talking about physical addresses. There is an overlap > between the physical addresses used by the RAM, and the physical > addresses at which I/O devices are visible. > > And I'm not sure the SDRAM address decoding windows allows to split the > first 4 GB of RAM into two areas, one that would be mapped starting at > physical address 0x0, and another area that would be mapped at a > different address (above 4 GB). > > However, I'm unsure why 0xC000 was chosen. Why not 0xD000, > where the internal registers currently start? I had the same question earlier but got distracted by other things. Thanks for bringing it up. Gregory, shouldn't this be 0xD000? thx, Jason. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
Dear Andrew Lunn, On Thu, 21 Mar 2013 21:15:33 +0100, Andrew Lunn wrote: > Could you recommend a document which introduces LPAE. > > Only being able to address 7GB seems a bit odd to me. I kind of > expected you set up the translation tables to map a page in the 32 bit > address range to any arbitrary page in the 40 bit address range. So > leaving 0xC000 to 0x in the 32bit address range clear is > easy. But why do you loose space in the 40bit address range? translation tables convert virtual addresses to physical addresses. Here, we are only talking about physical addresses. There is an overlap between the physical addresses used by the RAM, and the physical addresses at which I/O devices are visible. And I'm not sure the SDRAM address decoding windows allows to split the first 4 GB of RAM into two areas, one that would be mapped starting at physical address 0x0, and another area that would be mapped at a different address (above 4 GB). However, I'm unsure why 0xC000 was chosen. Why not 0xD000, where the internal registers currently start? Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
> /* > - * 4 GB of plug-in RAM modules by default but only 3GB > - * are visible, the amount of memory available can be > - * changed by the bootloader according the size of the > - * module actually plugged > + * 8 GB of plug-in RAM modules by default.The amount > + * of memory available can be changed by the > + * bootloader according the size of the module > + * actually plugged. Only 7GB are usable because > + * addresses from 0xC000 to 0x are used by > + * the internal registers of the SoC. >*/ > - reg = <0x 0xC000>; > + reg = <0x 0x 0x 0xC000>, > + <0x0001 0x 0x0001 0x>; > + Hi Gregory Could you recommend a document which introduces LPAE. Only being able to address 7GB seems a bit odd to me. I kind of expected you set up the translation tables to map a page in the 32 bit address range to any arbitrary page in the 40 bit address range. So leaving 0xC000 to 0x in the 32bit address range clear is easy. But why do you loose space in the 40bit address range? Thanks Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
Dear Arnd Bergmann,
On Thu, 21 Mar 2013 19:03:52 +, Arnd Bergmann wrote:
> On Thursday 21 March 2013, Rob Herring wrote:
> > > soc {
> > > - #address-cells = <1>;
> > > - #size-cells = <1>;
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> >
> > If all the addresses for the soc bus are below 4GB or even within a 4GB
> > range if using the ranges property, then changing all this and
> > everything below it is kind of pointless.
>
> Good point. We'll probably also have to change it all again when we add a new
> binding for that bus in 3.10, so it makes sense to change it only once.
In the mean time can we do something like:
soc {
compatible = "simple-bus";
range = <...>;
[... all the peripherals ...]
};
with the range = <...> property converting the peripheral registers
base address (expressed as offsets in the reg = <...> properties of the
subnodes) into the absolute physical address?
I'm planning to work on the DT binding for the mvebu-mbus driver as
soon as the PCIe driver gets accepted, but it would be good to have an
intermediate solution to get the LPAE support in.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On Thursday 21 March 2013, Rob Herring wrote:
> > soc {
> > - #address-cells = <1>;
> > - #size-cells = <1>;
> > + #address-cells = <2>;
> > + #size-cells = <2>;
>
> If all the addresses for the soc bus are below 4GB or even within a 4GB
> range if using the ranges property, then changing all this and
> everything below it is kind of pointless.
Good point. We'll probably also have to change it all again when we add a new
binding for that bus in 3.10, so it makes sense to change it only once.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On 03/21/2013 11:26 AM, Gregory CLEMENT wrote:
> In order to be able to use more than 4GB of RAM when the LPAE is
> activated, the dts must be converted in 64 bits.
>
> Armada XP and Armada 370 share a dtsi file which have also be
> converted to 64 bits. This lead to convert all the device tree files
> to 64 bits even the one used for Armada 370 (which don't support
> LPAE)
>
> This was heavily based on the work of Lior Amsalem.
>
> Signed-off-by: Lior Amsalem
> Signed-off-by: Gregory CLEMENT
[snip]
> diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
> b/arch/arm/boot/dts/armada-370-xp.dtsi
> index 5b70820..562f24c 100644
> --- a/arch/arm/boot/dts/armada-370-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-370-xp.dtsi
> @@ -15,8 +15,7 @@
> * This file contains the definitions that are common to the Armada
> * 370 and Armada XP SoC.
> */
> -
> -/include/ "skeleton.dtsi"
> +/include/ "skeleton64.dtsi"
>
> / {
> model = "Marvell Armada 370 and XP SoC";
> @@ -37,20 +36,20 @@
>
> coherency-fabric@d0020200 {
> compatible = "marvell,coherency-fabric";
> - reg = <0xd0020200 0xb0>,
> - <0xd0021810 0x1c>;
> + reg = <0 0xd0020200 0 0xb0>,
> + <0 0xd0021810 0 0x1c>;
> };
>
> soc {
> - #address-cells = <1>;
> - #size-cells = <1>;
> + #address-cells = <2>;
> + #size-cells = <2>;
If all the addresses for the soc bus are below 4GB or even within a 4GB
range if using the ranges property, then changing all this and
everything below it is kind of pointless.
Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On 03/21/2013 11:26 AM, Gregory CLEMENT wrote:
In order to be able to use more than 4GB of RAM when the LPAE is
activated, the dts must be converted in 64 bits.
Armada XP and Armada 370 share a dtsi file which have also be
converted to 64 bits. This lead to convert all the device tree files
to 64 bits even the one used for Armada 370 (which don't support
LPAE)
This was heavily based on the work of Lior Amsalem.
Signed-off-by: Lior Amsalem al...@marvell.com
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
[snip]
diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 5b70820..562f24c 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -15,8 +15,7 @@
* This file contains the definitions that are common to the Armada
* 370 and Armada XP SoC.
*/
-
-/include/ skeleton.dtsi
+/include/ skeleton64.dtsi
/ {
model = Marvell Armada 370 and XP SoC;
@@ -37,20 +36,20 @@
coherency-fabric@d0020200 {
compatible = marvell,coherency-fabric;
- reg = 0xd0020200 0xb0,
- 0xd0021810 0x1c;
+ reg = 0 0xd0020200 0 0xb0,
+ 0 0xd0021810 0 0x1c;
};
soc {
- #address-cells = 1;
- #size-cells = 1;
+ #address-cells = 2;
+ #size-cells = 2;
If all the addresses for the soc bus are below 4GB or even within a 4GB
range if using the ranges property, then changing all this and
everything below it is kind of pointless.
Rob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On Thursday 21 March 2013, Rob Herring wrote:
soc {
- #address-cells = 1;
- #size-cells = 1;
+ #address-cells = 2;
+ #size-cells = 2;
If all the addresses for the soc bus are below 4GB or even within a 4GB
range if using the ranges property, then changing all this and
everything below it is kind of pointless.
Good point. We'll probably also have to change it all again when we add a new
binding for that bus in 3.10, so it makes sense to change it only once.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
Dear Arnd Bergmann,
On Thu, 21 Mar 2013 19:03:52 +, Arnd Bergmann wrote:
On Thursday 21 March 2013, Rob Herring wrote:
soc {
- #address-cells = 1;
- #size-cells = 1;
+ #address-cells = 2;
+ #size-cells = 2;
If all the addresses for the soc bus are below 4GB or even within a 4GB
range if using the ranges property, then changing all this and
everything below it is kind of pointless.
Good point. We'll probably also have to change it all again when we add a new
binding for that bus in 3.10, so it makes sense to change it only once.
In the mean time can we do something like:
soc {
compatible = simple-bus;
range = ...;
[... all the peripherals ...]
};
with the range = ... property converting the peripheral registers
base address (expressed as offsets in the reg = ... properties of the
subnodes) into the absolute physical address?
I'm planning to work on the DT binding for the mvebu-mbus driver as
soon as the PCIe driver gets accepted, but it would be good to have an
intermediate solution to get the LPAE support in.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
/* - * 4 GB of plug-in RAM modules by default but only 3GB - * are visible, the amount of memory available can be - * changed by the bootloader according the size of the - * module actually plugged + * 8 GB of plug-in RAM modules by default.The amount + * of memory available can be changed by the + * bootloader according the size of the module + * actually plugged. Only 7GB are usable because + * addresses from 0xC000 to 0x are used by + * the internal registers of the SoC. */ - reg = 0x 0xC000; + reg = 0x 0x 0x 0xC000, + 0x0001 0x 0x0001 0x; + Hi Gregory Could you recommend a document which introduces LPAE. Only being able to address 7GB seems a bit odd to me. I kind of expected you set up the translation tables to map a page in the 32 bit address range to any arbitrary page in the 40 bit address range. So leaving 0xC000 to 0x in the 32bit address range clear is easy. But why do you loose space in the 40bit address range? Thanks Andrew -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
Dear Andrew Lunn, On Thu, 21 Mar 2013 21:15:33 +0100, Andrew Lunn wrote: Could you recommend a document which introduces LPAE. Only being able to address 7GB seems a bit odd to me. I kind of expected you set up the translation tables to map a page in the 32 bit address range to any arbitrary page in the 40 bit address range. So leaving 0xC000 to 0x in the 32bit address range clear is easy. But why do you loose space in the 40bit address range? translation tables convert virtual addresses to physical addresses. Here, we are only talking about physical addresses. There is an overlap between the physical addresses used by the RAM, and the physical addresses at which I/O devices are visible. And I'm not sure the SDRAM address decoding windows allows to split the first 4 GB of RAM into two areas, one that would be mapped starting at physical address 0x0, and another area that would be mapped at a different address (above 4 GB). However, I'm unsure why 0xC000 was chosen. Why not 0xD000, where the internal registers currently start? Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On Thu, Mar 21, 2013 at 09:22:36PM +0100, Thomas Petazzoni wrote: Dear Andrew Lunn, On Thu, 21 Mar 2013 21:15:33 +0100, Andrew Lunn wrote: Could you recommend a document which introduces LPAE. Only being able to address 7GB seems a bit odd to me. I kind of expected you set up the translation tables to map a page in the 32 bit address range to any arbitrary page in the 40 bit address range. So leaving 0xC000 to 0x in the 32bit address range clear is easy. But why do you loose space in the 40bit address range? translation tables convert virtual addresses to physical addresses. Here, we are only talking about physical addresses. There is an overlap between the physical addresses used by the RAM, and the physical addresses at which I/O devices are visible. And I'm not sure the SDRAM address decoding windows allows to split the first 4 GB of RAM into two areas, one that would be mapped starting at physical address 0x0, and another area that would be mapped at a different address (above 4 GB). However, I'm unsure why 0xC000 was chosen. Why not 0xD000, where the internal registers currently start? I had the same question earlier but got distracted by other things. Thanks for bringing it up. Gregory, shouldn't this be 0xD000? thx, Jason. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On Thu, Mar 21, 2013 at 09:22:36PM +0100, Thomas Petazzoni wrote: Dear Andrew Lunn, On Thu, 21 Mar 2013 21:15:33 +0100, Andrew Lunn wrote: Could you recommend a document which introduces LPAE. Only being able to address 7GB seems a bit odd to me. I kind of expected you set up the translation tables to map a page in the 32 bit address range to any arbitrary page in the 40 bit address range. So leaving 0xC000 to 0x in the 32bit address range clear is easy. But why do you loose space in the 40bit address range? translation tables convert virtual addresses to physical addresses. Here, we are only talking about physical addresses. There is an overlap between the physical addresses used by the RAM, and the physical addresses at which I/O devices are visible. And I'm not sure the SDRAM address decoding windows allows to split the first 4 GB of RAM into two areas, one that would be mapped starting at physical address 0x0, and another area that would be mapped at a different address (above 4 GB). So why not map the whole SDRAM above 4GB physical address? Thanks Andrew -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On Thu, Mar 21, 2013 at 09:22:36PM +0100, Thomas Petazzoni wrote: And I'm not sure the SDRAM address decoding windows allows to split the first 4 GB of RAM into two areas, one that would be mapped starting at physical address 0x0, and another area that would be mapped at a different address (above 4 GB). On prior Marvell chips the SDRAM is mapped on a rank by rank basis, so each rank can be placed in DRAM properly. However, I'm unsure why 0xC000 was chosen. Why not 0xD000, where the internal registers currently start? Probably because the 8GB is composed of 4 2GB ranks and what was done is to map like this: Rank 0 - 0 - 0x8000 (2G) Rank 1 - 0x08000 - 0x0C000 (2G rank, 1G mapped) Rank 2 - 0x1 - 0x18000 Rank 3 - 0x18000 - 0x3 The ranks must be power of two sizes, and aligned to their size, so it isn't possible to get closer to 0xD000. To recover the lost RAM the entire rank would need to be located above 4G. Or, better, locate all the internal registers above 8G and use contiguous DRAM mapping from 0 - 8GB Linux is sensitive to the ratio of high/low memory, if that gets too big it struggles, maximizing low memory is desirable - I assume ARM is basically the same as x86 in this regard? So why not map the whole SDRAM above 4GB physical address? I think the no-MMU boot mode would break if this was done? Jason -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
Dear Andrew Lunn, On Thu, 21 Mar 2013 21:37:51 +0100, Andrew Lunn wrote: And I'm not sure the SDRAM address decoding windows allows to split the first 4 GB of RAM into two areas, one that would be mapped starting at physical address 0x0, and another area that would be mapped at a different address (above 4 GB). So why not map the whole SDRAM above 4GB physical address? That's a good question. The problem is most likely that this would require to synchronize with U-Boot modifications, which is not easy to achieve. Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
Dear Jason Gunthorpe, On Thu, 21 Mar 2013 14:55:45 -0600, Jason Gunthorpe wrote: Or, better, locate all the internal registers above 8G and use contiguous DRAM mapping from 0 - 8GB I see two potential issues with this idea: *) It only works when LPAE is enabled, so we would have to have different internal register addresses depending on whether LPAE is enabled or not. Probably not impossible, but not very straightforward either. *) It would require Linux to change the internal registers address (for now the kernel relies on the bootloader). The problem is that we can't do it early enough to preserve the earlyprintk functionality. Maybe you have suggestions on how to achieve that? Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
Dear Andrew Lunn, On Thu, 21 Mar 2013 21:37:51 +0100, Andrew Lunn wrote: And I'm not sure the SDRAM address decoding windows allows to split the first 4 GB of RAM into two areas, one that would be mapped starting at physical address 0x0, and another area that would be mapped at a different address (above 4 GB). So why not map the whole SDRAM above 4GB physical address? As Lior rightly pointed out to me, this would prevent any device from DMA-ing to or from the RAM. Devices can only access the first 32 bits of the physical address space. So there must be some RAM below 4 GB. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On Thursday 21 March 2013, Thomas Petazzoni wrote:
In the mean time can we do something like:
soc {
compatible = simple-bus;
range = ...;
[... all the peripherals ...]
};
with the range = ... property converting the peripheral registers
base address (expressed as offsets in the reg = ... properties of the
subnodes) into the absolute physical address?
Yes, that is what Rob suggested you do.
I'm planning to work on the DT binding for the mvebu-mbus driver as
soon as the PCIe driver gets accepted, but it would be good to have an
intermediate solution to get the LPAE support in.
Sounds good.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On Thu, Mar 21, 2013 at 10:15:23PM +0100, Thomas Petazzoni wrote: Dear Jason Gunthorpe, On Thu, 21 Mar 2013 14:55:45 -0600, Jason Gunthorpe wrote: Or, better, locate all the internal registers above 8G and use contiguous DRAM mapping from 0 - 8GB I see two potential issues with this idea: *) It only works when LPAE is enabled, so we would have to have different internal register addresses depending on whether LPAE is enabled or not. Probably not impossible, but not very straightforward either. Ideally the internal register space address would come from the DT - we are getting very close to that on Marvell, I think.. Things like earlyprintk should ideally early parse the DT, harder I know :( *) It would require Linux to change the internal registers address (for now the kernel relies on the bootloader). The problem is that we can't do it early enough to preserve the earlyprintk functionality. Maybe you have suggestions on how to achieve that? I can't forsee how Linux could do this reprogramming - not only do you have to move the registers, you'd also have to reprogram the DRAM bases, while running from the DRAM. Not only does that have to be done early, but the DT would need to describe the DRAM ranks, and the code would have to parse it.. On top of that it would have to be very careful not to wack any DRAM that has already been touched by the kernel.. Tricky stuff :) Jason -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On 03/21/2013 10:41 PM, Jason Gunthorpe wrote: On Thu, Mar 21, 2013 at 10:15:23PM +0100, Thomas Petazzoni wrote: Dear Jason Gunthorpe, On Thu, 21 Mar 2013 14:55:45 -0600, Jason Gunthorpe wrote: Or, better, locate all the internal registers above 8G and use contiguous DRAM mapping from 0 - 8GB I see two potential issues with this idea: *) It only works when LPAE is enabled, so we would have to have different internal register addresses depending on whether LPAE is enabled or not. Probably not impossible, but not very straightforward either. Ideally the internal register space address would come from the DT - we are getting very close to that on Marvell, I think.. Things like earlyprintk should ideally early parse the DT, harder I know :( *) It would require Linux to change the internal registers address (for now the kernel relies on the bootloader). The problem is that we can't do it early enough to preserve the earlyprintk functionality. Maybe you have suggestions on how to achieve that? I can't forsee how Linux could do this reprogramming - not only do you have to move the registers, you'd also have to reprogram the DRAM bases, while running from the DRAM. Not only does that have to be done early, but the DT would need to describe the DRAM ranks, and the code would have to parse it.. On top of that it would have to be very careful not to wack any DRAM that has already been touched by the kernel.. Tricky stuff :) Jason, Lior, at least for Dove you are missing one important fact: The Internal Registers Base Address register is within ... the internal registers. You can't even look it up without knowing where it is. That doesn't mean we can parse the DT for the current register base address and move it to where we expect it. But for DRAM, I suggest not to mess with it. The boot loader is there for a reason. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: dts: Convert mvebu device tree files to 64 bits
On 03/21/2013 10:31 PM, Arnd Bergmann wrote:
On Thursday 21 March 2013, Thomas Petazzoni wrote:
In the mean time can we do something like:
soc {
compatible = simple-bus;
range =...;
[... all the peripherals ...]
};
with the range =... property converting the peripheral registers
base address (expressed as offsets in the reg =... properties of the
subnodes) into the absolute physical address?
Yes, that is what Rob suggested you do.
Thomas,
have a look at arch/arm/boot/dts/dove.dtsi, it uses ranges-property
and peripherals encoded as offsets.
Sebastian
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
