[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #200 from Jock Tanner <tanner.of.kha@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #197)
>
> yesyes i know i said "no extra software" then suggested installing pyro.  if
> i'm installing vim and editing inside the chroot, you can sneak pyro in :)

Well, if “no extra software” is the main concern, then I guess my initial idea
of installing Pycharm locally in chroot will do just fine. It's completely
self-contained and requires no modification to the system, with the exception
of:

- setup folder (can be installed in home folder, no root required),
- global settings folder (also in home folder),
- project settings folder (can be put in '.git/info/exclude' or '.gitignore',
which I usually do).

Delete that 3 objects, and you'll never remember that you used it.

Actually, I've tried it already, and all went well with one exception: I can't
get binary extensions indexed. Yes, I'd like to walk through Hurricane
attributes in editor. =) I think it's worth a little investigation.

(In reply to Luke Kenneth Casson Leighton from comment #198)
> absolutely and critically dependent on the website - pypi.org - for its
> security.  do you GPG sign packages before uploading them? what happens if
> pypi - the website - is hacked?

Yes, it depends on pypi.org to store and transfer packages. And on SSL chain of
trust to know if pypi.org is authentic. If pypi.org or chain of trust are
hacked, we're all hacked.

On the other hand, the processing of signatures is significantly increasing an
attack surface by inclusion of the corresponding tools in the process, on both
client and server sides. And, if a process is more complex, people are tend to
make more mistakes.

The model of trust is also important here. Should I trust the owner of a
certain site? The issuer of a certain PGP signature? The ISP?

Thankfully, all components, involved in the process: twine, cheeseshop, pip and
setuptools − are quite versatile, and the process can be easily tailored to
your model of trust. You can use the VCS of your choice on a trusted host to
store packages, or set up your own PyPI.

You can also place your signature somewhere in your PyPI package, and then
modify setuptools to verify the signature along with the package hash before
running setup.py. I think it should be fairly easy to implement.

> a solution is to *pre-install* debian python dependency packages *before*
> running "python setup.py develop".  this *stops* pip going out and
> arbitrarily and blithely downloading random crap that's completely unsigned
> and you have absolutely no idea if it's been vetted.

Package pinning in pip is out there since I don't remember when. I think there
were some difficulties in pinning pip itself, but I suppose they are gone now.
pip should be ready for reproducible builds.

The problem of malicious packages in PyPI can be also mitigated by package
pinning, although this is more a social problem, than a technical one.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #201 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Jock Tanner from comment #200)

> Well, if “no extra software” is the main concern, then I guess my initial
> idea of installing Pycharm locally in chroot will do just fine. It's
> completely self-contained and requires no modification to the system, with
> the exception of:
> 
> - setup folder (can be installed in home folder, no root required),
> - global settings folder (also in home folder),
> - project settings folder (can be put in '.git/info/exclude' or
> '.gitignore', which I usually do).
> 
> Delete that 3 objects, and you'll never remember that you used it.
> 
> Actually, I've tried it already, and all went well 

excellent

> with one exception: I can't get binary extensions indexed. 

this does not surprise me at all.  and you won't find anything anyway:
there are zero docstrings 

> Yes, I'd like to walk through Hurricane
> attributes in editor. =) I think it's worth a little investigation.

you will likely need the coriolisEnv.py settings. i believe pycharm
actually *executes* the module (imports it, which can have side-effects).

clearly, to execute the Hurricane.so that involves being able to load
the dynamic libraries it's linked to.

that in turn involves having coriolisEnv.py environment variables set up

it also implies having access to the entire coriolis binaries and libraries.

anyway - focus.

let me know how you get on with the analogy of creating something similar to
ioring.py, to create "Pads" that you can see in the experiments5 and alu_hier
nmigen benchs.  you might even be able to use the code *from* coriolis2 that
imports ioring.py as a base.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #202 from Jock Tanner <tanner.of.kha@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #201)
> this does not surprise me at all.  and you won't find anything anyway:
> there are zero docstrings 
> 

Well, actually 'help(Hurricane)' gives a lot of info, that Pycharm should use
for syntax check, code completion, et c. I wonder why it has failed this time.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #203 from Jock Tanner <tanner.of.kha@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #201)
> let me know how you get on with the analogy of creating something similar to
> ioring.py, to create "Pads" that you can see in the experiments5 and
> alu_hier nmigen benchs.  you might even be able to use the code *from*
> coriolis2 that imports ioring.py as a base.

