swupdate "uboot" handler only handles MTD devices?

[Bjørn Forsman]

Hi Stefano, all,

I just started testing swupdate. It looks good, and there is lots of
useful documentation. Thanks for sharing!

But I have an issue :-) Please read on.

My U-Boot and its environment is on an SD-card. I have this in
/etc/fw_env.config:

/dev/mmcblk2 0x60000 0x2000

fw_setenv/printenv works fine with this (block) device. But the
"uboot" handler in swupdate fails. It seems to expect an MTD device
("Cannot get MTD information: Invalid argument").

But worse, even though the "uboot" handler fails to update the
environment, swupdate says the overall update is successful and exits
with status 0. Isn't it supposed to be a transaction (i.e. all or
nothing), or do I misunderstand something regarding how the various
handlers interact?

You can see the full log from swupdate after my signature.

--
- Bjørn


# /tmp/swupdate -v --select stable,main -i /tmp/my-software_0.1.swu
Swupdate v2015.07.0

Licensed under GPLv2. See source distribution for detailed copyright notices.

Registered handlers:
raw
rawfile
shellscript
uboot
software set: stable mode: main
[NOTIFY] : SWUPDATE running : [extract_sw_description] : Found file:
filename sw-description
size 732
checksum 0x97e9 VERIFIED

Version 0.1
[NOTIFY] : SWUPDATE running : [parse_images] : Found Image:
output/images/rootfs.ext2 in device : /dev/mmcblk2p1 for handler raw

[NOTIFY] : SWUPDATE running : [parse_uboot] : U-Boot var: mmcpart = 1

[NOTIFY] : SWUPDATE running : [cpio_scan] : Found file:
filename output/images/rootfs.ext2
size 17581056
REQUIRED

[NOTIFY] : SWUPDATE running : [install_images] : Found installer for
stream output/images/rootfs.ext2 raw
[NOTIFY] : SWUPDATE running : [update_uboot_env] : Updating U-boot environment
Cannot get MTD information: Invalid argument
Error: environment not initialized
ERROR corelib/installer.c : update_uboot_env : 95 : Error updating
U-Boot environment
[NOTIFY] : SWUPDATE failed [0] ERROR corelib/installer.c :
update_uboot_env : 95 : Error updating U-Boot environment
Software updated successfully
Please reboot the device to start the new software
[NOTIFY] : SWUPDATE successful !
# echo $?
0

[Stefano Babic]

Hi Bjørn,

On 24/10/2015 16:01, Bjørn Forsman wrote:
> Hi Stefano, all,
>
> I just started testing swupdate. It looks good, and there is lots of
> useful documentation. Thanks for sharing!
>
> But I have an issue :-) Please read on.
>
> My U-Boot and its environment is on an SD-card. I have this in
> /etc/fw_env.config:
>
> /dev/mmcblk2 0x60000 0x2000
>
> fw_setenv/printenv works fine with this (block) device. But the
> "uboot" handler in swupdate fails. It seems to expect an MTD device
> ("Cannot get MTD information: Invalid argument").

Part of the u-boot handler is the fwenv.c file taken from the U-Boot
project, but of course not the current. Some other improvements are then
lost.

I think the best thing is to make that u-boot exports a library for the
environment, and swupdate uses that library.

>
> But worse, even though the "uboot" handler fails to update the
> environment, swupdate says the overall update is successful and exits
> with status 0.

This is a bug.

> Isn't it supposed to be a transaction (i.e. all or
> nothing),

Exactly.

It looks like that the error is not coming back to the caller, and the
installer does not know that the handler failed. It must be fixed.

Best regards,
Stefano Babic

--
=====================================================================
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=====================================================================

[Otavio Salvador]

On Sat, Oct 24, 2015 at 3:12 PM, Stefano Babic <sba...@denx.de> wrote:
> I think the best thing is to make that u-boot exports a library for the
> environment, and swupdate uses that library.

This would be indeed great. Even nicer if it could be LGPL so people
could reuse it in their commercial applications.

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750

[Stefano Babic]

Hi Otavio,

On 24/10/2015 19:15, Otavio Salvador wrote:
> On Sat, Oct 24, 2015 at 3:12 PM, Stefano Babic <sba...@denx.de> wrote:
>> I think the best thing is to make that u-boot exports a library for the
>> environment, and swupdate uses that library.
>
> This would be indeed great. Even nicer if it could be LGPL so people
> could reuse it in their commercial applications.

This could be discussed on U-Boot's ML, but I am afraid that code will
remain GPL.

Best regards,
Stefano

[Bjørn Forsman]

On 24 October 2015 at 19:12, Stefano Babic <sba...@denx.de> wrote:
> Hi Bjørn,
>
> On 24/10/2015 16:01, Bjørn Forsman wrote:
>> Hi Stefano, all,
>>
>> I just started testing swupdate. It looks good, and there is lots of
>> useful documentation. Thanks for sharing!
>>
>> But I have an issue :-) Please read on.
>>
>> My U-Boot and its environment is on an SD-card. I have this in
>> /etc/fw_env.config:
>>
>> /dev/mmcblk2 0x60000 0x2000
>>
>> fw_setenv/printenv works fine with this (block) device. But the
>> "uboot" handler in swupdate fails. It seems to expect an MTD device
>> ("Cannot get MTD information: Invalid argument").
>
> Part of the u-boot handler is the fwenv.c file taken from the U-Boot
> project, but of course not the current. Some other improvements are then
> lost.
>
> I think the best thing is to make that u-boot exports a library for the
> environment, and swupdate uses that library.

What about just re-syncing the file? Isn't that much simpler? I guess
the file doesn't change that often...?

Shelling out to fw_setenv is maybe also an option. But it's probably
not a good idea for a project like swupdate to rely on that
technique(?), because it's not possible to know if fw_setenv is
available on target until you try to do the update.

- Bjørn

[Stefano Babic]

Hi Bjørn,

On 24/10/2015 19:55, Bjørn Forsman wrote:

>>
>> I think the best thing is to make that u-boot exports a library for the
>> environment, and swupdate uses that library.
>
> What about just re-syncing the file? Isn't that much simpler?

I have already a patch, I can push it and you can check it. Yes it is
simpler, but it is not a long term solution.

> I guess
> the file doesn't change that often...?

The history proofed that it was changed and swupdate is then out of sync
with u-boot.

> Shelling out to fw_setenv is maybe also an option. But it's probably
> not a good idea for a project like swupdate to rely on that
> technique(?),

Yes, I would like to avoid calling system/exec and friends.

> because it's not possible to know if fw_setenv is
> available on target until you try to do the update.

Correct

[Bjørn Forsman]

Hi Stefano,

On 24 October 2015 at 22:08, Stefano Babic <sba...@denx.de> wrote:
> I have already a patch, I can push it and you can check it.

It works! Thanks!

With swupdate on master branch I have working U-Boot environment
manipulation on SD-card (block device).

- Bjørn