Ethernet support for lowrisc
by Jawad Haj-Yahya
Hello,
Could you please help with instructions on how to add support for Ethernet
port to the latest lowrisc (0.4)?
Best,
Jawad Haj-Yahya
5 years, 10 months
Debug Taskgroup
by kritik bhimani
Hi Alex/Stefan, I saw that you both are a part of the debug taskgroup. So
could you please let me know regarding any activity on Trace feature. I
wanted to know which features of the debug in previous revisions of lowRISC
should be ported to work with the latest rocket-chip. As features like MAM
and System Control Module I don't think are needed any more. Instead I
think the aim should rather be to extend the existing debug infrastructure
in the latest rocket-chip to use features from open soc debug like glip,
CTM and STM and at the same time be compliant with the debug spec. This
will also help in future to integrate latest rocket-chip into lowRISC.
Secondly can an issue on the GitHub repo be raised stating all the features
that are yet to be ported from the previous revisions like trace debug, tag
cache and related infrastructure.
5 years, 11 months
Re: [lowrisc-dev] SMP support
by Armia Salib
Hi Dr. Jonathan,
Thank you, Dr. Jonathan, for your quick reply.
I am able to instantiate two tiles after disabling the FPU. With those two tiles I am able to run a Linux without SMP support. But it did not boot also with the SMP.
Do you suggest to wait for the next release of LowRISC? When will it be available?
Best regards,
Armia
--------------------------------------------
On Sat, 12/23/17, Dr Jonathan Kimmitt <jrrk2(a)cam.ac.uk> wrote:
Subject: Re: [lowrisc-dev] SMP support
To: "Armia Salib" <armiasalib(a)yahoo.com>
Cc: lowrisc-dev(a)lists.lowrisc.org
Date: Saturday, December 23, 2017, 9:09 PM
It goes without saying you need
at least two cores to get a benefit and there are some
questions over the reliability of tilelink1, hence the move
to tilelink2 in the new Rocket (porting to LowRISC in
progress, does not yet boot Linux. This kind of debugging is
for experienced developers.
Sent from my iPhone
>
On 23 Dec 2017, at 20:03, Armia Salib <armiasalib(a)yahoo.com>
wrote:
>
> Hello
all,
>
> I tried to
enable the SMP feature on Linux by modifying the Linux
configurations to support up to two cores. However, I tried
to run this modified Linux on LowRISC V0.3 without any other
modifications, however, the Linux boot did not boot
successfully. So, my question is, is SMP supported in V0.3?
What are other modifications I may need?
>
> Best regards,
> Armia
>
5 years, 11 months
SMP support
by Armia Salib
Hello all,
I tried to enable the SMP feature on Linux by modifying the Linux configurations to support up to two cores. However, I tried to run this modified Linux on LowRISC V0.3 without any other modifications, however, the Linux boot did not boot successfully. So, my question is, is SMP supported in V0.3? What are other modifications I may need?
Best regards,
Armia
5 years, 11 months
minion core 0.4 boot procedure
by Luke Kenneth Casson Leighton
http://www.lowrisc.org/docs/minion-v0.4/overview/
i notice in that documentation that there is significant difficulty
experienced in getting the core booted up. a limit of 60k ROM is
mentioned, 5mhz card speeds set as a hard-coded limit, older cards not
supported and so on.
in commercial SoCs all these problems are solved with a multi-stage
boot process. they only require a 16k executable to be loaded off of
either NAND, eMMC, SPI or MicroSD (the loader itself being executed
from a boot ROM, which itself can be incredibly small), where the
first task of that program is: to initialise DDR3 RAM, PLLs and to
begin executing a *larger* (2nd stage) boot process.
the sub-16k boot process usually loads u-boot directly into the *DDR3*
ram then executes that. usually the sub-16k boot process is actually
a cut-down version *of* u-boot, called an "SPL loader".
all of this is extremely well-known, particularly to the developers of
u-boot who often have to merge proprietary SPL-loaders or write ones
for various SoCs where the proprietary SoC companies couldn't be
bothered to respect software licenses... such as the GPL.
which brings me to the strange conflict going on in my mind: what have
i missed? is the minion 0.4 boot process sufficiently different from
a standard commercial SoC (the A20's eGON bootloader is only 32k in
size and it *still* does NAND *and* SPI *and* MicroSD *and* eMMC
booting http://linux-sunxi.org/BROM - that's 60% the size of the ROM
mentioned at the page above), such that it's not possible to deploy
the same technique... or was it an oversight on the part of the team
that they were unaware of this tried-and-tested technique?
what am i missing?
tia,
l.
5 years, 11 months
Multicore support
by Armia Salib
Hello,
I want to configure LowRISC to have two tiles, I am using V0.3. So I disabled the FPU to save area, and modify the tool chain accordingly. Then I increased NTILES to 2. I am able to download the design into the FPGA, but when I use "opensocdebugd", the program stuck after printing the following lines:
Open SoC Debug Daemon
Backend: uart
Did I miss something?
Best regards,
Armia
5 years, 11 months
Running JAVA on lowrisc
by Jawad Haj-Yahya
Hello,
We would like to run Java bytecode on the latest lowrisc (0.4) on linux
on nexys4 ddr FPGA , is there any instructions how to do that?
Best,
Jawad Haj-Yahya
5 years, 11 months
Changes in SD card controller
by Olof Kindgren
Hi,
I'm currently working on adding FuseSoC support for LowRISC. So far I have
managed to build a bitstream, but not test it. Need a bit of clean up, add
simulation support and more, but generally it looks good. As a part of this
process, I'm looking for fixes in code that has been brought in from other
projects and should be sent upstream.
I have so far gone through the changes for the ps2 code, sent one trivial
fix upstream and kept some other patches as LowRISC-specific for now.
When it comes the the SD card controller however, there are significant
changes, and I can't find much in the history. Already when it was checked
into the minion_subystem repo it seems to have been heavily modified from
the upstream version. Could anyone shed some light on this. I would really
like to see relevant patches being fed back upstream. Happy to do the
actual work, but I need some context for what the changes are supposed to do
Also, as a code-deduplication fascist, are there any other pieces of code
that has been inherited and copied into LowRISC that I can look at?
//Olof
5 years, 12 months
