Update SPL with customized command instead of raw handler

[free...@gmail.com]

Hi All,

We are using i.mx6 with NAND flash and i.mx6 requires specific structure while writing SPL into /dev/mtd0, which means we can't use the raw handler for this purpose. I used the shell script as a workaround to flash the SPL with a NXP tool in preinstall. And we use the command line "-c" option to validate the .swu before passing it to the swupdate daemon. This works fine until I updated swupdate from 2020.05 to 2022.05 which implements the check feature with dryrun. I changed the code to do a dryrun via IPC to the swupdate daemon instead and got an issue that the SPL was always written to /dev/mtd0 (all other images are using dummy handler) while doing the dryrun. Is there an existing handler that supports customized command and work with dryrun? If not, would it be a good idea to implement one? Thanks.

BR,

Ben Guan

[Stefano Babic]

Hi Ben,

On 21.07.22 04:11, free...@gmail.com wrote:
> Hi All,
> We are using i.mx6 with NAND flash and i.mx6 requires specific structure
> while writing SPL into /dev/mtd0,

Sure, FCB and DBBT must be created.

> which means we can't use the raw
> handler for this purpose.

You can't, of course.

> I used the shell script as a workaround to
> flash the SPL with a NXP tool in preinstall. And we use the command line
> "-c" option to validate the .swu before passing it to the swupdate
> daemon. This works fine until I updated swupdate from 2020.05 to 2022.05
> which implements the check feature with dryrun. I changed the code to do
> a dryrun via IPC to the swupdate daemon instead and got an issue that
> the SPL was always written to /dev/mtd0 (all other images are using
> dummy handler) while doing the dryrun. Is there an existing handler that
> supports customized command and work with dryrun?

Let's say this is not the preferred and right way. The right way is to
add a "fcb" handler that just take the SPL image and writes the
bootloader into the NAND, writing the structure according to NXP. This
was also done in U-Boot, and it could be done in SWUpdate as well. A big
advantage is that you can reuse SWUpdate's facilities like automatic
versioning, and SWUpdate itself will update SPL just in case of mismatch
with the running one.

> If not, would it be a
> good idea to implement one?

No - this is a hack to circumvent one issue. The right way to do is to
add a specific handler for NXP's FCB structure. A similar approach was
done in the past for TI (OMAP 1/2) processor with the hamming handler.

Using the preinstall script, apart possible security issues, you disable
the possibility of streaming the SWU, and this is a no way for many
projects.

Best regards,
Stefano Babic

Thanks.
>
> BR,
> Ben Guan
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/swupdate/21707a68-23d4-493d-a2db-a7031966eefbn%40googlegroups.com
> <https://groups.google.com/d/msgid/swupdate/21707a68-23d4-493d-a2db-a7031966eefbn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[ayoub...@googlemail.com]

you can also use a lua handler:

require ("swupdate")

function kobs-ng_lua(image)

    local part_erase_cmd, part_write_cmd, err
    part_erase_cmd = string.format("flash_erase %s 0 0", image.device)
    part_write_cmd = string.format("kobs-ng init -x %s --search_exponent=1", image.filename)

    err = os.execute(part_erase_cmd)
    if not err then
        swupdate.error(string.format("Error: %s return %s!", part_erase_cmd, tostring(err)))
        return 1
    end

    err = os.execute(part_write_cmd)
    if not err then
        swupdate.error(string.format("Error: %s return %s!", part_write_cmd, tostring(err)))
        return 1
    end

    return 0
end

swupdate.register_handler("kobs-ng", kobs-ng_lua, swupdate.HANDLER_MASK.IMAGE_HANDLER)

[free...@gmail.com]

Looks like what I need. Will give it a try, thanks.

[James Hilliard]

So I tweaked this a bit trying to get it to work:
require ("swupdate")

function kobs_ng_lua(image)

local spl_img_path, part_erase_cmd, part_write_cmd, err, msg
spl_img_path = string.format("%s/%s", "/tmp", tostring(image.filename))

part_erase_cmd = string.format("flash_erase %s 0 0", image.device)
part_write_cmd = string.format("kobs-ng init

--chip_0_device_path=%s -x %s --search_exponent=1", image.device,
spl_img_path)

err, msg = image:copy2file(spl_img_path)
if err ~= 0 then
swupdate.error(string.format("Failed to copy image %s to %s:
%s!", tostring(image.filename), spl_img_path, msg))

return 1
end

err = os.execute(part_erase_cmd)
if not err then
swupdate.error(string.format("Error: %s return %s!",
part_erase_cmd, tostring(err)))
return 1
end

err = os.execute(part_write_cmd)
if not err then
swupdate.error(string.format("Error: %s return %s!",
part_write_cmd, tostring(err)))
return 1
end

return 0
end

swupdate.register_handler("kobs-ng", kobs_ng_lua,
swupdate.HANDLER_MASK.IMAGE_HANDLER)

However I'm getting a sha256 mismatch error somehow:
[TRACE] : SWUPDATE running : [install_single_image] : Found installer
for stream SPL kobs-ng
[ERROR] : SWUPDATE failed [0] ERROR cpio_utils.c : __swupdate_copy :
637 : HASH mismatch :
aa57483e484f97b0e37fa7038eee98cfb09875e68f0000bebfed130140ead238 <-->
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
[ERROR] : SWUPDATE failed [0] ERROR lua_interface.c : notify_helper :
730 : Failed to copy image SPL to /tmp/SPL: Success!
[TRACE] : SWUPDATE running : [l_handler_wrapper] : [Lua handler] returned: 1
[TRACE] : SWUPDATE running : [install_single_image] : Installer for
kobs-ng not successful !

When used with this image node:{
filename = "SPL";
device = "/dev/mtd0";
type = "kobs-ng";
sha256 = "@SPL";
},

Anyone have any idea how I would be hitting a sha256 error like this?
I'm pretty sure the sha256 is correct as it validates correctly with
the flash handler.

> To unsubscribe from this group and stop receiving emails from it, send an email to swupdate+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/swupdate/6e333956-409a-4726-854b-e41b9e53469dn%40googlegroups.com.

[James Hilliard]

So it looks like the file being hashed/written is for some reason empty, the
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 hash
is the hash for an empty file, I commented out the hash comparison
exception code
and confirmed that the actual file written is indeed empty as well.

[Stefano Babic]

Hi James,

mmhhh....it is like if the output file is the same that the input, and
file is immediately truncated.

What about to try to move your copy, just to verify this ? You have:

spl_img_path = string.format("%s/%s%s", "/tmp",
tostring(image.filename), ".mycopy")

Regards,
Stefano

[James Hilliard]

Well it's not empty here at least from the looks of it:
[TRACE] : SWUPDATE running : [extract_files] : Found file
[TRACE] : SWUPDATE running : [extract_files] : filename SPL
[TRACE] : SWUPDATE running : [extract_files] : size 60416 required

>
> What about to try to move your copy, just to verify this ? You have:
>
> spl_img_path = string.format("%s/%s%s", "/tmp",
> tostring(image.filename), ".mycopy")
>
> Regards,
> Stefano

I verified by calling sha256sum and ls -l from the command line after the
image:copy2file operation.

sha256sum matches empty hash and ls -l shows filesize of 0.

[James Hilliard]

On Tue, Sep 12, 2023 at 7:08 AM James Hilliard

Hmm, yeah that does look to be the issue:
fe3113e3854314ddbb9d55b718e876ef94c6aeb9fde699e3dd2f7729e2d86a44
/tmp/SPL.mycopy
-rw------- 1 root root 60416 Sep 12 13:29 /tmp/SPL.mycopy