Am Dienstag, den 16.04.2019, 21:22 +0200 schrieb Enrico Jörns:
> Hi Steffen,
> 
> Am 16.04.19 um 16:10 schrieb Ulrich Ölmann:
> > 
> > On Tue, Apr 16 2019 at 15:51 +0200, Ulrich Ölmann <u.oelmann@pengut
> > ronix.de> wrote:
> > > 
> > > Hi Steffen,
> > > 
> > > On Tue, Apr 16 2019 at 14:53 +0200, Steffen Kothe <steffen.kothe.
> > > gc1...@googlemail.com> wrote:
> > > > 
> > > > I try to update the U-Boot Loader on two different partitions.
> > > > 
> > > > /dev/mmcblk3boot0
> > > > /dev/mmcblk3boot1
> > > > 
> > > > A restriction on our i.Mx6 platform is location of the u-boot
> > > > entry on
> > > > the partition.
> > > > 
> > > > Offset: 1024 Byte Address: 0x400
> > > > 
> > > > So a raw copy would start at address 0x00, but we have to start
> > > > 0x400
> > > > for the entry point.
> which platform (i.mx6 variant) is that exactly? Where does the
> restriction come from? I would have expected that all i.mx6 platforms
> can handle eMMC boot partitions the same way.

Platform is the i.Mx6 Dual Light. 
The restriction came from the datasheet, that in case of use the eMMC
on an i.Mx6, the offset position for the u-boot on the boot partition
(eMMC) has to be 1KByte ( 0x400). This restriction depends on the used
memory technology. 
Other offsets are possible for different memory technologys! Refer for
more information to NXP i.MX6 Reference Manual
"Section 8.6.1 Image Vector Table and Boot Data"

RAUC handles the eMMC correctly, so I think, I just have to modify the 
offset address properly. If I do the update manually with "dd" ,
following command line is used

dd if=u-boot.imx of=/dev/mmcblk3boot0 bs=512 seek=2

If you would transform this command line to the RAUC behaviour, the
"dd" command would looks like this.

dd if=u-boot.imx of=/dev/mmcblk3boot0 bs=512 seek=0 

> > 
> > > 
> > > > 
> > > > Does rauc provides any options to customize the startaddress
> > > > for a raw
> > > > copy/install of a binary file (u-boot binary)?
> > > > 
> > > > I have took a look into the source code, but found out, that
> > > > there is
> > > > no option to customize the default offset address for a write
> > > > on a
> > > > partition.
> > > > 
> > > > 
> > > > Could you provide some help in this case?
> > > take a look at hooks, especially the subsubsection "Install
> > > Hook":
> > > https://rauc.readthedocs.io/en/latest/using.html#slot-hooks .
> > ... and use your own logic for updating the bootloader (forgot to
> > mention that): write a script that switches the eMMC's bootloader
> > partition from read-only to read-write and use the mmc-utils (see
> > [1] &
> > [2]) to atomically switch the eMMC's partition once it was written.
> This is exactly what RAUC provides out-of-the box. Thus I would like
> to
> understand why it is not working in that case. I assume you are doing
> eMMC boot partitions update to gain atomicity, right?
> 
> Did you notice the eMMC boot partition atomic update feature of RAUC?
> 
> https://rauc.readthedocs.io/en/latest/advanced.html#update-emmc-boot-
> partitions
> 
> It basically performs the steps Ulrich described above.
> 
> And please consider subscribing to the mailing list, because posts by
> non-members are blocked by default (and you won't receive messages
> that
> are replied to the list only... ;) ).
> 
> Thanks and best regards
> 
> Enrico

RAUC provides the uboot update out-of-the-box. I already use this
functions and found out, that the binary image, created by an yocto
recipe is included correctly but is not written to the correct position
on the eMMC itself.

I want to gain atomicity, true.

The code  does not provide  any option, to manual adjust the offset
write address for the binary uboot blob to the eMMC. 

Also the switching of boot paritions works correctly after the kernel
patch is applied. 

There is no BUG or something in the code,  its just a very specific
customization.

My ideas:

- Patch the code and extend the code for an offset option
- Use hooks for a post-install process, which copy the raw u-boot
binary from 0x0000 to 0x400 address after the raw install on the block
device (mmcblk3boot0 / mmcblk3boot1)


I would like to support you in this case with a code contribution. 
The code seems to be easy and well adjustable for this use case. 



_______________________________________________
RAUC mailing list

Reply via email to