Add support for offset of a filesystem within a block-device

PATCH New Hannes Petermaier 3 participants 9 messages Mar 6, 2014 – Mar 12, 2014

Subsystems (2)

MMC, SD and SDIO VFAT/FAT/msdos filesystem

lore

Share & tools

lore

Hannes Petermaier

author

2014-03-06 13:30 UTC #0 lore raw

PATCH 1/1 Add support for offset of a filesystem within a block-device

For clear separation of user's (OS) filesystem to U-Boot and other's stuff it is now possible to give the filesystem a specific offset and a specific size.
For full consistency OS storage driver also has to support this and has to use same offset and size.

Following new parameters has been added to the block_dev_desc_t structure:
- lba_offset : offset in blocks from which fs is reading/writing
- lba_fs : size in blocks of fs

This two parameters are filled from the underlaying device-driver. As default they are initialized for giving whole size of block-device to the filesystem.

In case of mmc-driver a function for modifiying drive geometry is called 'board_mmc_geometry', this function is implemented as '__weak', so it can be replaced by a board-specific function, which can setup suitable offset and size for the filesystem. This function is responsible for giving reasonable values, e.g. lba_offset+lba_fs must not exceed available blocks of the device.

Only MMC Driver and FATFS are modified to support this.

Signed-off-by Hannes Petermaier <[email protected]>

---
 disk/part_dos.c    |   11 ++++++++---
 drivers/mmc/mmc.c  |    8 ++++++++
 fs/fat/fat.c       |    5 +++--
 fs/fat/fat_write.c |    7 ++++---
 include/part.h     |   10 +++++++++-
 5 files changed, 32 insertions(+), 9 deletions(-)

disk/part_dos.c +8 -3

