amforth-devel

[Amforth] avra on a raspi zero v1

[Mark R. <cab...@gm...>]

Hello all.

I managed to day to cobble together my AmForth "computer" which is pretty
much the reason for avoiding using wine to build things. It consists of a
raspberry pi zero W v1(whatever point 5 maybe) as a base with raspian lite
on it. That has a usb hub, an old palm pilot folding keyboard the
connection to my uart for the controller and the usbasp to program. The
display was a bit overboard as it's a waveshare hdmi 800x480 7 inch thing
that makes it possible to actually use it for real.

Tonight I managed to get all the cobbled bits to work together and to build
everything including avra on the zero then flash the controller. So, no
real computer but using e4thcom after flashing let me get in and use that
nice big screen as a terminal.

I still haven't sorted out the single tick thing but I can kind of see
where it is coming from in avra. Pretty sure my C skills have faded over
the decades that it may just be a problem to look past.

I guess now it's time to work on a nice box for the whole thing so I could
sit anywhere, plug in a powerbank and hack away. I'll try and get some
better documentation up soon but it really wasn't terribly difficult. It
was really really nice to do everything from Raspian knowing that wine
wasn't an option.

Enjoy the weekend,
Mark

Re: [Amforth] avra on a raspi zero v1

[Erich W. <ew....@na...>]

Hello Mark, hello all,

congrats to your hack-box! :)

This is very close to what I am currently using (software wise).
I had ordered a Hifive Unmatched, a riscv64 computer in miniITX
Format. And once I got it going with Debian unstable, I
installed: avra, minicom (terminal), avrdude (burner), perl and
my scripts to use it for dabbling with amForth. No wine and
avrasm.exe involved. I have not upgraded my avra along the lines
mentioned recently, but I plan to. Granted, it is a much bigger
machine, but at least it is not collecting dust.

The warning with "'" missing a closing ' ... yes well. It does
work in the end, so no sweat.

Cheers,
Erich

Mark Roth <cab...@gm...> writes:

> Hello all.
>
> I managed to day to cobble together my AmForth "computer" which is pretty
> much the reason for avoiding using wine to build things. It consists of a
> raspberry pi zero W v1(whatever point 5 maybe) as a base with raspian lite
> on it. That has a usb hub, an old palm pilot folding keyboard the
> connection to my uart for the controller and the usbasp to program. The
> display was a bit overboard as it's a waveshare hdmi 800x480 7 inch thing
> that makes it possible to actually use it for real.
>
> Tonight I managed to get all the cobbled bits to work together and to build
> everything including avra on the zero then flash the controller. So, no
> real computer but using e4thcom after flashing let me get in and use that
> nice big screen as a terminal.
>
> I still haven't sorted out the single tick thing but I can kind of see
> where it is coming from in avra. Pretty sure my C skills have faded over
> the decades that it may just be a problem to look past.
>
> I guess now it's time to work on a nice box for the whole thing so I could
> sit anywhere, plug in a powerbank and hack away. I'll try and get some
> better documentation up soon but it really wasn't terribly difficult. It
> was really really nice to do everything from Raspian knowing that wine
> wasn't an option.
>
> Enjoy the weekend,
> Mark
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel


-- 
May the Forth be with you ...

Re: [Amforth] avra on a raspi zero v1

[Mark R. <cab...@gm...>]

> congrats to your hack-box! :)
>

Thanks! Slowly but surely I am collecting some better cables so I can put
it in an enclosure. :)

Hello weekend AmForth'ers

So, while waiting to see what will happen with the repo I have continued to
play with a git version for my own use. I have reworked the makefile and
made some changes to the repo structure to accommodate for the new avra
code (which is still only a placeholder until I get that repository in
properly). I think that the new makefile should make it very easy to get
started and there is a bit of a long winded readme to explain anything that
has changed. If anyone wants to take a look and give feedback that would be
great.

https://github.com/CableGuy67/AmForth

All the best,
Mark



