From: lkcl@lkcl.net (Luke Kenneth Casson Leighton) To: linux-riscv@lists.infradead.org Subject: [sw-dev] SBI extension proposal v2 Date: Sat, 10 Nov 2018 15:48:19 +0000 [thread overview] Message-ID: <CAPweEDz-7oRg2UWPkvTDdfi36Z4PQLAuLdL3-Sy-kmkGEJ=44A@mail.gmail.com> (raw) In-Reply-To: <2e5329eff04e2b0bc2433b5d974bf10f@mailhost.ics.forth.gr> --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> wrote: > > ???? 2018-11-10 07:12, Luke Kenneth Casson Leighton ??????: > > On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com> > > wrote: > > > >> ## Conclusion > >> This proposal is far from perfect and absolutely any suggestion is > >> welcome. Obviously, there are many other functionalities that can be > >> added to this proposal. However, I just wanted to start with something > >> that is an incremental change at best to kick off the discussion. The > >> aim here is to initiate a discussion that can lead to a robust SBI > >> specification. > > > > very cool, atish. > > > > i would very much like to see the optional addition of multiple > > serial lines, by adding a getchar and putchar function that takes just > > one extra argument: the serial line index. > > > > there are a lot of different uses to which mult-serial lines may be > > put: > > > > * boot message separation from console login > > * boot management separation from other purposes (u-boot/coreboot) > > * virtual /dev/ttyS0-3 > > * clean UPS reporting and management > > * remote virtual machine power management (power-on / off) > > * simple bog-standard multiple virtual login consoles > > * separation of debug messages (stdout/stderr) to ease debugging and > > development > > * remote and virtual OpenOCD and kernel debugging without disrupting > > the main serial console > > * PPP serial links. > > > > this latter is one that i am particularly interested in, as i would > > like to be able to boot a full GNU/Linux OS on spike, given the lower > > barrier to entry in making modifications and experimenting with spike > > than it is with qemu. > > > > if spike were able, through a multi-serial SBI interface, to have a > > PPP serial line, it would be possible to run a root NFS (or other > > network block device) without having to sacrifice console access. it > > would be possible to create an initramfs from a lower-capability > > system like buildroot, containing PPP, enable it, and pivot-root out > > to a full stock GNU/Linux OS such as debian or fedora. > > > > so there are huge benefits, reducing the development barrier to entry > > into RISC-V experimentation and debugging, and opening up a much wider > > range of capabilities and possibilities for machine and virtual system > > management. > > > > l. > > > The current SBI says that console_getchar/console_putchar are for the > debug > console but on Linux we use them for the main console on earlyprintk. ... yeah exactly. and what if something goes wrong, you want to be able to interact over openocd without interfering with that earlyprintk, particularly during that critical first bringup phase of real-world silicon? > I > think it's misleading and we should at least have an argument to chose > between the main console and an optional debug console, or rename > them to debug_console_getchar/debug_console_putchar and > main_console_getchar/ > main_console_putchar. i initially thought of proposing that, however: (1) the API already exists with "single console". it would therefore be disruptive to change that (2) if adding something called debug_console_{get/put}char, it might as well take advantage of the opportunity to be extended and made generic, and have the extra argument added > However I don't think that argument should be the serial line. Different > vendors may use different serial lines for the main console / debug > console, > the caller doesn't know which serial line maps to which console, so the > SBI > should be more abstract and use something like a console id where e.g. 0 > is > main console an 1 is debug. yes, it should [have]: my feeling is, it's a little late in the game given that it's almost certainly baked into pre-existing hardware, by now, so the next best thing is a new function call. l.
WARNING: multiple messages have this Message-ID (diff)
From: Luke Kenneth Casson Leighton <lkcl@lkcl.net> To: mick@ics.forth.gr Cc: mark.rutland@arm.com, hch@infradead.org, Damien.LeMoal@wdc.com, Olof Johansson <olof.johansson@gmail.com>, alankao@andestech.com, abner.chang@hpe.com, Anup Patel <anup@brainfault.org>, Palmer Dabbelt <palmer@sifive.com>, Alexander Graf <agraf@suse.de>, zong@andestech.com, atish.patra@wdc.com, sw-dev@groups.riscv.org, paul.walmsley@sifive.com, Alistair.Francis@wdc.com, linux-riscv@lists.infradead.org, Andrew Waterman <andrew@sifive.com> Subject: Re: [sw-dev] SBI extension proposal v2 Date: Sat, 10 Nov 2018 15:48:19 +0000 [thread overview] Message-ID: <CAPweEDz-7oRg2UWPkvTDdfi36Z4PQLAuLdL3-Sy-kmkGEJ=44A@mail.gmail.com> (raw) Message-ID: <20181110154819.SOwCurvjWiKopkmD-leCwoupInvgbPhYBH7y5xXGW7A@z> (raw) In-Reply-To: <2e5329eff04e2b0bc2433b5d974bf10f@mailhost.ics.forth.gr> --- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 On Sat, Nov 10, 2018 at 3:31 PM Nick Kossifidis <mick@ics.forth.gr> wrote: > > Στις 2018-11-10 07:12, Luke Kenneth Casson Leighton έγραψε: > > On Sat, Nov 10, 2018 at 2:42 AM Atish Patra <atish.patra@wdc.com> > > wrote: > > > >> ## Conclusion > >> This proposal is far from perfect and absolutely any suggestion is > >> welcome. Obviously, there are many other functionalities that can be > >> added to this proposal. However, I just wanted to start with something > >> that is an incremental change at best to kick off the discussion. The > >> aim here is to initiate a discussion that can lead to a robust SBI > >> specification. > > > > very cool, atish. > > > > i would very much like to see the optional addition of multiple > > serial lines, by adding a getchar and putchar function that takes just > > one extra argument: the serial line index. > > > > there are a lot of different uses to which mult-serial lines may be > > put: > > > > * boot message separation from console login > > * boot management separation from other purposes (u-boot/coreboot) > > * virtual /dev/ttyS0-3 > > * clean UPS reporting and management > > * remote virtual machine power management (power-on / off) > > * simple bog-standard multiple virtual login consoles > > * separation of debug messages (stdout/stderr) to ease debugging and > > development > > * remote and virtual OpenOCD and kernel debugging without disrupting > > the main serial console > > * PPP serial links. > > > > this latter is one that i am particularly interested in, as i would > > like to be able to boot a full GNU/Linux OS on spike, given the lower > > barrier to entry in making modifications and experimenting with spike > > than it is with qemu. > > > > if spike were able, through a multi-serial SBI interface, to have a > > PPP serial line, it would be possible to run a root NFS (or other > > network block device) without having to sacrifice console access. it > > would be possible to create an initramfs from a lower-capability > > system like buildroot, containing PPP, enable it, and pivot-root out > > to a full stock GNU/Linux OS such as debian or fedora. > > > > so there are huge benefits, reducing the development barrier to entry > > into RISC-V experimentation and debugging, and opening up a much wider > > range of capabilities and possibilities for machine and virtual system > > management. > > > > l. > > > The current SBI says that console_getchar/console_putchar are for the > debug > console but on Linux we use them for the main console on earlyprintk. ... yeah exactly. and what if something goes wrong, you want to be able to interact over openocd without interfering with that earlyprintk, particularly during that critical first bringup phase of real-world silicon? > I > think it's misleading and we should at least have an argument to chose > between the main console and an optional debug console, or rename > them to debug_console_getchar/debug_console_putchar and > main_console_getchar/ > main_console_putchar. i initially thought of proposing that, however: (1) the API already exists with "single console". it would therefore be disruptive to change that (2) if adding something called debug_console_{get/put}char, it might as well take advantage of the opportunity to be extended and made generic, and have the extra argument added > However I don't think that argument should be the serial line. Different > vendors may use different serial lines for the main console / debug > console, > the caller doesn't know which serial line maps to which console, so the > SBI > should be more abstract and use something like a console id where e.g. 0 > is > main console an 1 is debug. yes, it should [have]: my feeling is, it's a little late in the game given that it's almost certainly baked into pre-existing hardware, by now, so the next best thing is a new function call. l. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2018-11-10 15:48 UTC|newest] Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-10 2:42 SBI extension proposal v2 Atish Patra 2018-11-10 2:42 ` Atish Patra 2018-11-10 5:12 ` [sw-dev] " Luke Kenneth Casson Leighton 2018-11-10 5:12 ` Luke Kenneth Casson Leighton 2018-11-10 14:50 ` Nick Kossifidis 2018-11-10 14:50 ` Nick Kossifidis 2018-11-10 15:48 ` Luke Kenneth Casson Leighton [this message] 2018-11-10 15:48 ` Luke Kenneth Casson Leighton 2018-11-10 16:46 ` ron minnich 2018-11-10 16:46 ` ron minnich 2018-11-10 17:40 ` Luke Kenneth Casson Leighton 2018-11-10 17:40 ` Luke Kenneth Casson Leighton 2018-11-10 17:41 ` Samuel Falvo II 2018-11-10 17:41 ` Samuel Falvo II 2018-11-10 17:42 ` Luke Kenneth Casson Leighton 2018-11-10 17:42 ` Luke Kenneth Casson Leighton 2018-11-10 17:51 ` Samuel Falvo II 2018-11-10 17:51 ` Samuel Falvo II 2018-11-10 17:55 ` Luke Kenneth Casson Leighton 2018-11-10 17:55 ` Luke Kenneth Casson Leighton 2018-11-10 18:03 ` Samuel Falvo II 2018-11-10 18:03 ` Samuel Falvo II 2018-11-10 17:43 ` Samuel Falvo II 2018-11-10 17:43 ` Samuel Falvo II 2018-11-10 17:41 ` Olof Johansson 2018-11-10 17:41 ` Olof Johansson 2018-11-10 17:47 ` Luke Kenneth Casson Leighton 2018-11-10 17:47 ` Luke Kenneth Casson Leighton 2018-11-10 17:59 ` Nick Kossifidis 2018-11-10 17:59 ` Nick Kossifidis 2018-11-10 18:01 ` ron minnich 2018-11-10 18:01 ` ron minnich 2018-11-10 19:33 ` Luke Kenneth Casson Leighton 2018-11-10 19:33 ` Luke Kenneth Casson Leighton 2018-11-10 19:39 ` Luke Kenneth Casson Leighton 2018-11-10 19:39 ` Luke Kenneth Casson Leighton 2018-11-11 3:15 ` Nick Kossifidis 2018-11-11 3:15 ` Nick Kossifidis 2018-11-11 7:14 ` Luke Kenneth Casson Leighton 2018-11-11 7:14 ` Luke Kenneth Casson Leighton 2018-11-11 13:17 ` Nick Kossifidis 2018-11-11 13:17 ` Nick Kossifidis 2018-11-12 2:08 ` Palmer Dabbelt 2018-11-12 2:08 ` Palmer Dabbelt 2018-11-10 18:02 ` Olof Johansson 2018-11-10 18:02 ` Olof Johansson 2018-11-10 19:34 ` Luke Kenneth Casson Leighton 2018-11-10 19:34 ` Luke Kenneth Casson Leighton 2018-11-13 1:22 ` Michael Clark 2018-11-13 1:22 ` Michael Clark 2018-11-10 17:54 ` Nick Kossifidis 2018-11-10 17:54 ` Nick Kossifidis 2018-11-10 17:59 ` ron minnich 2018-11-10 17:59 ` ron minnich 2018-11-11 3:58 ` Atish Patra 2018-11-11 3:58 ` Atish Patra 2018-12-02 6:18 ` Benjamin Herrenschmidt 2019-01-28 12:31 ` Alexander Graf 2019-01-28 16:33 ` Luke Kenneth Casson Leighton 2019-01-28 16:38 ` Alexander Graf 2019-01-28 16:47 ` Nick Kossifidis 2019-01-28 19:43 ` Alexander Graf 2019-01-28 19:47 ` Atish Patra 2019-01-28 19:48 ` Alexander Graf 2019-01-28 19:40 ` ron minnich 2019-01-28 19:55 ` Alexander Graf 2019-01-28 20:18 ` ron minnich 2019-01-28 20:37 ` Alexander Graf 2019-01-28 22:23 ` ron minnich 2019-01-29 8:53 ` Alexander Graf 2019-01-29 15:52 ` ron minnich 2019-01-28 23:46 ` Luke Kenneth Casson Leighton 2019-01-28 23:22 ` Bruce Hoult 2019-01-29 0:03 ` Luke Kenneth Casson Leighton 2019-01-29 4:28 ` ron minnich [not found] ` <CANs6eMk4z-ZibLW_5o03onu8AQe23uMa2hSieceHFqKS7igLDQ@mail.gmail.com> 2019-01-30 0:05 ` Luke Kenneth Casson Leighton 2019-01-30 0:17 ` ron minnich 2019-01-30 0:49 ` Bruce Hoult 2019-01-30 3:15 ` Luke Kenneth Casson Leighton [not found] ` <09bede45-6ecf-4ded-8615-0be38aac33fc@groups.riscv.org> 2019-01-29 3:58 ` Samuel Falvo II 2019-01-29 4:33 ` ron minnich 2019-02-05 22:29 ` Benjamin Herrenschmidt 2019-02-05 23:02 ` Luís Marques 2019-02-06 7:03 ` ron minnich 2019-02-06 7:54 ` Damien Le Moal 2019-02-07 3:56 ` Paul Walmsley 2019-02-07 7:17 ` Anup Patel 2019-02-07 7:19 ` Anup Patel 2019-01-29 22:41 ` Palmer Dabbelt 2018-11-10 17:43 ` Nick Kossifidis 2018-11-10 17:43 ` Nick Kossifidis 2018-11-10 17:51 ` Luke Kenneth Casson Leighton 2018-11-10 17:51 ` Luke Kenneth Casson Leighton 2018-11-10 5:36 ` David Abdurachmanov 2018-11-10 5:36 ` David Abdurachmanov [not found] ` <CA++6G0BTdybjhqaXm9EhAz0HsgpwfozK6OEL7DuzbS48RbEChA@mail.gmail.com> 2018-11-10 15:09 ` Nick Kossifidis 2018-11-10 15:09 ` Nick Kossifidis 2018-11-12 4:33 ` Nick Kossifidis 2018-11-12 4:33 ` Nick Kossifidis 2018-12-04 23:22 ` [sw-dev] " Atish Patra
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAPweEDz-7oRg2UWPkvTDdfi36Z4PQLAuLdL3-Sy-kmkGEJ=44A@mail.gmail.com' \ --to=lkcl@lkcl.net \ --cc=linux-riscv@lists.infradead.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.