index 05c3933..aa38819 100644
@@ -87,7 +87,8 @@ int test_part_dos (block_dev_desc_t *dev_desc)
 {
 	ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
 
-	if (dev_desc->block_read(dev_desc->dev, 0, 1, (ulong *) buffer) != 1)
+	if (dev_desc->block_read(dev_desc->dev, dev_desc->lba_offset, 1,
+				 (ulong *)buffer) != 1)
 		return -1;
 
 	if (test_block_type(buffer) != DOS_MBR)

@@ -106,7 +107,9 @@ static void print_partition_extended(block_dev_desc_t *dev_desc,
 	dos_partition_t *pt;
 	int i;
 
-	if (dev_desc->block_read(dev_desc->dev, ext_part_sector, 1, (ulong *) buffer) != 1) {
+	if (dev_desc->block_read(dev_desc->dev,
+				 ext_part_sector + dev_desc->lba_offset, 1,
+				 (ulong *)buffer) != 1) {
 		printf ("** Can't read partition table on %d:%d **\n",
 			dev_desc->dev, ext_part_sector);
 		return;

@@ -169,7 +172,9 @@ static int get_partition_info_extended (block_dev_desc_t *dev_desc, int ext_part
 	dos_partition_t *pt;
 	int i;
 
-	if (dev_desc->block_read (dev_desc->dev, ext_part_sector, 1, (ulong *) buffer) != 1) {
+	if (dev_desc->block_read(dev_desc->dev,
+				 ext_part_sector + dev_desc->lba_offset, 1,
+				 (ulong *)buffer) != 1) {
 		printf ("** Can't read partition table on %d:%d **\n",
 			dev_desc->dev, ext_part_sector);
 		return -1;

drivers/mmc/mmc.c +8 -0

index 8ab0bc9..4acce73 100644
@@ -526,6 +526,12 @@ static int mmc_change_freq(struct mmc *mmc)
 	return 0;
 }
 
+void __weak board_mmc_geometry(struct mmc *mmc)
+{
+	mmc->block_dev.lba_fs = mmc->block_dev.lba;
+	mmc->block_dev.lba_offset = 0;
+}
+
 static int mmc_set_capacity(struct mmc *mmc, int part_num)
 {
 	switch (part_num) {

@@ -551,6 +557,8 @@ static int mmc_set_capacity(struct mmc *mmc, int part_num)
 
 	mmc->block_dev.lba = lldiv(mmc->capacity, mmc->read_bl_len);
 
+	board_mmc_geometry(mmc);
+
 	return 0;
 }

fs/fat/fat.c +3 -2

index 54f42ea..dba0989 100644
@@ -49,7 +49,8 @@ static int disk_read(__u32 block, __u32 nr_blocks, void *buf)
 		return -1;
 
 	return cur_dev->block_read(cur_dev->dev,
-			cur_part_info.start + block, nr_blocks, buf);
+			cur_part_info.start + block + cur_dev->lba_offset,
+			nr_blocks, buf);
 }
 
 int fat_set_blk_dev(block_dev_desc_t *dev_desc, disk_partition_t *info)

@@ -97,7 +98,7 @@ int fat_register_device(block_dev_desc_t *dev_desc, int part_no)
 		}
 
 		info.start = 0;
-		info.size = dev_desc->lba;
+		info.size = dev_desc->lba_fs;
 		info.blksz = dev_desc->blksz;
 		info.name[0] = 0;
 		info.type[0] = 0;

fs/fat/fat_write.c +4 -3

index 9f5e911..6238a8e 100644
@@ -31,14 +31,15 @@ static int disk_write(__u32 block, __u32 nr_blocks, void *buf)
 	if (!cur_dev || !cur_dev->block_write)
 		return -1;
 
-	if (cur_part_info.start + block + nr_blocks >
-		cur_part_info.start + total_sector) {
+	if (cur_part_info.start + block + nr_blocks + cur_dev->lba_offset >
+		cur_part_info.start + total_sector + cur_dev->lba_offset) {
 		printf("error: overflow occurs\n");
 		return -1;
 	}
 
 	return cur_dev->block_write(cur_dev->dev,
-			cur_part_info.start + block, nr_blocks,	buf);
+			cur_part_info.start + block + cur_dev->lba_offset,
+			nr_blocks, buf);
 }
 
 /*

include/part.h +9 -1

index 4beb6db..29a227a 100644
@@ -20,7 +20,15 @@ typedef struct block_dev_desc {
 #ifdef CONFIG_LBA48
 	unsigned char	lba48;		/* device can use 48bit addr (ATA/ATAPI v7) */
 #endif
-	lbaint_t	lba;		/* number of blocks */
+	lbaint_t	lba_offset;	/*
+					 * offset from which file-systems
+					 * do their work
+					 */
+	lbaint_t	lba_fs;		/*
+					 * number of blocks available to the
+					 * file-system
+					 */
+	lbaint_t	lba;		/* total number of blocks-available */
 	unsigned long	blksz;		/* block size */
 	int		log2blksz;	/* for convenience: log2(blksz) */
 	char		vendor [40+1];	/* IDE model, SCSI Vendor */

Signature · 1 line

1.7.9.5

Tom Rini

2014-03-12 16:08 UTC #1 lore raw

PATCH 1/1 Add support for offset of a filesystem within a block-device

Quoted 22 lines · Hannes Petermaier

For clear separation of user's (OS) filesystem to U-Boot and other's stuff it is now possible to give the filesystem a specific offset and a specific size.
For full consistency OS storage driver also has to support this and has to use same offset and size.
Following new parameters has been added to the block_dev_desc_t structure:
- lba_offset : offset in blocks from which fs is reading/writing
- lba_fs : size in blocks of fs
This two parameters are filled from the underlaying device-driver. As default they are initialized for giving whole size of block-device to the filesystem.
In case of mmc-driver a function for modifiying drive geometry is called 'board_mmc_geometry', this function is implemented as '__weak', so it can be replaced by a board-specific function, which can setup suitable offset and size for the filesystem. This function is responsible for giving reasonable values, e.g. lba_offset+lba_fs must not exceed available blocks of the device.

Quoted 3 lines

Only MMC Driver and FATFS are modified to support this.
Signed-off-by Hannes Petermaier <[email protected]>

Sorry if I'm being dense here, but what is the usecase exactly? When we don't have a partition table of some sort?

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140312/118ac62f/attachment.pgp>

Hannes Petermaier

2014-03-12 17:19 UTC #2 lore raw

PATCH 1/1 Add support for offset of a filesystem within a block-device

Quoted 24 lines · Tom Rini

Quoted 22 lines · Hannes Petermaier
For clear separation of user's (OS) filesystem to U-Boot and other's stuff it is now possible to give the filesystem a specific offset and a specific size.
For full consistency OS storage driver also has to support this and has to use same offset and size.
Following new parameters has been added to the block_dev_desc_t structure:
- lba_offset : offset in blocks from which fs is reading/writing
- lba_fs : size in blocks of fs
This two parameters are filled from the underlaying device-driver. As default they are initialized for giving whole size of block-device to the filesystem.
In case of mmc-driver a function for modifiying drive geometry is called 'board_mmc_geometry', this function is implemented as '__weak', so it can be replaced by a board-specific function, which can setup suitable offset and size for the filesystem. This function is responsible for giving reasonable values, e.g. lba_offset+lba_fs must not exceed available blocks of the device.

Quoted 6 lines

Quoted 3 lines
Only MMC Driver and FATFS are modified to support this.
Signed-off-by Hannes Petermaier <[email protected]>
Sorry if I'm being dense here, but what is the usecase exactly? When we don't have a partition table of some sort?

Hi Tom,

I try to explain the use case with my application as example:

I have an eMMC flash with 4GB space. On my target OS vxWorks is running, which has as filesystem a simple DOS-FAT.

I would like to give an offset to the filesystem due to two reasons:
a) U-Boot with its environment should / can not remain within the DOSFS (it should not be accessible by the user/OS). Also U-Boot must be at least with the MLO "in front" of the flash since i am booting from the eMMC flash.
b) i want limit the user-accessible space to the flash to about 512MB.

There are, for my unterstanding, two ways to achieve this:

a) give no offset for the "blockdevice" at all and have a partition table at the bottom of flash (ROM code searches in my case (am3352) at several places for a bootable code, so this method would be suitable for booting) - i don't know how it is on other processors, the rest would be magic of the following partioning software (OS) - but many os (vxworks for example) cannot have specific start-cylinder for the first partition, we would have to rewrite the partitioner. Making a change within the partitioning section at the OS is therefore a bit critical, not at least because changes there affects all other block devices too.