> This is very close to what I am currently using (software wise).
> I had ordered a Hifive Unmatched, a riscv64 computer in miniITX
> Format. And once I got it going with Debian unstable, I
> installed: avra, minicom (terminal), avrdude (burner), perl and
> my scripts to use it for dabbling with amForth. No wine and
> avrasm.exe involved. I have not upgraded my avra along the lines
> mentioned recently, but I plan to. Granted, it is a much bigger
> machine, but at least it is not collecting dust.
>
> The warning with "'" missing a closing ' ... yes well. It does
> work in the end, so no sweat.
>
> Cheers,
> Erich
>
> Mark Roth <cab...@gm...> writes:
>
> > Hello all.
> >
> > I managed to day to cobble together my AmForth "computer" which is pretty
> > much the reason for avoiding using wine to build things. It consists of a
> > raspberry pi zero W v1(whatever point 5 maybe) as a base with raspian
> lite
> > on it. That has a usb hub, an old palm pilot folding keyboard the
> > connection to my uart for the controller and the usbasp to program. The
> > display was a bit overboard as it's a waveshare hdmi 800x480 7 inch thing
> > that makes it possible to actually use it for real.
> >
> > Tonight I managed to get all the cobbled bits to work together and to
> build
> > everything including avra on the zero then flash the controller. So, no
> > real computer but using e4thcom after flashing let me get in and use that
> > nice big screen as a terminal.
> >
> > I still haven't sorted out the single tick thing but I can kind of see
> > where it is coming from in avra. Pretty sure my C skills have faded over
> > the decades that it may just be a problem to look past.
> >
> > I guess now it's time to work on a nice box for the whole thing so I
> could
> > sit anywhere, plug in a powerbank and hack away. I'll try and get some
> > better documentation up soon but it really wasn't terribly difficult. It
> > was really really nice to do everything from Raspian knowing that wine
> > wasn't an option.
> >
> > Enjoy the weekend,
> > Mark
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> --
> May the Forth be with you ...
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] avra on a raspi zero v1

[Keith A. <ca...@pi...>]

On 9/30/23 03:17, Mark Roth wrote:
> Hello weekend AmForth'ers
>
> So, while waiting to see what will happen with the repo I have continued to
> play with a git version for my own use. I have reworked the makefile and
> made some changes to the repo structure to accommodate for the new avra
> code (which is still only a placeholder until I get that repository in
> properly). I think that the new makefile should make it very easy to get
> started and there is a bit of a long winded readme to explain anything that
> has changed. If anyone wants to take a look and give feedback that would be
> great.
>
> https://github.com/CableGuy67/AmForth

I took a quick look at the makefile and related fines in the 
appl/template directory, which I believe is what you're referring to 
here. I have two minor suggestions:

 1. How about renaming "template.asm" as "app.asm" and making the
    corresponding changes to the makefile? I think this would make a
    workflow of copying the template directory to one named for a new
    application without updating names within the template directory
    very natural. I would feel weird leaving around a file called
    "template.asm" because that doesn't communicate well the purpose of
    the file in the ultimate project. But "app.asm" seems like it could
    usually fit. Having a consistent name like this could also simplify
    documentation.
 2. This is really just a template for an avr8 project, right? Perhaps
    the directory containing this sub-tree should be named
    "avr8-template" instead of "template"? It seems to me that really
    all the directories under "/appl" are currently templates for
    different targets? Is that right?

Note that I haven't tried anything here, these all come from code 
inspection and may be due to misunderstandings on my part.

Cheers!  Keith

Re: [Amforth] avra on a raspi zero v1

[Mark R. <cab...@gm...>]

On Sat, Sep 30, 2023 at 9:46 PM Keith Amidon wrote:

