Re: [U-Boot] Fastboot behaviour with sparse images
On Monday, October 12, 2015 at 6:43:37 AM UTC-7, Maxime Ripard wrote: > > Hi, > > I'm currently writing the support in U-Boot for NAND-backed devices > using fastboot [1], and that work derived a bit to supporting the > sparse images. > > For "regular" images that are being stored, we expect a pair of > download and flash commands. Simple. > > Things start to get a bit more complex with sparse images that have > been split because of a max-download-size lower than the actual image > size. > > Here, from what I could gather from various random blog posts, the > fastboot client implementation and dumping a few USB sessions, the > client simply creates several download / flash pairs, always on the > same partition, without any way to distinct that from several > subsequent writes issued by the user. > > So, I'm guessing that the expectation is that the bootloader > implementation should store the last offset it wrote to, and simple > resume from there if the partition names in the flash commands are the > same, which would prevent two subsequent write on the same partition > by any client. Am I right? > No, each blob passed to the bootloader will begin with a sparse "skip" chunk that will seek to the correct place to resume writing. The bootloader shouldn't need to store any metadata across commands. Just read in the blob from the data command, then write it out using a port of the Apache-licensed libsparse during the flash command. > A related question is when should we erase the NAND partition? Only > when doing fastboot erase, or also when doing fastboot write (which, > combined with the issue raised above, would also mean that we don't > want to do an erase on the whole partition everytime there's a flash > command on it). Fastboot should send an erase command before every sequence of writes. Erase the whole partition on the erase command, and don't erase anything on the flash command. > > Thanks! > Maxime > > 1: http://lists.denx.de/pipermail/u-boot/2015-August/226053.html > > -- > Maxime Ripard, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] add header for Android sparse image format
Add a BSD-3 relicensed version of the Android sparse format image
header from:
https://android.googlesource.com/platform/system/core/+/28fa5bc347390480fe190294c6c385b6a9f0d68b/libsparse/sparse_format.h
Unchanged except for the license header.
Cc: Tom Rini tr...@ti.com
Signed-off-by: Colin Cross ccr...@android.com
---
include/sparse_format.h | 49 +
1 file changed, 49 insertions(+)
create mode 100644 include/sparse_format.h
diff --git a/include/sparse_format.h b/include/sparse_format.h
new file mode 100644
index 000..af67581
--- /dev/null
+++ b/include/sparse_format.h
@@ -0,0 +1,49 @@
+/*
+ * This is from the Android Project,
+ * Repository: https://android.googlesource.com/platform/system/core
+ * File: libsparse/sparse_format.h
+ * Commit: 28fa5bc347390480fe190294c6c385b6a9f0d68b
+ * Copyright (C) 2010 The Android Open Source Project
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef _LIBSPARSE_SPARSE_FORMAT_H_
+#define _LIBSPARSE_SPARSE_FORMAT_H_
+#include sparse_defs.h
+
+typedef struct sparse_header {
+ __le32 magic; /* 0xed26ff3a */
+ __le16 major_version; /* (0x1) - reject images with higher major
versions */
+ __le16 minor_version; /* (0x0) - allow images with higer minor
versions */
+ __le16 file_hdr_sz;/* 28 bytes for first revision of the file
format */
+ __le16 chunk_hdr_sz; /* 12 bytes for first revision of the file
format */
+ __le32 blk_sz; /* block size in bytes, must be a multiple of 4
(4096) */
+ __le32 total_blks; /* total blocks in the non-sparse output image
*/
+ __le32 total_chunks; /* total chunks in the sparse input image */
+ __le32 image_checksum; /* CRC32 checksum of the original data,
counting don't care */
+ /* as 0. Standard 802.3 polynomial, use a
Public Domain */
+ /* table implementation */
+} sparse_header_t;
+
+#define SPARSE_HEADER_MAGIC0xed26ff3a
+
+#define CHUNK_TYPE_RAW 0xCAC1
+#define CHUNK_TYPE_FILL0xCAC2
+#define CHUNK_TYPE_DONT_CARE 0xCAC3
+#define CHUNK_TYPE_CRC320xCAC4
+
+typedef struct chunk_header {
+ __le16 chunk_type; /* 0xCAC1 - raw; 0xCAC2 - fill; 0xCAC3 -
don't care */
+ __le16 reserved1;
+ __le32 chunk_sz; /* in blocks in output image */
+ __le32 total_sz; /* in bytes of chunk input file including chunk
header and data */
+} chunk_header_t;
+
+/* Following a Raw or Fill or CRC32 chunk is data.
+ * For a Raw chunk, it's the data in chunk_sz * blk_sz.
+ * For a Fill chunk, it's 4 bytes of the fill data.
+ * For a CRC32 chunk, it's 4 bytes of CRC32
+ */
+
+#endif
--
2.1.0.rc2.206.gedb03e5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
On Tue, Jan 24, 2012 at 2:08 PM, Stephen Warren swar...@nvidia.com wrote:
Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM:
What about the peripheral resets which are also handled by CAR? Peripheral
clock nodes also offer assert and deassert methods for the reset signal
associated with them. Those methods are used when powergating domains for
example. Should we model this in the same binding?
In most cases, I think the resets are handled purely within clock enable
and disable, so there's no need to explicitly manage them or represent
them in the device tree. Do you agree here?
clk_enable could force a deasserted reset, but clk_disable cannot
imply asserting reset. The clocks need to be turned off for power
management without resetting the registers.
I recall that you mentioned some power-management code might need to
manage reset separately though. Can you explain why a module would be
reset separately from disabling the clocks though?
The TRM lists a very specific sequence of clocks, resets, clamps, and
power for power domain gating. Other than that, I think the only use
for directly calling reset that ended up in the Android Tegra2 tree
was for error recovery on HW blocks that could get locked up, probably
I2C.
If we do need this, I think we can just add a property to the node of
each device that needs such explicit management. Something like:
tegra_car: clock@60006000 {
compatible = nvidia,tegra20-car;
};
foo@70007000 {
compatible = nvidia,tegra20-foo;
regs = ...;
nvidia,car-reset-id = tegra_car 30;
};
And the driver for foo can ignore cell 0, and extract the cell 1 and
pass the value to tegra_periph_reset_assert().
I'd expect to put the CAR phandle into the property in case we ever get
a more generalized reset subsystem, and need more general code to
interpret the property. I did the same for the Tegra APB DMA controller
client binding where clients need to know the DMA select value.
Does that all seem reasonable?
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding
On Tue, Jan 24, 2012 at 2:43 PM, Stephen Warren swar...@nvidia.com wrote: Colin Cross wrote at Tuesday, January 24, 2012 3:33 PM: On Tue, Jan 24, 2012 at 2:08 PM, Stephen Warren swar...@nvidia.com wrote: Peter De Schrijver wrote at Tuesday, January 24, 2012 2:53 AM: What about the peripheral resets which are also handled by CAR? Peripheral clock nodes also offer assert and deassert methods for the reset signal associated with them. Those methods are used when powergating domains for example. Should we model this in the same binding? In most cases, I think the resets are handled purely within clock enable and disable, so there's no need to explicitly manage them or represent them in the device tree. Do you agree here? clk_enable could force a deasserted reset, but clk_disable cannot imply asserting reset. The clocks need to be turned off for power management without resetting the registers. Yes, I just spoke to someone off-list, and he said the same thing. He went on to say that therefore even the reset removal with clk_enable was questionable, and that drivers should explicitly manage reset removal themselves. Does that seem a reasonable stance? It'd certainly take away the somewhat asymmetric nature of reset removal just magically working when you first enable the clocks. We'd presumably then want a common reset infra-structure and binding to match that change? In 99% of drivers reset is irrelevant, as long as the block is out of reset by the time the driver starts writing to registers. clk_enable is a decent place to ensure that - it always has to be done before writing to the registers, and it maps nicely to the reset bits on Tegra. It would be nice if those driver didn't need to deassert reset explicitly, especially if that requires a Tegra-specific API. (I know that'd make Simon happy, since then we'd be able to represent the reset IDs directly everywhere, unrelated to the clock IDs, and hence he could just use the reset IDs directly in the U-Boot code he's writing and ignore the non 1:1 mapping between clock and reset IDs) I recall that you mentioned some power-management code might need to manage reset separately though. Can you explain why a module would be reset separately from disabling the clocks though? The TRM lists a very specific sequence of clocks, resets, clamps, and power for power domain gating. Other than that, I think the only use for directly calling reset that ended up in the Android Tegra2 tree was for error recovery on HW blocks that could get locked up, probably I2C. OK, those reasons make sense. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
