On 3/12/21 1:13 AM, Viresh Kumar wrote:
> On 12-03-21, 01:09, Frank Rowand wrote:
>> I suggested having the .dtso files include the .dts file because that is a
>> relatively
>> small and easy change to test. What would probably make more sense is the
>> rename
>> the existing overlay .dts files to be .dtso files and then for each overlay
>> .dtso
>> file create a new .dts file that #includes the corresponding .dtso file.
>> This is
>> more work and churn, but easier to document that the .dts files are a hack
>> that is
>> needed so that the corresponding .dtb.S files will be generated.
>
> What about creating links instead then ?
>
I don't really like the idea of using links here.
Maybe it is best to make the changes needed to allow the unittest
overlays to be .dtso instead of .dts.
Off the top of my head:
scripts/Makefile.lib:
The rule for %.dtb.S invokes cmd_dt_S_dtb, which puts the
overlay data in section .dtb.init.rodata, with a label
pointing to the beginning of the overlay __dtb_XXX_begin and
a label pointing to the end of the overlay __dtb_XXX_end,
for the overlay named XXX. I _think_ that you could simply
add a corresponding rule for %.dtbo.S using a new command
cmd_dt_S_dtbo (the same as cmd_dt_S_dtb, except use labels
__dtbo_XXX_begin and __dtbo_XXX_end).
drivers/of/unittest.o:
would need to have the #define of OVERLAY_INFO() changed to
reflect the changed label names (use __dtbo_##overlayname##begin
and __dtb_##overlay_name##_end).
drivers/of/unittest-data/Makefile:
In obj-$(CONFIG_OF_OVERLAY) change the *.dtb.o names to *.dtbo.o
I'm not sure how the DTC_FLAGS_... += -@ differentiates between
.dts / .dtb and .dtso / .dtbo That is worth looking at.
-Frank