So plan b) looked best for my opinion:
Give a specific offset/size to the 'blockdevice' within raw-flash. We have to adapt only the specific blockdevice driver to detect/have a specific offset/size and rest of OS don't need to know about this special situation. We don't use the space laying before the offset within the OS at all (clear separation). Within U-Boot we can use the whole flash in "raw-mode" and use "FAT" with the beginning of specified offset.
With the offset i also can control how much space is left for the OS and its filesystem.

Is my explanation clear ? please feel free to ask me more. Whats your opinion about this ?

best regards,
Hannes

Tom Rini

2014-03-12 19:00 UTC #3 lore raw

PATCH 1/1 Add support for offset of a filesystem within a block-device

Quoted 70 lines · Hannes Petermaier

Quoted 24 lines · Tom Rini
Quoted 22 lines · Hannes Petermaier
For clear separation of user's (OS) filesystem to U-Boot and other's stuff it is now possible to give the filesystem a specific offset and a specific size.
For full consistency OS storage driver also has to support this and has to use same offset and size.
Following new parameters has been added to the block_dev_desc_t structure:
- lba_offset : offset in blocks from which fs is reading/writing
- lba_fs : size in blocks of fs
This two parameters are filled from the underlaying device-driver. As default they are initialized for giving whole size of block-device to the filesystem.
In case of mmc-driver a function for modifiying drive geometry is called 'board_mmc_geometry', this function is implemented as '__weak', so it can be replaced by a board-specific function, which can setup suitable offset and size for the filesystem. This function is responsible for giving reasonable values, e.g. lba_offset+lba_fs must not exceed available blocks of the device.
Quoted 6 lines
Quoted 3 lines
Only MMC Driver and FATFS are modified to support this.
Signed-off-by Hannes Petermaier <[email protected]>
Sorry if I'm being dense here, but what is the usecase exactly? When we don't have a partition table of some sort?
Hi Tom,
I try to explain the use case with my application as example:
I have an eMMC flash with 4GB space. On my target OS vxWorks is running, which has as filesystem a simple DOS-FAT.
I would like to give an offset to the filesystem due to two reasons:
a) U-Boot with its environment should / can not remain within the DOSFS (it should not be accessible by the user/OS). Also U-Boot must be at least with the MLO "in front" of the flash since i am booting from the eMMC flash.
b) i want limit the user-accessible space to the flash to about 512MB.
There are, for my unterstanding, two ways to achieve this:
a) give no offset for the "blockdevice" at all and have a partition table at the bottom of flash (ROM code searches in my case (am3352) at several places for a bootable code, so this method would be suitable for booting) - i don't know how it is on other processors, the rest would be magic of the following partioning software (OS) - but many os (vxworks for example) cannot have specific start-cylinder for the first partition, we would have to rewrite the partitioner. Making a change within the partitioning section at the OS is therefore a bit critical, not at least because changes there affects all other block devices too.
So plan b) looked best for my opinion:
Give a specific offset/size to the 'blockdevice' within raw-flash. We have to adapt only the specific blockdevice driver to detect/have a specific offset/size and rest of OS don't need to know about this special situation. We don't use the space laying before the offset within the OS at all (clear separation). Within U-Boot we can use the whole flash in "raw-mode" and use "FAT" with the beginning of specified offset.
With the offset i also can control how much space is left for the OS and its filesystem.

