iMX8dx kobs-ng writing two boot streams

vmuthusu · ‎02-25-2019

Hi
We are using a custom board based on imx8dxp with Nand Flash. we have created a binary using the mkimage_imx8 with (SECO,SCFW,U-Boot and M4 binary).
When we flash this binary using the uuu tool and the command
FBK: ucmd kobs-ng init -v --chip_0_device_path=/dev/mtd0 /tmp/flash.bin
the mtd0 partition size is 0x00500000 (5MB)
the kobs-ng is writing the same binary into two locations.
Output of kobs-ng for your reference.
Firmware: image #0 @ 0x80000 size 0xe5000 - available 0x240000
Firmware: image #1 @ 0x2c0000 size 0xe5000 - available 0x240000.
can you please let us know why kobs-ng is writing it twice?

For iMX8 we have the Primary and Seconday Image container sets to boot.
The above flash.bin corresponds to one Image container set which comes immediately after the FCB and DBBT.
For this single image container set itself kobs-ng duplicates the binary.

Do we need to use kobs-ng to flash the other image container set? If we use kobs-ng won't the FCB and DBBT gets overwritten?

If we don't have to use kobs-ng for the other image container set, do we use nand_write() to flash the other image container set. If so what happens if we get a nand bad block detection during booting from this image container set?
Do we really need to have the kobs-ng flashing the binary in 2 different locations for iMX8 based processors?
Is it possible to configure this some way?

Thanks
V.Muthusubramanian

igorpadykov · ‎02-26-2019

Hi Muthusubramanian

>For this single image container set itself kobs-ng duplicates the binary.

this may be related to primary and secondary firmware which are

used for nand boot, as described in sect.5.8.1.2 NAND flash boot flow and Boot Control Blocks (BCB)

i.MX8DQXP Reference Manual
https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf

>Do we need to use kobs-ng to flash the other image container set?

based on suggestions provided on below link, the same procedure is used for generating

primary and secondary containers

Boot Image Layout in IMX8DQXP

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

vmuthusu · ‎02-26-2019

>this may be related to primary and secondary firmware which are

used for nand boot, as described in sect.5.8.1.2 NAND flash boot flow and Boot Control Blocks (BCB)

i.MX8DQXP Reference Manual

If this the case the secondary firmware should get written at the Image container set 1 offset address specified as fuse location. But kobs-ng doesn't know this address and it is not writing into that address as well.

>Do we need to use kobs-ng to flash the other image container set?

>seems not, one can follow suggestions provided on

If you look at the answer from Suresh on the "Boot image layout in imX8DQXP" question

Primary and secondary image container set are two separate binaries, same set of commands are used to generate both these binaries.

which indicates the primary and secondary image container set are two separate binaries, whereas kobs-ng accept one binary and gets written twice.

Thanks

V.Muthusubramanian

igorpadykov · ‎02-26-2019

one can check kobs-ng sources to know how it writes nand image structure

cafatgithub/imx-kobs - i.MX tool for flashing NAND boot to nand flash

Best regards
igor

vmuthusu · ‎02-26-2019

Hi Igor

Thanks for your reply.

I have already looked into the imx-kobs source and understood that it is writing two boot streams.

But what I don't know is

1. Why should it write twice. Is there any rationale behind this.

What I assume is if we some bad blocks in NAND on the firmware1 then the Firmware2 will be used.This is OK for iMX6 based processors where we don't have the primary image container set and secondary image container set boot flows. But for iMX8 since we have this boot flow does kobs-ng still needs to write one image container twice?

2. For writing the other image container set to NAND do we have to use kobs-ng again? If we use kobs-ng again won't the FCB and DBBT gets written again?

3. If we don't use kobs-ng to write the other image container set how the bad blocks will be managed.

Thanks

V.Muthusubramanian

igorpadykov · ‎02-26-2019

Hi Muthusubramanian

it writes twice as described in Reference Manual, both

primary and secondary firmware are written to nand. So

when primary image become corrupted, secondary is used.

Please reread sect.5.8.1.2 NAND flash boot flow and Boot Control Blocks (BCB)

i.MX8DQXP Reference Manual
https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf

>For writing the other image container set to NAND do we have to use kobs-ng again?

>If we use kobs-ng again won't the FCB and DBBT gets written again?

based on suggestions provided on below link, the same procedure is used for generating

primary and secondary containers

Boot Image Layout in IMX8DQXP

also from sect.5.9.2 Secondary Boot Container Set i.MX8DQXP Reference Manual:
"The Secondary Boot Container Set is a copy of the Primary Container Set. ROM will
always try to load the Primary Container Set first and if the Primary Container Set fails
SECO authorization or other failures occur (e.g. read error), ROM will then attempt to
load the Secondary Container Set."

Best regards
igor

vmuthusu · ‎02-26-2019

Hi Igor

From section 5.8.1.3 - Firmware configuration block

you can find

kobs-ng updates the FCB data struct and hence updates the above data as well based on the stride size.

As per your answer if it is secondary firmware corresponds to Image container set 1. Then as per FuseMap section Table 7.1

The Firmware2_startingPage written to FCB should have the offset corresponding to this fuse information. But kobs-ng has no idea about this and it calculates the Firmware2_startingPage based on stride size.

Also as per 5.9.3 Imager Container Set selection bullet point 3

So i feel what kobs-ng write as a Firmware2 is not same as Secondary Image Container set.

Thanks

V.Muthusubramanian

igorpadykov · ‎02-26-2019

Hi Muthusubramanian

>it is secondary firmware corresponds to Image container set 1

I am afraid it is confusion. "Firmware1_startingPage" does not relate to

Image Container Set and its fuse.

Best regards
igor