* [PATCH 1/7] scripts: allow lines longer than 80 cols with printf() in checkpatch
2013-05-03 16:51 [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Thomas Petazzoni
@ 2013-05-03 16:51 ` Thomas Petazzoni
2013-05-06 7:23 ` Sascha Hauer
2013-05-03 16:51 ` [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images Thomas Petazzoni
` (8 subsequent siblings)
9 siblings, 1 reply; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-03 16:51 UTC (permalink / raw)
To: barebox; +Cc: Lior Amsalem, Willy Tarreau, Ezequiel Garcia
The checkpatch.pl script is also used to validate user-space code in
the scripts/ directory, so it should allow printf() lines to be longer
than 80 columns.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 0d94f98..e80926f 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -209,7 +209,7 @@ our $typeTypedefs = qr{(?x:
)};
our $logFunctions = qr{(?x:
- printk|
+ printk|printf|
pr_(debug|dbg|vdbg|devel|info|warning|err|notice|alert|crit|emerg|cont)|
(dev|netdev|netif)_(printk|dbg|vdbg|info|warn|err|notice|alert|crit|emerg|WARN)|
WARN|
--
1.7.9.5
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH 1/7] scripts: allow lines longer than 80 cols with printf() in checkpatch
2013-05-03 16:51 ` [PATCH 1/7] scripts: allow lines longer than 80 cols with printf() in checkpatch Thomas Petazzoni
@ 2013-05-06 7:23 ` Sascha Hauer
2013-05-06 7:27 ` Thomas Petazzoni
0 siblings, 1 reply; 63+ messages in thread
From: Sascha Hauer @ 2013-05-06 7:23 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
On Fri, May 03, 2013 at 06:51:05PM +0200, Thomas Petazzoni wrote:
> The checkpatch.pl script is also used to validate user-space code in
> the scripts/ directory, so it should allow printf() lines to be longer
> than 80 columns.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Applied this one for now. The rest of this series already looks really
good so I think they can go in quite fast.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 1/7] scripts: allow lines longer than 80 cols with printf() in checkpatch
2013-05-06 7:23 ` Sascha Hauer
@ 2013-05-06 7:27 ` Thomas Petazzoni
0 siblings, 0 replies; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-06 7:27 UTC (permalink / raw)
To: Sascha Hauer; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
Dear Sascha Hauer,
On Mon, 6 May 2013 09:23:44 +0200, Sascha Hauer wrote:
> On Fri, May 03, 2013 at 06:51:05PM +0200, Thomas Petazzoni wrote:
> > The checkpatch.pl script is also used to validate user-space code in
> > the scripts/ directory, so it should allow printf() lines to be longer
> > than 80 columns.
> >
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> Applied this one for now. The rest of this series already looks really
> good so I think they can go in quite fast.
Thanks! I'll reply to the reviews on the patches themselves.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-03 16:51 [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Thomas Petazzoni
2013-05-03 16:51 ` [PATCH 1/7] scripts: allow lines longer than 80 cols with printf() in checkpatch Thomas Petazzoni
@ 2013-05-03 16:51 ` Thomas Petazzoni
2013-05-04 19:51 ` Jean-Christophe PLAGNIOL-VILLARD
` (2 more replies)
2013-05-03 16:51 ` [PATCH 3/7] scripts: add kwboot tool Thomas Petazzoni
` (7 subsequent siblings)
9 siblings, 3 replies; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-03 16:51 UTC (permalink / raw)
To: barebox; +Cc: Lior Amsalem, Willy Tarreau, Ezequiel Garcia
The Marvell EBU SoCs (Kirkwood, Armada 370, Armada XP) have a BootROM
that understand a specific image format, composed of a main header,
several extension headers and a paylod. This image can be booted from
NAND, SPI, SATA, UART, NOR, etc.
This patch adds a tool that allows to extract the components and
configuration of existing images, and to create new images.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
scripts/.gitignore | 1 +
scripts/Makefile | 3 +-
scripts/kwbimage.c | 1224 ++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 1227 insertions(+), 1 deletion(-)
create mode 100644 scripts/kwbimage.c
diff --git a/scripts/.gitignore b/scripts/.gitignore
index 1ca6603..414de7f 100644
--- a/scripts/.gitignore
+++ b/scripts/.gitignore
@@ -2,6 +2,7 @@ bareboxenv
bin2c
gen_netx_image
kallsyms
+kwbimage
mk-am35xx-spi-image
mkimage
mkublheader
diff --git a/scripts/Makefile b/scripts/Makefile
index 08b325c..22ec4b6 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -8,6 +8,7 @@ hostprogs-$(CONFIG_KALLSYMS) += kallsyms
hostprogs-y += bin2c
hostprogs-y += mkimage
hostprogs-y += bareboxenv
+hostprogs-$(CONFIG_ARCH_MVEBU) += kwbimage
hostprogs-$(CONFIG_ARCH_NETX) += gen_netx_image
hostprogs-$(CONFIG_ARCH_OMAP) += omap_signGP mk-am35xx-spi-image
hostprogs-$(CONFIG_ARCH_S5PCxx) += s5p_cksum
@@ -27,7 +28,7 @@ subdir-$(CONFIG_X86) += setupmbr
subdir- += basic kconfig setupmbr
quiet_cmd_csingle = CC $@
- cmd_csingle = $(CC) -Wp,-MD,$(depfile) $(CFLAGS) -o $@ $<
+ cmd_csingle = $(CC) -Wp,-MD,$(depfile) $(CFLAGS) -o $@ $<
obj-$(CONFIG_BAREBOXENV_TARGET) += bareboxenv-target
diff --git a/scripts/kwbimage.c b/scripts/kwbimage.c
new file mode 100644
index 0000000..864114d
--- /dev/null
+++ b/scripts/kwbimage.c
@@ -0,0 +1,1224 @@
+/*
+ * Image manipulator for Kirkwood, Armada 370 and Armada XP platforms.
+ *
+ * (C) Copyright 2013 Thomas Petazzoni
+ * <thomas.petazzoni@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * This tool allows to extract and create bootable images for Marvell
+ * Kirkwood, Marvell Armada 370 and Armada XP SoCs. It supports two
+ * versions of the bootable image format: version 0 (used on Marvell
+ * Kirkwood) and version 1 (used on Marvell Armada 370/XP).
+ *
+ * To extract an image, run:
+ * ./scripts/kwbimage -x -i <image-file> -o <some-directory>
+ *
+ * In <some-directory>, kwbimage will output 'kwbimage.cfg', the
+ * configuration file that describes the image, 'payload', which is
+ * the bootloader code itself, and it may output a 'binary.0' file
+ * that corresponds to a binary blob (only possible in version 1
+ * images).
+ *
+ * To create an image, run:
+ * ./scripts/kwbimage -x -c <image-cfg-file> -o <image-file>
+ *
+ * The given configuration file is in the format of the 'kwbimage.cfg'
+ * file, and should reference the payload file (generally the
+ * bootloader code) and optionally a binary blob.
+ *
+ * Not implemented: support for the register headers and secure
+ * headers in v1 images
+ */
+
+#define _GNU_SOURCE
+#include <stdio.h>
+#include <stdint.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <sys/mman.h>
+#include <unistd.h>
+#include <stdlib.h>
+#include <string.h>
+
+#define ALIGN_SUP(x, a) (((x) + (a - 1)) & ~(a - 1))
+
+/* Structure of the main header, version 0 (Kirkwood) */
+struct main_hdr_v0 {
+ uint8_t blockid; /*0 */
+ uint8_t nandeccmode; /*1 */
+ uint16_t nandpagesize; /*2-3 */
+ uint32_t blocksize; /*4-7 */
+ uint32_t rsvd1; /*8-11 */
+ uint32_t srcaddr; /*12-15 */
+ uint32_t destaddr; /*16-19 */
+ uint32_t execaddr; /*20-23 */
+ uint8_t satapiomode; /*24 */
+ uint8_t rsvd3; /*25 */
+ uint16_t ddrinitdelay; /*26-27 */
+ uint16_t rsvd2; /*28-29 */
+ uint8_t ext; /*30 */
+ uint8_t checksum; /*31 */
+};
+
+struct ext_hdr_v0_reg {
+ uint32_t raddr;
+ uint32_t rdata;
+};
+
+#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20)/sizeof(struct ext_hdr_v0_reg))
+
+struct ext_hdr_v0 {
+ uint32_t offset;
+ uint8_t reserved[0x20 - sizeof(uint32_t)];
+ struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT];
+ uint8_t reserved2[7];
+ uint8_t checksum;
+};
+
+/* Structure of the main header, version 1 (Armada 370, Armada XP) */
+struct main_hdr_v1 {
+ uint8_t blockid; /* 0 */
+ uint8_t reserved1; /* 1 */
+ uint16_t reserved2; /* 2-3 */
+ uint32_t blocksize; /* 4-7 */
+ uint8_t version; /* 8 */
+ uint8_t headersz_msb; /* 9 */
+ uint16_t headersz_lsb; /* A-B */
+ uint32_t srcaddr; /* C-F */
+ uint32_t destaddr; /* 10-13 */
+ uint32_t execaddr; /* 14-17 */
+ uint8_t reserved3; /* 18 */
+ uint8_t nandblocksize; /* 19 */
+ uint8_t nandbadblklocation; /* 1A */
+ uint8_t reserved4; /* 1B */
+ uint16_t reserved5; /* 1C-1D */
+ uint8_t ext; /* 1E */
+ uint8_t checksum; /* 1F */
+};
+
+/*
+ * Header for the optional headers, version 1 (Armada 370, Armada XP)
+ */
+struct opt_hdr_v1 {
+ uint8_t headertype;
+ uint8_t headersz_msb;
+ uint16_t headersz_lsb;
+ char data[0];
+};
+
+/*
+ * Various values for the opt_hdr_v1->headertype field, describing the
+ * different types of optional headers. The "secure" header contains
+ * informations related to secure boot (encryption keys, etc.). The
+ * "binary" header contains ARM binary code to be executed prior to
+ * executing the main payload (usually the bootloader). This is
+ * typically used to execute DDR3 training code. The "register" header
+ * allows to describe a set of (address, value) tuples that are
+ * generally used to configure the DRAM controller.
+ */
+#define OPT_HDR_V1_SECURE_TYPE 0x1
+#define OPT_HDR_V1_BINARY_TYPE 0x2
+#define OPT_HDR_V1_REGISTER_TYPE 0x3
+
+#define KWBHEADER_V1_SIZE(hdr) \
+ (((hdr)->headersz_msb << 16) | (hdr)->headersz_lsb)
+
+struct boot_mode {
+ unsigned int id;
+ const char *name;
+};
+
+struct boot_mode boot_modes[] = {
+ { 0x4D, "i2c" },
+ { 0x5A, "spi" },
+ { 0x8B, "nand" },
+ { 0x78, "sata" },
+ { 0x9C, "pex" },
+ { 0x69, "uart" },
+ {},
+};
+
+struct nand_ecc_mode {
+ unsigned int id;
+ const char *name;
+};
+
+struct nand_ecc_mode nand_ecc_modes[] = {
+ { 0x00, "default" },
+ { 0x01, "hamming" },
+ { 0x02, "rs" },
+ { 0x03, "disabled" },
+ {},
+};
+
+#define BINARY_MAX_ARGS 8
+
+/* In-memory representation of a line of the configuration file */
+struct image_cfg_element {
+ enum {
+ IMAGE_CFG_VERSION = 0x1,
+ IMAGE_CFG_BOOT_FROM,
+ IMAGE_CFG_DEST_ADDR,
+ IMAGE_CFG_EXEC_ADDR,
+ IMAGE_CFG_NAND_BLKSZ,
+ IMAGE_CFG_NAND_BADBLK_LOCATION,
+ IMAGE_CFG_BINARY,
+ IMAGE_CFG_PAYLOAD,
+ IMAGE_CFG_DATA,
+ } type;
+ union {
+ unsigned int version;
+ const char *boot_from;
+ struct {
+ const char *file;
+ unsigned int args[BINARY_MAX_ARGS];
+ unsigned int nargs;
+ } binary;
+ const char *payload;
+ unsigned int dstaddr;
+ unsigned int execaddr;
+ unsigned int nandblksz;
+ unsigned int nandbadblklocation;
+ struct ext_hdr_v0_reg regdata;
+ };
+};
+
+/*
+ * Byte 8 of the image header contains the version number. In the v0
+ * header, byte 8 was reserved, and always set to 0. In the v1 header,
+ * byte 8 has been changed to a proper field, set to 1.
+ */
+static unsigned int image_version(void *header)
+{
+ unsigned char *ptr = header;
+ return ptr[8];
+}
+
+/*
+ * Utility functions to manipulate boot mode and ecc modes (convert
+ * them back and forth between description strings and the
+ * corresponding numerical identifiers).
+ */
+
+static const char *image_boot_mode_name(unsigned int id)
+{
+ int i;
+ for (i = 0; boot_modes[i].name; i++)
+ if (boot_modes[i].id == id)
+ return boot_modes[i].name;
+ return NULL;
+}
+
+unsigned int image_boot_mode_id(const char *boot_mode_name)
+{
+ int i;
+ for (i = 0; boot_modes[i].name; i++)
+ if (!strcmp(boot_modes[i].name, boot_mode_name))
+ return boot_modes[i].id;
+
+ return 0;
+}
+
+static const char *image_nand_ecc_mode_name(unsigned int id)
+{
+ int i;
+ for (i = 0; nand_ecc_modes[i].name; i++)
+ if (nand_ecc_modes[i].id == id)
+ return nand_ecc_modes[i].name;
+ return NULL;
+}
+
+/*
+ * Compute a 8-bit checksum of a memory area. This algorithm follows
+ * the requirements of the Marvell SoC BootROM specifications.
+ */
+static uint8_t image_checksum8(void *start, uint32_t len)
+{
+ uint8_t csum = 0;
+ uint8_t *p = start;
+
+ /* check len and return zero checksum if invalid */
+ if (!len)
+ return 0;
+
+ do {
+ csum += *p;
+ p++;
+ } while (--len);
+
+ return csum;
+}
+
+static uint32_t image_checksum32 (void *start, uint32_t len)
+{
+ uint32_t csum = 0;
+ uint32_t *p = start;
+
+ /* check len and return zero checksum if invalid */
+ if (!len)
+ return 0;
+
+ if (len % sizeof(uint32_t)) {
+ fprintf (stderr, "Length %d is not in multiple of %zu\n",
+ len, sizeof(uint32_t));
+ return 0;
+ }
+
+ do {
+ csum += *p;
+ p++;
+ len -= sizeof(uint32_t);
+ } while (len > 0);
+
+ return csum;
+}
+
+static void usage(const char *prog)
+{
+ printf("Usage: %s [-c | -x] -i <input> -o <output>\n", prog);
+ printf(" -c: create a new image\n");
+ printf(" -x: extract an existing image\n");
+ printf(" -i: input file\n");
+ printf(" when used with -c, should point to a kwbimage.cfg file\n");
+ printf(" when used with -x, should point to the image to be extracted\n");
+ printf(" -o: output file/directory\n");
+ printf(" when used with -c, should point to the image file to create\n");
+ printf(" when used with -x, should point to a directory when the image will be extracted\n");
+}
+
+static int image_extract_payload(void *payload, size_t sz, const char *output)
+{
+ char *imageoutname;
+ FILE *imageout;
+ int ret;
+
+ ret = asprintf(&imageoutname, "%s/payload", output);
+ if (ret < 0) {
+ fprintf(stderr, "Cannot allocate memory\n");
+ return -1;
+ }
+
+ imageout = fopen(imageoutname, "w+");
+ if (!imageout) {
+ fprintf(stderr, "Could not open output file %s\n",
+ imageoutname);
+ free(imageoutname);
+ return -1;
+ }
+
+ ret = fwrite(payload, sz, 1, imageout);
+ if (ret != 1) {
+ fprintf(stderr, "Could not write to open file %s\n",
+ imageoutname);
+ fclose(imageout);
+ free(imageoutname);
+ return -1;
+ }
+
+ fclose(imageout);
+ free(imageoutname);
+ return 0;
+}
+
+static int image_extract_v0(void *fdimap, const char *output, FILE *focfg)
+{
+ struct main_hdr_v0 *main_hdr = fdimap;
+ struct ext_hdr_v0 *ext_hdr;
+ const char *boot_mode_name;
+ uint32_t *img_checksum;
+ size_t payloadsz;
+ int cksum, i;
+
+ /*
+ * Verify checksum. When calculating the header, discard the
+ * last byte of the header, which itself contains the
+ * checksum.
+ */
+ cksum = image_checksum8(main_hdr, sizeof(struct main_hdr_v0)-1);
+ if (cksum != main_hdr->checksum) {
+ fprintf(stderr,
+ "Invalid main header checksum: 0x%08x vs. 0x%08x\n",
+ cksum, main_hdr->checksum);
+ return -1;
+ }
+
+ boot_mode_name = image_boot_mode_name(main_hdr->blockid);
+ if (!boot_mode_name) {
+ fprintf(stderr, "Invalid boot ID: 0x%x\n",
+ main_hdr->blockid);
+ return -1;
+ }
+
+ fprintf(focfg, "VERSION 0\n");
+ fprintf(focfg, "BOOT_FROM %s\n", boot_mode_name);
+ fprintf(focfg, "DESTADDR %08x\n", main_hdr->destaddr);
+ fprintf(focfg, "EXECADDR %08x\n", main_hdr->execaddr);
+
+ if (!strcmp(boot_mode_name, "nand")) {
+ const char *nand_ecc_mode =
+ image_nand_ecc_mode_name(main_hdr->nandeccmode);
+ fprintf(focfg, "NAND_ECC_MODE %s\n",
+ nand_ecc_mode);
+ fprintf(focfg, "NAND_PAGE_SIZE %08x\n",
+ main_hdr->nandpagesize);
+ }
+
+ /* No extension header, we're done */
+ if (!main_hdr->ext)
+ return 0;
+
+ ext_hdr = fdimap + sizeof(struct main_hdr_v0);
+
+ for (i = 0; i < EXT_HDR_V0_REG_COUNT; i++) {
+ if (ext_hdr->rcfg[i].raddr == 0 &&
+ ext_hdr->rcfg[i].rdata == 0)
+ break;
+
+ fprintf(focfg, "DATA %08x %08x\n",
+ ext_hdr->rcfg[i].raddr,
+ ext_hdr->rcfg[i].rdata);
+ }
+
+ /* The image is concatenated with a 32 bits checksum */
+ payloadsz = main_hdr->blocksize - sizeof(uint32_t);
+ img_checksum = (uint32_t *) (fdimap + main_hdr->srcaddr + payloadsz);
+
+ if (*img_checksum != image_checksum32(fdimap + main_hdr->srcaddr,
+ payloadsz)) {
+ fprintf(stderr, "The image checksum does not match\n");
+ return -1;
+ }
+
+ /* Finally, handle the image itself */
+ fprintf(focfg, "PAYLOAD %s/payload\n", output);
+ return image_extract_payload(fdimap + main_hdr->srcaddr,
+ payloadsz, output);
+}
+
+static int image_extract_binary_hdr_v1(const void *binary, const char *output,
+ FILE *focfg, int hdrnum, size_t binsz)
+{
+ char *binaryoutname;
+ FILE *binaryout;
+ const unsigned int *args;
+ unsigned int nargs;
+ int ret, i;
+
+ args = binary;
+ nargs = args[0];
+ args++;
+
+ ret = asprintf(&binaryoutname, "%s/binary.%d", output,
+ hdrnum);
+ if (ret < 0) {
+ fprintf(stderr, "Couldn't not allocate memory\n");
+ return ret;
+ }
+
+ binaryout = fopen(binaryoutname, "w+");
+ if (!binaryout) {
+ fprintf(stderr, "Couldn't open output file %s\n",
+ binaryoutname);
+ free(binaryoutname);
+ return -1;
+ }
+
+ ret = fwrite(binary + (nargs + 1) * sizeof(unsigned int),
+ binsz - (nargs + 1) * sizeof(unsigned int), 1,
+ binaryout);
+ if (ret != 1) {
+ fprintf(stderr, "Could not write to output file %s\n",
+ binaryoutname);
+ fclose(binaryout);
+ free(binaryoutname);
+ return -1;
+ }
+
+ fclose(binaryout);
+
+ fprintf(focfg, "BINARY %s", binaryoutname);
+ for (i = 0; i < nargs; i++)
+ fprintf(focfg, " %08x", args[i]);
+ fprintf(focfg, "\n");
+
+ free(binaryoutname);
+
+ return 0;
+}
+
+static int image_extract_v1(void *fdimap, const char *output, FILE *focfg)
+{
+ struct main_hdr_v1 *main_hdr = fdimap;
+ struct opt_hdr_v1 *opt_hdr;
+ const char *boot_mode_name;
+ int headersz = KWBHEADER_V1_SIZE(main_hdr);
+ int hasheaders;
+ uint8_t cksum;
+ int opthdrid;
+
+ /*
+ * Verify the checkum. We have to substract the checksum
+ * itself, because when the checksum is calculated, the
+ * checksum field is 0.
+ */
+ cksum = image_checksum8(main_hdr, headersz);
+ cksum -= main_hdr->checksum;
+
+ if (cksum != main_hdr->checksum) {
+ fprintf(stderr,
+ "Invalid main header checksum: 0x%08x vs. 0x%08x\n",
+ cksum, main_hdr->checksum);
+ return -1;
+ }
+
+ /* First, take care of the main header */
+ boot_mode_name = image_boot_mode_name(main_hdr->blockid);
+ if (!boot_mode_name) {
+ fprintf(stderr, "Invalid boot ID: 0x%x\n",
+ main_hdr->blockid);
+ return -1;
+ }
+
+ fprintf(focfg, "VERSION 1\n");
+ fprintf(focfg, "BOOT_FROM %s\n", boot_mode_name);
+ fprintf(focfg, "DESTADDR %08x\n", main_hdr->destaddr);
+ fprintf(focfg, "EXECADDR %08x\n", main_hdr->execaddr);
+ fprintf(focfg, "NAND_BLKSZ %08x\n",
+ main_hdr->nandblocksize * 64 * 1024);
+ fprintf(focfg, "NAND_BADBLK_LOCATION %02x\n",
+ main_hdr->nandbadblklocation);
+
+ hasheaders = main_hdr->ext;
+ opt_hdr = fdimap + sizeof(struct main_hdr_v1);
+ opthdrid = 0;
+
+ /* Then, go through all the extension headers */
+ while (hasheaders) {
+ int opthdrsz = KWBHEADER_V1_SIZE(opt_hdr);
+
+ switch (opt_hdr->headertype) {
+ case OPT_HDR_V1_BINARY_TYPE:
+ image_extract_binary_hdr_v1(opt_hdr->data, output,
+ focfg, opthdrid,
+ opthdrsz -
+ sizeof(struct opt_hdr_v1));
+ break;
+ case OPT_HDR_V1_SECURE_TYPE:
+ case OPT_HDR_V1_REGISTER_TYPE:
+ fprintf(stderr,
+ "Support for header type 0x%x not implemented\n",
+ opt_hdr->headertype);
+ exit(1);
+ break;
+ default:
+ fprintf(stderr, "Invalid header type 0x%x\n",
+ opt_hdr->headertype);
+ exit(1);
+ }
+
+ /*
+ * The first byte of the last double word of the
+ * current header indicates whether there is a next
+ * header or not.
+ */
+ hasheaders = ((char *)opt_hdr)[opthdrsz - 4];
+
+ /* Move to the next header */
+ opt_hdr = ((void *)opt_hdr) + opthdrsz;
+ opthdrid++;
+ }
+
+ /* Finally, handle the image itself */
+ fprintf(focfg, "PAYLOAD %s/payload\n", output);
+ return image_extract_payload(fdimap + main_hdr->srcaddr,
+ main_hdr->blocksize - 4,
+ output);
+}
+
+static int image_extract(const char *input, const char *output)
+{
+ int fdi, ret;
+ struct stat fdistat, fdostat;
+ void *fdimap;
+ char *focfgname;
+ FILE *focfg;
+
+ fdi = open(input, O_RDONLY);
+ if (fdi < 0) {
+ fprintf(stderr, "Cannot open input file %s: %m\n",
+ input);
+ return -1;
+ }
+
+ ret = fstat(fdi, &fdistat);
+ if (ret < 0) {
+ fprintf(stderr, "Cannot stat input file %s: %m\n",
+ input);
+ close(fdi);
+ return -1;
+ }
+
+ fdimap = mmap(NULL, fdistat.st_size, PROT_READ, MAP_PRIVATE, fdi, 0);
+ if (fdimap == MAP_FAILED) {
+ fprintf(stderr, "Cannot map input file %s: %m\n",
+ input);
+ close(fdi);
+ return -1;
+ }
+
+ close(fdi);
+
+ ret = stat(output, &fdostat);
+ if (ret < 0) {
+ fprintf(stderr, "Cannot stat output directory %s: %m\n",
+ output);
+ munmap(fdimap, fdistat.st_size);
+ return -1;
+ }
+
+ if (!S_ISDIR(fdostat.st_mode)) {
+ fprintf(stderr, "Output %s should be a directory\n",
+ output);
+ munmap(fdimap, fdistat.st_size);
+ return -1;
+ }
+
+ ret = asprintf(&focfgname, "%s/kwbimage.cfg", output);
+ if (ret < 0) {
+ fprintf(stderr, "Failed to allocate memory\n");
+ munmap(fdimap, fdistat.st_size);
+ return -1;
+ }
+
+ focfg = fopen(focfgname, "w+");
+ if (!focfg) {
+ fprintf(stderr, "Output file %s could not be created\n",
+ focfgname);
+ free(focfgname);
+ munmap(fdimap, fdistat.st_size);
+ return -1;
+ }
+
+ free(focfgname);
+
+ if (image_version(fdimap) == 0)
+ ret = image_extract_v0(fdimap, output, focfg);
+ else if (image_version(fdimap) == 1)
+ ret = image_extract_v1(fdimap, output, focfg);
+ else {
+ fprintf(stderr, "Invalid image version %d\n",
+ image_version(fdimap));
+ ret = -1;
+ }
+
+ fclose(focfg);
+ munmap(fdimap, fdistat.st_size);
+ return ret;
+}
+
+static int image_create_payload(void *payload_start, size_t payloadsz,
+ const char *payload_filename)
+{
+ FILE *payload;
+ uint32_t *payload_checksum =
+ (uint32_t *) (payload_start + payloadsz);
+ int ret;
+
+ payload = fopen(payload_filename, "r");
+ if (!payload) {
+ fprintf(stderr, "Cannot open payload file %s\n",
+ payload_filename);
+ return -1;
+ }
+
+ ret = fread(payload_start, payloadsz, 1, payload);
+ if (ret != 1) {
+ fprintf(stderr, "Cannot read payload file %s\n",
+ payload_filename);
+ return -1;
+ }
+
+ fclose(payload);
+
+ *payload_checksum = image_checksum32(payload_start, payloadsz);
+ return 0;
+}
+
+static void *image_create_v0(struct image_cfg_element *image_cfg,
+ int cfgn, const char *output, size_t *imagesz)
+{
+ size_t headersz, payloadsz, totalsz;
+ struct main_hdr_v0 *main_hdr;
+ struct ext_hdr_v0 *ext_hdr;
+ void *image;
+ int has_ext = 0;
+ int cfgi, ret;
+
+ /* Calculate the size of the header and the size of the
+ * payload */
+ headersz = sizeof(struct main_hdr_v0);
+ payloadsz = 0;
+ for (cfgi = 0; cfgi < cfgn; cfgi++) {
+ struct image_cfg_element *el = &image_cfg[cfgi];
+ if (el->type == IMAGE_CFG_DATA)
+ has_ext = 1;
+ else if (el->type == IMAGE_CFG_PAYLOAD) {
+ struct stat s;
+ int ret;
+
+ ret = stat(el->payload, &s);
+ if (ret < 0) {
+ fprintf(stderr, "Cannot stat payload file %s\n",
+ el->payload);
+ return NULL;
+ }
+
+ payloadsz = s.st_size;
+ }
+ }
+
+ if (has_ext)
+ headersz += sizeof(struct ext_hdr_v0);
+
+ /* Headers, payload and 32-bits checksum */
+ totalsz = headersz + payloadsz + sizeof(uint32_t);
+
+ image = malloc(totalsz);
+ if (!image) {
+ fprintf(stderr, "Cannot allocate memory for image\n");
+ return NULL;
+ }
+
+ memset(image, 0, totalsz);
+
+ main_hdr = image;
+
+ /* Fill in the main header */
+ main_hdr->blocksize = payloadsz + sizeof(uint32_t);
+ main_hdr->srcaddr = headersz;
+ main_hdr->ext = has_ext;
+ for (cfgi = 0; cfgi < cfgn; cfgi++) {
+ struct image_cfg_element *el = &image_cfg[cfgi];
+ if (el->type == IMAGE_CFG_BOOT_FROM)
+ main_hdr->blockid = image_boot_mode_id(el->boot_from);
+ else if (el->type == IMAGE_CFG_DEST_ADDR)
+ main_hdr->destaddr = el->dstaddr;
+ else if (el->type == IMAGE_CFG_EXEC_ADDR)
+ main_hdr->execaddr = el->execaddr;
+ else if (el->type != IMAGE_CFG_VERSION)
+ break;
+ }
+
+ main_hdr->checksum = image_checksum8(image,
+ sizeof(struct main_hdr_v0));
+
+ /* Generate the ext header */
+ if (has_ext) {
+ int datai = 0;
+
+ ext_hdr = image + sizeof(struct main_hdr_v0);
+ ext_hdr->offset = 0x40;
+
+ for (; cfgi < cfgn; cfgi++) {
+ struct image_cfg_element *el = &image_cfg[cfgi];
+ if (el->type == IMAGE_CFG_DATA) {
+ ext_hdr->rcfg[datai].raddr = el->regdata.raddr;
+ ext_hdr->rcfg[datai].rdata = el->regdata.rdata;
+ datai++;
+ }
+ else if (el->type == IMAGE_CFG_PAYLOAD)
+ break;
+ else {
+ fprintf(stderr, "Invalid element of type %d\n",
+ el->type);
+ return NULL;
+ }
+ }
+
+ ext_hdr->checksum = image_checksum8(ext_hdr,
+ sizeof(struct ext_hdr_v0));
+ }
+
+ /* Now, time to take care of the payload, if any */
+ if (image_cfg[cfgi].type == IMAGE_CFG_PAYLOAD) {
+ if (cfgi != cfgn - 1) {
+ fprintf(stderr,
+ "There should always be only one payload, and it should be the last element\n");
+ return NULL;
+ }
+
+ ret = image_create_payload(image + headersz, payloadsz,
+ image_cfg[cfgi].payload);
+ if (ret < 0)
+ return NULL;
+ }
+
+ *imagesz = totalsz;
+ return image;
+}
+
+static void *image_create_v1(struct image_cfg_element *image_cfg,
+ int cfgn, const char *output, size_t *imagesz)
+{
+ struct main_hdr_v1 *main_hdr;
+ size_t headersz, payloadsz, totalsz;
+ void *image, *cur;
+ int hasext = 0;
+ int cfgi, ret;
+
+ /* Calculate the size of the header and the size of the
+ * payload */
+ headersz = sizeof(struct main_hdr_v1);
+ payloadsz = 0;
+ for (cfgi = 0; cfgi < cfgn; cfgi++) {
+ struct image_cfg_element *el = &image_cfg[cfgi];
+ if (el->type == IMAGE_CFG_BINARY) {
+ struct stat s;
+
+ ret = stat(el->binary.file, &s);
+ if (ret < 0) {
+ fprintf(stderr, "Cannot stat binary file %s\n",
+ el->binary.file);
+ return NULL;
+ }
+
+ headersz += s.st_size +
+ el->binary.nargs * sizeof(unsigned int);
+ hasext = 1;
+ } else if (el->type == IMAGE_CFG_PAYLOAD) {
+ struct stat s;
+
+ ret = stat(el->payload, &s);
+ if (ret < 0) {
+ fprintf(stderr, "Cannot stat payload file %s\n",
+ el->payload);
+ return NULL;
+ }
+
+ payloadsz = s.st_size;
+ }
+ }
+
+ /* The payload should be aligned on some reasonable
+ * boundary */
+ headersz = ALIGN_SUP(headersz, 4096);
+
+ /* The total size includes the headers, the payload, and the
+ * 32 bits checksum at the end of the payload */
+ totalsz = headersz + payloadsz + sizeof(uint32_t);
+
+ image = malloc(totalsz);
+ if (!image) {
+ fprintf(stderr, "Cannot allocate memory for image\n");
+ return NULL;
+ }
+
+ memset(image, 0, totalsz);
+
+ cur = main_hdr = image;
+ cur += sizeof(struct main_hdr_v1);
+
+ main_hdr->blocksize = payloadsz + sizeof(uint32_t);
+ main_hdr->headersz_lsb = headersz & 0xFFFF;
+ main_hdr->headersz_msb = (headersz & 0xFFFF0000) >> 16;
+ main_hdr->srcaddr = headersz;
+ main_hdr->ext = hasext;
+
+ /* First, take care of filling the main header */
+ for (cfgi = 0; cfgi < cfgn; cfgi++) {
+ struct image_cfg_element *el = &image_cfg[cfgi];
+ if (el->type == IMAGE_CFG_VERSION)
+ main_hdr->version = 1;
+ else if (el->type == IMAGE_CFG_BOOT_FROM)
+ main_hdr->blockid = image_boot_mode_id(el->boot_from);
+ else if (el->type == IMAGE_CFG_DEST_ADDR)
+ main_hdr->destaddr = el->dstaddr;
+ else if (el->type == IMAGE_CFG_EXEC_ADDR)
+ main_hdr->execaddr = el->execaddr;
+ else if (el->type == IMAGE_CFG_NAND_BLKSZ)
+ main_hdr->nandblocksize = el->nandblksz / (64 * 1024);
+ else if (el->type == IMAGE_CFG_NAND_BADBLK_LOCATION)
+ main_hdr->nandbadblklocation = el->nandbadblklocation;
+ else
+ break;
+ }
+
+ /* Then, fill the extension headers */
+ for (; cfgi < cfgn; cfgi++) {
+ struct image_cfg_element *el = &image_cfg[cfgi];
+
+ if (el->type == IMAGE_CFG_BINARY) {
+ struct opt_hdr_v1 *hdr = cur;
+ unsigned int *args;
+ size_t binhdrsz;
+ struct stat s;
+ int argi;
+ FILE *bin;
+
+ hdr->headertype = OPT_HDR_V1_BINARY_TYPE;
+
+ bin = fopen(el->binary.file, "r");
+ if (!bin) {
+ fprintf(stderr, "Cannot open binary file %s\n",
+ el->binary.file);
+ return NULL;
+ }
+
+ fstat(fileno(bin), &s);
+
+ binhdrsz = sizeof(struct opt_hdr_v1) +
+ (el->binary.nargs + 1) * sizeof(unsigned int) +
+ s.st_size;
+ hdr->headersz_lsb = binhdrsz & 0xFFFF;
+ hdr->headersz_msb = (binhdrsz & 0xFFFF0000) >> 16;
+
+ cur += sizeof(struct opt_hdr_v1);
+
+ args = cur;
+ *args = el->binary.nargs;
+ args++;
+ for (argi = 0; argi < el->binary.nargs; argi++)
+ args[argi] = el->binary.args[argi];
+
+ cur += (el->binary.nargs + 1) * sizeof(unsigned int);
+
+ ret = fread(cur, s.st_size, 1, bin);
+ if (ret != 1) {
+ fprintf(stderr,
+ "Could not read binary image %s\n",
+ el->binary.file);
+ return NULL;
+ }
+
+ fclose(bin);
+
+ cur += s.st_size;
+
+ /* See if we have a next header or not, and if
+ * so, add the marker indicating that we are
+ * not the last header */
+ if ((cfgi < (cfgn - 1)) &&
+ (image_cfg[cfgi + 1].type != IMAGE_CFG_PAYLOAD))
+ *((unsigned char *) cur) = 1;
+ cur += sizeof(uint32_t);
+ } else if (el->type == IMAGE_CFG_PAYLOAD)
+ break;
+ else {
+ fprintf(stderr, "Invalid element type %d (cfgi=%d)\n",
+ el->type, cfgi);
+ return NULL;
+ }
+ }
+
+ /* Calculate and set the header checksum */
+ main_hdr->checksum = image_checksum8(main_hdr, headersz);
+
+ /* Now, time to take care of the payload, if any */
+ if (image_cfg[cfgi].type == IMAGE_CFG_PAYLOAD) {
+ if (cfgi != cfgn - 1) {
+ fprintf(stderr,
+ "There should always be only one payload, and it should be the last element\n");
+ return NULL;
+ }
+
+ ret = image_create_payload(image + headersz, payloadsz,
+ image_cfg[cfgi].payload);
+ if (ret < 0)
+ return NULL;
+ }
+
+ *imagesz = totalsz;
+ return image;
+}
+
+static int image_create_config_parse_oneline(char *line,
+ struct image_cfg_element *el)
+{
+ char *keyword, *saveptr;
+
+ keyword = strtok_r(line, " ", &saveptr);
+ if (!strcmp(keyword, "VERSION")) {
+ char *value = strtok_r(NULL, " ", &saveptr);
+ el->type = IMAGE_CFG_VERSION;
+ el->version = atoi(value);
+ } else if (!strcmp(keyword, "BOOT_FROM")) {
+ char *value = strtok_r(NULL, " ", &saveptr);
+ el->type = IMAGE_CFG_BOOT_FROM;
+ el->boot_from = strdup(value);
+ } else if (!strcmp(keyword, "DESTADDR")) {
+ char *value = strtok_r(NULL, " ", &saveptr);
+ el->type = IMAGE_CFG_DEST_ADDR;
+ el->dstaddr = strtol(value, NULL, 16);
+ } else if (!strcmp(keyword, "EXECADDR")) {
+ char *value = strtok_r(NULL, " ", &saveptr);
+ el->type = IMAGE_CFG_EXEC_ADDR;
+ el->execaddr = strtol(value, NULL, 16);
+ } else if (!strcmp(keyword, "NAND_BLKSZ")) {
+ char *value = strtok_r(NULL, " ", &saveptr);
+ el->type = IMAGE_CFG_NAND_BLKSZ;
+ el->nandblksz = strtol(value, NULL, 16);
+ } else if (!strcmp(keyword, "NAND_BADBLK_LOCATION")) {
+ char *value = strtok_r(NULL, " ", &saveptr);
+ el->type = IMAGE_CFG_NAND_BADBLK_LOCATION;
+ el->nandbadblklocation =
+ strtol(value, NULL, 16);
+ } else if (!strcmp(keyword, "BINARY")) {
+ char *value = strtok_r(NULL, " ", &saveptr);
+ int argi = 0;
+
+ el->type = IMAGE_CFG_BINARY;
+ el->binary.file = strdup(value);
+ while (1) {
+ value = strtok_r(NULL, " ", &saveptr);
+ if (!value)
+ break;
+ el->binary.args[argi] = strtol(value, NULL, 16);
+ argi++;
+ if (argi >= BINARY_MAX_ARGS) {
+ fprintf(stderr,
+ "Too many argument for binary\n");
+ return -1;
+ }
+ }
+ el->binary.nargs = argi;
+ } else if (!strcmp(keyword, "DATA")) {
+ char *value1 = strtok_r(NULL, " ", &saveptr);
+ char *value2 = strtok_r(NULL, " ", &saveptr);
+
+ if (!value1 || !value2) {
+ fprintf(stderr, "Invalid number of arguments for DATA\n");
+ return -1;
+ }
+
+ el->type = IMAGE_CFG_DATA;
+ el->regdata.raddr = strtol(value1, NULL, 16);
+ el->regdata.rdata = strtol(value2, NULL, 16);
+ } else if (!strcmp(keyword, "PAYLOAD")) {
+ char *value = strtok_r(NULL, " ", &saveptr);
+ el->type = IMAGE_CFG_PAYLOAD;
+ el->payload = strdup(value);
+ } else {
+ fprintf(stderr, "Ignoring unknown line '%s'\n", line);
+ }
+
+ return 0;
+}
+
+static int image_create_config_parse(FILE *fcfg,
+ struct image_cfg_element *image_cfg)
+{
+ int ret;
+ int cfgi = 0;
+
+ /* Parse the configuration file */
+ while (!feof(fcfg)) {
+ char *line;
+ char buf[256];
+
+ /* Read the current line */
+ memset(buf, 0, sizeof(buf));
+ line = fgets(buf, sizeof(buf), fcfg);
+ if (!line)
+ break;
+
+ /* Ignore useless lines */
+ if (line[0] == '\n' || line[0] == '#')
+ continue;
+
+ /* Strip final newline */
+ if (line[strlen(line) - 1] == '\n')
+ line[strlen(line) - 1] = 0;
+
+ /* Parse the current line */
+ ret = image_create_config_parse_oneline(line,
+ &image_cfg[cfgi]);
+ if (ret)
+ return ret;
+
+ cfgi++;
+ }
+
+ return 0;
+}
+
+static int image_create_config_count_lines(FILE *fcfg)
+{
+ int lines = 0;
+
+ /* Count number of useful lines */
+ while (!feof(fcfg)) {
+ char *line;
+ char buf[256];
+ memset(buf, 0, sizeof(buf));
+ line = fgets(buf, sizeof(buf), fcfg);
+ if (!line)
+ break;
+ if (line[0] == '\n' || line[0] == '#')
+ continue;
+ lines++;
+ }
+
+ return lines;
+}
+
+static int image_create(const char *input, const char *output)
+{
+ struct image_cfg_element *image_cfg;
+ FILE *fcfg, *outputimg;
+ void *image = NULL;
+ int version = -1;
+ size_t imagesz;
+ int lines;
+ int cfgi;
+ int ret;
+
+ fcfg = fopen(input, "r");
+ if (!fcfg) {
+ fprintf(stderr, "Could not open input file %s\n",
+ input);
+ return -1;
+ }
+
+ lines = image_create_config_count_lines(fcfg);
+ if (lines == 0) {
+ fprintf(stderr, "Configuration file %s is empty\n",
+ input);
+ return -1;
+ }
+
+ image_cfg = malloc(lines * sizeof(struct image_cfg_element));
+ if (!image_cfg) {
+ fprintf(stderr, "Cannot allocate memory\n");
+ fclose(fcfg);
+ return -1;
+ }
+
+ memset(image_cfg, 0, lines * sizeof(struct image_cfg_element));
+ rewind(fcfg);
+
+ ret = image_create_config_parse(fcfg, image_cfg);
+ if (ret)
+ return -1;
+
+ for (cfgi = 0; cfgi < lines; cfgi++) {
+ if (image_cfg[cfgi].type != IMAGE_CFG_VERSION)
+ continue;
+
+ version = image_cfg[cfgi].version;
+ break;
+ }
+
+ if (version == -1) {
+ fprintf(stderr, "File %s does not have the VERSION field\n",
+ input);
+ return -1;
+ }
+
+ if (version == 0)
+ image = image_create_v0(image_cfg, lines, output, &imagesz);
+ else if (version == 1)
+ image = image_create_v1(image_cfg, lines, output, &imagesz);
+
+ if (!image) {
+ fprintf(stderr, "Could not create image\n");
+ return -1;
+ }
+
+ outputimg = fopen(output, "w");
+ if (!outputimg) {
+ fprintf(stderr, "Cannot open output image %s for writing\n",
+ output);
+ return -1;
+ }
+
+ ret = fwrite(image, imagesz, 1, outputimg);
+ if (ret != 1) {
+ fprintf(stderr, "Cannot write to output image %s\n",
+ output);
+ return -1;
+ }
+
+ fclose(outputimg);
+ free(image);
+
+ return 0;
+}
+
+enum {
+ ACTION_CREATE,
+ ACTION_EXTRACT,
+ ACTION_DUMP,
+ ACTION_HELP,
+};
+
+int main(int argc, char *argv[])
+{
+ int action = -1, opt;
+ const char *input = NULL, *output = NULL;
+
+ while ((opt = getopt(argc, argv, "hxci:o:")) != -1) {
+ switch (opt) {
+ case 'x':
+ action = ACTION_EXTRACT;
+ break;
+ case 'c':
+ action = ACTION_CREATE;
+ break;
+ case 'i':
+ input = optarg;
+ break;
+ case 'o':
+ output = optarg;
+ break;
+ case 'h':
+ action = ACTION_HELP;
+ break;
+ }
+ }
+
+ /* We should have consumed all arguments */
+ if (optind != argc) {
+ usage(argv[0]);
+ exit(1);
+ }
+
+ if (action != ACTION_HELP && !input) {
+ fprintf(stderr, "Missing input file\n");
+ usage(argv[0]);
+ exit(1);
+ }
+
+ if ((action == ACTION_EXTRACT || action == ACTION_CREATE) &&
+ !output) {
+ fprintf(stderr, "Missing output file\n");
+ usage(argv[1]);
+ exit(1);
+ }
+
+ switch (action) {
+ case ACTION_EXTRACT:
+ return image_extract(input, output);
+ case ACTION_CREATE:
+ return image_create(input, output);
+ case ACTION_HELP:
+ usage(argv[0]);
+ return 0;
+ default:
+ fprintf(stderr, "No action specified\n");
+ usage(argv[0]);
+ exit(1);
+ }
+
+ return 0;
+}
--
1.7.9.5
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-03 16:51 ` [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images Thomas Petazzoni
@ 2013-05-04 19:51 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-04 20:32 ` Jason Cooper
2013-05-06 19:41 ` Sascha Hauer
2013-05-06 19:16 ` Sascha Hauer
2013-05-07 23:30 ` Gregory CLEMENT
2 siblings, 2 replies; 63+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-04 19:51 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
On 18:51 Fri 03 May , Thomas Petazzoni wrote:
> The Marvell EBU SoCs (Kirkwood, Armada 370, Armada XP) have a BootROM
> that understand a specific image format, composed of a main header,
> several extension headers and a paylod. This image can be booted from
> NAND, SPI, SATA, UART, NOR, etc.
>
> This patch adds a tool that allows to extract the components and
> configuration of existing images, and to create new images.
I don't like this
please as on imx in barebox directly
and drop this tool
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> scripts/.gitignore | 1 +
> scripts/Makefile | 3 +-
> scripts/kwbimage.c | 1224 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 1227 insertions(+), 1 deletion(-)
> create mode 100644 scripts/kwbimage.c
>
> diff --git a/scripts/.gitignore b/scripts/.gitignore
> index 1ca6603..414de7f 100644
> --- a/scripts/.gitignore
> +++ b/scripts/.gitignore
> @@ -2,6 +2,7 @@ bareboxenv
> bin2c
> gen_netx_image
> kallsyms
> +kwbimage
> mk-am35xx-spi-image
> mkimage
> mkublheader
> diff --git a/scripts/Makefile b/scripts/Makefile
> index 08b325c..22ec4b6 100644
> --- a/scripts/Makefile
> +++ b/scripts/Makefile
> @@ -8,6 +8,7 @@ hostprogs-$(CONFIG_KALLSYMS) += kallsyms
> hostprogs-y += bin2c
> hostprogs-y += mkimage
> hostprogs-y += bareboxenv
> +hostprogs-$(CONFIG_ARCH_MVEBU) += kwbimage
> hostprogs-$(CONFIG_ARCH_NETX) += gen_netx_image
> hostprogs-$(CONFIG_ARCH_OMAP) += omap_signGP mk-am35xx-spi-image
> hostprogs-$(CONFIG_ARCH_S5PCxx) += s5p_cksum
> @@ -27,7 +28,7 @@ subdir-$(CONFIG_X86) += setupmbr
> subdir- += basic kconfig setupmbr
>
> quiet_cmd_csingle = CC $@
> - cmd_csingle = $(CC) -Wp,-MD,$(depfile) $(CFLAGS) -o $@ $<
> + cmd_csingle = $(CC) -Wp,-MD,$(depfile) $(CFLAGS) -o $@ $<
>
> obj-$(CONFIG_BAREBOXENV_TARGET) += bareboxenv-target
>
> diff --git a/scripts/kwbimage.c b/scripts/kwbimage.c
> new file mode 100644
> index 0000000..864114d
> --- /dev/null
> +++ b/scripts/kwbimage.c
> @@ -0,0 +1,1224 @@
> +/*
> + * Image manipulator for Kirkwood, Armada 370 and Armada XP platforms.
> + *
> + * (C) Copyright 2013 Thomas Petazzoni
> + * <thomas.petazzoni@free-electrons.com>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * This tool allows to extract and create bootable images for Marvell
> + * Kirkwood, Marvell Armada 370 and Armada XP SoCs. It supports two
> + * versions of the bootable image format: version 0 (used on Marvell
> + * Kirkwood) and version 1 (used on Marvell Armada 370/XP).
> + *
> + * To extract an image, run:
> + * ./scripts/kwbimage -x -i <image-file> -o <some-directory>
> + *
> + * In <some-directory>, kwbimage will output 'kwbimage.cfg', the
> + * configuration file that describes the image, 'payload', which is
> + * the bootloader code itself, and it may output a 'binary.0' file
> + * that corresponds to a binary blob (only possible in version 1
> + * images).
> + *
> + * To create an image, run:
> + * ./scripts/kwbimage -x -c <image-cfg-file> -o <image-file>
> + *
> + * The given configuration file is in the format of the 'kwbimage.cfg'
> + * file, and should reference the payload file (generally the
> + * bootloader code) and optionally a binary blob.
> + *
> + * Not implemented: support for the register headers and secure
> + * headers in v1 images
> + */
> +
> +#define _GNU_SOURCE
> +#include <stdio.h>
> +#include <stdint.h>
> +#include <sys/types.h>
> +#include <sys/stat.h>
> +#include <fcntl.h>
> +#include <unistd.h>
> +#include <sys/mman.h>
> +#include <unistd.h>
> +#include <stdlib.h>
> +#include <string.h>
> +
> +#define ALIGN_SUP(x, a) (((x) + (a - 1)) & ~(a - 1))
> +
> +/* Structure of the main header, version 0 (Kirkwood) */
> +struct main_hdr_v0 {
> + uint8_t blockid; /*0 */
> + uint8_t nandeccmode; /*1 */
> + uint16_t nandpagesize; /*2-3 */
> + uint32_t blocksize; /*4-7 */
> + uint32_t rsvd1; /*8-11 */
> + uint32_t srcaddr; /*12-15 */
> + uint32_t destaddr; /*16-19 */
> + uint32_t execaddr; /*20-23 */
> + uint8_t satapiomode; /*24 */
> + uint8_t rsvd3; /*25 */
> + uint16_t ddrinitdelay; /*26-27 */
> + uint16_t rsvd2; /*28-29 */
> + uint8_t ext; /*30 */
> + uint8_t checksum; /*31 */
> +};
> +
> +struct ext_hdr_v0_reg {
> + uint32_t raddr;
> + uint32_t rdata;
> +};
> +
> +#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20)/sizeof(struct ext_hdr_v0_reg))
> +
> +struct ext_hdr_v0 {
> + uint32_t offset;
> + uint8_t reserved[0x20 - sizeof(uint32_t)];
> + struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT];
> + uint8_t reserved2[7];
> + uint8_t checksum;
> +};
> +
> +/* Structure of the main header, version 1 (Armada 370, Armada XP) */
> +struct main_hdr_v1 {
> + uint8_t blockid; /* 0 */
> + uint8_t reserved1; /* 1 */
> + uint16_t reserved2; /* 2-3 */
> + uint32_t blocksize; /* 4-7 */
> + uint8_t version; /* 8 */
> + uint8_t headersz_msb; /* 9 */
> + uint16_t headersz_lsb; /* A-B */
> + uint32_t srcaddr; /* C-F */
> + uint32_t destaddr; /* 10-13 */
> + uint32_t execaddr; /* 14-17 */
> + uint8_t reserved3; /* 18 */
> + uint8_t nandblocksize; /* 19 */
> + uint8_t nandbadblklocation; /* 1A */
> + uint8_t reserved4; /* 1B */
> + uint16_t reserved5; /* 1C-1D */
> + uint8_t ext; /* 1E */
> + uint8_t checksum; /* 1F */
> +};
> +
> +/*
> + * Header for the optional headers, version 1 (Armada 370, Armada XP)
> + */
> +struct opt_hdr_v1 {
> + uint8_t headertype;
> + uint8_t headersz_msb;
> + uint16_t headersz_lsb;
> + char data[0];
> +};
> +
> +/*
> + * Various values for the opt_hdr_v1->headertype field, describing the
> + * different types of optional headers. The "secure" header contains
> + * informations related to secure boot (encryption keys, etc.). The
> + * "binary" header contains ARM binary code to be executed prior to
> + * executing the main payload (usually the bootloader). This is
> + * typically used to execute DDR3 training code. The "register" header
> + * allows to describe a set of (address, value) tuples that are
> + * generally used to configure the DRAM controller.
> + */
> +#define OPT_HDR_V1_SECURE_TYPE 0x1
> +#define OPT_HDR_V1_BINARY_TYPE 0x2
> +#define OPT_HDR_V1_REGISTER_TYPE 0x3
> +
> +#define KWBHEADER_V1_SIZE(hdr) \
> + (((hdr)->headersz_msb << 16) | (hdr)->headersz_lsb)
> +
> +struct boot_mode {
> + unsigned int id;
> + const char *name;
> +};
> +
> +struct boot_mode boot_modes[] = {
> + { 0x4D, "i2c" },
> + { 0x5A, "spi" },
> + { 0x8B, "nand" },
> + { 0x78, "sata" },
> + { 0x9C, "pex" },
> + { 0x69, "uart" },
> + {},
> +};
> +
> +struct nand_ecc_mode {
> + unsigned int id;
> + const char *name;
> +};
> +
> +struct nand_ecc_mode nand_ecc_modes[] = {
> + { 0x00, "default" },
> + { 0x01, "hamming" },
> + { 0x02, "rs" },
> + { 0x03, "disabled" },
> + {},
> +};
> +
> +#define BINARY_MAX_ARGS 8
> +
> +/* In-memory representation of a line of the configuration file */
> +struct image_cfg_element {
> + enum {
> + IMAGE_CFG_VERSION = 0x1,
> + IMAGE_CFG_BOOT_FROM,
> + IMAGE_CFG_DEST_ADDR,
> + IMAGE_CFG_EXEC_ADDR,
> + IMAGE_CFG_NAND_BLKSZ,
> + IMAGE_CFG_NAND_BADBLK_LOCATION,
> + IMAGE_CFG_BINARY,
> + IMAGE_CFG_PAYLOAD,
> + IMAGE_CFG_DATA,
> + } type;
> + union {
> + unsigned int version;
> + const char *boot_from;
> + struct {
> + const char *file;
> + unsigned int args[BINARY_MAX_ARGS];
> + unsigned int nargs;
> + } binary;
> + const char *payload;
> + unsigned int dstaddr;
> + unsigned int execaddr;
> + unsigned int nandblksz;
> + unsigned int nandbadblklocation;
> + struct ext_hdr_v0_reg regdata;
> + };
> +};
> +
> +/*
> + * Byte 8 of the image header contains the version number. In the v0
> + * header, byte 8 was reserved, and always set to 0. In the v1 header,
> + * byte 8 has been changed to a proper field, set to 1.
> + */
> +static unsigned int image_version(void *header)
> +{
> + unsigned char *ptr = header;
> + return ptr[8];
> +}
> +
> +/*
> + * Utility functions to manipulate boot mode and ecc modes (convert
> + * them back and forth between description strings and the
> + * corresponding numerical identifiers).
> + */
> +
> +static const char *image_boot_mode_name(unsigned int id)
> +{
> + int i;
> + for (i = 0; boot_modes[i].name; i++)
> + if (boot_modes[i].id == id)
> + return boot_modes[i].name;
> + return NULL;
> +}
> +
> +unsigned int image_boot_mode_id(const char *boot_mode_name)
> +{
> + int i;
> + for (i = 0; boot_modes[i].name; i++)
> + if (!strcmp(boot_modes[i].name, boot_mode_name))
> + return boot_modes[i].id;
> +
> + return 0;
> +}
> +
> +static const char *image_nand_ecc_mode_name(unsigned int id)
> +{
> + int i;
> + for (i = 0; nand_ecc_modes[i].name; i++)
> + if (nand_ecc_modes[i].id == id)
> + return nand_ecc_modes[i].name;
> + return NULL;
> +}
> +
> +/*
> + * Compute a 8-bit checksum of a memory area. This algorithm follows
> + * the requirements of the Marvell SoC BootROM specifications.
> + */
> +static uint8_t image_checksum8(void *start, uint32_t len)
> +{
> + uint8_t csum = 0;
> + uint8_t *p = start;
> +
> + /* check len and return zero checksum if invalid */
> + if (!len)
> + return 0;
> +
> + do {
> + csum += *p;
> + p++;
> + } while (--len);
> +
> + return csum;
> +}
> +
> +static uint32_t image_checksum32 (void *start, uint32_t len)
> +{
> + uint32_t csum = 0;
> + uint32_t *p = start;
> +
> + /* check len and return zero checksum if invalid */
> + if (!len)
> + return 0;
> +
> + if (len % sizeof(uint32_t)) {
> + fprintf (stderr, "Length %d is not in multiple of %zu\n",
> + len, sizeof(uint32_t));
> + return 0;
> + }
> +
> + do {
> + csum += *p;
> + p++;
> + len -= sizeof(uint32_t);
> + } while (len > 0);
> +
> + return csum;
> +}
> +
> +static void usage(const char *prog)
> +{
> + printf("Usage: %s [-c | -x] -i <input> -o <output>\n", prog);
> + printf(" -c: create a new image\n");
> + printf(" -x: extract an existing image\n");
> + printf(" -i: input file\n");
> + printf(" when used with -c, should point to a kwbimage.cfg file\n");
> + printf(" when used with -x, should point to the image to be extracted\n");
> + printf(" -o: output file/directory\n");
> + printf(" when used with -c, should point to the image file to create\n");
> + printf(" when used with -x, should point to a directory when the image will be extracted\n");
> +}
> +
> +static int image_extract_payload(void *payload, size_t sz, const char *output)
> +{
> + char *imageoutname;
> + FILE *imageout;
> + int ret;
> +
> + ret = asprintf(&imageoutname, "%s/payload", output);
> + if (ret < 0) {
> + fprintf(stderr, "Cannot allocate memory\n");
> + return -1;
> + }
> +
> + imageout = fopen(imageoutname, "w+");
> + if (!imageout) {
> + fprintf(stderr, "Could not open output file %s\n",
> + imageoutname);
> + free(imageoutname);
> + return -1;
> + }
> +
> + ret = fwrite(payload, sz, 1, imageout);
> + if (ret != 1) {
> + fprintf(stderr, "Could not write to open file %s\n",
> + imageoutname);
> + fclose(imageout);
> + free(imageoutname);
> + return -1;
> + }
> +
> + fclose(imageout);
> + free(imageoutname);
> + return 0;
> +}
> +
> +static int image_extract_v0(void *fdimap, const char *output, FILE *focfg)
> +{
> + struct main_hdr_v0 *main_hdr = fdimap;
> + struct ext_hdr_v0 *ext_hdr;
> + const char *boot_mode_name;
> + uint32_t *img_checksum;
> + size_t payloadsz;
> + int cksum, i;
> +
> + /*
> + * Verify checksum. When calculating the header, discard the
> + * last byte of the header, which itself contains the
> + * checksum.
> + */
> + cksum = image_checksum8(main_hdr, sizeof(struct main_hdr_v0)-1);
> + if (cksum != main_hdr->checksum) {
> + fprintf(stderr,
> + "Invalid main header checksum: 0x%08x vs. 0x%08x\n",
> + cksum, main_hdr->checksum);
> + return -1;
> + }
> +
> + boot_mode_name = image_boot_mode_name(main_hdr->blockid);
> + if (!boot_mode_name) {
> + fprintf(stderr, "Invalid boot ID: 0x%x\n",
> + main_hdr->blockid);
> + return -1;
> + }
> +
> + fprintf(focfg, "VERSION 0\n");
> + fprintf(focfg, "BOOT_FROM %s\n", boot_mode_name);
> + fprintf(focfg, "DESTADDR %08x\n", main_hdr->destaddr);
> + fprintf(focfg, "EXECADDR %08x\n", main_hdr->execaddr);
> +
> + if (!strcmp(boot_mode_name, "nand")) {
> + const char *nand_ecc_mode =
> + image_nand_ecc_mode_name(main_hdr->nandeccmode);
> + fprintf(focfg, "NAND_ECC_MODE %s\n",
> + nand_ecc_mode);
> + fprintf(focfg, "NAND_PAGE_SIZE %08x\n",
> + main_hdr->nandpagesize);
> + }
> +
> + /* No extension header, we're done */
> + if (!main_hdr->ext)
> + return 0;
> +
> + ext_hdr = fdimap + sizeof(struct main_hdr_v0);
> +
> + for (i = 0; i < EXT_HDR_V0_REG_COUNT; i++) {
> + if (ext_hdr->rcfg[i].raddr == 0 &&
> + ext_hdr->rcfg[i].rdata == 0)
> + break;
> +
> + fprintf(focfg, "DATA %08x %08x\n",
> + ext_hdr->rcfg[i].raddr,
> + ext_hdr->rcfg[i].rdata);
> + }
> +
> + /* The image is concatenated with a 32 bits checksum */
> + payloadsz = main_hdr->blocksize - sizeof(uint32_t);
> + img_checksum = (uint32_t *) (fdimap + main_hdr->srcaddr + payloadsz);
> +
> + if (*img_checksum != image_checksum32(fdimap + main_hdr->srcaddr,
> + payloadsz)) {
> + fprintf(stderr, "The image checksum does not match\n");
> + return -1;
> + }
> +
> + /* Finally, handle the image itself */
> + fprintf(focfg, "PAYLOAD %s/payload\n", output);
> + return image_extract_payload(fdimap + main_hdr->srcaddr,
> + payloadsz, output);
> +}
> +
> +static int image_extract_binary_hdr_v1(const void *binary, const char *output,
> + FILE *focfg, int hdrnum, size_t binsz)
> +{
> + char *binaryoutname;
> + FILE *binaryout;
> + const unsigned int *args;
> + unsigned int nargs;
> + int ret, i;
> +
> + args = binary;
> + nargs = args[0];
> + args++;
> +
> + ret = asprintf(&binaryoutname, "%s/binary.%d", output,
> + hdrnum);
> + if (ret < 0) {
> + fprintf(stderr, "Couldn't not allocate memory\n");
> + return ret;
> + }
> +
> + binaryout = fopen(binaryoutname, "w+");
> + if (!binaryout) {
> + fprintf(stderr, "Couldn't open output file %s\n",
> + binaryoutname);
> + free(binaryoutname);
> + return -1;
> + }
> +
> + ret = fwrite(binary + (nargs + 1) * sizeof(unsigned int),
> + binsz - (nargs + 1) * sizeof(unsigned int), 1,
> + binaryout);
> + if (ret != 1) {
> + fprintf(stderr, "Could not write to output file %s\n",
> + binaryoutname);
> + fclose(binaryout);
> + free(binaryoutname);
> + return -1;
> + }
> +
> + fclose(binaryout);
> +
> + fprintf(focfg, "BINARY %s", binaryoutname);
> + for (i = 0; i < nargs; i++)
> + fprintf(focfg, " %08x", args[i]);
> + fprintf(focfg, "\n");
> +
> + free(binaryoutname);
> +
> + return 0;
> +}
> +
> +static int image_extract_v1(void *fdimap, const char *output, FILE *focfg)
> +{
> + struct main_hdr_v1 *main_hdr = fdimap;
> + struct opt_hdr_v1 *opt_hdr;
> + const char *boot_mode_name;
> + int headersz = KWBHEADER_V1_SIZE(main_hdr);
> + int hasheaders;
> + uint8_t cksum;
> + int opthdrid;
> +
> + /*
> + * Verify the checkum. We have to substract the checksum
> + * itself, because when the checksum is calculated, the
> + * checksum field is 0.
> + */
> + cksum = image_checksum8(main_hdr, headersz);
> + cksum -= main_hdr->checksum;
> +
> + if (cksum != main_hdr->checksum) {
> + fprintf(stderr,
> + "Invalid main header checksum: 0x%08x vs. 0x%08x\n",
> + cksum, main_hdr->checksum);
> + return -1;
> + }
> +
> + /* First, take care of the main header */
> + boot_mode_name = image_boot_mode_name(main_hdr->blockid);
> + if (!boot_mode_name) {
> + fprintf(stderr, "Invalid boot ID: 0x%x\n",
> + main_hdr->blockid);
> + return -1;
> + }
> +
> + fprintf(focfg, "VERSION 1\n");
> + fprintf(focfg, "BOOT_FROM %s\n", boot_mode_name);
> + fprintf(focfg, "DESTADDR %08x\n", main_hdr->destaddr);
> + fprintf(focfg, "EXECADDR %08x\n", main_hdr->execaddr);
> + fprintf(focfg, "NAND_BLKSZ %08x\n",
> + main_hdr->nandblocksize * 64 * 1024);
> + fprintf(focfg, "NAND_BADBLK_LOCATION %02x\n",
> + main_hdr->nandbadblklocation);
> +
> + hasheaders = main_hdr->ext;
> + opt_hdr = fdimap + sizeof(struct main_hdr_v1);
> + opthdrid = 0;
> +
> + /* Then, go through all the extension headers */
> + while (hasheaders) {
> + int opthdrsz = KWBHEADER_V1_SIZE(opt_hdr);
> +
> + switch (opt_hdr->headertype) {
> + case OPT_HDR_V1_BINARY_TYPE:
> + image_extract_binary_hdr_v1(opt_hdr->data, output,
> + focfg, opthdrid,
> + opthdrsz -
> + sizeof(struct opt_hdr_v1));
> + break;
> + case OPT_HDR_V1_SECURE_TYPE:
> + case OPT_HDR_V1_REGISTER_TYPE:
> + fprintf(stderr,
> + "Support for header type 0x%x not implemented\n",
> + opt_hdr->headertype);
> + exit(1);
> + break;
> + default:
> + fprintf(stderr, "Invalid header type 0x%x\n",
> + opt_hdr->headertype);
> + exit(1);
> + }
> +
> + /*
> + * The first byte of the last double word of the
> + * current header indicates whether there is a next
> + * header or not.
> + */
> + hasheaders = ((char *)opt_hdr)[opthdrsz - 4];
> +
> + /* Move to the next header */
> + opt_hdr = ((void *)opt_hdr) + opthdrsz;
> + opthdrid++;
> + }
> +
> + /* Finally, handle the image itself */
> + fprintf(focfg, "PAYLOAD %s/payload\n", output);
> + return image_extract_payload(fdimap + main_hdr->srcaddr,
> + main_hdr->blocksize - 4,
> + output);
> +}
> +
> +static int image_extract(const char *input, const char *output)
> +{
> + int fdi, ret;
> + struct stat fdistat, fdostat;
> + void *fdimap;
> + char *focfgname;
> + FILE *focfg;
> +
> + fdi = open(input, O_RDONLY);
> + if (fdi < 0) {
> + fprintf(stderr, "Cannot open input file %s: %m\n",
> + input);
> + return -1;
> + }
> +
> + ret = fstat(fdi, &fdistat);
> + if (ret < 0) {
> + fprintf(stderr, "Cannot stat input file %s: %m\n",
> + input);
> + close(fdi);
> + return -1;
> + }
> +
> + fdimap = mmap(NULL, fdistat.st_size, PROT_READ, MAP_PRIVATE, fdi, 0);
> + if (fdimap == MAP_FAILED) {
> + fprintf(stderr, "Cannot map input file %s: %m\n",
> + input);
> + close(fdi);
> + return -1;
> + }
> +
> + close(fdi);
> +
> + ret = stat(output, &fdostat);
> + if (ret < 0) {
> + fprintf(stderr, "Cannot stat output directory %s: %m\n",
> + output);
> + munmap(fdimap, fdistat.st_size);
> + return -1;
> + }
> +
> + if (!S_ISDIR(fdostat.st_mode)) {
> + fprintf(stderr, "Output %s should be a directory\n",
> + output);
> + munmap(fdimap, fdistat.st_size);
> + return -1;
> + }
> +
> + ret = asprintf(&focfgname, "%s/kwbimage.cfg", output);
> + if (ret < 0) {
> + fprintf(stderr, "Failed to allocate memory\n");
> + munmap(fdimap, fdistat.st_size);
> + return -1;
> + }
> +
> + focfg = fopen(focfgname, "w+");
> + if (!focfg) {
> + fprintf(stderr, "Output file %s could not be created\n",
> + focfgname);
> + free(focfgname);
> + munmap(fdimap, fdistat.st_size);
> + return -1;
> + }
> +
> + free(focfgname);
> +
> + if (image_version(fdimap) == 0)
> + ret = image_extract_v0(fdimap, output, focfg);
> + else if (image_version(fdimap) == 1)
> + ret = image_extract_v1(fdimap, output, focfg);
> + else {
> + fprintf(stderr, "Invalid image version %d\n",
> + image_version(fdimap));
> + ret = -1;
> + }
> +
> + fclose(focfg);
> + munmap(fdimap, fdistat.st_size);
> + return ret;
> +}
> +
> +static int image_create_payload(void *payload_start, size_t payloadsz,
> + const char *payload_filename)
> +{
> + FILE *payload;
> + uint32_t *payload_checksum =
> + (uint32_t *) (payload_start + payloadsz);
> + int ret;
> +
> + payload = fopen(payload_filename, "r");
> + if (!payload) {
> + fprintf(stderr, "Cannot open payload file %s\n",
> + payload_filename);
> + return -1;
> + }
> +
> + ret = fread(payload_start, payloadsz, 1, payload);
> + if (ret != 1) {
> + fprintf(stderr, "Cannot read payload file %s\n",
> + payload_filename);
> + return -1;
> + }
> +
> + fclose(payload);
> +
> + *payload_checksum = image_checksum32(payload_start, payloadsz);
> + return 0;
> +}
> +
> +static void *image_create_v0(struct image_cfg_element *image_cfg,
> + int cfgn, const char *output, size_t *imagesz)
> +{
> + size_t headersz, payloadsz, totalsz;
> + struct main_hdr_v0 *main_hdr;
> + struct ext_hdr_v0 *ext_hdr;
> + void *image;
> + int has_ext = 0;
> + int cfgi, ret;
> +
> + /* Calculate the size of the header and the size of the
> + * payload */
> + headersz = sizeof(struct main_hdr_v0);
> + payloadsz = 0;
> + for (cfgi = 0; cfgi < cfgn; cfgi++) {
> + struct image_cfg_element *el = &image_cfg[cfgi];
> + if (el->type == IMAGE_CFG_DATA)
> + has_ext = 1;
> + else if (el->type == IMAGE_CFG_PAYLOAD) {
> + struct stat s;
> + int ret;
> +
> + ret = stat(el->payload, &s);
> + if (ret < 0) {
> + fprintf(stderr, "Cannot stat payload file %s\n",
> + el->payload);
> + return NULL;
> + }
> +
> + payloadsz = s.st_size;
> + }
> + }
> +
> + if (has_ext)
> + headersz += sizeof(struct ext_hdr_v0);
> +
> + /* Headers, payload and 32-bits checksum */
> + totalsz = headersz + payloadsz + sizeof(uint32_t);
> +
> + image = malloc(totalsz);
> + if (!image) {
> + fprintf(stderr, "Cannot allocate memory for image\n");
> + return NULL;
> + }
> +
> + memset(image, 0, totalsz);
> +
> + main_hdr = image;
> +
> + /* Fill in the main header */
> + main_hdr->blocksize = payloadsz + sizeof(uint32_t);
> + main_hdr->srcaddr = headersz;
> + main_hdr->ext = has_ext;
> + for (cfgi = 0; cfgi < cfgn; cfgi++) {
> + struct image_cfg_element *el = &image_cfg[cfgi];
> + if (el->type == IMAGE_CFG_BOOT_FROM)
> + main_hdr->blockid = image_boot_mode_id(el->boot_from);
> + else if (el->type == IMAGE_CFG_DEST_ADDR)
> + main_hdr->destaddr = el->dstaddr;
> + else if (el->type == IMAGE_CFG_EXEC_ADDR)
> + main_hdr->execaddr = el->execaddr;
> + else if (el->type != IMAGE_CFG_VERSION)
> + break;
> + }
> +
> + main_hdr->checksum = image_checksum8(image,
> + sizeof(struct main_hdr_v0));
> +
> + /* Generate the ext header */
> + if (has_ext) {
> + int datai = 0;
> +
> + ext_hdr = image + sizeof(struct main_hdr_v0);
> + ext_hdr->offset = 0x40;
> +
> + for (; cfgi < cfgn; cfgi++) {
> + struct image_cfg_element *el = &image_cfg[cfgi];
> + if (el->type == IMAGE_CFG_DATA) {
> + ext_hdr->rcfg[datai].raddr = el->regdata.raddr;
> + ext_hdr->rcfg[datai].rdata = el->regdata.rdata;
> + datai++;
> + }
> + else if (el->type == IMAGE_CFG_PAYLOAD)
> + break;
> + else {
> + fprintf(stderr, "Invalid element of type %d\n",
> + el->type);
> + return NULL;
> + }
> + }
> +
> + ext_hdr->checksum = image_checksum8(ext_hdr,
> + sizeof(struct ext_hdr_v0));
> + }
> +
> + /* Now, time to take care of the payload, if any */
> + if (image_cfg[cfgi].type == IMAGE_CFG_PAYLOAD) {
> + if (cfgi != cfgn - 1) {
> + fprintf(stderr,
> + "There should always be only one payload, and it should be the last element\n");
> + return NULL;
> + }
> +
> + ret = image_create_payload(image + headersz, payloadsz,
> + image_cfg[cfgi].payload);
> + if (ret < 0)
> + return NULL;
> + }
> +
> + *imagesz = totalsz;
> + return image;
> +}
> +
> +static void *image_create_v1(struct image_cfg_element *image_cfg,
> + int cfgn, const char *output, size_t *imagesz)
> +{
> + struct main_hdr_v1 *main_hdr;
> + size_t headersz, payloadsz, totalsz;
> + void *image, *cur;
> + int hasext = 0;
> + int cfgi, ret;
> +
> + /* Calculate the size of the header and the size of the
> + * payload */
> + headersz = sizeof(struct main_hdr_v1);
> + payloadsz = 0;
> + for (cfgi = 0; cfgi < cfgn; cfgi++) {
> + struct image_cfg_element *el = &image_cfg[cfgi];
> + if (el->type == IMAGE_CFG_BINARY) {
> + struct stat s;
> +
> + ret = stat(el->binary.file, &s);
> + if (ret < 0) {
> + fprintf(stderr, "Cannot stat binary file %s\n",
> + el->binary.file);
> + return NULL;
> + }
> +
> + headersz += s.st_size +
> + el->binary.nargs * sizeof(unsigned int);
> + hasext = 1;
> + } else if (el->type == IMAGE_CFG_PAYLOAD) {
> + struct stat s;
> +
> + ret = stat(el->payload, &s);
> + if (ret < 0) {
> + fprintf(stderr, "Cannot stat payload file %s\n",
> + el->payload);
> + return NULL;
> + }
> +
> + payloadsz = s.st_size;
> + }
> + }
> +
> + /* The payload should be aligned on some reasonable
> + * boundary */
> + headersz = ALIGN_SUP(headersz, 4096);
> +
> + /* The total size includes the headers, the payload, and the
> + * 32 bits checksum at the end of the payload */
> + totalsz = headersz + payloadsz + sizeof(uint32_t);
> +
> + image = malloc(totalsz);
> + if (!image) {
> + fprintf(stderr, "Cannot allocate memory for image\n");
> + return NULL;
> + }
> +
> + memset(image, 0, totalsz);
> +
> + cur = main_hdr = image;
> + cur += sizeof(struct main_hdr_v1);
> +
> + main_hdr->blocksize = payloadsz + sizeof(uint32_t);
> + main_hdr->headersz_lsb = headersz & 0xFFFF;
> + main_hdr->headersz_msb = (headersz & 0xFFFF0000) >> 16;
> + main_hdr->srcaddr = headersz;
> + main_hdr->ext = hasext;
> +
> + /* First, take care of filling the main header */
> + for (cfgi = 0; cfgi < cfgn; cfgi++) {
> + struct image_cfg_element *el = &image_cfg[cfgi];
> + if (el->type == IMAGE_CFG_VERSION)
> + main_hdr->version = 1;
> + else if (el->type == IMAGE_CFG_BOOT_FROM)
> + main_hdr->blockid = image_boot_mode_id(el->boot_from);
> + else if (el->type == IMAGE_CFG_DEST_ADDR)
> + main_hdr->destaddr = el->dstaddr;
> + else if (el->type == IMAGE_CFG_EXEC_ADDR)
> + main_hdr->execaddr = el->execaddr;
> + else if (el->type == IMAGE_CFG_NAND_BLKSZ)
> + main_hdr->nandblocksize = el->nandblksz / (64 * 1024);
> + else if (el->type == IMAGE_CFG_NAND_BADBLK_LOCATION)
> + main_hdr->nandbadblklocation = el->nandbadblklocation;
> + else
> + break;
> + }
> +
> + /* Then, fill the extension headers */
> + for (; cfgi < cfgn; cfgi++) {
> + struct image_cfg_element *el = &image_cfg[cfgi];
> +
> + if (el->type == IMAGE_CFG_BINARY) {
> + struct opt_hdr_v1 *hdr = cur;
> + unsigned int *args;
> + size_t binhdrsz;
> + struct stat s;
> + int argi;
> + FILE *bin;
> +
> + hdr->headertype = OPT_HDR_V1_BINARY_TYPE;
> +
> + bin = fopen(el->binary.file, "r");
> + if (!bin) {
> + fprintf(stderr, "Cannot open binary file %s\n",
> + el->binary.file);
> + return NULL;
> + }
> +
> + fstat(fileno(bin), &s);
> +
> + binhdrsz = sizeof(struct opt_hdr_v1) +
> + (el->binary.nargs + 1) * sizeof(unsigned int) +
> + s.st_size;
> + hdr->headersz_lsb = binhdrsz & 0xFFFF;
> + hdr->headersz_msb = (binhdrsz & 0xFFFF0000) >> 16;
> +
> + cur += sizeof(struct opt_hdr_v1);
> +
> + args = cur;
> + *args = el->binary.nargs;
> + args++;
> + for (argi = 0; argi < el->binary.nargs; argi++)
> + args[argi] = el->binary.args[argi];
> +
> + cur += (el->binary.nargs + 1) * sizeof(unsigned int);
> +
> + ret = fread(cur, s.st_size, 1, bin);
> + if (ret != 1) {
> + fprintf(stderr,
> + "Could not read binary image %s\n",
> + el->binary.file);
> + return NULL;
> + }
> +
> + fclose(bin);
> +
> + cur += s.st_size;
> +
> + /* See if we have a next header or not, and if
> + * so, add the marker indicating that we are
> + * not the last header */
> + if ((cfgi < (cfgn - 1)) &&
> + (image_cfg[cfgi + 1].type != IMAGE_CFG_PAYLOAD))
> + *((unsigned char *) cur) = 1;
> + cur += sizeof(uint32_t);
> + } else if (el->type == IMAGE_CFG_PAYLOAD)
> + break;
> + else {
> + fprintf(stderr, "Invalid element type %d (cfgi=%d)\n",
> + el->type, cfgi);
> + return NULL;
> + }
> + }
> +
> + /* Calculate and set the header checksum */
> + main_hdr->checksum = image_checksum8(main_hdr, headersz);
> +
> + /* Now, time to take care of the payload, if any */
> + if (image_cfg[cfgi].type == IMAGE_CFG_PAYLOAD) {
> + if (cfgi != cfgn - 1) {
> + fprintf(stderr,
> + "There should always be only one payload, and it should be the last element\n");
> + return NULL;
> + }
> +
> + ret = image_create_payload(image + headersz, payloadsz,
> + image_cfg[cfgi].payload);
> + if (ret < 0)
> + return NULL;
> + }
> +
> + *imagesz = totalsz;
> + return image;
> +}
> +
> +static int image_create_config_parse_oneline(char *line,
> + struct image_cfg_element *el)
> +{
> + char *keyword, *saveptr;
> +
> + keyword = strtok_r(line, " ", &saveptr);
> + if (!strcmp(keyword, "VERSION")) {
> + char *value = strtok_r(NULL, " ", &saveptr);
> + el->type = IMAGE_CFG_VERSION;
> + el->version = atoi(value);
> + } else if (!strcmp(keyword, "BOOT_FROM")) {
> + char *value = strtok_r(NULL, " ", &saveptr);
> + el->type = IMAGE_CFG_BOOT_FROM;
> + el->boot_from = strdup(value);
> + } else if (!strcmp(keyword, "DESTADDR")) {
> + char *value = strtok_r(NULL, " ", &saveptr);
> + el->type = IMAGE_CFG_DEST_ADDR;
> + el->dstaddr = strtol(value, NULL, 16);
> + } else if (!strcmp(keyword, "EXECADDR")) {
> + char *value = strtok_r(NULL, " ", &saveptr);
> + el->type = IMAGE_CFG_EXEC_ADDR;
> + el->execaddr = strtol(value, NULL, 16);
> + } else if (!strcmp(keyword, "NAND_BLKSZ")) {
> + char *value = strtok_r(NULL, " ", &saveptr);
> + el->type = IMAGE_CFG_NAND_BLKSZ;
> + el->nandblksz = strtol(value, NULL, 16);
> + } else if (!strcmp(keyword, "NAND_BADBLK_LOCATION")) {
> + char *value = strtok_r(NULL, " ", &saveptr);
> + el->type = IMAGE_CFG_NAND_BADBLK_LOCATION;
> + el->nandbadblklocation =
> + strtol(value, NULL, 16);
> + } else if (!strcmp(keyword, "BINARY")) {
> + char *value = strtok_r(NULL, " ", &saveptr);
> + int argi = 0;
> +
> + el->type = IMAGE_CFG_BINARY;
> + el->binary.file = strdup(value);
> + while (1) {
> + value = strtok_r(NULL, " ", &saveptr);
> + if (!value)
> + break;
> + el->binary.args[argi] = strtol(value, NULL, 16);
> + argi++;
> + if (argi >= BINARY_MAX_ARGS) {
> + fprintf(stderr,
> + "Too many argument for binary\n");
> + return -1;
> + }
> + }
> + el->binary.nargs = argi;
> + } else if (!strcmp(keyword, "DATA")) {
> + char *value1 = strtok_r(NULL, " ", &saveptr);
> + char *value2 = strtok_r(NULL, " ", &saveptr);
> +
> + if (!value1 || !value2) {
> + fprintf(stderr, "Invalid number of arguments for DATA\n");
> + return -1;
> + }
> +
> + el->type = IMAGE_CFG_DATA;
> + el->regdata.raddr = strtol(value1, NULL, 16);
> + el->regdata.rdata = strtol(value2, NULL, 16);
> + } else if (!strcmp(keyword, "PAYLOAD")) {
> + char *value = strtok_r(NULL, " ", &saveptr);
> + el->type = IMAGE_CFG_PAYLOAD;
> + el->payload = strdup(value);
> + } else {
> + fprintf(stderr, "Ignoring unknown line '%s'\n", line);
> + }
> +
> + return 0;
> +}
> +
> +static int image_create_config_parse(FILE *fcfg,
> + struct image_cfg_element *image_cfg)
> +{
> + int ret;
> + int cfgi = 0;
> +
> + /* Parse the configuration file */
> + while (!feof(fcfg)) {
> + char *line;
> + char buf[256];
> +
> + /* Read the current line */
> + memset(buf, 0, sizeof(buf));
> + line = fgets(buf, sizeof(buf), fcfg);
> + if (!line)
> + break;
> +
> + /* Ignore useless lines */
> + if (line[0] == '\n' || line[0] == '#')
> + continue;
> +
> + /* Strip final newline */
> + if (line[strlen(line) - 1] == '\n')
> + line[strlen(line) - 1] = 0;
> +
> + /* Parse the current line */
> + ret = image_create_config_parse_oneline(line,
> + &image_cfg[cfgi]);
> + if (ret)
> + return ret;
> +
> + cfgi++;
> + }
> +
> + return 0;
> +}
> +
> +static int image_create_config_count_lines(FILE *fcfg)
> +{
> + int lines = 0;
> +
> + /* Count number of useful lines */
> + while (!feof(fcfg)) {
> + char *line;
> + char buf[256];
> + memset(buf, 0, sizeof(buf));
> + line = fgets(buf, sizeof(buf), fcfg);
> + if (!line)
> + break;
> + if (line[0] == '\n' || line[0] == '#')
> + continue;
> + lines++;
> + }
> +
> + return lines;
> +}
> +
> +static int image_create(const char *input, const char *output)
> +{
> + struct image_cfg_element *image_cfg;
> + FILE *fcfg, *outputimg;
> + void *image = NULL;
> + int version = -1;
> + size_t imagesz;
> + int lines;
> + int cfgi;
> + int ret;
> +
> + fcfg = fopen(input, "r");
> + if (!fcfg) {
> + fprintf(stderr, "Could not open input file %s\n",
> + input);
> + return -1;
> + }
> +
> + lines = image_create_config_count_lines(fcfg);
> + if (lines == 0) {
> + fprintf(stderr, "Configuration file %s is empty\n",
> + input);
> + return -1;
> + }
> +
> + image_cfg = malloc(lines * sizeof(struct image_cfg_element));
> + if (!image_cfg) {
> + fprintf(stderr, "Cannot allocate memory\n");
> + fclose(fcfg);
> + return -1;
> + }
> +
> + memset(image_cfg, 0, lines * sizeof(struct image_cfg_element));
> + rewind(fcfg);
> +
> + ret = image_create_config_parse(fcfg, image_cfg);
> + if (ret)
> + return -1;
> +
> + for (cfgi = 0; cfgi < lines; cfgi++) {
> + if (image_cfg[cfgi].type != IMAGE_CFG_VERSION)
> + continue;
> +
> + version = image_cfg[cfgi].version;
> + break;
> + }
> +
> + if (version == -1) {
> + fprintf(stderr, "File %s does not have the VERSION field\n",
> + input);
> + return -1;
> + }
> +
> + if (version == 0)
> + image = image_create_v0(image_cfg, lines, output, &imagesz);
> + else if (version == 1)
> + image = image_create_v1(image_cfg, lines, output, &imagesz);
> +
> + if (!image) {
> + fprintf(stderr, "Could not create image\n");
> + return -1;
> + }
> +
> + outputimg = fopen(output, "w");
> + if (!outputimg) {
> + fprintf(stderr, "Cannot open output image %s for writing\n",
> + output);
> + return -1;
> + }
> +
> + ret = fwrite(image, imagesz, 1, outputimg);
> + if (ret != 1) {
> + fprintf(stderr, "Cannot write to output image %s\n",
> + output);
> + return -1;
> + }
> +
> + fclose(outputimg);
> + free(image);
> +
> + return 0;
> +}
> +
> +enum {
> + ACTION_CREATE,
> + ACTION_EXTRACT,
> + ACTION_DUMP,
> + ACTION_HELP,
> +};
> +
> +int main(int argc, char *argv[])
> +{
> + int action = -1, opt;
> + const char *input = NULL, *output = NULL;
> +
> + while ((opt = getopt(argc, argv, "hxci:o:")) != -1) {
> + switch (opt) {
> + case 'x':
> + action = ACTION_EXTRACT;
> + break;
> + case 'c':
> + action = ACTION_CREATE;
> + break;
> + case 'i':
> + input = optarg;
> + break;
> + case 'o':
> + output = optarg;
> + break;
> + case 'h':
> + action = ACTION_HELP;
> + break;
> + }
> + }
> +
> + /* We should have consumed all arguments */
> + if (optind != argc) {
> + usage(argv[0]);
> + exit(1);
> + }
> +
> + if (action != ACTION_HELP && !input) {
> + fprintf(stderr, "Missing input file\n");
> + usage(argv[0]);
> + exit(1);
> + }
> +
> + if ((action == ACTION_EXTRACT || action == ACTION_CREATE) &&
> + !output) {
> + fprintf(stderr, "Missing output file\n");
> + usage(argv[1]);
> + exit(1);
> + }
> +
> + switch (action) {
> + case ACTION_EXTRACT:
> + return image_extract(input, output);
> + case ACTION_CREATE:
> + return image_create(input, output);
> + case ACTION_HELP:
> + usage(argv[0]);
> + return 0;
> + default:
> + fprintf(stderr, "No action specified\n");
> + usage(argv[0]);
> + exit(1);
> + }
> +
> + return 0;
> +}
> --
> 1.7.9.5
>
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-04 19:51 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2013-05-04 20:32 ` Jason Cooper
2013-05-05 6:40 ` Sascha Hauer
2013-05-05 11:19 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 19:41 ` Sascha Hauer
1 sibling, 2 replies; 63+ messages in thread
From: Jason Cooper @ 2013-05-04 20:32 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Lior Amsalem, Willy Tarreau, Ezequiel Garcia, barebox
On Sat, May 04, 2013 at 09:51:25PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 18:51 Fri 03 May , Thomas Petazzoni wrote:
> > The Marvell EBU SoCs (Kirkwood, Armada 370, Armada XP) have a BootROM
> > that understand a specific image format, composed of a main header,
> > several extension headers and a paylod. This image can be booted from
> > NAND, SPI, SATA, UART, NOR, etc.
> >
> > This patch adds a tool that allows to extract the components and
> > configuration of existing images, and to create new images.
>
> I don't like this
Why?
> please as on imx in barebox directly
what? Could you please explain?
thx,
Jason.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-04 20:32 ` Jason Cooper
@ 2013-05-05 6:40 ` Sascha Hauer
2013-05-05 11:19 ` Jean-Christophe PLAGNIOL-VILLARD
1 sibling, 0 replies; 63+ messages in thread
From: Sascha Hauer @ 2013-05-05 6:40 UTC (permalink / raw)
To: Jason Cooper; +Cc: Lior Amsalem, barebox, Ezequiel Garcia, Willy Tarreau
On Sat, May 04, 2013 at 04:32:13PM -0400, Jason Cooper wrote:
> On Sat, May 04, 2013 at 09:51:25PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 18:51 Fri 03 May , Thomas Petazzoni wrote:
> > > The Marvell EBU SoCs (Kirkwood, Armada 370, Armada XP) have a BootROM
> > > that understand a specific image format, composed of a main header,
> > > several extension headers and a paylod. This image can be booted from
> > > NAND, SPI, SATA, UART, NOR, etc.
> > >
> > > This patch adds a tool that allows to extract the components and
> > > configuration of existing images, and to create new images.
> >
> > I don't like this
>
> Why?
>
> > please as on imx in barebox directly
>
> what? Could you please explain?
I can only guess that he means that he doesn't want to have a separate
tool for generating images but instead wants to generate the images
using C structures in the original binary like we do on i.MX currently.
Anyway, what we do on i.MX doesn't really scale anymore since the more
complicated features of the image format can't be used with C
structures. I'm working on replacing this with a imx-image tool.
You seem to use checksums in your images. These can't be generated
in C or CPP anyway.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-04 20:32 ` Jason Cooper
2013-05-05 6:40 ` Sascha Hauer
@ 2013-05-05 11:19 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-05 11:40 ` Willy Tarreau
` (2 more replies)
1 sibling, 3 replies; 63+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-05 11:19 UTC (permalink / raw)
To: Jason Cooper; +Cc: Lior Amsalem, Willy Tarreau, Ezequiel Garcia, barebox
On 16:32 Sat 04 May , Jason Cooper wrote:
> On Sat, May 04, 2013 at 09:51:25PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 18:51 Fri 03 May , Thomas Petazzoni wrote:
> > > The Marvell EBU SoCs (Kirkwood, Armada 370, Armada XP) have a BootROM
> > > that understand a specific image format, composed of a main header,
> > > several extension headers and a paylod. This image can be booted from
> > > NAND, SPI, SATA, UART, NOR, etc.
> > >
> > > This patch adds a tool that allows to extract the components and
> > > configuration of existing images, and to create new images.
> >
> > I don't like this
>
> Why?
to geneate a simple header do it in C not with a tools
>
> > please as on imx in barebox directly
>
> what? Could you please explain?
read the imx code we do it in C and place it at the begenning of the binary so
no need such tools and we can use linker scirpt and CONFIG_xx
Stop to think u-boot here
>
> thx,
>
> Jason.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-05 11:19 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2013-05-05 11:40 ` Willy Tarreau
2013-05-06 13:53 ` Thomas Petazzoni
2013-05-07 6:44 ` Sascha Hauer
2 siblings, 0 replies; 63+ messages in thread
From: Willy Tarreau @ 2013-05-05 11:40 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Lior Amsalem, Jason Cooper, Ezequiel Garcia, barebox
On Sun, May 05, 2013 at 01:19:27PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 16:32 Sat 04 May , Jason Cooper wrote:
> > On Sat, May 04, 2013 at 09:51:25PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 18:51 Fri 03 May , Thomas Petazzoni wrote:
> > > > The Marvell EBU SoCs (Kirkwood, Armada 370, Armada XP) have a BootROM
> > > > that understand a specific image format, composed of a main header,
> > > > several extension headers and a paylod. This image can be booted from
> > > > NAND, SPI, SATA, UART, NOR, etc.
> > > >
> > > > This patch adds a tool that allows to extract the components and
> > > > configuration of existing images, and to create new images.
> > >
> > > I don't like this
> >
> > Why?
> to geneate a simple header do it in C not with a tools
> >
> > > please as on imx in barebox directly
> >
> > what? Could you please explain?
>
> read the imx code we do it in C and place it at the begenning of the binary so
> no need such tools and we can use linker scirpt and CONFIG_xx
>
> Stop to think u-boot here
I don't see why you're talking about u-boot here, the tool is needed to
extract a binary payload from existing images in order to reuse it with
new images. Now whether you'd prefer have some C code contain a dump of
this 48kB payload or have a tool to build the final image will not change
the fact that such an extraction tool is needed anyway.
Willy
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-05 11:19 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-05 11:40 ` Willy Tarreau
@ 2013-05-06 13:53 ` Thomas Petazzoni
2013-05-06 13:54 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-07 6:44 ` Sascha Hauer
2 siblings, 1 reply; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-06 13:53 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
Dear Jean-Christophe PLAGNIOL-VILLARD,
On Sun, 5 May 2013 13:19:27 +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> > > > This patch adds a tool that allows to extract the components and
> > > > configuration of existing images, and to create new images.
> > >
> > > I don't like this
> >
> > Why?
> to geneate a simple header do it in C not with a tools
Then it seems like you haven't read the code at all. The 'simple
header' has the following properties:
* Is of variable length: it contains a main header, and an optional
arbitrary number of binary headers, security headers and register
headers.
* A 8-bit checksum that covers the entire size of headers. This cannot
be easily computed directly by compiling C code and using linker
scrips.
* A 32-bit checksum that covers the binary payload.
* The contents of the binary header are extracted from existing boot
images for Armada 370/XP platforms because this binary header
contains some DDR3 training code that I haven't worked on for now.
And since this binary header is cleanly isolated from the bootloader
itself, it is easier to re-use such binary code for now.
The tool also allows to extract binary images, which is needed to
extract the binary header mentioned above, and re-use when building a
bootable image that includes Barebox.
> read the imx code we do it in C and place it at the begenning of the binary so
> no need such tools and we can use linker scirpt and CONFIG_xx
>
> Stop to think u-boot here
Could you please adopt a nicer language? You are very aggressive... and
at that the same time completely wrong. Your comments make it entirely
clear that you haven't even read the comments at the top of file.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 13:53 ` Thomas Petazzoni
@ 2013-05-06 13:54 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 14:06 ` Thomas Petazzoni
0 siblings, 1 reply; 63+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-06 13:54 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
On 15:53 Mon 06 May , Thomas Petazzoni wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> On Sun, 5 May 2013 13:19:27 +0200, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>
> > > > > This patch adds a tool that allows to extract the components and
> > > > > configuration of existing images, and to create new images.
> > > >
> > > > I don't like this
> > >
> > > Why?
> > to geneate a simple header do it in C not with a tools
>
> Then it seems like you haven't read the code at all. The 'simple
> header' has the following properties:
>
> * Is of variable length: it contains a main header, and an optional
> arbitrary number of binary headers, security headers and register
> headers.
>
> * A 8-bit checksum that covers the entire size of headers. This cannot
> be easily computed directly by compiling C code and using linker
> scrips.
>
> * A 32-bit checksum that covers the binary payload.
>
> * The contents of the binary header are extracted from existing boot
> images for Armada 370/XP platforms because this binary header
> contains some DDR3 training code that I haven't worked on for now.
> And since this binary header is cleanly isolated from the bootloader
> itself, it is easier to re-use such binary code for now.
>
> The tool also allows to extract binary images, which is needed to
> extract the binary header mentioned above, and re-use when building a
> bootable image that includes Barebox.
>
> > read the imx code we do it in C and place it at the begenning of the binary so
> > no need such tools and we can use linker scirpt and CONFIG_xx
> >
> > Stop to think u-boot here
>
> Could you please adopt a nicer language? You are very aggressive... and
> at that the same time completely wrong. Your comments make it entirely
> clear that you haven't even read the comments at the top of file.
I did but still think we can handle it in C
and need to handle by barebox itself when flashing
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 13:54 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2013-05-06 14:06 ` Thomas Petazzoni
2013-05-06 14:04 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 1 reply; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-06 14:06 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
Dear Jean-Christophe PLAGNIOL-VILLARD,
On Mon, 6 May 2013 15:54:35 +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> > Could you please adopt a nicer language? You are very aggressive... and
> > at that the same time completely wrong. Your comments make it entirely
> > clear that you haven't even read the comments at the top of file.
> I did but still think we can handle it in C
>
> and need to handle by barebox itself when flashing
The image is pushed to the target through X-modem, directly talking to
the ROM code of the SoC. Do you want the kwboot tool to prepare the
image? It seems to me like it makes a lot more sense to have a tool to
prepare the image.
Remember also that this tool is needed to *extract* existing images.
And you haven't explained how you intend to do this without a proper
userspace tool such as kwbimage.
And by the way, the tool is a simple userspace tool written entirely in
C, I'm not sure to see where the problem is.
Quoting Sascha, an e-mail for this thread:
"""
Anyway, what we do on i.MX doesn't really scale anymore since the more
complicated features of the image format can't be used with C
structures. I'm working on replacing this with a imx-image tool.
You seem to use checksums in your images. These can't be generated
in C or CPP anyway.
"""
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 14:06 ` Thomas Petazzoni
@ 2013-05-06 14:04 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 14:13 ` Thomas Petazzoni
2013-05-06 14:21 ` Jason Cooper
0 siblings, 2 replies; 63+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-06 14:04 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
On 16:06 Mon 06 May , Thomas Petazzoni wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> On Mon, 6 May 2013 15:54:35 +0200, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>
> > > Could you please adopt a nicer language? You are very aggressive... and
> > > at that the same time completely wrong. Your comments make it entirely
> > > clear that you haven't even read the comments at the top of file.
> > I did but still think we can handle it in C
> >
> > and need to handle by barebox itself when flashing
>
> The image is pushed to the target through X-modem, directly talking to
> the ROM code of the SoC. Do you want the kwboot tool to prepare the
> image? It seems to me like it makes a lot more sense to have a tool to
> prepare the image.
yes a you want to re-flash barebox itself and you will do for ddr and I do not
want to care about all of this blob stuff twht the board already known
>
> Remember also that this tool is needed to *extract* existing images.
> And you haven't explained how you intend to do this without a proper
> userspace tool such as kwbimage.
why extract?
you generated at runtime
>
> And by the way, the tool is a simple userspace tool written entirely in
> C, I'm not sure to see where the problem is.
>
> Quoting Sascha, an e-mail for this thread:
>
> """
> Anyway, what we do on i.MX doesn't really scale anymore since the more
> complicated features of the image format can't be used with C
> structures. I'm working on replacing this with a imx-image tool.
> You seem to use checksums in your images. These can't be generated
> in C or CPP anyway.
> """
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 14:04 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2013-05-06 14:13 ` Thomas Petazzoni
2013-05-06 14:14 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 14:21 ` Jason Cooper
1 sibling, 1 reply; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-06 14:13 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
Dear Jean-Christophe PLAGNIOL-VILLARD,
On Mon, 6 May 2013 16:04:39 +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> > > > Could you please adopt a nicer language? You are very aggressive... and
> > > > at that the same time completely wrong. Your comments make it entirely
> > > > clear that you haven't even read the comments at the top of file.
> > > I did but still think we can handle it in C
> > >
> > > and need to handle by barebox itself when flashing
> >
> > The image is pushed to the target through X-modem, directly talking to
> > the ROM code of the SoC. Do you want the kwboot tool to prepare the
> > image? It seems to me like it makes a lot more sense to have a tool to
> > prepare the image.
>
> yes a you want to re-flash barebox itself and you will do for ddr and I do not
> want to care about all of this blob stuff twht the board already known
Sorry, but I don't understand what you're trying to explain here, your
english sentence doesn't make sense.
The binary blob is needed for now. I've intentionally written a tool
that allows people to extract this binary blob from their existing
bootloader image so we don't have to store this binary blob anywhere in
the Barebox tree. As I explained, getting a working DDR3 training code
will be something that can be done later on, but it's not yet my
priority.
> > Remember also that this tool is needed to *extract* existing images.
> > And you haven't explained how you intend to do this without a proper
> > userspace tool such as kwbimage.
>
> why extract?
>
> you generated at runtime
1) Because it's useful to extract the various parameters of an
existing bootloader image, to see how it was built by the vendor to
use the same parameters. For example, for Kirkwood SoCs, the header
contains the values to put in the DRAM controller to configure the
right timings, and it is useful to extract those values into a
configuration file, later used to create a shiny new image that
contains Barebox.
2) Because it's useful to extract the binary blob needed to configure
the DDR3 timing dynamically (for Armada 370/XP).
> > Quoting Sascha, an e-mail for this thread:
> >
> > """
> > Anyway, what we do on i.MX doesn't really scale anymore since the more
> > complicated features of the image format can't be used with C
> > structures. I'm working on replacing this with a imx-image tool.
> > You seem to use checksums in your images. These can't be generated
> > in C or CPP anyway.
> > """
Have you read Sascha comment?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 14:13 ` Thomas Petazzoni
@ 2013-05-06 14:14 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 14:31 ` Willy Tarreau
0 siblings, 1 reply; 63+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-06 14:14 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
On 16:13 Mon 06 May , Thomas Petazzoni wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> On Mon, 6 May 2013 16:04:39 +0200, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>
> > > > > Could you please adopt a nicer language? You are very aggressive... and
> > > > > at that the same time completely wrong. Your comments make it entirely
> > > > > clear that you haven't even read the comments at the top of file.
> > > > I did but still think we can handle it in C
> > > >
> > > > and need to handle by barebox itself when flashing
> > >
> > > The image is pushed to the target through X-modem, directly talking to
> > > the ROM code of the SoC. Do you want the kwboot tool to prepare the
> > > image? It seems to me like it makes a lot more sense to have a tool to
> > > prepare the image.
> >
> > yes a you want to re-flash barebox itself and you will do for ddr and I do not
> > want to care about all of this blob stuff twht the board already known
>
> Sorry, but I don't understand what you're trying to explain here, your
> english sentence doesn't make sense.
>
> The binary blob is needed for now. I've intentionally written a tool
> that allows people to extract this binary blob from their existing
> bootloader image so we don't have to store this binary blob anywhere in
> the Barebox tree. As I explained, getting a working DDR3 training code
> will be something that can be done later on, but it's not yet my
> priority.
>
> > > Remember also that this tool is needed to *extract* existing images.
> > > And you haven't explained how you intend to do this without a proper
> > > userspace tool such as kwbimage.
> >
> > why extract?
> >
> > you generated at runtime
>
> 1) Because it's useful to extract the various parameters of an
> existing bootloader image, to see how it was built by the vendor to
> use the same parameters. For example, for Kirkwood SoCs, the header
> contains the values to put in the DRAM controller to configure the
> right timings, and it is useful to extract those values into a
> configuration file, later used to create a shiny new image that
> contains Barebox.
>
> 2) Because it's useful to extract the binary blob needed to configure
> the DDR3 timing dynamically (for Armada 370/XP).
You do not read the comment
we need *runtime* update not *only* *xmodem* flashing. Barebox need to extract
by itself the information from a running platfrom in C
This is the barebox update that will ensure a binary is correct before
flashing and can only request barebox and not the blob stuff to udpate itself
>
> > > Quoting Sascha, an e-mail for this thread:
> > >
> > > """
> > > Anyway, what we do on i.MX doesn't really scale anymore since the more
> > > complicated features of the image format can't be used with C
> > > structures. I'm working on replacing this with a imx-image tool.
> > > You seem to use checksums in your images. These can't be generated
> > > in C or CPP anyway.
> > > """
>
> Have you read Sascha comment?
Yes you do not read what I write. I write *runtime* not *compiling* time
and yes if we can do *compiling* time I want it more that u-boot style tools
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 14:14 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2013-05-06 14:31 ` Willy Tarreau
2013-05-06 19:34 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 1 reply; 63+ messages in thread
From: Willy Tarreau @ 2013-05-06 14:31 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Thomas Petazzoni, Lior Amsalem, Jason Cooper, Ezequiel Garcia, barebox
Jean-Christophe,
On Mon, May 06, 2013 at 04:14:47PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > 2) Because it's useful to extract the binary blob needed to configure
> > the DDR3 timing dynamically (for Armada 370/XP).
>
> You do not read the comment
>
> we need *runtime* update not *only* *xmodem* flashing. Barebox need to extract
> by itself the information from a running platfrom in C
>
> This is the barebox update that will ensure a binary is correct before
> flashing and can only request barebox and not the blob stuff to udpate itself
I have read your comments as well and still don't understand what you want
to explain. I think it would be more productive to spend the time to write
real sentences and detailed explanations. Right now you're only in the
"no thanks" mode and it's very hard to understand your concerns.
You can't blame people for not understanding you when you are the one who
has difficulties explaining basic things in public.
> > Have you read Sascha comment?
> Yes you do not read what I write. I write *runtime* not *compiling* time
But for runtime to work, you need to boot at least once. The concern here
is to get it to boot the first time, and for this, extracting the binary
blob is needed.
Willy
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 14:31 ` Willy Tarreau
@ 2013-05-06 19:34 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 19:53 ` Willy Tarreau
0 siblings, 1 reply; 63+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-06 19:34 UTC (permalink / raw)
To: Willy Tarreau
Cc: Thomas Petazzoni, Lior Amsalem, Jason Cooper, Ezequiel Garcia, barebox
On 16:31 Mon 06 May , Willy Tarreau wrote:
> Jean-Christophe,
>
> On Mon, May 06, 2013 at 04:14:47PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > 2) Because it's useful to extract the binary blob needed to configure
> > > the DDR3 timing dynamically (for Armada 370/XP).
> >
> > You do not read the comment
> >
> > we need *runtime* update not *only* *xmodem* flashing. Barebox need to extract
> > by itself the information from a running platfrom in C
> >
> > This is the barebox update that will ensure a binary is correct before
> > flashing and can only request barebox and not the blob stuff to udpate itself
>
> I have read your comments as well and still don't understand what you want
> to explain. I think it would be more productive to spend the time to write
> real sentences and detailed explanations. Right now you're only in the
> "no thanks" mode and it's very hard to understand your concerns.
>
> You can't blame people for not understanding you when you are the one who
> has difficulties explaining basic things in public.
so read the code of barebox before speaking
when I mention barebox update is a specific part of the code, if you do not
read the code you can not understand what I talk about. So no I'll not spend
time to explain you code that you did not read.
>
> > > Have you read Sascha comment?
> > Yes you do not read what I write. I write *runtime* not *compiling* time
>
> But for runtime to work, you need to boot at least once. The concern here
> is to get it to boot the first time, and for this, extracting the binary
> blob is needed.
No, it's not.
It's to simplify the job of hacker.
Not mandatory.
And it's does not require you to generate the image before flashing.
And request the blob by XMODEM will NEVER work to update at runtime as can not
discuss with the ROM code via XMODEM. So yes this will not work for self
update
Best Regards,
J.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 19:34 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2013-05-06 19:53 ` Willy Tarreau
2013-05-06 20:21 ` Thomas Petazzoni
0 siblings, 1 reply; 63+ messages in thread
From: Willy Tarreau @ 2013-05-06 19:53 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Thomas Petazzoni, Lior Amsalem, Jason Cooper, Ezequiel Garcia, barebox
On Mon, May 06, 2013 at 09:34:22PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > This is the barebox update that will ensure a binary is correct before
> > > flashing and can only request barebox and not the blob stuff to udpate itself
> >
> > I have read your comments as well and still don't understand what you want
> > to explain. I think it would be more productive to spend the time to write
> > real sentences and detailed explanations. Right now you're only in the
> > "no thanks" mode and it's very hard to understand your concerns.
> >
> > You can't blame people for not understanding you when you are the one who
> > has difficulties explaining basic things in public.
> so read the code of barebox before speaking
>
> when I mention barebox update is a specific part of the code, if you do not
> read the code you can not understand what I talk about. So no I'll not spend
> time to explain you code that you did not read.
Then I think we're speaking about two different thing which might be the reason
for your misunderstanding. In order to get the bootloader run on these chips,
you *need* the DDR3 training code. So whatever is in the bootloader update code
is irrelevant at this step as it will not be used at all yet.
> > > > Have you read Sascha comment?
> > > Yes you do not read what I write. I write *runtime* not *compiling* time
> >
> > But for runtime to work, you need to boot at least once. The concern here
> > is to get it to boot the first time, and for this, extracting the binary
> > blob is needed.
>
> No, it's not.
> It's to simplify the job of hacker.
> Not mandatory.
No, it's to get the CPU to boot and to accept to load the boot loader. Period.
> And it's does not require you to generate the image before flashing.
> And request the blob by XMODEM will NEVER work to update at runtime as can not
> discuss with the ROM code via XMODEM. So yes this will not work for self
> update
You seem to be assuming that the bootloader is already running fine on the
box, which is not the case that Thomas has addressed. In order to *flash*
the bootloader to the device, you need that DDR3 code to be *executed*, and
if you had read his cover mail carefully, you'd have seen that this happens
*during* the XMODEM upload sequence (hence the changes to kwboot to protect
the upload while this code talks to the serial port). It's painful but that's
how it works, and once you get it after all it's rather flexible in the end.
So please don't use your update code as an argument as it's not the interesting
part here.
Thank you,
Willy
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 19:53 ` Willy Tarreau
@ 2013-05-06 20:21 ` Thomas Petazzoni
2013-05-06 20:35 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 1 reply; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-06 20:21 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia
Hello,
On Mon, 6 May 2013 21:53:59 +0200, Willy Tarreau wrote:
> > And it's does not require you to generate the image before flashing.
> > And request the blob by XMODEM will NEVER work to update at runtime
> > as can not discuss with the ROM code via XMODEM. So yes this will
> > not work for self update
>
> You seem to be assuming that the bootloader is already running fine
> on the box, which is not the case that Thomas has addressed. In order
> to *flash* the bootloader to the device, you need that DDR3 code to
> be *executed*, and if you had read his cover mail carefully, you'd
> have seen that this happens *during* the XMODEM upload sequence
> (hence the changes to kwboot to protect the upload while this code
> talks to the serial port). It's painful but that's how it works, and
> once you get it after all it's rather flexible in the end.
>
> So please don't use your update code as an argument as it's not the
> interesting part here.
Just to expand on what Willy explains: the bootable image contains
essentially 3 things:
* A header describing the image
* A binary header that contains the binary blob responsible for
calculating the DDR3 timings
* The payload, which in our case is Barebox.
When the ROM code sees a bootable image on SPI/NAND, or receives it
through Xmodem, it sets up the MMU, initializes the L2 cache as SRAM,
and it copies the header of the image (including the binary header)
into the SRAM. At this point, it *stops* getting data from Xmodem, and
executes the binary blob to configure the DDR3. Then, it goes on to
fetch the rest of the image (i.e the payload) and pushes that directly
to the DRAM, at an address defined in the header of the image. So the
DDR3 training code actually gets executed in the *middle* of the Xmodem
transfer, and the Xmodem transfer cannot continue if the DDR3 timings
have not been set up properly by the binary blob.
So, when you have in front of your eyes a device with *nothing* on it,
then you *must* have an image as prepared by kwbimage, that contains
those three elements: the header, the binary blob, and the payload, and
you must use the kwboot tool to push it through Xmodem to the SoC.
For self-update, there is no problem: the same kwbimage tool can
generate either an image that boots from UART, SPI, NAND or SATA. So
you can simply flash the generated image wherever you want on a SPI
flash or NAND flash, reboot and that's it. The image needs to be
slightly different depending on the boot media, but that's really
because the Marvell ROM code insists in the image having a 'blockid',
which identifies on which boot media the image is stored.
Jean-Christophe, I think you should have a serious look at the boot
process of Marvell SoC before aggressively telling everybody that they
are wrong. It's not because you know how AT91 and i.MX are booting that
you necessarily know the specificities of Marvell SoCs. Remember also
that the Marvell Armada 370 and XP have a different booting process than
Marvell Kirkwood (Marvell Kirkwood does not have this mechanism of
binary blob).
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 20:21 ` Thomas Petazzoni
@ 2013-05-06 20:35 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 20:44 ` Thomas Petazzoni
2013-05-06 20:48 ` Sascha Hauer
0 siblings, 2 replies; 63+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-06 20:35 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia, Jason Cooper
On 22:21 Mon 06 May , Thomas Petazzoni wrote:
> Hello,
>
> On Mon, 6 May 2013 21:53:59 +0200, Willy Tarreau wrote:
>
> > > And it's does not require you to generate the image before flashing.
> > > And request the blob by XMODEM will NEVER work to update at runtime
> > > as can not discuss with the ROM code via XMODEM. So yes this will
> > > not work for self update
> >
> > You seem to be assuming that the bootloader is already running fine
> > on the box, which is not the case that Thomas has addressed. In order
> > to *flash* the bootloader to the device, you need that DDR3 code to
> > be *executed*, and if you had read his cover mail carefully, you'd
> > have seen that this happens *during* the XMODEM upload sequence
> > (hence the changes to kwboot to protect the upload while this code
> > talks to the serial port). It's painful but that's how it works, and
> > once you get it after all it's rather flexible in the end.
> >
> > So please don't use your update code as an argument as it's not the
> > interesting part here.
>
> Just to expand on what Willy explains: the bootable image contains
> essentially 3 things:
>
> * A header describing the image
> * A binary header that contains the binary blob responsible for
> calculating the DDR3 timings
> * The payload, which in our case is Barebox.
>
> When the ROM code sees a bootable image on SPI/NAND, or receives it
> through Xmodem, it sets up the MMU, initializes the L2 cache as SRAM,
> and it copies the header of the image (including the binary header)
> into the SRAM. At this point, it *stops* getting data from Xmodem, and
> executes the binary blob to configure the DDR3. Then, it goes on to
> fetch the rest of the image (i.e the payload) and pushes that directly
> to the DRAM, at an address defined in the header of the image. So the
> DDR3 training code actually gets executed in the *middle* of the Xmodem
> transfer, and the Xmodem transfer cannot continue if the DDR3 timings
> have not been set up properly by the binary blob.
Same principle as on Atmel when you flash via XMODEM or USB Device
This does not means you need to generate any specific media file
>
> So, when you have in front of your eyes a device with *nothing* on it,
> then you *must* have an image as prepared by kwbimage, that contains
> those three elements: the header, the binary blob, and the payload, and
> you must use the kwboot tool to push it through Xmodem to the SoC.
>
> For self-update, there is no problem: the same kwbimage tool can
> generate either an image that boots from UART, SPI, NAND or SATA. So
> you can simply flash the generated image wherever you want on a SPI
> flash or NAND flash, reboot and that's it. The image needs to be
> slightly different depending on the boot media, but that's really
> because the Marvell ROM code insists in the image having a 'blockid',
> which identifies on which boot media the image is stored.
this is where it's wrong, you does not need such binary at all, barebox update
will handle this by himself and will never requiere one image per media
As barebox does not care wheren it boot from or where the dev is stored. we
choose is at runtime not at compile time
Barebox update will generate the correct image for the storagemedia at
runtime
>
> Jean-Christophe, I think you should have a serious look at the boot
> process of Marvell SoC before aggressively telling everybody that they
> are wrong. It's not because you know how AT91 and i.MX are booting that
> you necessarily know the specificities of Marvell SoCs. Remember also
> that the Marvell Armada 370 and XP have a different booting process than
> Marvell Kirkwood (Marvell Kirkwood does not have this mechanism of
> binary blob).
I very well such mecanism ST and ST-Ericsson use similar way. But mandatory to
generate the barebox image for a storage media is a non sense. That's why we
work to have multi-arch. SO no this is in the oposite way of the whole work on
barebox done for months. It's regression
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 20:35 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2013-05-06 20:44 ` Thomas Petazzoni
2013-05-06 20:56 ` Sascha Hauer
2013-05-06 20:48 ` Sascha Hauer
1 sibling, 1 reply; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-06 20:44 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia, Jason Cooper
Dear Jean-Christophe PLAGNIOL-VILLARD,
On Mon, 6 May 2013 22:35:40 +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> this is where it's wrong, you does not need such binary at all, barebox update
> will handle this by himself and will never requiere one image per media
>
> As barebox does not care wheren it boot from or where the dev is stored. we
> choose is at runtime not at compile time
>
> Barebox update will generate the correct image for the storagemedia at
> runtime
What is "Barebox update" ?
On my board, I currently have nothing, no bootloader, no nothing. How do
I bring Barebox on it if I can't build a UART bootable image ?
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 20:44 ` Thomas Petazzoni
@ 2013-05-06 20:56 ` Sascha Hauer
2013-05-06 21:03 ` Thomas Petazzoni
0 siblings, 1 reply; 63+ messages in thread
From: Sascha Hauer @ 2013-05-06 20:56 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
On Mon, May 06, 2013 at 10:44:56PM +0200, Thomas Petazzoni wrote:
> Dear Jean-Christophe PLAGNIOL-VILLARD,
>
> On Mon, 6 May 2013 22:35:40 +0200, Jean-Christophe PLAGNIOL-VILLARD
> wrote:
>
> > this is where it's wrong, you does not need such binary at all, barebox update
> > will handle this by himself and will never requiere one image per media
> >
> > As barebox does not care wheren it boot from or where the dev is stored. we
> > choose is at runtime not at compile time
> >
> > Barebox update will generate the correct image for the storagemedia at
> > runtime
>
> What is "Barebox update" ?
barebox_update is a command that you can call during runtime to update
barebox. Over writing images directly to the storage it has the
advantage that you can do additional sanity checks on the images.
Also for example on i.MX a board specific poke table is all you need
to bring up SDRAM. As long as you have this poke table and a devicetree
you could use the same binary on different boards.
For initial bring up you would still need a SoC specific image though
(at least when not using JTAG), so you still need a tool to generate it.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 20:56 ` Sascha Hauer
@ 2013-05-06 21:03 ` Thomas Petazzoni
2013-05-07 6:31 ` Sascha Hauer
2013-05-07 9:33 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 2 replies; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-06 21:03 UTC (permalink / raw)
To: Sascha Hauer
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
Dear Sascha Hauer,
On Mon, 6 May 2013 22:56:31 +0200, Sascha Hauer wrote:
> > > Barebox update will generate the correct image for the storagemedia at
> > > runtime
> >
> > What is "Barebox update" ?
>
> barebox_update is a command that you can call during runtime to update
> barebox. Over writing images directly to the storage it has the
> advantage that you can do additional sanity checks on the images.
>
> Also for example on i.MX a board specific poke table is all you need
> to bring up SDRAM. As long as you have this poke table and a devicetree
> you could use the same binary on different boards.
Ok, makes sense. On Marvell Kirkwood, the SDRAM bring up is also done
using a set of (address, value) pairs that are part of the image
header. This mechanism is also available for Armada 370/XP, but
apparently, DDR3 requires a more dynamic tuning to find optimal
timings, so having static values in a table is no longer appropriate.
In our case, how would barebox_update work? Would it overwrite just the
barebox.bin payload (which would require updating the 32 bits checksum
and the payload size in the header, otherwise the Marvell SoC would not
boot the image at the next reboot), or should it overwrite the whole
image (in which case it would have to re-extract the configuration and
the binary blob, and reconstruct the image at runtime) ? Probably the
first solution is the easiest one.
> For initial bring up you would still need a SoC specific image though
> (at least when not using JTAG), so you still need a tool to generate it.
Indeed.
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 21:03 ` Thomas Petazzoni
@ 2013-05-07 6:31 ` Sascha Hauer
2013-05-07 9:33 ` Jean-Christophe PLAGNIOL-VILLARD
1 sibling, 0 replies; 63+ messages in thread
From: Sascha Hauer @ 2013-05-07 6:31 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
On Mon, May 06, 2013 at 11:03:37PM +0200, Thomas Petazzoni wrote:
> Dear Sascha Hauer,
>
> On Mon, 6 May 2013 22:56:31 +0200, Sascha Hauer wrote:
>
> > > > Barebox update will generate the correct image for the storagemedia at
> > > > runtime
> > >
> > > What is "Barebox update" ?
> >
> > barebox_update is a command that you can call during runtime to update
> > barebox. Over writing images directly to the storage it has the
> > advantage that you can do additional sanity checks on the images.
> >
> > Also for example on i.MX a board specific poke table is all you need
> > to bring up SDRAM. As long as you have this poke table and a devicetree
> > you could use the same binary on different boards.
>
> Ok, makes sense. On Marvell Kirkwood, the SDRAM bring up is also done
> using a set of (address, value) pairs that are part of the image
> header. This mechanism is also available for Armada 370/XP, but
> apparently, DDR3 requires a more dynamic tuning to find optimal
> timings, so having static values in a table is no longer appropriate.
>
> In our case, how would barebox_update work? Would it overwrite just the
> barebox.bin payload (which would require updating the 32 bits checksum
> and the payload size in the header, otherwise the Marvell SoC would not
> boot the image at the next reboot), or should it overwrite the whole
> image (in which case it would have to re-extract the configuration and
> the binary blob, and reconstruct the image at runtime) ? Probably the
> first solution is the easiest one.
That's up to you how you implement it. I would recommend though that if
possible barebox_update should work on a naked device. This way you can
do things like booting from SD card and use barebox_update to write to
internal (erased) flash.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 21:03 ` Thomas Petazzoni
2013-05-07 6:31 ` Sascha Hauer
@ 2013-05-07 9:33 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-07 9:46 ` Willy Tarreau
2013-05-07 9:47 ` Sascha Hauer
1 sibling, 2 replies; 63+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-07 9:33 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
On 23:03 Mon 06 May , Thomas Petazzoni wrote:
> Dear Sascha Hauer,
>
> On Mon, 6 May 2013 22:56:31 +0200, Sascha Hauer wrote:
>
> > > > Barebox update will generate the correct image for the storagemedia at
> > > > runtime
> > >
> > > What is "Barebox update" ?
> >
> > barebox_update is a command that you can call during runtime to update
> > barebox. Over writing images directly to the storage it has the
> > advantage that you can do additional sanity checks on the images.
> >
> > Also for example on i.MX a board specific poke table is all you need
> > to bring up SDRAM. As long as you have this poke table and a devicetree
> > you could use the same binary on different boards.
>
> Ok, makes sense. On Marvell Kirkwood, the SDRAM bring up is also done
> using a set of (address, value) pairs that are part of the image
> header. This mechanism is also available for Armada 370/XP, but
> apparently, DDR3 requires a more dynamic tuning to find optimal
> timings, so having static values in a table is no longer appropriate.
>
> In our case, how would barebox_update work? Would it overwrite just the
> barebox.bin payload (which would require updating the 32 bits checksum
> and the payload size in the header, otherwise the Marvell SoC would not
> boot the image at the next reboot), or should it overwrite the whole
> image (in which case it would have to re-extract the configuration and
> the binary blob, and reconstruct the image at runtime) ? Probably the
> first solution is the easiest one.
yes you need to construct the image at *runtime* and drop this madness of 1
image per media to generate. As this will create 1 defconfig per target device
which duplicate the defconfig and make the maintainance a nightmare
So the *same* generated barebox image can run on any board virtualy
>
> > For initial bring up you would still need a SoC specific image though
> > (at least when not using JTAG), so you still need a tool to generate it.
>
> Indeed.
no you do not need to generate an image (file) you just need to upload it
same on the barebox update you do not need to provide the blob stuf you just
provuce the barebox image (or payload)
You need to share the code between barebox and the host
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-07 9:33 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2013-05-07 9:46 ` Willy Tarreau
2013-05-07 9:47 ` Sascha Hauer
1 sibling, 0 replies; 63+ messages in thread
From: Willy Tarreau @ 2013-05-07 9:46 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Thomas Petazzoni, Lior Amsalem, Jason Cooper, barebox, Ezequiel Garcia
On Tue, May 07, 2013 at 11:33:24AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> no you do not need to generate an image (file) you just need to upload it
I disagree with you on this. While this can generally be true, I (as a user)
absolutely want to have an image that I can upload using various tools, as I
had several issues while trying to upload the image on the mirabox the first
time, leading me to try several different tools.
Also, please note that Xmodem is commonly supported by many terminal servers
on many platforms and does not require that you try to build your code on
these platforms.
In my opinion, the C code should provide a portable, multi-platform binary,
and an external tool should transform it to the finally uploadable binary
image for your specific board or CPU. That way you can ship pre-compiled
binary barebox code if you want, and have the end user adapt it to his own
board.
I don't see how this could be a problem.
Willy
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-07 9:33 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-07 9:46 ` Willy Tarreau
@ 2013-05-07 9:47 ` Sascha Hauer
2013-05-07 9:57 ` Thomas Petazzoni
1 sibling, 1 reply; 63+ messages in thread
From: Sascha Hauer @ 2013-05-07 9:47 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Thomas Petazzoni, Lior Amsalem, Jason Cooper, barebox,
Ezequiel Garcia, Willy Tarreau
On Tue, May 07, 2013 at 11:33:24AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 23:03 Mon 06 May , Thomas Petazzoni wrote:
> > Dear Sascha Hauer,
> >
> > On Mon, 6 May 2013 22:56:31 +0200, Sascha Hauer wrote:
> >
> > > > > Barebox update will generate the correct image for the storagemedia at
> > > > > runtime
> > > >
> > > > What is "Barebox update" ?
> > >
> > > barebox_update is a command that you can call during runtime to update
> > > barebox. Over writing images directly to the storage it has the
> > > advantage that you can do additional sanity checks on the images.
> > >
> > > Also for example on i.MX a board specific poke table is all you need
> > > to bring up SDRAM. As long as you have this poke table and a devicetree
> > > you could use the same binary on different boards.
> >
> > Ok, makes sense. On Marvell Kirkwood, the SDRAM bring up is also done
> > using a set of (address, value) pairs that are part of the image
> > header. This mechanism is also available for Armada 370/XP, but
> > apparently, DDR3 requires a more dynamic tuning to find optimal
> > timings, so having static values in a table is no longer appropriate.
> >
> > In our case, how would barebox_update work? Would it overwrite just the
> > barebox.bin payload (which would require updating the 32 bits checksum
> > and the payload size in the header, otherwise the Marvell SoC would not
> > boot the image at the next reboot), or should it overwrite the whole
> > image (in which case it would have to re-extract the configuration and
> > the binary blob, and reconstruct the image at runtime) ? Probably the
> > first solution is the easiest one.
>
> yes you need to construct the image at *runtime* and drop this madness of 1
> image per media to generate. As this will create 1 defconfig per target device
>
> which duplicate the defconfig and make the maintainance a nightmare
That's the way we currently do it. Don't expect from Thomas to do it
differently as long there is not even a single example in the tree how
to do it.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-07 9:47 ` Sascha Hauer
@ 2013-05-07 9:57 ` Thomas Petazzoni
0 siblings, 0 replies; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-07 9:57 UTC (permalink / raw)
To: Sascha Hauer
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
Dear Sascha Hauer,
On Tue, 7 May 2013 11:47:52 +0200, Sascha Hauer wrote:
> > yes you need to construct the image at *runtime* and drop this madness of 1
> > image per media to generate. As this will create 1 defconfig per target device
> >
> > which duplicate the defconfig and make the maintainance a nightmare
>
> That's the way we currently do it. Don't expect from Thomas to do it
> differently as long there is not even a single example in the tree how
> to do it.
The Barebox image (barebox.bin) itself is *completely* independent from
the post-processing done by kwbimage. I.e, if I'm able to generate a
multiplatform barebox.bin that works on all Armada 370/XP boards, then
a single defconfig will be needed for all Armada 370/XP boards. This
defconfig will generate one single barebox.bin that works on all Armada
370/XP boards. Only the post-processing step to be done with kwbimage
will be board-specific, and this post-processing does not affect the
defconfig in any way. Of course, it remains to be defined how Barebox
will guess on which platform it runs (I suppose the idea is to somehow
bundle a DTB with Barebox, but I don't know).
Furthermore, the boot media is not selected in the Barebox
configuration, but only when running the kwbimage. So there is only one
barebox.bin per board, and one defconfig per board. Just like Barebox
is doing for all supported platforms at the moment.
So I'm not sure to see the connection between the number of defconfig
and the kwbimage tool. There is really no connection at all.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 20:35 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 20:44 ` Thomas Petazzoni
@ 2013-05-06 20:48 ` Sascha Hauer
1 sibling, 0 replies; 63+ messages in thread
From: Sascha Hauer @ 2013-05-06 20:48 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Thomas Petazzoni, Lior Amsalem, Jason Cooper, barebox,
Ezequiel Garcia, Willy Tarreau
On Mon, May 06, 2013 at 10:35:40PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 22:21 Mon 06 May , Thomas Petazzoni wrote:
> > Hello,
> >
> > On Mon, 6 May 2013 21:53:59 +0200, Willy Tarreau wrote:
> >
> > > > And it's does not require you to generate the image before flashing.
> > > > And request the blob by XMODEM will NEVER work to update at runtime
> > > > as can not discuss with the ROM code via XMODEM. So yes this will
> > > > not work for self update
> > >
> > > You seem to be assuming that the bootloader is already running fine
> > > on the box, which is not the case that Thomas has addressed. In order
> > > to *flash* the bootloader to the device, you need that DDR3 code to
> > > be *executed*, and if you had read his cover mail carefully, you'd
> > > have seen that this happens *during* the XMODEM upload sequence
> > > (hence the changes to kwboot to protect the upload while this code
> > > talks to the serial port). It's painful but that's how it works, and
> > > once you get it after all it's rather flexible in the end.
> > >
> > > So please don't use your update code as an argument as it's not the
> > > interesting part here.
> >
> > Just to expand on what Willy explains: the bootable image contains
> > essentially 3 things:
> >
> > * A header describing the image
> > * A binary header that contains the binary blob responsible for
> > calculating the DDR3 timings
> > * The payload, which in our case is Barebox.
> >
> > When the ROM code sees a bootable image on SPI/NAND, or receives it
> > through Xmodem, it sets up the MMU, initializes the L2 cache as SRAM,
> > and it copies the header of the image (including the binary header)
> > into the SRAM. At this point, it *stops* getting data from Xmodem, and
> > executes the binary blob to configure the DDR3. Then, it goes on to
> > fetch the rest of the image (i.e the payload) and pushes that directly
> > to the DRAM, at an address defined in the header of the image. So the
> > DDR3 training code actually gets executed in the *middle* of the Xmodem
> > transfer, and the Xmodem transfer cannot continue if the DDR3 timings
> > have not been set up properly by the binary blob.
> Same principle as on Atmel when you flash via XMODEM or USB Device
>
> This does not means you need to generate any specific media file
> >
> > So, when you have in front of your eyes a device with *nothing* on it,
> > then you *must* have an image as prepared by kwbimage, that contains
> > those three elements: the header, the binary blob, and the payload, and
> > you must use the kwboot tool to push it through Xmodem to the SoC.
> >
> > For self-update, there is no problem: the same kwbimage tool can
> > generate either an image that boots from UART, SPI, NAND or SATA. So
> > you can simply flash the generated image wherever you want on a SPI
> > flash or NAND flash, reboot and that's it. The image needs to be
> > slightly different depending on the boot media, but that's really
> > because the Marvell ROM code insists in the image having a 'blockid',
> > which identifies on which boot media the image is stored.
>
> this is where it's wrong, you does not need such binary at all, barebox update
> will handle this by himself and will never requiere one image per media
>
> As barebox does not care wheren it boot from or where the dev is stored. we
> choose is at runtime not at compile time
>
> Barebox update will generate the correct image for the storagemedia at
> runtime
You need a running barebox to be able to run barebox update. This tool
is for being able to run something for the first time.
Without this tool you have a can with the can opener inside.
> >
> > Jean-Christophe, I think you should have a serious look at the boot
> > process of Marvell SoC before aggressively telling everybody that they
> > are wrong. It's not because you know how AT91 and i.MX are booting that
> > you necessarily know the specificities of Marvell SoCs. Remember also
> > that the Marvell Armada 370 and XP have a different booting process than
> > Marvell Kirkwood (Marvell Kirkwood does not have this mechanism of
> > binary blob).
>
> I very well such mecanism ST and ST-Ericsson use similar way. But mandatory to
> generate the barebox image for a storage media is a non sense. That's why we
> work to have multi-arch. SO no this is in the oposite way of the whole work on
> barebox done for months. It's regression
It's absolutely necessary to generate SoC specific images, because
that's all that SoCs are able to boot.
All that multiarch for a bootloader can do is to reuse the same binary
for different SoCs. Still you have to encapsulate it in SoC specific
images.
The fact that often you want to be able to generate SoC specific images
from a generic binary during runtime is orthogonal to this issue.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 14:04 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 14:13 ` Thomas Petazzoni
@ 2013-05-06 14:21 ` Jason Cooper
2013-05-06 19:39 ` Jean-Christophe PLAGNIOL-VILLARD
1 sibling, 1 reply; 63+ messages in thread
From: Jason Cooper @ 2013-05-06 14:21 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Thomas Petazzoni, Lior Amsalem, Willy Tarreau, Ezequiel Garcia, barebox
On Mon, May 06, 2013 at 04:04:39PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 16:06 Mon 06 May , Thomas Petazzoni wrote:
> > Dear Jean-Christophe PLAGNIOL-VILLARD,
> >
> > On Mon, 6 May 2013 15:54:35 +0200, Jean-Christophe PLAGNIOL-VILLARD
> > wrote:
> >
> > > > Could you please adopt a nicer language? You are very aggressive... and
> > > > at that the same time completely wrong. Your comments make it entirely
> > > > clear that you haven't even read the comments at the top of file.
> > > I did but still think we can handle it in C
> > >
> > > and need to handle by barebox itself when flashing
> >
> > The image is pushed to the target through X-modem, directly talking to
> > the ROM code of the SoC. Do you want the kwboot tool to prepare the
> > image? It seems to me like it makes a lot more sense to have a tool to
> > prepare the image.
>
> yes a you want to re-flash barebox itself and you will do for ddr and I do not
> want to care about all of this blob stuff twht the board already known
>
> >
> > Remember also that this tool is needed to *extract* existing images.
> > And you haven't explained how you intend to do this without a proper
> > userspace tool such as kwbimage.
>
> why extract?
Because you *received* the blob over xmodem from the SoC. It came from
the factory that way. You need to take it apart to get the DDR info and
the stock bootloader blob. Think of this as a tool to assist board
hackers when the mfgr doesn't have the time/experience to help the open
source community.
Since a separate tool is needed to do this, it makes sense to have the
same code perform the packing as well. As opposed to the CPP.
hth,
Jason.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 14:21 ` Jason Cooper
@ 2013-05-06 19:39 ` Jean-Christophe PLAGNIOL-VILLARD
0 siblings, 0 replies; 63+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-06 19:39 UTC (permalink / raw)
To: Jason Cooper
Cc: Thomas Petazzoni, Lior Amsalem, Willy Tarreau, Ezequiel Garcia, barebox
On 10:21 Mon 06 May , Jason Cooper wrote:
> On Mon, May 06, 2013 at 04:04:39PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 16:06 Mon 06 May , Thomas Petazzoni wrote:
> > > Dear Jean-Christophe PLAGNIOL-VILLARD,
> > >
> > > On Mon, 6 May 2013 15:54:35 +0200, Jean-Christophe PLAGNIOL-VILLARD
> > > wrote:
> > >
> > > > > Could you please adopt a nicer language? You are very aggressive... and
> > > > > at that the same time completely wrong. Your comments make it entirely
> > > > > clear that you haven't even read the comments at the top of file.
> > > > I did but still think we can handle it in C
> > > >
> > > > and need to handle by barebox itself when flashing
> > >
> > > The image is pushed to the target through X-modem, directly talking to
> > > the ROM code of the SoC. Do you want the kwboot tool to prepare the
> > > image? It seems to me like it makes a lot more sense to have a tool to
> > > prepare the image.
> >
> > yes a you want to re-flash barebox itself and you will do for ddr and I do not
> > want to care about all of this blob stuff twht the board already known
> >
> > >
> > > Remember also that this tool is needed to *extract* existing images.
> > > And you haven't explained how you intend to do this without a proper
> > > userspace tool such as kwbimage.
> >
> > why extract?
>
> Because you *received* the blob over xmodem from the SoC. It came from
> the factory that way. You need to take it apart to get the DDR info and
> the stock bootloader blob. Think of this as a tool to assist board
> hackers when the mfgr doesn't have the time/experience to help the open
> source community.
This will only work if you known the DDR which is a huge suposition.
When porting barebox on new hardware this will not help at all
so not this tool can not be the default tool generate fashable images
>
> Since a separate tool is needed to do this, it makes sense to have the
> same code perform the packing as well. As opposed to the CPP.
>
> hth,
>
> Jason.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-05 11:19 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-05 11:40 ` Willy Tarreau
2013-05-06 13:53 ` Thomas Petazzoni
@ 2013-05-07 6:44 ` Sascha Hauer
2 siblings, 0 replies; 63+ messages in thread
From: Sascha Hauer @ 2013-05-07 6:44 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
On Sun, May 05, 2013 at 01:19:27PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 16:32 Sat 04 May , Jason Cooper wrote:
> > On Sat, May 04, 2013 at 09:51:25PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 18:51 Fri 03 May , Thomas Petazzoni wrote:
> > > > The Marvell EBU SoCs (Kirkwood, Armada 370, Armada XP) have a BootROM
> > > > that understand a specific image format, composed of a main header,
> > > > several extension headers and a paylod. This image can be booted from
> > > > NAND, SPI, SATA, UART, NOR, etc.
> > > >
> > > > This patch adds a tool that allows to extract the components and
> > > > configuration of existing images, and to create new images.
> > >
> > > I don't like this
> >
> > Why?
> to geneate a simple header do it in C not with a tools
> >
> > > please as on imx in barebox directly
> >
> > what? Could you please explain?
>
> read the imx code we do it in C and place it at the begenning of the binary so
> no need such tools and we can use linker scirpt and CONFIG_xx
>
> Stop to think u-boot here
If you want people to think positively about barebox you should try and
explain how barebox can be better and not tell them that they have the
wrong thinking. Thomas thinking can't be too wrong as he already sent
patches to barebox, right? ;)
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-04 19:51 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-04 20:32 ` Jason Cooper
@ 2013-05-06 19:41 ` Sascha Hauer
1 sibling, 0 replies; 63+ messages in thread
From: Sascha Hauer @ 2013-05-06 19:41 UTC (permalink / raw)
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Thomas Petazzoni, Lior Amsalem, Willy Tarreau, Ezequiel Garcia, barebox
On Sat, May 04, 2013 at 09:51:25PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 18:51 Fri 03 May , Thomas Petazzoni wrote:
> > The Marvell EBU SoCs (Kirkwood, Armada 370, Armada XP) have a BootROM
> > that understand a specific image format, composed of a main header,
> > several extension headers and a paylod. This image can be booted from
> > NAND, SPI, SATA, UART, NOR, etc.
> >
> > This patch adds a tool that allows to extract the components and
> > configuration of existing images, and to create new images.
>
> I don't like this
>
> please as on imx in barebox directly
As said, on i.MX the linker magic makes enough problems so that I am
working on adding a tool like this one.
>
> and drop this tool
And you drop the overlong context of the mails you are replying to. That
would be a first step to show that you actually care about other
people(s time)
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-03 16:51 ` [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images Thomas Petazzoni
2013-05-04 19:51 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2013-05-06 19:16 ` Sascha Hauer
2013-05-06 20:22 ` Thomas Petazzoni
2013-05-07 23:30 ` Gregory CLEMENT
2 siblings, 1 reply; 63+ messages in thread
From: Sascha Hauer @ 2013-05-06 19:16 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
On Fri, May 03, 2013 at 06:51:06PM +0200, Thomas Petazzoni wrote:
> The Marvell EBU SoCs (Kirkwood, Armada 370, Armada XP) have a BootROM
> that understand a specific image format, composed of a main header,
> several extension headers and a paylod. This image can be booted from
> NAND, SPI, SATA, UART, NOR, etc.
>
> This patch adds a tool that allows to extract the components and
> configuration of existing images, and to create new images.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> scripts/.gitignore | 1 +
> scripts/Makefile | 3 +-
> scripts/kwbimage.c | 1224 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 1227 insertions(+), 1 deletion(-)
> create mode 100644 scripts/kwbimage.c
>
> diff --git a/scripts/.gitignore b/scripts/.gitignore
> index 1ca6603..414de7f 100644
> --- a/scripts/.gitignore
> +++ b/scripts/.gitignore
> @@ -2,6 +2,7 @@ bareboxenv
> bin2c
> gen_netx_image
> kallsyms
> +kwbimage
> mk-am35xx-spi-image
> mkimage
> mkublheader
> diff --git a/scripts/Makefile b/scripts/Makefile
> index 08b325c..22ec4b6 100644
> --- a/scripts/Makefile
> +++ b/scripts/Makefile
> @@ -8,6 +8,7 @@ hostprogs-$(CONFIG_KALLSYMS) += kallsyms
> hostprogs-y += bin2c
> hostprogs-y += mkimage
> hostprogs-y += bareboxenv
> +hostprogs-$(CONFIG_ARCH_MVEBU) += kwbimage
> hostprogs-$(CONFIG_ARCH_NETX) += gen_netx_image
> hostprogs-$(CONFIG_ARCH_OMAP) += omap_signGP mk-am35xx-spi-image
> hostprogs-$(CONFIG_ARCH_S5PCxx) += s5p_cksum
> @@ -27,7 +28,7 @@ subdir-$(CONFIG_X86) += setupmbr
> subdir- += basic kconfig setupmbr
>
> quiet_cmd_csingle = CC $@
> - cmd_csingle = $(CC) -Wp,-MD,$(depfile) $(CFLAGS) -o $@ $<
> + cmd_csingle = $(CC) -Wp,-MD,$(depfile) $(CFLAGS) -o $@ $<
This is a whitespace change only, right? Please drop this.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-06 19:16 ` Sascha Hauer
@ 2013-05-06 20:22 ` Thomas Petazzoni
0 siblings, 0 replies; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-06 20:22 UTC (permalink / raw)
To: Sascha Hauer; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
Dear Sascha Hauer,
On Mon, 6 May 2013 21:16:15 +0200, Sascha Hauer wrote:
> > quiet_cmd_csingle = CC $@
> > - cmd_csingle = $(CC) -Wp,-MD,$(depfile) $(CFLAGS) -o $@ $<
> > + cmd_csingle = $(CC) -Wp,-MD,$(depfile) $(CFLAGS) -o $@ $<
>
> This is a whitespace change only, right? Please drop this.
Correct, will fix in v2.
(For the record, I think this white space change was due to me adding
-g to the CFLAGS of host tools in order to run the kwbimage tool under
gdb).
Thanks for the review!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images
2013-05-03 16:51 ` [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images Thomas Petazzoni
2013-05-04 19:51 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 19:16 ` Sascha Hauer
@ 2013-05-07 23:30 ` Gregory CLEMENT
2 siblings, 0 replies; 63+ messages in thread
From: Gregory CLEMENT @ 2013-05-07 23:30 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
Hi Thomas,
On 05/03/2013 06:51 PM, Thomas Petazzoni wrote:
[...]
> + * To create an image, run:
> + * ./scripts/kwbimage -x -c <image-cfg-file> -o <image-file>
here it should be
./scripts/kwbimage -c -i <image-cfg-file> -o <image-file>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 3/7] scripts: add kwboot tool
2013-05-03 16:51 [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Thomas Petazzoni
2013-05-03 16:51 ` [PATCH 1/7] scripts: allow lines longer than 80 cols with printf() in checkpatch Thomas Petazzoni
2013-05-03 16:51 ` [PATCH 2/7] scripts: new kwbimage manipulation tool for Marvell SoC boot images Thomas Petazzoni
@ 2013-05-03 16:51 ` Thomas Petazzoni
2013-05-03 16:51 ` [PATCH 4/7] arm: initial support for Marvell Armada 370/XP SoCs Thomas Petazzoni
` (6 subsequent siblings)
9 siblings, 0 replies; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-03 16:51 UTC (permalink / raw)
To: barebox; +Cc: Lior Amsalem, Willy Tarreau, Ezequiel Garcia
This tool is used with Marvell EBU SoC to trigger the UART boot mode
provided by the SoC BootROM, and push the bootloader image to the
target using the Xmodem protocol.
It has been taken from the U-Boot source code, with minor
modifications to make it work with Armada 370/XP platforms.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
scripts/.gitignore | 1 +
scripts/Makefile | 2 +-
scripts/kwboot.c | 717 ++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 719 insertions(+), 1 deletion(-)
create mode 100644 scripts/kwboot.c
diff --git a/scripts/.gitignore b/scripts/.gitignore
index 414de7f..371137e 100644
--- a/scripts/.gitignore
+++ b/scripts/.gitignore
@@ -3,6 +3,7 @@ bin2c
gen_netx_image
kallsyms
kwbimage
+kwboot
mk-am35xx-spi-image
mkimage
mkublheader
diff --git a/scripts/Makefile b/scripts/Makefile
index 22ec4b6..66935c9 100644
--- a/scripts/Makefile
+++ b/scripts/Makefile
@@ -8,7 +8,7 @@ hostprogs-$(CONFIG_KALLSYMS) += kallsyms
hostprogs-y += bin2c
hostprogs-y += mkimage
hostprogs-y += bareboxenv
-hostprogs-$(CONFIG_ARCH_MVEBU) += kwbimage
+hostprogs-$(CONFIG_ARCH_MVEBU) += kwbimage kwboot
hostprogs-$(CONFIG_ARCH_NETX) += gen_netx_image
hostprogs-$(CONFIG_ARCH_OMAP) += omap_signGP mk-am35xx-spi-image
hostprogs-$(CONFIG_ARCH_S5PCxx) += s5p_cksum
diff --git a/scripts/kwboot.c b/scripts/kwboot.c
new file mode 100644
index 0000000..afc8493
--- /dev/null
+++ b/scripts/kwboot.c
@@ -0,0 +1,717 @@
+/*
+ * Boot a Marvell Kirkwood SoC, with Xmodem over UART0.
+ *
+ * (c) 2012 Daniel Stodden <daniel.stodden@gmail.com>
+ *
+ * References: marvell.com, "88F6180, 88F6190, 88F6192, and 88F6281
+ * Integrated Controller: Functional Specifications" December 2,
+ * 2008. Chapter 24.2 "BootROM Firmware".
+ */
+
+#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <stdarg.h>
+#include <libgen.h>
+#include <fcntl.h>
+#include <errno.h>
+#include <unistd.h>
+#include <stdint.h>
+#include <termios.h>
+#include <sys/mman.h>
+#include <sys/stat.h>
+
+/*
+ * Marvell BootROM UART Sensing
+ */
+
+static unsigned char kwboot_msg_boot[] = {
+ 0xBB, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77
+};
+
+static unsigned char kwboot_msg_debug[] = {
+ 0xDD, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77
+};
+
+#define KWBOOT_MSG_REQ_DELAY 1000 /* ms */
+#define KWBOOT_MSG_RSP_TIMEO 1000 /* ms */
+
+/*
+ * Xmodem Transfers
+ */
+
+#define SOH 1 /* sender start of block header */
+#define EOT 4 /* sender end of block transfer */
+#define ACK 6 /* target block ack */
+#define NAK 21 /* target block negative ack */
+#define CAN 24 /* target/sender transfer cancellation */
+
+struct kwboot_block {
+ uint8_t soh;
+ uint8_t pnum;
+ uint8_t _pnum;
+ uint8_t data[128];
+ uint8_t csum;
+} __attribute((packed));
+
+#define KWBOOT_BLK_RSP_TIMEO 1000 /* ms */
+
+static int kwboot_verbose;
+
+static void
+kwboot_printv(const char *fmt, ...)
+{
+ va_list ap;
+
+ if (kwboot_verbose) {
+ va_start(ap, fmt);
+ vprintf(fmt, ap);
+ va_end(ap);
+ fflush(stdout);
+ }
+}
+
+static void
+__spinner(void)
+{
+ const char seq[] = { '-', '\\', '|', '/' };
+ const int div = 8;
+ static int state, bs;
+
+ if (state % div == 0) {
+ fputc(bs, stdout);
+ fputc(seq[state / div % sizeof(seq)], stdout);
+ fflush(stdout);
+ }
+
+ bs = '\b';
+ state++;
+}
+
+static void
+kwboot_spinner(void)
+{
+ if (kwboot_verbose)
+ __spinner();
+}
+
+static void
+__progress(int pct, char c)
+{
+ const int width = 70;
+ static const char *nl = "";
+ static int pos;
+
+ if (pos % width == 0)
+ printf("%s%3d %% [", nl, pct);
+
+ fputc(c, stdout);
+
+ nl = "]\n";
+ pos++;
+
+ if (pct == 100) {
+ while (pos++ < width)
+ fputc(' ', stdout);
+ fputs(nl, stdout);
+ }
+
+ fflush(stdout);
+
+}
+
+static void
+kwboot_progress(int _pct, char c)
+{
+ static int pct;
+
+ if (_pct != -1)
+ pct = _pct;
+
+ if (kwboot_verbose)
+ __progress(pct, c);
+}
+
+static int
+kwboot_tty_recv(int fd, void *buf, size_t len, int timeo)
+{
+ int rc, nfds;
+ fd_set rfds;
+ struct timeval tv;
+ ssize_t n;
+
+ rc = -1;
+
+ FD_ZERO(&rfds);
+ FD_SET(fd, &rfds);
+
+ tv.tv_sec = 0;
+ tv.tv_usec = timeo * 1000;
+ if (tv.tv_usec > 1000000) {
+ tv.tv_sec += tv.tv_usec / 1000000;
+ tv.tv_usec %= 1000000;
+ }
+
+ do {
+ nfds = select(fd + 1, &rfds, NULL, NULL, &tv);
+ if (nfds < 0)
+ goto out;
+ if (!nfds) {
+ errno = ETIMEDOUT;
+ goto out;
+ }
+
+ n = read(fd, buf, len);
+ if (n < 0)
+ goto out;
+
+ buf = (char *)buf + n;
+ len -= n;
+ } while (len > 0);
+
+ rc = 0;
+out:
+ return rc;
+}
+
+static int
+kwboot_tty_send(int fd, const void *buf, size_t len)
+{
+ int rc;
+ ssize_t n;
+
+ rc = -1;
+
+ do {
+ n = write(fd, buf, len);
+ if (n < 0)
+ goto out;
+
+ buf = (char *)buf + n;
+ len -= n;
+ } while (len > 0);
+
+ rc = tcdrain(fd);
+out:
+ return rc;
+}
+
+static int
+kwboot_tty_send_char(int fd, unsigned char c)
+{
+ return kwboot_tty_send(fd, &c, 1);
+}
+
+static speed_t
+kwboot_tty_speed(int baudrate)
+{
+ switch (baudrate) {
+ case 115200:
+ return B115200;
+ case 57600:
+ return B57600;
+ case 38400:
+ return B38400;
+ case 19200:
+ return B19200;
+ case 9600:
+ return B9600;
+ }
+
+ return -1;
+}
+
+static int
+kwboot_open_tty(const char *path, speed_t speed)
+{
+ int rc, fd;
+ struct termios tio;
+
+ rc = -1;
+
+ fd = open(path, O_RDWR|O_NOCTTY|O_NDELAY);
+ if (fd < 0)
+ goto out;
+
+ memset(&tio, 0, sizeof(tio));
+
+ tio.c_iflag = 0;
+ tio.c_cflag = CREAD|CLOCAL|CS8;
+
+ tio.c_cc[VMIN] = 1;
+ tio.c_cc[VTIME] = 10;
+
+ cfsetospeed(&tio, speed);
+ cfsetispeed(&tio, speed);
+
+ rc = tcsetattr(fd, TCSANOW, &tio);
+ if (rc)
+ goto out;
+
+ rc = fd;
+out:
+ if (rc < 0) {
+ if (fd >= 0)
+ close(fd);
+ }
+
+ return rc;
+}
+
+static int
+kwboot_bootmsg(int tty, void *msg)
+{
+ int rc;
+ char c;
+
+ kwboot_printv("Sending boot message. Please reboot the target...");
+
+ do {
+ rc = tcflush(tty, TCIOFLUSH);
+ if (rc)
+ break;
+
+ rc = kwboot_tty_send(tty, msg, 8);
+ if (rc) {
+ usleep(KWBOOT_MSG_REQ_DELAY * 1000);
+ continue;
+ }
+
+ rc = kwboot_tty_recv(tty, &c, 1, KWBOOT_MSG_RSP_TIMEO);
+
+ kwboot_spinner();
+
+ } while (rc || c != NAK);
+
+ kwboot_printv("\n");
+
+ return rc;
+}
+
+static int
+kwboot_debugmsg(int tty, void *msg)
+{
+ int rc;
+
+ kwboot_printv("Sending debug message. Please reboot the target...");
+
+ do {
+ char buf[16];
+
+ rc = tcflush(tty, TCIOFLUSH);
+ if (rc)
+ break;
+
+ rc = kwboot_tty_send(tty, msg, 8);
+ if (rc) {
+ usleep(KWBOOT_MSG_REQ_DELAY * 1000);
+ continue;
+ }
+
+ rc = kwboot_tty_recv(tty, buf, 16, KWBOOT_MSG_RSP_TIMEO);
+
+ kwboot_spinner();
+
+ } while (rc);
+
+ kwboot_printv("\n");
+
+ return rc;
+}
+
+static int
+kwboot_xm_makeblock(struct kwboot_block *block, const void *data,
+ size_t size, int pnum)
+{
+ const size_t blksz = sizeof(block->data);
+ size_t n;
+ int i;
+
+ block->pnum = pnum;
+ block->_pnum = ~block->pnum;
+
+ n = size < blksz ? size : blksz;
+ memcpy(&block->data[0], data, n);
+ memset(&block->data[n], 0, blksz - n);
+
+ block->csum = 0;
+ for (i = 0; i < n; i++)
+ block->csum += block->data[i];
+
+ return n;
+}
+
+static int
+kwboot_xm_sendblock(int fd, struct kwboot_block *block)
+{
+ int rc, retries;
+ char c;
+
+ retries = 16;
+ do {
+ rc = kwboot_tty_send(fd, block, sizeof(*block));
+ if (rc)
+ break;
+
+ do {
+ rc = kwboot_tty_recv(fd, &c, 1, KWBOOT_BLK_RSP_TIMEO);
+ if (rc)
+ break;
+
+ if (c != ACK && c!= NAK && c != CAN)
+ printf("%c", c);
+
+ } while (c != ACK && c != NAK && c != CAN);
+
+ if (c != ACK)
+ kwboot_progress(-1, '+');
+
+ } while (c == NAK && retries-- > 0);
+
+ rc = -1;
+
+ switch (c) {
+ case ACK:
+ rc = 0;
+ break;
+ case NAK:
+ errno = EBADMSG;
+ break;
+ case CAN:
+ errno = ECANCELED;
+ break;
+ default:
+ errno = EPROTO;
+ break;
+ }
+
+ return rc;
+}
+
+static int
+kwboot_xmodem(int tty, const void *_data, size_t size)
+{
+ const uint8_t *data = _data;
+ int rc, pnum, N, err;
+
+ pnum = 1;
+ N = 0;
+
+ kwboot_printv("Sending boot image...\n");
+
+ do {
+ struct kwboot_block block;
+ int n;
+
+ n = kwboot_xm_makeblock(&block,
+ data + N, size - N,
+ pnum++);
+ if (n < 0)
+ goto can;
+
+ if (!n)
+ break;
+
+ rc = kwboot_xm_sendblock(tty, &block);
+ if (rc)
+ goto out;
+
+ N += n;
+ kwboot_progress(N * 100 / size, '.');
+ } while (1);
+
+ rc = kwboot_tty_send_char(tty, EOT);
+
+out:
+ return rc;
+
+can:
+ err = errno;
+ kwboot_tty_send_char(tty, CAN);
+ errno = err;
+ goto out;
+}
+
+static int
+kwboot_term_pipe(int in, int out, char *quit, int *s)
+{
+ ssize_t nin, nout;
+ char _buf[128], *buf = _buf;
+
+ nin = read(in, buf, sizeof(buf));
+ if (nin < 0)
+ return -1;
+
+ if (quit) {
+ int i;
+
+ for (i = 0; i < nin; i++) {
+ if (*buf == quit[*s]) {
+ (*s)++;
+ if (!quit[*s])
+ return 0;
+ buf++;
+ nin--;
+ } else
+ while (*s > 0) {
+ nout = write(out, quit, *s);
+ if (nout <= 0)
+ return -1;
+ (*s) -= nout;
+ }
+ }
+ }
+
+ while (nin > 0) {
+ nout = write(out, buf, nin);
+ if (nout <= 0)
+ return -1;
+ nin -= nout;
+ }
+
+ return 0;
+}
+
+static int
+kwboot_terminal(int tty)
+{
+ int rc, in, s;
+ char *quit = "\34c";
+ struct termios otio, tio;
+
+ rc = -1;
+
+ in = STDIN_FILENO;
+ if (isatty(in)) {
+ rc = tcgetattr(in, &otio);
+ if (!rc) {
+ tio = otio;
+ cfmakeraw(&tio);
+ rc = tcsetattr(in, TCSANOW, &tio);
+ }
+ if (rc) {
+ perror("tcsetattr");
+ goto out;
+ }
+
+ kwboot_printv("[Type Ctrl-%c + %c to quit]\r\n",
+ quit[0]|0100, quit[1]);
+ } else
+ in = -1;
+
+ rc = 0;
+ s = 0;
+
+ do {
+ fd_set rfds;
+ int nfds = 0;
+
+ FD_SET(tty, &rfds);
+ nfds = nfds < tty ? tty : nfds;
+
+ if (in >= 0) {
+ FD_SET(in, &rfds);
+ nfds = nfds < in ? in : nfds;
+ }
+
+ nfds = select(nfds + 1, &rfds, NULL, NULL, NULL);
+ if (nfds < 0)
+ break;
+
+ if (FD_ISSET(tty, &rfds)) {
+ rc = kwboot_term_pipe(tty, STDOUT_FILENO, NULL, NULL);
+ if (rc)
+ break;
+ }
+
+ if (FD_ISSET(in, &rfds)) {
+ rc = kwboot_term_pipe(in, tty, quit, &s);
+ if (rc)
+ break;
+ }
+ } while (quit[s] != 0);
+
+ tcsetattr(in, TCSANOW, &otio);
+out:
+ return rc;
+}
+
+static void *
+kwboot_mmap_image(const char *path, size_t *size, int prot)
+{
+ int rc, fd, flags;
+ struct stat st;
+ void *img;
+
+ rc = -1;
+ fd = -1;
+ img = NULL;
+
+ fd = open(path, O_RDONLY);
+ if (fd < 0)
+ goto out;
+
+ rc = fstat(fd, &st);
+ if (rc)
+ goto out;
+
+ flags = (prot & PROT_WRITE) ? MAP_PRIVATE : MAP_SHARED;
+
+ img = mmap(NULL, st.st_size, prot, flags, fd, 0);
+ if (img == MAP_FAILED) {
+ img = NULL;
+ goto out;
+ }
+
+ rc = 0;
+ *size = st.st_size;
+out:
+ if (rc && img) {
+ munmap(img, st.st_size);
+ img = NULL;
+ }
+ if (fd >= 0)
+ close(fd);
+
+ return img;
+}
+
+static void
+kwboot_usage(FILE *stream, char *progname)
+{
+ fprintf(stream,
+ "Usage: %s [-d | -b <image>] [ -p ] [ -t ] "
+ "[-B <baud> ] <TTY>\n", progname);
+ fprintf(stream, "\n");
+ fprintf(stream, " -b <image>: boot <image>\n");
+ fprintf(stream, " -d: enter debug mode\n");
+ fprintf(stream, "\n");
+ fprintf(stream, " -t: mini terminal\n");
+ fprintf(stream, "\n");
+ fprintf(stream, " -B <baud>: set baud rate\n");
+ fprintf(stream, "\n");
+}
+
+int
+main(int argc, char **argv)
+{
+ const char *ttypath, *imgpath;
+ int rv, rc, tty, term;
+ void *bootmsg;
+ void *debugmsg;
+ void *img;
+ size_t size;
+ speed_t speed;
+
+ rv = 1;
+ tty = -1;
+ bootmsg = NULL;
+ debugmsg = NULL;
+ imgpath = NULL;
+ img = NULL;
+ term = 0;
+ size = 0;
+ speed = B115200;
+
+ kwboot_verbose = isatty(STDOUT_FILENO);
+
+ do {
+ int c = getopt(argc, argv, "hb:dptB:");
+ if (c < 0)
+ break;
+
+ switch (c) {
+ case 'b':
+ bootmsg = kwboot_msg_boot;
+ imgpath = optarg;
+ break;
+
+ case 'd':
+ debugmsg = kwboot_msg_debug;
+ break;
+
+ case 't':
+ term = 1;
+ break;
+
+ case 'B':
+ speed = kwboot_tty_speed(atoi(optarg));
+ if (speed == -1)
+ goto usage;
+ break;
+
+ case 'h':
+ rv = 0;
+ default:
+ goto usage;
+ }
+ } while (1);
+
+ if (!bootmsg && !term && !debugmsg)
+ goto usage;
+
+ if (argc - optind < 1)
+ goto usage;
+
+ ttypath = argv[optind++];
+
+ tty = kwboot_open_tty(ttypath, speed);
+ if (tty < 0) {
+ perror(ttypath);
+ goto out;
+ }
+
+ if (imgpath) {
+ img = kwboot_mmap_image(imgpath, &size, PROT_READ);
+ if (!img) {
+ perror(imgpath);
+ goto out;
+ }
+ }
+
+ if (debugmsg) {
+ rc = kwboot_debugmsg(tty, debugmsg);
+ if (rc) {
+ perror("debugmsg");
+ goto out;
+ }
+ }
+
+ if (bootmsg) {
+ rc = kwboot_bootmsg(tty, bootmsg);
+ if (rc) {
+ perror("bootmsg");
+ goto out;
+ }
+ }
+
+ if (img) {
+ rc = kwboot_xmodem(tty, img, size);
+ if (rc) {
+ perror("xmodem");
+ goto out;
+ }
+ }
+
+ if (term) {
+ rc = kwboot_terminal(tty);
+ if (rc && !(errno == EINTR)) {
+ perror("terminal");
+ goto out;
+ }
+ }
+
+ rv = 0;
+out:
+ if (tty >= 0)
+ close(tty);
+
+ if (img)
+ munmap(img, size);
+
+ return rv;
+
+usage:
+ kwboot_usage(rv ? stderr : stdout, basename(argv[0]));
+ goto out;
+}
--
1.7.9.5
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 4/7] arm: initial support for Marvell Armada 370/XP SoCs
2013-05-03 16:51 [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Thomas Petazzoni
` (2 preceding siblings ...)
2013-05-03 16:51 ` [PATCH 3/7] scripts: add kwboot tool Thomas Petazzoni
@ 2013-05-03 16:51 ` Thomas Petazzoni
2013-05-06 14:09 ` Thomas Petazzoni
2013-05-03 16:51 ` [PATCH 5/7] arm: add basic support for Armada XP OpenBlocks AX3 platform Thomas Petazzoni
` (5 subsequent siblings)
9 siblings, 1 reply; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-03 16:51 UTC (permalink / raw)
To: barebox; +Cc: Lior Amsalem, Willy Tarreau, Ezequiel Garcia
This commit adds minimal support for the Armada 370 and Armada XP SoCs
from Marvell.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/Kconfig | 8 ++
arch/arm/Makefile | 1 +
arch/arm/mach-mvebu/Kconfig | 40 ++++++++
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/mach-mvebu/core.c | 142 +++++++++++++++++++++++++++
arch/arm/mach-mvebu/include/mach/clkdev.h | 7 ++
arch/arm/mach-mvebu/include/mach/debug_ll.h | 40 ++++++++
arch/arm/mach-mvebu/include/mach/mvebu.h | 22 +++++
drivers/clocksource/Kconfig | 4 +
drivers/clocksource/Makefile | 1 +
drivers/clocksource/mvebu.c | 90 +++++++++++++++++
11 files changed, 356 insertions(+)
create mode 100644 arch/arm/mach-mvebu/Kconfig
create mode 100644 arch/arm/mach-mvebu/Makefile
create mode 100644 arch/arm/mach-mvebu/core.c
create mode 100644 arch/arm/mach-mvebu/include/mach/clkdev.h
create mode 100644 arch/arm/mach-mvebu/include/mach/debug_ll.h
create mode 100644 arch/arm/mach-mvebu/include/mach/mvebu.h
create mode 100644 drivers/clocksource/mvebu.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 7ac134e..4053c4d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -67,6 +67,13 @@ config ARCH_IMX
select WATCHDOG_IMX_RESET_SOURCE
select HAS_DEBUG_LL
+config ARCH_MVEBU
+ bool "Marvell EBU platforms"
+ select COMMON_CLK
+ select CLOCKSOURCE_MVEBU
+ select CLKDEV_LOOKUP
+ select HAS_DEBUG_LL
+
config ARCH_MXS
bool "Freescale i.MX23/28 (mxs) based"
select GENERIC_GPIO
@@ -138,6 +145,7 @@ source arch/arm/mach-ep93xx/Kconfig
source arch/arm/mach-highbank/Kconfig
source arch/arm/mach-imx/Kconfig
source arch/arm/mach-mxs/Kconfig
+source arch/arm/mach-mvebu/Kconfig
source arch/arm/mach-netx/Kconfig
source arch/arm/mach-nomadik/Kconfig
source arch/arm/mach-omap/Kconfig
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index b98d6b8..6e7acde 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -58,6 +58,7 @@ machine-$(CONFIG_ARCH_EP93XX) := ep93xx
machine-$(CONFIG_ARCH_HIGHBANK) := highbank
machine-$(CONFIG_ARCH_IMX) := imx
machine-$(CONFIG_ARCH_MXS) := mxs
+machine-$(CONFIG_ARCH_MVEBU) := mvebu
machine-$(CONFIG_ARCH_NOMADIK) := nomadik
machine-$(CONFIG_ARCH_NETX) := netx
machine-$(CONFIG_ARCH_OMAP) := omap
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
new file mode 100644
index 0000000..4cbe546
--- /dev/null
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -0,0 +1,40 @@
+if ARCH_MVEBU
+
+config ARCH_TEXT_BASE
+ hex
+
+config BOARDINFO
+ default
+
+choice
+ prompt "Marvell EBU Processor"
+
+config ARCH_ARMADA_370
+ bool "Armada 370"
+ select CPU_V7
+
+config ARCH_ARMADA_XP
+ bool "Armada XP"
+ select CPU_V7
+
+endchoice
+
+if ARCH_ARMADA_370
+
+choice
+ prompt "Armada 370 Board Type"
+
+endchoice
+
+endif # ARCH_ARMADA_370
+
+if ARCH_ARMADA_XP
+
+choice
+ prompt "Armada XP Board Type"
+
+endchoice
+
+endif # ARCH_ARMADA_XP
+
+endif # ARCH_MVEBU
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
new file mode 100644
index 0000000..820eb10
--- /dev/null
+++ b/arch/arm/mach-mvebu/Makefile
@@ -0,0 +1 @@
+obj-y += core.o
diff --git a/arch/arm/mach-mvebu/core.c b/arch/arm/mach-mvebu/core.c
new file mode 100644
index 0000000..f4672a3
--- /dev/null
+++ b/arch/arm/mach-mvebu/core.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright (C) 2013 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <init.h>
+#include <io.h>
+#include <linux/clk.h>
+#include <linux/clkdev.h>
+#include <ns16550.h>
+#include <asm/memory.h>
+#include <asm/barebox-arm.h>
+
+#define MVEBU_INT_REGS_BASE (0xd0000000)
+#define MVEBU_UART0_BASE (MVEBU_INT_REGS_BASE + 0x12000)
+#define MVEBU_SYSCTL_BASE (MVEBU_INT_REGS_BASE + 0x18200)
+#define MVEBU_SDRAM_WIN_BASE (MVEBU_INT_REGS_BASE + 0x20180)
+#define MVEBU_TIMER_BASE (MVEBU_INT_REGS_BASE + 0x20300)
+#define MVEBU_SAR_BASE (MVEBU_INT_REGS_BASE + 0x18230)
+
+#define DDR_BASE_CS_OFF(n) (0x0000 + ((n) << 3))
+#define DDR_BASE_CS_HIGH_MASK 0xf
+#define DDR_BASE_CS_LOW_MASK 0xff000000
+#define DDR_SIZE_CS_OFF(n) (0x0004 + ((n) << 3))
+#define DDR_SIZE_ENABLED (1 << 0)
+#define DDR_SIZE_CS_MASK 0x1c
+#define DDR_SIZE_CS_SHIFT 2
+#define DDR_SIZE_MASK 0xff000000
+
+#define SAR_LOW_REG_OFF 0
+#define SAR_TCLK_FREQ_BIT 20
+#define SAR_HIGH_REG_OFF 0x4
+
+static struct clk *tclk;
+
+static inline void mvebu_memory_find(unsigned long *phys_base,
+ unsigned long *phys_size)
+{
+ void __iomem *sdram_win = IOMEM(MVEBU_SDRAM_WIN_BASE);
+ int cs;
+
+ *phys_base = ~0;
+ *phys_size = 0;
+
+ for (cs = 0; cs < 4; cs++) {
+ uint32_t base = readl(sdram_win + DDR_BASE_CS_OFF(cs));
+ uint32_t ctrl = readl(sdram_win + DDR_SIZE_CS_OFF(cs));
+
+ /* Skip non-enabled CS */
+ if (! (ctrl & DDR_SIZE_ENABLED))
+ continue;
+
+ base &= DDR_BASE_CS_LOW_MASK;
+ if (base < *phys_base)
+ *phys_base = base;
+ *phys_size += (ctrl | ~DDR_SIZE_MASK) + 1;
+ }
+}
+
+void __naked __noreturn mvebu_barebox_entry(void)
+{
+ unsigned long phys_base, phys_size;
+ mvebu_memory_find(&phys_base, &phys_size);
+ barebox_arm_entry(phys_base, phys_size, 0);
+}
+
+static struct NS16550_plat uart0_plat = {
+ .shift = 2,
+};
+
+int mvebu_add_uart0(void)
+{
+ uart0_plat.clock = clk_get_rate(tclk);
+ add_ns16550_device(DEVICE_ID_DYNAMIC, MVEBU_UART0_BASE, 32,
+ IORESOURCE_MEM_32BIT, &uart0_plat);
+ return 0;
+}
+
+#if defined(CONFIG_ARCH_ARMADA_370)
+static int mvebu_init_clocks(void)
+{
+ uint32_t val;
+ unsigned int rate;
+ void __iomem *sar = IOMEM(MVEBU_SAR_BASE) + SAR_LOW_REG_OFF;
+
+ val = readl(sar);
+
+ /* On Armada 370, the TCLK frequency can be either 166 Mhz or
+ * 200 Mhz */
+ if (val & (1 << SAR_TCLK_FREQ_BIT))
+ rate = 200 * 1000 * 1000;
+ else
+ rate = 166 * 1000 * 1000;
+
+ tclk = clk_fixed("tclk", rate);
+ return clk_register_clkdev(tclk, NULL, "mvebu-timer");
+}
+#endif
+
+#if defined(CONFIG_ARCH_ARMADA_XP)
+static int mvebu_init_clocks(void)
+{
+ /* On Armada XP, the TCLK frequency is always 250 Mhz */
+ tclk = clk_fixed("tclk", 250 * 1000 * 1000);
+ return clk_register_clkdev(tclk, NULL, "mvebu-timer");
+}
+#endif
+
+static int mvebu_init_soc(void)
+{
+ unsigned long phys_base, phys_size;
+
+ mvebu_init_clocks();
+ add_generic_device("mvebu-timer", DEVICE_ID_SINGLE, NULL,
+ MVEBU_TIMER_BASE, 0x30, IORESOURCE_MEM,
+ NULL);
+ mvebu_memory_find(&phys_base, &phys_size);
+ arm_add_mem_device("ram0", phys_base, phys_size);
+ return 0;
+}
+
+postcore_initcall(mvebu_init_soc);
+
+void __noreturn reset_cpu(unsigned long addr)
+{
+ writel(0x1, MVEBU_SYSCTL_BASE + 0x60);
+ writel(0x1, MVEBU_SYSCTL_BASE + 0x64);
+ while (1)
+ ;
+}
+EXPORT_SYMBOL(reset_cpu);
diff --git a/arch/arm/mach-mvebu/include/mach/clkdev.h b/arch/arm/mach-mvebu/include/mach/clkdev.h
new file mode 100644
index 0000000..04b37a8
--- /dev/null
+++ b/arch/arm/mach-mvebu/include/mach/clkdev.h
@@ -0,0 +1,7 @@
+#ifndef __ASM_MACH_CLKDEV_H
+#define __ASM_MACH_CLKDEV_H
+
+#define __clk_get(clk) ({ 1; })
+#define __clk_put(clk) do { } while (0)
+
+#endif
diff --git a/arch/arm/mach-mvebu/include/mach/debug_ll.h b/arch/arm/mach-mvebu/include/mach/debug_ll.h
new file mode 100644
index 0000000..2653573
--- /dev/null
+++ b/arch/arm/mach-mvebu/include/mach/debug_ll.h
@@ -0,0 +1,40 @@
+/*
+ * Copyright (C) 2013 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __MACH_DEBUG_LL_H__
+#define __MACH_DEBUG_LL_H__
+
+#include <io.h>
+
+#define UART_BASE 0xd0012000
+#define UART_THR 0x0
+#define UART_LSR 0x14
+#define UART_LSR_THRE (1 << 5)
+
+static inline void PUTC_LL(char c)
+{
+ /* Wait until there is space in the FIFO */
+ while (!(readl(UART_BASE + UART_LSR) & UART_LSR_THRE))
+ ;
+
+ /* Send the character */
+ writel(c, UART_BASE + UART_THR)
+ ;
+
+ /* Wait to make sure it hits the line, in case we die too soon. */
+ while (!(readl(UART_BASE + UART_LSR) & UART_LSR_THRE))
+ ;
+}
+#endif
diff --git a/arch/arm/mach-mvebu/include/mach/mvebu.h b/arch/arm/mach-mvebu/include/mach/mvebu.h
new file mode 100644
index 0000000..e13a446
--- /dev/null
+++ b/arch/arm/mach-mvebu/include/mach/mvebu.h
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2013 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __MACH_MVEBU_H
+#define __MACH_MVEBU_H
+
+int mvebu_add_uart0(void);
+void __naked __noreturn mvebu_barebox_entry(void);
+
+#endif /* __MACH_MVEBU_H */
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 3f27cf2..073ffd5 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -10,6 +10,10 @@ config CLOCKSOURCE_BCM2835
bool
depends on ARCH_BCM2835
+config CLOCKSOURCE_MVEBU
+ bool
+ depends on ARCH_MVEBU
+
config CLOCKSOURCE_NOMADIK
bool
depends on ARM
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index b0bc8bd..0ab7c37 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_AMBA_SP804) += amba-sp804.o
obj-$(CONFIG_ARM_SMP_TWD) += arm_smp_twd.o
obj-$(CONFIG_CLOCKSOURCE_BCM2835) += bcm2835.o
+obj-$(CONFIG_CLOCKSOURCE_MVEBU) += mvebu.o
obj-$(CONFIG_CLOCKSOURCE_NOMADIK) += nomadik.o
diff --git a/drivers/clocksource/mvebu.c b/drivers/clocksource/mvebu.c
new file mode 100644
index 0000000..2b48a5c
--- /dev/null
+++ b/drivers/clocksource/mvebu.c
@@ -0,0 +1,90 @@
+/*
+ * Copyright (C) 2013 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <init.h>
+#include <clock.h>
+#include <linux/clk.h>
+#include <io.h>
+
+#define TIMER_CTRL_OFF 0x0000
+#define TIMER0_EN 0x0001
+#define TIMER0_RELOAD_EN 0x0002
+#define TIMER0_25MHZ 0x0800
+#define TIMER0_DIV(div) ((div) << 19)
+#define TIMER1_EN 0x0004
+#define TIMER1_RELOAD_EN 0x0008
+#define TIMER1_25MHZ 0x1000
+#define TIMER1_DIV(div) ((div) << 22)
+#define TIMER_EVENTS_STATUS 0x0004
+#define TIMER0_CLR_MASK (~0x1)
+#define TIMER1_CLR_MASK (~0x100)
+#define TIMER0_RELOAD_OFF 0x0010
+#define TIMER0_VAL_OFF 0x0014
+#define TIMER1_RELOAD_OFF 0x0018
+#define TIMER1_VAL_OFF 0x001c
+
+#define TIMER_DIVIDER_SHIFT 5
+
+static __iomem void *timer_base;
+
+uint64_t mvebu_clocksource_read(void)
+{
+ return __raw_readl(timer_base + TIMER0_VAL_OFF);
+}
+
+static struct clocksource cs = {
+ .read = mvebu_clocksource_read,
+ .mask = CLOCKSOURCE_MASK(32),
+ .shift = 10,
+};
+
+static int mvebu_timer_probe(struct device_d *dev)
+{
+ struct clk *tclk;
+ u32 val;
+
+ timer_base = dev_request_mem_region(dev, 0);
+
+ tclk = clk_get(dev, "tclk");
+
+ val = __raw_readl(timer_base + TIMER_CTRL_OFF);
+ val &= ~TIMER0_25MHZ;
+ __raw_writel(val, timer_base + TIMER_CTRL_OFF);
+
+ __raw_writel(0xffffffff, timer_base + TIMER0_VAL_OFF);
+ __raw_writel(0xffffffff, timer_base + TIMER0_RELOAD_OFF);
+
+ val = __raw_readl(timer_base + TIMER_CTRL_OFF);
+ val |= TIMER0_EN | TIMER0_RELOAD_EN | TIMER0_DIV(TIMER_DIVIDER_SHIFT);
+ __raw_writel(val, timer_base + TIMER_CTRL_OFF);
+
+ cs.mult = clocksource_hz2mult(clk_get_rate(tclk), cs.shift);
+
+ init_clock(&cs);
+
+ return 0;
+}
+
+static struct driver_d mvebu_timer_driver = {
+ .name = "mvebu-timer",
+ .probe = mvebu_timer_probe,
+};
+
+static int mvebu_timer_init(void)
+{
+ return platform_driver_register(&mvebu_timer_driver);
+}
+postcore_initcall(mvebu_timer_init);
--
1.7.9.5
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH 4/7] arm: initial support for Marvell Armada 370/XP SoCs
2013-05-03 16:51 ` [PATCH 4/7] arm: initial support for Marvell Armada 370/XP SoCs Thomas Petazzoni
@ 2013-05-06 14:09 ` Thomas Petazzoni
2013-05-06 14:07 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 14:30 ` Sascha Hauer
0 siblings, 2 replies; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-06 14:09 UTC (permalink / raw)
To: Sascha Hauer, Jean-Christophe PLAGNIOL-VILLARD
Cc: barebox, Lior Amsalem, Willy Tarreau, Ezequiel Garcia
Sascha, Jean-Christophe,
I have one question below regarding the SoC code.
On Fri, 3 May 2013 18:51:08 +0200, Thomas Petazzoni wrote:
> +static inline void mvebu_memory_find(unsigned long *phys_base,
> + unsigned long *phys_size)
> +{
> + void __iomem *sdram_win = IOMEM(MVEBU_SDRAM_WIN_BASE);
> + int cs;
Here...
> + *phys_base = ~0;
> + *phys_size = 0;
> +
> + for (cs = 0; cs < 4; cs++) {
> + uint32_t base = readl(sdram_win + DDR_BASE_CS_OFF(cs));
> + uint32_t ctrl = readl(sdram_win + DDR_SIZE_CS_OFF(cs));
... here ...
> +#if defined(CONFIG_ARCH_ARMADA_370)
> +static int mvebu_init_clocks(void)
> +{
> + uint32_t val;
> + unsigned int rate;
> + void __iomem *sar = IOMEM(MVEBU_SAR_BASE) + SAR_LOW_REG_OFF;
> +
> + val = readl(sar);
... and here, I'm directly poking at physical addresses, but it seems
like Barebox can run with the MMU enabled. Should I be mapping those
registers before accessing them? I see that drivers use
dev_request_mem_region(), but this clock and memory code isn't (yet?) a
driver per-se.
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH 4/7] arm: initial support for Marvell Armada 370/XP SoCs
2013-05-06 14:09 ` Thomas Petazzoni
@ 2013-05-06 14:07 ` Jean-Christophe PLAGNIOL-VILLARD
2013-05-06 14:30 ` Sascha Hauer
1 sibling, 0 replies; 63+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-05-06 14:07 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Lior Amsalem, barebox, Ezequiel Garcia, Willy Tarreau
On 16:09 Mon 06 May , Thomas Petazzoni wrote:
> Sascha, Jean-Christophe,
>
> I have one question below regarding the SoC code.
>
> On Fri, 3 May 2013 18:51:08 +0200, Thomas Petazzoni wrote:
> > +static inline void mvebu_memory_find(unsigned long *phys_base,
> > + unsigned long *phys_size)
> > +{
> > + void __iomem *sdram_win = IOMEM(MVEBU_SDRAM_WIN_BASE);
> > + int cs;
>
>
> Here...
>
> > + *phys_base = ~0;
> > + *phys_size = 0;
> > +
> > + for (cs = 0; cs < 4; cs++) {
> > + uint32_t base = readl(sdram_win + DDR_BASE_CS_OFF(cs));
> > + uint32_t ctrl = readl(sdram_win + DDR_SIZE_CS_OFF(cs));
>
> ... here ...
>
>
> > +#if defined(CONFIG_ARCH_ARMADA_370)
> > +static int mvebu_init_clocks(void)
> > +{
> > + uint32_t val;
> > + unsigned int rate;
> > + void __iomem *sar = IOMEM(MVEBU_SAR_BASE) + SAR_LOW_REG_OFF;
> > +
> > + val = readl(sar);
>
> ... and here, I'm directly poking at physical addresses, but it seems
> like Barebox can run with the MMU enabled. Should I be mapping those
> registers before accessing them? I see that drivers use
> dev_request_mem_region(), but this clock and memory code isn't (yet?) a
> driver per-se.
no as only the ddr is cached but the dev_request_mem_region track who request
what yes please create a device/drivers as you will be able to probe a dt
(even builtin) in this case
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH 4/7] arm: initial support for Marvell Armada 370/XP SoCs
2013-05-06 14:09 ` Thomas Petazzoni
2013-05-06 14:07 ` Jean-Christophe PLAGNIOL-VILLARD
@ 2013-05-06 14:30 ` Sascha Hauer
2013-05-06 14:34 ` Thomas Petazzoni
1 sibling, 1 reply; 63+ messages in thread
From: Sascha Hauer @ 2013-05-06 14:30 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Lior Amsalem, barebox, Ezequiel Garcia, Willy Tarreau
On Mon, May 06, 2013 at 04:09:16PM +0200, Thomas Petazzoni wrote:
> Sascha, Jean-Christophe,
>
> I have one question below regarding the SoC code.
>
> On Fri, 3 May 2013 18:51:08 +0200, Thomas Petazzoni wrote:
> > +static inline void mvebu_memory_find(unsigned long *phys_base,
> > + unsigned long *phys_size)
> > +{
> > + void __iomem *sdram_win = IOMEM(MVEBU_SDRAM_WIN_BASE);
> > + int cs;
>
>
> Here...
>
> > + *phys_base = ~0;
> > + *phys_size = 0;
> > +
> > + for (cs = 0; cs < 4; cs++) {
> > + uint32_t base = readl(sdram_win + DDR_BASE_CS_OFF(cs));
> > + uint32_t ctrl = readl(sdram_win + DDR_SIZE_CS_OFF(cs));
>
> ... here ...
>
>
> > +#if defined(CONFIG_ARCH_ARMADA_370)
> > +static int mvebu_init_clocks(void)
> > +{
> > + uint32_t val;
> > + unsigned int rate;
> > + void __iomem *sar = IOMEM(MVEBU_SAR_BASE) + SAR_LOW_REG_OFF;
> > +
> > + val = readl(sar);
>
> ... and here, I'm directly poking at physical addresses, but it seems
> like Barebox can run with the MMU enabled. Should I be mapping those
> registers before accessing them?
We use the MMU, but we use a 1:1 mapping. The SDRAM is mapped cached and
the rest is mapped uncached. This means you can simply access all
registers without mapping them
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH 4/7] arm: initial support for Marvell Armada 370/XP SoCs
2013-05-06 14:30 ` Sascha Hauer
@ 2013-05-06 14:34 ` Thomas Petazzoni
2013-05-06 14:46 ` Sascha Hauer
0 siblings, 1 reply; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-06 14:34 UTC (permalink / raw)
To: Sascha Hauer; +Cc: Lior Amsalem, barebox, Ezequiel Garcia, Willy Tarreau
Dear Sascha Hauer,
On Mon, 6 May 2013 16:30:30 +0200, Sascha Hauer wrote:
> > ... and here, I'm directly poking at physical addresses, but it seems
> > like Barebox can run with the MMU enabled. Should I be mapping those
> > registers before accessing them?
>
> We use the MMU, but we use a 1:1 mapping. The SDRAM is mapped cached and
> the rest is mapped uncached. This means you can simply access all
> registers without mapping them
Ok, thanks. So you're not overly chocked by those readl() poking
directly at physical addresses, if I understand correctly.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 4/7] arm: initial support for Marvell Armada 370/XP SoCs
2013-05-06 14:34 ` Thomas Petazzoni
@ 2013-05-06 14:46 ` Sascha Hauer
2013-05-06 14:48 ` Thomas Petazzoni
0 siblings, 1 reply; 63+ messages in thread
From: Sascha Hauer @ 2013-05-06 14:46 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Lior Amsalem, barebox, Ezequiel Garcia, Willy Tarreau
On Mon, May 06, 2013 at 04:34:24PM +0200, Thomas Petazzoni wrote:
> Dear Sascha Hauer,
>
> On Mon, 6 May 2013 16:30:30 +0200, Sascha Hauer wrote:
>
> > > ... and here, I'm directly poking at physical addresses, but it seems
> > > like Barebox can run with the MMU enabled. Should I be mapping those
> > > registers before accessing them?
> >
> > We use the MMU, but we use a 1:1 mapping. The SDRAM is mapped cached and
> > the rest is mapped uncached. This means you can simply access all
> > registers without mapping them
>
> Ok, thanks. So you're not overly chocked by those readl() poking
> directly at physical addresses, if I understand correctly.
Not at all, we do this everywhere. There is a tendency to turn units
into proper drivers though as drivers show up in the 'iomem' command and
with drivers it's generally easier to abstract between different SoCs.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 4/7] arm: initial support for Marvell Armada 370/XP SoCs
2013-05-06 14:46 ` Sascha Hauer
@ 2013-05-06 14:48 ` Thomas Petazzoni
0 siblings, 0 replies; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-06 14:48 UTC (permalink / raw)
To: Sascha Hauer; +Cc: Lior Amsalem, barebox, Ezequiel Garcia, Willy Tarreau
Dear Sascha Hauer,
On Mon, 6 May 2013 16:46:34 +0200, Sascha Hauer wrote:
> > > We use the MMU, but we use a 1:1 mapping. The SDRAM is mapped cached and
> > > the rest is mapped uncached. This means you can simply access all
> > > registers without mapping them
> >
> > Ok, thanks. So you're not overly chocked by those readl() poking
> > directly at physical addresses, if I understand correctly.
>
> Not at all, we do this everywhere. There is a tendency to turn units
> into proper drivers though as drivers show up in the 'iomem' command and
> with drivers it's generally easier to abstract between different SoCs.
Ok. The code in this patch is really an initial support, and I expect
the clock and DRAM stuff to evolve as support for other Marvell SOCs
will be added, or for additional devices.
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 5/7] arm: add basic support for Armada XP OpenBlocks AX3 platform
2013-05-03 16:51 [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Thomas Petazzoni
` (3 preceding siblings ...)
2013-05-03 16:51 ` [PATCH 4/7] arm: initial support for Marvell Armada 370/XP SoCs Thomas Petazzoni
@ 2013-05-03 16:51 ` Thomas Petazzoni
2013-05-05 6:59 ` Sascha Hauer
2013-05-03 16:51 ` [PATCH 6/7] arm: add basic support for the Armada 370 Mirabox platform Thomas Petazzoni
` (4 subsequent siblings)
9 siblings, 1 reply; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-03 16:51 UTC (permalink / raw)
To: barebox; +Cc: Lior Amsalem, Willy Tarreau, Ezequiel Garcia
The OpenBlocks AX3 platform is manufactured by PlatHome and uses the
MV78260 dual-core SoC from the Armada XP family.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/Makefile | 1 +
arch/arm/boards/plathome-openblocks-ax3/Makefile | 2 ++
arch/arm/boards/plathome-openblocks-ax3/config.h | 4 ++++
.../boards/plathome-openblocks-ax3/kwbimage.cfg | 8 +++++++
arch/arm/boards/plathome-openblocks-ax3/lowlevel.c | 25 ++++++++++++++++++++
.../plathome-openblocks-ax3.c | 25 ++++++++++++++++++++
arch/arm/configs/plathome_openblocks_ax3_defconfig | 9 +++++++
arch/arm/mach-mvebu/Kconfig | 6 ++++-
8 files changed, 79 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boards/plathome-openblocks-ax3/Makefile
create mode 100644 arch/arm/boards/plathome-openblocks-ax3/config.h
create mode 100644 arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
create mode 100644 arch/arm/boards/plathome-openblocks-ax3/lowlevel.c
create mode 100644 arch/arm/boards/plathome-openblocks-ax3/plathome-openblocks-ax3.c
create mode 100644 arch/arm/configs/plathome_openblocks_ax3_defconfig
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 6e7acde..ad8b355 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -142,6 +142,7 @@ board-$(CONFIG_MACH_GUF_CUPID) := guf-cupid
board-$(CONFIG_MACH_MINI2440) := friendlyarm-mini2440
board-$(CONFIG_MACH_MINI6410) := friendlyarm-mini6410
board-$(CONFIG_MACH_TINY6410) := friendlyarm-tiny6410
+board-$(CONFIG_MACH_PLATHOME_OPENBLOCKS_AX3) := plathome-openblocks-ax3
board-$(CONFIG_MACH_QIL_A9260) := qil-a9260
board-$(CONFIG_MACH_TNY_A9260) := tny-a926x
board-$(CONFIG_MACH_TNY_A9263) := tny-a926x
diff --git a/arch/arm/boards/plathome-openblocks-ax3/Makefile b/arch/arm/boards/plathome-openblocks-ax3/Makefile
new file mode 100644
index 0000000..91dc764
--- /dev/null
+++ b/arch/arm/boards/plathome-openblocks-ax3/Makefile
@@ -0,0 +1,2 @@
+obj-y = plathome-openblocks-ax3.o
+lwl-y += lowlevel.o
diff --git a/arch/arm/boards/plathome-openblocks-ax3/config.h b/arch/arm/boards/plathome-openblocks-ax3/config.h
new file mode 100644
index 0000000..ca15136
--- /dev/null
+++ b/arch/arm/boards/plathome-openblocks-ax3/config.h
@@ -0,0 +1,4 @@
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#endif /* __CONFIG_H */
diff --git a/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg b/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
new file mode 100644
index 0000000..0ae1efd
--- /dev/null
+++ b/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
@@ -0,0 +1,8 @@
+VERSION 1
+BOOT_FROM spi
+DESTADDR 00000000
+EXECADDR 00000000
+NAND_BLKSZ 00000000
+NAND_BADBLK_LOCATION 00
+BINARY binary.0 0000005b 00000068
+PAYLOAD barebox.bin
diff --git a/arch/arm/boards/plathome-openblocks-ax3/lowlevel.c b/arch/arm/boards/plathome-openblocks-ax3/lowlevel.c
new file mode 100644
index 0000000..e9b2e30
--- /dev/null
+++ b/arch/arm/boards/plathome-openblocks-ax3/lowlevel.c
@@ -0,0 +1,25 @@
+/*
+ * Copyright (C) 2013 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <mach/mvebu.h>
+#include <asm/barebox-arm.h>
+#include <asm/barebox-arm-head.h>
+
+void __naked barebox_arm_reset_vector(void)
+{
+ arm_cpu_lowlevel_init();
+ mvebu_barebox_entry();
+}
diff --git a/arch/arm/boards/plathome-openblocks-ax3/plathome-openblocks-ax3.c b/arch/arm/boards/plathome-openblocks-ax3/plathome-openblocks-ax3.c
new file mode 100644
index 0000000..9daf020
--- /dev/null
+++ b/arch/arm/boards/plathome-openblocks-ax3/plathome-openblocks-ax3.c
@@ -0,0 +1,25 @@
+/*
+ * Copyright (C) 2013 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <init.h>
+#include <mach/mvebu.h>
+
+static int plathome_openblocks_ax3_console_init(void)
+{
+ return mvebu_add_uart0();
+}
+
+console_initcall(plathome_openblocks_ax3_console_init);
diff --git a/arch/arm/configs/plathome_openblocks_ax3_defconfig b/arch/arm/configs/plathome_openblocks_ax3_defconfig
new file mode 100644
index 0000000..95449c9
--- /dev/null
+++ b/arch/arm/configs/plathome_openblocks_ax3_defconfig
@@ -0,0 +1,9 @@
+CONFIG_ARCH_MVEBU=y
+CONFIG_ARCH_ARMADA_XP=y
+CONFIG_AEABI=y
+CONFIG_DEBUG_LL=y
+CONFIG_CMD_LOADY=y
+CONFIG_CMD_LOADS=y
+CONFIG_CMD_RESET=y
+CONFIG_CMD_CLK=y
+CONFIG_DRIVER_SERIAL_NS16550=y
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 4cbe546..9196251 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -2,9 +2,10 @@ if ARCH_MVEBU
config ARCH_TEXT_BASE
hex
+ default 0x2000000 if MACH_PLATHOME_OPENBLOCKS_AX3
config BOARDINFO
- default
+ default "PlatHome OpenBlocks AX3" if MACH_PLATHOME_OPENBLOCKS_AX3
choice
prompt "Marvell EBU Processor"
@@ -33,6 +34,9 @@ if ARCH_ARMADA_XP
choice
prompt "Armada XP Board Type"
+config MACH_PLATHOME_OPENBLOCKS_AX3
+ bool "PlatHome OpenBlocks AX3"
+
endchoice
endif # ARCH_ARMADA_XP
--
1.7.9.5
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH 5/7] arm: add basic support for Armada XP OpenBlocks AX3 platform
2013-05-03 16:51 ` [PATCH 5/7] arm: add basic support for Armada XP OpenBlocks AX3 platform Thomas Petazzoni
@ 2013-05-05 6:59 ` Sascha Hauer
0 siblings, 0 replies; 63+ messages in thread
From: Sascha Hauer @ 2013-05-05 6:59 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
On Fri, May 03, 2013 at 06:51:09PM +0200, Thomas Petazzoni wrote:
> diff --git a/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg b/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
> new file mode 100644
> index 0000000..0ae1efd
> --- /dev/null
> +++ b/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
> @@ -0,0 +1,8 @@
> +VERSION 1
> +BOOT_FROM spi
> +DESTADDR 00000000
> +EXECADDR 00000000
> +NAND_BLKSZ 00000000
> +NAND_BADBLK_LOCATION 00
> +BINARY binary.0 0000005b 00000068
> +PAYLOAD barebox.bin
I think the payload file should be configurable on the commandline of
the kwbimage tool. When using compressed images the filename would be
zbarebox.bin for example.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* [PATCH 6/7] arm: add basic support for the Armada 370 Mirabox platform
2013-05-03 16:51 [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Thomas Petazzoni
` (4 preceding siblings ...)
2013-05-03 16:51 ` [PATCH 5/7] arm: add basic support for Armada XP OpenBlocks AX3 platform Thomas Petazzoni
@ 2013-05-03 16:51 ` Thomas Petazzoni
2013-05-03 16:51 ` [PATCH 7/7] arm: add basic support for the Armada XP GP platform Thomas Petazzoni
` (3 subsequent siblings)
9 siblings, 0 replies; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-03 16:51 UTC (permalink / raw)
To: barebox; +Cc: Lior Amsalem, Willy Tarreau, Ezequiel Garcia
The Mirabox is a platform manufactured by Globalscale, and based on
the Marvell Armada 370 SoC.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/Makefile | 1 +
arch/arm/boards/globalscale-mirabox/Makefile | 2 ++
arch/arm/boards/globalscale-mirabox/config.h | 4 +++
.../globalscale-mirabox/globalscale-mirabox.c | 26 ++++++++++++++++++++
arch/arm/boards/globalscale-mirabox/kwbimage.cfg | 8 ++++++
arch/arm/boards/globalscale-mirabox/lowlevel.c | 26 ++++++++++++++++++++
arch/arm/configs/globalscale_mirabox_defconfig | 8 ++++++
arch/arm/mach-mvebu/Kconfig | 5 ++++
8 files changed, 80 insertions(+)
create mode 100644 arch/arm/boards/globalscale-mirabox/Makefile
create mode 100644 arch/arm/boards/globalscale-mirabox/config.h
create mode 100644 arch/arm/boards/globalscale-mirabox/globalscale-mirabox.c
create mode 100644 arch/arm/boards/globalscale-mirabox/kwbimage.cfg
create mode 100644 arch/arm/boards/globalscale-mirabox/lowlevel.c
create mode 100644 arch/arm/configs/globalscale_mirabox_defconfig
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index ad8b355..e6604b4 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -101,6 +101,7 @@ board-$(CONFIG_MACH_EUKREA_CPUIMX51SD) := eukrea_cpuimx51
board-$(CONFIG_MACH_FREESCALE_MX25_3STACK) := freescale-mx25-3-stack
board-$(CONFIG_MACH_FREESCALE_MX35_3STACK) := freescale-mx35-3-stack
board-$(CONFIG_MACH_GE863) := telit-evk-pro3
+board-$(CONFIG_MACH_GLOBALSCALE_MIRABOX) := globalscale-mirabox
board-$(CONFIG_MACH_HIGHBANK) := highbank
board-$(CONFIG_MACH_IMX21ADS) := imx21ads
board-$(CONFIG_MACH_IMX27ADS) := imx27ads
diff --git a/arch/arm/boards/globalscale-mirabox/Makefile b/arch/arm/boards/globalscale-mirabox/Makefile
new file mode 100644
index 0000000..bd5d47e
--- /dev/null
+++ b/arch/arm/boards/globalscale-mirabox/Makefile
@@ -0,0 +1,2 @@
+obj-y = globalscale-mirabox.o
+lwl-y += lowlevel.o
diff --git a/arch/arm/boards/globalscale-mirabox/config.h b/arch/arm/boards/globalscale-mirabox/config.h
new file mode 100644
index 0000000..ca15136
--- /dev/null
+++ b/arch/arm/boards/globalscale-mirabox/config.h
@@ -0,0 +1,4 @@
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#endif /* __CONFIG_H */
diff --git a/arch/arm/boards/globalscale-mirabox/globalscale-mirabox.c b/arch/arm/boards/globalscale-mirabox/globalscale-mirabox.c
new file mode 100644
index 0000000..b8f4bff
--- /dev/null
+++ b/arch/arm/boards/globalscale-mirabox/globalscale-mirabox.c
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2013 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <init.h>
+#include <sizes.h>
+#include <mach/mvebu.h>
+
+static int globalscale_mirabox_console_init(void)
+{
+ return mvebu_add_uart0();
+}
+
+console_initcall(globalscale_mirabox_console_init);
diff --git a/arch/arm/boards/globalscale-mirabox/kwbimage.cfg b/arch/arm/boards/globalscale-mirabox/kwbimage.cfg
new file mode 100644
index 0000000..c83bf92
--- /dev/null
+++ b/arch/arm/boards/globalscale-mirabox/kwbimage.cfg
@@ -0,0 +1,8 @@
+VERSION 1
+BOOT_FROM uart
+DESTADDR 2000000
+EXECADDR 2000000
+NAND_BLKSZ 00020000
+NAND_BADBLK_LOCATION 01
+BINARY binary.0 0000005b 00000068
+PAYLOAD barebox.bin
diff --git a/arch/arm/boards/globalscale-mirabox/lowlevel.c b/arch/arm/boards/globalscale-mirabox/lowlevel.c
new file mode 100644
index 0000000..3ca202e
--- /dev/null
+++ b/arch/arm/boards/globalscale-mirabox/lowlevel.c
@@ -0,0 +1,26 @@
+/*
+ * Copyright (C) 2013 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <sizes.h>
+#include <asm/barebox-arm.h>
+#include <asm/barebox-arm-head.h>
+#include <mach/mvebu.h>
+
+void __naked barebox_arm_reset_vector(void)
+{
+ arm_cpu_lowlevel_init();
+ mvebu_barebox_entry();
+}
diff --git a/arch/arm/configs/globalscale_mirabox_defconfig b/arch/arm/configs/globalscale_mirabox_defconfig
new file mode 100644
index 0000000..ed9d94d
--- /dev/null
+++ b/arch/arm/configs/globalscale_mirabox_defconfig
@@ -0,0 +1,8 @@
+CONFIG_ARCH_MVEBU=y
+CONFIG_AEABI=y
+CONFIG_DEBUG_LL=y
+CONFIG_CMD_LOADY=y
+CONFIG_CMD_LOADS=y
+CONFIG_CMD_RESET=y
+CONFIG_CMD_CLK=y
+CONFIG_DRIVER_SERIAL_NS16550=y
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 9196251..8489335 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -3,9 +3,11 @@ if ARCH_MVEBU
config ARCH_TEXT_BASE
hex
default 0x2000000 if MACH_PLATHOME_OPENBLOCKS_AX3
+ default 0x2000000 if MACH_GLOBALSCALE_MIRABOX
config BOARDINFO
default "PlatHome OpenBlocks AX3" if MACH_PLATHOME_OPENBLOCKS_AX3
+ default "Globalscale Mirabox" if MACH_GLOBALSCALE_MIRABOX
choice
prompt "Marvell EBU Processor"
@@ -25,6 +27,9 @@ if ARCH_ARMADA_370
choice
prompt "Armada 370 Board Type"
+config MACH_GLOBALSCALE_MIRABOX
+ bool "Globalscale Mirabox"
+
endchoice
endif # ARCH_ARMADA_370
--
1.7.9.5
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread* [PATCH 7/7] arm: add basic support for the Armada XP GP platform
2013-05-03 16:51 [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Thomas Petazzoni
` (5 preceding siblings ...)
2013-05-03 16:51 ` [PATCH 6/7] arm: add basic support for the Armada 370 Mirabox platform Thomas Petazzoni
@ 2013-05-03 16:51 ` Thomas Petazzoni
2013-05-04 17:15 ` [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Jason Cooper
` (2 subsequent siblings)
9 siblings, 0 replies; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-03 16:51 UTC (permalink / raw)
To: barebox; +Cc: Lior Amsalem, Willy Tarreau, Ezequiel Garcia
The Armada XP GP platform is an evaluation platform designed by
Marvell, that uses the MV78460 quad-core SoC from the Armada XP
family.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
arch/arm/Makefile | 1 +
arch/arm/boards/marvell-armada-xp-gp/Makefile | 2 ++
arch/arm/boards/marvell-armada-xp-gp/config.h | 4 ++++
arch/arm/boards/marvell-armada-xp-gp/kwbimage.cfg | 8 +++++++
arch/arm/boards/marvell-armada-xp-gp/lowlevel.c | 25 ++++++++++++++++++++
.../marvell-armada-xp-gp/marvell-armada-xp-gp.c | 25 ++++++++++++++++++++
arch/arm/configs/marvell_armada_xp_gp_defconfig | 10 ++++++++
arch/arm/mach-mvebu/Kconfig | 5 ++++
8 files changed, 80 insertions(+)
create mode 100644 arch/arm/boards/marvell-armada-xp-gp/Makefile
create mode 100644 arch/arm/boards/marvell-armada-xp-gp/config.h
create mode 100644 arch/arm/boards/marvell-armada-xp-gp/kwbimage.cfg
create mode 100644 arch/arm/boards/marvell-armada-xp-gp/lowlevel.c
create mode 100644 arch/arm/boards/marvell-armada-xp-gp/marvell-armada-xp-gp.c
create mode 100644 arch/arm/configs/marvell_armada_xp_gp_defconfig
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index e6604b4..5ac1765 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -106,6 +106,7 @@ board-$(CONFIG_MACH_HIGHBANK) := highbank
board-$(CONFIG_MACH_IMX21ADS) := imx21ads
board-$(CONFIG_MACH_IMX27ADS) := imx27ads
board-$(CONFIG_MACH_IMX233_OLINUXINO) := imx233-olinuxino
+board-$(CONFIG_MACH_MARVELL_ARMADA_XP_GP) := marvell-armada-xp-gp
board-$(CONFIG_MACH_MIOA701) := mioa701
board-$(CONFIG_MACH_MMCCPU) := mmccpu
board-$(CONFIG_MACH_NOMADIK_8815NHK) := nhk8815
diff --git a/arch/arm/boards/marvell-armada-xp-gp/Makefile b/arch/arm/boards/marvell-armada-xp-gp/Makefile
new file mode 100644
index 0000000..ea89963
--- /dev/null
+++ b/arch/arm/boards/marvell-armada-xp-gp/Makefile
@@ -0,0 +1,2 @@
+obj-y = marvell-armada-xp-gp.o
+lwl-y += lowlevel.o
diff --git a/arch/arm/boards/marvell-armada-xp-gp/config.h b/arch/arm/boards/marvell-armada-xp-gp/config.h
new file mode 100644
index 0000000..ca15136
--- /dev/null
+++ b/arch/arm/boards/marvell-armada-xp-gp/config.h
@@ -0,0 +1,4 @@
+#ifndef __CONFIG_H
+#define __CONFIG_H
+
+#endif /* __CONFIG_H */
diff --git a/arch/arm/boards/marvell-armada-xp-gp/kwbimage.cfg b/arch/arm/boards/marvell-armada-xp-gp/kwbimage.cfg
new file mode 100644
index 0000000..9562633
--- /dev/null
+++ b/arch/arm/boards/marvell-armada-xp-gp/kwbimage.cfg
@@ -0,0 +1,8 @@
+VERSION 1
+BOOT_FROM uart
+DESTADDR 00000000
+EXECADDR 00000000
+NAND_BLKSZ 00000000
+NAND_BADBLK_LOCATION 00
+BINARY binary.0 0000005b 00000068
+PAYLOAD barebox.bin
diff --git a/arch/arm/boards/marvell-armada-xp-gp/lowlevel.c b/arch/arm/boards/marvell-armada-xp-gp/lowlevel.c
new file mode 100644
index 0000000..e9b2e30
--- /dev/null
+++ b/arch/arm/boards/marvell-armada-xp-gp/lowlevel.c
@@ -0,0 +1,25 @@
+/*
+ * Copyright (C) 2013 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <mach/mvebu.h>
+#include <asm/barebox-arm.h>
+#include <asm/barebox-arm-head.h>
+
+void __naked barebox_arm_reset_vector(void)
+{
+ arm_cpu_lowlevel_init();
+ mvebu_barebox_entry();
+}
diff --git a/arch/arm/boards/marvell-armada-xp-gp/marvell-armada-xp-gp.c b/arch/arm/boards/marvell-armada-xp-gp/marvell-armada-xp-gp.c
new file mode 100644
index 0000000..7351329
--- /dev/null
+++ b/arch/arm/boards/marvell-armada-xp-gp/marvell-armada-xp-gp.c
@@ -0,0 +1,25 @@
+/*
+ * Copyright (C) 2013 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <init.h>
+#include <mach/mvebu.h>
+
+static int marvell_armada_xp_gp_console_init(void)
+{
+ return mvebu_add_uart0();
+}
+
+console_initcall(marvell_armada_xp_gp_console_init);
diff --git a/arch/arm/configs/marvell_armada_xp_gp_defconfig b/arch/arm/configs/marvell_armada_xp_gp_defconfig
new file mode 100644
index 0000000..5a7ef52
--- /dev/null
+++ b/arch/arm/configs/marvell_armada_xp_gp_defconfig
@@ -0,0 +1,10 @@
+CONFIG_ARCH_MVEBU=y
+CONFIG_ARCH_ARMADA_XP=y
+CONFIG_MACH_MARVELL_ARMADA_XP_GP=y
+CONFIG_AEABI=y
+CONFIG_DEBUG_LL=y
+CONFIG_CMD_LOADY=y
+CONFIG_CMD_LOADS=y
+CONFIG_CMD_RESET=y
+CONFIG_CMD_CLK=y
+CONFIG_DRIVER_SERIAL_NS16550=y
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 8489335..e553e2d 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -4,10 +4,12 @@ config ARCH_TEXT_BASE
hex
default 0x2000000 if MACH_PLATHOME_OPENBLOCKS_AX3
default 0x2000000 if MACH_GLOBALSCALE_MIRABOX
+ default 0x2000000 if MACH_MARVELL_ARMADA_XP_GP
config BOARDINFO
default "PlatHome OpenBlocks AX3" if MACH_PLATHOME_OPENBLOCKS_AX3
default "Globalscale Mirabox" if MACH_GLOBALSCALE_MIRABOX
+ default "Marvell Armada XP GP" if MACH_MARVELL_ARMADA_XP_GP
choice
prompt "Marvell EBU Processor"
@@ -42,6 +44,9 @@ choice
config MACH_PLATHOME_OPENBLOCKS_AX3
bool "PlatHome OpenBlocks AX3"
+config MACH_MARVELL_ARMADA_XP_GP
+ bool "Marvell Armada XP GP"
+
endchoice
endif # ARCH_ARMADA_XP
--
1.7.9.5
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC
2013-05-03 16:51 [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Thomas Petazzoni
` (6 preceding siblings ...)
2013-05-03 16:51 ` [PATCH 7/7] arm: add basic support for the Armada XP GP platform Thomas Petazzoni
@ 2013-05-04 17:15 ` Jason Cooper
2013-05-04 17:23 ` Re[2]: " Alexander Shiyan
2013-05-04 17:52 ` Thomas Petazzoni
2013-05-06 19:28 ` Sascha Hauer
2013-05-07 23:28 ` Gregory CLEMENT
9 siblings, 2 replies; 63+ messages in thread
From: Jason Cooper @ 2013-05-04 17:15 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
Thomas,
Great work! Very clean series. I only have one thought. Prafulla
(u-boot kirkwood maintainer) is always asking about consolidating the
kwbimage.cfg files. The three you've submitted for the first three
boards are almost (if not entirely) identical. Before a whole bunch of
boards get added, should we make a kwbimage-common.cfg or similar?
I'm not sold on the idea, I'm just mentioning it since it's been an
issue in the past. If we want to do that, now would be the time.
thx,
Jason.
On Fri, May 03, 2013 at 06:51:04PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> Here is a patch set that adds basic support for the Marvell Armada 370
> and Armada XP SoC. For now, the support is quite minimal, since only
> the serial port is supported. However, a significant part of the work
> has been the development of the tools that allow to extract/create
> bootable images and to push a bootable image through the UART to the
> hardware platform.
>
> I expect to work on adding support for more devices (such as the
> network interface) and possibly to add support for the older, but
> popular, Marvell Kirkwood SoC family. Contributions are of course
> welcome.
>
> In detail, the patch set contains:
>
> * A kwbimage tool. This tool allows to extract existing bootloader
> images, and create new bootloader images. It is more or less
> similar in purpose to the kwbimage tool from U-Boot, but is capable
> of handling 'version 1' images used by Armada 370/XP, and not only
> allows to create images, but also extract images.
>
> A typical usage is to first extract an existing bootloader image:
>
> ./scripts/kwbimage -x -i <existing-image> -o <some-directory>
>
> As an output, you typically get 3 files: kwbimage.cfg (a text file
> that describes the configuration of the image in a format
> ressembling the one used by U-Boot), binary.0 (the binary blob that
> does the DDR3 training) and payload (the bootloader itself).
>
> Being able to extract an image is needed in order to get the DDR3
> training code, and re-use it with Barebox.
>
> An image is then later created with:
>
> ./scripts/kwbimage -x -i <path/to/kwbimage.cfg> -o <image>
>
> For each board, the kwbimage.cfg file is typically located in
> arch/arm/boards/<board-name>/. The DDR3 training code must however
> be extracted from an existing bootloader image of your board,
> usually the one provided by the board manufacturer.
>
> * A kwboot tool to push a bootloader through UART. It is directly
> taken from U-Boot source code, to which I've added some fixes:
>
> - Extend the timeouts, to actually make it work on Armada
> 370/XP. This has originally been found by Willy Tarreau.
>
> - Ignore non-Xmodem characters, so that the original DDR3 training
> code can be used without modifications (Willy had to change it to
> make it output its messages on a different serial port, otherwise
> it was confusing the Xmodem implementation)
>
> - Output to stdout all the non-Xmodem characters so that if
> something goes wrong during the transfer, we have some
> informations. It also shows the messages output by the DDR3
> training code.
>
> - Remove the 'patch' feature that patches an image to have the UART
> type. This requires a knowledge of the header format, which is
> different between version 0 (kirkwood) and version 1 (armada
> 370/xp). It is not really needed anyway since kwbimage can
> extract and create images.
>
> * The SoC-level code, which for now only consists in a minimal
> clocksource driver, a function to register an UART, a fixed-rate
> clock, and a function that determines the amount of RAM by looking
> at the SDRAM windows registers.
>
> * The board-level code for the Armada 370 Mirabox from Globalscale,
> the Armada XP OpenBlocks AX3 from Plathome and the Armada XP GP
> from Marvell.
>
> Reviews and comments welcome!
>
> Best regards,
>
> Thomas
>
> Thomas Petazzoni (7):
> scripts: allow lines longer than 80 cols with printf() in checkpatch
> scripts: new kwbimage manipulation tool for Marvell SoC boot images
> scripts: add kwboot tool
> arm: initial support for Marvell Armada 370/XP SoCs
> arm: add basic support for Armada XP OpenBlocks AX3 platform
> arm: add basic support for the Armada 370 Mirabox platform
> arm: add basic support for the Armada XP GP platform
>
> arch/arm/Kconfig | 8 +
> arch/arm/Makefile | 4 +
> arch/arm/boards/globalscale-mirabox/Makefile | 2 +
> arch/arm/boards/globalscale-mirabox/config.h | 4 +
> .../globalscale-mirabox/globalscale-mirabox.c | 26 +
> arch/arm/boards/globalscale-mirabox/kwbimage.cfg | 8 +
> arch/arm/boards/globalscale-mirabox/lowlevel.c | 26 +
> arch/arm/boards/marvell-armada-xp-gp/Makefile | 2 +
> arch/arm/boards/marvell-armada-xp-gp/config.h | 4 +
> arch/arm/boards/marvell-armada-xp-gp/kwbimage.cfg | 8 +
> arch/arm/boards/marvell-armada-xp-gp/lowlevel.c | 25 +
> .../marvell-armada-xp-gp/marvell-armada-xp-gp.c | 25 +
> arch/arm/boards/plathome-openblocks-ax3/Makefile | 2 +
> arch/arm/boards/plathome-openblocks-ax3/config.h | 4 +
> .../boards/plathome-openblocks-ax3/kwbimage.cfg | 8 +
> arch/arm/boards/plathome-openblocks-ax3/lowlevel.c | 25 +
> .../plathome-openblocks-ax3.c | 25 +
> arch/arm/configs/globalscale_mirabox_defconfig | 8 +
> arch/arm/configs/marvell_armada_xp_gp_defconfig | 10 +
> arch/arm/configs/plathome_openblocks_ax3_defconfig | 9 +
> arch/arm/mach-mvebu/Kconfig | 54 +
> arch/arm/mach-mvebu/Makefile | 1 +
> arch/arm/mach-mvebu/core.c | 142 +++
> arch/arm/mach-mvebu/include/mach/clkdev.h | 7 +
> arch/arm/mach-mvebu/include/mach/debug_ll.h | 40 +
> arch/arm/mach-mvebu/include/mach/mvebu.h | 22 +
> drivers/clocksource/Kconfig | 4 +
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/mvebu.c | 90 ++
> scripts/.gitignore | 2 +
> scripts/Makefile | 3 +-
> scripts/checkpatch.pl | 2 +-
> scripts/kwbimage.c | 1224 ++++++++++++++++++++
> scripts/kwboot.c | 717 ++++++++++++
> 34 files changed, 2540 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/boards/globalscale-mirabox/Makefile
> create mode 100644 arch/arm/boards/globalscale-mirabox/config.h
> create mode 100644 arch/arm/boards/globalscale-mirabox/globalscale-mirabox.c
> create mode 100644 arch/arm/boards/globalscale-mirabox/kwbimage.cfg
> create mode 100644 arch/arm/boards/globalscale-mirabox/lowlevel.c
> create mode 100644 arch/arm/boards/marvell-armada-xp-gp/Makefile
> create mode 100644 arch/arm/boards/marvell-armada-xp-gp/config.h
> create mode 100644 arch/arm/boards/marvell-armada-xp-gp/kwbimage.cfg
> create mode 100644 arch/arm/boards/marvell-armada-xp-gp/lowlevel.c
> create mode 100644 arch/arm/boards/marvell-armada-xp-gp/marvell-armada-xp-gp.c
> create mode 100644 arch/arm/boards/plathome-openblocks-ax3/Makefile
> create mode 100644 arch/arm/boards/plathome-openblocks-ax3/config.h
> create mode 100644 arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
> create mode 100644 arch/arm/boards/plathome-openblocks-ax3/lowlevel.c
> create mode 100644 arch/arm/boards/plathome-openblocks-ax3/plathome-openblocks-ax3.c
> create mode 100644 arch/arm/configs/globalscale_mirabox_defconfig
> create mode 100644 arch/arm/configs/marvell_armada_xp_gp_defconfig
> create mode 100644 arch/arm/configs/plathome_openblocks_ax3_defconfig
> create mode 100644 arch/arm/mach-mvebu/Kconfig
> create mode 100644 arch/arm/mach-mvebu/Makefile
> create mode 100644 arch/arm/mach-mvebu/core.c
> create mode 100644 arch/arm/mach-mvebu/include/mach/clkdev.h
> create mode 100644 arch/arm/mach-mvebu/include/mach/debug_ll.h
> create mode 100644 arch/arm/mach-mvebu/include/mach/mvebu.h
> create mode 100644 drivers/clocksource/mvebu.c
> create mode 100644 scripts/kwbimage.c
> create mode 100644 scripts/kwboot.c
>
> --
> 1.7.9.5
>
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread* Re[2]: [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC
2013-05-04 17:15 ` [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Jason Cooper
@ 2013-05-04 17:23 ` Alexander Shiyan
2013-05-04 17:49 ` Thomas Petazzoni
2013-05-04 17:52 ` Thomas Petazzoni
1 sibling, 1 reply; 63+ messages in thread
From: Alexander Shiyan @ 2013-05-04 17:23 UTC (permalink / raw)
To: Jason Cooper; +Cc: Lior Amsalem, Willy Tarreau, Ezequiel Garcia, barebox
> Great work! Very clean series. I only have one thought. Prafulla
> (u-boot kirkwood maintainer) is always asking about consolidating the
> kwbimage.cfg files. The three you've submitted for the first three
> boards are almost (if not entirely) identical. Before a whole bunch of
> boards get added, should we make a kwbimage-common.cfg or similar?
>
> I'm not sold on the idea, I'm just mentioning it since it's been an
> issue in the past. If we want to do that, now would be the time.
I did not look carefully these patches but seems to me that to have
any configuration files outside /env is not good for barebox.
---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC
2013-05-04 17:23 ` Re[2]: " Alexander Shiyan
@ 2013-05-04 17:49 ` Thomas Petazzoni
2013-05-04 17:52 ` Re[2]: " Alexander Shiyan
0 siblings, 1 reply; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-04 17:49 UTC (permalink / raw)
To: Alexander Shiyan
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
Dear Alexander Shiyan,
On Sat, 04 May 2013 21:23:49 +0400, Alexander Shiyan wrote:
> I did not look carefully these patches but seems to me that to have
> any configuration files outside /env is not good for barebox.
They are not configuration files used at runtime. They are
configuration files used by the image construction utility to know how
to create a bootable image for the target system. This image
construction utility runs on the build machine, and is the new
scripts/kwbimage tool introduced in this patch series.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re[2]: [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC
2013-05-04 17:49 ` Thomas Petazzoni
@ 2013-05-04 17:52 ` Alexander Shiyan
0 siblings, 0 replies; 63+ messages in thread
From: Alexander Shiyan @ 2013-05-04 17:52 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
> On Sat, 04 May 2013 21:23:49 +0400, Alexander Shiyan wrote:
>
> > I did not look carefully these patches but seems to me that to have
> > any configuration files outside /env is not good for barebox.
>
> They are not configuration files used at runtime. They are
> configuration files used by the image construction utility to know how
> to create a bootable image for the target system. This image
> construction utility runs on the build machine, and is the new
> scripts/kwbimage tool introduced in this patch series.
Then it makes sense.
Do not understand the meaning of the initial post. Sorry.
---
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC
2013-05-04 17:15 ` [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Jason Cooper
2013-05-04 17:23 ` Re[2]: " Alexander Shiyan
@ 2013-05-04 17:52 ` Thomas Petazzoni
2013-05-04 18:34 ` Jason Cooper
2013-05-05 6:33 ` Sascha Hauer
1 sibling, 2 replies; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-04 17:52 UTC (permalink / raw)
To: Jason Cooper; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
Dear Jason Cooper,
On Sat, 4 May 2013 13:15:30 -0400, Jason Cooper wrote:
> Great work! Very clean series. I only have one thought. Prafulla
> (u-boot kirkwood maintainer) is always asking about consolidating the
> kwbimage.cfg files. The three you've submitted for the first three
> boards are almost (if not entirely) identical. Before a whole bunch of
> boards get added, should we make a kwbimage-common.cfg or similar?
I'm not sure I want to make the configuration language more complicated
than it is already. It's already a pain to parse such a configuration
file in C (I would have preferred to write the kwbimage tool in Python,
but since all existing Barebox tools are in C, I wasn't sure a Python
tool would have been accepted). Adding the support for includes means
that you have to recursively handle includes, etc. I'm not sure I want
to go down this road for files that typically have between 10 to 30
lines.
> I'm not sold on the idea, I'm just mentioning it since it's been an
> issue in the past. If we want to do that, now would be the time.
I don't agree: we can refactor those files at any point in time. For
now, I don't think it's very useful, but in the future, if it turns out
to be useful and someone feels that it is important to improve this, we
can always refactor the .cfg files.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC
2013-05-04 17:52 ` Thomas Petazzoni
@ 2013-05-04 18:34 ` Jason Cooper
2013-05-05 6:33 ` Sascha Hauer
1 sibling, 0 replies; 63+ messages in thread
From: Jason Cooper @ 2013-05-04 18:34 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
On Sat, May 04, 2013 at 07:52:28PM +0200, Thomas Petazzoni wrote:
> Dear Jason Cooper,
>
> On Sat, 4 May 2013 13:15:30 -0400, Jason Cooper wrote:
>
> > Great work! Very clean series. I only have one thought. Prafulla
> > (u-boot kirkwood maintainer) is always asking about consolidating the
> > kwbimage.cfg files. The three you've submitted for the first three
> > boards are almost (if not entirely) identical. Before a whole bunch of
> > boards get added, should we make a kwbimage-common.cfg or similar?
>
> I'm not sure I want to make the configuration language more complicated
> than it is already. It's already a pain to parse such a configuration
> file in C (I would have preferred to write the kwbimage tool in Python,
> but since all existing Barebox tools are in C, I wasn't sure a Python
> tool would have been accepted). Adding the support for includes means
> that you have to recursively handle includes, etc. I'm not sure I want
> to go down this road for files that typically have between 10 to 30
> lines.
Agreed.
> > I'm not sold on the idea, I'm just mentioning it since it's been an
> > issue in the past. If we want to do that, now would be the time.
>
> I don't agree: we can refactor those files at any point in time. For
> now, I don't think it's very useful, but in the future, if it turns out
> to be useful and someone feels that it is important to improve this, we
> can always refactor the .cfg files.
Ok, no problem. I just wanted to make sure it was considered before we
went all gung-ho adding boards.
thx,
Jason.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC
2013-05-04 17:52 ` Thomas Petazzoni
2013-05-04 18:34 ` Jason Cooper
@ 2013-05-05 6:33 ` Sascha Hauer
2013-05-06 13:54 ` Thomas Petazzoni
1 sibling, 1 reply; 63+ messages in thread
From: Sascha Hauer @ 2013-05-05 6:33 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
Hi Thomas,
On Sat, May 04, 2013 at 07:52:28PM +0200, Thomas Petazzoni wrote:
> Dear Jason Cooper,
>
> On Sat, 4 May 2013 13:15:30 -0400, Jason Cooper wrote:
>
> > Great work! Very clean series. I only have one thought. Prafulla
> > (u-boot kirkwood maintainer) is always asking about consolidating the
> > kwbimage.cfg files. The three you've submitted for the first three
> > boards are almost (if not entirely) identical. Before a whole bunch of
> > boards get added, should we make a kwbimage-common.cfg or similar?
>
> I'm not sure I want to make the configuration language more complicated
> than it is already. It's already a pain to parse such a configuration
> file in C (I would have preferred to write the kwbimage tool in Python,
> but since all existing Barebox tools are in C, I wasn't sure a Python
> tool would have been accepted). Adding the support for includes means
> that you have to recursively handle includes, etc. I'm not sure I want
> to go down this road for files that typically have between 10 to 30
> lines.
How about using the C preprocessor for includes if they become
necessary?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC
2013-05-05 6:33 ` Sascha Hauer
@ 2013-05-06 13:54 ` Thomas Petazzoni
0 siblings, 0 replies; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-06 13:54 UTC (permalink / raw)
To: Sascha Hauer
Cc: Lior Amsalem, barebox, Jason Cooper, Ezequiel Garcia, Willy Tarreau
Dear Sascha Hauer,
On Sun, 5 May 2013 08:33:18 +0200, Sascha Hauer wrote:
> > > Great work! Very clean series. I only have one thought. Prafulla
> > > (u-boot kirkwood maintainer) is always asking about consolidating the
> > > kwbimage.cfg files. The three you've submitted for the first three
> > > boards are almost (if not entirely) identical. Before a whole bunch of
> > > boards get added, should we make a kwbimage-common.cfg or similar?
> >
> > I'm not sure I want to make the configuration language more complicated
> > than it is already. It's already a pain to parse such a configuration
> > file in C (I would have preferred to write the kwbimage tool in Python,
> > but since all existing Barebox tools are in C, I wasn't sure a Python
> > tool would have been accepted). Adding the support for includes means
> > that you have to recursively handle includes, etc. I'm not sure I want
> > to go down this road for files that typically have between 10 to 30
> > lines.
>
> How about using the C preprocessor for includes if they become
> necessary?
Yes, that could be one option, and certainly more reasonable than
including the include mechanism into the configuration language itself.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC
2013-05-03 16:51 [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Thomas Petazzoni
` (7 preceding siblings ...)
2013-05-04 17:15 ` [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Jason Cooper
@ 2013-05-06 19:28 ` Sascha Hauer
2013-05-06 20:32 ` Thomas Petazzoni
2013-05-07 23:28 ` Gregory CLEMENT
9 siblings, 1 reply; 63+ messages in thread
From: Sascha Hauer @ 2013-05-06 19:28 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
On Fri, May 03, 2013 at 06:51:04PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> Here is a patch set that adds basic support for the Marvell Armada 370
> and Armada XP SoC. For now, the support is quite minimal, since only
> the serial port is supported. However, a significant part of the work
> has been the development of the tools that allow to extract/create
> bootable images and to push a bootable image through the UART to the
> hardware platform.
>
> I expect to work on adding support for more devices (such as the
> network interface) and possibly to add support for the older, but
> popular, Marvell Kirkwood SoC family. Contributions are of course
> welcome.
>
> In detail, the patch set contains:
>
> * A kwbimage tool. This tool allows to extract existing bootloader
> images, and create new bootloader images. It is more or less
> similar in purpose to the kwbimage tool from U-Boot, but is capable
> of handling 'version 1' images used by Armada 370/XP, and not only
> allows to create images, but also extract images.
>
> A typical usage is to first extract an existing bootloader image:
>
> ./scripts/kwbimage -x -i <existing-image> -o <some-directory>
>
> As an output, you typically get 3 files: kwbimage.cfg (a text file
> that describes the configuration of the image in a format
> ressembling the one used by U-Boot), binary.0 (the binary blob that
> does the DDR3 training) and payload (the bootloader itself).
So now I have the DDR3 training blob and the payload. I would then
replace the payload with barebox and call kwbimage again to generate
a new image, right?
Just to understand what the problem here is: Am I right that we do not
have the source code for the DDR3 training code and that the code is not
GPL so that we can't distribute it with barebox?
Independently of this I repeat that adding a tool for the job of
generating images is the right way to go, at least when the images are
of a certain complexity which is the case here.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC
2013-05-06 19:28 ` Sascha Hauer
@ 2013-05-06 20:32 ` Thomas Petazzoni
0 siblings, 0 replies; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-06 20:32 UTC (permalink / raw)
To: Sascha Hauer; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
Dear Sascha Hauer,
On Mon, 6 May 2013 21:28:26 +0200, Sascha Hauer wrote:
> So now I have the DDR3 training blob and the payload. I would then
> replace the payload with barebox and call kwbimage again to generate
> a new image, right?
Exact, that's what I'm doing for the moment: retrieve a u-boot.bin that
is provided by the board vendor, or dump it somehow from the NAND or
SPI flash of the board. In fact, this u-boot.bin is not just U-Boot,
but it contains the header + the DDR3 training code. Once I have this
image, I use the 'kwbimage -x' option to separate the configuration,
the DDR3 binary blob and the payload. I just trash the payload, and
using the configuration, the DDR3 binary blob, barebox.bin and
'kwbimage -c', I create a new bootable image.
I am interested in writing documentation that explains how to do this,
because this is not trivial, and I want Barebox users to be able to do
this on their own. But I haven't really figured out where is the good
place to document that: the Doxygen documentation has some
board-specific documentation, but this problem is mostly SoC-family
related. Just let me know where I can insert a documentation blurb
about this, and I'll do it.
> Just to understand what the problem here is: Am I right that we do not
> have the source code for the DDR3 training code and that the code is not
> GPL so that we can't distribute it with barebox?
No, I don't have the source code for the DDR3 training code. Or more
precisely, I have access to a very small part of it, but the largest
part of it is just a binary .a library for which I don't have access to
the source code, and even if I had, I doubt it would be licensed under
the GPL.
So, for now, this code is not available, and in any case not under a
license that allows it to be distributed with Barebox. Long term, I'd
like this to be possible, but it will require quite some work.
In the mean time, I think the reason Marvell invented this "binary
header" thing is precisely to avoid linking the DDR3 training code with
the bootloader, so that the DDR3 training code can remain proprietary,
while allowing users to use an GPL-licensed bootloader. I believe that
what kwbimage does is just a mere aggregation of components, and not
linking, and distributing the mere aggregation of a proprietary binary
and GPL-licensed binary is allowed by the GPL license. Of course, IANAL.
> Independently of this I repeat that adding a tool for the job of
> generating images is the right way to go, at least when the images are
> of a certain complexity which is the case here.
Good to hear this confirmation, thanks.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC
2013-05-03 16:51 [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC Thomas Petazzoni
` (8 preceding siblings ...)
2013-05-06 19:28 ` Sascha Hauer
@ 2013-05-07 23:28 ` Gregory CLEMENT
2013-05-07 23:46 ` Gregory CLEMENT
2013-05-08 10:46 ` Thomas Petazzoni
9 siblings, 2 replies; 63+ messages in thread
From: Gregory CLEMENT @ 2013-05-07 23:28 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
On 05/03/2013 06:51 PM, Thomas Petazzoni wrote:
> Hello,
Hi Thomas,
it was a great work, I am currently trying to use but unfortunately,
I didn't managed to run barebox on the Armada XP OpenBlocks AX3 from
Plathome :/
I get something like that:
kwboot -t -b barebix.bin.kw -B 115200 /dev/ttyUSB0
Sending boot message. Please reboot the target...-
[here I power up the AX3]
Sending boot image...
0 % [......................................................................]
4 % [......................................................................]
9 % [......................................................................]
14 % [......................................................................]
18 % [......................................................................]
23 % [......................................................................]
28 % [......................................................................]
33 % [......................................................................]
37 % [......................................................................]
42 % [......................................................................]
47 % [......................................................................]
52 % [.............................................................BootROM: Invalid header ID
Booting from NOR flash
DDR3 Training Sequence - Ver 3.0.0
I also found typo in the command line example you gave to use kwbimage.
I will try the other platform soon.
[...]
>
> An image is then later created with:
>
> ./scripts/kwbimage -x -i <path/to/kwbimage.cfg> -o <image>
I think it should be:
./scripts/kwbimage -c -i <path/to/kwbimage.cfg> -o <image>
Thanks!
>
> For each board, the kwbimage.cfg file is typically located in
> arch/arm/boards/<board-name>/. The DDR3 training code must however
> be extracted from an existing bootloader image of your board,
> usually the one provided by the board manufacturer.
>
> * A kwboot tool to push a bootloader through UART. It is directly
> taken from U-Boot source code, to which I've added some fixes:
>
> - Extend the timeouts, to actually make it work on Armada
> 370/XP. This has originally been found by Willy Tarreau.
>
> - Ignore non-Xmodem characters, so that the original DDR3 training
> code can be used without modifications (Willy had to change it to
> make it output its messages on a different serial port, otherwise
> it was confusing the Xmodem implementation)
>
> - Output to stdout all the non-Xmodem characters so that if
> something goes wrong during the transfer, we have some
> informations. It also shows the messages output by the DDR3
> training code.
>
> - Remove the 'patch' feature that patches an image to have the UART
> type. This requires a knowledge of the header format, which is
> different between version 0 (kirkwood) and version 1 (armada
> 370/xp). It is not really needed anyway since kwbimage can
> extract and create images.
>
> * The SoC-level code, which for now only consists in a minimal
> clocksource driver, a function to register an UART, a fixed-rate
> clock, and a function that determines the amount of RAM by looking
> at the SDRAM windows registers.
>
> * The board-level code for the Armada 370 Mirabox from Globalscale,
> the Armada XP OpenBlocks AX3 from Plathome and the Armada XP GP
> from Marvell.
>
> Reviews and comments welcome!
>
> Best regards,
>
> Thomas
>
> Thomas Petazzoni (7):
> scripts: allow lines longer than 80 cols with printf() in checkpatch
> scripts: new kwbimage manipulation tool for Marvell SoC boot images
> scripts: add kwboot tool
> arm: initial support for Marvell Armada 370/XP SoCs
> arm: add basic support for Armada XP OpenBlocks AX3 platform
> arm: add basic support for the Armada 370 Mirabox platform
> arm: add basic support for the Armada XP GP platform
>
> arch/arm/Kconfig | 8 +
> arch/arm/Makefile | 4 +
> arch/arm/boards/globalscale-mirabox/Makefile | 2 +
> arch/arm/boards/globalscale-mirabox/config.h | 4 +
> .../globalscale-mirabox/globalscale-mirabox.c | 26 +
> arch/arm/boards/globalscale-mirabox/kwbimage.cfg | 8 +
> arch/arm/boards/globalscale-mirabox/lowlevel.c | 26 +
> arch/arm/boards/marvell-armada-xp-gp/Makefile | 2 +
> arch/arm/boards/marvell-armada-xp-gp/config.h | 4 +
> arch/arm/boards/marvell-armada-xp-gp/kwbimage.cfg | 8 +
> arch/arm/boards/marvell-armada-xp-gp/lowlevel.c | 25 +
> .../marvell-armada-xp-gp/marvell-armada-xp-gp.c | 25 +
> arch/arm/boards/plathome-openblocks-ax3/Makefile | 2 +
> arch/arm/boards/plathome-openblocks-ax3/config.h | 4 +
> .../boards/plathome-openblocks-ax3/kwbimage.cfg | 8 +
> arch/arm/boards/plathome-openblocks-ax3/lowlevel.c | 25 +
> .../plathome-openblocks-ax3.c | 25 +
> arch/arm/configs/globalscale_mirabox_defconfig | 8 +
> arch/arm/configs/marvell_armada_xp_gp_defconfig | 10 +
> arch/arm/configs/plathome_openblocks_ax3_defconfig | 9 +
> arch/arm/mach-mvebu/Kconfig | 54 +
> arch/arm/mach-mvebu/Makefile | 1 +
> arch/arm/mach-mvebu/core.c | 142 +++
> arch/arm/mach-mvebu/include/mach/clkdev.h | 7 +
> arch/arm/mach-mvebu/include/mach/debug_ll.h | 40 +
> arch/arm/mach-mvebu/include/mach/mvebu.h | 22 +
> drivers/clocksource/Kconfig | 4 +
> drivers/clocksource/Makefile | 1 +
> drivers/clocksource/mvebu.c | 90 ++
> scripts/.gitignore | 2 +
> scripts/Makefile | 3 +-
> scripts/checkpatch.pl | 2 +-
> scripts/kwbimage.c | 1224 ++++++++++++++++++++
> scripts/kwboot.c | 717 ++++++++++++
> 34 files changed, 2540 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/boards/globalscale-mirabox/Makefile
> create mode 100644 arch/arm/boards/globalscale-mirabox/config.h
> create mode 100644 arch/arm/boards/globalscale-mirabox/globalscale-mirabox.c
> create mode 100644 arch/arm/boards/globalscale-mirabox/kwbimage.cfg
> create mode 100644 arch/arm/boards/globalscale-mirabox/lowlevel.c
> create mode 100644 arch/arm/boards/marvell-armada-xp-gp/Makefile
> create mode 100644 arch/arm/boards/marvell-armada-xp-gp/config.h
> create mode 100644 arch/arm/boards/marvell-armada-xp-gp/kwbimage.cfg
> create mode 100644 arch/arm/boards/marvell-armada-xp-gp/lowlevel.c
> create mode 100644 arch/arm/boards/marvell-armada-xp-gp/marvell-armada-xp-gp.c
> create mode 100644 arch/arm/boards/plathome-openblocks-ax3/Makefile
> create mode 100644 arch/arm/boards/plathome-openblocks-ax3/config.h
> create mode 100644 arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
> create mode 100644 arch/arm/boards/plathome-openblocks-ax3/lowlevel.c
> create mode 100644 arch/arm/boards/plathome-openblocks-ax3/plathome-openblocks-ax3.c
> create mode 100644 arch/arm/configs/globalscale_mirabox_defconfig
> create mode 100644 arch/arm/configs/marvell_armada_xp_gp_defconfig
> create mode 100644 arch/arm/configs/plathome_openblocks_ax3_defconfig
> create mode 100644 arch/arm/mach-mvebu/Kconfig
> create mode 100644 arch/arm/mach-mvebu/Makefile
> create mode 100644 arch/arm/mach-mvebu/core.c
> create mode 100644 arch/arm/mach-mvebu/include/mach/clkdev.h
> create mode 100644 arch/arm/mach-mvebu/include/mach/debug_ll.h
> create mode 100644 arch/arm/mach-mvebu/include/mach/mvebu.h
> create mode 100644 drivers/clocksource/mvebu.c
> create mode 100644 scripts/kwbimage.c
> create mode 100644 scripts/kwboot.c
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread* Re: [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC
2013-05-07 23:28 ` Gregory CLEMENT
@ 2013-05-07 23:46 ` Gregory CLEMENT
2013-05-08 10:46 ` Thomas Petazzoni
1 sibling, 0 replies; 63+ messages in thread
From: Gregory CLEMENT @ 2013-05-07 23:46 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
On 05/08/2013 01:28 AM, Gregory CLEMENT wrote:
> On 05/03/2013 06:51 PM, Thomas Petazzoni wrote:
>> Hello,
> Hi Thomas,
>
> it was a great work, I am currently trying to use but unfortunately,
> I didn't managed to run barebox on the Armada XP OpenBlocks AX3 from
> Plathome :/
But I managed to run barebox on the Mirabox!
>
> I get something like that:
>
> kwboot -t -b barebix.bin.kw -B 115200 /dev/ttyUSB0
> Sending boot message. Please reboot the target...-
>
> [here I power up the AX3]
>
> Sending boot image...
> 0 % [......................................................................]
> 4 % [......................................................................]
> 9 % [......................................................................]
> 14 % [......................................................................]
> 18 % [......................................................................]
> 23 % [......................................................................]
> 28 % [......................................................................]
> 33 % [......................................................................]
> 37 % [......................................................................]
> 42 % [......................................................................]
> 47 % [......................................................................]
> 52 % [.............................................................BootROM: Invalid header ID
> Booting from NOR flash
> DDR3 Training Sequence - Ver 3.0.0
>
> I also found typo in the command line example you gave to use kwbimage.
>
> I will try the other platform soon.
>
> [...]
>>
>> An image is then later created with:
>>
>> ./scripts/kwbimage -x -i <path/to/kwbimage.cfg> -o <image>
>
> I think it should be:
> ./scripts/kwbimage -c -i <path/to/kwbimage.cfg> -o <image>
>
> Thanks!
>>
>> For each board, the kwbimage.cfg file is typically located in
>> arch/arm/boards/<board-name>/. The DDR3 training code must however
>> be extracted from an existing bootloader image of your board,
>> usually the one provided by the board manufacturer.
>>
>> * A kwboot tool to push a bootloader through UART. It is directly
>> taken from U-Boot source code, to which I've added some fixes:
>>
>> - Extend the timeouts, to actually make it work on Armada
>> 370/XP. This has originally been found by Willy Tarreau.
>>
>> - Ignore non-Xmodem characters, so that the original DDR3 training
>> code can be used without modifications (Willy had to change it to
>> make it output its messages on a different serial port, otherwise
>> it was confusing the Xmodem implementation)
>>
>> - Output to stdout all the non-Xmodem characters so that if
>> something goes wrong during the transfer, we have some
>> informations. It also shows the messages output by the DDR3
>> training code.
>>
>> - Remove the 'patch' feature that patches an image to have the UART
>> type. This requires a knowledge of the header format, which is
>> different between version 0 (kirkwood) and version 1 (armada
>> 370/xp). It is not really needed anyway since kwbimage can
>> extract and create images.
>>
>> * The SoC-level code, which for now only consists in a minimal
>> clocksource driver, a function to register an UART, a fixed-rate
>> clock, and a function that determines the amount of RAM by looking
>> at the SDRAM windows registers.
>>
>> * The board-level code for the Armada 370 Mirabox from Globalscale,
>> the Armada XP OpenBlocks AX3 from Plathome and the Armada XP GP
>> from Marvell.
>>
>> Reviews and comments welcome!
>>
>> Best regards,
>>
>> Thomas
>>
>> Thomas Petazzoni (7):
>> scripts: allow lines longer than 80 cols with printf() in checkpatch
>> scripts: new kwbimage manipulation tool for Marvell SoC boot images
>> scripts: add kwboot tool
>> arm: initial support for Marvell Armada 370/XP SoCs
>> arm: add basic support for Armada XP OpenBlocks AX3 platform
>> arm: add basic support for the Armada 370 Mirabox platform
>> arm: add basic support for the Armada XP GP platform
>>
>> arch/arm/Kconfig | 8 +
>> arch/arm/Makefile | 4 +
>> arch/arm/boards/globalscale-mirabox/Makefile | 2 +
>> arch/arm/boards/globalscale-mirabox/config.h | 4 +
>> .../globalscale-mirabox/globalscale-mirabox.c | 26 +
>> arch/arm/boards/globalscale-mirabox/kwbimage.cfg | 8 +
>> arch/arm/boards/globalscale-mirabox/lowlevel.c | 26 +
>> arch/arm/boards/marvell-armada-xp-gp/Makefile | 2 +
>> arch/arm/boards/marvell-armada-xp-gp/config.h | 4 +
>> arch/arm/boards/marvell-armada-xp-gp/kwbimage.cfg | 8 +
>> arch/arm/boards/marvell-armada-xp-gp/lowlevel.c | 25 +
>> .../marvell-armada-xp-gp/marvell-armada-xp-gp.c | 25 +
>> arch/arm/boards/plathome-openblocks-ax3/Makefile | 2 +
>> arch/arm/boards/plathome-openblocks-ax3/config.h | 4 +
>> .../boards/plathome-openblocks-ax3/kwbimage.cfg | 8 +
>> arch/arm/boards/plathome-openblocks-ax3/lowlevel.c | 25 +
>> .../plathome-openblocks-ax3.c | 25 +
>> arch/arm/configs/globalscale_mirabox_defconfig | 8 +
>> arch/arm/configs/marvell_armada_xp_gp_defconfig | 10 +
>> arch/arm/configs/plathome_openblocks_ax3_defconfig | 9 +
>> arch/arm/mach-mvebu/Kconfig | 54 +
>> arch/arm/mach-mvebu/Makefile | 1 +
>> arch/arm/mach-mvebu/core.c | 142 +++
>> arch/arm/mach-mvebu/include/mach/clkdev.h | 7 +
>> arch/arm/mach-mvebu/include/mach/debug_ll.h | 40 +
>> arch/arm/mach-mvebu/include/mach/mvebu.h | 22 +
>> drivers/clocksource/Kconfig | 4 +
>> drivers/clocksource/Makefile | 1 +
>> drivers/clocksource/mvebu.c | 90 ++
>> scripts/.gitignore | 2 +
>> scripts/Makefile | 3 +-
>> scripts/checkpatch.pl | 2 +-
>> scripts/kwbimage.c | 1224 ++++++++++++++++++++
>> scripts/kwboot.c | 717 ++++++++++++
>> 34 files changed, 2540 insertions(+), 2 deletions(-)
>> create mode 100644 arch/arm/boards/globalscale-mirabox/Makefile
>> create mode 100644 arch/arm/boards/globalscale-mirabox/config.h
>> create mode 100644 arch/arm/boards/globalscale-mirabox/globalscale-mirabox.c
>> create mode 100644 arch/arm/boards/globalscale-mirabox/kwbimage.cfg
>> create mode 100644 arch/arm/boards/globalscale-mirabox/lowlevel.c
>> create mode 100644 arch/arm/boards/marvell-armada-xp-gp/Makefile
>> create mode 100644 arch/arm/boards/marvell-armada-xp-gp/config.h
>> create mode 100644 arch/arm/boards/marvell-armada-xp-gp/kwbimage.cfg
>> create mode 100644 arch/arm/boards/marvell-armada-xp-gp/lowlevel.c
>> create mode 100644 arch/arm/boards/marvell-armada-xp-gp/marvell-armada-xp-gp.c
>> create mode 100644 arch/arm/boards/plathome-openblocks-ax3/Makefile
>> create mode 100644 arch/arm/boards/plathome-openblocks-ax3/config.h
>> create mode 100644 arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
>> create mode 100644 arch/arm/boards/plathome-openblocks-ax3/lowlevel.c
>> create mode 100644 arch/arm/boards/plathome-openblocks-ax3/plathome-openblocks-ax3.c
>> create mode 100644 arch/arm/configs/globalscale_mirabox_defconfig
>> create mode 100644 arch/arm/configs/marvell_armada_xp_gp_defconfig
>> create mode 100644 arch/arm/configs/plathome_openblocks_ax3_defconfig
>> create mode 100644 arch/arm/mach-mvebu/Kconfig
>> create mode 100644 arch/arm/mach-mvebu/Makefile
>> create mode 100644 arch/arm/mach-mvebu/core.c
>> create mode 100644 arch/arm/mach-mvebu/include/mach/clkdev.h
>> create mode 100644 arch/arm/mach-mvebu/include/mach/debug_ll.h
>> create mode 100644 arch/arm/mach-mvebu/include/mach/mvebu.h
>> create mode 100644 drivers/clocksource/mvebu.c
>> create mode 100644 scripts/kwbimage.c
>> create mode 100644 scripts/kwboot.c
>>
>
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC
2013-05-07 23:28 ` Gregory CLEMENT
2013-05-07 23:46 ` Gregory CLEMENT
@ 2013-05-08 10:46 ` Thomas Petazzoni
2013-05-08 21:02 ` Gregory CLEMENT
1 sibling, 1 reply; 63+ messages in thread
From: Thomas Petazzoni @ 2013-05-08 10:46 UTC (permalink / raw)
To: Gregory CLEMENT; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
Dear Gregory CLEMENT,
On Wed, 08 May 2013 01:28:47 +0200, Gregory CLEMENT wrote:
> it was a great work, I am currently trying to use but unfortunately,
> I didn't managed to run barebox on the Armada XP OpenBlocks AX3 from
> Plathome :/
>
> I get something like that:
>
> kwboot -t -b barebix.bin.kw -B 115200 /dev/ttyUSB0
> Sending boot message. Please reboot the target...-
>
> [here I power up the AX3]
>
> Sending boot image...
> 0 % [......................................................................]
> 4 % [......................................................................]
> 9 % [......................................................................]
> 14 % [......................................................................]
> 18 % [......................................................................]
> 23 % [......................................................................]
> 28 % [......................................................................]
> 33 % [......................................................................]
> 37 % [......................................................................]
> 42 % [......................................................................]
> 47 % [......................................................................]
> 52 % [.............................................................BootROM: Invalid header ID
> Booting from NOR flash
> DDR3 Training Sequence - Ver 3.0.0
Thanks for testing!
The kwbimage.cfg for the OpenBlocks AX3 was wrong in this first version
of the patches. 'BOOT_FROM spi' should have been 'BOOT_FROM uart' if
you want the image to be bootable from the UART.
> > An image is then later created with:
> >
> > ./scripts/kwbimage -x -i <path/to/kwbimage.cfg> -o <image>
>
> I think it should be:
> ./scripts/kwbimage -c -i <path/to/kwbimage.cfg> -o <image>
Correct, will fix!
I plan to send a v2 either today or tomorrow.
Thanks again for the testing,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread
* Re: [PATCH 0/7] Basic support for Marvell Armada 370/XP SoC
2013-05-08 10:46 ` Thomas Petazzoni
@ 2013-05-08 21:02 ` Gregory CLEMENT
0 siblings, 0 replies; 63+ messages in thread
From: Gregory CLEMENT @ 2013-05-08 21:02 UTC (permalink / raw)
To: Thomas Petazzoni; +Cc: Lior Amsalem, barebox, Willy Tarreau, Ezequiel Garcia
On 05/08/2013 12:46 PM, Thomas Petazzoni wrote:
> Dear Gregory CLEMENT,
>
> On Wed, 08 May 2013 01:28:47 +0200, Gregory CLEMENT wrote:
>
>> it was a great work, I am currently trying to use but unfortunately,
>> I didn't managed to run barebox on the Armada XP OpenBlocks AX3 from
>> Plathome :/
>>
>> I get something like that:
>>
>> kwboot -t -b barebix.bin.kw -B 115200 /dev/ttyUSB0
>> Sending boot message. Please reboot the target...-
>>
>> [here I power up the AX3]
>>
>> Sending boot image...
>> 0 % [......................................................................]
>> 4 % [......................................................................]
>> 9 % [......................................................................]
>> 14 % [......................................................................]
>> 18 % [......................................................................]
>> 23 % [......................................................................]
>> 28 % [......................................................................]
>> 33 % [......................................................................]
>> 37 % [......................................................................]
>> 42 % [......................................................................]
>> 47 % [......................................................................]
>> 52 % [.............................................................BootROM: Invalid header ID
>> Booting from NOR flash
>> DDR3 Training Sequence - Ver 3.0.0
>
> Thanks for testing!
>
> The kwbimage.cfg for the OpenBlocks AX3 was wrong in this first version
> of the patches. 'BOOT_FROM spi' should have been 'BOOT_FROM uart' if
> you want the image to be bootable from the UART.
Indeed, by updating kwbimage.cfg with 'BOOT_FROM uart' I also managed to run
barebox on the OpenBlocks AX3.
Thanks!
>
>>> An image is then later created with:
>>>
>>> ./scripts/kwbimage -x -i <path/to/kwbimage.cfg> -o <image>
>>
>> I think it should be:
>> ./scripts/kwbimage -c -i <path/to/kwbimage.cfg> -o <image>
>
> Correct, will fix!
>
> I plan to send a v2 either today or tomorrow.
>
> Thanks again for the testing,
>
> Thomas
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply [flat|nested] 63+ messages in thread