Quoted 2 lines

Is my explanation clear ? please feel free to ask me more. Whats your opinion about this ?

Thanks for explaining. But you should be able to have this work without changing U-Boot or VxWorks code by doing:
1) Create a partition table at the start of eMMC
2) Write SPL to offset 128KB
2b) If you like, put a backup copy at 256KB
3) Write U-Boot to offset 384KB as usual

Now here's where I'm hindered a bit by my (lack of) knowledge of VxWorks. If you cannot say that the first partition in the table is wherever you like (which seems odd, this is fine elsewhere), just create a dummy partition that covers from the start until end-512MB, and then make the next partiton, where you want the user to see next and make it be 512MB.

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140312/49b57dd2/attachment.pgp>

Hannes Petermaier

2014-03-12 19:17 UTC #4 lore raw

PATCH 1/1 Add support for offset of a filesystem within a block-device

Quoted 79 lines · Tom Rini

Quoted 69 lines · Hannes Petermaier
Quoted 24 lines · Tom Rini
Quoted 22 lines · Hannes Petermaier
For clear separation of user's (OS) filesystem to U-Boot and other's stuff it is now possible to give the filesystem a specific offset and a specific size.
For full consistency OS storage driver also has to support this and has to use same offset and size.
Following new parameters has been added to the block_dev_desc_t structure:
- lba_offset : offset in blocks from which fs is reading/writing
- lba_fs : size in blocks of fs
This two parameters are filled from the underlaying device-driver. As default they are initialized for giving whole size of block-device to the filesystem.
In case of mmc-driver a function for modifiying drive geometry is called 'board_mmc_geometry', this function is implemented as '__weak', so it can be replaced by a board-specific function, which can setup suitable offset and size for the filesystem. This function is responsible for giving reasonable values, e.g. lba_offset+lba_fs must not exceed available blocks of the device.
Quoted 6 lines
Quoted 3 lines
Only MMC Driver and FATFS are modified to support this.
Signed-off-by Hannes Petermaier <[email protected]>
Sorry if I'm being dense here, but what is the usecase exactly? When we don't have a partition table of some sort?
Hi Tom,
I try to explain the use case with my application as example:
I have an eMMC flash with 4GB space. On my target OS vxWorks is running, which has as filesystem a simple DOS-FAT.
I would like to give an offset to the filesystem due to two reasons:
a) U-Boot with its environment should / can not remain within the DOSFS (it should not be accessible by the user/OS). Also U-Boot must be at least with the MLO "in front" of the flash since i am booting from the eMMC flash.
b) i want limit the user-accessible space to the flash to about 512MB.
There are, for my unterstanding, two ways to achieve this:
a) give no offset for the "blockdevice" at all and have a partition table at the bottom of flash (ROM code searches in my case (am3352) at several places for a bootable code, so this method would be suitable for booting) - i don't know how it is on other processors, the rest would be magic of the following partioning software (OS) - but many os (vxworks for example) cannot have specific start-cylinder for the first partition, we would have to rewrite the partitioner. Making a change within the partitioning section at the OS is therefore a bit critical, not at least because changes there affects all other block devices too.
So plan b) looked best for my opinion:
Give a specific offset/size to the 'blockdevice' within raw-flash. We have to adapt only the specific blockdevice driver to detect/have a specific offset/size and rest of OS don't need to know about this special situation. We don't use the space laying before the offset within the OS at all (clear separation). Within U-Boot we can use the whole flash in "raw-mode" and use "FAT" with the beginning of specified offset.
With the offset i also can control how much space is left for the OS and its filesystem.
Quoted 2 lines
Is my explanation clear ? please feel free to ask me more. Whats your opinion about this ?
Thanks for explaining. But you should be able to have this work without changing U-Boot or VxWorks code by doing:
1) Create a partition table at the start of eMMC
2) Write SPL to offset 128KB
2b) If you like, put a backup copy at 256KB
3) Write U-Boot to offset 384KB as usual

