why UBI static volumes are flagged as DEVFS_IS_CHARACTER_DEV

why UBI static volumes are flagged as DEVFS_IS_CHARACTER_DEV

[iw3gtf]

Hi,

I noticed that the commit id c087e0804f0290e9886899e8a3cccb07c4ce088b flagged static
UBI volumes as DEVFS_IS_CHARACTER_DEV.

A consequence of this flag is that commands like:

# cp /dev/nand0.ubi_volumes.ubi.my_static_vol file

will not work because the cp command will see a src file (the static UBI volume) with a size
of -1 (FILE_SIZE_STREAM) and keep on reading from the volume until a flood of
"UBI assert failed in ubi_eba_read_leb at 359" asserts comes out of the console.

I tried to comment out the flag assignment, just to see what happen:

int ubi_volume_cdev_add(struct ubi_device *ubi, struct ubi_volume *vol)
{
...
	cdev->size = vol->used_bytes;

//	if (vol->vol_type == UBI_STATIC_VOLUME)
//		cdev->flags = DEVFS_IS_CHARACTER_DEV;

	cdev->dev = &vol->dev;
...

and then the cp command worked than as expected.

Could someone shortly confirm that the DEVFS_IS_CHARACTER_DEV flag for static UBI volumes
is really needed (to avoid some other problems that my superficial test does not triggers) ?

giorgio


Giorgio, iw3gtf@arcor.de

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: why UBI static volumes are flagged as DEVFS_IS_CHARACTER_DEV

[Teresa Remmet]

Hello Giorgio,

Am Mittwoch, den 05.10.2016, 15:23 +0200 schrieb iw3gtf@arcor.de:
> Hi,
> 
> I noticed that the commit id c087e0804f0290e9886899e8a3cccb07c4ce088b flagged static
> UBI volumes as DEVFS_IS_CHARACTER_DEV.
> 
> A consequence of this flag is that commands like:
> 
> # cp /dev/nand0.ubi_volumes.ubi.my_static_vol file
> 
> will not work because the cp command will see a src file (the static UBI volume) with a size
> of -1 (FILE_SIZE_STREAM) and keep on reading from the volume until a flood of
> "UBI assert failed in ubi_eba_read_leb at 359" asserts comes out of the console.
> 
> I tried to comment out the flag assignment, just to see what happen:
> 
> int ubi_volume_cdev_add(struct ubi_device *ubi, struct ubi_volume *vol)
> {
> ...
> 	cdev->size = vol->used_bytes;
> 
> //	if (vol->vol_type == UBI_STATIC_VOLUME)
> //		cdev->flags = DEVFS_IS_CHARACTER_DEV;
> 
> 	cdev->dev = &vol->dev;
> ...
> 
> and then the cp command worked than as expected.
> 
> Could someone shortly confirm that the DEVFS_IS_CHARACTER_DEV flag for static UBI volumes
> is really needed (to avoid some other problems that my superficial test does not triggers) ?

the size of a static ubi volume device is equal to the image size you
flashed. When you create a new static ubi volume the size is 0, as it is
empty.
We need the chardev flag to be able to update the static ubi volume or
barebox will complain that there is not enough space.

Regards,
Teresa

> 
> giorgio
> 
> 
> Giorgio, iw3gtf@arcor.de
> 
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox



_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Aw: Re: why UBI static volumes are flagged as DEVFS_IS_CHARACTER_DEV

[iw3gtf]

 


----- Original Nachricht ----
Von:     Teresa Remmet <t.remmet@phytec.de>
An:      iw3gtf@arcor.de
Datum:   06.10.2016 10:17
Betreff: Re: why UBI static volumes are flagged as DEVFS_IS_CHARACTER_DEV

> Hello Giorgio,
> 
> Am Mittwoch, den 05.10.2016, 15:23 +0200 schrieb iw3gtf@arcor.de:
> > Hi,
> > 
> > I noticed that the commit id c087e0804f0290e9886899e8a3cccb07c4ce088b
> flagged static
> > UBI volumes as DEVFS_IS_CHARACTER_DEV.
> > 
> > A consequence of this flag is that commands like:
> > 
> > # cp /dev/nand0.ubi_volumes.ubi.my_static_vol file
> > 
> > will not work because the cp command will see a src file (the static UBI
> volume) with a size
> > of -1 (FILE_SIZE_STREAM) and keep on reading from the volume until a flood
> of
> > "UBI assert failed in ubi_eba_read_leb at 359" asserts comes out of the
> console.
> > 
> > I tried to comment out the flag assignment, just to see what happen:
> > 
> > int ubi_volume_cdev_add(struct ubi_device *ubi, struct ubi_volume *vol)
> > {
> > ...
> > 	cdev->size = vol->used_bytes;
> > 
> > //	if (vol->vol_type == UBI_STATIC_VOLUME)
> > //		cdev->flags = DEVFS_IS_CHARACTER_DEV;
> > 
> > 	cdev->dev = &vol->dev;
> > ...
> > 
> > and then the cp command worked than as expected.
> > 
> > Could someone shortly confirm that the DEVFS_IS_CHARACTER_DEV flag for
> static UBI volumes
> > is really needed (to avoid some other problems that my superficial test
> does not triggers) ?
> 
> the size of a static ubi volume device is equal to the image size you
> flashed. When you create a new static ubi volume the size is 0, as it is
> empty.
> We need the chardev flag to be able to update the static ubi volume or
> barebox will complain that there is not enough space.
> 
> Regards,
> Teresa
> 
Hi,

thanks for the answer, I knew there must be a reason for it.

Nonetheless it is a bit annoying not to be able to simply extract the content
of a static volume.

In my application the static volume contains a barebox bootloader image for an
imx25 cpu, I used to copy it to an mtd partition at the beginning of the nand flash
with the commands: erase /dev/nand0.barebox ; cp /dev/nand0.ubi_volumes... /dev/barebox
This does not work anymore now.

With a newer imx6 cpu I use the command barebox_update -y /dev/nand0.ubi_volumes...,
this works as expected.

Maybe I should write a new barebox_update command variant for the older cpu.

giorgio


Giorgio, iw3gtf@arcor.de

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: why UBI static volumes are flagged as DEVFS_IS_CHARACTER_DEV

[Sascha Hauer]

On Thu, Oct 06, 2016 at 10:17:27AM +0200, Teresa Remmet wrote:
> Hello Giorgio,
> 
> Am Mittwoch, den 05.10.2016, 15:23 +0200 schrieb iw3gtf@arcor.de:
> > Hi,
> > 
> > I noticed that the commit id c087e0804f0290e9886899e8a3cccb07c4ce088b flagged static
> > UBI volumes as DEVFS_IS_CHARACTER_DEV.
> > 
> > A consequence of this flag is that commands like:
> > 
> > # cp /dev/nand0.ubi_volumes.ubi.my_static_vol file
> > 
> > will not work because the cp command will see a src file (the static UBI volume) with a size
> > of -1 (FILE_SIZE_STREAM) and keep on reading from the volume until a flood of
> > "UBI assert failed in ubi_eba_read_leb at 359" asserts comes out of the console.
> > 
> > I tried to comment out the flag assignment, just to see what happen:
> > 
> > int ubi_volume_cdev_add(struct ubi_device *ubi, struct ubi_volume *vol)
> > {
> > ...
> > 	cdev->size = vol->used_bytes;
> > 
> > //	if (vol->vol_type == UBI_STATIC_VOLUME)
> > //		cdev->flags = DEVFS_IS_CHARACTER_DEV;
> > 
> > 	cdev->dev = &vol->dev;
> > ...
> > 
> > and then the cp command worked than as expected.
> > 
> > Could someone shortly confirm that the DEVFS_IS_CHARACTER_DEV flag for static UBI volumes
> > is really needed (to avoid some other problems that my superficial test does not triggers) ?
> 
> the size of a static ubi volume device is equal to the image size you
> flashed. When you create a new static ubi volume the size is 0, as it is
> empty.
> We need the chardev flag to be able to update the static ubi volume or
> barebox will complain that there is not enough space.

Then I think we need another solution for that. UBI volumes are clearly
not character devices, so we shouldn't set this flag to work around
other issues we have.

Currently devfs_truncate is implemented like:

static int devfs_truncate(struct device_d *dev, FILE *f, ulong size)
{
        if (f->fsdev->dev.num_resources < 1)
                return -ENOSPC;
        if (size > resource_size(&f->fsdev->dev.resource[0]))
                return -ENOSPC;
        return 0;
}

Maybe we need an optional cdev->ops->truncate() to let the UBI volumes be
able to overwrite this behaviour?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: why UBI static volumes are flagged as DEVFS_IS_CHARACTER_DEV

[Teresa Remmet]

Hello Sascha,

Am Freitag, den 07.10.2016, 09:27 +0200 schrieb Sascha Hauer:
> On Thu, Oct 06, 2016 at 10:17:27AM +0200, Teresa Remmet wrote:
> > Hello Giorgio,
> > 
> > Am Mittwoch, den 05.10.2016, 15:23 +0200 schrieb iw3gtf@arcor.de:
> > > Hi,
> > > 
> > > I noticed that the commit id c087e0804f0290e9886899e8a3cccb07c4ce088b flagged static
> > > UBI volumes as DEVFS_IS_CHARACTER_DEV.
> > > 
> > > A consequence of this flag is that commands like:
> > > 
> > > # cp /dev/nand0.ubi_volumes.ubi.my_static_vol file
> > > 
> > > will not work because the cp command will see a src file (the static UBI volume) with a size
> > > of -1 (FILE_SIZE_STREAM) and keep on reading from the volume until a flood of
> > > "UBI assert failed in ubi_eba_read_leb at 359" asserts comes out of the console.
> > > 
> > > I tried to comment out the flag assignment, just to see what happen:
> > > 
> > > int ubi_volume_cdev_add(struct ubi_device *ubi, struct ubi_volume *vol)
> > > {
> > > ...
> > > 	cdev->size = vol->used_bytes;
> > > 
> > > //	if (vol->vol_type == UBI_STATIC_VOLUME)
> > > //		cdev->flags = DEVFS_IS_CHARACTER_DEV;
> > > 
> > > 	cdev->dev = &vol->dev;
> > > ...
> > > 
> > > and then the cp command worked than as expected.
> > > 
> > > Could someone shortly confirm that the DEVFS_IS_CHARACTER_DEV flag for static UBI volumes
> > > is really needed (to avoid some other problems that my superficial test does not triggers) ?
> > 
> > the size of a static ubi volume device is equal to the image size you
> > flashed. When you create a new static ubi volume the size is 0, as it is
> > empty.
> > We need the chardev flag to be able to update the static ubi volume or
> > barebox will complain that there is not enough space.
> 
> Then I think we need another solution for that. UBI volumes are clearly
> not character devices, so we shouldn't set this flag to work around
> other issues we have.

Yes, you are write using the character dev flag is more a work around.
Which now brings up other problems like dumping the data back from
flash.

> 
> Currently devfs_truncate is implemented like:
> 
> static int devfs_truncate(struct device_d *dev, FILE *f, ulong size)
> {
>         if (f->fsdev->dev.num_resources < 1)
>                 return -ENOSPC;
>         if (size > resource_size(&f->fsdev->dev.resource[0]))
>                 return -ENOSPC;
>         return 0;
> }
> 
> Maybe we need an optional cdev->ops->truncate() to let the UBI volumes be
> able to overwrite this behaviour?

Truncate sounds like a better way. But UBI itself is not a filesystem.
So I do not see a good place to overwrite it on a first look.

I will try to look into this deeper next week. 

Regards,
Teresa

> 
> Sascha
> 



_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox