RISC-V U-Boot for HiFive Unleashed Board is available on GitHub

[Padmarao Begari]

RISC-V U-Boot(64-bit) for HiFive Unleashed Board is available on GitHub

                    

https://github.com/Microsemi-SoC-IP/HiFive_U-Boot

This repository contains the RISC-V U-Boot created by Microsemi a Microchip company for RISC-V core on HiFive Unleashed 540 device. The HiFive Unleashed Board is used for HiFive U-Boot development

Regards

Padmarao

[Christoph Hellwig]

Can you explain a bit more where U-Boot fits into the picture? Is it
started as an S-mode payload, or have you ported M-mode code to U-boot?

[atish patra]

I think the uboot runs in M mode and acts as a FSBL in this case.

The boot flow still require bbl image (bbl+vmlinux) to boot Linux.

At least. that's what I understood from the makefile changes. Padmarao can correct me if I am wrong.

https://github.com/Microsemi-SoC-IP/HiFive_U-Boot#load-uboot-image-on-sd-card 

sgdisk --clear                                                               \
           --new=1:2048:4095   --change-name=1:uboot      --typecode=1:$(FSBL)   \
           --new=2:4096:69631  --change-name=2:bootloader --typecode=2:$(BBL)   \
           --new=3:264192:     --change-name=3:root       --typecode=3:$(LINUX) \

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/20181011132455.GA7242%40lst.de.

--

Regards,

Atish

[Padmarao Begari]

The SiFive FSBL is replaced with U-Boot and stores in SD card and runs in M-mode at present.

The u-boot requires bbl image (bbl+vmlinux) to boot Linux at present.

Our next step is to change M-mode to S-mode in u-boot and removing bbl from  Linux image (bbl+vmlinux). 

Regards

Padmarao

[atish patra]

Hi Padmarao,
Thanks for the confirmation. 

On Fri, Oct 12, 2018 at 12:35 AM Padmarao Begari <padma...@gmail.com> wrote:

The SiFive FSBL is replaced with U-Boot and stores in SD card and runs in M-mode at present.

The u-boot requires bbl image (bbl+vmlinux) to boot Linux at present.

Our next step is to change M-mode to S-mode in u-boot and removing bbl from  Linux image (bbl+vmlinux). 

Awesome. Does that mean you are planning to implement SBI as well in uboot or bbl continue to exist in M mode ?
Can you please explain the boot flow design if u-boot runs in S-mode ?

Regards,
Atish

 

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/dfaca48a-b9b5-4408-94a2-c26aa8523874%40groups.riscv.org.

--

Regards,

Atish

[Anup Patel]

Yes, thats better.

U-boot should run in S-mode only so that we can later on use same
U-boot as bootloader for Guest/VM.

In fact, it should also be possible run U-boot on QEMU Virt machine
using BBL (i.e. using bbl+uboot).

Regards,
Anup

> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/dfaca48a-b9b5-4408-94a2-c26aa8523874%40groups.riscv.org.

[Anup Patel]

On Fri, Oct 12, 2018 at 1:18 PM atish patra <atis...@gmail.com> wrote:
>
> Hi Padmarao,
> Thanks for the confirmation.
>
> On Fri, Oct 12, 2018 at 12:35 AM Padmarao Begari <padma...@gmail.com> wrote:
>>
>> The SiFive FSBL is replaced with U-Boot and stores in SD card and runs in M-mode at present.
>> The u-boot requires bbl image (bbl+vmlinux) to boot Linux at present.
>>
>> Our next step is to change M-mode to S-mode in u-boot and removing bbl from Linux image (bbl+vmlinux).
>>
>
> Awesome. Does that mean you are planning to implement SBI as well in uboot or bbl continue to exist in M mode ?
> Can you please explain the boot flow design if u-boot runs in S-mode ?

Please no M-mode code in U-boot or any general purpose bootloader.

Instead of replacing SiFive FSBL with U-Boot, I suggest to boot
bbl+uboot.bin from SiFive FSBL

U-boot can use SBI services just like any other S-mode software.

U-boot should boot RAW Linux image (instead of vmlinux) using bootm.

The role of last stage bootloader (such as U-boot, UEFI, Grub, etc) is
to support booting protocol for
variety of OSes (Linux, BSD, Vxworks, etc). There should be no
restriction on what last stage
bootloader will be except that it should run in S-mode. For any M-mode
facilities, it should use
SBI calls just like Linux.

Regards,
Anup

[Christoph Hellwig]

On Fri, Oct 12, 2018 at 01:35:02PM +0530, Anup Patel wrote:
> > Awesome. Does that mean you are planning to implement SBI as well in uboot or bbl continue to exist in M mode ?
> > Can you please explain the boot flow design if u-boot runs in S-mode ?
>
> Please no M-mode code in U-boot or any general purpose bootloader.

Indeed, that is what I feared :(

> Instead of replacing SiFive FSBL with U-Boot, I suggest to boot
> bbl+uboot.bin from SiFive FSBL

That would be more useful indeed.

[ron minnich]

I'm surprised to see this idea but in any event coreboot replaces bbl and has m mode code and I don't expect that to change. I'm done with trusting vendor supplied fsbl no matter what the source.

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/20181012080840.GA27426%40lst.de.

[Paul Walmsley]

Many embedded users will have no desire to run any external firmware
beyond an open-source bootloader and the kernel.

No one should be discouraging that use-case, as it reflects the needs of
a significant chunk of the user base.

That's worked fine on ARM for many years, and it's the same approach
that folks should keep in mind for RISC-V, even if people might not
understand why others want that.


- Paul

[Paul Walmsley]

Yes - for RISC-V U-boot, it's best to follow the example set by the ARM64 U-boot folks and support booting in any mode:

https://github.com/theopolis/u-boot/blob/master/doc/README.arm64

- Paul

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAP6exYKr_uHoX1FvKSTnPB8gPkYzYY0LOKB%2BbvTvYiyV%3DcfgfA%40mail.gmail.com.

[kr...@berkeley.edu]

Ron,

Please don't confuse the desire to separate M-mode functionality from
S-mode functionality for the purposes of making code more portable,
with a desire by vendors to lock down M-mode.

Having a clean separation of concerns between abstraction layers is
important for engineering reasons, and is completely orthogonal to
whether each abstraction layer is open or not.

We want to enable platforms that don't trust the OS or even
bootloaders, as much as we want to allow platforms that don't trust
vendor firmware. We also want to make it easier to build emulations
and flexible virtualization systems.

My comments are not meant to read on any of the proposals below, but
just on the sentiment that somehow specifying this abstraction
interface will prevent open implementations of the abstraction
interface, or prevent different implementations that ignore the
abstraction interface.

Krste

| CAP6exYKr_uHoX1FvKSTnPB8gPkYzYY0LOKB%2BbvTvYiyV%3DcfgfA%40mail.gmail.com.

[ron minnich]

Krste, thanks, I was only reacting to this sentence:

"Please no M-mode code in U-boot or any general purpose bootloader."

U-boot and coreboot live in the same "place" in the boot path, usually called firmware. Some people call them bootloaders, although I do not.

Since the first port in 2014, coreboot has always started in M-mode, and has always provided an SBI implementation, and will continue to do so. 

Further, we're looking at the following model for things coreboot loads (payloads)

- payload can be loaded in M mode and if it is, is allowed to replace existing M-mode code with its own (this includes Linux)

  coreboot will not write protect or lock away the M mode code area

- payload can be loaded in S mode and if it is, we assume it uses coreboot's M-Mode code. 

  coreboot might write protect the M mode code area but will never revoke execute or write permissions.

  revoking read access to M-mode is just another instance of security through obscurity and it worries me. But vendors do this

  type of thing all the time (See: SMM)

I was a bit concerned by several comments on this thread implying firmware running in M-mode is not desirable. 

I would certainly be worried should a given riscv implementation and mask rom make it impossible for coreboot to start in M-mode.

Thanks

ron

[alist...@gmail.com]

I agree that we shouldn't trust vendor firmware. It is always buggy at best.

The problem that I see with starting coreboot or u-boot (the last stage bootloaders) in M mode is that we then end up with duplicated work between the projects.

This is where a model like Arm Trusted Firmware fits in well. We can see something like this:

 1. CPU boots up and ROM does it's thing

 2. ROM boots into an open source firmware (ATF equivalent) in M mode

    - This will end up being pretty SoC specific

 3. The firmware boots into u-boot or core boot in S mode (or H mode when that exists)

    - Hopefully this can then be as generic as possible

 4. From there we boot the system

The advantage I see with this is that we only need to implement the M mode functionality once and then coreboot, u-boot and anything else can utilise it. It also keeps bigger later stage boot loaders out of M mode which has a mild security benefit of smaller attack surfaces.

The other aim is to allow a single RISC-V image to boot on a variety of different SoCs. The more generic we can make the last stage boot loaders the more achievable this is.

Alistair

[Tommy Murphy]

On Friday, 12 October 2018 22:12:08 UTC+1, alist...@gmail.com wrote:

I agree that we shouldn't trust vendor firmware. It is always buggy at best.

 

But once the source is open/available surely one can see what's going on and address problems/bugs as needed? 

Declaration/disclaimer: I work for Microchip/Microsemi.

[ron minnich]

On Fri, Oct 12, 2018 at 2:40 PM Tommy Murphy <tommy_...@hotmail.com> wrote:

On Friday, 12 October 2018 22:12:08 UTC+1, alist...@gmail.com wrote:

I agree that we shouldn't trust vendor firmware. It is always buggy at best.

 

But once the source is open/available surely one can see what's going on and address problems/bugs as needed? 

40 years of experience shows otherwise. The only thing that works is if everyone always has the ability to compile and build their firmware, and from more than one source.

A very similar argument to the one we use for open source kernels, in fact.

ron 

[ron minnich]

On Fri, Oct 12, 2018 at 2:12 PM <alist...@gmail.com> wrote:

I agree that we shouldn't trust vendor firmware. It is always buggy at best.

The problem that I see with starting coreboot or u-boot (the last stage bootloaders) in M mode is that we then end up with duplicated work between the projects.

Sure. There's lots of duplicated work between kernels (BSD, Linux, ...); compilers (clang, gcc); browsers, shells, editors ...

nobody has ever made a convincing argument that this is a problem. And it's not a problem for firmware.

 

This is where a model like Arm Trusted Firmware fits in well. We can see something like this:

... 

(interested text removed :-)

 

The advantage I see with this is that we only need to implement the M mode functionality once and then coreboot, u-boot and anything else can utilise it. It also keeps bigger later stage boot loaders out of M mode which has a mild security benefit of smaller attack surfaces.

I don't see any advantage. If M-mode is so complex that we can only have one workable implementation, something's gone horribly wrong in RISC-V.

We also learned the value of multiple  firmware implementations back in the linuxbios days, over and over again, particularly on the early opteron: an AMD engineer told us the linuxbios hypertransport enumeration code was better than what AMD had. And we knew this from experience: companies had opteron mainboards that would not boot if socket 0 was empty, and linuxbios had no trouble with that at all.

So, no, software monoculture is not a good idea for firmware, as it is not a good idea anywhere else.

ron 

[alist...@gmail.com]

I'm not saying that we have to have one implementation. I just see a lot of value in separating what runs in M mode and what runs in S mode.

If someone wanted to they can run something that handles both, nothing is stopping them from doing that. There is no enforcement of mono-culture or of vendor firmware.

I just see a lot of value in separating the firmware from the last stage bootloader. As part of this though we would need to come up with a firmware option that can be used for those who want to.

Alistair

 

ron 

[ron minnich]

On Fri, Oct 12, 2018 at 3:43 PM <alist...@gmail.com> wrote:

I just see a lot of value in separating the firmware from the last stage bootloader. As part of this though we would need to come up with a firmware option that can be used for those who want to.

I guess I don't understand the distinction. On chromebooks, for example, coreboot is the firmware and the last stage bootloader. And certainly u-boot on many systems is the firmware and last stage bootloader.  This is an area with lots of variety :-)

But all that said, if we're not closing off firmware and even kernels from having M-mode components they provide, I'm fine.

[Luke Kenneth Casson Leighton]

On Fri, Oct 12, 2018 at 10:12 PM <alist...@gmail.com> wrote:

> The problem that I see with starting coreboot or u-boot (the last stage bootloaders)
> in M mode is that we then end up with duplicated work between the projects.

yes. that has not stopped either project from continuing. it also
hasn't stopped libreboot, or grub, or the system which allows a linux
kernel to actually *be* the bootloader (which runs an initramfs and
calls kexec).

each of these bootloaders has different fans and userbases. they
don't necessarily talk to each other, and that's just how it is.

expecting each independent team to cooperate, particularly when some
of them are hard forks of other bootloader projects, is not realistic.

> This is where a model like Arm Trusted Firmware fits in well.

you mean, ARM _treacherous_ firmware? the "trust" you refer to is
directed at *manufacturers*, providing the specific goal of
*betraying* users. "Trust Us. We Will HELP You To Prevent And
Prohibit Users From Owning Their Devices".

>We can see something like this:
> 1. CPU boots up and ROM does it's thing
> 2. ROM boots into an open source firmware (ATF equivalent) in M mode
> - This will end up being pretty SoC specific

yes. and may not fit into the available memory, which may be
absolutely tiny.

the ROM bootloader, which is best made about as ridiculously dumb and
tiny as can possibly be made, is usually just about capable of loading
from a single (16k) sector of a Micro-SD or eMMC device, or 16k from
an SPI device, or 16k from an ONFI NAND, and so on. that sub-16k
executable the "first stage" bootloader.

16K is the "normal" amount of available SRAM that SoCs are prepared to
allocate for these first-stage bootloaders. that 1st stage basically
does things like "initialise the DDR3 RAM, set up IRQs"... oh and it
happens to initialise the
device-from-which-the-next-phase-is-to-be-loaded.

in u-boot, this first stage bootloader is called the "SPL", and it's
compiled from u-boot with some special #defines that *MASSIVELY* cut
down u-boot to the absolute, absolute bare minimum (surprise: under
16k).

all of this is typically entirely hidden from end-users. you don't
have to know. you don't have to care. people have *no idea* that
their system goes through a four, five or even six stage boot process
to get to an OS. even intel x86 systems.

basically i'm saying that "one size does not fit all", that creating
standards in this area is not only unrealistic but also completely
undesirable it is so heavily application-specific, and that
restricting vendors through standardisation to be not permitted to run
from the absolute lowest possible level (M-Mode) will almost certainly
cause a massive back-lash.

*on the other hand*, if there exists *informal reference source code*
out there, that's absolutely fantastic, as it will cut down massively
on development NREs. example ROM bootloaders, for example, would be
fantastic.

why would it be fantastic? because the entire process is so
proprietary, so secret, that very few people actually know what's
involved. full libre-licensed source code - preferably with
libre-licensed overview documents - would completely change how SoCs
are developed.

l.

[alist...@gmail.com]

On Friday, October 12, 2018 at 4:23:10 PM UTC-7, Luke Kenneth Casson Leighton wrote:

On Fri, Oct 12, 2018 at 10:12 PM <alist...@gmail.com> wrote:

> The problem that I see with starting coreboot or u-boot (the last stage bootloaders)
> in M mode is that we then end up with duplicated work between the projects.

 yes.  that has not stopped either project from continuing.  it also
hasn't stopped libreboot, or grub, or the system which allows a linux
kernel to actually *be* the bootloader (which runs an initramfs and
calls kexec).

 each of these bootloaders has different fans and userbases.  they
don't necessarily talk to each other, and that's just how it is.

 expecting each independent team to cooperate, particularly when some
of them are hard forks of other bootloader projects, is not realistic.

> This is where a model like Arm Trusted Firmware fits in well.

 you mean, ARM _treacherous_ firmware?  the "trust" you refer to is
directed at *manufacturers*, providing the specific goal of
*betraying* users.   "Trust Us.  We Will HELP You To Prevent And
Prohibit Users From Owning Their Devices".

That seems a little harsh. ATF is open source and you can compile it yourself from the source to deploy. You are also free to re-write it if need be.

The risk that I see with just letting everyone go their own way is that we will end up with a similar situation to the ARM world.

That is that every SoC vendor does their own thing. This can result in a less open ecosystem as every vendor writes their own boot code and keeps it closed.

The other problem I see is a fragmented boot process. Where some boards use coreboot and some use u-boot and some use something else. We will then get to a point where every board is different. x86 has this pretty much sorted as I can boot my Linux USB stick on every PC I own. ARM is the exact opposite of this. I would like to see RISC-V not go down this fragmentation route. One way to do this is just to have a "best" way to setup the boot process. Then SoC vendors will hopefully opt to follow it.

A mix-mash of ways seems like a dangerous path to lead to fragmentation and confusion and that is what I'm afraid of.

Alistair

 

l.

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Oct 13, 2018 at 12:45 AM <alist...@gmail.com> wrote:

> That seems a little harsh. ATF is open source and you can
> compile it yourself from the source to deploy. You are also free to re-write it if need be.

superb (and thank you for the additional, missing, qualifying
information). then by definition it's not treacherous.

>> why would it be fantastic? because the entire process is so
>> proprietary, so secret, that very few people actually know what's
>> involved. full libre-licensed source code - preferably with
>> libre-licensed overview documents - would completely change how SoCs
>> are developed.
>
>
> The risk that I see with just letting everyone go their own way is that we will end up with a similar situation to the ARM world.
>
> That is that every SoC vendor does their own thing. This can
> result in a less open ecosystem as every vendor writes their own
> boot code and keeps it closed.

there's a reason for that, despite in many cases the code that
vendors being used actually being GPLv2-licensed (and thus they
release criminally-infringing products). i'll back-track and post on
that from a different point in the thread.

> The other problem I see is a fragmented boot process.

this is just an unavoidable reflection of the disparate
hardware-level requirements and design constraints that implementors
face.

> x86 has this pretty much sorted as I can boot my
> Linux USB stick on every PC I own.

yah. have you tried booting it when the SPI bootloader chip on the
motherboard is empty, corrupted, or missing? have you tried asking
intel for information about how the first stage bootloader process
actually works? try those things... it's extremely illuminating.

> One way to do this is just to have a "best" way to setup
> the boot process. Then SoC vendors will hopefully opt to follow it.

i specifically avoided the use of the word "best", as that implies
that "other means and methods are worst". however you've pretty much
said exactly what i said, just in different words.

> A mix-mash of ways seems like a dangerous path to lead
> to fragmentation and confusion and that is what I'm afraid of.

like i said: fragmentation, here, is just unavoidable, and efforts to
standardise *WILL* mean with stone-walling. you cannot possibly
expect completely different hardware to have anything in common at the
*boot initialisation* level, and we know from experience that attempts
at abstraction result in bloat.

bloat when you have only 16K to play with... the first thing that
gets cut is: attempts at abstraction.

l.

[ron minnich]

On Fri, Oct 12, 2018 at 4:45 PM <alist...@gmail.com> wrote:

That seems a little harsh. ATF is open source and you can compile it yourself from the source to deploy. You are also free to re-write it if need be.

I agree. ARM has been very good about ATF, in fact it's a model of how it can be done. I'm sorry to see this type of message in what has been an interesting technical discussion. 

 

A mix-mash of ways seems like a dangerous path to lead to fragmentation and confusion and that is what I'm afraid of.

I don't see that multiple implementations necessarily lead to this case, but you make a fair point. 

Anyway, my question has been answered: the things I want will remain possible, so I'm happy.

Thanks everyone.

ron

[alist...@gmail.com]

To a certain extent it's unavoidable, but if RISC-V is ever going to take off we are going to have to at least somewhat deal with it. Booting ARM boards today is such a pain that I suspect 90% of people give up and just take the prebuilt binaries from the SoC vendor. It is a hassle and if we tackle this early on we might be able to reduce this for RISC-V.

At least the first step is are guide lines of what should be implemented and where. Just to have everyone on the same page is very helpful.

For example saying that the first stage boot loader must start in M (obviously) and the last stage in S. That means that you can have one binary that does both, or two binaries separately. Even a very basic and general best practices will help push vendors to do the right thing and make it easier for developers.This can even be done just using current implementations as reference. It just hopefully stops someone in the future doing something super crazy that doesn't work well with anyone else.

I still prefer the layered approach that ATF follows, but any standardisation is good, so we can drop that out.

Alistair

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Fri, Oct 12, 2018 at 6:42 PM <kr...@berkeley.edu> wrote:
>
>
> Ron,
>
> Please don't confuse the desire to separate M-mode functionality from
> S-mode functionality for the purposes of making code more portable,
> with a desire by vendors to lock down M-mode.
>
> Having a clean separation of concerns between abstraction layers is
> important for engineering reasons, and is completely orthogonal to
> whether each abstraction layer is open or not.
>
> We want to enable platforms that don't trust the OS or even
> bootloaders, as much as we want to allow platforms that don't trust
> vendor firmware. We also want to make it easier to build emulations
> and flexible virtualization systems.

these are reasonable statements and a good reflection of a wide range
of goals and requirements from many different sources.

the mention of abstraction however has me twitching, slightly, where
(as mentioned in another reply), the design constraints are so
disparate, and the available memory constraints so insanely low, that
putting in any kind of abstraction is almost certainly likely to fail,
as the first thing that vendors will do is look at the hardware cost
of doing so, and reject it immediately.

chain-loading on the other hand - multi-stage bootloading - not a
problem, and is extremely common:

* http://linux-sunxi.org/EGON#eGON.BRM and you can see a link to the
BROM page as well. following the reverse-engineering that is
described, there, u-boot now supports the "eGON" header format for
allwinner SoCs, such that u-boot's "SPL" first stage bootloader is
recognised.

* http://opensource.rock-chips.com/wiki_U-Boot - here you see "u-boot
SPL" which is that 1st-stage bootloader previously mentioned. the
RK3288 is a bit annoying as the 1st stage bootloader has to be CRC/RC4
encrypted and signed. and that's in the boot ROM so is completely
impossible to circumvent. or fix.

where confusion might arise from what you wrote, krste, is that
normally, u-boot's first-stage SPL (and likely the coreboot
equivalent) *absolutely* has to be run in M-Mode. where else would
the DDR3 timings, the PLL, IRQs and other absolutely essential
peripherals be initialised?

and, that being the case, if u-boot or coreboot were operating in
S-Mode, it would be impossible for those hardware-level
initialisations to be properly carried out. more to the point: what
got u-boot / coreboot *into* S-Mode in the first place??

:)

so, logically, when you refer to a desire to run "bootloaders" in
S-Mode we may *deduce* that you are NOT referring to the ENTIRE boot
process, that instead that you may be referring to the SECOND phase of
u-boot / coreboot. i.e. definitely *not* the (16-or-so-K) first phase
(known as SPL mode for u-boot)... [unless the processor's bootrom has
already done so... which would be hugely risky from a design
perspective]

here - the second phase - it _might_ be reasonable (and possible) to
run from S-Mode. binary sizes are 600k to 2MB (estimated), in main
(DDR) memory. it just depends on whether there was enough spare SRAM
on the processor for a first-stage boot loader with S-Mode
initialisation to *actually fit*.

*that may not actually be the case*... and you'd be looking instead
at triple-stage loading.

really i just want to make people aware, this area is quite involved,
and the number of people in the world who know what's going on *and we
can communicate with because they're not under NDA* is very small: the
members of the u-boot team, plus the members of the coreboot team, and
libreboot as well.

getting their input here - and making absolutely sure that they're
properly compensated for their time (reminder to Foundation Members:
please read section 2.3 of your Member Charter Agreement) - is
absolutely essential.


