14:01 <austriancoder> NishanthMenon: Do you know in what partition type (user, RPMB, ..) I need to copy U-Boot etc for emmc boot on am642?

14:03 <NishanthMenon> aaah -> there are atleast two ways.

14:17 <austriancoder> okay..

14:21 <NishanthMenon> austriancoder: https://www.pengutronix.de/media/blog/2020/2020-10-15_anpassen-einer-emmc/overview-eMMC.png as an example

14:21 <NishanthMenon> option 1: tiboot3.bin in boot0. sysfw.itb... etc in boot0 partition : https://e2e.ti.com/support/processors-group/processors/f/processors-forum/950948/faq-tda4vm-how-to-modify-offsets-for-boot-binaries-in-emmc -> the sizes offsets will depend on emmc sector sizes and 4MB or 8MB boot partition.

14:22 <NishanthMenon> option 1 drove me nuts on ai64.. because features in u-boot kept changing..

14:23 <NishanthMenon> esp u-boot.img etc.. and given the fact that tfa and optee was stored as well in boot0 partition, i could see it scale..

14:24 <NishanthMenon> so, option 2 in ai64: https://github.com/beagleboard/u-boot/commit/84c57f48937093d9624f28a127611dfcb57ca902 -> which this change, uda has /boot partition like sd card does.. with that , only tiboot3.bin is written to emmc boot0 partition. so the update cycle becomes trivial https://github.com/nmenon/beagle-ai64-boot-build/blob/main/lnx-write-boot-emmc.sh -> i could not scale the a72 /a53 binaries to what ever it desires

14:25 <NishanthMenon> negatives of option2: it is fs access for R5 SPL.. so it is naturally slower than purely raw emmc access if all binaries are in boot0.

14:25 <NishanthMenon> there is an argument for option 3: -> folks are suggesting using ospi as a jump point before jumping over to uda in emmc.

14:26 <NishanthMenon> that allows for emmc uda images to be completely EBBR compatible..

14:27 <NishanthMenon> austriancoder: funny you should ask.. a few weeks back, I had gone nuts trying to figure out why ai64 boot regressed... wrote a TI internal training slide using that as a case study ;)

14:28 <austriancoder> NishanthMenon: we want to get rid of the spi as boot source and move everything to emmc ..

14:29 <NishanthMenon> austriancoder: gotcha.. well.. it depends on scalability vs nuanced boot time optimization. standard sdk supports "optimized boot" configuration.. for me, at least with ai64, it was'nt allowing flexibility.. i would like 20MB optee images and multi-mb u-boot which is feature rich..

14:30 <NishanthMenon> austriancoder: curious why to get rid of spi - BoM cost?

14:32 <austriancoder> NishanthMenon: yeah.. it is all about the money

14:32 <NishanthMenon> austriancoder: what else is new ;)

14:33 <austriancoder> NishanthMenon: thanks for your links etc. .. this will help me a lot!

14:34 <NishanthMenon> austriancoder: cool.. i wish there was a simpler - hey here is a single soln.. works perfectly and optimally and scales with feature changes for ever.. unfortunately, as with everything.. tradeoff choices :(

14:35 <austriancoder> the next thing that will come .. boot time optimization :/

14:37 <NishanthMenon> yup..

16:49 <vigneshr> One of the arguments for choosing option 1: booting from raw boot0 partition is quicker for ROM/SPL as there is not much of initialization required.. It's supposed to be faster than raw access to UDA

21:41 <NishanthMenon> aah... thanks vigneshr ... option 1 for performance, option 2 for flexibility, and option 3 for potentially ebbr