> On 9/30/23 03:17, Mark Roth wrote:
> > Hello weekend AmForth'ers
> >
> > So, while waiting to see what will happen with the repo I have continued
> to
> > play with a git version for my own use. I have reworked the makefile and
> > made some changes to the repo structure to accommodate for the new avra
> > code (which is still only a placeholder until I get that repository in
> > properly). I think that the new makefile should make it very easy to get
> > started and there is a bit of a long winded readme to explain anything
> that
> > has changed. If anyone wants to take a look and give feedback that would
> be
> > great.
> >
> > https://github.com/CableGuy67/AmForth
>
> I took a quick look at the makefile and related fines in the
> appl/template directory, which I believe is what you're referring to
> here. I have two minor suggestions:
>
>  1. How about renaming "template.asm" as "app.asm" and making the
>     corresponding changes to the makefile? I think this would make a
>     workflow of copying the template directory to one named for a new
>     application without updating names within the template directory
>     very natural. I would feel weird leaving around a file called
>     "template.asm" because that doesn't communicate well the purpose of
>     the file in the ultimate project. But "app.asm" seems like it could
>     usually fit. Having a consistent name like this could also simplify
>     documentation.
>

Yeah, that does sound like a good idea. I like the way it implies intent.


>  2. This is really just a template for an avr8 project, right? Perhaps
>     the directory containing this sub-tree should be named
>     "avr8-template" instead of "template"? It seems to me that really
>     all the directories under "/appl" are currently templates for
>     different targets? Is that right?
>
> Note that I haven't tried anything here, these all come from code
> inspection and may be due to misunderstandings on my part.
>
> Cheers!  Keith
>

You're not wrong in that. Since I only use the avr-8 chips I only recently
even looked into those other appl directories. It seems that it just sort
of grew like mushrooms (appl that is) and never had any cohesiveness.
Indicating that it is the appl template for avr8 is a no brainer. I have to
wonder if the makefile at one point in time was supposed to be more
inclusive with the other platforms but just never got there.

Thanks for the suggestions. Different eyes and all.

All the best,
Mark


>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] avra on a raspi zero v1

[Tristan W. <ho...@tj...>]

Hello Mark,

I took a local clone of your repo and the new template built for an uno
without issue. Thank you.

Are you open to a pull request?

Seeing that we are dealing with makefiles, it seemed a good time to
address prebuilt binaries. I have blended/amended your template with
the existing makefile in appl/arduino to output hex files for the m328
based UNO and the 2561 based mega.

Separately, I have written a script to produce a simple html build
specific reference-card that lists the words built into the respective
pre-built hex files. It searches the .lst file produced by the
assembler (in this case avra) for the assembler source files used and
then searches them for the documentation. This has been discussed [1]
on the mailing list before. However, if there are going to be prebuilt
hex files in the repo, then a reference-card for those builds will be
helpful for the person trying them out. It is not intended to be a
substitute for the reference-card for AmForth as a whole. 

I have put up the html here as an idea.

https://www.mostlymostly.uk/amforthdocs/prebuilt.html

The page uses material from the existing site. It is not plumbed
into the rst source (but it could be).

Best wishes,
Tristan

[1] https://sourceforge.net/p/amforth/mailman/message/37112236/

On 30Sep23 22:30, Mark Roth wrote:
> On Sat, Sep 30, 2023 at 9:46 PM Keith Amidon wrote:
> 
> > On 9/30/23 03:17, Mark Roth wrote:
> > > Hello weekend AmForth'ers
> > >
> > > So, while waiting to see what will happen with the repo I have continued
> > to
> > > play with a git version for my own use. I have reworked the makefile and
> > > made some changes to the repo structure to accommodate for the new avra
> > > code (which is still only a placeholder until I get that repository in
> > > properly). I think that the new makefile should make it very easy to get
> > > started and there is a bit of a long winded readme to explain anything
> > that
> > > has changed. If anyone wants to take a look and give feedback that would
> > be
> > > great.
> > >
> > > https://github.com/CableGuy67/AmForth
> >
> > I took a quick look at the makefile and related fines in the
> > appl/template directory, which I believe is what you're referring to
> > here. I have two minor suggestions:
> >
> >  1. How about renaming "template.asm" as "app.asm" and making the
> >     corresponding changes to the makefile? I think this would make a
> >     workflow of copying the template directory to one named for a new
> >     application without updating names within the template directory
> >     very natural. I would feel weird leaving around a file called
> >     "template.asm" because that doesn't communicate well the purpose of
> >     the file in the ultimate project. But "app.asm" seems like it could
> >     usually fit. Having a consistent name like this could also simplify
> >     documentation.
> >
> 
> Yeah, that does sound like a good idea. I like the way it implies intent.
> 
> 
> >  2. This is really just a template for an avr8 project, right? Perhaps
> >     the directory containing this sub-tree should be named
> >     "avr8-template" instead of "template"? It seems to me that really
> >     all the directories under "/appl" are currently templates for
> >     different targets? Is that right?
> >
> > Note that I haven't tried anything here, these all come from code
> > inspection and may be due to misunderstandings on my part.
> >
> > Cheers!  Keith
> >
> 
> You're not wrong in that. Since I only use the avr-8 chips I only recently
> even looked into those other appl directories. It seems that it just sort
> of grew like mushrooms (appl that is) and never had any cohesiveness.
> Indicating that it is the appl template for avr8 is a no brainer. I have to
> wonder if the makefile at one point in time was supposed to be more
> inclusive with the other platforms but just never got there.
> 
> Thanks for the suggestions. Different eyes and all.
> 
> All the best,
> Mark
> 
> 
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] avra on a raspi zero v1