one other thing that has me concerned: most DDR3/4 vendors FORCE
customers to sign ridiculously-restrictive NDAs, that do not even
permit them to release the source code of the DDR3/4 initialisation
sequence.

the *only* way for fabless semiconductors to release useful product
(i.e. product that will actually boot) is:

(a) release a proprietary first stage bootloader [and then wait for
libre software engineers to reverse-engineer it. in their "spare"
time. unpaid.]

(b) criminally infringe copyright law.

Allwinner and many other Chinese Fabless semiconductor companies
systematically choose option (b). Western corporations, who
understand a little bit more about Copyright Law, typically choose
option (a).

i suspect that even SiFive has had to face this situation. and may
even be under such a restrictive NDA that they can't even talk about
it. anyone at SiFive who can confirm that, would be nice to hear from
you. of course... if we _don't_ hear from you... :)

l.

[Luke Kenneth Casson Leighton]

On Sat, Oct 13, 2018 at 1:16 AM <alist...@gmail.com> wrote:

> To a certain extent it's unavoidable, but if RISC-V is ever going to take off we are going to have to at least somewhat deal with it. Booting ARM boards today is such a pain that I suspect 90% of people give up and just take the prebuilt binaries from the SoC vendor. It is a hassle and if we tackle this early on we might be able to reduce this for RISC-V.

