Skip to contentSkip to conversation

RISC-V: add LiteX SoC support; resurrect nmon

PATCH Superseded Antony Pavlov 2 participants 26 messages May 6, 2021 – May 7, 2021

Subsystems (7)
Network drivers GPIO RISC-V SPI +3 more subsystems

v2 of 4 Superseded Latest is v4 →

lore
Share & tools
lore
#0 lore raw

v2 cover RISC-V: add LiteX SoC support; resurrect nmon

Changes since v1:

* rebased on top of next branch;
* new patches are introduced:
* clocksource: timer-riscv: select CSR from device tree
* RISC-V: make RISCV_SBI and RISCV_M_MODE explicitly mutually exclusive
* RISC-V: make it possible to build RV32I multi-image with DEBUG_LL=n
* almost all of Ahmad's notes are fixed (e.g. unused header files inclusions are dropped);
* NOT FIXED: gpio-74xx-mmio still uses dev_get_drvdata(), not device_get_match_data()

Antony Pavlov (11):
clocksource: timer-riscv: select CSR from device tree
RISC-V: make RISCV_SBI and RISCV_M_MODE explicitly mutually exclusive
RISC-V: make it possible to run nmon from PBL C code
RISC-V: boards: erizo: make it possible to use nmon
serial: add litex UART driver
gpio: add driver for 74xx-ICs with MMIO access
spi: add litex spiflash driver
net: add LiteEth driver
RISC-V: add LiteX SoC and linux-on-litex-vexriscv support
RISC-V: add litex_linux_defconfig
RISC-V: make it possible to build RV32I multi-image with DEBUG_LL=n

 arch/riscv/Kconfig                         |  22 +-
 arch/riscv/Kconfig.socs                    |  18 +-
 arch/riscv/boards/Makefile                 |   1 +
 arch/riscv/boards/erizo/lowlevel.c         |   5 +
 arch/riscv/boards/litex-linux/Makefile     |   3 +
 arch/riscv/boards/litex-linux/lowlevel.c   |  20 ++
 arch/riscv/boot/Makefile                   |   1 +
 arch/riscv/boot/nmon_entry.S               |  13 +
 arch/riscv/configs/erizo_generic_defconfig |   1 +
 arch/riscv/configs/litex_linux_defconfig   |  77 +++++
 arch/riscv/cpu/time.c                      |   7 +
 arch/riscv/dts/Makefile                    |   1 +
 arch/riscv/dts/erizo.dtsi                  |   2 +
 arch/riscv/dts/litex-linux.dts             |  96 ++++++
 arch/riscv/dts/litex_soc_linux.dtsi        |  49 +++
 arch/riscv/include/asm/debug_ll.h          |   3 +
 arch/riscv/include/asm/debug_ll_litex.h    | 123 +++++++
 arch/riscv/include/asm/riscv_nmon.h        |  49 ++-
 arch/riscv/include/asm/timer.h             |   1 +
 common/Kconfig                             |   4 +
 drivers/clocksource/timer-riscv.c          |  19 +-
 drivers/gpio/Kconfig                       |  14 +
 drivers/gpio/Makefile                      |   1 +
 drivers/gpio/gpio-74xx-mmio.c              | 166 +++++++++
 drivers/net/Kconfig                        |   8 +
 drivers/net/Makefile                       |   1 +
 drivers/net/liteeth.c                      | 376 +++++++++++++++++++++
 drivers/serial/Makefile                    |   1 +
 drivers/serial/serial_litex.c              |  96 ++++++
 drivers/spi/Kconfig                        |   3 +
 drivers/spi/Makefile                       |   1 +
 drivers/spi/litex_spiflash.c               | 241 +++++++++++++
 images/Makefile.riscv                      |   4 +
 33 files changed, 1388 insertions(+), 39 deletions(-)
 create mode 100644 arch/riscv/boards/litex-linux/Makefile
 create mode 100644 arch/riscv/boards/litex-linux/lowlevel.c
 create mode 100644 arch/riscv/boot/nmon_entry.S
 create mode 100644 arch/riscv/configs/litex_linux_defconfig
 create mode 100644 arch/riscv/dts/litex-linux.dts
 create mode 100644 arch/riscv/dts/litex_soc_linux.dtsi
 create mode 100644 arch/riscv/include/asm/debug_ll_litex.h
 create mode 100644 drivers/gpio/gpio-74xx-mmio.c
 create mode 100644 drivers/net/liteeth.c
 create mode 100644 drivers/serial/serial_litex.c
 create mode 100644 drivers/spi/litex_spiflash.c
Signature · 7 lines
2.31.1


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#1 lore raw

PATCH v2 1/11 clocksource: timer-riscv: select CSR from device tree

barebox timer-riscv driver supports one of user counters:

* 'cycle', counter for RDCYCLE instruction (CSR 0xc00);
* 'time', timer for RDTIME instruction (CSR 0xc01).

At the moment in S-mode timer-riscv uses the 'cycle' counter, and in M-mode timer-riscv uses the 'time' timer.

Alas picorv32 CPU core supports only the 'cycle' counter. VexRiscV CPU core supports only the 'time' timer.

This patch makes it possible to use the 'time' timer for VexRiscV CPU in M-mode.

---
 arch/riscv/cpu/time.c             |  7 +++++++
 arch/riscv/dts/erizo.dtsi         |  2 ++
 arch/riscv/include/asm/timer.h    |  1 +
 drivers/clocksource/timer-riscv.c | 19 ++++++++-----------
 4 files changed, 18 insertions(+), 11 deletions(-)
arch/riscv/cpu/time.c +7 -0
index 39bb6a5112..59c8ca61d6 100644
@@ -18,6 +18,7 @@
 #include <asm/timer.h>
 
 unsigned long riscv_timebase;
