[LEDE-DEV] fixing of image file names

Mathias Kresin dev at kresin.me
Wed Nov 29 00:33:39 PST 2017


28.11.2017 19:24, Daniel Golle:
> Hi Moritz,
> 
> thanks for stepping forward and adressing this issue.
> It'd be good to include the two assertions added to your list beelow.
> 
> On Tue, Nov 28, 2017 at 07:05:23PM +0100, Moritz Warning wrote:
>> Hi,
>>
>> I noticed that there are some image file names that do not follow the "common" name scheme.
>> Is it ok to change it? I would like to submit a patch.
>>
>> Some examples:
>> - all lower case image names
>>    - lede-ipq806x-EA8500-squashfs-sysupgrade.tar => lede-ipq806x-ea8500-squashfs-sysupgrade.tar
>> - revision between -
>>    - lede-mvebu-linksys-wrt1900acv2-squashfs-sysupgrade.bin => lede-mvebu-linksys-wrt1900ac-v2-squashfs-sysupgrade.bin
>> - region specific images with region identifiers (us, eu, il, ...)
>>   - lede-ramips-rt305x-wnce2001-squashfs-factory-northamerica.bin => lede-ramips-rt305x-wnce2001-us-squashfs-factory.bin
>> - separate images for each version
>>    - lede-brcm47xx-mips74k-linksys-e1000-v1-v2-v2.1-squashfs.bin => lede-brcm47xx-mips74k-linksys-e1000-v1-squashfs.bin, ...
> 
>   - board_name (in target userspace) == profile (in imagebuilder) == DTS name
> 
>   - image_filename == ${distro}-${target}-${subtarget}-${board_name}-${fstype}-${imgtype}
> 
> that would make identifying sysupgrade images much more straight
> forward (and hence automatizable).
> 
> See also
> https://github.com/aparcar/attendedsysupgrade-server/issues/80

I would like to propose something different which basically aims the same.

1. fix the compatible strings in the DTS files
2. use the compatible string from the DTS in userspace (boardname)
3. use the compatible string for the image filename (board_name in above 
example)

The DTS compatible string is supposed to be unique across the whole 
kernel and this way we can prevent duplicates in big targets like ramips.

The compatible string includes the vendor, which will make it way easier 
to find a particular image in directories with a lot of images. In 
theory, it should be even possible to provide all images in a single 
directory without target/subtarget prefix.

Since the underscore isn't a valid character in compatible strings, we 
can use it in the image filename as replacement for the comma to split 
vendor from boardname.

Due to the sync of runtime boardname and the boardname used in the image 
filename, it should be possible to guess the used image filename more 
reliably as requested.

I'm working on to do so since a while, with the following status:

1. is already done for the ramips target, more fixes are in the 
boarddetection branch of my staging tree

2. done for some targets in the boarddetection branch of my staging 
tree; done for a handful of ramips boards in the ramips branch of my 
staging tree

3. done for a handful of ramips boards in the ramips branch of my 
staging tree

Using the TP-Link TL-WR840N v5 as an example, the userspace boardname 
would be "tplink,tl-wr840n-v5" and the image filename would change from

   lede-ramips-mt76x8-tl-wr840n-v4-squashfs-sysupgrade.bin

to

   lede-ramips-mt76x8-tplink_tl-wr840n-v4-squashfs-sysupgrade.bin

Target and subtarget can be found in /etc/os_release of the running system.

I started working on the compat string in userspace thingy to get rid of 
another layer of glue code 
(target/linux/ramips/base-files/lib/ramips.sh), to unify the creation of 
the userspace boardname across all targets.

Initially it was meant to make the review of board support patches 
easier for me. But I noticed that it has more benefits than that as we 
can see with this mail thread.

But fixing the compat strings and migrating the userspace boardname to a 
DTS compat string based one is a hugh task and time consuming.

The first commits in my staging tree regarding the topic are from April 
this year and I'm still not finished. As all of us, I'm time constrained 
as well.

Any feedback on this approach (and help in migrating exists boards of 
course) is highly welcome.

Mathias



More information about the Lede-dev mailing list