On Wed 2015-01-21 13:27:00, Jason Gunthorpe wrote:
> On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
> > Hi Alan,
> >
> > > On Jan 21, 2015, at 18:01 , One Thousand Gnomes <[email protected]> wrote:
> > >
> > > On Thu, 15 Jan 2015 22:54:46 +0200
> > > Pantelis Antoniou <[email protected]> wrote:
> > >
> > >> Hi Alan,
> > >>
> > >>> On Jan 15, 2015, at 22:45 , One Thousand Gnomes <[email protected]> wrote:
> > >>>
> > >>> On Thu, 15 Jan 2015 11:47:26 -0700
> > >>> Jason Gunthorpe <[email protected]> wrote:
> > >>>> It is a novel idea, my concern would be that embedding the FPGA in the
> > >>>> DT makes it permanent unswappable kernel memory.
> > >>>> Not having the kernel hold the FPGA is best for many uses.
> > >>>
> > >>> If you have a filesysytem before the FPGA is set up then it belongs in
> > >>> the file system. As you presumably loaded the kernel from somewhere there
> > >>> ought to be a file system (even an initrd).
> > >>>
> > >>
> > >> Request firmware does not imply keeping it around. You can always re-request
> > >> when reloading (although there’s a nasty big of caching that needs to be
> > >> resolved with the firmware loader).
> > >
> > > Which comes down to the same thing. Unless you can prove that there is a
> > > path to recover the firmware file that does not have any dependancies
> > > upon the firmware executing (and those can be subtle and horrid at times)
> > > you need to keep it around for suspend/resume at least and potentially
> > > any unexpected error/reset.
> > >
> >
> > In that case the only safe place to put it is in the kernel image itself, which
> > is something the firmware loader already supports.
>
> My point is that the current firmware layer is overly cautious and
> FPGAs are very big. My current project on small Xilinx device has a
> 10MB programming file. The biggest Xilinx device today has a max
> bitfile size around 122MB.
>
> So keeping that much memory pinned in the kernel when I can prove it
> is uncessary for my system (either because there is no suspend/resume
> possibility, or because I know the CPU can always access the
> filesytem) is very undesirable.
Well, your current device aalso has 1GB RAM, no?
> Other systems might have to take the ram hit.
I'd say the general case is "store bitstream in RAM" we can add
optimalizations later.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 02/15/2015 04:40 PM, Pavel Machek wrote:
> On Wed 2015-01-21 13:27:00, Jason Gunthorpe wrote:
>> On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
>> My point is that the current firmware layer is overly cautious and
>> FPGAs are very big. My current project on small Xilinx device has a
>> 10MB programming file. The biggest Xilinx device today has a max
>> bitfile size around 122MB.
>>
>> So keeping that much memory pinned in the kernel when I can prove it
>> is uncessary for my system (either because there is no suspend/resume
>> possibility, or because I know the CPU can always access the
>> filesytem) is very undesirable.
>
> Well, your current device aalso has 1GB RAM, no?
Unnecessarily pinning 10% of your ram is a good solution?
> I'd say the general case is "store bitstream in RAM" we can add
> optimalizations later.
We _have_ a firmware loading layer that doesn't store other kinds of
firmware in pinned kernel memory. I guess that was retroactively a bad
idea. As was the "freeing kernel memory" part at the end of boot.
There honestly are small embedded devices. Still. When you have your
DRAM on the SOC instead of as an external chip, a gigabyte is not in the
cards.
If you're saying "Linux should not care about this niche, let's open
ourselves to a new disruptive technology attack with that as its initial
protected base, because the average kernel developer age is about 44 now
and we're not really recruiting anybody younger than that, so we'll all
be dead before we have to care about being replaced"...
Rob
(At $DAYJOB we're building a chip that runs off of induction current to
retrofit monitoring sensors onto things. It currently has 64 megs of ram
but they're trying to trim that _down_ to free up chip space.)
On Sun, Feb 15, 2015 at 11:40:06PM +0100, Pavel Machek wrote:
> > So keeping that much memory pinned in the kernel when I can prove it
> > is uncessary for my system (either because there is no suspend/resume
> > possibility, or because I know the CPU can always access the
> > filesytem) is very undesirable.
>
> Well, your current device aalso has 1GB RAM, no?
No, certainly not. 256MB - the board only has space for two x16 DDR3
chips, and at design time 1GBit was about the biggest that could be
reasonably obtained.
It is also using a Zynq chip for management and the next firmware spin
is likely to throw away 50% of that space to enable Xilinx's narrow ECC
scheme on the ram.
The Linux environment requires only about 40M of ram for runtime, as
it was designed for systems with only 64M of ram, so even the 128M is
overkill.
Jason
On Tue 2015-02-17 11:07:53, Rob Landley wrote:
>
>
> On 02/15/2015 04:40 PM, Pavel Machek wrote:
> > On Wed 2015-01-21 13:27:00, Jason Gunthorpe wrote:
> >> On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
> >> My point is that the current firmware layer is overly cautious and
> >> FPGAs are very big. My current project on small Xilinx device has a
> >> 10MB programming file. The biggest Xilinx device today has a max
> >> bitfile size around 122MB.
> >>
> >> So keeping that much memory pinned in the kernel when I can prove it
> >> is uncessary for my system (either because there is no suspend/resume
> >> possibility, or because I know the CPU can always access the
> >> filesytem) is very undesirable.
> >
> > Well, your current device aalso has 1GB RAM, no?
>
> Unnecessarily pinning 10% of your ram is a good solution?
Never said that. But I'd rather have _some_ API proposed, then try to
design in everthing including kitchen sink and do nothing.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 02/17/2015 08:17 PM, Pavel Machek wrote:
> On Tue 2015-02-17 11:07:53, Rob Landley wrote:
>>
>>
>> On 02/15/2015 04:40 PM, Pavel Machek wrote:
>>> On Wed 2015-01-21 13:27:00, Jason Gunthorpe wrote:
>>>> On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
>>>> My point is that the current firmware layer is overly cautious and
>>>> FPGAs are very big. My current project on small Xilinx device has a
>>>> 10MB programming file. The biggest Xilinx device today has a max
>>>> bitfile size around 122MB.
>>>>
>>>> So keeping that much memory pinned in the kernel when I can prove it
>>>> is uncessary for my system (either because there is no suspend/resume
>>>> possibility, or because I know the CPU can always access the
>>>> filesytem) is very undesirable.
>>>
>>> Well, your current device aalso has 1GB RAM, no?
>>
>> Unnecessarily pinning 10% of your ram is a good solution?
>
> Never said that. But I'd rather have _some_ API proposed, then try to
> design in everthing including kitchen sink and do nothing.
+1 on this.
Thanks,
Michal
On Thu, 19 Feb 2015, Michal Simek wrote:
> On 02/17/2015 08:17 PM, Pavel Machek wrote:
> > On Tue 2015-02-17 11:07:53, Rob Landley wrote:
> >>
> >>
> >> On 02/15/2015 04:40 PM, Pavel Machek wrote:
> >>> On Wed 2015-01-21 13:27:00, Jason Gunthorpe wrote:
> >>>> On Wed, Jan 21, 2015 at 06:33:12PM +0200, Pantelis Antoniou wrote:
> >>>> My point is that the current firmware layer is overly cautious and
> >>>> FPGAs are very big. My current project on small Xilinx device has a
> >>>> 10MB programming file. The biggest Xilinx device today has a max
> >>>> bitfile size around 122MB.
> >>>>
> >>>> So keeping that much memory pinned in the kernel when I can prove it
> >>>> is uncessary for my system (either because there is no suspend/resume
> >>>> possibility, or because I know the CPU can always access the
> >>>> filesytem) is very undesirable.
> >>>
> >>> Well, your current device aalso has 1GB RAM, no?
> >>
> >> Unnecessarily pinning 10% of your ram is a good solution?
> >
> > Never said that. But I'd rather have _some_ API proposed, then try to
> > design in everthing including kitchen sink and do nothing.
>
I propose an extension to the firmware class:
int request_firmware_streamed(const struct firmware **firmware_p,
const char *name,
struct device *device,
int (*consumer)(char *buf,
size_t size,
void *priv))
This is a new function that streams the firmware file in 4k chunks to
a callback function. So firmware is not limited to the allocation
size of vmalloc.
This new function would have the same parameters as request_firmware except
adding a pointer to a consumer function. In the case of fpga's, the
consumer function is writing the 4k chunks to the fpga.
The new function will:
* open the file
* read 4k
* hand that buffer to the consumer
* sleep until the consumer returns
* give up if consumer has a nonzero exit, continue reading otherwise
Admittedly this is really different from the current firmeware class's
structures.
The real problem this is trying to solve is that bitstreams can be huge,
especially as fpga's can be daisychained. And the CPU doing the loading
could be embedded (limited resources). IFAIK fpga's don't need to have
the whole image in a ram buffer.
This gives us the convenience of request_firmware() and gives the kernel an
extension of the firmware class that others might useful instead of solving
this problem that we keep hovering around for fpga's only.
Alan Tull