Hi Mike, The approach you describe is really interesting. Especially the part where the "flash the NAND" is made dependant on the nand image. Though this means technicians in the field should flash a new sd card for every new release instead of just scp-ipping the files to the live (old) SD image. Thanks for sharing!
Il mer 24 lug 2024, 13:09 Mike Looijmans <mike.looijm...@topic.nl> ha scritto: > We usually have one machine and let the bootloader figure it out. > > If there are bootswitches to boot from NAND vs SD card, there's usually a > way > to get at those switches through reading some register. Set U-boot's > "boot_targets" based on that, so it tries to boot from that media first. > > Another quick way is to just try SD first then revert to NAND boot. The SD > check is usually very quick because of the card-detect. > > You can create the same image for SD and NAND by setting IMAGE_FSTYPES (to > ubifs and ext4 I'd guess). Handy to be able to run directly from SD > during > development. > > To create the "flash the NAND" image, just create a recipe that RDEPENDS > on > the production image. Add a dependency on "image_complete" and then you > can > just fetch the image from the deploy directory and pack it in. > > So no new machine, just a new image. > > > > > Met vriendelijke groet / kind regards, > > Mike Looijmans > System Expert > > > TOPIC Embedded Products B.V. > Materiaalweg 4, 5681 RJ Best > The Netherlands > > T: +31 (0) 499 33 69 69 > E: mike.looijm...@topic.nl > W: www.topic.nl > > Please consider the environment before printing this e-mail > On 21-07-2024 03:39, ppanaccio78 via lists.yoctoproject.org wrote: > > Hello community, > > I have a project where I work with two different image recipes. One is > meant > > for production and targets NAND, another one for SD CARD. The second > one is > > basically a tiny image that contains scripts to flash the NAND with the > > production image. > > My question is: what's the recommended way to manage these two images in > terms > > of MACHINE and UBOOT_CONFIG? > > How I did till now: just changed the weak default for UBOOT_CONFIG found > in > > the machine.conf depending on the image I was baking. This does not look > good > > to me because it clutters the deploy dir for the given machine with > unrelated > > build artifacts. > > A better alternative comes to my mind: the physical board is just one, > so it > > makes sense that both images should refer to the same MACHINE variable. > The > > machine.conf provides a weak assignment for UBOOT_CONFIG and image > recipes > > should change its value depending on their needs. > > But I suspect that since the data store for each recipe (comprised image > > recipes) is a local coly, such assignment does not work. > > Then only two bins are left: mess up the deploy dir as I did till now OR > use > > two different machines with different weak defaults, which I think is > somewhat > > wrong as the hardware is one. > > Can you help me sort this out? > > Thanks > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63567): https://lists.yoctoproject.org/g/yocto/message/63567 Mute This Topic: https://lists.yoctoproject.org/mt/107461549/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