Can the solution looks like this:

> ('experiment5/alu_heir.py')
>
> def create_pads(top_element, pins, file_name):
>     for pin in pins:
>         # some introspective magic
>         # as well as a bunch of guessing
>         pass
> 
>     with open(file_name, "w") as ioring:
>         # a bit of templating magic with jinja2
>
>
>         ...
>
>
> if __name__ == "__main__":
>     alu = ALU(width=16)
>     pins = [alu.op, alu.a, alu.b, alu.o]
>     create_pads(alu, pins, "coriolis2/ioring.py")
>     create_ilang(alu, pins, "alu_hier")
>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #204 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Jock Tanner from comment #203)

> Can the solution looks like this:
> 
> > ('experiment5/alu_heir.py')
> >
> > def create_pads(top_element, pins, file_name):
> >     for pin in pins:
> >         # some introspective magic
> >         # as well as a bunch of guessing
> >         pass
> > 
> >     with open(file_name, "w") as ioring:
> >         # a bit of templating magic with jinja2

ermmm ermermerm i like the idea of keeping things in an external file

*thinks*... actually, CSV format would be better, because it's 3 lines of code:

    import csv # standard python library
    with open(file_path, 'r') as csvfile:
        return list(csv.DictReader(csvfile))

remember, we need to minimise the dependencies (see HDL_workflow, and see
discussion we just had!)

in CSV format, it could be:

SIDE,pinname,offset,comment
NORTH,clk,,,

the defaults would be, if there is no offset, to make one.  the order of
the pins in the CSV file would define the order in which they appear on
that side.

i think that would work really well.  later we can consider actually embedding
the CSV file contents *into* the docstring (or a function) of the actual nmigen
source code.

or something.

if it turns out to be more sophisticated than that, we can revisit this (or use
an alternative format).

basic guiding principle: keep it *real* simple.  i won't go into full detail of
the nightmare story of someone doing a less-functional "Model-View-Controller"
replacement of 800 lines of python i did, once.  he wrote 16 *THOUSAND* lines
of code - in 5 weeks.  for a simple "real-time CPU usage" web app.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #205 from Jock Tanner <tanner.of.kha@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #204)
> ermmm ermermerm i like the idea of keeping things in an external file
> 
> *thinks*... actually, CSV format would be better, because it's 3 lines of
> code:
> 
>     import csv # standard python library
>     with open(file_path, 'r') as csvfile:
>         return list(csv.DictReader(csvfile))
> 
> remember, we need to minimise the dependencies (see HDL_workflow, and see
> discussion we just had!)
> 
> in CSV format, it could be:
> 
> SIDE,pinname,offset,comment
> NORTH,clk,,,
> 
> the defaults would be, if there is no offset, to make one.  the order of
> the pins in the CSV file would define the order in which they appear on
> that side.
> 
> i think that would work really well.  later we can consider actually
> embedding
> the CSV file contents *into* the docstring (or a function) of the actual
> nmigen source code.

Looks like I implied too much.

First of all, I thought of keeping all the ioring logic intact as of a
requirement, or at least as a generally good approach. That's why I didn't
consider adding, say, CSV support into 'coriolis2.ioring' or
'Configuration.loadConfiguration()'.

Second, I don't think that introducing an additional file with a special format
would do us any good. I suppose that 'coriolis2.ioring' is ok as it is for
passing pad configuration between stages. If I am just not aware of the issues
with it, please point me in a right direction.

What I did thought is necessary, is to eliminate the need for the user to
configure the pads at all, or at least to configure them separately from
top-level logic. I thought we can just set up formal rules (like putting pins
with names ending on '_i' to the left, '_o' − to the right), and implement the
reusable 'create_pads()' to inspect the list of pins according to these rules
and generate 'coriolis2.ioring'.