[Mark R. <cab...@gm...>]

On Wed, Oct 4, 2023 at 2:37 PM Tristan Williams wrote:

> Hello Mark,
>
> I took a local clone of your repo and the new template built for an uno
> without issue. Thank you.
>
> Are you open to a pull request?
>

Of course. I do believe that last night I fixed the last of the little bits
that were giving me trouble after trying to take care of the zero byte
padding issues. For some odd reason one of them played havoc with Evalue in
so that it just didn't work. It was in the word list, but was just hanging.
That is fine now as far as I can tell. I tested quite a bit with my word
list that is pretty extensive.


>
> Seeing that we are dealing with makefiles, it seemed a good time to
> address prebuilt binaries. I have blended/amended your template with
> the existing makefile in appl/arduino to output hex files for the m328
> based UNO and the 2561 based mega.


I agree. Any of the projects in appl should be able to be built and/or have
a prebuilt hex in them. Since today was the first day I was able to stop
looking at the repo and look at my own project to clean up the next thing I
did want to do is to cull and clean those. I have an uno or three and a
mega from an old disassembled  3D printer around here so I can try those
next. I also have a few other atmegas to work with from various interests
over the years. I need to look and see if any of them (atmega8, 16 etc) are
even able to take AmForth. So yes, any info put up at the repo will most
certainly be seen and considered by me for now unless something else
happens to move that focus.


> Separately, I have written a script to produce a simple html build
> specific reference-card that lists the words built into the respective
> pre-built hex files. It searches the .lst file produced by the
> assembler (in this case avra) for the assembler source files used and
> then searches them for the documentation. This has been discussed [1]
> on the mailing list before. However, if there are going to be prebuilt
> hex files in the repo, then a reference-card for those builds will be
> helpful for the person trying them out. It is not intended to be a
> substitute for the reference-card for AmForth as a whole.
>
> I have put up the html here as an idea.
>
> https://www.mostlymostly.uk/amforthdocs/prebuilt.html
>
> The page uses material from the existing site. It is not plumbed
> into the rst source (but it could be).


This looks great. A few times after you put up the link I accidentally
ended up there and wondered why the SF site was so snappy. I see you have
kept up with the refcard thing over the years from when we played around
with it. It's done with python I'm guessing. I really like your idea of
making them from the .lst files. It's something I've always thought would
be a great addition inside of the project directories if someone so
desired.


> Best wishes,
> Tristan
>
> [1] https://sourceforge.net/p/amforth/mailman/message/37112236/


All the best to you as well. It feels good to be polishing up the tools to
polish up the Forth that was starting to bit rot in my brain.
Mark


>
>
> On 30Sep23 22:30, Mark Roth wrote:
> > On Sat, Sep 30, 2023 at 9:46 PM Keith Amidon wrote:
> >
> > > On 9/30/23 03:17, Mark Roth wrote:
> > > > Hello weekend AmForth'ers
> > > >
> > > > So, while waiting to see what will happen with the repo I have
> continued
> > > to
> > > > play with a git version for my own use. I have reworked the makefile
> and
> > > > made some changes to the repo structure to accommodate for the new
> avra
> > > > code (which is still only a placeholder until I get that repository
> in
> > > > properly). I think that the new makefile should make it very easy to
> get
> > > > started and there is a bit of a long winded readme to explain
> anything
> > > that
> > > > has changed. If anyone wants to take a look and give feedback that
> would
> > > be
> > > > great.
> > > >
> > > > https://github.com/CableGuy67/AmForth
> > >
> > > I took a quick look at the makefile and related fines in the
> > > appl/template directory, which I believe is what you're referring to
> > > here. I have two minor suggestions:
> > >
> > >  1. How about renaming "template.asm" as "app.asm" and making the
> > >     corresponding changes to the makefile? I think this would make a
> > >     workflow of copying the template directory to one named for a new
> > >     application without updating names within the template directory
> > >     very natural. I would feel weird leaving around a file called
> > >     "template.asm" because that doesn't communicate well the purpose of
> > >     the file in the ultimate project. But "app.asm" seems like it could
> > >     usually fit. Having a consistent name like this could also simplify
> > >     documentation.
> > >
> >
> > Yeah, that does sound like a good idea. I like the way it implies intent.
> >
> >
> > >  2. This is really just a template for an avr8 project, right? Perhaps
> > >     the directory containing this sub-tree should be named
> > >     "avr8-template" instead of "template"? It seems to me that really
> > >     all the directories under "/appl" are currently templates for
> > >     different targets? Is that right?
> > >
> > > Note that I haven't tried anything here, these all come from code
> > > inspection and may be due to misunderstandings on my part.
> > >
> > > Cheers!  Keith
> > >
> >
> > You're not wrong in that. Since I only use the avr-8 chips I only
> recently
> > even looked into those other appl directories. It seems that it just sort
> > of grew like mushrooms (appl that is) and never had any cohesiveness.
> > Indicating that it is the appl template for avr8 is a no brainer. I have
> to
> > wonder if the makefile at one point in time was supposed to be more
> > inclusive with the other platforms but just never got there.
> >
> > Thanks for the suggestions. Different eyes and all.
> >
> > All the best,
> > Mark
> >
> >
> > >
> > > _______________________________________________
> > > Amforth-devel mailing list for http://amforth.sf.net/
> > > Amf...@li...
> > > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > >
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth] AmForth RISC-V

[Tristan W. <ho...@tj...>]

Hi,

I managed to get AmForth RISC-V running on a SparkFun RED-V Thing Plus [1]
which is based on the same/similar SiFive RISC-V FE310 SoC as on the now
discontinued HiFive1 board [2]   

amforth 7.0 RV32IM RED-V Thing Plus
 Wed Oct 11 21:25:54 BST 2023 
> words
forth-wordlist environment riscv-wordlist @cycle dump .8hex .4hex
.2hex ?ascii type0 hifive-turnkey rev-info build-info mtimecmp mtime
black magenta cyan yellow white blue green red led-init cacheflush
inflash? c!i !i serial-emit? serial-emit serial-key? serial-key
serial-lastchar +usart ram-wordlist wordlist Udefer! Udefer@ dp >in 0>
get-current >body wlscope variable to ; : ] reveal recurse ?abort
postpone +loop newest loop latest header endloop do (create) defer!
defer@ create constant :noname char ['] [compile] [char] \ abort"
abort ' turnkey immediate leave >l l> lp lp0 repeat again else if
while until then begin ahead words sliteral s, ." s" itype type count
ver init-ram ?do map-stack interpret recognize cfg-recognizer
forth-recognizer split rectype-split rec-split rec-num rectype-dnum
rectype-num rectype-xt rec-find rectype-null set-base bases number
>number digit? toupper within ud* m+ name>flags name>string
search-wordlist current show-wordlist traverse-wordlist nfa2cfa
nfa>lfa find-xt cfg-order c, , compile literal 2literal /string parse
parse-name cskip cscan ?stack source-tib source throw catch handler
.ready .ok .input .error ?crlf bs accept refill-tib refill .s ud.r
ud. u. d. d.r . sign #> #s # <# hold hld allot here pad hex decimal (
[ spaces space bl cr ms warm false true -1 4 2 1 0 nr> n>r compare 1ms
up! up@ aligned j i unloop bounds nop pause emit? emit key? key
execute quit cold #tib tib state cells cell+ 2/ 2* 2- 2+ 1- 1+ - +
base d0= d0< ud/mod um/mod s>d 2dup d- d+ dnegate dabs d2/ d2* 2r> 2>r
2r@ 2over 2drop 2nip 2swap umax umin max min = <> u> u< u<= u>= > < <=
>= 0< 0<> 0= c! c@ +! fill move lshift rshift invert not xor or and
rdrop rdepth depth /mod u/mod mod / m* um* * abs negate ! @ sp0 sp sp!
sp@ rp rp! rp@ r@ r> >r pick -rot tuck ?dup rot over nip dup swap drop
exit ok >

I needed to make a few changes to the existing code to get it to
run. Flashing AmForth to the SparkFun RED-V Thing Plus is simple, as
when plugged in it presents itself as a drive. Copy the hex file to
the drive and it flashes itself.

On reset a bootloader runs the copied and flashed AmForth hex file,
but it sends some AT commands over the usart prior to running the
flashed program. It may do other things too. A search suggests this
might be related to a WiFi/BT chip on the HiFive1 Rev B. [3] Remaking
AmForth for a 115200 uart shows this nicely.

ATE0--> Send Flag error: #0 #0 #0 #0 AT+BLEINIT=0--> Send Flag error: #255 #255 #255 #255 AT+CWMODE=0--> Send Flag error: #255 #248 #0 #0 
amforth 7.0 RV32IM RED-V Thing Plus
 Thu Oct 12 21:48:35 BST 2023 
> 

I know next to nothing about risc-v assembly, but Matthias' code/macros look
super elegant to me.   

COLON "hifive-turnkey", APPLTURNKEY

  .word XT_LED_INIT
  .word XT_DECIMAL
  .word XT_INIT_USART

  .word XT_DOT_VER, XT_SPACE
  .word XT_ENV_BOARD,XT_TYPE, XT_CR

  .word XT_BUILD_INFO,XT_TYPE
  .word XT_SPACE, XT_REV_INFO, XT_TYPE

.word XT_EXIT

The SparkFun RED-V Thing Plus has a different LED arrangement and
location but it was easy enough to cobble together some assembler
words to make a proof of blinky. 

CODEWORD  "led-init", LED_INIT
  li x20, 1 << 5 
  li x21, GPIO_OUTPUT_EN
  sw x20, 0(x21)
  li x20, 1 << 5 
  li x21, GPIO_PORT
  sw x20, 0(x21)
NEXT

CODEWORD  "+led", PLUSLED
    li x20, 1 << 5 
    li x21, GPIO_PORT
    sw x20, 0(x21)
NEXT

CODEWORD  "-led", MINUSLED
    li x20, 1 << 5 
    li x21, GPIO_PORT
    sw zero, 0(x21)
NEXT

I'm glad I started with the SparkFun RED-V Thing Plus board. Whilst
it's more expensive than some other offerings, having something close to
the board AmForth RISC-V was originally written for, definitely helps a
lot. RISC-V is not an "open-source processor" [4] and I'm not able to
cope with the variety yet, if ever.

Despite the product page "backorder" status, there are quite a few of
the SparkFun RED-V Thing Plus still available from the usual sources.

Well a lot of fun, plenty to study for the winter, and with a blinky
up-and-running there is always the hope of progress.

Best wishes,
Tristan


[1] https://www.sparkfun.com/products/15799
[2] https://www.sifive.com/boards/hifive1
[3] https://www.sifive.com/boards/hifive1-rev-b
[4] https://riscv.org/blog/2020/02/risc-v-is-not-an-open-source-processor-krste-asanovic-chairman-of-the-board-risc-v/