2012-06-15 22:45:18 +02:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2012 Henrik Nordstrom <henrik@henriknordstrom.net>
|
|
|
|
|
*
|
|
|
|
|
* 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, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* Needs _BSD_SOURCE for htole and letoh */
|
2015-09-09 11:57:47 +02:00
|
|
|
/* glibc 2.20+ also requires _DEFAULT_SOURCE */
|
|
|
|
|
#define _DEFAULT_SOURCE
|
2012-06-15 22:45:18 +02:00
|
|
|
#define _BSD_SOURCE
|
2014-01-31 21:36:18 +01:00
|
|
|
#define _NETBSD_SOURCE
|
2012-06-15 22:45:18 +02:00
|
|
|
|
|
|
|
|
#include <libusb.h>
|
|
|
|
|
#include <stdint.h>
|
2015-11-19 15:49:55 +01:00
|
|
|
#include <stdbool.h>
|
2012-06-15 22:45:18 +02:00
|
|
|
#include <assert.h>
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
#include <string.h>
|
|
|
|
|
#include <stdio.h>
|
|
|
|
|
#include <ctype.h>
|
2015-02-23 11:37:00 +02:00
|
|
|
#include <stdarg.h>
|
2013-09-06 22:22:51 +02:00
|
|
|
#include <errno.h>
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
#include <unistd.h>
|
2015-11-26 15:36:43 +01:00
|
|
|
#include <sys/stat.h>
|
2012-06-16 18:24:57 +02:00
|
|
|
|
2012-08-07 00:18:34 +00:00
|
|
|
#include "endian_compat.h"
|
2015-11-13 11:19:02 +01:00
|
|
|
#include "progress.h"
|
2012-07-18 21:06:38 +02:00
|
|
|
|
2012-06-15 22:45:18 +02:00
|
|
|
struct aw_usb_request {
|
|
|
|
|
char signature[8];
|
|
|
|
|
uint32_t length;
|
|
|
|
|
uint32_t unknown1; /* 0x0c000000 */
|
|
|
|
|
uint16_t request;
|
|
|
|
|
uint32_t length2; /* Same as length */
|
|
|
|
|
char pad[10];
|
|
|
|
|
} __attribute__((packed));
|
|
|
|
|
|
2015-02-06 22:26:33 +02:00
|
|
|
struct aw_fel_version {
|
|
|
|
|
char signature[8];
|
|
|
|
|
uint32_t soc_id; /* 0x00162300 */
|
|
|
|
|
uint32_t unknown_0a; /* 1 */
|
|
|
|
|
uint16_t protocol; /* 1 */
|
|
|
|
|
uint8_t unknown_12; /* 0x44 */
|
|
|
|
|
uint8_t unknown_13; /* 0x08 */
|
|
|
|
|
uint32_t scratchpad; /* 0x7e00 */
|
|
|
|
|
uint32_t pad[2]; /* unused */
|
|
|
|
|
} __attribute__((packed));
|
|
|
|
|
|
2012-06-15 22:45:18 +02:00
|
|
|
static const int AW_USB_READ = 0x11;
|
|
|
|
|
static const int AW_USB_WRITE = 0x12;
|
|
|
|
|
|
2014-09-21 23:42:41 +08:00
|
|
|
static int AW_USB_FEL_BULK_EP_OUT;
|
|
|
|
|
static int AW_USB_FEL_BULK_EP_IN;
|
2012-08-15 10:37:20 +02:00
|
|
|
static int timeout = 60000;
|
2015-11-19 15:49:55 +01:00
|
|
|
static bool verbose = false; /* If set, makes the 'fel' tool more talkative */
|
2015-07-15 18:33:38 +02:00
|
|
|
static uint32_t uboot_entry = 0; /* entry point (address) of U-Boot */
|
|
|
|
|
static uint32_t uboot_size = 0; /* size of U-Boot binary */
|
2015-02-23 11:37:00 +02:00
|
|
|
|
|
|
|
|
static void pr_info(const char *fmt, ...)
|
|
|
|
|
{
|
|
|
|
|
va_list arglist;
|
|
|
|
|
if (verbose) {
|
|
|
|
|
va_start(arglist, fmt);
|
|
|
|
|
vprintf(fmt, arglist);
|
|
|
|
|
va_end(arglist);
|
|
|
|
|
}
|
|
|
|
|
}
|
2012-06-15 22:45:18 +02:00
|
|
|
|
2015-02-04 20:38:23 +02:00
|
|
|
static const int AW_USB_MAX_BULK_SEND = 4 * 1024 * 1024; // 4 MiB per bulk request
|
|
|
|
|
|
2015-11-13 12:15:45 +01:00
|
|
|
void usb_bulk_send(libusb_device_handle *usb, int ep, const void *data,
|
|
|
|
|
size_t length, bool progress)
|
2012-06-15 22:45:18 +02:00
|
|
|
{
|
2015-11-13 13:10:46 +01:00
|
|
|
/*
|
|
|
|
|
* With no progress notifications, we'll use the maximum chunk size.
|
|
|
|
|
* Otherwise, it's useful to lower the size (have more chunks) to get
|
|
|
|
|
* more frequent status updates. 128 KiB per request seem suitable.
|
|
|
|
|
*/
|
|
|
|
|
size_t max_chunk = progress ? 128 * 1024 : AW_USB_MAX_BULK_SEND;
|
2015-11-13 12:15:45 +01:00
|
|
|
|
|
|
|
|
size_t chunk;
|
2012-06-15 22:45:18 +02:00
|
|
|
int rc, sent;
|
|
|
|
|
while (length > 0) {
|
2015-11-13 12:15:45 +01:00
|
|
|
chunk = length < max_chunk ? length : max_chunk;
|
|
|
|
|
rc = libusb_bulk_transfer(usb, ep, (void *)data, chunk, &sent, timeout);
|
2012-06-15 22:45:18 +02:00
|
|
|
if (rc != 0) {
|
2012-08-15 10:37:46 +02:00
|
|
|
fprintf(stderr, "libusb usb_bulk_send error %d\n", rc);
|
2012-06-15 22:45:18 +02:00
|
|
|
exit(2);
|
|
|
|
|
}
|
|
|
|
|
length -= sent;
|
|
|
|
|
data += sent;
|
2015-11-13 12:15:45 +01:00
|
|
|
|
|
|
|
|
if (progress)
|
|
|
|
|
progress_update(sent); // notification after each chunk
|
2012-06-15 22:45:18 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void usb_bulk_recv(libusb_device_handle *usb, int ep, void *data, int length)
|
|
|
|
|
{
|
|
|
|
|
int rc, recv;
|
|
|
|
|
while (length > 0) {
|
2012-08-15 10:37:20 +02:00
|
|
|
rc = libusb_bulk_transfer(usb, ep, data, length, &recv, timeout);
|
2012-06-15 22:45:18 +02:00
|
|
|
if (rc != 0) {
|
2012-08-15 10:37:46 +02:00
|
|
|
fprintf(stderr, "usb_bulk_recv error %d\n", rc);
|
2012-06-15 22:45:18 +02:00
|
|
|
exit(2);
|
|
|
|
|
}
|
|
|
|
|
length -= recv;
|
|
|
|
|
data += recv;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-09-29 16:36:41 +02:00
|
|
|
/* Constants taken from ${U-BOOT}/include/image.h */
|
|
|
|
|
#define IH_MAGIC 0x27051956 /* Image Magic Number */
|
|
|
|
|
#define IH_ARCH_ARM 2 /* ARM */
|
|
|
|
|
#define IH_TYPE_INVALID 0 /* Invalid Image */
|
|
|
|
|
#define IH_TYPE_FIRMWARE 5 /* Firmware Image */
|
|
|
|
|
#define IH_TYPE_SCRIPT 6 /* Script file */
|
|
|
|
|
#define IH_NMLEN 32 /* Image Name Length */
|
|
|
|
|
|
|
|
|
|
/* Additional error codes, newly introduced for get_image_type() */
|
|
|
|
|
#define IH_TYPE_ARCH_MISMATCH -1
|
|
|
|
|
|
|
|
|
|
#define HEADER_NAME_OFFSET 32 /* offset of name field */
|
|
|
|
|
#define HEADER_SIZE (HEADER_NAME_OFFSET + IH_NMLEN)
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Utility function to determine the image type from a mkimage-compatible
|
|
|
|
|
* header at given buffer (address).
|
|
|
|
|
*
|
|
|
|
|
* For invalid headers (insufficient size or 'magic' mismatch) the function
|
|
|
|
|
* will return IH_TYPE_INVALID. Negative return values might indicate
|
|
|
|
|
* special error conditions, e.g. IH_TYPE_ARCH_MISMATCH signals that the
|
|
|
|
|
* image doesn't match the expected (ARM) architecture.
|
|
|
|
|
* Otherwise the function will return the "ih_type" field for valid headers.
|
|
|
|
|
*/
|
|
|
|
|
int get_image_type(const uint8_t *buf, size_t len)
|
|
|
|
|
{
|
|
|
|
|
uint32_t *buf32 = (uint32_t *)buf;
|
|
|
|
|
|
|
|
|
|
if (len <= HEADER_SIZE) /* insufficient length/size */
|
|
|
|
|
return IH_TYPE_INVALID;
|
|
|
|
|
if (be32toh(buf32[0]) != IH_MAGIC) /* signature mismatch */
|
|
|
|
|
return IH_TYPE_INVALID;
|
|
|
|
|
/* For sunxi, we always expect ARM architecture here */
|
|
|
|
|
if (buf[29] != IH_ARCH_ARM)
|
|
|
|
|
return IH_TYPE_ARCH_MISMATCH;
|
|
|
|
|
|
|
|
|
|
/* assume a valid header, and return ih_type */
|
|
|
|
|
return buf[30];
|
|
|
|
|
}
|
|
|
|
|
|
2012-06-15 22:45:18 +02:00
|
|
|
void aw_send_usb_request(libusb_device_handle *usb, int type, int length)
|
|
|
|
|
{
|
|
|
|
|
struct aw_usb_request req;
|
|
|
|
|
memset(&req, 0, sizeof(req));
|
|
|
|
|
strcpy(req.signature, "AWUC");
|
|
|
|
|
req.length = req.length2 = htole32(length);
|
|
|
|
|
req.request = htole16(type);
|
|
|
|
|
req.unknown1 = htole32(0x0c000000);
|
2015-11-13 12:15:45 +01:00
|
|
|
usb_bulk_send(usb, AW_USB_FEL_BULK_EP_OUT, &req, sizeof(req), false);
|
2012-06-15 22:45:18 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void aw_read_usb_response(libusb_device_handle *usb)
|
|
|
|
|
{
|
|
|
|
|
char buf[13];
|
|
|
|
|
usb_bulk_recv(usb, AW_USB_FEL_BULK_EP_IN, &buf, sizeof(buf));
|
|
|
|
|
assert(strcmp(buf, "AWUS") == 0);
|
|
|
|
|
}
|
|
|
|
|
|
2015-11-13 12:15:45 +01:00
|
|
|
void aw_usb_write(libusb_device_handle *usb, const void *data, size_t len,
|
|
|
|
|
bool progress)
|
2012-06-15 22:45:18 +02:00
|
|
|
{
|
|
|
|
|
aw_send_usb_request(usb, AW_USB_WRITE, len);
|
2015-11-13 12:15:45 +01:00
|
|
|
usb_bulk_send(usb, AW_USB_FEL_BULK_EP_OUT, data, len, progress);
|
2012-06-15 22:45:18 +02:00
|
|
|
aw_read_usb_response(usb);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void aw_usb_read(libusb_device_handle *usb, const void *data, size_t len)
|
|
|
|
|
{
|
|
|
|
|
aw_send_usb_request(usb, AW_USB_READ, len);
|
2015-11-13 12:15:45 +01:00
|
|
|
usb_bulk_send(usb, AW_USB_FEL_BULK_EP_IN, data, len, false);
|
2012-06-15 22:45:18 +02:00
|
|
|
aw_read_usb_response(usb);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
struct aw_fel_request {
|
|
|
|
|
uint32_t request;
|
|
|
|
|
uint32_t address;
|
|
|
|
|
uint32_t length;
|
|
|
|
|
uint32_t pad;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static const int AW_FEL_VERSION = 0x001;
|
|
|
|
|
static const int AW_FEL_1_WRITE = 0x101;
|
|
|
|
|
static const int AW_FEL_1_EXEC = 0x102;
|
|
|
|
|
static const int AW_FEL_1_READ = 0x103;
|
|
|
|
|
|
|
|
|
|
void aw_send_fel_request(libusb_device_handle *usb, int type, uint32_t addr, uint32_t length)
|
|
|
|
|
{
|
|
|
|
|
struct aw_fel_request req;
|
|
|
|
|
memset(&req, 0, sizeof(req));
|
|
|
|
|
req.request = htole32(type);
|
|
|
|
|
req.address = htole32(addr);
|
|
|
|
|
req.length = htole32(length);
|
2015-11-13 12:15:45 +01:00
|
|
|
aw_usb_write(usb, &req, sizeof(req), false);
|
2012-06-15 22:45:18 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void aw_read_fel_status(libusb_device_handle *usb)
|
|
|
|
|
{
|
|
|
|
|
char buf[8];
|
|
|
|
|
aw_usb_read(usb, &buf, sizeof(buf));
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-06 22:26:33 +02:00
|
|
|
void aw_fel_get_version(libusb_device_handle *usb, struct aw_fel_version *buf)
|
2012-06-15 22:45:18 +02:00
|
|
|
{
|
|
|
|
|
aw_send_fel_request(usb, AW_FEL_VERSION, 0, 0);
|
2015-02-06 22:26:33 +02:00
|
|
|
aw_usb_read(usb, buf, sizeof(*buf));
|
2012-06-15 22:45:18 +02:00
|
|
|
aw_read_fel_status(usb);
|
|
|
|
|
|
2015-02-06 22:26:33 +02:00
|
|
|
buf->soc_id = (le32toh(buf->soc_id) >> 8) & 0xFFFF;
|
|
|
|
|
buf->unknown_0a = le32toh(buf->unknown_0a);
|
|
|
|
|
buf->protocol = le32toh(buf->protocol);
|
|
|
|
|
buf->scratchpad = le16toh(buf->scratchpad);
|
|
|
|
|
buf->pad[0] = le32toh(buf->pad[0]);
|
|
|
|
|
buf->pad[1] = le32toh(buf->pad[1]);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void aw_fel_print_version(libusb_device_handle *usb)
|
|
|
|
|
{
|
|
|
|
|
struct aw_fel_version buf;
|
|
|
|
|
aw_fel_get_version(usb, &buf);
|
2012-08-06 02:39:35 +02:00
|
|
|
|
2013-05-15 11:08:01 +02:00
|
|
|
const char *soc_name="unknown";
|
2015-02-06 22:26:33 +02:00
|
|
|
switch (buf.soc_id) {
|
2013-05-15 11:08:01 +02:00
|
|
|
case 0x1623: soc_name="A10";break;
|
|
|
|
|
case 0x1625: soc_name="A13";break;
|
|
|
|
|
case 0x1633: soc_name="A31";break;
|
2013-06-23 15:04:56 +02:00
|
|
|
case 0x1651: soc_name="A20";break;
|
2014-04-24 11:08:51 +08:00
|
|
|
case 0x1650: soc_name="A23";break;
|
2014-09-21 23:42:40 +08:00
|
|
|
case 0x1639: soc_name="A80";break;
|
2015-08-18 22:34:19 +08:00
|
|
|
case 0x1667: soc_name="A33";break;
|
2015-08-18 22:34:20 +08:00
|
|
|
case 0x1673: soc_name="A83T";break;
|
2015-08-18 22:34:21 +08:00
|
|
|
case 0x1680: soc_name="H3";break;
|
2013-05-15 11:08:01 +02:00
|
|
|
}
|
|
|
|
|
|
2015-02-06 22:26:33 +02:00
|
|
|
printf("%.8s soc=%08x(%s) %08x ver=%04x %02x %02x scratchpad=%08x %08x %08x\n",
|
|
|
|
|
buf.signature, buf.soc_id, soc_name, buf.unknown_0a,
|
|
|
|
|
buf.protocol, buf.unknown_12, buf.unknown_13,
|
|
|
|
|
buf.scratchpad, buf.pad[0], buf.pad[1]);
|
2012-06-15 22:45:18 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void aw_fel_read(libusb_device_handle *usb, uint32_t offset, void *buf, size_t len)
|
|
|
|
|
{
|
|
|
|
|
aw_send_fel_request(usb, AW_FEL_1_READ, offset, len);
|
|
|
|
|
aw_usb_read(usb, buf, len);
|
|
|
|
|
aw_read_fel_status(usb);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void aw_fel_write(libusb_device_handle *usb, void *buf, uint32_t offset, size_t len)
|
|
|
|
|
{
|
|
|
|
|
aw_send_fel_request(usb, AW_FEL_1_WRITE, offset, len);
|
2015-11-13 12:15:45 +01:00
|
|
|
aw_usb_write(usb, buf, len, false);
|
2012-06-15 22:45:18 +02:00
|
|
|
aw_read_fel_status(usb);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void aw_fel_execute(libusb_device_handle *usb, uint32_t offset)
|
|
|
|
|
{
|
|
|
|
|
aw_send_fel_request(usb, AW_FEL_1_EXEC, offset, 0);
|
|
|
|
|
aw_read_fel_status(usb);
|
|
|
|
|
}
|
|
|
|
|
|
2015-11-13 11:48:42 +01:00
|
|
|
/*
|
|
|
|
|
* This function is a higher-level wrapper for the FEL write functionality.
|
|
|
|
|
* Unlike aw_fel_write() above - which is reserved for internal use - this
|
|
|
|
|
* routine is meant to be called from "user" code, and supports (= allows)
|
|
|
|
|
* progress callbacks.
|
|
|
|
|
* The return value represents elapsed time in seconds (needed for execution).
|
|
|
|
|
*/
|
|
|
|
|
double aw_write_buffer(libusb_device_handle *usb, void *buf, uint32_t offset,
|
2015-11-13 12:15:45 +01:00
|
|
|
size_t len, bool progress)
|
2015-11-13 11:48:42 +01:00
|
|
|
{
|
|
|
|
|
/* safeguard against overwriting an already loaded U-Boot binary */
|
|
|
|
|
if (uboot_size > 0 && offset <= uboot_entry + uboot_size
|
|
|
|
|
&& offset + len >= uboot_entry)
|
|
|
|
|
{
|
|
|
|
|
fprintf(stderr, "ERROR: Attempt to overwrite U-Boot! "
|
|
|
|
|
"Request 0x%08X-0x%08X overlaps 0x%08X-0x%08X.\n",
|
|
|
|
|
offset, offset + len,
|
|
|
|
|
uboot_entry, uboot_entry + uboot_size);
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
double start = gettime();
|
|
|
|
|
aw_send_fel_request(usb, AW_FEL_1_WRITE, offset, len);
|
2015-11-13 12:15:45 +01:00
|
|
|
aw_usb_write(usb, buf, len, progress);
|
2015-11-13 11:48:42 +01:00
|
|
|
aw_read_fel_status(usb);
|
|
|
|
|
return gettime() - start;
|
|
|
|
|
}
|
|
|
|
|
|
2012-06-15 22:45:18 +02:00
|
|
|
void hexdump(void *data, uint32_t offset, size_t size)
|
|
|
|
|
{
|
|
|
|
|
size_t j;
|
|
|
|
|
unsigned char *buf = data;
|
|
|
|
|
for (j = 0; j < size; j+=16) {
|
|
|
|
|
size_t i;
|
|
|
|
|
printf("%08lx: ",(long int)offset + j);
|
|
|
|
|
for (i = 0; i < 16; i++) {
|
|
|
|
|
if ((j+i) < size) {
|
|
|
|
|
printf("%02x ", buf[j+i]);
|
|
|
|
|
} else {
|
|
|
|
|
printf("__ ");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
printf(" ");
|
|
|
|
|
for (i = 0; i < 16; i++) {
|
|
|
|
|
if (j+i >= size) {
|
|
|
|
|
printf(".");
|
|
|
|
|
} else if (isprint(buf[j+i])) {
|
|
|
|
|
printf("%c", buf[j+i]);
|
|
|
|
|
} else {
|
|
|
|
|
printf(".");
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
printf("\n");
|
|
|
|
|
}
|
|
|
|
|
}
|
2012-09-04 21:08:10 +02:00
|
|
|
|
2015-11-26 15:36:43 +01:00
|
|
|
unsigned int file_size(const char *filename)
|
|
|
|
|
{
|
|
|
|
|
struct stat st;
|
|
|
|
|
if (stat(filename, &st) != 0) {
|
|
|
|
|
fprintf(stderr, "stat() error on file \"%s\": %s\n", filename,
|
|
|
|
|
strerror(errno));
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
if (!S_ISREG(st.st_mode)) {
|
|
|
|
|
fprintf(stderr, "error: \"%s\" is not a regular file\n", filename);
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
return st.st_size;
|
|
|
|
|
}
|
|
|
|
|
|
2012-09-04 21:08:10 +02:00
|
|
|
int save_file(const char *name, void *data, size_t size)
|
|
|
|
|
{
|
|
|
|
|
FILE *out = fopen(name, "wb");
|
|
|
|
|
int rc;
|
2013-09-06 22:22:51 +02:00
|
|
|
if (!out) {
|
|
|
|
|
perror("Failed to open output file: ");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
2012-09-04 21:08:10 +02:00
|
|
|
rc = fwrite(data, size, 1, out);
|
|
|
|
|
fclose(out);
|
|
|
|
|
return rc;
|
|
|
|
|
}
|
|
|
|
|
|
2012-06-15 22:45:18 +02:00
|
|
|
void *load_file(const char *name, size_t *size)
|
|
|
|
|
{
|
|
|
|
|
size_t bufsize = 8192;
|
|
|
|
|
size_t offset = 0;
|
|
|
|
|
char *buf = malloc(bufsize);
|
|
|
|
|
FILE *in;
|
|
|
|
|
if (strcmp(name, "-") == 0)
|
|
|
|
|
in = stdin;
|
|
|
|
|
else
|
|
|
|
|
in = fopen(name, "rb");
|
2013-09-06 22:22:51 +02:00
|
|
|
if (!in) {
|
|
|
|
|
perror("Failed to open input file: ");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
2012-06-15 22:45:18 +02:00
|
|
|
|
|
|
|
|
while(1) {
|
2012-08-10 16:46:18 +02:00
|
|
|
ssize_t len = bufsize - offset;
|
|
|
|
|
ssize_t n = fread(buf+offset, 1, len, in);
|
2012-06-15 22:45:18 +02:00
|
|
|
offset += n;
|
2012-08-10 16:46:18 +02:00
|
|
|
if (n < len)
|
2012-06-15 22:45:18 +02:00
|
|
|
break;
|
|
|
|
|
bufsize <<= 1;
|
|
|
|
|
buf = realloc(buf, bufsize);
|
|
|
|
|
}
|
|
|
|
|
if (size)
|
|
|
|
|
*size = offset;
|
|
|
|
|
if (in != stdin)
|
|
|
|
|
fclose(in);
|
|
|
|
|
return buf;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void aw_fel_hexdump(libusb_device_handle *usb, uint32_t offset, size_t size)
|
|
|
|
|
{
|
|
|
|
|
unsigned char buf[size];
|
|
|
|
|
aw_fel_read(usb, offset, buf, size);
|
|
|
|
|
hexdump(buf, offset, size);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void aw_fel_dump(libusb_device_handle *usb, uint32_t offset, size_t size)
|
|
|
|
|
{
|
|
|
|
|
unsigned char buf[size];
|
|
|
|
|
aw_fel_read(usb, offset, buf, size);
|
|
|
|
|
fwrite(buf, size, 1, stdout);
|
|
|
|
|
}
|
2012-06-16 00:57:22 +02:00
|
|
|
void aw_fel_fill(libusb_device_handle *usb, uint32_t offset, size_t size, unsigned char value)
|
2012-06-15 22:45:18 +02:00
|
|
|
{
|
|
|
|
|
unsigned char buf[size];
|
2012-06-16 00:57:22 +02:00
|
|
|
memset(buf, value, size);
|
2015-11-13 12:15:45 +01:00
|
|
|
aw_write_buffer(usb, buf, offset, size, false);
|
2012-06-15 22:45:18 +02:00
|
|
|
}
|
|
|
|
|
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
/*
|
|
|
|
|
* The 'sram_swap_buffers' structure is used to describe information about
|
|
|
|
|
* two buffers in SRAM, the content of which needs to be exchanged before
|
|
|
|
|
* calling the U-Boot SPL code and then exchanged again before returning
|
|
|
|
|
* control back to the FEL code from the BROM.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
uint32_t buf1; /* BROM buffer */
|
|
|
|
|
uint32_t buf2; /* backup storage location */
|
|
|
|
|
uint32_t size; /* buffer size */
|
|
|
|
|
} sram_swap_buffers;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Each SoC variant may have its own list of memory buffers to be exchanged
|
|
|
|
|
* and the information about the placement of the thunk code, which handles
|
|
|
|
|
* the transition of execution from the BROM FEL code to the U-Boot SPL and
|
|
|
|
|
* back.
|
|
|
|
|
*
|
|
|
|
|
* Note: the entries in the 'swap_buffers' tables need to be sorted by 'buf1'
|
|
|
|
|
* addresses. And the 'buf1' addresses are the BROM data buffers, while 'buf2'
|
|
|
|
|
* addresses are the intended backup locations.
|
2015-11-17 02:27:56 +02:00
|
|
|
*
|
|
|
|
|
* Also for performance reasons, we optionally want to have MMU enabled with
|
|
|
|
|
* optimal section attributes configured (the code from the BROM should use
|
|
|
|
|
* I-cache, writing data to the DRAM area should use write combining). The
|
|
|
|
|
* reason is that the BROM FEL protocol implementation moves data using the
|
|
|
|
|
* CPU somewhere on the performance critical path when transferring data over
|
|
|
|
|
* USB. The older SoC variants (A10/A13/A20/A31/A23) already have MMU enabled
|
|
|
|
|
* and we only need to adjust section attributes. The BROM in newer SoC variants
|
|
|
|
|
* (A33/A83T/H3) doesn't enable MMU anymore, so we need to find some 16K of
|
|
|
|
|
* spare space in SRAM to place the translation table there and specify it as
|
|
|
|
|
* the 'mmu_tt_addr' field in the 'soc_sram_info' structure. The 'mmu_tt_addr'
|
|
|
|
|
* address must be 16K aligned.
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
*/
|
|
|
|
|
typedef struct {
|
2015-08-19 13:17:50 +03:00
|
|
|
uint32_t soc_id; /* ID of the SoC */
|
2015-08-19 14:41:56 +03:00
|
|
|
uint32_t spl_addr; /* SPL load address */
|
2015-08-19 13:17:50 +03:00
|
|
|
uint32_t scratch_addr; /* A safe place to upload & run code */
|
|
|
|
|
uint32_t thunk_addr; /* Address of the thunk code */
|
|
|
|
|
uint32_t thunk_size; /* Maximal size of the thunk code */
|
|
|
|
|
uint32_t needs_l2en; /* Set the L2EN bit */
|
2015-11-17 02:27:56 +02:00
|
|
|
uint32_t mmu_tt_addr; /* MMU translation table address */
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
sram_swap_buffers *swap_buffers;
|
|
|
|
|
} soc_sram_info;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* The FEL code from BROM in A10/A13/A20 sets up two stacks for itself. One
|
|
|
|
|
* at 0x2000 (and growing down) for the IRQ handler. And another one at 0x7000
|
|
|
|
|
* (and also growing down) for the regular code. In order to use the whole
|
|
|
|
|
* 32 KiB in the A1/A2 sections of SRAM, we need to temporarily move these
|
|
|
|
|
* stacks elsewhere. And the addresses above 0x7000 are also a bit suspicious,
|
|
|
|
|
* so it might be safer to backup the 0x7000-0x8000 area too. On A10/A13/A20
|
|
|
|
|
* we can use the SRAM section A3 (0x8000) for this purpose.
|
|
|
|
|
*/
|
|
|
|
|
sram_swap_buffers a10_a13_a20_sram_swap_buffers[] = {
|
|
|
|
|
{ .buf1 = 0x01800, .buf2 = 0x8000, .size = 0x800 },
|
|
|
|
|
{ .buf1 = 0x05C00, .buf2 = 0x8800, .size = 0x8000 - 0x5C00 },
|
|
|
|
|
{ 0 } /* End of the table */
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* A31 is very similar to A10/A13/A20, except that it has no SRAM at 0x8000.
|
|
|
|
|
* So we use the SRAM section at 0x44000 instead. This is the memory, which
|
|
|
|
|
* is normally shared with the OpenRISC core (should we do an extra check to
|
|
|
|
|
* ensure that this core is powered off and can't interfere?).
|
|
|
|
|
*/
|
|
|
|
|
sram_swap_buffers a31_sram_swap_buffers[] = {
|
|
|
|
|
{ .buf1 = 0x01800, .buf2 = 0x44000, .size = 0x800 },
|
|
|
|
|
{ .buf1 = 0x05C00, .buf2 = 0x44800, .size = 0x8000 - 0x5C00 },
|
|
|
|
|
{ 0 } /* End of the table */
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
soc_sram_info soc_sram_info_table[] = {
|
|
|
|
|
{
|
|
|
|
|
.soc_id = 0x1623, /* Allwinner A10 */
|
2015-08-19 13:17:50 +03:00
|
|
|
.scratch_addr = 0x2000,
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
.thunk_addr = 0xAE00, .thunk_size = 0x200,
|
|
|
|
|
.swap_buffers = a10_a13_a20_sram_swap_buffers,
|
2015-02-24 03:54:09 +02:00
|
|
|
.needs_l2en = 1,
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.soc_id = 0x1625, /* Allwinner A13 */
|
2015-08-19 13:17:50 +03:00
|
|
|
.scratch_addr = 0x2000,
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
.thunk_addr = 0xAE00, .thunk_size = 0x200,
|
|
|
|
|
.swap_buffers = a10_a13_a20_sram_swap_buffers,
|
2015-02-24 03:54:09 +02:00
|
|
|
.needs_l2en = 1,
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
},
|
|
|
|
|
{
|
|
|
|
|
.soc_id = 0x1651, /* Allwinner A20 */
|
2015-08-19 13:17:50 +03:00
|
|
|
.scratch_addr = 0x2000,
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
.thunk_addr = 0xAE00, .thunk_size = 0x200,
|
|
|
|
|
.swap_buffers = a10_a13_a20_sram_swap_buffers,
|
|
|
|
|
},
|
2015-02-24 19:15:14 +01:00
|
|
|
{
|
|
|
|
|
.soc_id = 0x1650, /* Allwinner A23 */
|
2015-08-19 13:17:50 +03:00
|
|
|
.scratch_addr = 0x2000,
|
2015-02-24 19:15:14 +01:00
|
|
|
.thunk_addr = 0x46E00, .thunk_size = 0x200,
|
|
|
|
|
.swap_buffers = a31_sram_swap_buffers,
|
|
|
|
|
},
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
{
|
|
|
|
|
.soc_id = 0x1633, /* Allwinner A31 */
|
2015-08-19 13:17:50 +03:00
|
|
|
.scratch_addr = 0x2000,
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
.thunk_addr = 0x46E00, .thunk_size = 0x200,
|
|
|
|
|
.swap_buffers = a31_sram_swap_buffers,
|
|
|
|
|
},
|
2015-08-18 22:34:19 +08:00
|
|
|
{
|
|
|
|
|
.soc_id = 0x1667, /* Allwinner A33 */
|
2015-08-19 13:17:50 +03:00
|
|
|
.scratch_addr = 0x2000,
|
2015-08-18 22:34:19 +08:00
|
|
|
.thunk_addr = 0x46E00, .thunk_size = 0x200,
|
|
|
|
|
.swap_buffers = a31_sram_swap_buffers,
|
|
|
|
|
},
|
2015-08-18 22:34:20 +08:00
|
|
|
{
|
|
|
|
|
.soc_id = 0x1673, /* Allwinner A83T */
|
2015-08-19 13:17:50 +03:00
|
|
|
.scratch_addr = 0x2000,
|
2015-08-18 22:34:20 +08:00
|
|
|
.thunk_addr = 0x46E00, .thunk_size = 0x200,
|
|
|
|
|
.swap_buffers = a31_sram_swap_buffers,
|
|
|
|
|
},
|
2015-08-18 22:34:21 +08:00
|
|
|
{
|
|
|
|
|
.soc_id = 0x1680, /* Allwinner H3 */
|
2015-08-19 13:17:50 +03:00
|
|
|
.scratch_addr = 0x2000,
|
2015-11-10 12:42:41 +02:00
|
|
|
.mmu_tt_addr = 0x44000,
|
2015-08-18 22:34:21 +08:00
|
|
|
.thunk_addr = 0x46E00, .thunk_size = 0x200,
|
|
|
|
|
.swap_buffers = a31_sram_swap_buffers,
|
|
|
|
|
},
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
{ 0 } /* End of the table */
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This generic record assumes BROM with similar properties to A10/A13/A20/A31,
|
|
|
|
|
* but no extra SRAM sections beyond 0x8000. It also assumes that the IRQ
|
|
|
|
|
* handler stack usage never exceeds 0x400 bytes.
|
|
|
|
|
*
|
|
|
|
|
* The users may or may not hope that the 0x7000-0x8000 area is also unused
|
|
|
|
|
* by the BROM and re-purpose it for the SPL stack.
|
|
|
|
|
*
|
|
|
|
|
* The size limit for the ".text + .data" sections is ~21 KiB.
|
|
|
|
|
*/
|
|
|
|
|
sram_swap_buffers generic_sram_swap_buffers[] = {
|
|
|
|
|
{ .buf1 = 0x01C00, .buf2 = 0x5800, .size = 0x400 },
|
|
|
|
|
{ 0 } /* End of the table */
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
soc_sram_info generic_sram_info = {
|
2015-08-19 13:17:50 +03:00
|
|
|
.scratch_addr = 0x2000,
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
.thunk_addr = 0x5680, .thunk_size = 0x180,
|
|
|
|
|
.swap_buffers = generic_sram_swap_buffers,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
soc_sram_info *aw_fel_get_sram_info(libusb_device_handle *usb)
|
|
|
|
|
{
|
2015-09-29 16:36:42 +02:00
|
|
|
/* persistent sram_info, retrieves result pointer once and caches it */
|
|
|
|
|
static soc_sram_info *result = NULL;
|
|
|
|
|
if (result == NULL) {
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
struct aw_fel_version buf;
|
|
|
|
|
aw_fel_get_version(usb, &buf);
|
|
|
|
|
|
|
|
|
|
for (i = 0; soc_sram_info_table[i].swap_buffers; i++)
|
|
|
|
|
if (soc_sram_info_table[i].soc_id == buf.soc_id) {
|
|
|
|
|
result = &soc_sram_info_table[i];
|
|
|
|
|
break;
|
|
|
|
|
}
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
|
2015-09-29 16:36:42 +02:00
|
|
|
if (!result) {
|
|
|
|
|
printf("Warning: no 'soc_sram_info' data for your SoC (id=%04X)\n",
|
|
|
|
|
buf.soc_id);
|
|
|
|
|
result = &generic_sram_info;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return result;
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static uint32_t fel_to_spl_thunk[] = {
|
|
|
|
|
#include "fel-to-spl-thunk.h"
|
|
|
|
|
};
|
|
|
|
|
|
2015-02-24 02:35:58 +02:00
|
|
|
#define DRAM_BASE 0x40000000
|
|
|
|
|
#define DRAM_SIZE 0x80000000
|
|
|
|
|
|
2015-11-17 01:08:33 +02:00
|
|
|
uint32_t aw_read_arm_cp_reg(libusb_device_handle *usb, soc_sram_info *sram_info,
|
|
|
|
|
uint32_t coproc, uint32_t opc1, uint32_t crn,
|
|
|
|
|
uint32_t crm, uint32_t opc2)
|
|
|
|
|
{
|
|
|
|
|
uint32_t val = 0;
|
|
|
|
|
uint32_t opcode = 0xEE000000 | (1 << 20) | (1 << 4) |
|
|
|
|
|
((opc1 & 7) << 21) |
|
|
|
|
|
((crn & 15) << 16) |
|
|
|
|
|
((coproc & 15) << 8) |
|
|
|
|
|
((opc2 & 7) << 5) |
|
|
|
|
|
(crm & 15);
|
|
|
|
|
uint32_t arm_code[] = {
|
|
|
|
|
htole32(opcode), /* mrc coproc, opc1, r0, crn, crm, opc2 */
|
|
|
|
|
htole32(0xe58f0000), /* str r0, [pc] */
|
|
|
|
|
htole32(0xe12fff1e), /* bx lr */
|
|
|
|
|
};
|
|
|
|
|
aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code));
|
|
|
|
|
aw_fel_execute(usb, sram_info->scratch_addr);
|
|
|
|
|
aw_fel_read(usb, sram_info->scratch_addr + 12, &val, sizeof(val));
|
|
|
|
|
return le32toh(val);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void aw_write_arm_cp_reg(libusb_device_handle *usb, soc_sram_info *sram_info,
|
|
|
|
|
uint32_t coproc, uint32_t opc1, uint32_t crn,
|
|
|
|
|
uint32_t crm, uint32_t opc2, uint32_t val)
|
|
|
|
|
{
|
|
|
|
|
uint32_t opcode = 0xEE000000 | (0 << 20) | (1 << 4) |
|
|
|
|
|
((opc1 & 7) << 21) |
|
|
|
|
|
((crn & 15) << 16) |
|
|
|
|
|
((coproc & 15) << 8) |
|
|
|
|
|
((opc2 & 7) << 5) |
|
|
|
|
|
(crm & 15);
|
|
|
|
|
uint32_t arm_code[] = {
|
|
|
|
|
htole32(0xe59f000c), /* ldr r0, [pc, #12] */
|
|
|
|
|
htole32(opcode), /* mcr coproc, opc1, r0, crn, crm, opc2 */
|
|
|
|
|
htole32(0xf57ff04f), /* dsb sy */
|
|
|
|
|
htole32(0xf57ff06f), /* isb sy */
|
|
|
|
|
htole32(0xe12fff1e), /* bx lr */
|
|
|
|
|
htole32(val)
|
|
|
|
|
};
|
|
|
|
|
aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code));
|
|
|
|
|
aw_fel_execute(usb, sram_info->scratch_addr);
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-19 13:17:50 +03:00
|
|
|
void aw_enable_l2_cache(libusb_device_handle *usb, soc_sram_info *sram_info)
|
2015-02-24 03:54:09 +02:00
|
|
|
{
|
|
|
|
|
uint32_t arm_code[] = {
|
|
|
|
|
htole32(0xee112f30), /* mrc 15, 0, r2, cr1, cr0, {1} */
|
|
|
|
|
htole32(0xe3822002), /* orr r2, r2, #2 */
|
|
|
|
|
htole32(0xee012f30), /* mcr 15, 0, r2, cr1, cr0, {1} */
|
|
|
|
|
htole32(0xe12fff1e), /* bx lr */
|
|
|
|
|
};
|
|
|
|
|
|
2015-08-19 13:17:50 +03:00
|
|
|
aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code));
|
|
|
|
|
aw_fel_execute(usb, sram_info->scratch_addr);
|
2015-02-24 03:54:09 +02:00
|
|
|
}
|
|
|
|
|
|
2015-08-19 13:17:50 +03:00
|
|
|
void aw_get_stackinfo(libusb_device_handle *usb, soc_sram_info *sram_info,
|
|
|
|
|
uint32_t *sp_irq, uint32_t *sp)
|
2015-08-18 22:29:04 +03:00
|
|
|
{
|
|
|
|
|
uint32_t results[2] = { 0 };
|
|
|
|
|
#if 0
|
|
|
|
|
/* Does not work on Cortex-A8 (needs Virtualization Extensions) */
|
|
|
|
|
uint32_t arm_code[] = {
|
|
|
|
|
htole32(0xe1010300), /* mrs r0, SP_irq */
|
|
|
|
|
htole32(0xe58f0004), /* str r0, [pc, #4] */
|
|
|
|
|
htole32(0xe58fd004), /* str sp, [pc, #4] */
|
|
|
|
|
htole32(0xe12fff1e), /* bx lr */
|
|
|
|
|
};
|
|
|
|
|
|
2015-08-19 13:17:50 +03:00
|
|
|
aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code));
|
|
|
|
|
aw_fel_execute(usb, sram_info->scratch_addr);
|
|
|
|
|
aw_fel_read(usb, sram_info->scratch_addr + 0x10, results, 8);
|
2015-08-18 22:29:04 +03:00
|
|
|
#else
|
|
|
|
|
/* Works everywhere */
|
|
|
|
|
uint32_t arm_code[] = {
|
|
|
|
|
htole32(0xe10f0000), /* mrs r0, CPSR */
|
|
|
|
|
htole32(0xe3c0101f), /* bic r1, r0, #31 */
|
|
|
|
|
htole32(0xe3811012), /* orr r1, r1, #18 */
|
|
|
|
|
htole32(0xe121f001), /* msr CPSR_c, r1 */
|
|
|
|
|
htole32(0xe1a0100d), /* mov r1, sp */
|
|
|
|
|
htole32(0xe121f000), /* msr CPSR_c, r0 */
|
|
|
|
|
htole32(0xe58f1004), /* str r1, [pc, #4] */
|
|
|
|
|
htole32(0xe58fd004), /* str sp, [pc, #4] */
|
|
|
|
|
htole32(0xe12fff1e), /* bx lr */
|
|
|
|
|
};
|
|
|
|
|
|
2015-08-19 13:17:50 +03:00
|
|
|
aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code));
|
|
|
|
|
aw_fel_execute(usb, sram_info->scratch_addr);
|
|
|
|
|
aw_fel_read(usb, sram_info->scratch_addr + 0x24, results, 8);
|
2015-08-18 22:29:04 +03:00
|
|
|
#endif
|
|
|
|
|
*sp_irq = le32toh(results[0]);
|
|
|
|
|
*sp = le32toh(results[1]);
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-19 13:17:50 +03:00
|
|
|
uint32_t aw_get_ttbr0(libusb_device_handle *usb, soc_sram_info *sram_info)
|
2015-02-24 02:35:58 +02:00
|
|
|
{
|
2015-11-17 01:08:33 +02:00
|
|
|
return aw_read_arm_cp_reg(usb, sram_info, 15, 0, 2, 0, 0);
|
2015-02-24 02:35:58 +02:00
|
|
|
}
|
|
|
|
|
|
2015-11-17 02:27:56 +02:00
|
|
|
uint32_t aw_get_ttbcr(libusb_device_handle *usb, soc_sram_info *sram_info)
|
|
|
|
|
{
|
|
|
|
|
return aw_read_arm_cp_reg(usb, sram_info, 15, 0, 2, 0, 2);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
uint32_t aw_get_dacr(libusb_device_handle *usb, soc_sram_info *sram_info)
|
|
|
|
|
{
|
|
|
|
|
return aw_read_arm_cp_reg(usb, sram_info, 15, 0, 3, 0, 0);
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-19 13:17:50 +03:00
|
|
|
uint32_t aw_get_sctlr(libusb_device_handle *usb, soc_sram_info *sram_info)
|
2015-02-24 02:35:58 +02:00
|
|
|
{
|
2015-11-17 01:08:33 +02:00
|
|
|
return aw_read_arm_cp_reg(usb, sram_info, 15, 0, 1, 0, 0);
|
2015-02-24 02:35:58 +02:00
|
|
|
}
|
|
|
|
|
|
2015-11-17 02:27:56 +02:00
|
|
|
void aw_set_ttbr0(libusb_device_handle *usb, soc_sram_info *sram_info,
|
|
|
|
|
uint32_t ttbr0)
|
|
|
|
|
{
|
|
|
|
|
return aw_write_arm_cp_reg(usb, sram_info, 15, 0, 2, 0, 0, ttbr0);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void aw_set_ttbcr(libusb_device_handle *usb, soc_sram_info *sram_info,
|
|
|
|
|
uint32_t ttbcr)
|
|
|
|
|
{
|
|
|
|
|
return aw_write_arm_cp_reg(usb, sram_info, 15, 0, 2, 0, 2, ttbcr);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void aw_set_dacr(libusb_device_handle *usb, soc_sram_info *sram_info,
|
|
|
|
|
uint32_t dacr)
|
|
|
|
|
{
|
|
|
|
|
aw_write_arm_cp_reg(usb, sram_info, 15, 0, 3, 0, 0, dacr);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void aw_set_sctlr(libusb_device_handle *usb, soc_sram_info *sram_info,
|
|
|
|
|
uint32_t sctlr)
|
|
|
|
|
{
|
|
|
|
|
aw_write_arm_cp_reg(usb, sram_info, 15, 0, 1, 0, 0, sctlr);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Reconstruct the same MMU translation table as used by the A20 BROM.
|
|
|
|
|
* We are basically reverting the changes, introduced in newer SoC
|
|
|
|
|
* variants. This works fine for the SoC variants with the memory
|
|
|
|
|
* layout similar to A20 (the SRAM is in the first megabyte of the
|
|
|
|
|
* address space and the BROM is in the last megabyte of the address
|
|
|
|
|
* space).
|
|
|
|
|
*/
|
|
|
|
|
uint32_t *aw_generate_mmu_translation_table(void)
|
|
|
|
|
{
|
|
|
|
|
uint32_t *tt = malloc(4096 * sizeof(uint32_t));
|
|
|
|
|
uint32_t i;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Direct mapping using 1MB sections with TEXCB=00000 (Strongly
|
|
|
|
|
* ordered) for all memory except the first and the last sections,
|
|
|
|
|
* which have TEXCB=00100 (Normal). Domain bits are set to 1111
|
|
|
|
|
* and AP bits are set to 11, but this is mostly irrelevant.
|
|
|
|
|
*/
|
|
|
|
|
for (i = 0; i < 4096; i++)
|
|
|
|
|
tt[i] = 0x00000DE2 | (i << 20);
|
|
|
|
|
tt[0x000] |= 0x1000;
|
|
|
|
|
tt[0xFFF] |= 0x1000;
|
|
|
|
|
|
|
|
|
|
return tt;
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-19 13:17:50 +03:00
|
|
|
uint32_t *aw_backup_and_disable_mmu(libusb_device_handle *usb,
|
|
|
|
|
soc_sram_info *sram_info)
|
2015-02-24 02:35:58 +02:00
|
|
|
{
|
2015-08-18 22:34:18 +08:00
|
|
|
uint32_t *tt = NULL;
|
2015-08-19 13:17:50 +03:00
|
|
|
uint32_t ttbr0 = aw_get_ttbr0(usb, sram_info);
|
|
|
|
|
uint32_t sctlr = aw_get_sctlr(usb, sram_info);
|
2015-11-17 02:27:56 +02:00
|
|
|
uint32_t ttbcr = aw_get_ttbcr(usb, sram_info);
|
|
|
|
|
uint32_t dacr = aw_get_dacr(usb, sram_info);
|
2015-02-24 02:35:58 +02:00
|
|
|
uint32_t i;
|
|
|
|
|
|
|
|
|
|
uint32_t arm_code[] = {
|
2015-02-24 03:10:08 +02:00
|
|
|
/* Disable I-cache, MMU and branch prediction */
|
2015-02-24 02:35:58 +02:00
|
|
|
htole32(0xee110f10), /* mrc 15, 0, r0, cr1, cr0, {0} */
|
|
|
|
|
htole32(0xe3c00001), /* bic r0, r0, #1 */
|
2015-02-24 03:10:08 +02:00
|
|
|
htole32(0xe3c00a01), /* bic r0, r0, #4096 */
|
|
|
|
|
htole32(0xe3c00b02), /* bic r0, r0, #2048 */
|
2015-02-24 02:35:58 +02:00
|
|
|
htole32(0xee010f10), /* mcr 15, 0, r0, cr1, cr0, {0} */
|
|
|
|
|
/* Return back to FEL */
|
|
|
|
|
htole32(0xe12fff1e), /* bx lr */
|
|
|
|
|
};
|
|
|
|
|
|
2015-11-17 02:27:56 +02:00
|
|
|
/*
|
|
|
|
|
* Below are some checks for the register values, which are known
|
|
|
|
|
* to be initialized in this particular way by the existing BROM
|
|
|
|
|
* implementations. We don't strictly need them to exactly match,
|
|
|
|
|
* but still have these safety guards in place in order to detect
|
|
|
|
|
* and review any potential configuration changes in future SoC
|
|
|
|
|
* variants (if one of these checks fails, then it is not a serious
|
|
|
|
|
* problem but more likely just an indication that one of these
|
|
|
|
|
* checks needs to be relaxed).
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* Basically, ignore M/Z/I bits and expect no TEX remap */
|
|
|
|
|
if ((sctlr & ~((1 << 12) | (1 << 11) | 1)) != 0x00C52078) {
|
|
|
|
|
fprintf(stderr, "Unexpected SCTLR (%08X)\n", sctlr);
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-24 02:35:58 +02:00
|
|
|
if (!(sctlr & 1)) {
|
2015-08-18 22:34:18 +08:00
|
|
|
pr_info("MMU is not enabled by BROM\n");
|
|
|
|
|
return NULL;
|
2015-02-24 02:35:58 +02:00
|
|
|
}
|
|
|
|
|
|
2015-11-17 02:27:56 +02:00
|
|
|
if (dacr != 0x55555555) {
|
|
|
|
|
fprintf(stderr, "Unexpected DACR (%08X)\n", dacr);
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ttbcr != 0x00000000) {
|
|
|
|
|
fprintf(stderr, "Unexpected TTBCR (%08X)\n", ttbcr);
|
2015-02-24 02:35:58 +02:00
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ttbr0 & 0x3FFF) {
|
|
|
|
|
fprintf(stderr, "Unexpected TTBR0 (%08X)\n", ttbr0);
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-18 22:34:18 +08:00
|
|
|
tt = malloc(16 * 1024);
|
2015-02-24 02:35:58 +02:00
|
|
|
pr_info("Reading the MMU translation table from 0x%08X\n", ttbr0);
|
|
|
|
|
aw_fel_read(usb, ttbr0, tt, 16 * 1024);
|
|
|
|
|
for (i = 0; i < 4096; i++)
|
|
|
|
|
tt[i] = le32toh(tt[i]);
|
|
|
|
|
|
|
|
|
|
/* Basic sanity checks to be sure that this is a valid table */
|
|
|
|
|
for (i = 0; i < 4096; i++) {
|
|
|
|
|
if (((tt[i] >> 1) & 1) != 1 || ((tt[i] >> 18) & 1) != 0) {
|
|
|
|
|
fprintf(stderr, "MMU: not a section descriptor\n");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
if ((tt[i] >> 20) != i) {
|
|
|
|
|
fprintf(stderr, "MMU: not a direct mapping\n");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-24 03:10:08 +02:00
|
|
|
pr_info("Disabling I-cache, MMU and branch prediction...");
|
2015-08-19 13:17:50 +03:00
|
|
|
aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code));
|
|
|
|
|
aw_fel_execute(usb, sram_info->scratch_addr);
|
2015-02-24 02:35:58 +02:00
|
|
|
pr_info(" done.\n");
|
|
|
|
|
|
|
|
|
|
return tt;
|
|
|
|
|
}
|
|
|
|
|
|
2015-08-19 13:17:50 +03:00
|
|
|
void aw_restore_and_enable_mmu(libusb_device_handle *usb,
|
|
|
|
|
soc_sram_info *sram_info,
|
|
|
|
|
uint32_t *tt)
|
2015-02-24 02:35:58 +02:00
|
|
|
{
|
|
|
|
|
uint32_t i;
|
2015-08-19 13:17:50 +03:00
|
|
|
uint32_t ttbr0 = aw_get_ttbr0(usb, sram_info);
|
2015-02-24 02:35:58 +02:00
|
|
|
|
|
|
|
|
uint32_t arm_code[] = {
|
2015-02-24 03:10:08 +02:00
|
|
|
/* Invalidate I-cache, TLB and BTB */
|
|
|
|
|
htole32(0xe3a00000), /* mov r0, #0 */
|
|
|
|
|
htole32(0xee080f17), /* mcr 15, 0, r0, cr8, cr7, {0} */
|
|
|
|
|
htole32(0xee070f15), /* mcr 15, 0, r0, cr7, cr5, {0} */
|
|
|
|
|
htole32(0xee070fd5), /* mcr 15, 0, r0, cr7, cr5, {6} */
|
|
|
|
|
htole32(0xf57ff04f), /* dsb sy */
|
|
|
|
|
htole32(0xf57ff06f), /* isb sy */
|
|
|
|
|
/* Enable I-cache, MMU and branch prediction */
|
2015-02-24 02:35:58 +02:00
|
|
|
htole32(0xee110f10), /* mrc 15, 0, r0, cr1, cr0, {0} */
|
|
|
|
|
htole32(0xe3800001), /* orr r0, r0, #1 */
|
2015-02-24 03:10:08 +02:00
|
|
|
htole32(0xe3800a01), /* orr r0, r0, #4096 */
|
|
|
|
|
htole32(0xe3800b02), /* orr r0, r0, #2048 */
|
2015-02-24 02:35:58 +02:00
|
|
|
htole32(0xee010f10), /* mcr 15, 0, r0, cr1, cr0, {0} */
|
|
|
|
|
/* Return back to FEL */
|
|
|
|
|
htole32(0xe12fff1e), /* bx lr */
|
|
|
|
|
};
|
|
|
|
|
|
2015-02-24 03:10:08 +02:00
|
|
|
pr_info("Setting write-combine mapping for DRAM.\n");
|
|
|
|
|
for (i = (DRAM_BASE >> 20); i < ((DRAM_BASE + DRAM_SIZE) >> 20); i++) {
|
|
|
|
|
/* Clear TEXCB bits */
|
|
|
|
|
tt[i] &= ~((7 << 12) | (1 << 3) | (1 << 2));
|
|
|
|
|
/* Set TEXCB to 00100 (Normal uncached mapping) */
|
|
|
|
|
tt[i] |= (1 << 12);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
pr_info("Setting cached mapping for BROM.\n");
|
|
|
|
|
/* Clear TEXCB bits first */
|
|
|
|
|
tt[0xFFF] &= ~((7 << 12) | (1 << 3) | (1 << 2));
|
|
|
|
|
/* Set TEXCB to 00111 (Normal write-back cached mapping) */
|
|
|
|
|
tt[0xFFF] |= (1 << 12) | /* TEX */
|
|
|
|
|
(1 << 3) | /* C */
|
|
|
|
|
(1 << 2); /* B */
|
|
|
|
|
|
2015-02-24 02:35:58 +02:00
|
|
|
pr_info("Writing back the MMU translation table.\n");
|
|
|
|
|
for (i = 0; i < 4096; i++)
|
|
|
|
|
tt[i] = htole32(tt[i]);
|
|
|
|
|
aw_fel_write(usb, tt, ttbr0, 16 * 1024);
|
|
|
|
|
|
2015-02-24 03:10:08 +02:00
|
|
|
pr_info("Enabling I-cache, MMU and branch prediction...");
|
2015-08-19 13:17:50 +03:00
|
|
|
aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code));
|
|
|
|
|
aw_fel_execute(usb, sram_info->scratch_addr);
|
2015-02-24 02:35:58 +02:00
|
|
|
pr_info(" done.\n");
|
|
|
|
|
|
|
|
|
|
free(tt);
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-15 18:33:38 +02:00
|
|
|
/*
|
|
|
|
|
* Maximum size of SPL, at the same time this is the start offset
|
|
|
|
|
* of the main U-Boot image within u-boot-sunxi-with-spl.bin
|
|
|
|
|
*/
|
2015-08-20 14:24:33 +02:00
|
|
|
#define SPL_LEN_LIMIT 0x8000
|
2015-02-24 02:35:58 +02:00
|
|
|
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
void aw_fel_write_and_execute_spl(libusb_device_handle *usb,
|
|
|
|
|
uint8_t *buf, size_t len)
|
|
|
|
|
{
|
|
|
|
|
soc_sram_info *sram_info = aw_fel_get_sram_info(usb);
|
|
|
|
|
sram_swap_buffers *swap_buffers;
|
|
|
|
|
char header_signature[9] = { 0 };
|
|
|
|
|
size_t i, thunk_size;
|
|
|
|
|
uint32_t *thunk_buf;
|
2015-08-18 22:29:04 +03:00
|
|
|
uint32_t sp, sp_irq;
|
2015-07-15 18:33:38 +02:00
|
|
|
uint32_t spl_checksum, spl_len, spl_len_limit = SPL_LEN_LIMIT;
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
uint32_t *buf32 = (uint32_t *)buf;
|
2015-08-19 14:41:56 +03:00
|
|
|
uint32_t cur_addr = sram_info->spl_addr;
|
2015-02-24 02:35:58 +02:00
|
|
|
uint32_t *tt = NULL;
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
|
|
|
|
|
if (!sram_info || !sram_info->swap_buffers) {
|
|
|
|
|
fprintf(stderr, "SPL: Unsupported SoC type\n");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (len < 32 || memcmp(buf + 4, "eGON.BT0", 8) != 0) {
|
|
|
|
|
fprintf(stderr, "SPL: eGON header is not found\n");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
spl_checksum = 2 * le32toh(buf32[3]) - 0x5F0A6C39;
|
|
|
|
|
spl_len = le32toh(buf32[4]);
|
|
|
|
|
|
|
|
|
|
if (spl_len > len || (spl_len % 4) != 0) {
|
|
|
|
|
fprintf(stderr, "SPL: bad length in the eGON header\n");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
len = spl_len;
|
|
|
|
|
for (i = 0; i < len / 4; i++)
|
|
|
|
|
spl_checksum -= le32toh(buf32[i]);
|
|
|
|
|
|
|
|
|
|
if (spl_checksum != 0) {
|
|
|
|
|
fprintf(stderr, "SPL: checksum check failed\n");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
2015-02-24 03:54:09 +02:00
|
|
|
if (sram_info->needs_l2en) {
|
|
|
|
|
pr_info("Enabling the L2 cache\n");
|
2015-08-19 13:17:50 +03:00
|
|
|
aw_enable_l2_cache(usb, sram_info);
|
2015-02-24 03:54:09 +02:00
|
|
|
}
|
|
|
|
|
|
2015-08-19 13:17:50 +03:00
|
|
|
aw_get_stackinfo(usb, sram_info, &sp_irq, &sp);
|
2015-08-18 22:29:04 +03:00
|
|
|
pr_info("Stack pointers: sp_irq=0x%08X, sp=0x%08X\n", sp_irq, sp);
|
|
|
|
|
|
2015-08-19 13:17:50 +03:00
|
|
|
tt = aw_backup_and_disable_mmu(usb, sram_info);
|
2015-11-17 02:27:56 +02:00
|
|
|
if (!tt && sram_info->mmu_tt_addr) {
|
|
|
|
|
if (sram_info->mmu_tt_addr & 0x3FFF) {
|
|
|
|
|
fprintf(stderr, "SPL: 'mmu_tt_addr' must be 16K aligned\n");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
pr_info("Generating the new MMU translation table at 0x%08X\n",
|
|
|
|
|
sram_info->mmu_tt_addr);
|
|
|
|
|
/*
|
|
|
|
|
* These settings are used by the BROM in A10/A13/A20 and
|
|
|
|
|
* we replicate them here when enabling the MMU. The DACR
|
|
|
|
|
* value 0x55555555 means that accesses are checked against
|
|
|
|
|
* the permission bits in the translation tables for all
|
|
|
|
|
* domains. The TTBCR value 0x00000000 means that the short
|
|
|
|
|
* descriptor translation table format is used, TTBR0 is used
|
|
|
|
|
* for all the possible virtual addresses (N=0) and that the
|
|
|
|
|
* translation table must be aligned at a 16K boundary.
|
|
|
|
|
*/
|
|
|
|
|
aw_set_dacr(usb, sram_info, 0x55555555);
|
|
|
|
|
aw_set_ttbcr(usb, sram_info, 0x00000000);
|
|
|
|
|
aw_set_ttbr0(usb, sram_info, sram_info->mmu_tt_addr);
|
|
|
|
|
tt = aw_generate_mmu_translation_table();
|
|
|
|
|
}
|
2015-02-24 02:35:58 +02:00
|
|
|
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
swap_buffers = sram_info->swap_buffers;
|
|
|
|
|
for (i = 0; swap_buffers[i].size; i++) {
|
2015-08-19 14:41:56 +03:00
|
|
|
if ((swap_buffers[i].buf2 >= sram_info->spl_addr) &&
|
|
|
|
|
(swap_buffers[i].buf2 < sram_info->spl_addr + spl_len_limit))
|
|
|
|
|
spl_len_limit = swap_buffers[i].buf2 - sram_info->spl_addr;
|
|
|
|
|
if (len > 0 && cur_addr < swap_buffers[i].buf1) {
|
|
|
|
|
uint32_t tmp = swap_buffers[i].buf1 - cur_addr;
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
if (tmp > len)
|
|
|
|
|
tmp = len;
|
2015-08-19 14:41:56 +03:00
|
|
|
aw_fel_write(usb, buf, cur_addr, tmp);
|
|
|
|
|
cur_addr += tmp;
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
buf += tmp;
|
|
|
|
|
len -= tmp;
|
|
|
|
|
}
|
2015-08-19 14:41:56 +03:00
|
|
|
if (len > 0 && cur_addr == swap_buffers[i].buf1) {
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
uint32_t tmp = swap_buffers[i].size;
|
|
|
|
|
if (tmp > len)
|
|
|
|
|
tmp = len;
|
|
|
|
|
aw_fel_write(usb, buf, swap_buffers[i].buf2, tmp);
|
2015-08-19 14:41:56 +03:00
|
|
|
cur_addr += tmp;
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
buf += tmp;
|
|
|
|
|
len -= tmp;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Clarify the SPL size limitations, and bail out if they are not met */
|
|
|
|
|
if (sram_info->thunk_addr < spl_len_limit)
|
|
|
|
|
spl_len_limit = sram_info->thunk_addr;
|
|
|
|
|
|
|
|
|
|
if (spl_len > spl_len_limit) {
|
|
|
|
|
fprintf(stderr, "SPL: too large (need %d, have %d)\n",
|
|
|
|
|
(int)spl_len, (int)spl_len_limit);
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Write the remaining part of the SPL */
|
|
|
|
|
if (len > 0)
|
2015-08-19 14:41:56 +03:00
|
|
|
aw_fel_write(usb, buf, cur_addr, len);
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
|
2015-08-19 14:41:56 +03:00
|
|
|
thunk_size = sizeof(fel_to_spl_thunk) + sizeof(sram_info->spl_addr) +
|
|
|
|
|
(i + 1) * sizeof(*swap_buffers);
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
|
|
|
|
|
if (thunk_size > sram_info->thunk_size) {
|
|
|
|
|
fprintf(stderr, "SPL: bad thunk size (need %d, have %d)\n",
|
|
|
|
|
(int)sizeof(fel_to_spl_thunk), sram_info->thunk_size);
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
thunk_buf = malloc(thunk_size);
|
|
|
|
|
memcpy(thunk_buf, fel_to_spl_thunk, sizeof(fel_to_spl_thunk));
|
|
|
|
|
memcpy(thunk_buf + sizeof(fel_to_spl_thunk) / sizeof(uint32_t),
|
2015-08-19 14:41:56 +03:00
|
|
|
&sram_info->spl_addr, sizeof(sram_info->spl_addr));
|
|
|
|
|
memcpy(thunk_buf + sizeof(fel_to_spl_thunk) / sizeof(uint32_t) + 1,
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
swap_buffers, (i + 1) * sizeof(*swap_buffers));
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < thunk_size / sizeof(uint32_t); i++)
|
|
|
|
|
thunk_buf[i] = htole32(thunk_buf[i]);
|
|
|
|
|
|
2015-02-24 02:35:58 +02:00
|
|
|
pr_info("=> Executing the SPL...");
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
aw_fel_write(usb, thunk_buf, sram_info->thunk_addr, thunk_size);
|
|
|
|
|
aw_fel_execute(usb, sram_info->thunk_addr);
|
2015-02-24 02:35:58 +02:00
|
|
|
pr_info(" done.\n");
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
|
|
|
|
|
free(thunk_buf);
|
|
|
|
|
|
|
|
|
|
/* TODO: Try to find and fix the bug, which needs this workaround */
|
|
|
|
|
usleep(250000);
|
|
|
|
|
|
|
|
|
|
/* Read back the result and check if everything was fine */
|
2015-08-19 14:41:56 +03:00
|
|
|
aw_fel_read(usb, sram_info->spl_addr + 4, header_signature, 8);
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
if (strcmp(header_signature, "eGON.FEL") != 0) {
|
|
|
|
|
fprintf(stderr, "SPL: failure code '%s'\n",
|
|
|
|
|
header_signature);
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
2015-02-24 02:35:58 +02:00
|
|
|
|
2015-08-18 22:34:18 +08:00
|
|
|
/* re-enable the MMU if it was enabled by BROM */
|
|
|
|
|
if(tt != NULL)
|
2015-08-19 13:17:50 +03:00
|
|
|
aw_restore_and_enable_mmu(usb, sram_info, tt);
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
}
|
|
|
|
|
|
2015-07-15 18:33:38 +02:00
|
|
|
/*
|
|
|
|
|
* This function tests a given buffer address and length for a valid U-Boot
|
|
|
|
|
* image. Upon success, the image data gets transferred to the default memory
|
|
|
|
|
* address stored within the image header; and the function preserves the
|
|
|
|
|
* U-Boot entry point (offset) and size values.
|
|
|
|
|
*/
|
|
|
|
|
void aw_fel_write_uboot_image(libusb_device_handle *usb,
|
|
|
|
|
uint8_t *buf, size_t len)
|
|
|
|
|
{
|
|
|
|
|
if (len <= HEADER_SIZE)
|
|
|
|
|
return; /* Insufficient size (no actual data), just bail out */
|
|
|
|
|
|
|
|
|
|
uint32_t *buf32 = (uint32_t *)buf;
|
|
|
|
|
|
2015-09-29 16:36:41 +02:00
|
|
|
/* Check for a valid mkimage header */
|
|
|
|
|
int image_type = get_image_type(buf, len);
|
|
|
|
|
if (image_type <= IH_TYPE_INVALID) {
|
|
|
|
|
switch (image_type) {
|
|
|
|
|
case IH_TYPE_INVALID:
|
|
|
|
|
fprintf(stderr, "Invalid U-Boot image: bad size or signature\n");
|
|
|
|
|
break;
|
|
|
|
|
case IH_TYPE_ARCH_MISMATCH:
|
|
|
|
|
fprintf(stderr, "Invalid U-Boot image: wrong architecture\n");
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
fprintf(stderr, "Invalid U-Boot image: error code %d\n",
|
|
|
|
|
image_type);
|
|
|
|
|
}
|
2015-07-15 18:33:38 +02:00
|
|
|
exit(1);
|
|
|
|
|
}
|
2015-09-29 16:36:41 +02:00
|
|
|
if (image_type != IH_TYPE_FIRMWARE) {
|
|
|
|
|
fprintf(stderr, "U-Boot image type mismatch: "
|
|
|
|
|
"expected IH_TYPE_FIRMWARE, got %02X\n", image_type);
|
2015-07-15 18:33:38 +02:00
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
uint32_t data_size = be32toh(buf32[3]); /* Image Data Size */
|
|
|
|
|
uint32_t load_addr = be32toh(buf32[4]); /* Data Load Address */
|
2015-09-29 16:36:41 +02:00
|
|
|
if (data_size != len - HEADER_SIZE) {
|
2015-07-15 18:33:38 +02:00
|
|
|
fprintf(stderr, "U-Boot image data size mismatch: "
|
2015-09-29 16:36:41 +02:00
|
|
|
"expected %zu, got %u\n", len - HEADER_SIZE, data_size);
|
2015-07-15 18:33:38 +02:00
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
/* TODO: Verify image data integrity using the checksum field ih_dcrc,
|
|
|
|
|
* available from be32toh(buf32[6])
|
|
|
|
|
*
|
|
|
|
|
* However, this requires CRC routines that mimic their U-Boot
|
2015-09-09 11:57:46 +02:00
|
|
|
* counterparts, namely image_check_dcrc() in ${U-BOOT}/common/image.c
|
2015-07-15 18:33:38 +02:00
|
|
|
* and crc_wd() in ${U-BOOT}/lib/crc32.c
|
|
|
|
|
*
|
|
|
|
|
* It should be investigated if existing CRC routines in sunxi-tools
|
|
|
|
|
* could be factored out and reused for this purpose - e.g. calc_crc32()
|
|
|
|
|
* from nand-part-main.c
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/* If we get here, we're "good to go" (i.e. actually write the data) */
|
|
|
|
|
pr_info("Writing image \"%.*s\", %u bytes @ 0x%08X.\n",
|
|
|
|
|
IH_NMLEN, buf + HEADER_NAME_OFFSET, data_size, load_addr);
|
|
|
|
|
|
2015-11-13 12:15:45 +01:00
|
|
|
aw_write_buffer(usb, buf + HEADER_SIZE, load_addr, data_size, false);
|
2015-07-15 18:33:38 +02:00
|
|
|
|
|
|
|
|
/* keep track of U-Boot memory region in global vars */
|
|
|
|
|
uboot_entry = load_addr;
|
|
|
|
|
uboot_size = data_size;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* This function handles the common part of both "spl" and "uboot" commands.
|
|
|
|
|
*/
|
|
|
|
|
void aw_fel_process_spl_and_uboot(libusb_device_handle *usb,
|
|
|
|
|
const char *filename)
|
|
|
|
|
{
|
|
|
|
|
/* load file into memory buffer */
|
|
|
|
|
size_t size;
|
|
|
|
|
uint8_t *buf = load_file(filename, &size);
|
|
|
|
|
/* write and execute the SPL from the buffer */
|
|
|
|
|
aw_fel_write_and_execute_spl(usb, buf, size);
|
|
|
|
|
/* check for optional main U-Boot binary (and transfer it, if applicable) */
|
2015-08-20 14:24:33 +02:00
|
|
|
if (size > SPL_LEN_LIMIT)
|
|
|
|
|
aw_fel_write_uboot_image(usb, buf + SPL_LEN_LIMIT, size - SPL_LEN_LIMIT);
|
2015-07-15 18:33:38 +02:00
|
|
|
}
|
|
|
|
|
|
2015-09-29 16:36:43 +02:00
|
|
|
/*
|
|
|
|
|
* Test the SPL header for our "sunxi" variant. We want to make sure that
|
|
|
|
|
* we can safely use specific header fields to pass information to U-Boot.
|
|
|
|
|
* In case of a missing signature (e.g. Allwinner boot0) or header version
|
|
|
|
|
* mismatch, this function will return "false". If all seems fine,
|
|
|
|
|
* the result is "true".
|
|
|
|
|
*/
|
|
|
|
|
#define SPL_SIGNATURE "SPL" /* marks "sunxi" header */
|
|
|
|
|
#define SPL_MIN_VERSION 1 /* minimum required version */
|
|
|
|
|
#define SPL_MAX_VERSION 1 /* maximum supported version */
|
2015-11-19 15:49:55 +01:00
|
|
|
bool have_sunxi_spl(libusb_device_handle *usb, uint32_t spl_addr)
|
2015-09-29 16:36:43 +02:00
|
|
|
{
|
|
|
|
|
uint8_t spl_signature[4];
|
|
|
|
|
|
|
|
|
|
aw_fel_read(usb, spl_addr + 0x14,
|
|
|
|
|
&spl_signature, sizeof(spl_signature));
|
|
|
|
|
|
|
|
|
|
if (memcmp(spl_signature, SPL_SIGNATURE, 3) != 0)
|
2015-11-19 15:49:55 +01:00
|
|
|
return false; /* signature mismatch, no "sunxi" SPL */
|
2015-09-29 16:36:43 +02:00
|
|
|
|
|
|
|
|
if (spl_signature[3] < SPL_MIN_VERSION) {
|
|
|
|
|
fprintf(stderr, "sunxi SPL version mismatch: "
|
|
|
|
|
"found 0x%02X < required minimum 0x%02X\n",
|
|
|
|
|
spl_signature[3], SPL_MIN_VERSION);
|
|
|
|
|
fprintf(stderr, "You need to update your U-Boot (mksunxiboot) to a more recent version.\n");
|
2015-11-19 15:49:55 +01:00
|
|
|
return false;
|
2015-09-29 16:36:43 +02:00
|
|
|
}
|
|
|
|
|
if (spl_signature[3] > SPL_MAX_VERSION) {
|
|
|
|
|
fprintf(stderr, "sunxi SPL version mismatch: "
|
|
|
|
|
"found 0x%02X > maximum supported 0x%02X\n",
|
|
|
|
|
spl_signature[3], SPL_MAX_VERSION);
|
|
|
|
|
fprintf(stderr, "You need a more recent version of this (sunxi-tools) fel utility.\n");
|
2015-11-19 15:49:55 +01:00
|
|
|
return false;
|
2015-09-29 16:36:43 +02:00
|
|
|
}
|
2015-11-19 15:49:55 +01:00
|
|
|
return true; /* sunxi SPL and suitable version */
|
2015-09-29 16:36:43 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Pass information to U-Boot via specialized fields in the SPL header
|
2015-11-19 15:43:14 +01:00
|
|
|
* (see "boot_file_head" in ${U-BOOT}/arch/arm/include/asm/arch-sunxi/spl.h),
|
|
|
|
|
* providing the boot script address (DRAM location of boot.scr).
|
2015-09-29 16:36:43 +02:00
|
|
|
*/
|
|
|
|
|
void pass_fel_information(libusb_device_handle *usb, uint32_t script_address)
|
|
|
|
|
{
|
|
|
|
|
soc_sram_info *sram_info = aw_fel_get_sram_info(usb);
|
|
|
|
|
|
|
|
|
|
/* write something _only_ if we have a suitable SPL header */
|
|
|
|
|
if (have_sunxi_spl(usb, sram_info->spl_addr)) {
|
|
|
|
|
pr_info("Passing boot info via sunxi SPL: script address = 0x%08X\n",
|
|
|
|
|
script_address);
|
|
|
|
|
aw_fel_write(usb, &script_address,
|
|
|
|
|
sram_info->spl_addr + 0x18, sizeof(script_address));
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2014-09-21 23:42:41 +08:00
|
|
|
static int aw_fel_get_endpoint(libusb_device_handle *usb)
|
|
|
|
|
{
|
|
|
|
|
struct libusb_device *dev = libusb_get_device(usb);
|
|
|
|
|
struct libusb_config_descriptor *config;
|
|
|
|
|
int if_idx, set_idx, ep_idx, ret;
|
|
|
|
|
|
|
|
|
|
ret = libusb_get_active_config_descriptor(dev, &config);
|
|
|
|
|
if (ret)
|
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
|
|
for (if_idx = 0; if_idx < config->bNumInterfaces; if_idx++) {
|
|
|
|
|
const struct libusb_interface *iface = config->interface + if_idx;
|
|
|
|
|
|
|
|
|
|
for (set_idx = 0; set_idx < iface->num_altsetting; set_idx++) {
|
|
|
|
|
const struct libusb_interface_descriptor *setting =
|
|
|
|
|
iface->altsetting + set_idx;
|
|
|
|
|
|
|
|
|
|
for (ep_idx = 0; ep_idx < setting->bNumEndpoints; ep_idx++) {
|
|
|
|
|
const struct libusb_endpoint_descriptor *ep =
|
|
|
|
|
setting->endpoint + ep_idx;
|
|
|
|
|
|
|
|
|
|
// Test for bulk transfer endpoint
|
|
|
|
|
if ((ep->bmAttributes & LIBUSB_TRANSFER_TYPE_MASK) !=
|
|
|
|
|
LIBUSB_TRANSFER_TYPE_BULK)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if ((ep->bEndpointAddress & LIBUSB_ENDPOINT_DIR_MASK) ==
|
|
|
|
|
LIBUSB_ENDPOINT_IN)
|
|
|
|
|
AW_USB_FEL_BULK_EP_IN = ep->bEndpointAddress;
|
|
|
|
|
else
|
|
|
|
|
AW_USB_FEL_BULK_EP_OUT = ep->bEndpointAddress;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
libusb_free_config_descriptor(config);
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2015-11-26 15:36:43 +01:00
|
|
|
/* private helper function, gets used for "write*" and "multi*" transfers */
|
|
|
|
|
static unsigned int file_upload(libusb_device_handle *handle, size_t count,
|
|
|
|
|
size_t argc, char **argv, progress_cb_t progress)
|
|
|
|
|
{
|
|
|
|
|
if (argc < count * 2) {
|
|
|
|
|
fprintf(stderr, "error: too few arguments for uploading %zu files\n",
|
|
|
|
|
count);
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* get all file sizes, keeping track of total bytes */
|
|
|
|
|
size_t size = 0;
|
|
|
|
|
unsigned int i;
|
|
|
|
|
for (i = 0; i < count; i++)
|
|
|
|
|
size += file_size(argv[i * 2 + 1]);
|
|
|
|
|
|
|
|
|
|
progress_start(progress, size); // set total size and progress callback
|
|
|
|
|
|
|
|
|
|
/* now transfer each file in turn */
|
|
|
|
|
for (i = 0; i < count; i++) {
|
|
|
|
|
void *buf = load_file(argv[i * 2 + 1], &size);
|
|
|
|
|
if (size > 0) {
|
|
|
|
|
uint32_t offset = strtoul(argv[i * 2], NULL, 0);
|
|
|
|
|
aw_write_buffer(handle, buf, offset, size, true);
|
|
|
|
|
|
|
|
|
|
// If we transferred a script, try to inform U-Boot about its address.
|
|
|
|
|
if (get_image_type(buf, size) == IH_TYPE_SCRIPT)
|
|
|
|
|
pass_fel_information(handle, offset);
|
|
|
|
|
}
|
|
|
|
|
free(buf);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return i; // return number of files that were processed
|
|
|
|
|
}
|
|
|
|
|
|
2012-06-15 22:45:18 +02:00
|
|
|
int main(int argc, char **argv)
|
|
|
|
|
{
|
2015-12-16 11:25:46 +01:00
|
|
|
bool uboot_autostart = false; /* flag for "uboot" command = U-Boot autostart */
|
2015-11-13 13:10:46 +01:00
|
|
|
bool pflag_active = false; /* -p switch, causing "write" to output progress */
|
2012-06-15 22:45:18 +02:00
|
|
|
int rc;
|
|
|
|
|
libusb_device_handle *handle = NULL;
|
2013-05-19 11:55:17 +02:00
|
|
|
int iface_detached = -1;
|
2012-06-15 22:45:18 +02:00
|
|
|
rc = libusb_init(NULL);
|
|
|
|
|
assert(rc == 0);
|
|
|
|
|
|
|
|
|
|
if (argc <= 1) {
|
2015-02-23 11:37:00 +02:00
|
|
|
printf("Usage: %s [options] command arguments... [command...]\n"
|
|
|
|
|
" -v, --verbose Verbose logging\n"
|
2015-11-13 13:10:46 +01:00
|
|
|
" -p, --progress \"write\" transfers show a progress bar\n"
|
2015-07-15 18:33:38 +02:00
|
|
|
"\n"
|
|
|
|
|
" spl file Load and execute U-Boot SPL\n"
|
|
|
|
|
" If file additionally contains a main U-Boot binary\n"
|
|
|
|
|
" (u-boot-sunxi-with-spl.bin), this command also transfers that\n"
|
|
|
|
|
" to memory (default address from image), but won't execute it.\n"
|
|
|
|
|
"\n"
|
|
|
|
|
" uboot file-with-spl like \"spl\", but actually starts U-Boot\n"
|
|
|
|
|
" U-Boot execution will take place when the fel utility exits.\n"
|
|
|
|
|
" This allows combining \"uboot\" with further \"write\" commands\n"
|
|
|
|
|
" (to transfer other files needed for the boot).\n"
|
|
|
|
|
"\n"
|
2012-06-15 22:45:18 +02:00
|
|
|
" hex[dump] address length Dumps memory region in hex\n"
|
|
|
|
|
" dump address length Binary memory dump\n"
|
|
|
|
|
" exe[cute] address Call function address\n"
|
2012-09-04 21:08:10 +02:00
|
|
|
" read address length file Write memory contents into file\n"
|
2012-06-15 22:45:18 +02:00
|
|
|
" write address file Store file contents into memory\n"
|
2015-11-26 16:16:58 +01:00
|
|
|
" write-with-progress addr file \"write\" with progress bar\n"
|
2015-11-26 16:46:01 +01:00
|
|
|
" write-with-gauge addr file Output progress for \"dialog --gauge\"\n"
|
|
|
|
|
" write-with-xgauge addr file Extended gauge output (updates prompt)\n"
|
2015-11-26 16:16:58 +01:00
|
|
|
" multi[write] # addr file ... \"write-with-progress\" multiple files,\n"
|
|
|
|
|
" sharing a common progress status\n"
|
2015-11-26 16:46:01 +01:00
|
|
|
" multi[write]-with-gauge ... like their \"write-with-*\" counterpart,\n"
|
|
|
|
|
" multi[write]-with-xgauge ... but following the 'multi' syntax:\n"
|
|
|
|
|
" <#> addr file [addr file [...]]\n"
|
2015-11-27 15:13:48 +01:00
|
|
|
" echo-gauge \"some text\" Update prompt/caption for gauge output\n"
|
2012-06-15 22:45:18 +02:00
|
|
|
" ver[sion] Show BROM version\n"
|
|
|
|
|
" clear address length Clear memory\n"
|
2012-06-16 00:57:22 +02:00
|
|
|
" fill address length value Fill memory\n"
|
2012-06-15 22:45:18 +02:00
|
|
|
, argv[0]
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
handle = libusb_open_device_with_vid_pid(NULL, 0x1f3a, 0xefe8);
|
|
|
|
|
if (!handle) {
|
2013-09-06 22:22:51 +02:00
|
|
|
switch (errno) {
|
|
|
|
|
case EACCES:
|
|
|
|
|
fprintf(stderr, "ERROR: You don't have permission to access Allwinner USB FEL device\n");
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
fprintf(stderr, "ERROR: Allwinner USB FEL device not found!\n");
|
|
|
|
|
break;
|
|
|
|
|
}
|
2012-06-15 22:45:18 +02:00
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
rc = libusb_claim_interface(handle, 0);
|
2013-05-19 11:55:17 +02:00
|
|
|
#if defined(__linux__)
|
|
|
|
|
if (rc != LIBUSB_SUCCESS) {
|
|
|
|
|
libusb_detach_kernel_driver(handle, 0);
|
|
|
|
|
iface_detached = 0;
|
|
|
|
|
rc = libusb_claim_interface(handle, 0);
|
|
|
|
|
}
|
|
|
|
|
#endif
|
2012-06-15 22:45:18 +02:00
|
|
|
assert(rc == 0);
|
|
|
|
|
|
2014-09-21 23:42:41 +08:00
|
|
|
if (aw_fel_get_endpoint(handle)) {
|
|
|
|
|
fprintf(stderr, "ERROR: Failed to get FEL mode endpoint addresses!\n");
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
|
2015-12-16 12:15:47 +01:00
|
|
|
/* process all "prefix"-type arguments first */
|
|
|
|
|
while (argc > 1) {
|
|
|
|
|
if (strcmp(argv[1], "--verbose") == 0 || strcmp(argv[1], "-v") == 0)
|
|
|
|
|
verbose = true;
|
|
|
|
|
else if (strcmp(argv[1], "--progress") == 0 || strcmp(argv[1], "-p") == 0)
|
|
|
|
|
pflag_active = true;
|
|
|
|
|
else
|
|
|
|
|
break; /* no valid (prefix) option detected, exit loop */
|
2015-02-23 11:37:00 +02:00
|
|
|
argc -= 1;
|
|
|
|
|
argv += 1;
|
|
|
|
|
}
|
|
|
|
|
|
2012-06-15 22:45:18 +02:00
|
|
|
while (argc > 1 ) {
|
|
|
|
|
int skip = 1;
|
2015-11-13 13:10:46 +01:00
|
|
|
|
2015-12-16 12:15:47 +01:00
|
|
|
if (strncmp(argv[1], "hex", 3) == 0 && argc > 3) {
|
2012-06-15 22:45:18 +02:00
|
|
|
aw_fel_hexdump(handle, strtoul(argv[2], NULL, 0), strtoul(argv[3], NULL, 0));
|
|
|
|
|
skip = 3;
|
|
|
|
|
} else if (strncmp(argv[1], "dump", 4) == 0 && argc > 3) {
|
|
|
|
|
aw_fel_dump(handle, strtoul(argv[2], NULL, 0), strtoul(argv[3], NULL, 0));
|
|
|
|
|
skip = 3;
|
2015-12-16 12:15:47 +01:00
|
|
|
} else if (strncmp(argv[1], "exe", 3) == 0 && argc > 2) {
|
2012-06-15 22:45:18 +02:00
|
|
|
aw_fel_execute(handle, strtoul(argv[2], NULL, 0));
|
|
|
|
|
skip=3;
|
|
|
|
|
} else if (strncmp(argv[1], "ver", 3) == 0 && argc > 1) {
|
2015-02-06 22:26:33 +02:00
|
|
|
aw_fel_print_version(handle);
|
2012-06-15 22:45:18 +02:00
|
|
|
skip=1;
|
|
|
|
|
} else if (strcmp(argv[1], "write") == 0 && argc > 3) {
|
2015-11-26 15:36:43 +01:00
|
|
|
skip += 2 * file_upload(handle, 1, argc - 2, argv + 2,
|
|
|
|
|
pflag_active ? progress_bar : NULL);
|
2015-11-26 16:16:58 +01:00
|
|
|
} else if (strcmp(argv[1], "write-with-progress") == 0 && argc > 3) {
|
|
|
|
|
skip += 2 * file_upload(handle, 1, argc - 2, argv + 2,
|
|
|
|
|
progress_bar);
|
2015-11-26 16:46:01 +01:00
|
|
|
} else if (strcmp(argv[1], "write-with-gauge") == 0 && argc > 3) {
|
|
|
|
|
skip += 2 * file_upload(handle, 1, argc - 2, argv + 2,
|
|
|
|
|
progress_gauge);
|
|
|
|
|
} else if (strcmp(argv[1], "write-with-xgauge") == 0 && argc > 3) {
|
|
|
|
|
skip += 2 * file_upload(handle, 1, argc - 2, argv + 2,
|
|
|
|
|
progress_gauge_xxx);
|
2015-11-26 16:16:58 +01:00
|
|
|
} else if ((strcmp(argv[1], "multiwrite") == 0 ||
|
|
|
|
|
strcmp(argv[1], "multi") == 0) && argc > 4) {
|
|
|
|
|
size_t count = strtoul(argv[2], NULL, 0); /* file count */
|
|
|
|
|
skip = 2 + 2 * file_upload(handle, count, argc - 3,
|
|
|
|
|
argv + 3, progress_bar);
|
2015-11-26 16:46:01 +01:00
|
|
|
} else if ((strcmp(argv[1], "multiwrite-with-gauge") == 0 ||
|
|
|
|
|
strcmp(argv[1], "multi-with-gauge") == 0) && argc > 4) {
|
|
|
|
|
size_t count = strtoul(argv[2], NULL, 0); /* file count */
|
|
|
|
|
skip = 2 + 2 * file_upload(handle, count, argc - 3,
|
|
|
|
|
argv + 3, progress_gauge);
|
|
|
|
|
} else if ((strcmp(argv[1], "multiwrite-with-xgauge") == 0 ||
|
|
|
|
|
strcmp(argv[1], "multi-with-xgauge") == 0) && argc > 4) {
|
|
|
|
|
size_t count = strtoul(argv[2], NULL, 0); /* file count */
|
|
|
|
|
skip = 2 + 2 * file_upload(handle, count, argc - 3,
|
|
|
|
|
argv + 3, progress_gauge_xxx);
|
2015-11-27 15:13:48 +01:00
|
|
|
} else if ((strcmp(argv[1], "echo-gauge") == 0) && argc > 2) {
|
|
|
|
|
skip = 2;
|
|
|
|
|
printf("XXX\n0\n%s\nXXX\n", argv[2]);
|
|
|
|
|
fflush(stdout);
|
2012-09-04 21:08:10 +02:00
|
|
|
} else if (strcmp(argv[1], "read") == 0 && argc > 4) {
|
|
|
|
|
size_t size = strtoul(argv[3], NULL, 0);
|
|
|
|
|
void *buf = malloc(size);
|
|
|
|
|
aw_fel_read(handle, strtoul(argv[2], NULL, 0), buf, size);
|
|
|
|
|
save_file(argv[4], buf, size);
|
|
|
|
|
free(buf);
|
|
|
|
|
skip=4;
|
2012-06-15 22:45:18 +02:00
|
|
|
} else if (strcmp(argv[1], "clear") == 0 && argc > 2) {
|
2012-06-16 00:57:22 +02:00
|
|
|
aw_fel_fill(handle, strtoul(argv[2], NULL, 0), strtoul(argv[3], NULL, 0), 0);
|
2012-06-15 22:45:18 +02:00
|
|
|
skip=3;
|
2012-06-16 00:57:22 +02:00
|
|
|
} else if (strcmp(argv[1], "fill") == 0 && argc > 3) {
|
|
|
|
|
aw_fel_fill(handle, strtoul(argv[2], NULL, 0), strtoul(argv[3], NULL, 0), (unsigned char)strtoul(argv[4], NULL, 0));
|
|
|
|
|
skip=4;
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
} else if (strcmp(argv[1], "spl") == 0 && argc > 2) {
|
2015-07-15 18:33:38 +02:00
|
|
|
aw_fel_process_spl_and_uboot(handle, argv[2]);
|
|
|
|
|
skip=2;
|
|
|
|
|
} else if (strcmp(argv[1], "uboot") == 0 && argc > 2) {
|
|
|
|
|
aw_fel_process_spl_and_uboot(handle, argv[2]);
|
2015-12-16 11:25:46 +01:00
|
|
|
uboot_autostart = (uboot_entry > 0 && uboot_size > 0);
|
|
|
|
|
if (!uboot_autostart)
|
2015-07-15 18:33:38 +02:00
|
|
|
printf("Warning: \"uboot\" command failed to detect image! Can't execute U-Boot.\n");
|
fel: New command for loading U-Boot SPL binaries in eGON format
Now it is possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. Just a different delivery
method (a USB OTG cable instead of an SD card) for handling
exactly the same content.
The only argument for this new command is the name of the SPL
binary file (with a eGON header generated by the 'mksunxiboot'
tool). Now the 'fel' tool can be run as:
fel spl u-boot-sunxi-with-spl.bin
Before this change, the SPL was only able to use the memory between
addresses 0x2000 and ~0x5D00, totalling to something like ~15 KiB.
This is the biggest contiguous area in SRAM, which is not used
by the FEL code from the BROM. Unfortunately, it is rather small.
And also the unusual starting offset was making it difficult to
use the same SPL binary for booting from the SD card and via FEL.
There are surely more unused parts of SRAM, but they are scattered
across multiple locations, primarily because the FEL code from the
BROM sets up two stacks at inconvenient locations (the IRQ handler
stack at 0x2000, and a regular stack at 0x7000). Essentially, the
problem to solve here is to ensure a sufficiently large and consistent
SRAM address space for the SPL without any potentially SoC specific
holes in the case of booting over USB via FEL.
This is achieved by injecting special entry/exit thunk code, which
is moving the data in SRAM to provide a contiguous space for the SPL
at the beginning of SRAM, while still preserving the the data from
the BROM elsewhere. When the SPL tries to return control back to the
FEL code in the BROM, the thunk code moves the data back to its
original place. Additionally, the eGON checksum is verified to
ensure that no data corruption has happened due to some unexpected
clash with the FEL protocol code from the BROM.
So the thunk code takes care of the address space allocation uglyness
and provides the U-Boot SPL with a somewhat nicer abstraction.
Now the FEL booted SPL on A10/A13/A20/A31 can use up to 32 KiB of
SRAM because the BROM data is saved to different SRAM section.
There is also generic code, which does not rely on extra SRAM
sections, but just glues together the unused free space from
both BROM FEL stacks to provide something like ~21 KiB to the SPL.
Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
2015-02-06 23:19:12 +02:00
|
|
|
skip=2;
|
2012-06-15 22:45:18 +02:00
|
|
|
} else {
|
|
|
|
|
fprintf(stderr,"Invalid command %s\n", argv[1]);
|
|
|
|
|
exit(1);
|
|
|
|
|
}
|
|
|
|
|
argc-=skip;
|
|
|
|
|
argv+=skip;
|
|
|
|
|
}
|
|
|
|
|
|
2015-07-15 18:33:38 +02:00
|
|
|
// auto-start U-Boot if requested (by the "uboot" command)
|
2015-12-16 11:25:46 +01:00
|
|
|
if (uboot_autostart) {
|
2015-07-15 18:33:38 +02:00
|
|
|
pr_info("Starting U-Boot (0x%08X).\n", uboot_entry);
|
|
|
|
|
aw_fel_execute(handle, uboot_entry);
|
|
|
|
|
}
|
|
|
|
|
|
2013-05-19 11:55:17 +02:00
|
|
|
#if defined(__linux__)
|
|
|
|
|
if (iface_detached >= 0)
|
|
|
|
|
libusb_attach_kernel_driver(handle, iface_detached);
|
|
|
|
|
#endif
|
|
|
|
|
|
2012-06-15 22:45:18 +02:00
|
|
|
return 0;
|
|
|
|
|
}
|