Date: Thu, 19 Mar 2015 18:53:39 -0300 From: =?UTF-8?Q?Mat=C3=ADas_Perret_Cantoni?= <perretcantonim@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: Zynq-7020 SoC on-chip-memory Message-ID: <CADLKG02p-r=Ogxt6R-8x2hDV5fLkmA1bSUxQAUxzvgbhAp1pMQ@mail.gmail.com> In-Reply-To: <1426795003.87786.3.camel@freebsd.org> References: <CADLKG01oSQ=caZFOnZQM14=pAVPvLz45EznMes9mVfG2kD6TEQ@mail.gmail.com> <D2F57338-AC51-4A2D-982B-F024A5E422E4@sbcglobal.net> <91283C43-66EA-4CE7-B080-D5F4223A725B@bsdimp.com> <1426795003.87786.3.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Well it was for a special purpose. I'm working on my carrer's final
project and I've been assigned one last requirement: one of the
project directors is doing research on Petri Net Processors and due to
some speed requirements he asked me to execute code on the
on-chip-memory.
I thought that may be I could simply set that memory as part of the
system memory and then execute code there. But given your answers I
guess it's way far from my capacities right now.
Any way I'll share you my innocent ideas so far, just in case:
1) Implement the functionalities in a driver and then load it at the
OCM's address space with something like:
# kldload driver.ko -at ocm_addr
Which I know can't be done this way, but... is there some similar way
of doing so?
2) Write a driver that owns the OCM region as part of its resources
and copy my binary there and execute it in some way. I was thinking in
something like JIT code injection on the heap during run time. I was
able to do this already in my x86 station, following some simple
examples I found.
3) Linker magic?
Well that's all.
Thank you all, I'm learning a bunch with you.
Regards,
Matias.-
2015-03-19 16:56 GMT-03:00 Ian Lepore <ian@freebsd.org>:
> On Thu, 2015-03-19 at 13:38 -0600, Warner Losh wrote:
>> > On Mar 19, 2015, at 1:19 PM, Thomas Skibo <ThomasSkibo@sbcglobal.net> =
wrote:
>> >> Any advice on how to add this memory to my system?
>> >
>> > I think it might be more trouble than it=E2=80=99s worth.
>>
>> I do too. I tried back in the day to map Atmel=E2=80=99s small cache of =
RAM into the OS
>> as well. It didn=E2=80=99t go well.
>>
>> You likely don=E2=80=99t want to use this 256kB for general purpose memo=
ry anyway. You=E2=80=99ll
>> likely want to use it for something special. For Atmel, I was looking at=
running interrupt
>> handlers and/or ethernet packets through that memory=E2=80=A6 There were=
issues with doing
>> either one of these that I can no longer recall...
>>
>> Warner
>>
>
> My vague plan for a long time has been to try to get L1 page descriptor
> tables into this sort of ram. Often the on-chip ram can be accessed at
> the same speed as L1 cache so it would be a big win.
>
> Sometimes when a SoC has on-chip crypto accellerator hardware, this
> on-chip ram (or some portion of it) needs to be dedicated to it.
>
> If it's described in the memory region data in FDT it'll just get handed
> over to the vm subsystem as available memory, and get allocated for
> who-knows-what.
>
> -- Ian
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLKG02p-r=Ogxt6R-8x2hDV5fLkmA1bSUxQAUxzvgbhAp1pMQ>