* [PATCH 1/8] ARM: MMU: add zero_page_{access,faulting}
2020-11-09 13:44 [PATCH 0/8] QEMU virt machine support via mach-vexpress Rouven Czerwinski
@ 2020-11-09 13:44 ` Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping Rouven Czerwinski
` (7 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Rouven Czerwinski @ 2020-11-09 13:44 UTC (permalink / raw)
To: barebox; +Cc: Rouven Czerwinski
On the qemu virt machine, the cfi flash is mapped at 0x0.
Therefore implement zero_page_{access,faulting} to allow usage of the
cfi_flash driver on this machine.
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
arch/arm/cpu/Kconfig | 1 -
arch/arm/cpu/mmu.c | 13 +++++++++++++
include/zero_page.h | 14 --------------
lib/Kconfig | 3 ---
4 files changed, 13 insertions(+), 18 deletions(-)
diff --git a/arch/arm/cpu/Kconfig b/arch/arm/cpu/Kconfig
index ca3bd98962..f9f52a6252 100644
--- a/arch/arm/cpu/Kconfig
+++ b/arch/arm/cpu/Kconfig
@@ -89,7 +89,6 @@ config CPU_V8
select ARM_EXCEPTIONS
select GENERIC_FIND_NEXT_BIT
select ARCH_HAS_STACK_DUMP
- select ARCH_HAS_ZERO_PAGE
config CPU_XSC3
bool
diff --git a/arch/arm/cpu/mmu.c b/arch/arm/cpu/mmu.c
index 6af228505d..bfb8eab5f5 100644
--- a/arch/arm/cpu/mmu.c
+++ b/arch/arm/cpu/mmu.c
@@ -17,6 +17,7 @@
#include <memory.h>
#include <asm/system_info.h>
#include <asm/sections.h>
+#include <zero_page.h>
#include "mmu.h"
@@ -354,6 +355,18 @@ static void create_zero_page(void)
}
}
+void zero_page_access(void)
+{
+ arm_create_pte(0x0, pte_flags_cached);
+}
+
+void zero_page_faulting(void)
+{
+ u32 *zero;
+ zero = arm_create_pte(0x0, pte_flags_uncached);
+ zero[0] = 0;
+}
+
/*
* Map vectors and zero page
*/
diff --git a/include/zero_page.h b/include/zero_page.h
index ad6861f240..b0efb814db 100644
--- a/include/zero_page.h
+++ b/include/zero_page.h
@@ -4,8 +4,6 @@
#include <common.h>
-#if defined CONFIG_ARCH_HAS_ZERO_PAGE
-
/*
* zero_page_faulting - fault when accessing the zero page
*/
@@ -20,18 +18,6 @@ void zero_page_faulting(void);
*/
void zero_page_access(void);
-#else
-
-static inline void zero_page_faulting(void)
-{
-}
-
-static inline void zero_page_access(void)
-{
-}
-
-#endif
-
static inline bool zero_page_contains(unsigned long addr)
{
return addr < PAGE_SIZE;
diff --git a/lib/Kconfig b/lib/Kconfig
index e5831ecdb9..887f50ff00 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -182,9 +182,6 @@ config ARCH_HAS_STACK_DUMP
config ARCH_HAS_DATA_ABORT_MASK
bool
-config ARCH_HAS_ZERO_PAGE
- bool
-
config HAVE_EFFICIENT_UNALIGNED_ACCESS
bool
--
2.28.0
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping
2020-11-09 13:44 [PATCH 0/8] QEMU virt machine support via mach-vexpress Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 1/8] ARM: MMU: add zero_page_{access,faulting} Rouven Czerwinski
@ 2020-11-09 13:44 ` Rouven Czerwinski
2020-11-09 13:52 ` Lucas Stach
2020-11-09 13:44 ` [PATCH 3/8] amba: add *_amba_driver helper macros Rouven Czerwinski
` (6 subsequent siblings)
8 siblings, 1 reply; 18+ messages in thread
From: Rouven Czerwinski @ 2020-11-09 13:44 UTC (permalink / raw)
To: barebox; +Cc: Rouven Czerwinski
Annotate the different read and write functions with
zero_page_{access/faulting}. This allows the cfi_flash driver to be used
on the QEMU virt machine with an enabled MMU.
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
drivers/mtd/nor/cfi_flash.c | 6 ++++++
drivers/mtd/nor/cfi_flash.h | 18 ++++++++++++++++++
2 files changed, 24 insertions(+)
diff --git a/drivers/mtd/nor/cfi_flash.c b/drivers/mtd/nor/cfi_flash.c
index 225b03ec3d..2fcbd13e46 100644
--- a/drivers/mtd/nor/cfi_flash.c
+++ b/drivers/mtd/nor/cfi_flash.c
@@ -896,8 +896,10 @@ static int cfi_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
{
struct flash_info *info = container_of(mtd, struct flash_info, mtd);
+ zero_page_access();
memcpy(buf, info->base + from, len);
*retlen = len;
+ zero_page_faulting();
return 0;
}
@@ -908,7 +910,9 @@ static int cfi_mtd_write(struct mtd_info *mtd, loff_t to, size_t len,
struct flash_info *info = container_of(mtd, struct flash_info, mtd);
int ret;
+ zero_page_access();
ret = write_buff(info, buf, (unsigned long)info->base + to, len);
+ zero_page_faulting();
*retlen = len;
return ret;
@@ -919,7 +923,9 @@ static int cfi_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
struct flash_info *info = container_of(mtd, struct flash_info, mtd);
int ret;
+ zero_page_access();
ret = cfi_erase(info, instr->len, instr->addr);
+ zero_page_faulting();
if (ret)
return -EIO;
diff --git a/drivers/mtd/nor/cfi_flash.h b/drivers/mtd/nor/cfi_flash.h
index cea6a8712c..99359a325e 100644
--- a/drivers/mtd/nor/cfi_flash.h
+++ b/drivers/mtd/nor/cfi_flash.h
@@ -22,6 +22,8 @@
#include <io.h>
#include <linux/mtd/mtd.h>
+#include <zero_page.h>
+
typedef unsigned long flash_sect_t;
#if defined(CONFIG_DRIVER_CFI_BANK_WIDTH_8)
@@ -255,43 +257,59 @@ void flash_make_cmd(struct flash_info *info, u32 cmd, cfiword_t *cmdbuf);
static inline void flash_write8(u8 value, void *addr)
{
+ zero_page_access();
__raw_writeb(value, addr);
+ zero_page_faulting();
}
static inline void flash_write16(u16 value, void *addr)
{
+ zero_page_access();
__raw_writew(value, addr);
+ zero_page_faulting();
}
static inline void flash_write32(u32 value, void *addr)
{
+ zero_page_access();
__raw_writel(value, addr);
+ zero_page_faulting();
}
static inline void flash_write64(u64 value, void *addr)
{
+ zero_page_access();
memcpy((void *)addr, &value, 8);
+ zero_page_faulting();
}
static inline u8 flash_read8(void *addr)
{
+ zero_page_access();
return __raw_readb(addr);
+ zero_page_faulting();
}
static inline u16 flash_read16(void *addr)
{
+ zero_page_access();
return __raw_readw(addr);
+ zero_page_faulting();
}
static inline u32 flash_read32(void *addr)
{
+ zero_page_access();
return __raw_readl(addr);
+ zero_page_faulting();
}
static inline u64 flash_read64(void *addr)
{
+ zero_page_access();
/* No architectures currently implement readq() */
return *(volatile u64 *)addr;
+ zero_page_faulting();
}
/*
--
2.28.0
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping
2020-11-09 13:44 ` [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping Rouven Czerwinski
@ 2020-11-09 13:52 ` Lucas Stach
2020-11-10 6:33 ` Rouven Czerwinski
0 siblings, 1 reply; 18+ messages in thread
From: Lucas Stach @ 2020-11-09 13:52 UTC (permalink / raw)
To: Rouven Czerwinski, barebox
Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven Czerwinski:
> Annotate the different read and write functions with
> zero_page_{access/faulting}. This allows the cfi_flash driver to be used
> on the QEMU virt machine with an enabled MMU.
I don't like this zero-page access allow in a driver at all. If you
have some free address space somewhere, you could also solve this issue
by remapping the IO resource to somewhere else in the address space,
deviating from the 1:1 mapping. The Tegra PCIe host driver does this,
if you need some inspiration.
Regards,
Lucas
> Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
> ---
> drivers/mtd/nor/cfi_flash.c | 6 ++++++
> drivers/mtd/nor/cfi_flash.h | 18 ++++++++++++++++++
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/mtd/nor/cfi_flash.c b/drivers/mtd/nor/cfi_flash.c
> index 225b03ec3d..2fcbd13e46 100644
> --- a/drivers/mtd/nor/cfi_flash.c
> +++ b/drivers/mtd/nor/cfi_flash.c
> @@ -896,8 +896,10 @@ static int cfi_mtd_read(struct mtd_info *mtd, loff_t from, size_t len,
> {
> struct flash_info *info = container_of(mtd, struct flash_info, mtd);
>
> + zero_page_access();
> memcpy(buf, info->base + from, len);
> *retlen = len;
> + zero_page_faulting();
>
> return 0;
> }
> @@ -908,7 +910,9 @@ static int cfi_mtd_write(struct mtd_info *mtd, loff_t to, size_t len,
> struct flash_info *info = container_of(mtd, struct flash_info, mtd);
> int ret;
>
> + zero_page_access();
> ret = write_buff(info, buf, (unsigned long)info->base + to, len);
> + zero_page_faulting();
> *retlen = len;
>
> return ret;
> @@ -919,7 +923,9 @@ static int cfi_mtd_erase(struct mtd_info *mtd, struct erase_info *instr)
> struct flash_info *info = container_of(mtd, struct flash_info, mtd);
> int ret;
>
> + zero_page_access();
> ret = cfi_erase(info, instr->len, instr->addr);
> + zero_page_faulting();
> if (ret)
> return -EIO;
>
> diff --git a/drivers/mtd/nor/cfi_flash.h b/drivers/mtd/nor/cfi_flash.h
> index cea6a8712c..99359a325e 100644
> --- a/drivers/mtd/nor/cfi_flash.h
> +++ b/drivers/mtd/nor/cfi_flash.h
> @@ -22,6 +22,8 @@
> #include <io.h>
> #include <linux/mtd/mtd.h>
>
> +#include <zero_page.h>
> +
> typedef unsigned long flash_sect_t;
>
> #if defined(CONFIG_DRIVER_CFI_BANK_WIDTH_8)
> @@ -255,43 +257,59 @@ void flash_make_cmd(struct flash_info *info, u32 cmd, cfiword_t *cmdbuf);
>
> static inline void flash_write8(u8 value, void *addr)
> {
> + zero_page_access();
> __raw_writeb(value, addr);
> + zero_page_faulting();
> }
>
> static inline void flash_write16(u16 value, void *addr)
> {
> + zero_page_access();
> __raw_writew(value, addr);
> + zero_page_faulting();
> }
>
> static inline void flash_write32(u32 value, void *addr)
> {
> + zero_page_access();
> __raw_writel(value, addr);
> + zero_page_faulting();
> }
>
> static inline void flash_write64(u64 value, void *addr)
> {
> + zero_page_access();
> memcpy((void *)addr, &value, 8);
> + zero_page_faulting();
> }
>
> static inline u8 flash_read8(void *addr)
> {
> + zero_page_access();
> return __raw_readb(addr);
> + zero_page_faulting();
> }
>
> static inline u16 flash_read16(void *addr)
> {
> + zero_page_access();
> return __raw_readw(addr);
> + zero_page_faulting();
> }
>
> static inline u32 flash_read32(void *addr)
> {
> + zero_page_access();
> return __raw_readl(addr);
> + zero_page_faulting();
> }
>
> static inline u64 flash_read64(void *addr)
> {
> + zero_page_access();
> /* No architectures currently implement readq() */
> return *(volatile u64 *)addr;
> + zero_page_faulting();
> }
>
> /*
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping
2020-11-09 13:52 ` Lucas Stach
@ 2020-11-10 6:33 ` Rouven Czerwinski
2020-11-10 7:48 ` Sascha Hauer
0 siblings, 1 reply; 18+ messages in thread
From: Rouven Czerwinski @ 2020-11-10 6:33 UTC (permalink / raw)
To: Lucas Stach, barebox
On Mon, 2020-11-09 at 14:52 +0100, Lucas Stach wrote:
> Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven Czerwinski:
> > Annotate the different read and write functions with
> > zero_page_{access/faulting}. This allows the cfi_flash driver to be used
> > on the QEMU virt machine with an enabled MMU.
>
> I don't like this zero-page access allow in a driver at all. If you
> have some free address space somewhere, you could also solve this issue
> by remapping the IO resource to somewhere else in the address space,
> deviating from the 1:1 mapping. The Tegra PCIe host driver does this,
> if you need some inspiration.
I totally agree, remapping the IO region sounds like a much better
choice.
Regards,
Rouven
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping
2020-11-10 6:33 ` Rouven Czerwinski
@ 2020-11-10 7:48 ` Sascha Hauer
2020-11-10 9:15 ` Sascha Hauer
0 siblings, 1 reply; 18+ messages in thread
From: Sascha Hauer @ 2020-11-10 7:48 UTC (permalink / raw)
To: Rouven Czerwinski; +Cc: barebox
On Tue, Nov 10, 2020 at 07:33:53AM +0100, Rouven Czerwinski wrote:
> On Mon, 2020-11-09 at 14:52 +0100, Lucas Stach wrote:
> > Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven Czerwinski:
> > > Annotate the different read and write functions with
> > > zero_page_{access/faulting}. This allows the cfi_flash driver to be used
> > > on the QEMU virt machine with an enabled MMU.
> >
> > I don't like this zero-page access allow in a driver at all. If you
> > have some free address space somewhere, you could also solve this issue
> > by remapping the IO resource to somewhere else in the address space,
> > deviating from the 1:1 mapping. The Tegra PCIe host driver does this,
> > if you need some inspiration.
>
> I totally agree, remapping the IO region sounds like a much better
> choice.
But where should it be mapped to? Just 4k upwards and hope that the area
just above the cfi flash isn't occupied by something else?
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping
2020-11-10 7:48 ` Sascha Hauer
@ 2020-11-10 9:15 ` Sascha Hauer
2020-11-10 9:36 ` Ahmad Fatoum
0 siblings, 1 reply; 18+ messages in thread
From: Sascha Hauer @ 2020-11-10 9:15 UTC (permalink / raw)
To: Rouven Czerwinski; +Cc: barebox
On Tue, Nov 10, 2020 at 08:48:11AM +0100, Sascha Hauer wrote:
> On Tue, Nov 10, 2020 at 07:33:53AM +0100, Rouven Czerwinski wrote:
> > On Mon, 2020-11-09 at 14:52 +0100, Lucas Stach wrote:
> > > Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven Czerwinski:
> > > > Annotate the different read and write functions with
> > > > zero_page_{access/faulting}. This allows the cfi_flash driver to be used
> > > > on the QEMU virt machine with an enabled MMU.
> > >
> > > I don't like this zero-page access allow in a driver at all. If you
> > > have some free address space somewhere, you could also solve this issue
> > > by remapping the IO resource to somewhere else in the address space,
> > > deviating from the 1:1 mapping. The Tegra PCIe host driver does this,
> > > if you need some inspiration.
> >
> > I totally agree, remapping the IO region sounds like a much better
> > choice.
>
> But where should it be mapped to? Just 4k upwards and hope that the area
> just above the cfi flash isn't occupied by something else?
Ok, here's the plan:
In a board specific initcall map the memory to wherever it's convenient,
modify the address of the CFI flash in the device node and add a big
comment that there's nothing to see here.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping
2020-11-10 9:15 ` Sascha Hauer
@ 2020-11-10 9:36 ` Ahmad Fatoum
2020-11-10 9:43 ` Ahmad Fatoum
0 siblings, 1 reply; 18+ messages in thread
From: Ahmad Fatoum @ 2020-11-10 9:36 UTC (permalink / raw)
To: Sascha Hauer, Rouven Czerwinski; +Cc: barebox
Hi,
On 11/10/20 10:15 AM, Sascha Hauer wrote:
> On Tue, Nov 10, 2020 at 08:48:11AM +0100, Sascha Hauer wrote:
>> On Tue, Nov 10, 2020 at 07:33:53AM +0100, Rouven Czerwinski wrote:
>>> On Mon, 2020-11-09 at 14:52 +0100, Lucas Stach wrote:
>>>> Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven Czerwinski:
>>>>> Annotate the different read and write functions with
>>>>> zero_page_{access/faulting}. This allows the cfi_flash driver to be used
>>>>> on the QEMU virt machine with an enabled MMU.
>>>>
>>>> I don't like this zero-page access allow in a driver at all. If you
>>>> have some free address space somewhere, you could also solve this issue
>>>> by remapping the IO resource to somewhere else in the address space,
>>>> deviating from the 1:1 mapping. The Tegra PCIe host driver does this,
>>>> if you need some inspiration.
>>>
>>> I totally agree, remapping the IO region sounds like a much better
>>> choice.
>>
>> But where should it be mapped to? Just 4k upwards and hope that the area
>> just above the cfi flash isn't occupied by something else?
>
> Ok, here's the plan:
>
> In a board specific initcall map the memory to wherever it's convenient,
> modify the address of the CFI flash in the device node and add a big
> comment that there's nothing to see here.
The device tree specification defines a "virtual-reg property [that] specifies
an effective address that maps to the first physical address specified in
the reg property of the device node. This property enables boot programs to
provide client programs with virtual-to-physical mappings that have been set up".
So, how about a tad more generic approach:
- barebox device tree extends cfi-flash node with virtual-reg of appropriate
location
- Define a of_iomap() function that
- MMU off => does normal request_iomem_region when MMU is off
- MMU on => remaps reg to virtual-reg and does request_iomem_region
Advantages:
- No extra board code
- Reusable for others as well
- No device tree patching necessary
I am not familiar with the PowerPC support in barebox, but if we keep the MMU
on, then the use of virtual-reg is correct and if we turn it off, it doesn't
hurt to have it, so we should be within spec.
Let me know what you think.
Cheers,
Ahmad
>
> Sascha
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping
2020-11-10 9:36 ` Ahmad Fatoum
@ 2020-11-10 9:43 ` Ahmad Fatoum
2020-11-12 10:06 ` Sascha Hauer
0 siblings, 1 reply; 18+ messages in thread
From: Ahmad Fatoum @ 2020-11-10 9:43 UTC (permalink / raw)
To: Sascha Hauer, Rouven Czerwinski; +Cc: barebox
On 11/10/20 10:36 AM, Ahmad Fatoum wrote:
> Hi,
>
> On 11/10/20 10:15 AM, Sascha Hauer wrote:
>> On Tue, Nov 10, 2020 at 08:48:11AM +0100, Sascha Hauer wrote:
>>> On Tue, Nov 10, 2020 at 07:33:53AM +0100, Rouven Czerwinski wrote:
>>>> On Mon, 2020-11-09 at 14:52 +0100, Lucas Stach wrote:
>>>>> Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven Czerwinski:
>>>>>> Annotate the different read and write functions with
>>>>>> zero_page_{access/faulting}. This allows the cfi_flash driver to be used
>>>>>> on the QEMU virt machine with an enabled MMU.
>>>>>
>>>>> I don't like this zero-page access allow in a driver at all. If you
>>>>> have some free address space somewhere, you could also solve this issue
>>>>> by remapping the IO resource to somewhere else in the address space,
>>>>> deviating from the 1:1 mapping. The Tegra PCIe host driver does this,
>>>>> if you need some inspiration.
>>>>
>>>> I totally agree, remapping the IO region sounds like a much better
>>>> choice.
>>>
>>> But where should it be mapped to? Just 4k upwards and hope that the area
>>> just above the cfi flash isn't occupied by something else?
>>
>> Ok, here's the plan:
>>
>> In a board specific initcall map the memory to wherever it's convenient,
>> modify the address of the CFI flash in the device node and add a big
>> comment that there's nothing to see here.
>
> The device tree specification defines a "virtual-reg property [that] specifies
> an effective address that maps to the first physical address specified in
> the reg property of the device node. This property enables boot programs to
> provide client programs with virtual-to-physical mappings that have been set up".
>
> So, how about a tad more generic approach:
>
> - barebox device tree extends cfi-flash node with virtual-reg of appropriate
> location
> - Define a of_iomap() function that
Or rather a more generic name, like dev_ioremap?.(In that case
!CONFIG_OF is the same as MMU off).
> - MMU off => does normal request_iomem_region when MMU is off
> - MMU on => remaps reg to virtual-reg and does request_iomem_region
>
> Advantages:
> - No extra board code
> - Reusable for others as well
> - No device tree patching necessary
>
> I am not familiar with the PowerPC support in barebox, but if we keep the MMU
> on, then the use of virtual-reg is correct and if we turn it off, it doesn't
> hurt to have it, so we should be within spec.
>
> Let me know what you think.
> Cheers,
> Ahmad
>
>>
>> Sascha
>>
>>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping
2020-11-10 9:43 ` Ahmad Fatoum
@ 2020-11-12 10:06 ` Sascha Hauer
2020-11-12 10:09 ` Rouven Czerwinski
0 siblings, 1 reply; 18+ messages in thread
From: Sascha Hauer @ 2020-11-12 10:06 UTC (permalink / raw)
To: Ahmad Fatoum; +Cc: barebox, Rouven Czerwinski
On Tue, Nov 10, 2020 at 10:43:30AM +0100, Ahmad Fatoum wrote:
> On 11/10/20 10:36 AM, Ahmad Fatoum wrote:
> > Hi,
> >
> > On 11/10/20 10:15 AM, Sascha Hauer wrote:
> >> On Tue, Nov 10, 2020 at 08:48:11AM +0100, Sascha Hauer wrote:
> >>> On Tue, Nov 10, 2020 at 07:33:53AM +0100, Rouven Czerwinski wrote:
> >>>> On Mon, 2020-11-09 at 14:52 +0100, Lucas Stach wrote:
> >>>>> Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven Czerwinski:
> >>>>>> Annotate the different read and write functions with
> >>>>>> zero_page_{access/faulting}. This allows the cfi_flash driver to be used
> >>>>>> on the QEMU virt machine with an enabled MMU.
> >>>>>
> >>>>> I don't like this zero-page access allow in a driver at all. If you
> >>>>> have some free address space somewhere, you could also solve this issue
> >>>>> by remapping the IO resource to somewhere else in the address space,
> >>>>> deviating from the 1:1 mapping. The Tegra PCIe host driver does this,
> >>>>> if you need some inspiration.
> >>>>
> >>>> I totally agree, remapping the IO region sounds like a much better
> >>>> choice.
> >>>
> >>> But where should it be mapped to? Just 4k upwards and hope that the area
> >>> just above the cfi flash isn't occupied by something else?
> >>
> >> Ok, here's the plan:
> >>
> >> In a board specific initcall map the memory to wherever it's convenient,
> >> modify the address of the CFI flash in the device node and add a big
> >> comment that there's nothing to see here.
> >
> > The device tree specification defines a "virtual-reg property [that] specifies
> > an effective address that maps to the first physical address specified in
> > the reg property of the device node. This property enables boot programs to
> > provide client programs with virtual-to-physical mappings that have been set up".
> >
> > So, how about a tad more generic approach:
> >
> > - barebox device tree extends cfi-flash node with virtual-reg of appropriate
> > location
> > - Define a of_iomap() function that
>
> Or rather a more generic name, like dev_ioremap?.(In that case
> !CONFIG_OF is the same as MMU off).
I wouldn't use ioremap as name when the function has a different
semantics, but other than that: Sounds good. Make it so!
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping
2020-11-12 10:06 ` Sascha Hauer
@ 2020-11-12 10:09 ` Rouven Czerwinski
0 siblings, 0 replies; 18+ messages in thread
From: Rouven Czerwinski @ 2020-11-12 10:09 UTC (permalink / raw)
To: Sascha Hauer, Ahmad Fatoum; +Cc: barebox
On Thu, 2020-11-12 at 11:06 +0100, Sascha Hauer wrote:
> On Tue, Nov 10, 2020 at 10:43:30AM +0100, Ahmad Fatoum wrote:
> > On 11/10/20 10:36 AM, Ahmad Fatoum wrote:
> > > Hi,
> > >
> > > On 11/10/20 10:15 AM, Sascha Hauer wrote:
> > > > On Tue, Nov 10, 2020 at 08:48:11AM +0100, Sascha Hauer wrote:
> > > > > On Tue, Nov 10, 2020 at 07:33:53AM +0100, Rouven Czerwinski
> > > > > wrote:
> > > > > > On Mon, 2020-11-09 at 14:52 +0100, Lucas Stach wrote:
> > > > > > > Am Montag, den 09.11.2020, 14:44 +0100 schrieb Rouven
> > > > > > > Czerwinski:
> > > > > > > > Annotate the different read and write functions with
> > > > > > > > zero_page_{access/faulting}. This allows the cfi_flash
> > > > > > > > driver to be used
> > > > > > > > on the QEMU virt machine with an enabled MMU.
> > > > > > >
> > > > > > > I don't like this zero-page access allow in a driver at
> > > > > > > all. If you
> > > > > > > have some free address space somewhere, you could also
> > > > > > > solve this issue
> > > > > > > by remapping the IO resource to somewhere else in the
> > > > > > > address space,
> > > > > > > deviating from the 1:1 mapping. The Tegra PCIe host
> > > > > > > driver does this,
> > > > > > > if you need some inspiration.
> > > > > >
> > > > > > I totally agree, remapping the IO region sounds like a much
> > > > > > better
> > > > > > choice.
> > > > >
> > > > > But where should it be mapped to? Just 4k upwards and hope
> > > > > that the area
> > > > > just above the cfi flash isn't occupied by something else?
> > > >
> > > > Ok, here's the plan:
> > > >
> > > > In a board specific initcall map the memory to wherever it's
> > > > convenient,
> > > > modify the address of the CFI flash in the device node and add
> > > > a big
> > > > comment that there's nothing to see here.
> > >
> > > The device tree specification defines a "virtual-reg property
> > > [that] specifies
> > > an effective address that maps to the first physical address
> > > specified in
> > > the reg property of the device node. This property enables boot
> > > programs to
> > > provide client programs with virtual-to-physical mappings that
> > > have been set up".
> > >
> > > So, how about a tad more generic approach:
> > >
> > > - barebox device tree extends cfi-flash node with virtual-reg of
> > > appropriate
> > > location
> > > - Define a of_iomap() function that
> >
> > Or rather a more generic name, like dev_ioremap?.(In that case
> > !CONFIG_OF is the same as MMU off).
>
> I wouldn't use ioremap as name when the function has a different
> semantics, but other than that: Sounds good. Make it so!
This only works if you have available IOMEM big enough somewhere, which
is not the case on the qemu ARM virt platform. While I agree that
having MMU enabled is great for testing, maybe we can just add !MMU as
a dependency for the virt board.
Regards,
Rouven
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH 3/8] amba: add *_amba_driver helper macros
2020-11-09 13:44 [PATCH 0/8] QEMU virt machine support via mach-vexpress Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 1/8] ARM: MMU: add zero_page_{access,faulting} Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 2/8] mtd: cfi_flash: allow 0x0 mapping Rouven Czerwinski
@ 2020-11-09 13:44 ` Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 4/8] ARM: vexpress: remove unused KConfig file Rouven Czerwinski
` (5 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Rouven Czerwinski @ 2020-11-09 13:44 UTC (permalink / raw)
To: barebox; +Cc: Rouven Czerwinski
Reuse the flexible register_driver_macro() to add
{device,coredevice,console}_amba_driver to get rid of the init
boilerplate code used within the amba drivers.
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
drivers/clocksource/amba-sp804.c | 2 +-
drivers/mci/mmci.c | 7 +------
drivers/serial/amba-pl011.c | 8 +-------
include/linux/amba/bus.h | 7 +++++++
4 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/clocksource/amba-sp804.c b/drivers/clocksource/amba-sp804.c
index 8ed5ae4be0..0c0ecaa83a 100644
--- a/drivers/clocksource/amba-sp804.c
+++ b/drivers/clocksource/amba-sp804.c
@@ -85,4 +85,4 @@ struct amba_driver sp804_driver = {
.id_table = sp804_ids,
};
-coredevice_platform_driver(sp804_driver);
+coredevice_amba_driver(sp804_driver);
diff --git a/drivers/mci/mmci.c b/drivers/mci/mmci.c
index f45557d4f7..53f25dff96 100644
--- a/drivers/mci/mmci.c
+++ b/drivers/mci/mmci.c
@@ -709,9 +709,4 @@ static struct amba_driver mmci_driver = {
.id_table = mmci_ids,
};
-static int mmci_init(void)
-{
- amba_driver_register(&mmci_driver);
- return 0;
-}
-device_initcall(mmci_init);
+device_amba_driver(mmci_driver);
diff --git a/drivers/serial/amba-pl011.c b/drivers/serial/amba-pl011.c
index 865ecdddb2..9261d20f2a 100644
--- a/drivers/serial/amba-pl011.c
+++ b/drivers/serial/amba-pl011.c
@@ -237,10 +237,4 @@ struct amba_driver pl011_driver = {
.id_table = pl011_ids,
};
-static int pl011_init(void)
-{
- amba_driver_register(&pl011_driver);
- return 0;
-}
-
-console_initcall(pl011_init);
+console_amba_driver(pl011_driver);
diff --git a/include/linux/amba/bus.h b/include/linux/amba/bus.h
index 7b3e603322..390220a3de 100644
--- a/include/linux/amba/bus.h
+++ b/include/linux/amba/bus.h
@@ -60,6 +60,13 @@ extern struct bus_type amba_bustype;
#define to_amba_device(d) container_of(d, struct amba_device, dev)
+#define device_amba_driver(drv) \
+ register_driver_macro(device,amba,drv)
+#define coredevice_amba_driver(drv) \
+ register_driver_macro(coredevice,amba,drv)
+#define console_amba_driver(drv) \
+ register_driver_macro(console,amba,drv)
+
int amba_driver_register(struct amba_driver *);
void amba_driver_unregister(struct amba_driver *);
struct amba_device *amba_device_alloc(const char *, int id, resource_size_t, size_t);
--
2.28.0
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 4/8] ARM: vexpress: remove unused KConfig file
2020-11-09 13:44 [PATCH 0/8] QEMU virt machine support via mach-vexpress Rouven Czerwinski
` (2 preceding siblings ...)
2020-11-09 13:44 ` [PATCH 3/8] amba: add *_amba_driver helper macros Rouven Czerwinski
@ 2020-11-09 13:44 ` Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 5/8] ARM: vexpress: convert to board driver Rouven Czerwinski
` (4 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Rouven Czerwinski @ 2020-11-09 13:44 UTC (permalink / raw)
To: barebox; +Cc: Rouven Czerwinski
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
arch/arm/boards/vexpress/Kconfig | 8 --------
1 file changed, 8 deletions(-)
delete mode 100644 arch/arm/boards/vexpress/Kconfig
diff --git a/arch/arm/boards/vexpress/Kconfig b/arch/arm/boards/vexpress/Kconfig
deleted file mode 100644
index 94cba3ba81..0000000000
--- a/arch/arm/boards/vexpress/Kconfig
+++ /dev/null
@@ -1,8 +0,0 @@
-
-if MACH_VERSATILEPB
-
-config ARCH_TEXT_BASE
- hex
- default 0x01000000
-
-endif
--
2.28.0
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 5/8] ARM: vexpress: convert to board driver
2020-11-09 13:44 [PATCH 0/8] QEMU virt machine support via mach-vexpress Rouven Czerwinski
` (3 preceding siblings ...)
2020-11-09 13:44 ` [PATCH 4/8] ARM: vexpress: remove unused KConfig file Rouven Czerwinski
@ 2020-11-09 13:44 ` Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 6/8] ARM: vexpress: move Options to ARCH_VEXPRESS Rouven Czerwinski
` (3 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Rouven Czerwinski @ 2020-11-09 13:44 UTC (permalink / raw)
To: barebox; +Cc: Rouven Czerwinski
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
arch/arm/boards/vexpress/init.c | 69 +++++++++++++++++++--------------
1 file changed, 40 insertions(+), 29 deletions(-)
diff --git a/arch/arm/boards/vexpress/init.c b/arch/arm/boards/vexpress/init.c
index 946385393f..6ba23bbb62 100644
--- a/arch/arm/boards/vexpress/init.c
+++ b/arch/arm/boards/vexpress/init.c
@@ -19,9 +19,33 @@
#define V2M_SYS_FLASH 0x03c
-static int vexpress_core_init(void)
+static int of_fixup_virtio_mmio(struct device_node *root, void *unused)
+{
+ struct device_node *barebox_root, *np, *parent;
+
+ barebox_root = of_get_root_node();
+ if (root == barebox_root)
+ return 0;
+
+ for_each_compatible_node_from(np, barebox_root, NULL, "virtio,mmio") {
+ if (of_get_parent(np) == barebox_root)
+ parent = root;
+ else
+ parent = of_find_node_by_path_from(root,
+ of_get_parent(np)->full_name);
+ if (!parent)
+ return -EINVAL;
+
+ of_copy_node(parent, np);
+ }
+
+ return 0;
+}
+
+static int vexpress_probe(struct device_d *dev)
{
char *hostname = "vexpress-unknown";
+ int ret = 0;
if (amba_is_arm_sp804(IOMEM(0x10011000))) {
vexpress_a9_legacy_init();
@@ -42,35 +66,22 @@ static int vexpress_core_init(void)
barebox_set_hostname(hostname);
- return 0;
-}
-postcore_initcall(vexpress_core_init);
-
-static int of_fixup_virtio_mmio(struct device_node *root, void *unused)
-{
- struct device_node *barebox_root, *np, *parent;
-
- barebox_root = of_get_root_node();
- if (root == barebox_root)
- return 0;
+ ret = of_register_fixup(of_fixup_virtio_mmio, NULL);
- for_each_compatible_node_from(np, barebox_root, NULL, "virtio,mmio") {
- if (of_get_parent(np) == barebox_root)
- parent = root;
- else
- parent = of_find_node_by_path_from(root,
- of_get_parent(np)->full_name);
- if (!parent)
- return -EINVAL;
+ return ret;
+}
- of_copy_node(parent, np);
- }
+static const struct of_device_id vexpress_of_match[] = {
+ { .compatible = "arm,vexpress,v2p-ca9" },
+ { .compatible = "arm,vexpress,v2p-ca15" },
+ { .compatible = "arm,vexpress" },
+ { /* Sentinel */},
+};
- return 0;
-}
+static struct driver_d vexpress_board_driver = {
+ .name = "board-vexpress",
+ .probe = vexpress_probe,
+ .of_compatible = vexpress_of_match,
+};
-static int of_register_virtio_mmio_fixup(void)
-{
- return of_register_fixup(of_fixup_virtio_mmio, NULL);
-}
-late_initcall(of_register_virtio_mmio_fixup);
+postcore_platform_driver(vexpress_board_driver);
--
2.28.0
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 6/8] ARM: vexpress: move Options to ARCH_VEXPRESS
2020-11-09 13:44 [PATCH 0/8] QEMU virt machine support via mach-vexpress Rouven Czerwinski
` (4 preceding siblings ...)
2020-11-09 13:44 ` [PATCH 5/8] ARM: vexpress: convert to board driver Rouven Czerwinski
@ 2020-11-09 13:44 ` Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 7/8] ARM: qemu: add support for qemu virt platform Rouven Czerwinski
` (2 subsequent siblings)
8 siblings, 0 replies; 18+ messages in thread
From: Rouven Czerwinski @ 2020-11-09 13:44 UTC (permalink / raw)
To: barebox; +Cc: Rouven Czerwinski
In preparation for the qemu virt image, move the KConfig options from
MACH_VEXPRESS to ARCH_VEXPRESS. Also remove the choice, since we allow
multiple boards to be selected with HAVE_PBL_MULTI_IMAGES.
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
arch/arm/Kconfig | 4 ++++
arch/arm/mach-vexpress/Kconfig | 8 --------
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ea6d459dfe..91da0e4ff3 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -223,6 +223,10 @@ config ARCH_VEXPRESS
select AMBA_SP804
select CLKDEV_LOOKUP
select COMMON_CLK
+ select OFTREE
+ select OFDEVICE
+ select RELOCATABLE
+ select HAVE_PBL_MULTI_IMAGES
config ARCH_TEGRA
bool "NVIDIA Tegra"
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index aaa535f073..4058177b3a 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -4,17 +4,9 @@ config ARCH_TEXT_BASE
hex
default 0x0
-choice
- prompt "ARM Board type"
-
config MACH_VEXPRESS
bool "ARM Vexpress"
- select RELOCATABLE
- select HAVE_PBL_MULTI_IMAGES
- select OFTREE
- select OFDEVICE
select COMMON_CLK_OF_PROVIDER
-endchoice
endif
--
2.28.0
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 7/8] ARM: qemu: add support for qemu virt platform
2020-11-09 13:44 [PATCH 0/8] QEMU virt machine support via mach-vexpress Rouven Czerwinski
` (5 preceding siblings ...)
2020-11-09 13:44 ` [PATCH 6/8] ARM: vexpress: move Options to ARCH_VEXPRESS Rouven Czerwinski
@ 2020-11-09 13:44 ` Rouven Czerwinski
2020-11-09 13:44 ` [PATCH 8/8] ARM: vexpress: enable VIRT board, MMU and cmds Rouven Czerwinski
2020-11-12 10:30 ` [PATCH 0/8] QEMU virt machine support via mach-vexpress Sascha Hauer
8 siblings, 0 replies; 18+ messages in thread
From: Rouven Czerwinski @ 2020-11-09 13:44 UTC (permalink / raw)
To: barebox; +Cc: Rouven Czerwinski
Necessary support to boot barebox on ARM qemu virt platforms.
No internal device tree, since it is passed by qemu. Therefore it
employs the generic 2nd stage image as the low level code and only adds
a virt specific board driver.
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
arch/arm/Kconfig | 2 +-
arch/arm/boards/Makefile | 1 +
arch/arm/boards/qemu-virt/Makefile | 1 +
arch/arm/boards/qemu-virt/board.c | 36 ++++++++++++++++++++++++++++++
arch/arm/mach-vexpress/Kconfig | 4 ++++
5 files changed, 43 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boards/qemu-virt/Makefile
create mode 100644 arch/arm/boards/qemu-virt/board.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 91da0e4ff3..5342de54c1 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -216,7 +216,7 @@ config ARCH_VERSATILE
select HAS_DEBUG_LL
config ARCH_VEXPRESS
- bool "ARM Vexpres boards"
+ bool "ARM Vexpress & virt boards"
select HAS_DEBUG_LL
select CPU_V7
select ARM_AMBA
diff --git a/arch/arm/boards/Makefile b/arch/arm/boards/Makefile
index a02d80d2da..81c228efd6 100644
--- a/arch/arm/boards/Makefile
+++ b/arch/arm/boards/Makefile
@@ -164,6 +164,7 @@ obj-$(CONFIG_MACH_ZYLONITE) += zylonite/
obj-$(CONFIG_MACH_VARISCITE_MX6) += variscite-mx6/
obj-$(CONFIG_MACH_VSCOM_BALTOS) += vscom-baltos/
obj-$(CONFIG_MACH_QEMU_VIRT64) += qemu-virt64/
+obj-$(CONFIG_MACH_VIRT) += qemu-virt/
obj-$(CONFIG_MACH_WARP7) += element14-warp7/
obj-$(CONFIG_MACH_WEBASTO_CCBV2) += webasto-ccbv2/
obj-$(CONFIG_MACH_VF610_TWR) += freescale-vf610-twr/
diff --git a/arch/arm/boards/qemu-virt/Makefile b/arch/arm/boards/qemu-virt/Makefile
new file mode 100644
index 0000000000..dcfc2937d3
--- /dev/null
+++ b/arch/arm/boards/qemu-virt/Makefile
@@ -0,0 +1 @@
+obj-y += board.o
diff --git a/arch/arm/boards/qemu-virt/board.c b/arch/arm/boards/qemu-virt/board.c
new file mode 100644
index 0000000000..3aeea1a017
--- /dev/null
+++ b/arch/arm/boards/qemu-virt/board.c
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 Pengutronix e.K.
+ *
+ */
+#include <common.h>
+#include <init.h>
+#include <asm/system_info.h>
+
+static int virt_probe(struct device_d *dev)
+{
+ char *hostname = "virt";
+
+ if (cpu_is_cortex_a7())
+ hostname = "virt-a7";
+ else if (cpu_is_cortex_a15())
+ hostname = "virt-a15";
+
+ barebox_set_model("ARM QEMU virt");
+ barebox_set_hostname(hostname);
+
+ return 0;
+}
+
+static const struct of_device_id virt_of_match[] = {
+ { .compatible = "linux,dummy-virt" },
+ { /* Sentinel */},
+};
+
+static struct driver_d virt_board_driver = {
+ .name = "board-qemu-virt",
+ .probe = virt_probe,
+ .of_compatible = virt_of_match,
+};
+
+postcore_platform_driver(virt_board_driver);
diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
index 4058177b3a..7677a1411b 100644
--- a/arch/arm/mach-vexpress/Kconfig
+++ b/arch/arm/mach-vexpress/Kconfig
@@ -8,5 +8,9 @@ config MACH_VEXPRESS
bool "ARM Vexpress"
select COMMON_CLK_OF_PROVIDER
+config MACH_VIRT
+ bool "QEMU virt"
+ select ARM_PSCI_CLIENT
+ select BOARD_ARM_GENERIC_DT
endif
--
2.28.0
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH 8/8] ARM: vexpress: enable VIRT board, MMU and cmds
2020-11-09 13:44 [PATCH 0/8] QEMU virt machine support via mach-vexpress Rouven Czerwinski
` (6 preceding siblings ...)
2020-11-09 13:44 ` [PATCH 7/8] ARM: qemu: add support for qemu virt platform Rouven Czerwinski
@ 2020-11-09 13:44 ` Rouven Czerwinski
2020-11-12 10:30 ` [PATCH 0/8] QEMU virt machine support via mach-vexpress Sascha Hauer
8 siblings, 0 replies; 18+ messages in thread
From: Rouven Czerwinski @ 2020-11-09 13:44 UTC (permalink / raw)
To: barebox; +Cc: Rouven Czerwinski
Enable the new qemu virt board, the MMU, ofdiff and mmuinfo.
Signed-off-by: Rouven Czerwinski <r.czerwinski@pengutronix.de>
---
arch/arm/configs/vexpress_defconfig | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/configs/vexpress_defconfig b/arch/arm/configs/vexpress_defconfig
index caa9f512d6..b8dc2686da 100644
--- a/arch/arm/configs/vexpress_defconfig
+++ b/arch/arm/configs/vexpress_defconfig
@@ -1,4 +1,6 @@
CONFIG_ARCH_VEXPRESS=y
+CONFIG_MACH_VEXPRESS=y
+CONFIG_MACH_VIRT=y
CONFIG_AEABI=y
CONFIG_ARM_OPTIMZED_STRING_FUNCTIONS=y
CONFIG_MALLOC_SIZE=0x0
@@ -36,6 +38,7 @@ CONFIG_CMD_EDIT=y
CONFIG_CMD_LOGIN=y
CONFIG_CMD_MENU=y
CONFIG_CMD_MENU_MANAGEMENT=y
+CONFIG_CMD_ARM_MMUINFO=y
CONFIG_CMD_PASSWD=y
CONFIG_CMD_READLINE=y
CONFIG_CMD_TIMEOUT=y
@@ -44,6 +47,7 @@ CONFIG_CMD_CRC_CMP=y
CONFIG_CMD_CLK=y
CONFIG_CMD_DETECT=y
CONFIG_CMD_OFTREE=y
+CONFIG_CMD_OF_DIFF=y
CONFIG_NET=y
CONFIG_NET_NFS=y
CONFIG_NET_NETCONSOLE=y
@@ -52,6 +56,7 @@ CONFIG_SERIAL_AMBA_PL011=y
CONFIG_DRIVER_NET_SMC91111=y
# CONFIG_SPI is not set
CONFIG_MTD=y
+CONFIG_MMU=y
CONFIG_MTD_CONCAT=y
CONFIG_DRIVER_CFI=y
CONFIG_MCI=y
--
2.28.0
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH 0/8] QEMU virt machine support via mach-vexpress
2020-11-09 13:44 [PATCH 0/8] QEMU virt machine support via mach-vexpress Rouven Czerwinski
` (7 preceding siblings ...)
2020-11-09 13:44 ` [PATCH 8/8] ARM: vexpress: enable VIRT board, MMU and cmds Rouven Czerwinski
@ 2020-11-12 10:30 ` Sascha Hauer
8 siblings, 0 replies; 18+ messages in thread
From: Sascha Hauer @ 2020-11-12 10:30 UTC (permalink / raw)
To: Rouven Czerwinski; +Cc: barebox
On Mon, Nov 09, 2020 at 02:44:22PM +0100, Rouven Czerwinski wrote:
> Instead of using ARCH_QEMU, this variant uses ARCH_VEXPRESS to base its
> support for the QEMU virt machine on. Contains a cleanup and conversion
> of the vexpress boards to board drivers and an implementation of
> zero_page_access and faulting for ARM32.
>
> Rouven Czerwinski (8):
> ARM: MMU: add zero_page_{access,faulting}
> mtd: cfi_flash: allow 0x0 mapping
> amba: add *_amba_driver helper macros
> ARM: vexpress: remove unused KConfig file
> ARM: vexpress: convert to board driver
> ARM: vexpress: move Options to ARCH_VEXPRESS
> ARM: qemu: add support for qemu virt platform
> ARM: vexpress: enable VIRT board, MMU and cmds
Until the flash-at-zero problem is solved: Applied 3-7.
Sascha
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 18+ messages in thread