Zynq-7020 SoC on-chip-memory

Matías Perret Cantoni perretcantonim at gmail.com
Thu Mar 19 21:53:40 UTC 2015


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 at 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 at sbcglobal.net> wrote:
>> >> Any advice on how to add this memory to my system?
>> >
>> > I think it might be more trouble than it’s worth.
>>
>> I do too. I tried back in the day to map Atmel’s small cache of RAM into the OS
>> as well. It didn’t go well.
>>
>> You likely don’t want to use this 256kB for general purpose memory anyway. You’ll
>> likely want to use it for something special. For Atmel, I was looking at running interrupt
>> handlers and/or ethernet packets through that memory… 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
>
>


More information about the freebsd-arm mailing list