RISC-V: add LiteX SoC support; resurrect nmon
Subsystems (7)
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
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
@@ -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
@@ -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
@@ -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
@@ -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
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 (CSR0xc01).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
Signed-off-by Antony Pavlov <[email protected]>--- 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@@ -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
-0of_platform_populate (cpu,NULL ,NULL );return 0 ;arch/riscv/dts/erizo.dtsi +2
-0@@ -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@@ -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@@ -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
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 (CSR0xc01).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
Signed-off-by Antony Pavlov <[email protected]>--- 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@@ -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
-0of_platform_populate (cpu,NULL ,NULL );return 0 ;arch/riscv/dts/erizo.dtsi +2
-0@@ -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@@ -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@@ -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
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 exceptionQuoted 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
Signed-off-by Antony Pavlov <[email protected]>--- 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@@ -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_timebaseparse routine outside of driver probe. I tryed to avoid code duplication.
Why we couldn't parseriscv_timebasein 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
-0of_platform_populate (cpu,NULL ,NULL );return 0 ;arch/riscv/dts/erizo.dtsi +2
-0@@ -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@@ -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@@ -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
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
@@ -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
@@ -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
@@ -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
Re: [PATCH v2 02/11] RISC-V: make RISCV_SBI and RISCV_M_MODE explicitly mutually exclusive
Hello,
Quoted 16 lines · Antony Pavlov
Signed-off-by Antony Pavlov <[email protected]>--- 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@@ -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 - endmenuarch/riscv/Kconfig.socs +3
-1@@ -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_TIMERarch/riscv/configs/erizo_generic_defconfig +1
-0@@ -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
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
Signed-off-by Antony Pavlov <[email protected]>--- 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@@ -38,6 +38,18 @@ config ARCH_RV64I endchoice +choicearch/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)" + +endchoiceHmm. 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_moderiscv_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 - endmenuarch/riscv/Kconfig.socs +3
-1@@ -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_TIMERarch/riscv/configs/erizo_generic_defconfig +1
-0@@ -1,3 +1,4 @@ +CONFIG_RISCV_M_MODE=y CONFIG_SOC_ERIZO=y # CONFIG_GLOBALVAR is not set CONFIG_STACK_SIZE=0x20000Signature · 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
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_SIZEandMALLOC_SIZEper-board parameters not per-defconfig parameters like now.If we could make
STACK_SIZEandMALLOC_SIZEper-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 - endmenuarch/riscv/Kconfig.socs +3
-1@@ -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_TIMERarch/riscv/configs/erizo_generic_defconfig +1
-0@@ -1,3 +1,4 @@ +CONFIG_RISCV_M_MODE=y CONFIG_SOC_ERIZO=y # CONFIG_GLOBALVAR is not set CONFIG_STACK_SIZE=0x20000Signature · 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
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_SIZEandMALLOC_SIZEper-board parameters not per-defconfig parameters like now.If we could make
STACK_SIZEandMALLOC_SIZEper-board compile-time parameters then we can make RISC-V mode per-board compile-time parameter too. Is this solution acceptable?
MALLOC_SIZEcan be set as 0 and barebox will determine it based on membase + memsize that are set by PBL.
STACK_SIZEmust be set perKconfig, 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()andbarebox_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 - endmenuarch/riscv/Kconfig.socs +3
-1@@ -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_TIMERarch/riscv/configs/erizo_generic_defconfig +1
-0@@ -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
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_SIZEandMALLOC_SIZEper-board parameters not per-defconfig parameters like now.If we could make
STACK_SIZEandMALLOC_SIZEper-board compile-time parameters then we can make RISC-V mode per-board compile-time parameter too. Is this solution acceptable?
MALLOC_SIZEcan be set as 0 and barebox will determine it based on membase + memsize that are set by PBL.
STACK_SIZEmust be set perKconfig, 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()andbarebox_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/2823Hmm, 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
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_SIZEandMALLOC_SIZEper-board parameters not per-defconfig parameters like now.If we could make
STACK_SIZEandMALLOC_SIZEper-board compile-time parameters then we can make RISC-V mode per-board compile-time parameter too. Is this solution acceptable?
MALLOC_SIZEcan be set as 0 and barebox will determine it based on membase + memsize that are set by PBL.
STACK_SIZEmust be set perKconfig, 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()andbarebox_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/2823Hmm, 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()andbarebox_riscv_supervisor_entry(), so PBL entry points can decide for themselves what mode the rest of barebox should get whenriscv_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
PATCH v2 3/11 RISC-V: make it possible to run nmon from PBL C code
In reply to Antony PavlovAfter 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
@@ -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
@@ -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
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
@@ -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
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
@@ -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
Re: [PATCH v2 05/11] serial: add litex UART driver
Hi,
Quoted 87 lines · Antony Pavlov
Signed-off-by Antony Pavlov <[email protected]>--- drivers/serial/Makefile | 1 + drivers/serial/serial_litex.c | 96 +++++++++++++++++++++++++++++++++++ 2 files changed, 97 insertions(+)drivers/serial/Makefile +1
-0@@ -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.odrivers/serial/serial_litex.c new file +66
-0@@ -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
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
Signed-off-by Antony Pavlov <[email protected]>--- drivers/serial/Makefile | 1 + drivers/serial/serial_litex.c | 96 +++++++++++++++++++++++++++++++++++ 2 files changed, 97 insertions(+)drivers/serial/Makefile +1
-0@@ -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.odrivers/serial/serial_litex.c new file +70
-0@@ -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
PATCH v2 6/11 gpio: add driver for 74xx-ICs with MMIO access
In reply to Antony PavlovThis 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)--- 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
@@ -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
@@ -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
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
@@ -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
@@ -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
PATCH v2 8/11 net: add LiteEth driver
In reply to Antony PavlovLiteEth 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
@@ -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
@@ -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
PATCH v2 9/11 RISC-V: add LiteX SoC and linux-on-litex-vexriscv support
In reply to Antony PavlovLiteX 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
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
@@ -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
PATCH v2 11/11 RISC-V: make it possible to build RV32I multi-image with DEBUG_LL=n
In reply to Antony PavlovBuilding multi-image with these options:
CONFIG_ARCH_RV32I=yCONFIG_RISCV_M_MODE=yCONFIG_SOC_ERIZO=yCONFIG_BOARD_ERIZO_GENERIC=yCONFIG_SOC_LITEX=yCONFIG_BOARD_LITEX_LINUX=yCONFIG_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
@@ -9,7 +9,9 @@ ENTRY_FUNCTION(start_erizo_generic, a0, a1, a2) {extern char __dtb_z_erizo_generic_start[]; +#if definedCONFIG_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
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=yCONFIG_RISCV_M_MODE=yCONFIG_SOC_ERIZO=yCONFIG_BOARD_ERIZO_GENERIC=yCONFIG_SOC_LITEX=yCONFIG_BOARD_LITEX_LINUX=yCONFIG_DEBUG_LL=nleads 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
Signed-off-by Antony Pavlov <[email protected]>--- arch/riscv/boards/erizo/lowlevel.c | 2 ++ 1 file changed, 2 insertions(+)arch/riscv/boards/erizo/lowlevel.c +2
-0@@ -9,7 +9,9 @@ ENTRY_FUNCTION(start_erizo_generic, a0, a1, a2) {extern char __dtb_z_erizo_generic_start[]; +#if definedCONFIG_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
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: makeRISCV_SBIandRISCV_M_MODEexplicitly 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 usesdev_get_drvdata(), notdevice_get_match_data()
Why?
Quoted 60 lines
Antony Pavlov (11):
clocksource: timer-riscv: select CSR from device tree
RISC-V: makeRISCV_SBIandRISCV_M_MODEexplicitly 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: addlitex_linux_defconfig
RISC-V: make it possible to build RV32I multi-image with DEBUG_LL=narch/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
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: makeRISCV_SBIandRISCV_M_MODEexplicitly 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 usesdev_get_drvdata(), notdevice_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