Quoted 7 lines

Now here's where I'm hindered a bit by my (lack of) knowledge of VxWorks. If you cannot say that the first partition in the table is wherever you like (which seems odd, this is fine elsewhere), just create a dummy partition that covers from the start until end-512MB, and then make the next partiton, where you want the user to see next and make it be 512MB.

Thanks for reply.

Good idea, i've also thougt about this way ....
but what happens in case of OS is going to re-partitioning the drive (flash), delete all partitions (dummy-part also) an puts the first (new) partition behind the part-table (vxWorks can handle up to four partitions and we give end-user the possibility to create/delete partitions) ? First partition becomes laying over U-Boot @ 384k (and some other stuff which may be stored there).
To prevent this case we would have to modify "fdisk" of vxWorks, which i would like to prevent because this is a common part of OS and would affect all mass-storage.
With my solution, OS never can see/delete any other (dummy) partitiion - it has always "a normal drive" accessible.

best regards,
Hannes

Tom Rini

2014-03-12 19:33 UTC #5 lore raw

PATCH 1/1 Add support for offset of a filesystem within a block-device

Quoted 4 lines · Hannes Petermaier

Good idea, i've also thougt about this way ....
but what happens in case of OS is going to re-partitioning the drive (flash), delete all partitions (dummy-part also) an puts the first (new) partition behind the part-table (vxWorks can handle up to four

Quoted 8 lines

partitions and we give end-user the possibility to create/delete partitions) ? First partition becomes laying over U-Boot @ 384k (and some other stuff which may be stored there).
To prevent this case we would have to modify "fdisk" of vxWorks, which i would like to prevent because this is a common part of OS and would affect all mass-storage.
With my solution, OS never can see/delete any other (dummy) partitiion - it has always "a normal drive" accessible.

Since this is really eMMC, mark SPL/U-Boot as protected? I'd swear such a thing is allowed, but I've just been looking at QSPI things recently not eMMC so I might have some mental mismatch.

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140312/1f48cca6/attachment.pgp>

Hannes Petermaier

2014-03-12 20:14 UTC #6 lore raw

PATCH 1/1 Add support for offset of a filesystem within a block-device

Quoted 14 lines · Tom Rini

Quoted 4 lines · Hannes Petermaier
Good idea, i've also thougt about this way ....
but what happens in case of OS is going to re-partitioning the drive (flash), delete all partitions (dummy-part also) an puts the first (new) partition behind the part-table (vxWorks can handle up to four
Quoted 8 lines
partitions and we give end-user the possibility to create/delete partitions) ? First partition becomes laying over U-Boot @ 384k (and some other stuff which may be stored there).
To prevent this case we would have to modify "fdisk" of vxWorks, which i would like to prevent because this is a common part of OS and would affect all mass-storage.
With my solution, OS never can see/delete any other (dummy) partitiion - it has always "a normal drive" accessible.

Quoted 4 lines