Of course, I'm not yet proficient enough in the current workflow to see all the
right implications. So I have to ask of you to specify my task.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #206 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Jock Tanner from comment #205)
> (In reply to Luke Kenneth Casson Leighton from comment #204)
> > ermmm ermermerm i like the idea of keeping things in an external file
> > 
> > *thinks*... actually, CSV format would be better, because it's 3 lines of
> > code:
> > 
> >     import csv # standard python library
> >     with open(file_path, 'r') as csvfile:
> >         return list(csv.DictReader(csvfile))
> > 
> > remember, we need to minimise the dependencies (see HDL_workflow, and see
> > discussion we just had!)
> > 
> > in CSV format, it could be:
> > 
> > SIDE,pinname,offset,comment
> > NORTH,clk,,,
> > 
> > the defaults would be, if there is no offset, to make one.  the order of
> > the pins in the CSV file would define the order in which they appear on
> > that side.
> > 
> > i think that would work really well.  later we can consider actually
> > embedding
> > the CSV file contents *into* the docstring (or a function) of the actual
> > nmigen source code.
> 
> Looks like I implied too much.

(nono, we're discussing ideas, here.  it's just that unlike other projects
which can freely add arbitrary dependencies, we have to be careful and consider
how a particular task may be achieved.  the suggestion of doing something that
jinja would *be* suited to was great).

> First of all, I thought of keeping all the ioring logic intact as of a
> requirement, 

not a hard one.

> or at least as a generally good approach. 

yes.

> That's why I didn't
> consider adding, say, CSV support into 'coriolis2.ioring' or
> 'Configuration.loadConfiguration()'.

no that would be stepping on the toes of the coriolis2 project.

> Second, I don't think that introducing an additional file with a special
> format would do us any good. I suppose that 'coriolis2.ioring' is ok as it
> is for passing pad configuration between stages. If I am just not aware of
> the issues with it, please point me in a right direction.

the issue with ioring.py "as-is", is that the procedure for laying out the pads
is entirely automatic, spaced-out evenly, because it's designed *exclusively*
for doing Quad Flat Packages (QFPs).

what it can't do is something like this:

https://cdn.sparkfun.com/r/600-600/assets/7/a/6/9/c/51c0d009ce395feb33000000.jpg

that's an *uneven* distribution of the pads.

now, if ioring.py was capable of allowing us to specify that "signals a[0..15]
are to be on the LEFT part of the NORTH side", then yes i would say it was
perfect.

this is why i suggested being able to specify the precise location.


> What I did thought is necessary, is to eliminate the need for the user to
> configure the pads at all, or at least to configure them separately from
> top-level logic. I thought we can just set up formal rules (like putting
> pins with names ending on '_i' to the left, '_o' − to the right), and
> implement the reusable 'create_pads()' to inspect the list of pins according
> to these rules and generate 'coriolis2.ioring'.

hmmm.... that may actually be useful in some cases.  i think... i think we need
a class of some kind, with the ability to derive from it and create alternative
layouts.

> Of course, I'm not yet proficient enough in the current workflow to see all
> the right implications. So I have to ask of you to specify my task.

ok, let's discuss this on another bugreport.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #208 from Jean-Paul.Chaput@lip6.fr ---
(In reply to Jean-Paul.Chaput from comment #207)
> Created attachment 35 [details]
> Coriolis2 ioring.py with explicit pad positioning

> > Second, I don't think that introducing an additional file with a special
> > format would do us any good. I suppose that 'coriolis2.ioring' is ok as it
> > is for passing pad configuration between stages. If I am just not aware of
> > the issues with it, please point me in a right direction.
> 
> the issue with ioring.py "as-is", is that the procedure for laying out the
> pads is entirely automatic, spaced-out evenly, because it's designed
> *exclusively* for doing Quad Flat Packages (QFPs).
> 
> what it can't do is something like this:
> 
> https://cdn.sparkfun.com/r/600-600/assets/7/a/6/9/c/51c0d009ce395feb33000000.
> jpg
> 
> that's an *uneven* distribution of the pads.

  Wrong! ;-) You can specify the exact position of each pad with the ioring.py
  file. I did put an example in attachement #35. It is not part of the toolkit
  as the related example is the adder with AMS 350nm (under NDA).

  I did not completely follow the thead about CSV file, but in my experience,
  I don't see the need of introducing a new file format (even if its simple
  CSV), directly write in Python instead.

