Add a parser in fpga_region to decode the tlv meta data suggested by Sundar

Quoted 5 lines · Moritz Fischer

It doesn't have to be exactly FIT, but it serves a very similar purpose, so I'll definitely spend some more time on studying how that works. What you describe above seems to 'fit' (pun intended) very well with what the U-Boot guys do with FIT already (multiple images, configurations etc) there's definitely code there that we can reuse.

Bringing all of FIT to the kernel would be a large project (and wouldn't belong in drivers/fpga). But as your experimentation demonstrated, parsing our own thing with existing support in the kernel or libfdt would be pretty easy.

Quoted 2 lines

The one thing that would be interesting for our use case might be the non-contiguous header case which I assume 1. and 2. are meant to deal with?

Yes non-contiguous cases and streaming cases.

1. is the file magic (4 bytes) 2. is header size (4 bytes). The parser code will check the magic, get the header size, then gather enough additional non-contiguous/streaming header into a buffer to parse it. Having parsed it, it will have offsets to the bitfiles and other header info.

Quoted 9 lines · Alan Tull

Quoted 5 lines · Moritz Fischer

It doesn't have to be exactly FIT, but it serves a very similar purpose, so I'll definitely spend some more time on studying how that works. What you describe above seems to 'fit' (pun intended) very well with what the U-Boot guys do with FIT already (multiple images, configurations etc) there's definitely code there that we can reuse.

Quoted 4 lines

Bringing all of FIT to the kernel would be a large project (and wouldn't belong in drivers/fpga). But as your experimentation demonstrated, parsing our own thing with existing support in the kernel or libfdt would be pretty easy.

Possibly, yeah.

Quoted 10 lines

Quoted 2 lines

The one thing that would be interesting for our use case might be the non-contiguous header case which I assume 1. and 2. are meant to deal with?

Yes non-contiguous cases and streaming cases.

1. is the file magic (4 bytes) 2. is header size (4 bytes). The parser code will check the magic, get the header size, then gather enough additional non-contiguous/streaming header into a buffer to parse it. Having parsed it, it will have offsets to the bitfiles and other header info.

I think again fdt got us covered ([1]) there :-) There's a magic and a totalsize member:

<snip>
struct fdt_header {
fdt32_t magic; /* magic word FDT_MAGIC */
fdt32_t totalsize; /* total size of DT block
</snip>

Cheers,

Moritz

[1] http://lxr.free-electrons.com/source/scripts/dtc/libfdt/fdt.h#L57