I remember having sent this on Wednesday, but for some reason I don't see it in
your tree or my outbox so I might be crazy. I was planning submitting some
more patches next week anyway, so while I'm OK just rolling these up as well
it'd be slightly easier if we can get these into -rc1 so we can test them.
Sorry!
The following changes since commit 94710cac0ef4ee177a63b5227664b38c95bbf703:
Linux 4.18 (2018-08-12 13:41:04 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux.git tags/riscv-for-linus-4.19-mw0
for you to fetch changes up to 627672cf431b0379c07cc8d146f907cda6797222:
dt-bindings: interrupt-controller: SiFive Plaform Level Interrupt Controller (2018-08-13 09:39:11 -0700)
----------------------------------------------------------------
RISC-V Updates for the 4.19 Merge Window
This tag contains some major improvements to the RISC-V port, including
the necessary interrupt controller and timer support to actually make it
to userspace. Support for three devices has been added:
* Support for the ISA-mandated timers on RISC-V systems.
* Support for the ISA-mandated first-level interrupt controller on
RISC-V systems, which is handled as part of our core arch code because
it's very small and tightly tied to the ISA.
* Support for SiFive's platform-level interrupt controller, which talks
to the actual devices.
In addition to these new devices, there are a handful of cleanups all
over the RISC-V tree:
* Build fixes for various configurations
* A fix to the vDSO build's makefile so it respects CFLAGS.
* The addition of __lshrti3, a libgcc derived function necessary for
some 32-bit configurations.
* !SMP && PERF_EVENTS
* Cleanups to the arch code to remove the remnants of old versions of
the drivers that were just properly submitted.
* Some dead code from the timer driver, most of which wasn't ever
even compiled.
* Cleanups of some interrupt #defines, which are now local to the
interrupt handling code.
* Fixes to ptrace(), which while not being sufficient to fully make GDB
work are at least sufficient to get simple GDB tasks to work.
* Early printk support via RISC-V's architecturally mandated SBI console
device.
* A fix to our early debug trap handler to ensure it's always aligned.
These patches have all been through a fairly extensive review process,
but as this enables a whole pile of functionality (ie, userspace) I'm
confident we'll need to submit a few more patches. The only concrete
issues I know about are the sys_riscv_flush_icache patches, but as I
managed to screw those up on Friday I figured it'd be best to let them
bake another week.
This tag boots a Fedora root filesystem on QEMU's master branch for me,
and before this morning's rebase (from 4.18-rc8 to 4.18) it booted on
the HiFive Unleashed.
Thanks to Christoph Hellwig and the other guys at WD for getting the new
drivers in shape!
----------------------------------------------------------------
Alex Guo (1):
RISC-V: implement __lshrti3.
Atish Patra (1):
RISC-V: Fix !CONFIG_SMP compilation error
Christoph Hellwig (6):
RISC-V: remove timer leftovers
RISC-V: simplify software interrupt / IPI code
RISC-V: remove INTERRUPT_CAUSE_* defines from asm/irq.h
RISC-V: add a definition for the SIE SEIE bit
RISC-V: implement low-level interrupt handling
irqchip: add a SiFive PLIC driver
Jim Wilson (1):
RISC-V: Don't increment sepc after breakpoint.
Palmer Dabbelt (5):
RISC-V: Use KBUILD_CFLAGS instead of KCFLAGS when building the vDSO
RISC-V: Add early printk support via the SBI console
clocksource: new RISC-V SBI timer driver
dt-bindings: interrupt-controller: RISC-V local interrupt controller
dt-bindings: interrupt-controller: SiFive Plaform Level Interrupt Controller
Zong Li (1):
RISC-V: Add the directive for alignment of stvec's value
.../interrupt-controller/riscv,cpu-intc.txt | 44 ++++
.../interrupt-controller/sifive,plic-1.0.0.txt | 58 +++++
arch/riscv/Makefile | 3 +
arch/riscv/configs/defconfig | 1 +
arch/riscv/include/asm/csr.h | 1 +
arch/riscv/include/asm/irq.h | 5 +-
arch/riscv/include/asm/perf_event.h | 1 +
arch/riscv/include/asm/smp.h | 6 -
arch/riscv/kernel/entry.S | 4 +-
arch/riscv/kernel/head.S | 2 +
arch/riscv/kernel/irq.c | 55 ++++-
arch/riscv/kernel/perf_event.c | 1 -
arch/riscv/kernel/setup.c | 27 +++
arch/riscv/kernel/smp.c | 6 +-
arch/riscv/kernel/smpboot.c | 1 -
arch/riscv/kernel/time.c | 30 +--
arch/riscv/kernel/traps.c | 1 -
arch/riscv/kernel/vdso/Makefile | 4 +-
arch/riscv/lib/Makefile | 1 +
arch/riscv/lib/tishift.S | 42 ++++
drivers/clocksource/Kconfig | 11 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/riscv_timer.c | 105 +++++++++
drivers/irqchip/Kconfig | 12 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-sifive-plic.c | 260 +++++++++++++++++++++
include/linux/cpuhotplug.h | 1 +
27 files changed, 625 insertions(+), 59 deletions(-)
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/riscv,cpu-intc.txt
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.txt
create mode 100644 arch/riscv/lib/tishift.S
create mode 100644 drivers/clocksource/riscv_timer.c
create mode 100644 drivers/irqchip/irq-sifive-plic.c
Hi Palmer,
On Fri, Aug 17, 2018 at 01:28:11PM -0700, Palmer Dabbelt wrote:
[ ... ]
>
> This tag boots a Fedora root filesystem on QEMU's master branch for me,
> and before this morning's rebase (from 4.18-rc8 to 4.18) it booted on
> the HiFive Unleashed.
>
Do you have vmlinux embedded in bbl ?
With separate bbl and vmlinux, and the following qemu command line
(with qemu 3.0)
qemu-system-riscv64 -M virt -m 512M -no-reboot \
-bios bbl -kernel vmlinux \
-netdev user,id=net0 -device virtio-net-device,netdev=net0 \
-device virtio-blk-device,drive=d0 \
-drive file=rootfs.ext2,if=none,id=d0,format=raw \
-append 'root=/dev/vda rw console=ttyS0,115200' \
-nographic -monitor none
all I get is
rom: requested regions overlap (rom mrom.reset. free=0x000000000001cbe8, addr=0x0000000000001000)
However, the she system boots fine with the same qemu command line if I use qemu
built from https://github.com/riscv/riscv-qemu.git, branch qemu-for-upstream.
Excellent - once this series hits mainline, I'll add riscv to my
boot tests.
Thanks,
Guenter
On Fri, Aug 17, 2018 at 1:28 PM Palmer Dabbelt <[email protected]> wrote:
>
> I remember having sent this on Wednesday, but for some reason I don't see it in
> your tree or my outbox so I might be crazy.
You might indeed have been having hallucinations. I don't see any
other pull request from you in my mailbox than this one.
Google does find a posting from you saying
"Below is the pull request I plan to submit on Wednesday morning"
on the RISC-V development google group list, so I think you just
remembered your _plan_, not your actual email ...
Anyway, I can confirm that this new pull request is now in my queue
even if I don't see any earlier ones.
Linus
On Sat, Aug 18, 2018 at 06:37:59AM -0700, Guenter Roeck wrote:
> On Fri, Aug 17, 2018 at 01:28:11PM -0700, Palmer Dabbelt wrote:
> [ ... ]
> >
> > This tag boots a Fedora root filesystem on QEMU's master branch for me,
> > and before this morning's rebase (from 4.18-rc8 to 4.18) it booted on
> > the HiFive Unleashed.
>
> Do you have vmlinux embedded in bbl ?
>
> With separate bbl and vmlinux, and the following qemu command line
> (with qemu 3.0)
>
> qemu-system-riscv64 -M virt -m 512M -no-reboot \
> -bios bbl -kernel vmlinux \
> -netdev user,id=net0 -device virtio-net-device,netdev=net0 \
> -device virtio-blk-device,drive=d0 \
> -drive file=rootfs.ext2,if=none,id=d0,format=raw \
> -append 'root=/dev/vda rw console=ttyS0,115200' \
> -nographic -monitor none
>
> all I get is
>
> rom: requested regions overlap (rom mrom.reset. free=0x000000000001cbe8, addr=0x0000000000001000)
>
> However, the she system boots fine with the same qemu command line if I use qemu
> built from https://github.com/riscv/riscv-qemu.git, branch qemu-for-upstream.
Hello,
AFAICS the qemu patch that adds support for handling separate bbl
and kernel images, i.e.
https://github.com/riscv/riscv-qemu/commit/6338416ecf4717197c635b5abf9c17465d2d0da0
hasn't yet made it into upstream qemu, so using the "-bios"
option for bbl generally doesn't work with (upstream) qemu 3.0.
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
On 08/19/2018 12:26 AM, Karsten Merker wrote:
[ ... ]
>> However, the she system boots fine with the same qemu command line if I use qemu
>> built from https://github.com/riscv/riscv-qemu.git, branch qemu-for-upstream.
>
> Hello,
>
> AFAICS the qemu patch that adds support for handling separate bbl
> and kernel images, i.e.
>
> https://github.com/riscv/riscv-qemu/commit/6338416ecf4717197c635b5abf9c17465d2d0da0
>
> hasn't yet made it into upstream qemu, so using the "-bios"
> option for bbl generally doesn't work with (upstream) qemu 3.0.
>
You are correct. With qemu 3.0+commit b79cd8dec5 ("RISC-V: Support separate firmware
and kernel payload") and this pull request plus "riscv: Drop setup_initrd" on top
of mainline, my test passes:
Build reference: riscv-for-linus-4.19-mw0-8897-gd028021652dd
Building virt:defconfig:initrd ... running .... passed
Building virt:defconfig:virtio-blk:rootfs ... running .... passed
... giving this an official
Tested-by: Guenter Roeck <[email protected]>
Guenter
On Sat, 18 Aug 2018 11:15:18 PDT (-0700), Linus Torvalds wrote:
> On Fri, Aug 17, 2018 at 1:28 PM Palmer Dabbelt <[email protected]> wrote:
>>
>> I remember having sent this on Wednesday, but for some reason I don't see it in
>> your tree or my outbox so I might be crazy.
>
> You might indeed have been having hallucinations. I don't see any
> other pull request from you in my mailbox than this one.
>
> Google does find a posting from you saying
>
> "Below is the pull request I plan to submit on Wednesday morning"
>
> on the RISC-V development google group list, so I think you just
> remembered your _plan_, not your actual email ...
That does sound like something I would do... It's odd because I remember
specifically being excited that I finally got the arguments to "git send-pull"
correct, but I guess that excitement was pre-mature :)
> Anyway, I can confirm that this new pull request is now in my queue
> even if I don't see any earlier ones.
Thanks!
I'm planning on submitting another PR tomorrow (which has been baking since
yesterday like it's supposed to), so fingers crossed I'm slightly less crazy
this week.
On Sat, 18 Aug 2018 06:37:59 PDT (-0700), [email protected] wrote:
> Hi Palmer,
>
> On Fri, Aug 17, 2018 at 01:28:11PM -0700, Palmer Dabbelt wrote:
> [ ... ]
>
>>
>> This tag boots a Fedora root filesystem on QEMU's master branch for me,
>> and before this morning's rebase (from 4.18-rc8 to 4.18) it booted on
>> the HiFive Unleashed.
>>
>
> Do you have vmlinux embedded in bbl ?
>
> With separate bbl and vmlinux, and the following qemu command line
> (with qemu 3.0)
>
> qemu-system-riscv64 -M virt -m 512M -no-reboot \
> -bios bbl -kernel vmlinux \
> -netdev user,id=net0 -device virtio-net-device,netdev=net0 \
> -device virtio-blk-device,drive=d0 \
> -drive file=rootfs.ext2,if=none,id=d0,format=raw \
> -append 'root=/dev/vda rw console=ttyS0,115200' \
> -nographic -monitor none
>
> all I get is
>
> rom: requested regions overlap (rom mrom.reset. free=0x000000000001cbe8, addr=0x0000000000001000)
>
> However, the she system boots fine with the same qemu command line if I use qemu
> built from https://github.com/riscv/riscv-qemu.git, branch qemu-for-upstream.
Yes, I have a vmlinux built into my BBL. I didn't actually look closely at the
command line I was copying and see that vmlinux in there, my guess would be
that it's getting ignored. I don't remember if upstream BBL actually works
with the split bbl/vmlinux setup, I've kind of stopped paying attention to BBL
as I'm just waiting for someone to tell me instructions as to how to use a real
bootloader... :)
I'm building master from QEMU as of a few weeks ago
* f7502360397d - (HEAD -> master, tag: v3.0.0-rc3, origin/master, origin/HEAD) Update version for v3.0.0-rc3 release (3 weeks ago) <Peter Maydell>
* b89041647422 - Merge remote-tracking branch 'remotes/armbru/tags/pull-monitor-2018-07-31' into staging (3 weeks ago) <Peter Maydell>
|\
| * 9a1054061c62 - monitor: temporary fix for dead-lock on event recursion (3 weeks ago) <Marc-André Lureau>
|/
* 42e76456cf68 - Merge remote-tracking branch 'remotes/vivier2/tags/linux-user-for-3.0-pull-request' into staging (3 weeks ago) <Peter Maydell>
|\
| * 5d9f3ea08172 - linux-user: ppc64: don't use volatile register during safe_syscall (3 weeks ago) <Shivaprasad G Bhat>
| * 28cbb997d66e - tests: add check_invalid_maps to test-mmap (3 weeks ago) <Alex Bennée>
| * 38138fab9358 - linux-user/mmap.c: handle invalid len maps correctly (3 weeks ago) <Alex Bennée>
* | 45a505d0a4b3 - Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging (3 weeks ago) <Peter Maydell>
in general once we get a port upstream I jump over to using master from
upstream as that way we'll find any bugs quickly. Michael Clark has a pretty
big QEMU patch queue, but nothing appears to be critical for Linux boot.
> Excellent - once this series hits mainline, I'll add riscv to my
> boot tests.
Thanks! I'm super excited to get CI stuff up and running as now that we can
boot I'm worried people will notice when I screw something up :)
On Tue, Aug 21, 2018 at 11:31:48AM -0700, Palmer Dabbelt wrote:
> On Sat, 18 Aug 2018 06:37:59 PDT (-0700), [email protected] wrote:
[...]
> > Do you have vmlinux embedded in bbl ?
> >
> > With separate bbl and vmlinux, and the following qemu command line
> > (with qemu 3.0)
> >
> > qemu-system-riscv64 -M virt -m 512M -no-reboot \
> > -bios bbl -kernel vmlinux \
> > -netdev user,id=net0 -device virtio-net-device,netdev=net0 \
> > -device virtio-blk-device,drive=d0 \
> > -drive file=rootfs.ext2,if=none,id=d0,format=raw \
> > -append 'root=/dev/vda rw console=ttyS0,115200' \
> > -nographic -monitor none
> >
> > all I get is
> >
> > rom: requested regions overlap (rom mrom.reset. free=0x000000000001cbe8, addr=0x0000000000001000)
> >
> > However, the she system boots fine with the same qemu command line if I use qemu
> > built from https://github.com/riscv/riscv-qemu.git, branch qemu-for-upstream.
>
> Yes, I have a vmlinux built into my BBL. I didn't actually look closely at
> the command line I was copying and see that vmlinux in there, my guess would
> be that it's getting ignored. I don't remember if upstream BBL actually
> works with the split bbl/vmlinux setup, I've kind of stopped paying
> attention to BBL as I'm just waiting for someone to tell me instructions as
> to how to use a real bootloader... :)
JFTR, upstream bbl supports the split bbl/vmlinux setup, it's just
upstream qemu that lacks the support for now (qemu-riscv has it).
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
On Tue, 21 Aug 2018 12:45:50 PDT (-0700), [email protected] wrote:
> On Tue, Aug 21, 2018 at 11:31:48AM -0700, Palmer Dabbelt wrote:
>> On Sat, 18 Aug 2018 06:37:59 PDT (-0700), [email protected] wrote:
> [...]
>> > Do you have vmlinux embedded in bbl ?
>> >
>> > With separate bbl and vmlinux, and the following qemu command line
>> > (with qemu 3.0)
>> >
>> > qemu-system-riscv64 -M virt -m 512M -no-reboot \
>> > -bios bbl -kernel vmlinux \
>> > -netdev user,id=net0 -device virtio-net-device,netdev=net0 \
>> > -device virtio-blk-device,drive=d0 \
>> > -drive file=rootfs.ext2,if=none,id=d0,format=raw \
>> > -append 'root=/dev/vda rw console=ttyS0,115200' \
>> > -nographic -monitor none
>> >
>> > all I get is
>> >
>> > rom: requested regions overlap (rom mrom.reset. free=0x000000000001cbe8, addr=0x0000000000001000)
>> >
>> > However, the she system boots fine with the same qemu command line if I use qemu
>> > built from https://github.com/riscv/riscv-qemu.git, branch qemu-for-upstream.
>>
>> Yes, I have a vmlinux built into my BBL. I didn't actually look closely at
>> the command line I was copying and see that vmlinux in there, my guess would
>> be that it's getting ignored. I don't remember if upstream BBL actually
>> works with the split bbl/vmlinux setup, I've kind of stopped paying
>> attention to BBL as I'm just waiting for someone to tell me instructions as
>> to how to use a real bootloader... :)
>
> JFTR, upstream bbl supports the split bbl/vmlinux setup, it's just
> upstream qemu that lacks the support for now (qemu-riscv has it).
Thanks!