+unsigned long riscv_use_csr_cycle;
 
 int timer_init(void)
 {
@@ -32,6 +33,12 @@ int timer_init(void)
 
 	riscv_timebase = prop;
 
+	if (of_property_read_bool(cpu, "csr-cycle")) {
+		riscv_use_csr_cycle = 1;
+	} else {
+		riscv_use_csr_cycle = 0;
+	}
+
 	of_platform_populate(cpu, NULL, NULL);
 
 	return 0;
arch/riscv/dts/erizo.dtsi +2 -0
index 228711bd69..b3ccf281f2 100644
@@ -22,6 +22,8 @@
 
 		timebase-frequency = <24000000>;
 
+		csr-cycle;
+
 		cpu@0 {
 			device_type = "cpu";
 			compatible = "cliffordwolf,picorv32", "riscv";
arch/riscv/include/asm/timer.h +1 -0
index 1f78ef4c00..555b3f5989 100644
@@ -5,5 +5,6 @@
 
 int timer_init(void);
 extern unsigned long riscv_timebase;
+extern unsigned long riscv_use_csr_cycle;
 
 #endif /* _ASM_RISCV_DELAY_H */
drivers/clocksource/timer-riscv.c +8 -11
index ef67cff475..c0deed40eb 100644
@@ -13,7 +13,7 @@
 #include <asm/timer.h>
 #include <asm/csr.h>
 
-static u64 notrace riscv_timer_get_count_sbi(void)
+static u64 notrace riscv_timer_get_count_time(void)
 {
 	__maybe_unused u32 hi, lo;
 
@@ -28,7 +28,7 @@ static u64 notrace riscv_timer_get_count_sbi(void)
 	return ((u64)hi << 32) | lo;
 }
 
-static u64 notrace riscv_timer_get_count_rdcycle(void)
+static u64 notrace riscv_timer_get_count_cycle(void)
 {
 	__maybe_unused u32 hi, lo;
 
@@ -43,16 +43,7 @@ static u64 notrace riscv_timer_get_count_rdcycle(void)
 	return ((u64)hi << 32) | lo;
 }
 
-static u64 notrace riscv_timer_get_count(void)
-{
-	if (IS_ENABLED(CONFIG_RISCV_SBI))
-		return riscv_timer_get_count_sbi();
-	else
-		return riscv_timer_get_count_rdcycle();
-}
-
 static struct clocksource riscv_clocksource = {
-	.read		= riscv_timer_get_count,
 	.mask		= CLOCKSOURCE_MASK(64),
 	.priority	= 100,
 };
@@ -61,6 +52,12 @@ static int riscv_timer_init(struct device_d* dev)
 {
 	dev_info(dev, "running at %lu Hz\n", riscv_timebase);
 
+	if (riscv_use_csr_cycle) {
+		riscv_clocksource.read = riscv_timer_get_count_cycle;
+	} else {
+		riscv_clocksource.read = riscv_timer_get_count_time;
+	}
+
 	riscv_clocksource.mult = clocksource_hz2mult(riscv_timebase, riscv_clocksource.shift);
 
 	return init_clock(&riscv_clocksource);
Signature · 7 lines
2.31.1


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#2 lore raw

Re: [PATCH v2 01/11] clocksource: timer-riscv: select CSR from device tree

Hello Antony,

Quoted 7 lines · Antony Pavlov

barebox timer-riscv driver supports one of user counters:

* 'cycle', counter for RDCYCLE instruction (CSR 0xc00);
* 'time', timer for RDTIME instruction (CSR 0xc01).

At the moment in S-mode timer-riscv uses the 'cycle' counter, and in M-mode timer-riscv uses the 'time' timer.

Other way round, right? cycle for M-Mode, time for S-Mode?

Quoted 6 lines

Alas picorv32 CPU core supports only the 'cycle' counter. VexRiscV CPU core supports only the 'time' timer.

This patch makes it possible to use the 'time' timer for VexRiscV CPU in M-mode.

Is that allowed by the ISA? To provide time, but not cycle? Can VexRiscV boot Linux? If so, how does Linux handle lack of this CSR?

Quoted 21 lines
---
 arch/riscv/cpu/time.c             |  7 +++++++
 arch/riscv/dts/erizo.dtsi         |  2 ++
 arch/riscv/include/asm/timer.h    |  1 +
 drivers/clocksource/timer-riscv.c | 19 ++++++++-----------
 4 files changed, 18 insertions(+), 11 deletions(-)
arch/riscv/cpu/time.c +1 -0
index 39bb6a5112..59c8ca61d6 100644
@@ -18,6 +18,7 @@
 #include <asm/timer.h>
 
 unsigned long riscv_timebase;
+unsigned long riscv_use_csr_cycle;
 
 int timer_init(void)
 {

arch/riscv/cpu/time.c int timer_init(void) · line 41

Quoted 9 lines
arch/riscv/cpu/time.c +6 -0
@@ -32,6 +33,12 @@ int timer_init(void)
 
 	riscv_timebase = prop;
 
+	if (of_property_read_bool(cpu, "csr-cycle")) {
+		riscv_use_csr_cycle = 1;
+	} else {
+		riscv_use_csr_cycle = 0;
+	}
+

Any reason this couldn't happen in driver probe? I'd also prefer another name, e.g. barebox,use-csr-cycle ?

Quoted 80 lines
arch/riscv/cpu/time.c +0 -0
 	of_platform_populate(cpu, NULL, NULL);
 
 	return 0;
arch/riscv/dts/erizo.dtsi +2 -0
index 228711bd69..b3ccf281f2 100644
@@ -22,6 +22,8 @@
 
 		timebase-frequency = <24000000>;
 
+		csr-cycle;
+
 		cpu@0 {
 			device_type = "cpu";
 			compatible = "cliffordwolf,picorv32", "riscv";
arch/riscv/include/asm/timer.h +1 -0
index 1f78ef4c00..555b3f5989 100644
@@ -5,5 +5,6 @@
 
 int timer_init(void);
 extern unsigned long riscv_timebase;
+extern unsigned long riscv_use_csr_cycle;
 
 #endif /* _ASM_RISCV_DELAY_H */
drivers/clocksource/timer-riscv.c +8 -11
index ef67cff475..c0deed40eb 100644
@@ -13,7 +13,7 @@
 #include <asm/timer.h>
 #include <asm/csr.h>
 
-static u64 notrace riscv_timer_get_count_sbi(void)
+static u64 notrace riscv_timer_get_count_time(void)
 {
 	__maybe_unused u32 hi, lo;
 
@@ -28,7 +28,7 @@ static u64 notrace riscv_timer_get_count_sbi(void)
 	return ((u64)hi << 32) | lo;
 }
 
-static u64 notrace riscv_timer_get_count_rdcycle(void)
+static u64 notrace riscv_timer_get_count_cycle(void)
 {
 	__maybe_unused u32 hi, lo;
 
@@ -43,16 +43,7 @@ static u64 notrace riscv_timer_get_count_rdcycle(void)
 	return ((u64)hi << 32) | lo;
 }
 
-static u64 notrace riscv_timer_get_count(void)
-{
-	if (IS_ENABLED(CONFIG_RISCV_SBI))
-		return riscv_timer_get_count_sbi();
-	else
-		return riscv_timer_get_count_rdcycle();
-}
-
 static struct clocksource riscv_clocksource = {
-	.read		= riscv_timer_get_count,
 	.mask		= CLOCKSOURCE_MASK(64),
 	.priority	= 100,
 };
@@ -61,6 +52,12 @@ static int riscv_timer_init(struct device_d* dev)
 {
 	dev_info(dev, "running at %lu Hz\n", riscv_timebase);
 
+	if (riscv_use_csr_cycle) {
+		riscv_clocksource.read = riscv_timer_get_count_cycle;
+	} else {
+		riscv_clocksource.read = riscv_timer_get_count_time;
+	}
+
 	riscv_clocksource.mult = clocksource_hz2mult(riscv_timebase, riscv_clocksource.shift);
 
 	return init_clock(&riscv_clocksource);
Signature · 9 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#3 lore raw

Re: [PATCH v2 01/11] clocksource: timer-riscv: select CSR from device tree

Quoted 5 lines · On Fri, 7 May 2021 13:34:30 +0200 Ahmad Fatoum <[email protected]> wrote:

Hello Antony,

Quoted 2 lines · Antony Pavlov

barebox timer-riscv driver supports one of user counters:

Quoted 7 lines
Quoted 5 lines

* 'cycle', counter for RDCYCLE instruction (CSR 0xc00);
* 'time', timer for RDTIME instruction (CSR 0xc01).

At the moment in S-mode timer-riscv uses the 'cycle' counter, and in M-mode timer-riscv uses the 'time' timer.

Other way round, right? cycle for M-Mode, time for S-Mode?

Yes, you are right, my bad.

Quoted 10 lines
Quoted 6 lines

Alas picorv32 CPU core supports only the 'cycle' counter. VexRiscV CPU core supports only the 'time' timer.

This patch makes it possible to use the 'time' timer for VexRiscV CPU in M-mode.

Is that allowed by the ISA? To provide time, but not cycle? Can VexRiscV boot Linux? If so, how does Linux handle lack of this CSR?

Here is an unobvious answer for all these questions at once.

The RISC-V Instruction Set Manual, Volume II: Privileged Architecture Document Version 20190608-Priv-MSU-Ratified states that

<<
Attempts to access a non-existent CSR raise an illegal instruction exception

Quoted 1 line
Quoted 1 line

So you can even realize in hardware very few CSR for exception handling (mstatus, mcause, mtvec, mie, mepc) and try to emulate all other CSR in software !

As a result exception handler for VexRiscv emulates access to 'cycle' CSR (RDCYCLE pseudo-op) by reading the 'time' CSR !
Please see https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/c/emulator/src/main.c#L239

opensbi do near the same ! Please see https://github.com/riscv/opensbi/blob/master/lib/sbi/sbi_emulate_csr.c#L64

Can VexRiscV boot Linux? Yes, it can boot linux!
Please see this demo: https://asciinema.org/a/7fLu84ytgtVd3rjPm7Li3GD4r
In this demo barebox loads emulator.bin into the RAM.
This emulator.bin realizes SBI for linux kernel and emulates all missed features necessary for running linux.

Quoted 25 lines
Quoted 25 lines
---
 arch/riscv/cpu/time.c             |  7 +++++++
 arch/riscv/dts/erizo.dtsi         |  2 ++
 arch/riscv/include/asm/timer.h    |  1 +
 drivers/clocksource/timer-riscv.c | 19 ++++++++-----------
 4 files changed, 18 insertions(+), 11 deletions(-)
arch/riscv/cpu/time.c +1 -0
index 39bb6a5112..59c8ca61d6 100644
@@ -18,6 +18,7 @@
 #include <asm/timer.h>
 
 unsigned long riscv_timebase;
+unsigned long riscv_use_csr_cycle;
 
 int timer_init(void)
 {
@@ -32,6 +33,12 @@ int timer_init(void)
 
 	riscv_timebase = prop;
 
Quoted 8 lines

arch/riscv/cpu/time.c int timer_init(void) · line 41

Quoted 6 lines
arch/riscv/cpu/time.c +6 -0
+	if (of_property_read_bool(cpu, "csr-cycle")) {
+		riscv_use_csr_cycle = 1;
+	} else {
+		riscv_use_csr_cycle = 0;
+	}
+

Any reason this couldn't happen in driver probe?

Because we already have riscv_timebase parse routine outside of driver probe. I tryed to avoid code duplication.
Why we couldn't parse riscv_timebase in driver probe?

Quoted 1 line

I'd also prefer another name, e.g. barebox,use-csr-cycle ?

Yes, barebox,use-csr-cycle is a better name.

Quoted 86 lines
Quoted 80 lines
arch/riscv/cpu/time.c +0 -0
 	of_platform_populate(cpu, NULL, NULL);
 
 	return 0;
arch/riscv/dts/erizo.dtsi +2 -0
index 228711bd69..b3ccf281f2 100644
@@ -22,6 +22,8 @@
 
 		timebase-frequency = <24000000>;
 
+		csr-cycle;
+
 		cpu@0 {
 			device_type = "cpu";
 			compatible = "cliffordwolf,picorv32", "riscv";
arch/riscv/include/asm/timer.h +1 -0
index 1f78ef4c00..555b3f5989 100644
@@ -5,5 +5,6 @@
 
 int timer_init(void);
 extern unsigned long riscv_timebase;
+extern unsigned long riscv_use_csr_cycle;
 
 #endif /* _ASM_RISCV_DELAY_H */
drivers/clocksource/timer-riscv.c +8 -11
index ef67cff475..c0deed40eb 100644
@@ -13,7 +13,7 @@
 #include <asm/timer.h>
 #include <asm/csr.h>
 
-static u64 notrace riscv_timer_get_count_sbi(void)
+static u64 notrace riscv_timer_get_count_time(void)
 {
 	__maybe_unused u32 hi, lo;
 
@@ -28,7 +28,7 @@ static u64 notrace riscv_timer_get_count_sbi(void)
 	return ((u64)hi << 32) | lo;
 }
 
-static u64 notrace riscv_timer_get_count_rdcycle(void)
+static u64 notrace riscv_timer_get_count_cycle(void)
 {
 	__maybe_unused u32 hi, lo;
 
@@ -43,16 +43,7 @@ static u64 notrace riscv_timer_get_count_rdcycle(void)
 	return ((u64)hi << 32) | lo;
 }
 
-static u64 notrace riscv_timer_get_count(void)
-{
-	if (IS_ENABLED(CONFIG_RISCV_SBI))
-		return riscv_timer_get_count_sbi();
-	else
-		return riscv_timer_get_count_rdcycle();
-}
-
 static struct clocksource riscv_clocksource = {
-	.read		= riscv_timer_get_count,
 	.mask		= CLOCKSOURCE_MASK(64),
 	.priority	= 100,
 };
@@ -61,6 +52,12 @@ static int riscv_timer_init(struct device_d* dev)
 {
 	dev_info(dev, "running at %lu Hz\n", riscv_timebase);
 
+	if (riscv_use_csr_cycle) {
+		riscv_clocksource.read = riscv_timer_get_count_cycle;
+	} else {
+		riscv_clocksource.read = riscv_timer_get_count_time;
+	}
+
 	riscv_clocksource.mult = clocksource_hz2mult(riscv_timebase, riscv_clocksource.shift);
 
 	return init_clock(&riscv_clocksource);
Signature · 4 lines
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 |
Signature · 7 lines
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#4 lore raw

Re: [PATCH v2 01/11] clocksource: timer-riscv: select CSR from device tree

Hello Antony,

Quoted 27 lines · Antony Pavlov
Quoted 9 lines · On Fri, 7 May 2021 13:34:30 +0200 Ahmad Fatoum <[email protected]> wrote:
Quoted 5 lines

Alas picorv32 CPU core supports only the 'cycle' counter. VexRiscV CPU core supports only the 'time' timer.

This patch makes it possible to use the 'time' timer for VexRiscV CPU in M-mode.

Is that allowed by the ISA? To provide time, but not cycle? Can VexRiscV boot Linux? If so, how does Linux handle lack of this CSR?

Here is an unobvious answer for all these questions at once.

The RISC-V Instruction Set Manual, Volume II: Privileged Architecture Document Version 20190608-Priv-MSU-Ratified states that

<<
Attempts to access a non-existent CSR raise an illegal instruction exception

Quoted 1 line
Quoted 1 line

So you can even realize in hardware very few CSR for exception handling (mstatus, mcause, mtvec, mie, mepc) and try to emulate all other CSR in software !>
As a result exception handler for VexRiscv emulates access to 'cycle' CSR (RDCYCLE pseudo-op) by reading the 'time' CSR !
Please see https://github.com/SpinalHDL/VexRiscv/blob/master/src/main/c/emulator/src/main.c#L239

Quoted 7 lines

opensbi do near the same ! Please see https://github.com/riscv/opensbi/blob/master/lib/sbi/sbi_emulate_csr.c#L64

Can VexRiscV boot Linux? Yes, it can boot linux!
Please see this demo: https://asciinema.org/a/7fLu84ytgtVd3rjPm7Li3GD4r
In this demo barebox loads emulator.bin into the RAM.
This emulator.bin realizes SBI for linux kernel and emulates all missed features necessary for running linux.

Thanks for clearing this up :)

Quoted 33 lines
Quoted 24 lines
Quoted 24 lines
---
 arch/riscv/cpu/time.c             |  7 +++++++
 arch/riscv/dts/erizo.dtsi         |  2 ++
 arch/riscv/include/asm/timer.h    |  1 +
 drivers/clocksource/timer-riscv.c | 19 ++++++++-----------
 4 files changed, 18 insertions(+), 11 deletions(-)
arch/riscv/cpu/time.c +1 -0
index 39bb6a5112..59c8ca61d6 100644
@@ -18,6 +18,7 @@
 #include <asm/timer.h>
 
 unsigned long riscv_timebase;
+unsigned long riscv_use_csr_cycle;
 
 int timer_init(void)
 {
@@ -32,6 +33,12 @@ int timer_init(void)
 
 	riscv_timebase = prop;
 
Quoted 8 lines

arch/riscv/cpu/time.c int timer_init(void) · line 41

Quoted 6 lines
arch/riscv/cpu/time.c +6 -0
+	if (of_property_read_bool(cpu, "csr-cycle")) {
+		riscv_use_csr_cycle = 1;
+	} else {
+		riscv_use_csr_cycle = 0;
+	}
+

Any reason this couldn't happen in driver probe?

Quoted 3 lines

Because we already have riscv_timebase parse routine outside of driver probe. I tryed to avoid code duplication.
Why we couldn't parse riscv_timebase in driver probe?

Because riscv_timebase is also used for CLINT clocksource, but this one here would be exclusive to riscv timer, so it should be read there.

Quoted 93 lines
Quoted 1 line

I'd also prefer another name, e.g. barebox,use-csr-cycle ?

Yes, barebox,use-csr-cycle is a better name.

Quoted 86 lines
Quoted 80 lines
arch/riscv/cpu/time.c +0 -0
 	of_platform_populate(cpu, NULL, NULL);
 
 	return 0;
arch/riscv/dts/erizo.dtsi +2 -0
index 228711bd69..b3ccf281f2 100644
@@ -22,6 +22,8 @@
 
 		timebase-frequency = <24000000>;
 
+		csr-cycle;
+
 		cpu@0 {
 			device_type = "cpu";
 			compatible = "cliffordwolf,picorv32", "riscv";
arch/riscv/include/asm/timer.h +1 -0
index 1f78ef4c00..555b3f5989 100644
@@ -5,5 +5,6 @@
 
 int timer_init(void);
 extern unsigned long riscv_timebase;
+extern unsigned long riscv_use_csr_cycle;
 
 #endif /* _ASM_RISCV_DELAY_H */
drivers/clocksource/timer-riscv.c +8 -11
index ef67cff475..c0deed40eb 100644
@@ -13,7 +13,7 @@
 #include <asm/timer.h>
 #include <asm/csr.h>
 
-static u64 notrace riscv_timer_get_count_sbi(void)
+static u64 notrace riscv_timer_get_count_time(void)
 {
 	__maybe_unused u32 hi, lo;
 
@@ -28,7 +28,7 @@ static u64 notrace riscv_timer_get_count_sbi(void)
 	return ((u64)hi << 32) | lo;
 }
 
-static u64 notrace riscv_timer_get_count_rdcycle(void)
+static u64 notrace riscv_timer_get_count_cycle(void)
 {
 	__maybe_unused u32 hi, lo;
 
@@ -43,16 +43,7 @@ static u64 notrace riscv_timer_get_count_rdcycle(void)
 	return ((u64)hi << 32) | lo;
 }
 
-static u64 notrace riscv_timer_get_count(void)
-{
-	if (IS_ENABLED(CONFIG_RISCV_SBI))
-		return riscv_timer_get_count_sbi();
-	else
-		return riscv_timer_get_count_rdcycle();
-}
-
 static struct clocksource riscv_clocksource = {
-	.read		= riscv_timer_get_count,
 	.mask		= CLOCKSOURCE_MASK(64),
 	.priority	= 100,
 };
@@ -61,6 +52,12 @@ static int riscv_timer_init(struct device_d* dev)
 {
 	dev_info(dev, "running at %lu Hz\n", riscv_timebase);
 
+	if (riscv_use_csr_cycle) {
+		riscv_clocksource.read = riscv_timer_get_count_cycle;
+	} else {
+		riscv_clocksource.read = riscv_timer_get_count_time;
+	}
+
 	riscv_clocksource.mult = clocksource_hz2mult(riscv_timebase, riscv_clocksource.shift);
 
 	return init_clock(&riscv_clocksource);
Signature · 4 lines
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 |
Signature · 9 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#5 lore raw

PATCH v2 2/11 RISC-V: make RISCV_SBI and RISCV_M_MODE explicitly mutually exclusive

In reply to Antony Pavlov
---
 arch/riscv/Kconfig                         | 22 ++++++++++++----------
 arch/riscv/Kconfig.socs                    |  4 +++-
 arch/riscv/configs/erizo_generic_defconfig |  1 +
 3 files changed, 16 insertions(+), 11 deletions(-)
arch/riscv/Kconfig +12 -10
index a4aa799acf..dcff00d63f 100644
@@ -38,6 +38,18 @@ config ARCH_RV64I
 
 endchoice
 
+choice
+	prompt "Privilege level"
+	default RISCV_SBI
+
+config RISCV_SBI
+	bool "S-mode (supervisor mode), use SBI calls"
+
+config RISCV_M_MODE
+	bool "M-mode (machine mode)"
+
+endchoice
+
 source "arch/riscv/Kconfig.socs"
 
 config CPU_SUPPORTS_32BIT_KERNEL
@@ -97,14 +109,4 @@ config NMON_HELP
 	  Say yes here to get the nmon commands message on
 	  every nmon start.
 
-# set if we run in machine mode, cleared if we run in supervisor mode
-config RISCV_M_MODE
-	bool
-
-# set if we are running in S-mode and can use SBI calls
-config RISCV_SBI
-	bool
-	depends on !RISCV_M_MODE
-	default y
-
 endmenu
arch/riscv/Kconfig.socs +3 -1
index c6875738d0..f767942f34 100644
@@ -3,10 +3,10 @@ menu "SoC selection"
 config SOC_ERIZO
 	bool "Erizo SoC"
 	depends on ARCH_RV32I
+	depends on RISCV_M_MODE
 	select HAS_ASM_DEBUG_LL
 	select HAS_NMON
 	select USE_COMPRESSED_DTB
-	select RISCV_M_MODE
 	select RISCV_TIMER
 
 config BOARD_ERIZO_GENERIC
@@ -15,6 +15,7 @@ config BOARD_ERIZO_GENERIC
 
 config SOC_VIRT
 	bool "QEMU Virt Machine"
+	depends on RISCV_SBI
 	select BOARD_RISCV_GENERIC_DT
 	select CLINT_TIMER
 	help
@@ -23,6 +24,7 @@ config SOC_VIRT
 
 config SOC_SIFIVE
 	bool "SiFive SoCs"
+	depends on RISCV_SBI
 	select CLK_SIFIVE
 	select CLK_SIFIVE_PRCI
 	select RISCV_TIMER
arch/riscv/configs/erizo_generic_defconfig +1 -0
index 247a179130..16168eef66 100644
@@ -1,3 +1,4 @@
+CONFIG_RISCV_M_MODE=y
 CONFIG_SOC_ERIZO=y
 # CONFIG_GLOBALVAR is not set
 CONFIG_STACK_SIZE=0x20000
Signature · 7 lines
2.31.1


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#6 lore raw

Re: [PATCH v2 02/11] RISC-V: make RISCV_SBI and RISCV_M_MODE explicitly mutually exclusive

Hello,

Quoted 16 lines · Antony Pavlov
---
 arch/riscv/Kconfig                         | 22 ++++++++++++----------
 arch/riscv/Kconfig.socs                    |  4 +++-
 arch/riscv/configs/erizo_generic_defconfig |  1 +
 3 files changed, 16 insertions(+), 11 deletions(-)
arch/riscv/Kconfig +1 -0
index a4aa799acf..dcff00d63f 100644
@@ -38,6 +38,18 @@ config ARCH_RV64I
 
 endchoice
 
+choice

arch/riscv/Kconfig config ARCH_RV64I · line 51

Quoted 10 lines
arch/riscv/Kconfig +10 -0
+	prompt "Privilege level"
+	default RISCV_SBI
+
+config RISCV_SBI
+	bool "S-mode (supervisor mode), use SBI calls"
+
+config RISCV_M_MODE
+	bool "M-mode (machine mode)"
+
+endchoice

Hmm. I am wondering if we shouldn't just make both selectable at the same time and fix code to call a function that determines mode dynamically? e.g.

enum riscv_mode { RISCV_M_MODE = 1, RISCV_S_MODE = 2 };

static inline enum riscv_mode riscv_get_mode(void)

{
	if (IS_ENABLED(CONFIG_RISCV_M_MODE) && IS_ENABLED(CONFIG_RISCV_S_MODE)) {
		/* somehow determine it dynamically */
	}

	return IS_ENABLED(CONFIG_RISCV_M_MODE) ? RISCV_M_MODE : RISCV_S_MODE;
}

I would really like to have a riscv{32,64}_defconfig that can just build all boards at once. Do you know if this could be dynamically determined?

Quoted 61 lines
arch/riscv/Kconfig +1 -10
+
 source "arch/riscv/Kconfig.socs"
 
 config CPU_SUPPORTS_32BIT_KERNEL
@@ -97,14 +109,4 @@ config NMON_HELP
 	  Say yes here to get the nmon commands message on
 	  every nmon start.
 
-# set if we run in machine mode, cleared if we run in supervisor mode
-config RISCV_M_MODE
-	bool
-
-# set if we are running in S-mode and can use SBI calls
-config RISCV_SBI
-	bool
-	depends on !RISCV_M_MODE
-	default y
-
 endmenu
arch/riscv/Kconfig.socs +3 -1
index c6875738d0..f767942f34 100644
@@ -3,10 +3,10 @@ menu "SoC selection"
 config SOC_ERIZO
 	bool "Erizo SoC"
 	depends on ARCH_RV32I
+	depends on RISCV_M_MODE
 	select HAS_ASM_DEBUG_LL
 	select HAS_NMON
 	select USE_COMPRESSED_DTB
-	select RISCV_M_MODE
 	select RISCV_TIMER
 
 config BOARD_ERIZO_GENERIC
@@ -15,6 +15,7 @@ config BOARD_ERIZO_GENERIC
 
 config SOC_VIRT
 	bool "QEMU Virt Machine"
+	depends on RISCV_SBI
 	select BOARD_RISCV_GENERIC_DT
 	select CLINT_TIMER
 	help
@@ -23,6 +24,7 @@ config SOC_VIRT
 
 config SOC_SIFIVE
 	bool "SiFive SoCs"
+	depends on RISCV_SBI
 	select CLK_SIFIVE
 	select CLK_SIFIVE_PRCI
 	select RISCV_TIMER
arch/riscv/configs/erizo_generic_defconfig +1 -0
index 247a179130..16168eef66 100644
@@ -1,3 +1,4 @@
+CONFIG_RISCV_M_MODE=y
 CONFIG_SOC_ERIZO=y
 # CONFIG_GLOBALVAR is not set
 CONFIG_STACK_SIZE=0x20000
Signature · 9 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#7 lore raw

Re: [PATCH v2 02/11] RISC-V: make RISCV_SBI and RISCV_M_MODE explicitly mutually exclusive

On Fri, 7 May 2021 13:42:00 +0200
Ahmad Fatoum <[email protected]> wrote:

Hi Ahmad!

Quoted 46 lines

Hello,

Quoted 16 lines · Antony Pavlov
---
 arch/riscv/Kconfig                         | 22 ++++++++++++----------
 arch/riscv/Kconfig.socs                    |  4 +++-
 arch/riscv/configs/erizo_generic_defconfig |  1 +
 3 files changed, 16 insertions(+), 11 deletions(-)
arch/riscv/Kconfig +1 -0
index a4aa799acf..dcff00d63f 100644
@@ -38,6 +38,18 @@ config ARCH_RV64I
 
 endchoice
 
+choice

arch/riscv/Kconfig config ARCH_RV64I · line 51

Quoted 10 lines
arch/riscv/Kconfig +10 -0
+	prompt "Privilege level"
+	default RISCV_SBI
+
+config RISCV_SBI
+	bool "S-mode (supervisor mode), use SBI calls"
+
+config RISCV_M_MODE
+	bool "M-mode (machine mode)"
+
+endchoice

Hmm. I am wondering if we shouldn't just make both selectable at the same time and fix code to call a function that determines mode dynamically? e.g.

enum riscv_mode { RISCV_M_MODE = 1, RISCV_S_MODE = 2 };

static inline enum riscv_mode riscv_get_mode(void)

{
	if (IS_ENABLED(CONFIG_RISCV_M_MODE) && IS_ENABLED(CONFIG_RISCV_S_MODE)) {
		/* somehow determine it dynamically */
	}

	return IS_ENABLED(CONFIG_RISCV_M_MODE) ? RISCV_M_MODE : RISCV_S_MODE;
}
Quoted 2 lines

I would really like to have a riscv{32,64}_defconfig that can just build all boards at once. Do you know if this could be dynamically determined?

At the moment I have not answer.
I'll try to investigate dynamic mode determination, it's very attractive idea.

On the other hand compile time mode selection is not the show stopper for "one defconfig to build them all": we have to make STACK_SIZE and MALLOC_SIZE per-board parameters not per-defconfig parameters like now.

If we could make STACK_SIZE and MALLOC_SIZE per-board compile-time parameters then we can make RISC-V mode per-board compile-time parameter too. Is this solution acceptable?

Quoted 67 lines
Quoted 61 lines
arch/riscv/Kconfig +1 -10
+
 source "arch/riscv/Kconfig.socs"
 
 config CPU_SUPPORTS_32BIT_KERNEL
@@ -97,14 +109,4 @@ config NMON_HELP
 	  Say yes here to get the nmon commands message on
 	  every nmon start.
 
-# set if we run in machine mode, cleared if we run in supervisor mode
-config RISCV_M_MODE
-	bool
-
-# set if we are running in S-mode and can use SBI calls
-config RISCV_SBI
-	bool
-	depends on !RISCV_M_MODE
-	default y
-
 endmenu
arch/riscv/Kconfig.socs +3 -1
index c6875738d0..f767942f34 100644
@@ -3,10 +3,10 @@ menu "SoC selection"
 config SOC_ERIZO
 	bool "Erizo SoC"
 	depends on ARCH_RV32I
+	depends on RISCV_M_MODE
 	select HAS_ASM_DEBUG_LL
 	select HAS_NMON
 	select USE_COMPRESSED_DTB
-	select RISCV_M_MODE
 	select RISCV_TIMER
 
 config BOARD_ERIZO_GENERIC
@@ -15,6 +15,7 @@ config BOARD_ERIZO_GENERIC
 
 config SOC_VIRT
 	bool "QEMU Virt Machine"
+	depends on RISCV_SBI
 	select BOARD_RISCV_GENERIC_DT
 	select CLINT_TIMER
 	help
@@ -23,6 +24,7 @@ config SOC_VIRT
 
 config SOC_SIFIVE
 	bool "SiFive SoCs"
+	depends on RISCV_SBI
 	select CLK_SIFIVE
 	select CLK_SIFIVE_PRCI
 	select RISCV_TIMER
arch/riscv/configs/erizo_generic_defconfig +1 -0
index 247a179130..16168eef66 100644
@@ -1,3 +1,4 @@
+CONFIG_RISCV_M_MODE=y
 CONFIG_SOC_ERIZO=y
 # CONFIG_GLOBALVAR is not set
 CONFIG_STACK_SIZE=0x20000
Signature · 4 lines
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 |
Signature · 7 lines
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#8 lore raw

Re: [PATCH v2 02/11] RISC-V: make RISCV_SBI and RISCV_M_MODE explicitly mutually exclusive

Hello Antony,

Quoted 6 lines · Antony Pavlov
Quoted 2 lines

I would really like to have a riscv{32,64}_defconfig that can just build all boards at once. Do you know if this could be dynamically determined?

At the moment I have not answer.
I'll try to investigate dynamic mode determination, it's very attractive idea.

Quoted 7 lines

On the other hand compile time mode selection is not the show stopper for "one defconfig to build them all": we have to make STACK_SIZE and MALLOC_SIZE per-board parameters not per-defconfig parameters like now.

If we could make STACK_SIZE and MALLOC_SIZE per-board compile-time parameters then we can make RISC-V mode per-board compile-time parameter too. Is this solution acceptable?

MALLOC_SIZE can be set as 0 and barebox will determine it based on membase + memsize that are set by PBL.

STACK_SIZE must be set per Kconfig, but I think even a generous default stack size should accommodate all targets.

If we do the same for RISC-V mode that would probably mean having two functions barebox_riscv_machine_entry() and barebox_riscv_supervisor_entry() in PBL that take care to pass the correct info to barebox proper.

Apparently, you can determine mode if you catch exceptions:
https://forums.sifive.com/t/how-to-determine-the-current-execution-privilege-mode/2823

We don't yet install exception handlers in barebox, but I am fine with using different PBL common code entry functions.

What do you think?

Cheers,
Ahmad

Quoted 70 lines
Quoted 68 lines
Quoted 62 lines
arch/riscv/Kconfig +1 -10
+
 source "arch/riscv/Kconfig.socs"
 
 config CPU_SUPPORTS_32BIT_KERNEL
@@ -97,14 +109,4 @@ config NMON_HELP
 	  Say yes here to get the nmon commands message on
 	  every nmon start.
 
-# set if we run in machine mode, cleared if we run in supervisor mode
-config RISCV_M_MODE
-	bool
-
-# set if we are running in S-mode and can use SBI calls
-config RISCV_SBI
-	bool
-	depends on !RISCV_M_MODE
-	default y
-
 endmenu
arch/riscv/Kconfig.socs +3 -1
index c6875738d0..f767942f34 100644
@@ -3,10 +3,10 @@ menu "SoC selection"
 config SOC_ERIZO
 	bool "Erizo SoC"
 	depends on ARCH_RV32I
+	depends on RISCV_M_MODE
 	select HAS_ASM_DEBUG_LL
 	select HAS_NMON
 	select USE_COMPRESSED_DTB
-	select RISCV_M_MODE
 	select RISCV_TIMER
 
 config BOARD_ERIZO_GENERIC
@@ -15,6 +15,7 @@ config BOARD_ERIZO_GENERIC
 
 config SOC_VIRT
 	bool "QEMU Virt Machine"
+	depends on RISCV_SBI
 	select BOARD_RISCV_GENERIC_DT
 	select CLINT_TIMER
 	help
@@ -23,6 +24,7 @@ config SOC_VIRT
 
 config SOC_SIFIVE
 	bool "SiFive SoCs"
+	depends on RISCV_SBI
 	select CLK_SIFIVE
 	select CLK_SIFIVE_PRCI
 	select RISCV_TIMER
arch/riscv/configs/erizo_generic_defconfig +1 -0
index 247a179130..16168eef66 100644
@@ -1,3 +1,4 @@
+CONFIG_RISCV_M_MODE=y
 CONFIG_SOC_ERIZO=y
 # CONFIG_GLOBALVAR is not set
 CONFIG_STACK_SIZE=0x20000
Signature · 4 lines
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 |
Signature · 9 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#9 lore raw

Re: [PATCH v2 02/11] RISC-V: make RISCV_SBI and RISCV_M_MODE explicitly mutually exclusive

On Fri, 7 May 2021 16:44:24 +0200
Ahmad Fatoum <[email protected]> wrote:

Hi Ahmad !

Quoted 23 lines

Hello Antony,

Quoted 6 lines · Antony Pavlov
Quoted 2 lines

I would really like to have a riscv{32,64}_defconfig that can just build all boards at once. Do you know if this could be dynamically determined?

At the moment I have not answer.
I'll try to investigate dynamic mode determination, it's very attractive idea.

Quoted 7 lines

On the other hand compile time mode selection is not the show stopper for "one defconfig to build them all": we have to make STACK_SIZE and MALLOC_SIZE per-board parameters not per-defconfig parameters like now.

If we could make STACK_SIZE and MALLOC_SIZE per-board compile-time parameters then we can make RISC-V mode per-board compile-time parameter too. Is this solution acceptable?

MALLOC_SIZE can be set as 0 and barebox will determine it based on membase + memsize that are set by PBL.

STACK_SIZE must be set per Kconfig, but I think even a generous default stack size should accommodate all targets.

Quoted 6 lines

If we do the same for RISC-V mode that would probably mean having two functions barebox_riscv_machine_entry() and barebox_riscv_supervisor_entry() in PBL that take care to pass the correct info to barebox proper.

Apparently, you can determine mode if you catch exceptions:
https://forums.sifive.com/t/how-to-determine-the-current-execution-privilege-mode/2823

Hmm, answer is mostly negative:

<<
RISC-V deliberately doesn’t make it easy for code to discover what mode it is running it because this is a virtualisation hole. As a general principle, code should be designed for and implicitly know what mode it will run in.

Quoted 6 lines
Quoted 1 line

We don't yet install exception handlers in barebox, but I am fine with using different PBL common code entry functions.

What do you think?

I think that adding exception handling to barebox would be very handy.
At the moment barebox sometimes hangs during my experiments without any error message. Even with a simple exception handler that just prints out epc, status and cause registers I have much more information on hang reason.

Signature · 2 lines
Best regards,
  Antony Pavlov
Quoted 62 lines
Quoted 62 lines
Quoted 62 lines
Quoted 62 lines
arch/riscv/Kconfig +1 -10
+
 source "arch/riscv/Kconfig.socs"
 
 config CPU_SUPPORTS_32BIT_KERNEL
@@ -97,14 +109,4 @@ config NMON_HELP
 	  Say yes here to get the nmon commands message on
 	  every nmon start.
 
-# set if we run in machine mode, cleared if we run in supervisor mode
-config RISCV_M_MODE
-	bool
-
-# set if we are running in S-mode and can use SBI calls
-config RISCV_SBI
-	bool
-	depends on !RISCV_M_MODE
-	default y
-
 endmenu
arch/riscv/Kconfig.socs +3 -1
index c6875738d0..f767942f34 100644
@@ -3,10 +3,10 @@ menu "SoC selection"
 config SOC_ERIZO
 	bool "Erizo SoC"
 	depends on ARCH_RV32I
+	depends on RISCV_M_MODE
 	select HAS_ASM_DEBUG_LL
 	select HAS_NMON
 	select USE_COMPRESSED_DTB
-	select RISCV_M_MODE
 	select RISCV_TIMER
 
 config BOARD_ERIZO_GENERIC
@@ -15,6 +15,7 @@ config BOARD_ERIZO_GENERIC
 
 config SOC_VIRT
 	bool "QEMU Virt Machine"
+	depends on RISCV_SBI
 	select BOARD_RISCV_GENERIC_DT
 	select CLINT_TIMER
 	help
@@ -23,6 +24,7 @@ config SOC_VIRT
 
 config SOC_SIFIVE
 	bool "SiFive SoCs"
+	depends on RISCV_SBI
 	select CLK_SIFIVE
 	select CLK_SIFIVE_PRCI
 	select RISCV_TIMER
arch/riscv/configs/erizo_generic_defconfig +1 -0
index 247a179130..16168eef66 100644
@@ -1,3 +1,4 @@
+CONFIG_RISCV_M_MODE=y
 CONFIG_SOC_ERIZO=y
 # CONFIG_GLOBALVAR is not set
 CONFIG_STACK_SIZE=0x20000
Quoted 14 lines
Quoted 8 lines
Quoted 6 lines
Signature · 5 lines
-- 
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 |
Signature · 4 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox

#10 lore raw

Re: [PATCH v2 02/11] RISC-V: make RISCV_SBI and RISCV_M_MODE explicitly mutually exclusive

Hi,

Quoted 47 lines · Antony Pavlov

On Fri, 7 May 2021 16:44:24 +0200
Ahmad Fatoum <[email protected]> wrote:

Hi Ahmad !

Quoted 23 lines

Hello Antony,

Quoted 6 lines · Antony Pavlov
Quoted 2 lines

I would really like to have a riscv{32,64}_defconfig that can just build all boards at once. Do you know if this could be dynamically determined?

At the moment I have not answer.
I'll try to investigate dynamic mode determination, it's very attractive idea.

Quoted 7 lines

On the other hand compile time mode selection is not the show stopper for "one defconfig to build them all": we have to make STACK_SIZE and MALLOC_SIZE per-board parameters not per-defconfig parameters like now.

If we could make STACK_SIZE and MALLOC_SIZE per-board compile-time parameters then we can make RISC-V mode per-board compile-time parameter too. Is this solution acceptable?

MALLOC_SIZE can be set as 0 and barebox will determine it based on membase + memsize that are set by PBL.

STACK_SIZE must be set per Kconfig, but I think even a generous default stack size should accommodate all targets.

Quoted 6 lines

If we do the same for RISC-V mode that would probably mean having two functions barebox_riscv_machine_entry() and barebox_riscv_supervisor_entry() in PBL that take care to pass the correct info to barebox proper.

Apparently, you can determine mode if you catch exceptions:
https://forums.sifive.com/t/how-to-determine-the-current-execution-privilege-mode/2823

Hmm, answer is mostly negative:

<<
RISC-V deliberately doesn’t make it easy for code to discover what mode it is running it because this is a virtualisation hole. As a general principle, code should be designed for and implicitly know what mode it will run in.

Quoted 5 lines
Quoted 1 line

We don't yet install exception handlers in barebox, but I am fine with using different PBL common code entry functions.

Quoted 6 lines
Quoted 1 line

What do you think?

I think that adding exception handling to barebox would be very handy.
At the moment barebox sometimes hangs during my experiments without any error message. Even with a simple exception handler that just prints out epc, status and cause registers I have much more information on hang reason.

Exception handling would be useful, no doubt. Rouven is looking into adding that.

I was asking about what you think about adding barebox_riscv_machine_entry() and barebox_riscv_supervisor_entry(), so PBL entry points can decide for themselves what mode the rest of barebox should get when riscv_mode() is called. I'll CC you on the series.

Cheers,
Ahmad

Signature · 9 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#11 lore raw

Re: [PATCH v2 02/11] RISC-V: make RISCV_SBI and RISCV_M_MODE explicitly mutually exclusive

On Fri, 7 May 2021 20:08:48 +0200
Ahmad Fatoum <[email protected]> wrote:

Hi Ahmad!

Quoted 55 lines · Antony Pavlov
Quoted 47 lines

On Fri, 7 May 2021 16:44:24 +0200
Ahmad Fatoum <[email protected]> wrote:

Hi Ahmad !

Quoted 23 lines

Hello Antony,

Quoted 6 lines · Antony Pavlov
Quoted 2 lines

I would really like to have a riscv{32,64}_defconfig that can just build all boards at once. Do you know if this could be dynamically determined?

At the moment I have not answer.
I'll try to investigate dynamic mode determination, it's very attractive idea.

Quoted 7 lines

On the other hand compile time mode selection is not the show stopper for "one defconfig to build them all": we have to make STACK_SIZE and MALLOC_SIZE per-board parameters not per-defconfig parameters like now.

If we could make STACK_SIZE and MALLOC_SIZE per-board compile-time parameters then we can make RISC-V mode per-board compile-time parameter too. Is this solution acceptable?

MALLOC_SIZE can be set as 0 and barebox will determine it based on membase + memsize that are set by PBL.

STACK_SIZE must be set per Kconfig, but I think even a generous default stack size should accommodate all targets.

Quoted 6 lines

If we do the same for RISC-V mode that would probably mean having two functions barebox_riscv_machine_entry() and barebox_riscv_supervisor_entry() in PBL that take care to pass the correct info to barebox proper.

Apparently, you can determine mode if you catch exceptions:
https://forums.sifive.com/t/how-to-determine-the-current-execution-privilege-mode/2823

Hmm, answer is mostly negative:

<<
RISC-V deliberately doesn’t make it easy for code to discover what mode it is running it because this is a virtualisation hole. As a general principle, code should be designed for and implicitly know what mode it will run in.

Quoted 5 lines
Quoted 1 line

We don't yet install exception handlers in barebox, but I am fine with using different PBL common code entry functions.

Quoted 6 lines
Quoted 1 line

What do you think?

I think that adding exception handling to barebox would be very handy.
At the moment barebox sometimes hangs during my experiments without any error message. Even with a simple exception handler that just prints out epc, status and cause registers I have much more information on hang reason.

Quoted 7 lines

Exception handling would be useful, no doubt. Rouven is looking into adding that.

I was asking about what you think about adding barebox_riscv_machine_entry() and barebox_riscv_supervisor_entry(), so PBL entry points can decide for themselves what mode the rest of barebox should get when riscv_mode() is called. I'll CC you on the series.

Can we just add one more 'int mode' argument to barebox_riscv_entry()?

Signature · 7 lines
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#12 lore raw

PATCH v2 3/11 RISC-V: make it possible to run nmon from PBL C code

In reply to Antony Pavlov

After migrating to PBL we can't use nmon assembler macro in C code anymore. Some changes are introduced to invoke nmon from PBL C code:

* use 'lla' macro instruction instead of 'la';
* don't touch the 'ra' register, use 'a2' instead;
* add wrapper C function for nmon.

---
 arch/riscv/boot/Makefile            |  1 +
 arch/riscv/boot/nmon_entry.S        | 13 ++++++++
 arch/riscv/include/asm/riscv_nmon.h | 49 +++++++++++++++++++----------
 3 files changed, 46 insertions(+), 17 deletions(-)
arch/riscv/boot/Makefile +1 -0
index 968a826d16..80f63a4a0a 100644
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-y += start.o
 pbl-y += entry.o uncompress.o
+pbl-y += nmon_entry.o
 pbl-$(CONFIG_BOARD_GENERIC_DT) += board-dt-2nd.o
arch/riscv/boot/nmon_entry.S new file +13 -0
new file mode 100644
index 0000000000..ae017d2a1c
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#include <linux/linkage.h>
+#include <asm/sections.h>
+
+#include "asm/debug_ll.h"
+#include "asm/riscv_nmon.h"
+
+.section .text_bare_init
+
+ENTRY(__barebox_nmon_entry)
+	riscv_nmon
+	ret
+ENDPROC(__barebox_nmon_entry)
arch/riscv/include/asm/riscv_nmon.h +32 -17

110 lines not on this page · raw message

Signature · 7 lines
2.31.1


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#13 lore raw

PATCH v2 4/11 RISC-V: boards: erizo: make it possible to use nmon

In reply to Antony Pavlov
---
 arch/riscv/boards/erizo/lowlevel.c | 3 +++
 1 file changed, 3 insertions(+)
arch/riscv/boards/erizo/lowlevel.c +3 -0
index d9edb530b7..fd899c8679 100644
@@ -3,12 +3,15 @@
 #include <common.h>
 #include <asm/barebox-riscv.h>
 #include <debug_ll.h>
+#include <asm/riscv_nmon.h>
 
 ENTRY_FUNCTION(start_erizo_generic, a0, a1, a2)
 {
 	extern char __dtb_z_erizo_generic_start[];
 
 	debug_ll_ns16550_init();
+	barebox_nmon_entry();
+
 	putc_ll('>');
 
 	/* On POR, we are running from read-only memory here. */
Signature · 7 lines
2.31.1


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#14 lore raw

PATCH v2 5/11 serial: add litex UART driver

In reply to Antony Pavlov
---
 drivers/serial/Makefile       |  1 +
 drivers/serial/serial_litex.c | 96 +++++++++++++++++++++++++++++++++++
 2 files changed, 97 insertions(+)
drivers/serial/Makefile +1 -0
index 5120b17376..45055371ea 100644
@@ -24,3 +24,4 @@ obj-$(CONFIG_DRIVER_SERIAL_DIGIC)		+= serial_digic.o
 obj-$(CONFIG_DRIVER_SERIAL_LPUART)		+= serial_lpuart.o
 obj-$(CONFIG_VIRTIO_CONSOLE)			+= virtio_console.o
 obj-$(CONFIG_SERIAL_SIFIVE)			+= serial_sifive.o
+obj-$(CONFIG_SOC_LITEX)				+= serial_litex.o
drivers/serial/serial_litex.c new file +96 -0

96 lines not on this page · raw message

Signature · 7 lines
2.31.1


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#15 lore raw

Re: [PATCH v2 05/11] serial: add litex UART driver

Hi,

Quoted 87 lines · Antony Pavlov
---
 drivers/serial/Makefile       |  1 +
 drivers/serial/serial_litex.c | 96 +++++++++++++++++++++++++++++++++++
 2 files changed, 97 insertions(+)
drivers/serial/Makefile +1 -0
index 5120b17376..45055371ea 100644
@@ -24,3 +24,4 @@ obj-$(CONFIG_DRIVER_SERIAL_DIGIC)		+= serial_digic.o
 obj-$(CONFIG_DRIVER_SERIAL_LPUART)		+= serial_lpuart.o
 obj-$(CONFIG_VIRTIO_CONSOLE)			+= virtio_console.o
 obj-$(CONFIG_SERIAL_SIFIVE)			+= serial_sifive.o
+obj-$(CONFIG_SOC_LITEX)				+= serial_litex.o
drivers/serial/serial_litex.c new file +66 -0
new file mode 100644
index 0000000000..8562a45ecc
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Antony Pavlov <[email protected]>
+ *
+ */
+
+#include <common.h>
+#include <init.h>
+#include <io.h>
+
+#define UART_RXTX	0x00
+#define UART_TXFULL	0x04
+#define UART_RXEMPTY	0x08
+#define UART_EV_PENDING	0x10
+#define  UART_EV_RX	(1 << 1)
+
+static inline uint32_t litex_serial_readb(struct console_device *cdev,
+						uint32_t offset)
+{
+	void __iomem *base = cdev->dev->priv;
+
+	return readb(base + offset);
+}
+
+static inline void litex_serial_writeb(struct console_device *cdev,
+					uint32_t value, uint32_t offset)
+{
+	void __iomem *base = cdev->dev->priv;
+
+	writeb(value, base + offset);
+}
+
+static void litex_serial_putc(struct console_device *cdev, char c)
+{
+	while (litex_serial_readb(cdev, UART_TXFULL))
+		;
+
+	litex_serial_writeb(cdev, c, UART_RXTX);
+}
+
+static int litex_serial_getc(struct console_device *cdev)
+{
+	int c;
+
+	while (litex_serial_readb(cdev, UART_RXEMPTY))
+		;
+
+	c = litex_serial_readb(cdev, UART_RXTX);
+
+	/* refresh UART_RXEMPTY by writing UART_EV_RX to UART_EV_PENDING */
+	litex_serial_writeb(cdev, UART_EV_RX, UART_EV_PENDING);
+
+	return c;
+}
+
+static int litex_serial_tstc(struct console_device *cdev)
+{
+	return !litex_serial_readb(cdev, UART_RXEMPTY);
+}
+
+static int litex_serial_probe(struct device_d *dev)
+{
+	struct resource *iores;
+	struct console_device *cdev;
+
+	cdev = xzalloc(sizeof(struct console_device));

drivers/serial/serial_litex.c line 76

Quoted 10 lines
drivers/serial/serial_litex.c new file +10 -0
+	iores = dev_request_mem_resource(dev, 0);
+	if (IS_ERR(iores))
+		return PTR_ERR(iores);
+
+	dev->priv = IOMEM(iores->start);
+	cdev->dev = dev;
+	cdev->tstc = &litex_serial_tstc;
+	cdev->putc = &litex_serial_putc;
+	cdev->getc = &litex_serial_getc;
+	cdev->setbrg = NULL;

Does the IP only output a fixed baudrate/configuration?

Quoted 21 lines
drivers/serial/serial_litex.c new file +20 -0
+
+	console_register(cdev);
+
+	return 0;
+}
+
+static __maybe_unused struct of_device_id litex_serial_dt_ids[] = {
+	{
+		.compatible = "litex,uart",
+	}, {
+		/* sentinel */
+	}
+};
+
+static struct driver_d litex_serial_driver = {
+	.name  = "litex-uart",
+	.probe = litex_serial_probe,
+	.of_compatible = DRV_OF_COMPAT(litex_serial_dt_ids),
+};
+console_platform_driver(litex_serial_driver);
Signature · 9 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#16 lore raw

Re: [PATCH v2 05/11] serial: add litex UART driver

Quoted 94 lines · On Fri, 7 May 2021 13:45:57 +0200 Ahmad Fatoum <[email protected]> wrote:

Hi,

Quoted 91 lines · Antony Pavlov
---
 drivers/serial/Makefile       |  1 +
 drivers/serial/serial_litex.c | 96 +++++++++++++++++++++++++++++++++++
 2 files changed, 97 insertions(+)
drivers/serial/Makefile +1 -0
index 5120b17376..45055371ea 100644
@@ -24,3 +24,4 @@ obj-$(CONFIG_DRIVER_SERIAL_DIGIC)		+= serial_digic.o
 obj-$(CONFIG_DRIVER_SERIAL_LPUART)		+= serial_lpuart.o
 obj-$(CONFIG_VIRTIO_CONSOLE)			+= virtio_console.o
 obj-$(CONFIG_SERIAL_SIFIVE)			+= serial_sifive.o
+obj-$(CONFIG_SOC_LITEX)				+= serial_litex.o
drivers/serial/serial_litex.c new file +70 -0
new file mode 100644
index 0000000000..8562a45ecc
@@ -0,0 +1,96 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Antony Pavlov <[email protected]>
+ *
+ */
+
+#include <common.h>
+#include <init.h>
+#include <io.h>
+
+#define UART_RXTX	0x00
+#define UART_TXFULL	0x04
+#define UART_RXEMPTY	0x08
+#define UART_EV_PENDING	0x10
+#define  UART_EV_RX	(1 << 1)
+
+static inline uint32_t litex_serial_readb(struct console_device *cdev,
+						uint32_t offset)
+{
+	void __iomem *base = cdev->dev->priv;
+
+	return readb(base + offset);
+}
+
+static inline void litex_serial_writeb(struct console_device *cdev,
+					uint32_t value, uint32_t offset)
+{
+	void __iomem *base = cdev->dev->priv;
+
+	writeb(value, base + offset);
+}
+
+static void litex_serial_putc(struct console_device *cdev, char c)
+{
+	while (litex_serial_readb(cdev, UART_TXFULL))
+		;
+
+	litex_serial_writeb(cdev, c, UART_RXTX);
+}
+
+static int litex_serial_getc(struct console_device *cdev)
+{
+	int c;
+
+	while (litex_serial_readb(cdev, UART_RXEMPTY))
+		;
+
+	c = litex_serial_readb(cdev, UART_RXTX);
+
+	/* refresh UART_RXEMPTY by writing UART_EV_RX to UART_EV_PENDING */
+	litex_serial_writeb(cdev, UART_EV_RX, UART_EV_PENDING);
+
+	return c;
+}
+
+static int litex_serial_tstc(struct console_device *cdev)
+{
+	return !litex_serial_readb(cdev, UART_RXEMPTY);
+}
+
+static int litex_serial_probe(struct device_d *dev)
+{
+	struct resource *iores;
+	struct console_device *cdev;
+
+	cdev = xzalloc(sizeof(struct console_device));
+	iores = dev_request_mem_resource(dev, 0);
+	if (IS_ERR(iores))
+		return PTR_ERR(iores);
+
Quoted 8 lines

drivers/serial/serial_litex.c line 76

Quoted 6 lines
drivers/serial/serial_litex.c new file +6 -0
+	dev->priv = IOMEM(iores->start);
+	cdev->dev = dev;
+	cdev->tstc = &litex_serial_tstc;
+	cdev->putc = &litex_serial_putc;
+	cdev->getc = &litex_serial_getc;
+	cdev->setbrg = NULL;

Does the IP only output a fixed baudrate/configuration?

Yes, this IP works at fixed baudrate.

Baudrate is selected during FPGA bitstream compilation,
e.g. see https://github.com/litex-hub/linux-on-litex-vexriscv/commit/0b133cc3

At the moment there is a problem with this fixed speed port: loady command does not work.

Quoted 27 lines
Quoted 21 lines
drivers/serial/serial_litex.c new file +20 -0
+
+	console_register(cdev);
+
+	return 0;
+}
+
+static __maybe_unused struct of_device_id litex_serial_dt_ids[] = {
+	{
+		.compatible = "litex,uart",
+	}, {
+		/* sentinel */
+	}
+};
+
+static struct driver_d litex_serial_driver = {
+	.name  = "litex-uart",
+	.probe = litex_serial_probe,
+	.of_compatible = DRV_OF_COMPAT(litex_serial_dt_ids),
+};
+console_platform_driver(litex_serial_driver);
Signature · 4 lines
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 |
Signature · 7 lines
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#17 lore raw

PATCH v2 6/11 gpio: add driver for 74xx-ICs with MMIO access

In reply to Antony Pavlov

This patch adds driver to support GPIO functionality for 74xx-compatible ICs with MMIO access.

Compatible models include:

     1 bit:   741G125 (Input), 741G74 (Output)
     2 bits:  742G125 (Input), 7474 (Output)
     4 bits:  74125 (Input), 74175 (Output)
     6 bits:  74365 (Input), 74174 (Output)
     8 bits:  74244 (Input), 74273 (Output)
     16 bits: 741624 (Input), 7416374 (Output)
Cc Alexander Shiyan <[email protected]>
---
 drivers/gpio/Kconfig          |  14 +++
 drivers/gpio/Makefile         |   1 +
 drivers/gpio/gpio-74xx-mmio.c | 166 ++++++++++++++++++++++++++++++++++
 3 files changed, 181 insertions(+)
drivers/gpio/Kconfig +14 -0
index a8ee9e58b8..579d5c04b3 100644
@@ -21,6 +21,20 @@ config GPIO_74164
 	  shift registers. This driver can be used to provide access
 	  to more gpio outputs.
 
+config GPIO_74XX_MMIO
+	tristate "GPIO driver for 74xx-ICs with MMIO access"
+	depends on OFDEVICE
+	select GPIO_GENERIC
+	help
+	  Say yes here to support GPIO functionality for 74xx-compatible ICs
+	  with MMIO access. Compatible models include:
+	    1 bit:	741G125 (Input), 741G74 (Output)
+	    2 bits:	742G125 (Input), 7474 (Output)
+	    4 bits:	74125 (Input), 74175 (Output)
+	    6 bits:	74365 (Input), 74174 (Output)
+	    8 bits:	74244 (Input), 74273 (Output)
+	    16 bits:	741624 (Input), 7416374 (Output)
+
 config GPIO_CLPS711X
 	bool "GPIO support for CLPS711X"
 	depends on ARCH_CLPS711X || COMPILE_TEST
drivers/gpio/Makefile +1 -0
index 25e12105d8..41c65fa0ac 100644
@@ -1,6 +1,7 @@
 obj-$(CONFIG_GPIOLIB)		+= gpiolib.o
 
 obj-$(CONFIG_GPIO_74164)	+= gpio-74164.o
+obj-$(CONFIG_GPIO_74XX_MMIO)	+= gpio-74xx-mmio.o
 obj-$(CONFIG_MACH_MIPS_ATH79)	+= gpio-ath79.o
 obj-$(CONFIG_GPIO_DAVINCI)	+= gpio-davinci.o
 obj-$(CONFIG_GPIO_CLPS711X)	+= gpio-clps711x.o
drivers/gpio/gpio-74xx-mmio.c new file +166 -0

166 lines not on this page · raw message

Signature · 7 lines
2.31.1


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#18 lore raw

PATCH v2 7/11 spi: add litex spiflash driver

In reply to Antony Pavlov
---
 drivers/spi/Kconfig          |   3 +
 drivers/spi/Makefile         |   1 +
 drivers/spi/litex_spiflash.c | 241 +++++++++++++++++++++++++++++++++++
 3 files changed, 245 insertions(+)
drivers/spi/Kconfig +3 -0
index 323d93efeb..714d30e909 100644
@@ -74,6 +74,9 @@ config DRIVER_SPI_IMX_2_3
 	depends on ARCH_IMX50 || ARCH_IMX51 || ARCH_IMX53 || ARCH_IMX6 || ARCH_IMX7 || ARCH_IMX8MQ
 	default y
 
+config DRIVER_SPI_LITEX_SPIFLASH
+	bool "Litex SPIFLASH bitbang master driver"
+
 config DRIVER_SPI_MXS
 	bool "i.MX (23,28) SPI Master driver"
 	depends on ARCH_IMX28
drivers/spi/Makefile +1 -0
index 908d514a01..ac95ffc1db 100644
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRIVER_SPI_ATH79) += ath79_spi.o
 obj-$(CONFIG_DRIVER_SPI_GPIO) += gpio_spi.o
 obj-$(CONFIG_DRIVER_SPI_FSL_QUADSPI) += spi-fsl-qspi.o
 obj-$(CONFIG_DRIVER_SPI_IMX) += imx_spi.o
+obj-$(CONFIG_DRIVER_SPI_LITEX_SPIFLASH) += litex_spiflash.o
 obj-$(CONFIG_DRIVER_SPI_MVEBU) += mvebu_spi.o
 obj-$(CONFIG_DRIVER_SPI_MXS) += mxs_spi.o
 obj-$(CONFIG_DRIVER_SPI_ALTERA) += altera_spi.o
drivers/spi/litex_spiflash.c new file +241 -0

241 lines not on this page · raw message

Signature · 7 lines
2.31.1


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#19 lore raw

PATCH v2 8/11 net: add LiteEth driver

In reply to Antony Pavlov

LiteEth provides a small footprint and configurable Ethernet core.

LiteEth is part of LiteX libraries whose aims are to lower entry level of complex FPGA cores by providing simple, elegant and efficient implementations of components used in today's SoC such as Ethernet, SATA, PCIe, SDRAM Controller...

Using Migen to describe the HDL allows the core to be highly and easily configurable.

LiteEth can be used as LiteX library or can be integrated with your standard design flow by generating the verilog rtl that you will use as a standard core.

See https://github.com/enjoy-digital/liteeth for details.

---
 drivers/net/Kconfig   |   8 +
 drivers/net/Makefile  |   1 +
 drivers/net/liteeth.c | 376 ++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 385 insertions(+)
drivers/net/Kconfig +8 -0
index 0d55ea7a3b..4818f52603 100644
@@ -271,6 +271,14 @@ config TSE_USE_DEDICATED_DESC_MEM
 	  reserved with a malloc but directly mapped to the memory
 	  address (defined in config.h)
 
+config DRIVER_NET_LITEETH
+	bool "LiteX ethernet driver"
+	select PHYLIB
+	select MDIO_BITBANG
+	help
+	  This option enables support for the LiteX LiteEth
+	  ethernet IP core.
+
 source "drivers/net/phy/Kconfig"
 source "drivers/net/usb/Kconfig"
 
drivers/net/Makefile +1 -0
index 656d45a868..bb751943f6 100644
@@ -36,3 +36,4 @@ obj-$(CONFIG_DRIVER_NET_TAP)		+= tap.o
 obj-$(CONFIG_DRIVER_NET_TSE)		+= altera_tse.o
 obj-$(CONFIG_DRIVER_NET_EFI_SNP)	+= efi-snp.o
 obj-$(CONFIG_DRIVER_NET_AG71XX)		+= ag71xx.o
+obj-$(CONFIG_DRIVER_NET_LITEETH)	+= liteeth.o
drivers/net/liteeth.c new file +376 -0

376 lines not on this page · raw message

Signature · 7 lines
2.31.1


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#20 lore raw

PATCH v2 9/11 RISC-V: add LiteX SoC and linux-on-litex-vexriscv support

In reply to Antony Pavlov

LiteX is a Migen-based System on Chip, supporting softcore VexRiscv CPU, a 32-bits Linux Capable RISC-V CPU.

See https://github.com/enjoy-digital/litex and
https://github.com/litex-hub/linux-on-litex-vexriscv
for details.

---
 arch/riscv/Kconfig.socs                  |  14 +++
 arch/riscv/boards/Makefile               |   1 +
 arch/riscv/boards/litex-linux/Makefile   |   3 +
 arch/riscv/boards/litex-linux/lowlevel.c |  20 ++++
 arch/riscv/dts/Makefile                  |   1 +
 arch/riscv/dts/litex-linux.dts           |  96 ++++++++++++++++++
 arch/riscv/dts/litex_soc_linux.dtsi      |  49 +++++++++
 arch/riscv/include/asm/debug_ll.h        |   3 +
 arch/riscv/include/asm/debug_ll_litex.h  | 123 +++++++++++++++++++++++
 common/Kconfig                           |   4 +
 images/Makefile.riscv                    |   4 +
 11 files changed, 318 insertions(+)
arch/riscv/Kconfig.socs +14 -0
index f767942f34..07995d1287 100644
@@ -42,4 +42,18 @@ config BOARD_HIFIVE
 
 endif
 
+config SOC_LITEX
+	bool "LiteX SoCs"
+	depends on ARCH_RV32I
+	depends on RISCV_M_MODE
+	select HAS_ASM_DEBUG_LL
+	select HAS_NMON
+	select USE_COMPRESSED_DTB
+	select RISCV_TIMER
+
+config BOARD_LITEX_LINUX
+	bool "litex linux board"
+	depends on SOC_LITEX
+	def_bool y
+
 endmenu
arch/riscv/boards/Makefile +1 -0
index 99f22f32b4..0468871fde 100644
@@ -1,3 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_BOARD_ERIZO_GENERIC)	+= erizo/
 obj-$(CONFIG_BOARD_HIFIVE)		+= hifive/
+obj-$(CONFIG_BOARD_LITEX_LINUX)		+= litex-linux/
arch/riscv/boards/litex-linux/Makefile new file +3 -0
new file mode 100644
index 0000000000..3d217ffe0b
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+pbl-y += lowlevel.o
arch/riscv/boards/litex-linux/lowlevel.c new file +20 -0
new file mode 100644
index 0000000000..ecc5423058
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <common.h>
+#include <asm/barebox-riscv.h>
+#include <debug_ll.h>
+#include <asm/riscv_nmon.h>
+
+ENTRY_FUNCTION(start_litex_linux, a0, a1, a2)
+{
+	extern char __dtb_z_litex_linux_start[];
+
+	barebox_nmon_entry();
+
+	putc_ll('>');
+
+	/* On POR, we are running from read-only memory here. */
+
+	barebox_riscv_entry(0x40000000, SZ_256M,
+			    __dtb_z_litex_linux_start + get_runtime_offset());
+}
arch/riscv/dts/Makefile +1 -0
index 17fdc9445b..683038189f 100644
@@ -7,5 +7,6 @@ obj- += dummy.o
 pbl-$(CONFIG_BOARD_ERIZO_GENERIC) += erizo-generic.dtb.o
 pbl-$(CONFIG_BOARD_HIFIVE) += hifive-unmatched-a00.dtb.o \
                               hifive-unleashed-a00.dtb.o
+pbl-$(CONFIG_BOARD_LITEX_LINUX) += litex-linux.dtb.o
 
 clean-files := *.dtb *.dtb.S .*.dtc .*.pre .*.dts
arch/riscv/dts/litex-linux.dts new file +96 -0

96 lines not on this page · raw message

arch/riscv/dts/litex_soc_linux.dtsi new file +49 -0

49 lines not on this page · raw message

arch/riscv/include/asm/debug_ll.h +3 -0
index 6ef26280d1..2812b97751 100644
@@ -37,6 +37,9 @@ static inline void PUTC_LL(char ch)
 
 	writel(ch, uart0);
 }
+#elif defined CONFIG_DEBUG_LITEX
+
+#include <asm/debug_ll_litex.h>
 
 #endif
 
arch/riscv/include/asm/debug_ll_litex.h new file +123 -0

123 lines not on this page · raw message

common/Kconfig +4 -0
index 6b3c1701be..066a8389cb 100644
@@ -1358,6 +1358,10 @@ config DEBUG_SIFIVE
 	bool "SiFive serial0 port"
 	depends on SOC_SIFIVE
 
+config DEBUG_LITEX
+	bool "LiteX serial port"
+	depends on SOC_LITEX
+
 endchoice
 
 config DEBUG_IMX_UART_PORT
images/Makefile.riscv +4 -0
index c44c683431..24e33f5b11 100644
@@ -15,3 +15,7 @@ pblb-$(CONFIG_BOARD_HIFIVE) += start_hifive_unmatched start_hifive_unleashed
 FILE_barebox-hifive-unmatched.img = start_hifive_unmatched.pblb
 FILE_barebox-hifive-unleashed.img = start_hifive_unleashed.pblb
 image-$(CONFIG_BOARD_HIFIVE) += barebox-hifive-unmatched.img barebox-hifive-unleashed.img
+
+pblb-$(CONFIG_BOARD_LITEX_LINUX) += start_litex_linux
+FILE_barebox-litex-linux.img = start_litex_linux.pblb
+image-$(CONFIG_BOARD_LITEX_LINUX) += barebox-litex-linux.img
Signature · 7 lines
2.31.1


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#21 lore raw

PATCH v2 10/11 RISC-V: add litex_linux_defconfig

In reply to Antony Pavlov
---
 arch/riscv/configs/litex_linux_defconfig | 77 ++++++++++++++++++++++++
 1 file changed, 77 insertions(+)
arch/riscv/configs/litex_linux_defconfig new file +77 -0
new file mode 100644
index 0000000000..211fa4bbce
@@ -0,0 +1,77 @@
+CONFIG_RISCV_M_MODE=y
+CONFIG_SOC_LITEX=y
+CONFIG_STACK_SIZE=0x20000
+CONFIG_MALLOC_SIZE=0xf00000
+CONFIG_MALLOC_TLSF=y
+CONFIG_PANIC_HANG=y
+CONFIG_BAUDRATE=1000000
+CONFIG_HUSH_FANCY_PROMPT=y
+CONFIG_CMDLINE_EDITING=y
+CONFIG_AUTO_COMPLETE=y
+# CONFIG_TIMESTAMP is not set
+CONFIG_BOOTM_SHOW_TYPE=y
+CONFIG_BOOTM_VERBOSE=y
+CONFIG_BOOTM_INITRD=y
+CONFIG_BOOTM_OFTREE=y
+CONFIG_BOOTM_OFTREE_UIMAGE=y
+CONFIG_DEFAULT_ENVIRONMENT_GENERIC_NEW=y
+CONFIG_DEBUG_LL=y
+CONFIG_LONGHELP=y
+CONFIG_CMD_IOMEM=y
+CONFIG_CMD_IMD=y
+CONFIG_CMD_MEMINFO=y
+CONFIG_CMD_GO=y
+CONFIG_CMD_LOADY=y
+CONFIG_CMD_EXPORT=y
+CONFIG_CMD_CMP=y
+CONFIG_CMD_MD5SUM=y
+CONFIG_CMD_SHA1SUM=y
+CONFIG_CMD_MSLEEP=y
+CONFIG_CMD_SLEEP=y
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MIITOOL=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_TFTP=y
+CONFIG_CMD_ECHO_E=y
+CONFIG_CMD_EDIT=y
+CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_MM=y
+CONFIG_CMD_CLK=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_LED=y
+CONFIG_CMD_SPI=y
+CONFIG_CMD_LED_TRIGGER=y
+CONFIG_CMD_OF_DUMP=y
+CONFIG_CMD_TIME=y
+CONFIG_CMD_DHRYSTONE=y
+CONFIG_NET=y
+CONFIG_NET_NFS=y
+CONFIG_NET_NETCONSOLE=y
+CONFIG_DRIVER_NET_LITEETH=y
+CONFIG_AR8327N_PHY=y
+CONFIG_AT803X_PHY=y
+CONFIG_DAVICOM_PHY=y
+CONFIG_DP83867_PHY=y
+CONFIG_LXT_PHY=y
+CONFIG_MARVELL_PHY=y
+CONFIG_MICREL_PHY=y
+CONFIG_NATIONAL_PHY=y
+CONFIG_REALTEK_PHY=y
+CONFIG_SMSC_PHY=y
+CONFIG_NET_DSA_MV88E6XXX=y
+CONFIG_DRIVER_SPI_LITEX_SPIFLASH=y
+CONFIG_MTD=y
+# CONFIG_MTD_OOB_DEVICE is not set
+CONFIG_MTD_M25P80=y
+CONFIG_CLOCKSOURCE_DUMMY_RATE=20000
+CONFIG_SRAM=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
+CONFIG_LED_GPIO_OF=y
+CONFIG_LED_TRIGGERS=y
+CONFIG_GPIO_74XX_MMIO=y
+CONFIG_GPIO_GENERIC_PLATFORM=y
+# CONFIG_PINCTRL is not set
+CONFIG_FS_TFTP=y
+CONFIG_FS_NFS=y
+CONFIG_DIGEST_CRC32_GENERIC=y
Signature · 7 lines
2.31.1


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#22 lore raw

PATCH v2 11/11 RISC-V: make it possible to build RV32I multi-image with DEBUG_LL=n

In reply to Antony Pavlov

Building multi-image with these options:

CONFIG_ARCH_RV32I=y
CONFIG_RISCV_M_MODE=y
CONFIG_SOC_ERIZO=y
CONFIG_BOARD_ERIZO_GENERIC=y
CONFIG_SOC_LITEX=y
CONFIG_BOARD_LITEX_LINUX=y
CONFIG_DEBUG_LL=n

leads to the build error:

arch/riscv/boards/erizo/lowlevel.c: In function ‘__start_erizo_generic’:
arch/riscv/boards/erizo/lowlevel.c:11:2: error: implicit declaration of function ‘debug_ll_ns16550_init’ [-Werror=implicit-function-declaration]

   11 |  debug_ll_ns16550_init();
      |  ^~~~~~~~~~~~~~~~~~~~~

This patch fixes the problem by using preprocessor's directive.

---
 arch/riscv/boards/erizo/lowlevel.c | 2 ++
 1 file changed, 2 insertions(+)
arch/riscv/boards/erizo/lowlevel.c +2 -0
index fd899c8679..bab49d3c87 100644
@@ -9,7 +9,9 @@ ENTRY_FUNCTION(start_erizo_generic, a0, a1, a2)
 {
 	extern char __dtb_z_erizo_generic_start[];
 
+#if defined CONFIG_DEBUG_LL
 	debug_ll_ns16550_init();
+#endif
 	barebox_nmon_entry();
 
 	putc_ll('>');
Signature · 7 lines
2.31.1


_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#23 lore raw

Re: [PATCH v2 11/11] RISC-V: make it possible to build RV32I multi-image with DEBUG_LL=n

Hell Antony,

Quoted 12 lines · Antony Pavlov

Building multi-image with these options:

CONFIG_ARCH_RV32I=y
CONFIG_RISCV_M_MODE=y
CONFIG_SOC_ERIZO=y
CONFIG_BOARD_ERIZO_GENERIC=y
CONFIG_SOC_LITEX=y
CONFIG_BOARD_LITEX_LINUX=y
CONFIG_DEBUG_LL=n

leads to the build error:

Quoted 7 lines

arch/riscv/boards/erizo/lowlevel.c: In function ‘__start_erizo_generic’:
arch/riscv/boards/erizo/lowlevel.c:11:2: error: implicit declaration of function ‘debug_ll_ns16550_init’ [-Werror=implicit-function-declaration]

   11 |  debug_ll_ns16550_init();
      |  ^~~~~~~~~~~~~~~~~~~~~

This patch fixes the problem by using preprocessor's directive.

I noticed that too. I just sent out a fixup for this.

Quoted 21 lines
---
 arch/riscv/boards/erizo/lowlevel.c | 2 ++
 1 file changed, 2 insertions(+)
arch/riscv/boards/erizo/lowlevel.c +2 -0
index fd899c8679..bab49d3c87 100644
@@ -9,7 +9,9 @@ ENTRY_FUNCTION(start_erizo_generic, a0, a1, a2)
 {
 	extern char __dtb_z_erizo_generic_start[];
 
+#if defined CONFIG_DEBUG_LL
 	debug_ll_ns16550_init();
+#endif
 	barebox_nmon_entry();
 
 	putc_ll('>');
Signature · 9 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#24 lore raw
In reply to Antony Pavlov
Quoted 9 lines · Antony Pavlov

Changes since v1:

* rebased on top of next branch;
* new patches are introduced:
* clocksource: timer-riscv: select CSR from device tree
* RISC-V: make RISCV_SBI and RISCV_M_MODE explicitly mutually exclusive
* RISC-V: make it possible to build RV32I multi-image with DEBUG_LL=n
* almost all of Ahmad's notes are fixed (e.g. unused header files inclusions are dropped);
* NOT FIXED: gpio-74xx-mmio still uses dev_get_drvdata(), not device_get_match_data()

Why?

Quoted 60 lines

Antony Pavlov (11):
clocksource: timer-riscv: select CSR from device tree
RISC-V: make RISCV_SBI and RISCV_M_MODE explicitly mutually exclusive
RISC-V: make it possible to run nmon from PBL C code
RISC-V: boards: erizo: make it possible to use nmon
serial: add litex UART driver
gpio: add driver for 74xx-ICs with MMIO access
spi: add litex spiflash driver
net: add LiteEth driver
RISC-V: add LiteX SoC and linux-on-litex-vexriscv support
RISC-V: add litex_linux_defconfig
RISC-V: make it possible to build RV32I multi-image with DEBUG_LL=n

 arch/riscv/Kconfig                         |  22 +-
 arch/riscv/Kconfig.socs                    |  18 +-
 arch/riscv/boards/Makefile                 |   1 +
 arch/riscv/boards/erizo/lowlevel.c         |   5 +
 arch/riscv/boards/litex-linux/Makefile     |   3 +
 arch/riscv/boards/litex-linux/lowlevel.c   |  20 ++
 arch/riscv/boot/Makefile                   |   1 +
 arch/riscv/boot/nmon_entry.S               |  13 +
 arch/riscv/configs/erizo_generic_defconfig |   1 +
 arch/riscv/configs/litex_linux_defconfig   |  77 +++++
 arch/riscv/cpu/time.c                      |   7 +
 arch/riscv/dts/Makefile                    |   1 +
 arch/riscv/dts/erizo.dtsi                  |   2 +
 arch/riscv/dts/litex-linux.dts             |  96 ++++++
 arch/riscv/dts/litex_soc_linux.dtsi        |  49 +++
 arch/riscv/include/asm/debug_ll.h          |   3 +
 arch/riscv/include/asm/debug_ll_litex.h    | 123 +++++++
 arch/riscv/include/asm/riscv_nmon.h        |  49 ++-
 arch/riscv/include/asm/timer.h             |   1 +
 common/Kconfig                             |   4 +
 drivers/clocksource/timer-riscv.c          |  19 +-
 drivers/gpio/Kconfig                       |  14 +
 drivers/gpio/Makefile                      |   1 +
 drivers/gpio/gpio-74xx-mmio.c              | 166 +++++++++
 drivers/net/Kconfig                        |   8 +
 drivers/net/Makefile                       |   1 +
 drivers/net/liteeth.c                      | 376 +++++++++++++++++++++
 drivers/serial/Makefile                    |   1 +
 drivers/serial/serial_litex.c              |  96 ++++++
 drivers/spi/Kconfig                        |   3 +
 drivers/spi/Makefile                       |   1 +
 drivers/spi/litex_spiflash.c               | 241 +++++++++++++
 images/Makefile.riscv                      |   4 +
 33 files changed, 1388 insertions(+), 39 deletions(-)
 create mode 100644 arch/riscv/boards/litex-linux/Makefile
 create mode 100644 arch/riscv/boards/litex-linux/lowlevel.c
 create mode 100644 arch/riscv/boot/nmon_entry.S
 create mode 100644 arch/riscv/configs/litex_linux_defconfig
 create mode 100644 arch/riscv/dts/litex-linux.dts
 create mode 100644 arch/riscv/dts/litex_soc_linux.dtsi
 create mode 100644 arch/riscv/include/asm/debug_ll_litex.h
 create mode 100644 drivers/gpio/gpio-74xx-mmio.c
 create mode 100644 drivers/net/liteeth.c
 create mode 100644 drivers/serial/serial_litex.c
 create mode 100644 drivers/spi/litex_spiflash.c
Signature · 9 lines
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
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox
#25 lore raw
Quoted 11 lines · On Fri, 7 May 2021 12:23:47 +0200 Ahmad Fatoum <[email protected]> wrote:
Quoted 9 lines · Antony Pavlov

Changes since v1:

* rebased on top of next branch;
* new patches are introduced:
* clocksource: timer-riscv: select CSR from device tree
* RISC-V: make RISCV_SBI and RISCV_M_MODE explicitly mutually exclusive
* RISC-V: make it possible to build RV32I multi-image with DEBUG_LL=n
* almost all of Ahmad's notes are fixed (e.g. unused header files inclusions are dropped);
* NOT FIXED: gpio-74xx-mmio still uses dev_get_drvdata(), not device_get_match_data()

Quoted 1 line

Why?

Changing dev_get_drvdata() to device_get_match_data() is easy (but not trivial). On the other hand there are three new patches in the v2 patchseries. I foresee discussion on these new patches, during this discussion I can polish gpio-74xx-mmio ;)

Signature · 7 lines
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/barebox