From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6651890010995818496 X-Received: by 2002:a2e:482:: with SMTP id a2-v6mr337044ljf.28.1548763832275; Tue, 29 Jan 2019 04:10:32 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:814b:: with SMTP id t11-v6ls2620778ljg.6.gmail; Tue, 29 Jan 2019 04:10:31 -0800 (PST) X-Google-Smtp-Source: AHgI3IaYM6hLpMWNlruNAMGmTgmltEtLth3sLZPR5FHnNYFgtOeKaGg9ELmZmiL46vWjDCAyUauS X-Received: by 2002:a2e:8842:: with SMTP id z2-v6mr329023ljj.29.1548763831734; Tue, 29 Jan 2019 04:10:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548763831; cv=none; d=google.com; s=arc-20160816; b=cec6uWBzDYro0tu7w0jLvf00cBk14vGIx/xjaCu8FntfqR8zJ2xua0tg44Wrz16Oiv Z70m+ky20ZwhBwy1GjQ/KUk5paBMKluMnntkgfrRIvcT3YBdS7qDBpBNv6iAZN9t9iA2 P97QnZnPnS0unL1mzuS1kh0r82H5Iu4lXWmUwuT3nd1D4+Y1+x5h5EgMM2Ylzf+BrPf1 8tWIDKW8vpe0ohbfCCh9tq2MvKocgMTWWToUohj+FHc6XYjCeTKVW3aNaGbx3MbnMusb svaEZnuAA9a138vqI3VSTbajOiMCN07VGlvsDdTmeGX68Vef1WjQWH2iOi9dW+9n6EdF PHYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from; bh=dERgrfMc1w/LMunVftYSmaxH59Qof9dzDDByFphbgIs=; b=lcKI1zWaYRdbFcIkMb+1EBMvDuywWUpCjVEDE1eKPd7ZCfnhKLeSpa9oB88o4Qnb4t /zfAWHSQkWfMCytCDcVur8kTsDXJpJa9XH6Bw9XBe4oa726cMrG7KmR3Aynsky2Z1NQf Q08tGUFDR6LiixFOD8adUSLflXDPzddxBRCcS4bPLb9Vu9/mk2Z7Ioql+jkC46+Fvgqq LpgacxxxceDIrRfgnthKLqNtm42tC+fiXue0X2lblTZPDK9dDmSqme0A4FZZt6GbmC2V 29PeRjsPuS6KW9kbLKHNMKzRTjThFTXuoP06Qs4XtNYZv6sMSrwgb25CShJbC0X8sfjw I/Yw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Return-Path: Received: from lizzard.sbs.de (lizzard.sbs.de. [194.138.37.39]) by gmr-mx.google.com with ESMTPS id y18si835740lfe.3.2019.01.29.04.10.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 04:10:31 -0800 (PST) Received-SPF: pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.39 as permitted sender) client-ip=194.138.37.39; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of claudius.heine.ext@siemens.com designates 194.138.37.39 as permitted sender) smtp.mailfrom=claudius.heine.ext@siemens.com Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id x0TCAUte017938 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Jan 2019 13:10:30 +0100 Received: from ring.ppmd.siemens.net (linux-ses-ext02.ppmd.siemens.net [139.25.69.181]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTP id x0TCAThV021516; Tue, 29 Jan 2019 13:10:29 +0100 From: claudius.heine.ext@siemens.com To: isar-users@googlegroups.com Cc: Claudius Heine Subject: [RFC PATCH 0/2] Implementation of UBI Date: Tue, 29 Jan 2019 13:10:18 +0100 Message-Id: <20190129121020.30845-1-claudius.heine.ext@siemens.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-TUID: jpCgGAReZ8ek From: Claudius Heine Hi, I send this patch as an RFC, because I would like to have feedback about it first, before finalizing it with documentation and more. Here a few remarks about what I would like to have feedback on. # meta/classes: added ubi-img class I would like to know what you think about the template system employed here. For example usage see the second patch. I plan to add some documentation about this into the user manual as well. # meta-isar: added qemusabrelite example to demonstrate UBI use My primary goal here is to provide some reference and ci test case for the UBI image creation. Not a real goal for me is to provide a working BSP for sabrelite running on qemu, but that would be nice to have. Background for this is that qemu supports a `--mtdblock` parameter for sabrelite, so it might be possible to use the resulting ubi image to boot a system using this. The problem is however that this doesn't seem to work. I am not sure if what ubinize outputs can even be directly used for this parameter or how to generate a valid mtd file to be used for that. Normally ubiformat is used to write ubi images to mtd partitions on real hardware, so I guess some emulation needs to happen in order to write correct mtd image files. Another issue is that in order to boot from NAND directy in i.MX6 platforms, the NAND has to contain some propritary infomation that is written by the kobs [1]. So for me the efford needed to provide a working qemu or hardware sabrelite support seems a bit to high for this patchset. So instead I think I will just rename the qemusabrelite stuff to nand-ubi-demo to provide just some reference about how to use this instead of falsely claim support for some hardware. IMO testing if the image can be created is more of a goal here than testing if it can be booted as well. Are the other possiblities I don't see here? Thanks, Claudius [1] https://github.com/NXPmicro/imx-kobs Claudius Heine (2): meta/classes: added ubi-img class meta-isar: added qemusabrelite example to demonstrate UBI use meta-isar/classes/ubi-ubifs-img.bbclass | 9 +++ meta-isar/conf/machine/qemusabrelite.conf | 11 +++ .../multiconfig/qemusabrelite-buster.conf | 13 ++++ .../images/files/ubinize.cfg.tmpl | 35 +++++++++ .../recipes-core/images/isar-image-ubi.bb | 49 +++++++++++++ meta/classes/ubi-img.bbclass | 71 +++++++++++++++++++ 6 files changed, 188 insertions(+) create mode 100644 meta-isar/classes/ubi-ubifs-img.bbclass create mode 100644 meta-isar/conf/machine/qemusabrelite.conf create mode 100644 meta-isar/conf/multiconfig/qemusabrelite-buster.conf create mode 100644 meta-isar/recipes-core/images/files/ubinize.cfg.tmpl create mode 100644 meta-isar/recipes-core/images/isar-image-ubi.bb create mode 100644 meta/classes/ubi-img.bbclass -- 2.20.1