no. really. please. try to understand and accept the implications,
here. if you want RISC-V to be in the embedded world, and in multiple
SoCs, and in desktops, and in high-end servers, you have to accept the
reality of the absolutely massive fundamental hardware differences
between all those different scenarios, where the bootloader and
bootloader choice absolutely necessarily reflects that.

if you start talking about UEFI to low-cost tablet vendors for
example they will just laugh at you. and if you even mention ACPI to
them as a required standard as part of a boot process, they'd be quite
likely to punch your lights out (and i would cheer and congratulate
them).

x86 does not have this "problem" that ARM has because x86 has FAILED
to enter the ARM-dominated SoC market. despite intel bribing vendors,
sellers, OEMs *and customers* to buy their products, they *still could
not get market share*. yes, i've been talking to a business
development manager for an ARM-based fabless semi company, who
regularly was asked, "how much are YOU going to pay US to use your
SoC, because that's what intel does".

all that having been said: i concur that *if* full source code is
available (and available early enough), chances are indeed high that
fabless semi companies will just cookie-cut the available solutions.

unfortunately, the DDR3/4 hard macro vendors (who typically provide
proprietary initialisation source code under insane NDAs) are going to
get in the way, there.

so that's down to the early adopters - SiFive in particular as the
high-profile one - to take responsibility for that, and tell the
DDR3/4 interface vendors in no uncertain terms that proprietary
licensing on the DRAM initialisation is not acceptable.

l.

[Samuel Falvo II]

On Fri, Oct 12, 2018 at 4:23 PM Luke Kenneth Casson Leighton
<lk...@lkcl.net> wrote:
> basically i'm saying that "one size does not fit all", that creating
> standards in this area is not only unrealistic but also completely
> undesirable it is so heavily application-specific, and that
> restricting vendors through standardisation to be not permitted to run
> from the absolute lowest possible level (M-Mode) will almost certainly
> cause a massive back-lash.
>
> *on the other hand*, if there exists *informal reference source code*
> out there, that's absolutely fantastic, as it will cut down massively
> on development NREs. example ROM bootloaders, for example, would be
> fantastic.

I'm going to once again put forth the idea that it was a mistake for
the RISC-V community to settle on an ITU-style standards setting
process. While it may prove advantageous in some circumstances, I
think it sets a bad precedent overall where viable implementations
come second to the desire for an up-front, all-inclusive, frequently
self-inconsistent standard with which everyone must conform. See also
CORBA.

If standards are genuinely desirable, then I **strongly** encourage
the use of IETF-inspired standards track processes. I cannot
emphasize this enough. The process is 100% compatible with the idea
that implementation-specific boot-loaders are not only possible, but
even expected. IETF's processes say you need at least two (more are
preferred) independent, working, and interoperable implementations for
your (bootstrap) proposal to be even *considered* for RFC status.
This is a recognition that standards evolve bottom-up, and aren't
dictated top-down. It really doesn't matter how many RFCs related to
a topic exists (for example, there exists no fewer than four remote
service invokation mechanisms: XDR, NDR, XML-RPC, and SOAP); the
market will eventually sort out which one becomes dominant. And when
one (or a couple) becomes dominant, you get to say things like, "This
system complies with RFC-12345 bootstrapping standards," or "Our
latest model now supports RFC-12345."

