85xx: add ability to upload QE firmware

Define the layout of a binary blob that contains a QE firmware and instructions on how to upload it. Add function qe_upload_firmware() to parse the blob and perform the actual upload. Add command-line command "qe fw" to take a firmware blob in memory and upload it. Update ft_cpu_setup() on 83xx to create the 'firmware' device tree node if U-Boot has uploaded a firmware. Fully define 'struct rsp' in immap_qe.h to include the actual RISC Special Registers.

---

Tested on an MPC8568 MDS. This patch applies on top of Kumar's mpc85xx branch.

 common/fdt_support.c       |   48 ++++++++++
 cpu/mpc85xx/fdt.c          |    1 +
 drivers/qe/qe.c            |  219 ++++++++++++++++++++++++++++++++++++++++++++
 drivers/qe/qe.h            |   56 +++++++++++
 include/asm-ppc/immap_qe.h |   33 ++++++-
 include/fdt_support.h      |    1 +
 6 files changed, 356 insertions(+), 2 deletions(-)

index b5ee6e9..17a9da4 100644
@@ -30,6 +30,9 @@
 #include <fdt_support.h>
 #include <exports.h>
 
+#ifdef CONFIG_QE
+#include "../drivers/qe/qe.h"
+#endif
 /*
  * Global data (for the gd->bd)
  */

@@ -607,4 +610,49 @@ void fdt_fixup_ethernet(void *fdt, bd_t *bd)
 #endif
 	}
 }
+
+#ifdef CONFIG_QE
+/*
+ * If a QE firmware has been uploaded, then add the 'firmware' node under
+ * the 'qe' node.
+ */
+void fdt_fixup_qe_firmware(void *fdt)
+{
+	struct qe_firmware_info *qe_fw_info;
+	int node, ret;
+
+	qe_fw_info = qe_get_firmware_info();
+	if (!qe_fw_info)
+		return;
+
+	node = fdt_path_offset(fdt, "/qe");
+	if (node < 0)
+		return;
+
+	/* We assume the node doesn't exist yet */
+	node = fdt_add_subnode(fdt, node, "firmware");
+	if (node < 0)
+		return;
+
+	ret = fdt_setprop(fdt, node, "extended_modes",
+		&qe_fw_info->extended_modes, sizeof(u64));
+	if (ret < 0)
+		goto error;
+
+	ret = fdt_setprop_string(fdt, node, "id", qe_fw_info->id);
+	if (ret < 0)
+		goto error;
+
+	ret = fdt_setprop(fdt, node, "virtual_traps", qe_fw_info->vtraps,
+		sizeof(qe_fw_info->vtraps));
+	if (ret < 0)
+		goto error;
+
+	return;
+
+error:
+	fdt_del_node(fdt, node);
+}
+#endif
+
 #endif

index 737a6c4..0812c89 100644
@@ -45,6 +45,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
 #ifdef CONFIG_QE
 	do_fixup_by_prop_u32(blob, "device_type", "soc", 4,
 		"bus-frequency", bd->bi_busfreq, 1);
+	fdt_fixup_qe_firmware(blob);
 #endif
 
 #ifdef CFG_NS16550

index a16a6d3..39da377 100644
@@ -513,10 +513,39 @@ typedef struct dbg {
 	u8 res2[0x48];
 } __attribute__ ((packed)) dbg_t;
 