> > What I did thought is necessary, is to eliminate the need for the user to
> > configure the pads at all, or at least to configure them separately from
> > top-level logic. I thought we can just set up formal rules (like putting
> > pins with names ending on '_i' to the left, '_o' − to the right), and
> > implement the reusable 'create_pads()' to inspect the list of pins according
> > to these rules and generate 'coriolis2.ioring'.
> 
> hmmm.... that may actually be useful in some cases.  i think... i think we
> need a class of some kind, with the ability to derive from it and create
> alternative layouts.

  In my experience again, there is too many different cases so that an
automated
  way works for for enough of them. And I'm very reluctant to put semantic in
  the pad names, it may clash with the HDL in too many ways.

   Lastly, if I'm not mistaken, you want to put information about the pads at
   nMigen level. I think it should be avoided. nMigen is for the design
   (behavioral or high leval description), and information pertaining to
   the layout should be kept at Coriolis level.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

Luke Kenneth Casson Leighton <lkcl@lkcl.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|IN_PROGRESS                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #209 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
i'm going to close this one as resolved as far as the tutorial part is
concerned (and we'll work out who gets what), however if it's useful to do so,
carry on discussing :)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[Cole Poirier]

> On Mar 12, 2020, at 10:26 AM, bugzilla-daemon@libre-riscv.org wrote:
> 
> http://bugs.libre-riscv.org/show_bug.cgi?id=178
> 
> --- Comment #210 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
> for this one, i'm going to suggest:
> 
> * EUR 250 to jock for the (crucial) questions and for helping get to buster 
> * EUR 200 to tobias for the early checking of the tutorial
> * EUR 700 to be donated to LIP6.fr for the huge amount of bugfixing by JP
> * EUR 150 to Staf for his insights
> * EUR 1200 to me for the persistent head-banging against brick walls
> 
> Cole, as long as you are in Europe, you helped find some early bugs in the
> tutorial page, and made some useful edits, however if you are outside of
> Europe, most of what NLNet would transfer to you would go in banking fees.  we
> can if you like work something out.

Thank you for the consideration Luke, even though I have yet to add my discoveries to the wiki. I reside in Vancouver, Canada so a donation to me would be a waste of the funding we have, in addition I really don’t want to be paid for anything unless it is a substantial contribution to the core of the project (i.e. something that will end up in silicon). Apologies for my lack of communication, I recently started my first career-level job and I’m still in the process acclimating to my new circumstances. That being said, I was able to progress further with the coriolis2 tutorial last weekend, and I plan on trying to repeat this and document it tomorrow. I will edit the wiki with my successful installation steps, and reply here when I inevitably get stuck. Additionally, I plan on setting up and configuring Jacob’s gitlab dev server this weekend. I will leave a reply on the relevant thread.

Best,
Cole
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #211 from Tobias Platen <hacks2019@platen-software.de> ---
200 for me looks good

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #212 from Jock Tanner <tanner.of.kha@gmail.com> ---
I don't know if I'm expected to react somehow, but for me it's fine. I only
think if anyone could enlighten me about the due procedures.