--
Samuel A. Falvo II

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Oct 13, 2018 at 1:16 AM <alist...@gmail.com> wrote:

> For example saying that the first stage boot loader
> must start in M (obviously) and the last stage in S.
> That means that you can have one binary that does both,

sorry, i missed this: no, you can't. really, you can't. the
processor is typically booted up with the DDR3/4 RAM *COMPLETELY
DISABLED*. as in; ***SWITCHED OFF***.

the only way to get it up and running is to turn it on, then do some
scans to find out what DRAM (and what type of DRAM) is there (and in
which banks), then tell both DRAM and Controller to start doing
impedance matching... it's *horrendously* complex, and most first
stage bootloaders do the absolute bare minimum (get the DDR3/4 RAM
running at say 200-300mhz) then leave the rest to second-stage.

the only way to load programs that do that is to have *SRAM* on-board
the processor, which, given that you need a minimum of 16k,
realistically, it's quite a lot to put down in a processor, so you
want to minimise the amount. you could hypothetically put the DRAM
initialisation into ROM however you would be taking a serious risk to
do so, as future DRAM from third party vendors could be incompatible,
ending the life of the processor immediately.

> or two binaries separately.

or, as i mentioned in the message to krste, three. first stage
M-Mode and initialising DRAM (and other critical peripherals). second
stage S-Mode initialisation. *THIRD* stage "main" boot loader, what
most people think of as "u-boot" (or coreboot).

all done as chain-loaders.

there is one _hell_ of a lot going on to get a processor up and running.

l.

[Anup Patel]

I totally agree with Alistair's comments.

The intentions behind having last stage bootloader run only in S-mode are:
1. Re-use it for VS-mode. In other words, it should be possible to
re-use last stage bootloader under a Guest/VM.
2. Platform specific services for CPU hotplug, Reboot, Shutdown, Power
management, Image authentication, etc (i.e. SBI calls) should be
provided by platform specific M-mode firmware

We certainly don't want #2 to be replicated across bootloaders (Uboot,
Coreboot, UEFI, etc). The best people to maintain code related to #2
are SOC vendors themselves. Of course, code related to #2 has to open
source so that people get chance to fix bugs themselves and also have
transparency.

It is also important that we don't want separate bootloader for
Guest/VM (i.e. VS-mode) so last stage bootloader should consider
Guest/VM requirements (i.e. #1 above)

Both above points are not cooked-up ideas, these are based on failures
and learning from ARM world. There is not point of discussion if
people want to re-invent wheel here.

For RISC-V ecosystem to succeed, all good practices from other
architectures should be considered from start itself.

It is better to take the pain now and get booting flow standardised
for RISC-V systems. It will be very difficult in future when we have
lot of RISC-V systems with there own booting flow.

Regards,
Anup

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Sat, Oct 13, 2018 at 7:45 AM Anup Patel <an...@brainfault.org> wrote:

> On Sat, Oct 13, 2018 at 5:46 AM <alist...@gmail.com> wrote:

> > I still prefer the layered approach that ATF follows, but any standardisation is good, so we can drop that out.
> >
> > Alistair
> >
>
> I totally agree with Alistair's comments.
>
> The intentions behind having last stage bootloader run only in S-mode are:
> 1. Re-use it for VS-mode. In other words, it should be possible to
> re-use last stage bootloader under a Guest/VM.

yes, this is a reasonable aim.

just bear in mind that each boot system being developed usually finds
it easier to go through their own chain-loading system and on
subsequently to a full OS. to add support for anything other than
that actually requires speciic effort (which obviously some
corporation has to pay for).

any kind of inter-project cross-collaboration - opportunities for
standardisation - is usually an informal affair that's completely by
accident, from a slow "organic" growth.

for example, UEFI was forced onto teams through x86 BIOSes adopting
it. consequently, YEARS after it became mainstream in the x86 world,
if you now google "u-boot UEFI" it is actually possible to do, and
there is in fact a talk about "marrying u-boot, uEFI and grub2":

https://www.cnx-software.com/2016/08/11/u-boot-now-supports-uefi-on-32-bit-and-64-bit-arm-platforms/

https://www.youtube.com/watch?v=qJAkJ3nmWgM

> 2. Platform specific services for CPU hotplug, Reboot, Shutdown, Power
> management, Image authentication, etc (i.e. SBI calls) should be
> provided by platform specific M-mode firmware
>
> We certainly don't want #2 to be replicated across bootloaders (Uboot,
> Coreboot, UEFI, etc).

apologies for putting it this way, anup: i appreciate that you're not
*actually* saying this: what you've written may very unfortunately be
interpreted as an unpaid "demand" - an order that must be obeyed - to
the u-boot and coreboot developers (and to the grub developers who
have an implementation of UEFI) that they absolutely must follow and
do precisely and exactly what you have said.

the closest that you can get is as follows:

(1) create a reasonable and rational logical argument and, in NEUTRAL
TERMS, propose it (separately) to the u-boot developers and to the
coreboot developers, and the grub developers.

(2) include an offer of compensation and payment for services as part
of the contact with those respective teams

(3) if there is no take-up (no interest) implement it yourself and
*demonstrate* that it's a good idea.

you cannot in *any way* expect sovereign libre project developers -
many of whom are chronically underfunded and absolutely sick and tired
of MULTIPLE BILLION DOLLAR corporations PERSISTENTLY spongeing off of
their expertise and time - to drop everything and "do what you want".

i know you *didn't* make demands of software libre teams: please
however be extremely careful how you put things, ok?

> The best people to maintain code related to #2
> are SOC vendors themselves. Of course, code related to #2 has to open
> source so that people get chance to fix bugs themselves and also have
> transparency.

