[U-Boot] [PATCH v3 1/4] usb/gadget: fastboot: add sparse image definitions

[Marek Vasut]

On Thursday, July 31, 2014 at 07:32:51 PM, Steve Rae wrote:
> On 14-07-30 06:25 PM, Marek Vasut wrote:
> > On Thursday, June 26, 2014 at 10:13:21 PM, Steve Rae wrote:
> >> - to prepare for the support of fastboot sparse images
> >> 
> >> Signed-off-by: Steve Rae <srae at broadcom.com>
> >> ---
> >> This file is ASIS from:
> >> 
> >> https://raw.githubusercontent.com/AOSB/android_system_core/master/libspa
> >> rs e/sparse_format.h (commit 28fa5bc347390480fe190294c6c385b6a9f0d68b)
> >> except for the __UBOOT__ conditional include.
> >> 
> >> Changes in v3: None
> >> Changes in v2: None
> >> 
> >>   include/sparse_format.h | 58
> >> 
> >> +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58
> >> 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 0000000..21fbd05
> >> --- /dev/null
> >> +++ b/include/sparse_format.h
> >> @@ -0,0 +1,58 @@
> >> +/*
> >> + * Copyright (C) 2010 The Android Open Source Project
> >> + *
> >> + * Licensed under the Apache License, Version 2.0 (the "License");
> >> + * you may not use this file except in compliance with the License.
> >> + * You may obtain a copy of the License at
> >> + *
> >> + *      http://www.apache.org/licenses/LICENSE-2.0
> >> + *
> >> + * Unless required by applicable law or agreed to in writing, software
> >> + * distributed under the License is distributed on an "AS IS" BASIS,
> >> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> >> implied. + * See the License for the specific language governing
> >> permissions and + * limitations under the License.
> > 
> > Please use the SPDX licence identifiers (pelase see Licenses/README)?
> > 
> >> + */
> >> +
> >> +#ifndef _LIBSPARSE_SPARSE_FORMAT_H_
> >> +#define _LIBSPARSE_SPARSE_FORMAT_H_
> >> +#define __UBOOT__
> >> +#ifndef __UBOOT__
> >> +#include "sparse_defs.h"
> >> +#endif
> >> +
> >> +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_MAGIC	0xed26ff3a
> >> +
> >> +#define CHUNK_TYPE_RAW		0xCAC1
> >> +#define CHUNK_TYPE_FILL		0xCAC2
> >> +#define CHUNK_TYPE_DONT_CARE	0xCAC3
> >> +#define CHUNK_TYPE_CRC32    0xCAC4
> >> +
> >> +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.
> > 
> > The comment here is not aligned with coding style, I'll leave fixing it
> > up to you, since the license header text needs revisiting.
> > 
> >> + *  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
> 
> To clarify:
> I am taking this file ASIS from the location stated in the commit
> message....
> Do we _really_ want to modify _anything_ in this file (especially when
> the content is not changing); or do we want to leaving it pristine?

I'd prefer consistency with the rest of the codebase. Let's wait what others 
think.