On Fri, 07 Aug 2015 20:09:14 +0200, Felix Fietkau <[email protected]> wrote:
On 2015-08-07 18:50, Mathieu Olivari wrote:
Actually, I was asking myself the same questions yesterday. I was
leaning
towards dts for the reasons you mention below as well; the problem is
on ref
designs, there is no "standard" layout. The flash layout changes with
time
(an AP148 with an old boot binary blob will have a different layout
than the
same AP148 with a new boot image), sometimes with a certain application
(some boots will have an SMEM with 2 kernels & 2 rootfs for dual
partitioning). For this reason, and on ref designs, it'd be easier to
have
one dts and the kernel adapting at run-time, than multiplying the dts
files
and having to pick the right one based on your current SMEM content.
Well, there's no reason to try to support old versions or nonstandard
designs upstream. You just have to pick the one you consider upstream
version. For what you are looking for, you might want to take a look at
device tree overlays.
I would agree that it's the exception though; on most retail routers,
you
would have one SMEM per SKU, i.e. one layout per dts.
I'm thinking the most flexible way would probably to have the
opportunity in
dts to select between "dynamic" smem partitioning, or regular "fixed"
partitioning. Not sure if something like this has ever been done in the
past; but we could explore it.
The bcm53xx target in OpenWrt works like that. The mtd driver specifies
two partition parsers, first ofpart, then a custom one.
If ofpart fails to find any partitions, the custom one gets to specify
the layout. We could probably make use of something like that for ipq as
well.
Agreed, but I'm afraid 3rd party vendors will miss-use that as usual.
Imre
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
