SPL: Add YMODEM over UART load support

From: Matt Porter <[email protected]>

Adds support for loading U-Boot from UART using YMODEM protocol. If YMODEM support is enabled in SPL and the romcode indicates that SPL loaded via UART then SPL will wait for start of a YMODEM transfer via the console port.

Signed-off-by Matt Porter <[email protected]>

Signed-off-by Tom Rini <[email protected]>

---
 arch/arm/cpu/armv7/omap-common/Makefile     |    3 +
 arch/arm/cpu/armv7/omap-common/spl.c        |    5 ++
 arch/arm/cpu/armv7/omap-common/spl_ymodem.c |   76

 arch/arm/include/asm/omap_common.h          |    3 +
 common/Makefile                             |    3 +
 lib/Makefile                                |    3 +
 6 files changed, 93 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/omap-common/spl_ymodem.c

new file mode 100644
index 0000000..47663f7

arch/arm/cpu/armv7/omap-common/spl_ymodem.c new file +51 -0

@@ -0,0 +1,76 @@
+/*
+ * (C) Copyright 2000-2004
+ * Wolfgang Denk, DENX Software Engineering, wd at denx.de.
+ *
+ * (C) Copyright 2011
+ * Texas Instruments, <www.ti.com>
+ *
+ * Matt Porter <[email protected]>
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+#include <common.h>
+#include <xyzModem.h>
+#include <asm/u-boot.h>
+#include <asm/utils.h>
+#include <asm/arch/sys_proto.h>
+#include <asm/omap_common.h>
+
+#define BUF_SIZE 1024
+
+static int getcymodem(void) {
+       if (tstc())
+               return (getc());
+       return -1;
+}
+
+void spl_ymodem_load_image(void)
+{
+       int size = 0;
+       int err;
+       int res;
+       int ret;
+       connection_info_t info;
+       char buf[BUF_SIZE];
+       ulong store_addr = ~0;

arch/arm/cpu/armv7/omap-common/spl_ymodem.c new file +15 -0

+                       store_addr = addr + spl_image.load_addr;
+                       size += res;
+                       addr += res;
+                       memcpy((char *)(store_addr), buf, res);
+               }
+       } else {
+               printf("spl: ymodem err - %s\n", xyzModem_error(err));
+               hang();
+       }
+
+       xyzModem_stream_close(&err);
+       xyzModem_stream_terminate(false, &getcymodem);
+
+       printf("Loaded %d bytes\n", size);
+}

Hi Tom, Hi Matt,

Quoted 6 lines · Tom Rini

From: Matt Porter <[email protected]>

Adds support for loading U-Boot from UART using YMODEM protocol. If YMODEM support is enabled in SPL and the romcode indicates that SPL loaded via UART then SPL will wait for start of a YMODEM transfer via the console port.

:-) I like this feature!

I tried something similar a few month ago for the da850evm and my own board, it worked but I never had time to finished it and submit it, it was just a hack.

For my tests I used the UART loader utility from TI to load the SPL and then minicom for loading u-boot. Do you have an automated solution for this? Would be nice to have something like this in tools/.

Could this be somewhere where it's accessible for other SoC families like davinci? E.g. We have nand_spl_load.c in drivers/mtd/nand and something similar for SPI flash.

From: Matt Porter <[email protected]>

Adds support for loading U-Boot from UART using YMODEM protocol. If YMODEM support is enabled in SPL and the romcode indicates that SPL loaded via UART then SPL will wait for start of a YMODEM transfer via the console port.

Dear Tom Rini,

Quoted 6 lines · In message <[email protected]> you wrote:

From: Matt Porter <[email protected]>

Adds support for loading U-Boot from UART using YMODEM protocol. If YMODEM support is enabled in SPL and the romcode indicates that SPL loaded via UART then SPL will wait for start of a YMODEM transfer via the console port.

Does it really make sense to add all kind of bloat to the SPL?

What originally has been designed to be minimal code now start to pull in all kinds of other crap, that has never been designed to run before relocation.

Quoted 4 lines

What originally has been designed to be minimal code now start to pull in all kinds of other crap, that has never been designed to run before relocation.

Boards that don't need it can opt out. We use this internally for automated testing of U-Boot on hardware (and I'm setting up the same thing locally).

Dear Tom Rini,

Quoted 8 lines · In message <CA+M6bXmKum1B39RVcJ+jgDRmFCFr5sToZYDUVXnM4NfUZ-XQaQ@mail.gmail.com>…

Quoted 4 lines

What originally has been designed to be minimal code now start to pull in all kinds of other crap, that has never been designed to run before relocation.

Boards that don't need it can opt out. ?We use this internally for automated testing of U-Boot on hardware (and I'm setting up the same thing locally).

I don't deny that it's useful. ?And it may even ork fine in your specific case.

But the approach is wrong. This code has never been meant to run before relocation.

I object against opening this pandora box.

If you have so ample resources to run such code, then load a minimal configuration of U-Boot.

Quoted 5 lines

I object against opening this pandora box.

If you have so ample resources to run such code, then load a minimal configuration of U-Boot.

Is this a change of heart then?

http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/109170

Dear Tom Rini,

Quoted 6 lines · In message <CA+M6bXnb5k6gA8kbqr0BQ+JLMVFXpzCT+g+dEXfJx307fYn=ew@mail.gmail.com>…

Quoted 5 lines

I object against opening this pandora box.

If you have so ample resources to run such code, then load a minimal configuration of U-Boot.

Quoted 1 line

Is this a change of heart then?

No - I never was happy about pulling arbitrary code into SPL.

Quoted 1 line

http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/109170

I don't see how this is related?

Dear Tom Rini,

Quoted 6 lines · In message <[email protected]> you wrote:

From: Matt Porter <[email protected]>

Adds support for loading U-Boot from UART using YMODEM protocol. If YMODEM support is enabled in SPL and the romcode indicates that SPL loaded via UART then SPL will wait for start of a YMODEM transfer via the console port.

Does it really make sense to add all kind of bloat to the SPL?

What originally has been designed to be minimal code now start to pull in all kinds of other crap,

that has never been designed to run before relocation.

Quoted 12 lines · Wolfgang Denk

Dear Tom Rini,

Quoted 6 lines · In message <[email protected]> you wrote:

From: Matt Porter <[email protected]>

Adds support for loading U-Boot from UART using YMODEM protocol. If YMODEM support is enabled in SPL and the romcode indicates that SPL loaded via UART then SPL will wait for start of a YMODEM transfer via the console port.

Does it really make sense to add all kind of bloat to the SPL?

Quoted 2 lines

What originally has been designed to be minimal code now start to pull in all kinds of other crap,

What's the alternative -- another name and separate makefile infrastructure for non-minimal initial loaders?

It's important that SPL be *able* to produce very small images when needed, but its purpose has grown beyond that.

Quoted 1 line

that has never been designed to run before relocation.

At least some SPLs do relocation.

Maybe we need to separate out the systems which are very resource constrained from the ones that aren't, share code where we can and make that code obviously marked as such.

Dear Tom Rini,

Quoted 1 line · In message <CA+M6bXkXA+356AFLGDS55o=7bZuuQCcPCXAVEjo9AWDENn3wfQ@mail.gmail.com>…

Quoted 3 lines

Maybe we need to separate out the systems which are very resource constrained from the ones that aren't, share code where we can and make that code obviously marked as such.

I think it's the other way round. You ned to find out which code is safe to call from a restricted environment, and track down the linker dependencies to make sure you don't pull something in that breaks. Which means you need to review all code and mark it's requirements.

What's the alternative -- another name and separate makefile infrastructure for non-minimal initial loaders?

It's important that SPL be *able* to produce very small images when needed, but its purpose has grown beyond that.