[OpenRISC] (no subject)

[OpenRISC] (no subject)

[Kais JALLOULI]

Hi all  ,
I am a student and I want to use the cpu openrisc or1200.I have a question
and I wish you repond me. Please  there   is any simple makefile example
for or1200 without using it as SoC? I am grateful for help.
Thanks a lot.



<https://mailtrack.io/> Sent with Mailtrack
<https://mailtrack.io/install?source=signature&lang=en&referral=kais.jallouli@enit.utm.tn&idSignature=22>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20170822/d595b99c/attachment.html>

[OpenRISC] (no subject)

[Olof Kindgren]

On Tue, Aug 22, 2017 at 5:10 PM, Kais JALLOULI <kais.jallouli@enit.utm.tn>
wrote:

> Hi all  ,
> I am a student and I want to use the cpu openrisc or1200.I have a question
> and I wish you repond me. Please  there   is any simple makefile example
> for or1200 without using it as SoC? I am grateful for help.
> Thanks a lot.
>
>
>
> <https://mailtrack.io/> Sent with Mailtrack
> <https://mailtrack.io/install?source=signature&lang=en&referral=kais.jallouli@enit.utm.tn&idSignature=22>
>
> _______________________________________________
> OpenRISC mailing list
> OpenRISC at lists.librecores.org
> https://lists.librecores.org/listinfo/openrisc
>
>
Hi,

First of all I would recommend you to use mor1kx instead of or1200 as
mor1kx is a more modern replacement with better code, more features and
likely less bugs. If you need to use or1200 anyway for some reason, that's
fine too

I'm not sure what kind of makefile you need. For example, are you looking
at integrating the CPU in a larger project, run simulations or perform
stand-alone ASIC synthesis?

For the two first cases I would recommend you to use FuseSoC (
https://github.com/olofk/fusesoc). With FuseSoC you can easily build a
larger system from existing components. There is also a small simulation
SoC for both or1200 (or1200-generic) and mor1kx (mor1kx-generic). I know
you said that you don't want a SoC, but you will at least need some kind of
memory to store program/data and likely a UART for output, which is exactly
what is included in the simulation systems.

Hope this helps as a starting point

//Olof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20170823/70804c5b/attachment.html>

[OpenRISC] (no subject)

[Christoph Hellwig]

To: iommu@lists.linux-foundation.org
Cc: linux-arch at vger.kernel.org
Cc: Michal Simek <monstr@monstr.eu>
Cc: Greentime Hu <green.hu@gmail.com>
Cc: Vincent Chen <deanbo422@gmail.com>
Cc: linux-alpha at vger.kernel.org
Cc: linux-snps-arc at lists.infradead.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-c6x-dev at linux-c6x.org
Cc: linux-hexagon at vger.kernel.org
Cc: linux-m68k at lists.linux-m68k.org
Cc: nios2-dev at lists.rocketboards.org
Cc: openrisc at lists.librecores.org
Cc: linux-parisc at vger.kernel.org
Cc: linux-sh at vger.kernel.org
Cc: sparclinux at vger.kernel.org
Cc: linux-xtensa at linux-xtensa.org
Cc: linux-kernel at vger.kernel.org
Subject: [RFC] common non-cache coherent direct dma mapping ops

Hi all,

this series continues consolidating the dma-mapping code, with a focus
on architectures that do not (always) provide cache coherence for DMA.
Three architectures (arm, mips and powerpc) are still left to be
converted later due to complexity of their dma ops selection.

The dma-noncoherent ops calls the dma-direct ops for the actual
translation of streaming mappins and allow the architecture to provide
any cache flushing required for cpu to device and/or device to cpu
ownership transfers.  The dma coherent allocator is for now still left
entirely to architecture supplied implementations due the amount of
variations.  Hopefully we can do some consolidation for them later on
as well.

A lot of architectures are currently doing very questionable things
in their dma mapping routines, which are documented in the changelogs
for each patch.  Please review them very careful and correct me on
incorrect assumptions.

Because this series sits on top of two previously submitted series
a git tree might be useful to actually test it.  It is provided here:

    git://git.infradead.org/users/hch/misc.git generic-dma-noncoherent

Gitweb:

    http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/generic-dma-noncoherent

[OpenRISC] (no subject)

[Kais JALLOULI]

I am a student .

I want to use the cpu or1200 and integrate it in a larger project.

I downloaded  the rtl code from https://github.com/openrisc/or1200 and
followed up this tutorial to install the toolchain

http://electria.metropolia.fi/2013/12/linux-on-de0-nano-part-i-simulator/

However the downloaded rtl code did not have software generation info such
as to get the toolchain and generate the Makefile.

The problem is that I am  from Electronic faculty and have limited
knowledge about software  development ( such as librray, makefile,
toolchain ...generation).

I would really appreciate it if you  can help me in writing the makefile
and guide us how to get a toolchain for Or1200 cpu.




<https://mailtrack.io/> Sent with Mailtrack
<https://mailtrack.io/install?source=signature&lang=en&referral=kais.jallouli@enit.utm.tn&idSignature=22>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.librecores.org/pipermail/openrisc/attachments/20170824/22e526f1/attachment.html>

[OpenRISC] (no subject)

[David Howells]

> -header-y += msr-index.h

I see it on my desktop as /usr/include/asm/msr-index.h and it's been there at
least four years - and as such it's part of the UAPI.  I don't think you can
remove it unless you can guarantee there are no userspace users.

David

[OpenRISC] (no subject)

[David Howells]

Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:

> This header file is exported, thus move it to uapi.

Exported how?

> +#ifdef __INT32_TYPE__
> +#undef __INT32_TYPE__
> +#define __INT32_TYPE__		int
> +#endif
> +
> +#ifdef __UINT32_TYPE__
> +#undef __UINT32_TYPE__
> +#define __UINT32_TYPE__	unsigned int
> +#endif
> +
> +#ifdef __UINTPTR_TYPE__
> +#undef __UINTPTR_TYPE__
> +#define __UINTPTR_TYPE__	unsigned long
> +#endif

These weren't defined by the kernel before, so why do we need to define them
now?

Will defining __UINTPTR_TYPE__ cause problems in compiling libboost by
changing the signature on C++ functions that use uintptr_t?

David