(In reply to Luke Kenneth Casson Leighton from comment #210)
> for this one, i'm going to suggest:
> 
> * EUR 250 to jock for the (crucial) questions and for helping get to buster 
> * EUR 200 to tobias for the early checking of the tutorial
> * EUR 700 to be donated to LIP6.fr for the huge amount of bugfixing by JP
> * EUR 150 to Staf for his insights
> * EUR 1200 to me for the persistent head-banging against brick walls
> 
> Cole, as long as you are in Europe, you helped find some early bugs in the
> tutorial page, and made some useful edits, however if you are outside of
> Europe, most of what NLNet would transfer to you would go in banking fees. 
> we can if you like work something out.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #213 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Jock Tanner from comment #212)
> I don't know if I'm expected to react somehow, but for me it's fine. I only
> think if anyone could enlighten me about the due procedures.

ok see https://libre-riscv.org/about_us/ create yourself a user-page
on the wiki (template one of the existing ones, use mine as i have
more "headings"), then put EUR amount in a "pending" section, with
the heading "NLNet 2019 Coriolis2 Layout proposal 2019-10-029" and
put the date on that as well.

the RFP will go in to NLNet once i hear back from them.  are you in
Europe?  if so it's ok to put in small(ish) amounts.

(In reply to Tobias Platen from comment #211)
> 200 for me looks good

great, can you do the same as jock?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #214 from Jock Tanner <tanner.of.kha@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #213)
> ok see https://libre-riscv.org/about_us/ create yourself a user-page
> on the wiki (template one of the existing ones, use mine as i have
> more "headings"), then put EUR amount in a "pending" section, with
> the heading "NLNet 2019 Coriolis2 Layout proposal 2019-10-029" and
> put the date on that as well.

Done.

> the RFP will go in to NLNet once i hear back from them.  are you in
> Europe?  if so it's ok to put in small(ish) amounts.

I live in Russia. I have an account in a local bank. I can receive
international bank transfers. I understand that nonprofit organization can not
pay bank charges for me. But exactly how terrible those charges are?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #215 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Jock Tanner from comment #214)
> (In reply to Luke Kenneth Casson Leighton from comment #213)
> > ok see https://libre-riscv.org/about_us/ create yourself a user-page
> > on the wiki (template one of the existing ones, use mine as i have
> > more "headings"), then put EUR amount in a "pending" section, with
> > the heading "NLNet 2019 Coriolis2 Layout proposal 2019-10-029" and
> > put the date on that as well.
> 
> Done.
>  
> > the RFP will go in to NLNet once i hear back from them.  are you in
> > Europe?  if so it's ok to put in small(ish) amounts.
> 
> I live in Russia. I have an account in a local bank. I can receive
> international bank transfers. I understand that nonprofit organization can
> not pay bank charges for me. But exactly how terrible those charges are?

we should probably wait until you accumulate arouuund... EUR 1500 minimum,
then.  NLnet are asking if they would like to support us, or if they woykd like
to support the banks.

:)

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[Cole Poirier]

On Apr 21 2020, at 2:30 pm, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> so, cole - open a new bugreport and we can discuss it there ok?
> 
> each new "thing" needs its own bugreport.
> 
> i began discussing the coriolis2 chroot with you because you used the
> coriolis2 tutorial bugreport.
> 
> that is - was - its context.
> 
> you see why it is important to keep to separate bugs?
> 
> l.
> 

Ah my mistake, I didn't realize this bug report was closed, and
mistakenly thought that this was the appropriate place to discuss it.
Thank you for the clarification. I will make a new bug report now.

Cole

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

Re: [libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[Luke Kenneth Casson Leighton]

so, cole - open a new bugreport and we can discuss it there ok?

each new "thing" needs its own bugreport.

i began discussing the coriolis2 chroot with you because you used the
coriolis2 tutorial bugreport.

that is - was - its context.

you see why it is important to keep to separate bugs?

l.

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

On Tue, Apr 21, 2020 at 10:29 PM <bugzilla-daemon@libre-soc.org> wrote:
>
> https://bugs.libre-soc.org/show_bug.cgi?id=178
>
> --- Comment #219 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
> (In reply to Cole Poirier from comment #218)
> > (In reply to Luke Kenneth Casson Leighton from comment #217)
> > > (In reply to Cole Poirier from comment #216)
> > > > Luke, do you want gcc-9-powerpc64-linux-gnu installed inside of the chroot?
> > >
> > > for coriolis2? we have no reason to compile executables (yet).
> >
> > I've left out your comments regarding compiling for a moving target for
> > brevity, but I definitely take your point. The reason I ask is that I'm
> > following the HDL workflow,
>
> ok.  then this bugreport, which is not for HDL_workflow, it is for coriolis2,
> is not the right place.
>
> plus, this bugreport (related to coriolis2) has been closed.
>
> > and there is a section instructing the user to
> > install gcc-9-powerpc.
> >
> > ```
> > Section 6.6 qemu, cross-compilers, gdb
> >
> > As we are doing POWER ISA, POWER ISA compilers, toolchains and emulators are
> > required.
> >
> > Install powerpc64 gcc:
> >
> > apt-get install gcc-9-powerpc64-linux-gnu
>
> that's only available in debian/testing.
>
> gcc-8-powerpc64-linux-gnu is what is available in debian/10.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev@lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=178

--- Comment #219 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #218)
> (In reply to Luke Kenneth Casson Leighton from comment #217)
> > (In reply to Cole Poirier from comment #216)
> > > Luke, do you want gcc-9-powerpc64-linux-gnu installed inside of the chroot?
> > 
> > for coriolis2? we have no reason to compile executables (yet).
> 
> I've left out your comments regarding compiling for a moving target for
> brevity, but I definitely take your point. The reason I ask is that I'm
> following the HDL workflow, 

ok.  then this bugreport, which is not for HDL_workflow, it is for coriolis2,
is not the right place.

plus, this bugreport (related to coriolis2) has been closed.

> and there is a section instructing the user to
> install gcc-9-powerpc.
> 
> ```
> Section 6.6 qemu, cross-compilers, gdb
> 
> As we are doing POWER ISA, POWER ISA compilers, toolchains and emulators are
> required.
> 
> Install powerpc64 gcc:
> 
> apt-get install gcc-9-powerpc64-linux-gnu

that's only available in debian/testing.

gcc-8-powerpc64-linux-gnu is what is available in debian/10.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=178

--- Comment #218 from Cole Poirier <colepoirier@gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #217)
> (In reply to Cole Poirier from comment #216)
> > Luke, do you want gcc-9-powerpc64-linux-gnu installed inside of the chroot?
> 
> for coriolis2? we have no reason to compile executables (yet).

I've left out your comments regarding compiling for a moving target for
brevity, but I definitely take your point. The reason I ask is that I'm
following the HDL workflow, and there is a section instructing the user to
install gcc-9-powerpc.

```
Section 6.6 qemu, cross-compilers, gdb

As we are doing POWER ISA, POWER ISA compilers, toolchains and emulators are
required.

Install powerpc64 gcc:

apt-get install gcc-9-powerpc64-linux-gnu

Install qemu:

apt-get install qemu-system-ppc

Install gdb from source. Obtain the latest tarball, unpack it, then:

cd gdb-9.1 (or other location)
mkdir build
cd build
 ../configure --srcdir=.. --host=x86_64-linux --target=powerpc64-linux-gnu
make -j16
make install
```

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=178

--- Comment #217 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
(In reply to Cole Poirier from comment #216)
> Luke, do you want gcc-9-powerpc64-linux-gnu installed inside of the chroot?

for coriolis2? we have no reason to compile executables (yet).

> The reason I ask is because it involves changing /etc/apt/sources.list from
> buster to testing or unstable in order to install via apt, 

yeah that's not a good idea.  the coriolis2 chroot absolutely has to be
a reproducible build.  debian/testing is the absolute opposite of that.

> something that I presume is trivial in the chroot, 

it's trivial on both, however the results would be absolute disaster.
i do not know if you have ever tried to compile software on a moving
target, it is absolute hell.

if we absolutely have to install gcc for powerpc in the chroot, it would
be better to do so from a full source code build.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

https://bugs.libre-soc.org/show_bug.cgi?id=178

Cole Poirier <colepoirier@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |colepoirier@gmail.com

--- Comment #216 from Cole Poirier <colepoirier@gmail.com> ---
Luke, do you want gcc-9-powerpc64-linux-gnu installed inside of the chroot? The
reason I ask is because it involves changing /etc/apt/sources.list from buster
to testing or unstable in order to install via apt, something that I presume is
trivial in the chroot, but likely not as feasible on the host system. If I am
wrong in any of my assumptions please clarify, I'm still very, very new to
linux.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev

[libre-riscv-dev] [Bug 178] first coriolis2 tutorial, workflow and "test project" page

[bugzilla-daemon]

http://bugs.libre-riscv.org/show_bug.cgi?id=178

--- Comment #210 from Luke Kenneth Casson Leighton <lkcl@lkcl.net> ---
for this one, i'm going to suggest:

* EUR 250 to jock for the (crucial) questions and for helping get to buster 
* EUR 200 to tobias for the early checking of the tutorial
* EUR 700 to be donated to LIP6.fr for the huge amount of bugfixing by JP
* EUR 150 to Staf for his insights
* EUR 1200 to me for the persistent head-banging against brick walls

Cole, as long as you are in Europe, you helped find some early bugs in the
tutorial page, and made some useful edits, however if you are outside of
Europe, most of what NLNet would transfer to you would go in banking fees.  we
can if you like work something out.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
libre-riscv-dev mailing list
libre-riscv-dev@lists.libre-riscv.org
http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev