Hi, If anyone wonders, that's a sunxi-tools patch. To avoid confusion in the future, it's best to have this information in the subject line.
On Tue, 4 Aug 2015 01:26:43 +0200 Bernhard Nortmann <[email protected]> wrote: > Signed-off-by: Bernhard Nortmann <[email protected]> > --- > fel.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/fel.c b/fel.c > index 41b19c9..bbaeec9 100644 > --- a/fel.c > +++ b/fel.c > @@ -215,8 +215,7 @@ void aw_fel_write(libusb_device_handle *usb, void *buf, > uint32_t offset, size_t > 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 + (int)len, > - uboot_entry, uboot_entry + uboot_size); > + offset, offset + len, uboot_entry, uboot_entry + > uboot_size); > exit(1); > } > aw_send_fel_request(usb, AW_FEL_1_WRITE, offset, len); > @@ -752,9 +751,11 @@ void aw_fel_write_and_execute_spl(libusb_device_handle > *usb, > * 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. > + * Note that for small files (SPL only, less than SPL_LEN_LIMIT bytes), > + * len < 0 may be passed to this function; meaning there is no U-Boot image. > */ Maybe it would be better to rework this code in order not assign a special magical meaning of the negative 'len' value? Either by passing the file name instead of the buffer pointer and buffer len pair to the 'aw_fel_write_uboot_image' function. Or by doing the check for missing u-boot part outside of the 'aw_fel_write_uboot_image'. In the former case, we can also support fel booting via extracting U-Boot from the SD card images (by checking the eGON signature both in the beginning of the file and at a certain offset). And because SD card images tend to be rather large (up to several gigabytes), reading the whole file to RAM is not a very good idea. > void aw_fel_write_uboot_image(libusb_device_handle *usb, > - uint8_t *buf, size_t len) > + uint8_t *buf, int len) > { > if (len <= HEADER_SIZE) > return; /* Insufficient size (no actual data), just bail out */ If the user uses the 'uboot' command with improper file (without the u-boot part), then he/she should probably see a descriptive error message. > @@ -774,17 +775,16 @@ void aw_fel_write_uboot_image(libusb_device_handle *usb, > } > uint32_t data_size = be32toh(buf32[3]); /* Image Data Size */ > uint32_t load_addr = be32toh(buf32[4]); /* Data Load Address */ > - if ((size_t)data_size != len - HEADER_SIZE) { > + if ((int)data_size != len - HEADER_SIZE) { > fprintf(stderr, "U-Boot image data size mismatch: " > - "expected %d, got %u\n", (int)len - HEADER_SIZE, > - data_size); > + "expected %d, got %u\n", len - HEADER_SIZE, data_size); > 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 > - * counterparts, namely image_check_dcrc() in > ${U-BOOT}/common/image.cabs > + * counterparts, namely image_check_dcrc() in ${U-BOOT}/common/image.c > * and crc_wd() in ${U-BOOT}/lib/crc32.c > * > * It should be investigated if existing CRC routines in sunxi-tools -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