Since this is really eMMC, mark SPL/U-Boot as protected? I'd swear such a thing is allowed, but I've just been looking at QSPI things recently not eMMC so I might have some mental mismatch.

Hi Tom,
You're right. SPL could be marked as protected.
But how to deal here with u-boot itself ? its address is within a possible area of a partition.
Fdisk doesn't know about that :-(
We also cannot protect #0 where partition-table is stored, because user should able to create/delete partitions.

So - maybe be a solution, but unfortunately not for me :-( Today we give to our end-users up to 4 partitiions, exact that what VxWorks can support - so i will be hard to have a 5th one ...

best regards,
Hannes

Tom Rini

2014-03-12 20:27 UTC #7 lore raw

PATCH 1/1 Add support for offset of a filesystem within a block-device

Quoted 20 lines · Hannes Petermaier

Quoted 14 lines · Tom Rini
Quoted 4 lines · Hannes Petermaier
Good idea, i've also thougt about this way ....
but what happens in case of OS is going to re-partitioning the drive (flash), delete all partitions (dummy-part also) an puts the first (new) partition behind the part-table (vxWorks can handle up to four
Quoted 8 lines
partitions and we give end-user the possibility to create/delete partitions) ? First partition becomes laying over U-Boot @ 384k (and some other stuff which may be stored there).
To prevent this case we would have to modify "fdisk" of vxWorks, which i would like to prevent because this is a common part of OS and would affect all mass-storage.
With my solution, OS never can see/delete any other (dummy) partitiion - it has always "a normal drive" accessible.
Quoted 4 lines
Since this is really eMMC, mark SPL/U-Boot as protected? I'd swear such a thing is allowed, but I've just been looking at QSPI things recently not eMMC so I might have some mental mismatch.

Quoted 7 lines

Hi Tom,
You're right. SPL could be marked as protected.
But how to deal here with u-boot itself ? its address is within a possible area of a partition.
Fdisk doesn't know about that :-(
We also cannot protect #0 where partition-table is stored, because user should able to create/delete partitions.

Block size then wouldn't let 0->128K be writable, 128->whatever read-only, whatever->end writable ?

Quoted 3 lines

So - maybe be a solution, but unfortunately not for me :-( Today we give to our end-users up to 4 partitiions, exact that what VxWorks can support - so i will be hard to have a 5th one ...

Well, I guess there's two ways to look at this, either just documentation or seeing how hard it would be to make VxWorks behave like other OSes and let partition 1 be wherever it says it is, or some combination of both.

I do appreciate you posting the code as it may be useful to others but at least right now, barring an outcry of "oh wait, I need this too!" I'm inclined to mark this as RFC in patchwork. Thanks again!

Signature · 8 lines

Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140312/29d1d40d/attachment.pgp>

Hannes Petermaier

2014-03-12 20:51 UTC #8 lore raw

PATCH 1/1 Add support for offset of a filesystem within a block-device

Quoted 14 lines · Tom Rini

Quoted 8 lines
Hi Tom,
You're right. SPL could be marked as protected.
But how to deal here with u-boot itself ? its address is within a possible area of a partition.
Fdisk doesn't know about that :-(
We also cannot protect #0 where partition-table is stored, because user should able to create/delete partitions.
Block size then wouldn't let 0->128K be writable, 128->whatever read-only, whatever->end writable ?
Quoted 3 lines
So - maybe be a solution, but unfortunately not for me :-( Today we give to our end-users up to 4 partitiions, exact that what VxWorks can support - so i will be hard to have a 5th one ...

Quoted 9 lines

Well, I guess there's two ways to look at this, either just documentation or seeing how hard it would be to make VxWorks behave like other OSes and let partition 1 be wherever it says it is, or some combination of both.
I do appreciate you posting the code as it may be useful to others but at least right now, barring an outcry of "oh wait, I need this too!" I'm inclined to mark this as RFC in patchwork. Thanks again!

Ok Tom, we can do so ... please mark it for now as RFC. Maybe in the future other people say "i like this too ..." and we can apply this feature to the mainline code.

Until this day comes, "block-device offset within flash" will be my personal "nursing-case" and i have to patch it into my build.

many thanks for your time and best regards,
Hannes