-/* RISC Special Registers (Trap and Breakpoint)
+/*
+ * RISC Special Registers (Trap and Breakpoint).  These are described in
+ * the QE Developer's Handbook.
 */
 typedef struct rsp {
-	u8 fixme[0x100];
+	u32 tibcr[16];	/* Trap/instruction breakpoint control regs */
+	u8 res0[64];
+	u32 ibcr0;
+	u32 ibs0;
+	u32 ibcnr0;
+	u8 res1[4];
+	u32 ibcr1;
+	u32 ibs1;
+	u32 ibcnr1;
+	u32 npcr;
+	u32 dbcr;
+	u32 dbar;
+	u32 dbamr;
+	u32 dbsr;
+	u32 dbcnr;
+	u8 res2[12];
+	u32 dbdr_h;
+	u32 dbdr_l;
+	u32 dbdmr_h;
+	u32 dbdmr_l;
+	u32 bsr;
+	u32 bor;
+	u32 bior;
+	u8 res3[4];
+	u32 iatr[4];
+	u32 eccr;		/* Exception control configuration register */
+	u32 eicr;
+	u8 res4[0x100-0xf8];
 } __attribute__ ((packed)) rsp_t;
 
 typedef struct qe_immap {

index 3d6c1a8..859eaa8 100644
@@ -46,6 +46,7 @@ void do_fixup_by_compat_u32(void *fdt, const char *compat,
 			    const char *prop, u32 val, int create);
 int fdt_fixup_memory(void *blob, u64 start, u64 size);
 void fdt_fixup_ethernet(void *fdt, bd_t *bd);
+void fdt_fixup_qe_firmware(void *fdt);
 
 #ifdef CONFIG_OF_HAS_UBOOT_ENV
 int fdt_env(void *fdt);

1.5.2.4

I'm not sure if such firmware shouldbe part of the device tree, or rather a separate image or part of the image. Actually I think the definition of such a blob, if needed at all, should only be a tamporary workaround unti we have the new image format in place. Then this should become part of the new image implementation.

Please follow the ongoing discussions of this topic and make sure to voice your wishes and requirements.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Is a computer language with goto's totally Wirth-less?

The firmware itself is not part of the device tree, just a few pieces of information about the firmware. I need some way to pass information from U-Boot to the kernel, and my choices are the device tree or command line. The command line is clunky, and so I thought the device tree is best place. This design decision has already been reviewed (and approved by Arnd) on the kernel mailing lists.

The firmware blob needs to be a separate image because the code and firmware layout is meant to be cross-platform, so I can't use any U-Boot-specific wrapper. In addition, the firmware itself is not GPL, so I can't merge it with GPL code, or anything else for that matter. It needs to exist as an independent entity. The code which uploads the blob into the QE is GPL, of course.

The design and layout of the firmware blob is specific to the needs of the QE. I don't see how a new image format will help. I'll only use the new image format to wrap the binary.

The goal is to have this firmware blob sitting in flash somewhere, all I need to do to upload it is:

qe fw $fwaddr

The ability to upload firmware to the QE in U-Boot is needed by QE microcode developers.

Are you talking about "RFC: New U-boot image format"? If so, then I just don't see how that applies. I don't want a new binary format, because I already have one defined that works. If you want me to add support for my binary blob wrapped in some other kind of image format, I can add that *after* this patch has been applied, since the ability to accept these binary blobs as-is is necessary.

Timur Tabi
Linux kernel developer at Freescale

Yes, I do.

Think about the situation that someone whats to use DHCP to boot his board, which will usually result in the TFTP download of exactly *one* image from a TFTP server. That image should then contain the Linux kernel, the dtb, the QE firmware image, eventually a ramdisk, and maybe even more... That's what the new image format is about.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If I don't document something, it's usually either for a good reason,
or a bad reason.  In this case it's a good reason.  :-)
                 - Larry Wall in <[email protected]>

Ok, I can appreciate that, but how is my QE firmware blob any different from any other generic binary that this new image format must support? And since this new format is still a long way from being implemented, I don't see why it should delay adding support for QE firmware.

The "qe fw" command requires an address, and it takes care of the rest. As long as this new image format can identify the QE firmware within it and pass the address of the blob to the "qe fw" command, I don't really care about the rest.

Timur Tabi
Linux kernel developer at Freescale

It's just another type of payload to wrap and to recognize.

Oh, that's not a long way. Probaly counted in weeks rather than months.

Yes, but how do you get this address from a multi-file image format?

I see.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
 The software required `Windows 95 or better', so I installed Linux.

Hmmmm. I think the easiest way would be to for the multi-file image format processing code to identify the QE firmware blob and set the '$qefwaddr' environment variable accordingly.

I'll add my two cents to the multi-image format thread.

Timur Tabi
Linux kernel developer at Freescale

It will not do that. Booting a multifile image is a different procedure.

Yes, please.

Best regards,

Wolfgang Denk

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Anyone who isn't confused here doesn't really know what's going on.

Slight typo -- this should say "85xx" not "83xx". Andy, please correct if/when you apply this patch.

Timur Tabi
Linux kernel developer at Freescale