indeed. and the upstream developers adequately compensated and paid
for their time. this does not "go without saying". it's something
that corporations have to actively take responsibility for. you made
money? PAY the people on whose success that money is critically
dependent!

i'll mention the words "shellshock", "heartbleed" and leave it at that.

> It is also important that we don't want separate bootloader for
> Guest/VM (i.e. VS-mode) so last stage bootloader should consider
> Guest/VM requirements (i.e. #1 above)
>
> Both above points are not cooked-up ideas, these are based on failures
> and learning from ARM world.

indeed... so that means that a full and comprehensive analysis *of*
the ARM world is needed. all of it. right from the Cortex M-series,
through the ARM9, ARM11, Cortex A8, A7/15, to the A53 and beyond.

then studying the way that PowerPC mirrored x86, and why MIPS
architectures do not, for example.

in other words, it's not just about saying "ARM was a failure because
the boot world is a mess", you have to understand **WHY** it got that
way in the first place.

and in doing so, you may learn that there are extremely good reasons why.

> There is not point of discussion if
> people want to re-invent wheel here.

equally there is no point in discussion if there is a failure to
recognise the reality of quite how disparate the hardware world really
is.

also, again: i'm obliged to remind you that you don't get to tell
software libre developers "what to do". if they want to reinvent
wheels as spheres, squares or other shapes, that's entirely their
prerogative, and you cannot in any way stop them.

secondly: i know you are not (i'm wording it deliberately this way by
way of illustration) - are you *really* proposing, for example, that a
low-cost RISC-V tablet processor design companyy be FORCED to use UEFI
boot, for example, because it "Shall Become A Standard That Is To Be
Forced Onto People In the RISC-V World"?

> For RISC-V ecosystem to succeed, all good practices from other
> architectures should be considered from start itself.

absolutely. except i would not make it *absolutely* conditional that
"RISC-V will *FAIL* if all good practices are not considered", which
is unfortunately a possible implication of the wording that you've
chosen here.

> It is better to take the pain now and get booting flow standardised
> for RISC-V systems.

anup: you have jumped the gun, here. it is very strange. in one
sentence you say "RISC-V should look at good practices from other
architectures", and then *IMMEDIATELY* jump to, "and that process is
ABSOLUTELY going to result in standardisation for RISC-V boot
procedures".

that sounds like the proposed review of good practices from other
architectures is a loaded, foregone conclusion. you see how that
could be bad?

> It will be very difficult in future when we have
> lot of RISC-V systems with there own booting flow.

nooo, the future will reflect what individual diverse fabless
semiconductor companies with completely and utterly different hardware
and customer requirements *need* from a boot flow.

basically what i would like to get across to people here, is, that
u-boot, coreboot, libreboot and the grub developers have been at this
for a lot longer than RISC-V has been around. their expertise and
approach actually takes precedence over that of RISC-V! u-boot has to
deal with thousands of disparate systems (only a tiny handful of which
are *developer* boards with RISC-V cores)

RISC-V is the *newcomer* here. people may *want* boot
standardisation in RISC-V in order to reduce development and
maintenance costs (a desirable goal), however starting from a position
of assuming or implying that the teams who manage those projects must
be "stupid" by having gone their own separate ways and having
"reinvented wheels", is not going to fly.

also a reminder to RISC-V Foundation Members of section 2.2:
https://content.riscv.org/wp-content/uploads/2016/01/RISC-V-Foundation-Membership-Agreement-8Dec2016.pdf

"During the term of its membership in Foundation, Member is expected
to support the free and open design, development and improvement of
the RISC-V ISA, together with its software and hardware ecosystem for
use in all computing devices."

l.

[Anup Patel]

I tried to explain my view in best possible way. If this is taken as
unpaid demand then that was not the intention.

>
> the closest that you can get is as follows:
>
> (1) create a reasonable and rational logical argument and, in NEUTRAL
> TERMS, propose it (separately) to the u-boot developers and to the
> coreboot developers, and the grub developers.
>
> (2) include an offer of compensation and payment for services as part
> of the contact with those respective teams
>
> (3) if there is no take-up (no interest) implement it yourself and
> *demonstrate* that it's a good idea.
>
> you cannot in *any way* expect sovereign libre project developers -
> many of whom are chronically underfunded and absolutely sick and tired
> of MULTIPLE BILLION DOLLAR corporations PERSISTENTLY spongeing off of
> their expertise and time - to drop everything and "do what you want".
>
> i know you *didn't* make demands of software libre teams: please
> however be extremely careful how you put things, ok?

I see this getting derailed. The whole discussion about what should be
correct boot flow.

The "should" in my comment should not be interpreted unpaid demand. The
"should" here is the sense "what I think correct way is".

>
> > The best people to maintain code related to #2
> > are SOC vendors themselves. Of course, code related to #2 has to open
> > source so that people get chance to fix bugs themselves and also have
> > transparency.
>
> indeed. and the upstream developers adequately compensated and paid
> for their time. this does not "go without saying". it's something
> that corporations have to actively take responsibility for. you made
> money? PAY the people on whose success that money is critically
> dependent!
>
> i'll mention the words "shellshock", "heartbleed" and leave it at that.
>
>
> > It is also important that we don't want separate bootloader for
> > Guest/VM (i.e. VS-mode) so last stage bootloader should consider
> > Guest/VM requirements (i.e. #1 above)
> >
> > Both above points are not cooked-up ideas, these are based on failures
> > and learning from ARM world.
>
> indeed... so that means that a full and comprehensive analysis *of*
> the ARM world is needed. all of it. right from the Cortex M-series,
> through the ARM9, ARM11, Cortex A8, A7/15, to the A53 and beyond.
>
> then studying the way that PowerPC mirrored x86, and why MIPS
> architectures do not, for example.

Yes, of course.

People should certainly make suggestions/recommendations based on
their experiences with other architectures.

(Note: Please don't mis-interpret "should" here.)

>
> in other words, it's not just about saying "ARM was a failure because
> the boot world is a mess", you have to understand **WHY** it got that
> way in the first place.
>
> and in doing so, you may learn that there are extremely good reasons why.

Yes, of course.

I don't see people asking "WHY" were things done in a particular way
in some ABC architecture.

>
>
> > There is not point of discussion if
> > people want to re-invent wheel here.
>
> equally there is no point in discussion if there is a failure to
> recognise the reality of quite how disparate the hardware world really
> is.
>
> also, again: i'm obliged to remind you that you don't get to tell
> software libre developers "what to do". if they want to reinvent
> wheels as spheres, squares or other shapes, that's entirely their
> prerogative, and you cannot in any way stop them.

Again, please don't mis-interpret my statement.

>
> secondly: i know you are not (i'm wording it deliberately this way by
> way of illustration) - are you *really* proposing, for example, that a
> low-cost RISC-V tablet processor design companyy be FORCED to use UEFI
> boot, for example, because it "Shall Become A Standard That Is To Be
> Forced Onto People In the RISC-V World"?

I am not supporting any particular bootloader here.

I am trying to suggest what should be correct boot flow.

(Please don't mis-interpret "should" in above sentence)

>
>
> > For RISC-V ecosystem to succeed, all good practices from other
> > architectures should be considered from start itself.
>
> absolutely. except i would not make it *absolutely* conditional that
> "RISC-V will *FAIL* if all good practices are not considered", which
> is unfortunately a possible implication of the wording that you've
> chosen here.

I am done clarifying your mis-interpretations. Where have I implied
RISC-V will FAIL.

It was really interesting to see how simple comments can be
heavily mis-interpreted.

Regards,
Anup

[Luke Kenneth Casson Leighton]

On Sat, Oct 13, 2018 at 10:42 AM Anup Patel <an...@brainfault.org> wrote:

> It was really interesting to see how simple comments can be
> heavily mis-interpreted.

indeed it is... and not by me. i used phrases that indicated that
they *could* (third person) be misinterpreted.

l.

[Luke Kenneth Casson Leighton]

On Sat, Oct 13, 2018 at 10:42 AM Anup Patel <an...@brainfault.org> wrote:
>
> The whole discussion about what should be
> correct boot flow.

for which sub-design architecture? are you referring to the correct
boot flow for embedded systems with below 3MB of (internal) RAM? for
embedded systems with below 48k of (hard-coded, on-board) RAM?
low-cost smartphone / tablet SoC market where the mass-volume target
price of a 4-core 1.5ghz SoC is around USD $3, for use in products
where the OEM price will be under $30? chromebook/netbook style
systems? desktop systems? high-end server systems?

all of these have wildly disparate boot flow requirements, yet you
consistently refer to "one" boot flow, and also use the word
"correct", as if there shall be one and only one possible option. if
you had said, "the whole discussion is about what should be the best
recommended boot flow for each platform", i would have agreed with you
entirely.

apologies for saying this, anup: i feel that it is disingenuous to
claim that the "conversation has been derailed" when i am simply
pointing out that the points that you raised are incomplete,
oversimplified, and indicative of a lack of knowledge of this
extremely comprehensive and diverse area.

> I don't see people asking "WHY" were things done in a particular way
> in some ABC architecture.

i have. as a reverse-engineer and embedded systems engineer who has
over 20 years experience of board bring-up on dozens of systems (many
of them with zero knowledge) i've studied dozens of different
architectures.

i have indeed asked the question "why" for example is PowerPC such a
uniform and easy architecture to work with, when the 1000+ licensees
of ARM do not have it easy at all (one clue is in the "1000+").

l.

[Luke Kenneth Casson Leighton]

On Thu, Oct 11, 2018 at 12:10 PM Padmarao Begari <padma...@gmail.com> wrote:
>
> RISC-V U-Boot(64-bit) for HiFive Unleashed Board is available on GitHub
>
> https://github.com/Microsemi-SoC-IP/HiFive_U-Boot
>
> This repository contains the RISC-V U-Boot created by Microsemi a Microchip company for RISC-V core on HiFive Unleashed 540 device. The HiFive Unleashed Board is used for HiFive U-Boot development

padmarao, hi, as the discussion has changed topic, i thought it
important to say thank you and recognise the work that you and
microsemi have put in here. as someone who has worked on u-boot board
bring-up i know it is very detailed work, so thank you.

l.

[Anup Patel]

On Sat, Oct 13, 2018 at 3:37 PM Luke Kenneth Casson Leighton
<lk...@lkcl.net> wrote:
>
> On Sat, Oct 13, 2018 at 10:42 AM Anup Patel <an...@brainfault.org> wrote:
> >
> > The whole discussion about what should be
> > correct boot flow.
>
> for which sub-design architecture? are you referring to the correct
> boot flow for embedded systems with below 3MB of (internal) RAM? for
> embedded systems with below 48k of (hard-coded, on-board) RAM?
> low-cost smartphone / tablet SoC market where the mass-volume target
> price of a 4-core 1.5ghz SoC is around USD $3, for use in products
> where the OEM price will be under $30? chromebook/netbook style
> systems? desktop systems? high-end server systems?

Yap, ATF-like boot flow work perfectly fine for internal SRAM as
low as 128KB

I have seen this in both embedded and high-end server systems.

>
> all of these have wildly disparate boot flow requirements, yet you
> consistently refer to "one" boot flow, and also use the word
> "correct", as if there shall be one and only one possible option. if
> you had said, "the whole discussion is about what should be the best
>