Re: [U-Boot] [PATCH] binman: ensure temp filenames don't collide
On 07/19/2018 08:17 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 19 July 2018 at 15:14, Stephen Warren wrote:
>> On 07/18/2018 07:32 PM, Simon Glass wrote:
>>> Hi Stephen,
>>>
>>> On 16 July 2018 at 16:51, Stephen Warren wrote:
From: Stephen Warren
The U-Boot Makefile can invoke binman multiple times in parallel. This
is problematic because binman uses a static hard-coded temporary file
name. If two instances of binman use that filename at the same time, one
writing one reading, they may silently read the wrong content or actively
detect missing signatures and error out the build process. Fix this by
using a PID-specific filename instead.
Signed-off-by: Stephen Warren
---
tools/binman/control.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/binman/control.py b/tools/binman/control.py
index a40b300fdacb..515999278949 100644
--- a/tools/binman/control.py
+++ b/tools/binman/control.py
@@ -121,7 +121,7 @@ def Binman(options, args):
# output into a file in our output directly. Then scan it for
use
# in binman.
dtb_fname = fdt_util.EnsureCompiled(dtb_fname)
-fname = tools.GetOutputFilename('u-boot-out.dtb')
+fname = tools.GetOutputFilename('u-boot-out.dtb') +
str(os.getpid())
with open(dtb_fname) as infd:
with open(fname, 'wb') as outfd:
outfd.write(infd.read())
--
2.18.0
>>>
>>> But the output directory is itself (normally) a temporary dir. That
>>> determines the directly which GetOutputFilename() uses. So I am not
>>> sure how this can happen in practice?
>>
>> IIRC, the output directory for all 3 files was the same; the root of the
>> build output directory. Perhaps the fact I run "make O=build-xxx" rather
>> than just "make" makes a difference?
>
> Yes you are right - the -O flag sets the output directory and it
> no-longer uses a temporary directory.
>
> But if we add a PID to every filename then we end up with multiple
> output files and we don't know which is right.
>
> I think the correct fix is to change the Makefile to only run binman
> once. It makes no sense to run it multiple times.
IIRC, this filename is just a temp file that eventually gets removed
after binman runs. Certainly there are not *.${pid} files left around
after the build has completed.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 11/17] fs: add mkdir interface
"mkdir" interface is added to file operations.
This is a preparatory change as mkdir support for FAT file system
will be added in next patch.
Signed-off-by: AKASHI Takahiro
---
fs/fs.c | 45 +
include/fs.h | 10 ++
2 files changed, 55 insertions(+)
diff --git a/fs/fs.c b/fs/fs.c
index 33808d549e..3cb6b21fe9 100644
--- a/fs/fs.c
+++ b/fs/fs.c
@@ -105,6 +105,11 @@ static inline int fs_opendir_unsupported(const char
*filename,
return -EACCES;
}
+static inline int fs_mkdir_unsupported(const char *dirname)
+{
+ return -1;
+}
+
struct fstype_info {
int fstype;
char *name;
@@ -142,6 +147,7 @@ struct fstype_info {
int (*readdir)(struct fs_dir_stream *dirs, struct fs_dirent **dentp);
/* see fs_closedir() */
void (*closedir)(struct fs_dir_stream *dirs);
+ int (*mkdir)(const char *dirname);
};
static struct fstype_info fstypes[] = {
@@ -165,6 +171,7 @@ static struct fstype_info fstypes[] = {
.opendir = fat_opendir,
.readdir = fat_readdir,
.closedir = fat_closedir,
+ .mkdir = fs_mkdir_unsupported,
},
#endif
#ifdef CONFIG_FS_EXT4
@@ -185,6 +192,7 @@ static struct fstype_info fstypes[] = {
#endif
.uuid = ext4fs_uuid,
.opendir = fs_opendir_unsupported,
+ .mkdir = fs_mkdir_unsupported,
},
#endif
#ifdef CONFIG_SANDBOX
@@ -201,6 +209,7 @@ static struct fstype_info fstypes[] = {
.write = fs_write_sandbox,
.uuid = fs_uuid_unsupported,
.opendir = fs_opendir_unsupported,
+ .mkdir = fs_mkdir_unsupported,
},
#endif
#ifdef CONFIG_CMD_UBIFS
@@ -217,6 +226,7 @@ static struct fstype_info fstypes[] = {
.write = fs_write_unsupported,
.uuid = fs_uuid_unsupported,
.opendir = fs_opendir_unsupported,
+ .mkdir = fs_mkdir_unsupported,
},
#endif
#ifdef CONFIG_FS_BTRFS
@@ -233,6 +243,7 @@ static struct fstype_info fstypes[] = {
.write = fs_write_unsupported,
.uuid = btrfs_uuid,
.opendir = fs_opendir_unsupported,
+ .mkdir = fs_mkdir_unsupported,
},
#endif
{
@@ -248,6 +259,7 @@ static struct fstype_info fstypes[] = {
.write = fs_write_unsupported,
.uuid = fs_uuid_unsupported,
.opendir = fs_opendir_unsupported,
+ .mkdir = fs_mkdir_unsupported,
},
};
@@ -498,6 +510,20 @@ void fs_closedir(struct fs_dir_stream *dirs)
}
+int fs_mkdir(const char *dirname)
+{
+ int ret;
+
+ struct fstype_info *info = fs_get_info(fs_type);
+
+ ret = info->mkdir(dirname);
+
+ fs_type = FS_TYPE_ANY;
+ fs_close();
+
+ return ret;
+}
+
int do_size(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
int fstype)
{
@@ -700,3 +726,22 @@ int do_fs_type(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
return CMD_RET_SUCCESS;
}
+int do_mkdir(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
+ int fstype)
+{
+ int ret;
+
+ if (argc != 4)
+ return CMD_RET_USAGE;
+
+ if (fs_set_blk_dev(argv[1], argv[2], fstype))
+ return 1;
+
+ ret = fs_mkdir(argv[3]);
+ if (ret) {
+ printf("** Unable to create a directory \"%s\" **\n", argv[3]);
+ return 1;
+ }
+
+ return 0;
+}
diff --git a/include/fs.h b/include/fs.h
index 163da103b4..fbaee154dd 100644
--- a/include/fs.h
+++ b/include/fs.h
@@ -155,6 +155,14 @@ struct fs_dirent *fs_readdir(struct fs_dir_stream *dirs);
*/
void fs_closedir(struct fs_dir_stream *dirs);
+/*
+ * fs_mkdir - Create a directory
+ *
+ * @filename: Name of directory to create
+ * @return 0 on success, -1 on error conditions
+ */
+int fs_mkdir(const char *filename);
+
/*
* Common implementation for various filesystem commands, optionally limited
* to a specific filesystem type via the fstype parameter.
@@ -169,6 +177,8 @@ int file_exists(const char *dev_type, const char *dev_part,
const char *file,
int fstype);
int do_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
int fstype);
+int do_mkdir(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[],
+ int fstype);
/*
* Determine the UUID of the specified filesystem and print it. Optionally it
is
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 16/17] efi_loader: implement a pseudo "file delete"
This patch is necessary to run SCT.efi (UEFI Self-Certification Test).
Returning EFI_SUCCESS can cheat SCT execution.
Signed-off-by: AKASHI Takahiro
---
lib/efi_loader/efi_file.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index 6ec98c8022..12044a0c71 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -226,12 +226,20 @@ static efi_status_t EFIAPI efi_file_close(struct
efi_file_handle *file)
return EFI_EXIT(file_close(fh));
}
+static efi_status_t EFIAPI efi_file_write(struct efi_file_handle *file,
+ efi_uintn_t *buffer_size,
+ void *buffer);
+
static efi_status_t EFIAPI efi_file_delete(struct efi_file_handle *file)
{
struct file_handle *fh = to_fh(file);
+ efi_uintn_t size = 0;
EFI_ENTRY("%p", file);
+
+ /* TODO: implement real 'delete' */
+ efi_file_write(file, , NULL);
file_close(fh);
- return EFI_EXIT(EFI_WARN_DELETE_FAILURE);
+ return EFI_SUCCESS;
}
static efi_status_t file_read(struct file_handle *fh, u64 *buffer_size,
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 10/17] cmd: fat: add offset parameter to fatwrite
In this patch, fatwrite command is extended so as to accept an additional
parameter of file offset.
Signed-off-by: AKASHI Takahiro
---
cmd/fat.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/cmd/fat.c b/cmd/fat.c
index 03de5d11af..2a5f7bfc26 100644
--- a/cmd/fat.c
+++ b/cmd/fat.c
@@ -104,6 +104,7 @@ static int do_fat_fswrite(cmd_tbl_t *cmdtp, int flag,
int ret;
unsigned long addr;
unsigned long count;
+ long offset;
struct blk_desc *dev_desc = NULL;
disk_partition_t info;
int dev = 0;
@@ -126,9 +127,11 @@ static int do_fat_fswrite(cmd_tbl_t *cmdtp, int flag,
}
addr = simple_strtoul(argv[3], NULL, 16);
count = (argc <= 5) ? 0 : simple_strtoul(argv[5], NULL, 16);
+ /* offset should be a hex, but "-1" is allowed */
+ offset = (argc <= 6) ? 0 : simple_strtol(argv[6], NULL, 16);
buf = map_sysmem(addr, count);
- ret = file_fat_write(argv[4], buf, 0, count, );
+ ret = file_fat_write(argv[4], buf, offset, count, );
unmap_sysmem(buf);
if (ret < 0) {
printf("\n** Unable to write \"%s\" from %s %d:%d **\n",
@@ -142,9 +145,9 @@ static int do_fat_fswrite(cmd_tbl_t *cmdtp, int flag,
}
U_BOOT_CMD(
- fatwrite, 6, 0, do_fat_fswrite,
+ fatwrite, 7, 0, do_fat_fswrite,
"write file into a dos filesystem",
- "[]\n"
+ "[ []]\n"
"- write file 'filename' from the address 'addr' in RAM\n"
" to 'dev' on 'interface'"
);
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 07/17] fs: fat: support write with sub-directory path
In this patch, write implementation is overhauled and rewritten by
making full use of directory iterator. The ovbious bonus is that we are
now able to write to a file with a directory path, like /A/B/C/FILE.
Please note that, as there is no notion of "current directory" on u-boot,
a file name specified must contain an absolute directory path. Otherwise,
"/" (root directory) is assumed.
Signed-off-by: AKASHI Takahiro
---
fs/fat/fat.c | 9 -
fs/fat/fat_write.c | 469 +++--
2 files changed, 157 insertions(+), 321 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index d9bfb08d97..9bafc3a40c 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -464,15 +464,6 @@ static __u8 mkcksum(const char name[8], const char ext[3])
return ret;
}
-/*
- * TODO these should go away once fat_write is reworked to use the
- * directory iterator
- */
-__u8 get_dentfromdir_block[MAX_CLUSTSIZE]
- __aligned(ARCH_DMA_MINALIGN);
-__u8 do_fat_read_at_block[MAX_CLUSTSIZE]
- __aligned(ARCH_DMA_MINALIGN);
-
/*
* Read boot sector and volume info from a FAT filesystem
*/
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 1e4f5af910..96edb6674c 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -99,7 +99,6 @@ static void set_name(dir_entry *dirent, const char *filename)
debug("ext : %s\n", dirent->ext);
}
-static __u8 num_of_fats;
/*
* Write fat buffer into block device
*/
@@ -128,7 +127,7 @@ static int flush_dirty_fat_buffer(fsdata *mydata)
return -1;
}
- if (num_of_fats == 2) {
+ if (mydata->bs_fats == 2) {
/* Update corresponding second FAT blocks */
startblock += mydata->fatlength;
if (disk_write(startblock, getsize, bufptr) < 0) {
@@ -210,15 +209,14 @@ name11_12:
return 1;
}
-static int is_next_clust(fsdata *mydata, dir_entry *dentptr);
-static void flush_dir_table(fsdata *mydata, dir_entry **dentptr);
+static int flush_dir_table(fat_itr *itr);
/*
* Fill dir_slot entries with appropriate name, id, and attr
- * The real directory entry is returned by 'dentptr'
+ * 'itr' will point to a next entry
*/
-static void
-fill_dir_slot(fsdata *mydata, dir_entry **dentptr, const char *l_name)
+static int
+fill_dir_slot(fat_itr *itr, const char *l_name)
{
__u8 temp_dir_slot_buffer[MAX_LFN_SLOT * sizeof(dir_slot)];
dir_slot *slotptr = (dir_slot *)temp_dir_slot_buffer;
@@ -226,7 +224,7 @@ fill_dir_slot(fsdata *mydata, dir_entry **dentptr, const
char *l_name)
int idx = 0, ret;
/* Get short file name checksum value */
- checksum = mkcksum((*dentptr)->name, (*dentptr)->ext);
+ checksum = mkcksum(itr->dent->name, itr->dent->ext);
do {
memset(slotptr, 0x00, sizeof(dir_slot));
@@ -241,120 +239,21 @@ fill_dir_slot(fsdata *mydata, dir_entry **dentptr, const
char *l_name)
slotptr->id |= LAST_LONG_ENTRY_MASK;
while (counter >= 1) {
- if (is_next_clust(mydata, *dentptr)) {
- /* A new cluster is allocated for directory table */
- flush_dir_table(mydata, dentptr);
- }
- memcpy(*dentptr, slotptr, sizeof(dir_slot));
- (*dentptr)++;
+ memcpy(itr->dent, slotptr, sizeof(dir_slot));
slotptr--;
counter--;
- }
-
- if (is_next_clust(mydata, *dentptr)) {
- /* A new cluster is allocated for directory table */
- flush_dir_table(mydata, dentptr);
- }
-}
-
-static __u32 dir_curclust;
-
-/*
- * Extract the full long filename starting at 'retdent' (which is really
- * a slot) into 'l_name'. If successful also copy the real directory entry
- * into 'retdent'
- * If additional adjacent cluster for directory entries is read into memory,
- * then 'get_contents_vfatname_block' is copied into 'get_dentfromdir_block'
and
- * the location of the real directory entry is returned by 'retdent'
- * Return 0 on success, -1 otherwise.
- */
-static int
-get_long_file_name(fsdata *mydata, int curclust, __u8 *cluster,
- dir_entry **retdent, char *l_name)
-{
- dir_entry *realdent;
- dir_slot *slotptr = (dir_slot *)(*retdent);
- dir_slot *slotptr2 = NULL;
- __u8 *buflimit = cluster + mydata->sect_size * ((curclust == 0) ?
- PREFETCH_BLOCKS :
- mydata->clust_size);
- __u8 counter = (slotptr->id & ~LAST_LONG_ENTRY_MASK) & 0xff;
- int idx = 0, cur_position = 0;
-
- if (counter > VFAT_MAXSEQ) {
- debug("Error: VFAT name is too long\n");
- return -1;
- }
-
- while ((__u8 *)slotptr < buflimit) {
- if (counter == 0)
- break;
- if (((slotptr->id &
[U-Boot] [PATCH 13/17] fs: fat: support mkdir
In this patch, mkdir support is added to FAT file system.
A newly created directory contains only "." and ".." entries.
Signed-off-by: AKASHI Takahiro
---
fs/fat/fat_write.c | 138 +
fs/fs.c| 3 +-
include/fat.h | 1 +
3 files changed, 141 insertions(+), 1 deletion(-)
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index cc45a33876..781883c9f4 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -1185,3 +1185,141 @@ int file_fat_write(const char *filename, void *buffer,
loff_t offset,
{
return file_fat_write_at(filename, offset, buffer, maxsize, actwrite);
}
+
+int fat_mkdir(const char *new_dirname)
+{
+ dir_entry *retdent;
+ fsdata datablock = { .fatbuf = NULL, };
+ fsdata *mydata =
+ fat_itr *itr = NULL;
+ char *dirname_copy, *parent, *dirname;
+ char l_dirname[VFAT_MAXLEN_BYTES];
+ int ret = -1;
+ loff_t actwrite;
+ unsigned int bytesperclust;
+ dir_entry *dotdent = NULL;
+
+ dirname_copy = strdup(new_dirname);
+ if (!dirname_copy)
+ goto exit;
+
+ split_filename(dirname_copy, , );
+ if (!strlen(dirname)) {
+ ret = -EINVAL;
+ goto exit;
+ }
+
+ if (normalize_longname(l_dirname, dirname)) {
+ printf("FAT: illegal filename (%s)\n", dirname);
+ ret = -EINVAL;
+ goto exit;
+ }
+
+ itr = malloc_cache_aligned(sizeof(fat_itr));
+ if (!itr) {
+ ret = -ENOMEM;
+ goto exit;
+ }
+
+ ret = fat_itr_root(itr, );
+ if (ret)
+ goto exit;
+
+ total_sector = datablock.bs_total_sect;
+ if (total_sector == 0)
+ total_sector = (int)cur_part_info.size; /* cast of lbaint_t */
+
+ ret = fat_itr_resolve(itr, parent, TYPE_DIR);
+ if (ret) {
+ printf("%s: doesn't exist (%d)\n", parent, ret);
+ goto exit;
+ }
+
+ retdent = find_directory_entry(itr, l_dirname);
+
+ if (retdent) {
+ printf("%s: already exists\n", l_dirname);
+ ret = -EEXIST;
+ goto exit;
+ } else {
+ if (itr->is_root) {
+ /* root dir cannot have "." or ".." */
+ if (!strcmp(l_dirname, ".") ||
+ !strcmp(l_dirname, "..")) {
+ ret = -EINVAL;
+ goto exit;
+ }
+ }
+
+ if (!itr->dent) {
+ printf("Error: allocating new dir entry\n");
+ ret = -EIO;
+ goto exit;
+ }
+
+ memset(itr->dent, 0, sizeof(*itr->dent));
+
+ /* Set short name to set alias checksum field in dir_slot */
+ set_name(itr->dent, dirname);
+ fill_dir_slot(itr, dirname);
+
+ /* Set attribute as archieve for regular file */
+ fill_dentry(itr->fsdata, itr->dent, dirname, 0, 0,
+ ATTR_DIR | ATTR_ARCH);
+
+ retdent = itr->dent;
+ }
+
+ /* Default entries */
+ bytesperclust = mydata->clust_size * mydata->sect_size;
+ dotdent = malloc_cache_aligned(bytesperclust);
+ if (!dotdent) {
+ ret = -ENOMEM;
+ goto exit;
+ }
+ memset(dotdent, 0, bytesperclust);
+
+ memcpy(dotdent[0].name, ". ", 8);
+ memcpy(dotdent[0].ext, " ", 3);
+ dotdent[0].attr = ATTR_DIR | ATTR_ARCH;
+
+ memcpy(dotdent[1].name, ".. ", 8);
+ memcpy(dotdent[1].ext, " ", 3);
+ dotdent[1].attr = ATTR_DIR | ATTR_ARCH;
+ set_start_cluster(mydata, [1], itr->start_clust);
+
+ ret = set_contents(mydata, retdent, 0, (__u8 *)dotdent, bytesperclust,
+ );
+ if (ret < 0) {
+ printf("Error: writing contents\n");
+ goto exit;
+ }
+ /* Write twice for "." */
+ set_start_cluster(mydata, [0], START(retdent));
+ ret = set_contents(mydata, retdent, 0, (__u8 *)dotdent, bytesperclust,
+ );
+ if (ret < 0) {
+ printf("Error: writing contents\n");
+ goto exit;
+ }
+
+ /* Flush fat buffer */
+ ret = flush_dirty_fat_buffer(mydata);
+ if (ret) {
+ printf("Error: flush fat buffer\n");
+ goto exit;
+ }
+
+ /* Write directory table to device */
+ ret = set_cluster(mydata, itr->clust, itr->block,
+ mydata->clust_size * mydata->sect_size);
+ if (ret)
+ printf("Error: writing directory entry\n");
+
+exit:
+ free(dirname_copy);
+
[U-Boot] [PATCH 15/17] efi_loader: file: support creating a directory
In efi world, there is no obvious "mkdir" interface, instead, Open()
with EFI_FILE_MODE_CREATE in mode parameter and EFI_FILE_DIRECTORY
in attributes parameter creates a directory.
In this patch, efi_file_open() is extended so as to accept such
a combination of parameters and call u-boot's mkdir interface for
expected action.
Signed-off-by: AKASHI Takahiro
---
lib/efi_loader/efi_file.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
index e6a15bcb52..6ec98c8022 100644
--- a/lib/efi_loader/efi_file.c
+++ b/lib/efi_loader/efi_file.c
@@ -130,7 +130,8 @@ static int sanitize_path(char *path)
* With windoze style backlashes, ofc.
*/
static struct efi_file_handle *file_open(struct file_system *fs,
- struct file_handle *parent, s16 *file_name, u64 mode)
+ struct file_handle *parent, s16 *file_name, u64 mode,
+ u64 attributes)
{
struct file_handle *fh;
char f0[MAX_UTF8_PER_UTF16] = {0};
@@ -173,7 +174,12 @@ static struct efi_file_handle *file_open(struct
file_system *fs,
if (set_blk_dev(fh))
goto error;
- if (!((mode & EFI_FILE_MODE_CREATE) || fs_exists(fh->path)))
+ if ((mode & EFI_FILE_MODE_CREATE) &&
+ (attributes & EFI_FILE_DIRECTORY)) {
+ if (fs_mkdir(fh->path))
+ goto error;
+ } else if (!((mode & EFI_FILE_MODE_CREATE) ||
+fs_exists(fh->path)))
goto error;
/* figure out if file is a directory: */
@@ -199,7 +205,7 @@ static efi_status_t EFIAPI efi_file_open(struct
efi_file_handle *file,
EFI_ENTRY("%p, %p, \"%ls\", %llx, %llu", file, new_handle, file_name,
open_mode, attributes);
- *new_handle = file_open(fh->fs, fh, file_name, open_mode);
+ *new_handle = file_open(fh->fs, fh, file_name, open_mode, attributes);
if (!*new_handle)
return EFI_EXIT(EFI_NOT_FOUND);
@@ -598,7 +604,7 @@ efi_open_volume(struct efi_simple_file_system_protocol
*this,
EFI_ENTRY("%p, %p", this, root);
- *root = file_open(fs, NULL, NULL, 0);
+ *root = file_open(fs, NULL, NULL, 0, 0);
return EFI_EXIT(EFI_SUCCESS);
}
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 09/17] fs: fat: support write with non-zero offset
In this patch, all the necessary code for allowing for a file offset
at write is implemented. What plays a major roll here is get_set_cluster(),
which, in contrast to its counterpart, set_cluster(), only operates on
already-allocated clusters, overwriting with data.
So, with a file offset specified, set_contents() seeks and writes data
with set_get_cluster() until the end of a file, and, once it reaches
there, continues writing with set_cluster() for the rest.
Please note that a file will be trimmed as a result of write operation if
write ends before reaching file's end. This is an intended behavior
in order to maitain compatibility with the current interface.
Signed-off-by: AKASHI Takahiro
---
fs/fat/fat_write.c | 287 ++---
1 file changed, 272 insertions(+), 15 deletions(-)
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 3a9c53e253..cc45a33876 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -450,6 +450,120 @@ set_cluster(fsdata *mydata, __u32 clustnum, __u8 *buffer,
return 0;
}
+static __u8 tmpbuf_cluster[MAX_CLUSTSIZE] __aligned(ARCH_DMA_MINALIGN);
+
+/*
+ * Read and modify data on existing and consecutive cluster blocks
+ */
+static int
+get_set_cluster(fsdata *mydata, __u32 clustnum, loff_t pos, __u8 *buffer,
+ loff_t size, loff_t *gotsize)
+{
+ unsigned int bytesperclust = mydata->clust_size * mydata->sect_size;
+ __u32 startsect;
+ loff_t wsize;
+ int clustcount, i, ret;
+
+ *gotsize = 0;
+ if (!size)
+ return 0;
+
+ assert(pos < bytesperclust);
+ startsect = clust_to_sect(mydata, clustnum);
+
+ debug("clustnum: %d, startsect: %d, pos: %lld\n", clustnum, startsect,
+ pos);
+
+ /* partial write at beginning */
+ if (pos) {
+ wsize = min(bytesperclust - pos, size);
+ ret = disk_read(startsect, mydata->clust_size, tmpbuf_cluster);
+ if (ret != mydata->clust_size) {
+ debug("Error reading data (got %d)\n", ret);
+ return -1;
+ }
+
+ memcpy(tmpbuf_cluster + pos, buffer, wsize);
+ ret = disk_write(startsect, mydata->clust_size, tmpbuf_cluster);
+ if (ret != mydata->clust_size) {
+ debug("Error writing data (got %d)\n", ret);
+ return -1;
+ }
+
+ size -= wsize;
+ buffer += wsize;
+ *gotsize += wsize;
+
+ startsect += mydata->clust_size;
+
+ if (!size)
+ return 0;
+ }
+
+ /* full-cluster write */
+ if (size >= bytesperclust) {
+ clustcount = lldiv(size, bytesperclust);
+
+ if (!((unsigned long)buffer & (ARCH_DMA_MINALIGN - 1))) {
+ wsize = clustcount * bytesperclust;
+ ret = disk_write(startsect,
+ clustcount * mydata->clust_size,
+ buffer);
+ if (ret != clustcount * mydata->clust_size) {
+ debug("Error writing data (got %d)\n", ret);
+ return -1;
+ }
+
+ size -= wsize;
+ buffer += wsize;
+ *gotsize += wsize;
+
+ startsect += clustcount * mydata->clust_size;
+ } else {
+ for (i = 0; i < clustcount; i++) {
+ memcpy(tmpbuf_cluster, buffer, bytesperclust);
+ ret = disk_write(startsect, mydata->clust_size,
+ tmpbuf_cluster);
+ if (ret != mydata->clust_size) {
+ debug("Error writing data (got %d)\n",
+ ret);
+ return -1;
+ }
+
+ size -= bytesperclust;
+ buffer += bytesperclust;
+ *gotsize += bytesperclust;
+
+ startsect += mydata->clust_size;
+ }
+ }
+ }
+
+ /* partial write at end */
+ if (size) {
+ wsize = size;
+ ret = disk_read(startsect, mydata->clust_size, tmpbuf_cluster);
+ if (ret != mydata->clust_size) {
+ debug("Error reading data (got %d)\n", ret);
+ return -1;
+ }
+ memcpy(tmpbuf_cluster, buffer, wsize);
+ ret = disk_write(startsect, mydata->clust_size, tmpbuf_cluster);
[U-Boot] [PATCH 14/17] cmd: fat: add fatmkdir command
In this patch, a new command, fatmkdir, is added.
Please note that, as there is no notion of "current directory" on u-boot,
a directory name specified must contains an absolute directory path as
a parent directory. Otherwise, "/" (root directory) is assumed.
Signed-off-by: AKASHI Takahiro
---
cmd/fat.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/cmd/fat.c b/cmd/fat.c
index 2a5f7bfc26..136a5114c6 100644
--- a/cmd/fat.c
+++ b/cmd/fat.c
@@ -151,4 +151,17 @@ U_BOOT_CMD(
"- write file 'filename' from the address 'addr' in RAM\n"
" to 'dev' on 'interface'"
);
+
+static int do_fat_mkdir(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ return do_mkdir(cmdtp, flag, argc, argv, FS_TYPE_FAT);
+}
+
+U_BOOT_CMD(
+ fatmkdir, 4, 1, do_fat_mkdir,
+ "create a directory",
+ " [] \n"
+ "- create a directory in 'dev' on 'interface'"
+);
#endif
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 12/17] fs: fat: remember the starting cluster number of directory
The starting cluster number of directory is needed to initialize ".."
(parent directory) entry when creating a new directory.
Signed-off-by: AKASHI Takahiro
---
fs/fat/fat.c | 2 ++
include/fat.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 9bafc3a40c..ade5264551 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -639,6 +639,7 @@ int fat_itr_root(fat_itr *itr, fsdata *fsdata)
return -ENXIO;
itr->fsdata = fsdata;
+ itr->start_clust = 0;
itr->clust = fsdata->root_cluster;
itr->next_clust = fsdata->root_cluster;
itr->dent = NULL;
@@ -674,6 +675,7 @@ void fat_itr_child(fat_itr *itr, fat_itr *parent)
assert(fat_itr_isdir(parent));
itr->fsdata = parent->fsdata;
+ itr->start_clust = clustnum;
if (clustnum > 0) {
itr->clust = clustnum;
itr->next_clust = clustnum;
diff --git a/include/fat.h b/include/fat.h
index bc0f77abb5..295da0f243 100644
--- a/include/fat.h
+++ b/include/fat.h
@@ -197,6 +197,7 @@ static inline u32 sect_to_clust(fsdata *fsdata, int sect)
typedef struct {
fsdata*fsdata;/* filesystem parameters */
+ unsigned start_clust; /* first cluster */
unsigned clust; /* current cluster */
unsigned next_clust;/* next cluster if remaining == 0 */
intlast_cluster; /* set once we've read last cluster */
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 17/17] fs-test: fix false positive error at Test Case 12
The error message to be matched is wrong. Fix it.
Signed-off-by: AKASHI Takahiro
---
test/fs/fs-test.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/test/fs/fs-test.sh b/test/fs/fs-test.sh
index 2e8d5ee4df..7b0c5ea56f 100755
--- a/test/fs/fs-test.sh
+++ b/test/fs/fs-test.sh
@@ -522,7 +522,7 @@ function check_results() {
"TC11: 1MB write to $3.w - content verified"
# Check lookup of 'dot' directory
- grep -A4 "Test Case 12 " "$1" | grep -q 'Unable to write file'
+ grep -A4 "Test Case 12 " "$1" | grep -q 'Unable to write'
pass_fail "TC12: 1MB write to . - write denied"
# Check directory traversal
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 08/17] fs: fat: refactor write interface for a file offset
The current write implementation is quite simple: remove existing clusters
and then allocating new ones and filling them with data. This, inevitably,
enforces always writing from the beginning of a file.
As the first step to lift this restriction, fat_file_write() and
set_contents() are modified to accept an additional parameter, file offset
and further re-factored so that, in the next patch, all the necessary code
will be put into set_contents().
Signed-off-by: AKASHI Takahiro
---
fs/fat/fat_write.c | 178 +
1 file changed, 65 insertions(+), 113 deletions(-)
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 96edb6674c..3a9c53e253 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -528,6 +528,43 @@ static int clear_fatent(fsdata *mydata, __u32 entry)
return 0;
}
+/*
+ * Set start cluster in directory entry
+ */
+static void set_start_cluster(const fsdata *mydata, dir_entry *dentptr,
+ __u32 start_cluster)
+{
+ if (mydata->fatsize == 32)
+ dentptr->starthi =
+ cpu_to_le16((start_cluster & 0x) >> 16);
+ dentptr->start = cpu_to_le16(start_cluster & 0x);
+}
+
+/*
+ * Check whether adding a file makes the file system to
+ * exceed the size of the block device
+ * Return -1 when overflow occurs, otherwise return 0
+ */
+static int check_overflow(fsdata *mydata, __u32 clustnum, loff_t size)
+{
+ __u32 startsect, sect_num, offset;
+
+ if (clustnum > 0) {
+ startsect = clust_to_sect(mydata, clustnum);
+ } else {
+ startsect = mydata->rootdir_sect;
+ }
+
+ sect_num = div_u64_rem(size, mydata->sect_size, );
+
+ if (offset != 0)
+ sect_num++;
+
+ if (startsect + sect_num > total_sector)
+ return -1;
+ return 0;
+}
+
/*
* Write at most 'maxsize' bytes from 'buffer' into
* the file associated with 'dentptr'
@@ -535,29 +572,36 @@ static int clear_fatent(fsdata *mydata, __u32 entry)
* or return -1 on fatal errors.
*/
static int
-set_contents(fsdata *mydata, dir_entry *dentptr, __u8 *buffer,
+set_contents(fsdata *mydata, dir_entry *dentptr, loff_t pos, __u8 *buffer,
loff_t maxsize, loff_t *gotsize)
{
- loff_t filesize = FAT2CPU32(dentptr->size);
+ loff_t filesize;
unsigned int bytesperclust = mydata->clust_size * mydata->sect_size;
__u32 curclust = START(dentptr);
__u32 endclust = 0, newclust = 0;
loff_t actsize;
*gotsize = 0;
- debug("Filesize: %llu bytes\n", filesize);
-
- if (maxsize > 0 && filesize > maxsize)
- filesize = maxsize;
+ filesize = maxsize;
debug("%llu bytes\n", filesize);
- if (!curclust) {
- if (filesize) {
- debug("error: nonempty clusterless file!\n");
+ if (curclust) {
+ /*
+* release already-allocated clusters anyway
+*/
+ if (clear_fatent(mydata, curclust)) {
+ printf("Error: clearing FAT entries\n");
return -1;
}
- return 0;
+ }
+
+ curclust = find_empty_cluster(mydata);
+ set_start_cluster(mydata, dentptr, curclust);
+
+ if (check_overflow(mydata, curclust, filesize)) {
+ printf("Error: no space left: %llu\n", filesize);
+ return -1;
}
actsize = bytesperclust;
@@ -568,6 +612,7 @@ set_contents(fsdata *mydata, dir_entry *dentptr, __u8
*buffer,
newclust = determine_fatent(mydata, endclust);
if ((newclust - 1) != endclust)
+ /* write to */
goto getit;
if (CHECK_CLUST(newclust, mydata->fatsize)) {
@@ -614,18 +659,8 @@ getit:
actsize = bytesperclust;
curclust = endclust = newclust;
} while (1);
-}
-/*
- * Set start cluster in directory entry
- */
-static void set_start_cluster(const fsdata *mydata, dir_entry *dentptr,
- __u32 start_cluster)
-{
- if (mydata->fatsize == 32)
- dentptr->starthi =
- cpu_to_le16((start_cluster & 0x) >> 16);
- dentptr->start = cpu_to_le16(start_cluster & 0x);
+ return 0;
}
/*
@@ -642,31 +677,6 @@ static void fill_dentry(fsdata *mydata, dir_entry *dentptr,
set_name(dentptr, filename);
}
-/*
- * Check whether adding a file makes the file system to
- * exceed the size of the block device
- * Return -1 when overflow occurs, otherwise return 0
- */
-static int check_overflow(fsdata *mydata, __u32 clustnum, loff_t size)
-{
- __u32 startsect, sect_num, offset;
-
- if (clustnum > 0) {
- startsect = clust_to_sect(mydata, clustnum);
-
[U-Boot] [PATCH 06/17] fs: fat: write returns error code instead of -1
It would be good that FAT write function return error code instead of
just returning -1 as fat_read_file() does.
This patch attempts to address this issue although it is 'best effort
(or estimate)' for now.
Signed-off-by: AKASHI Takahiro
---
fs/fat/fat_write.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 6c715a70f4..1e4f5af910 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -956,7 +956,7 @@ static int do_fat_write(const char *filename, void *buffer,
loff_t size,
if (read_bootsectandvi(, , >fatsize)) {
debug("error: reading boot sector\n");
- return -1;
+ return -EIO;
}
total_sector = bs.total_sect;
@@ -997,7 +997,7 @@ static int do_fat_write(const char *filename, void *buffer,
loff_t size,
mydata->fatbuf = memalign(ARCH_DMA_MINALIGN, FATBUFSIZE);
if (mydata->fatbuf == NULL) {
debug("Error: allocating memory\n");
- return -1;
+ return -ENOMEM;
}
if (disk_read(cursect,
@@ -1005,6 +1005,7 @@ static int do_fat_write(const char *filename, void
*buffer, loff_t size,
(mydata->clust_size) :
PREFETCH_BLOCKS, do_fat_read_at_block) < 0) {
debug("Error: reading rootdir block\n");
+ ret = -EIO;
goto exit;
}
dentptr = (dir_entry *) do_fat_read_at_block;
@@ -1029,6 +1030,7 @@ static int do_fat_write(const char *filename, void
*buffer, loff_t size,
size);
if (ret) {
printf("Error: %llu overflow\n", size);
+ ret = -ENOSPC;
goto exit;
}
}
@@ -1036,6 +1038,7 @@ static int do_fat_write(const char *filename, void
*buffer, loff_t size,
ret = clear_fatent(mydata, start_cluster);
if (ret) {
printf("Error: clearing FAT entries\n");
+ ret = -EIO;
goto exit;
}
@@ -1045,12 +1048,14 @@ static int do_fat_write(const char *filename, void
*buffer, loff_t size,
ret = start_cluster = find_empty_cluster(mydata);
if (ret < 0) {
printf("Error: finding empty cluster\n");
+ ret = -ENOSPC;
goto exit;
}
ret = check_overflow(mydata, start_cluster, size);
if (ret) {
printf("Error: %llu overflow\n", size);
+ ret = -ENOSPC;
goto exit;
}
@@ -1065,12 +1070,14 @@ static int do_fat_write(const char *filename, void
*buffer, loff_t size,
ret = start_cluster = find_empty_cluster(mydata);
if (ret < 0) {
printf("Error: finding empty cluster\n");
+ ret = -ENOSPC;
goto exit;
}
ret = check_overflow(mydata, start_cluster, size);
if (ret) {
printf("Error: %llu overflow\n", size);
+ ret = -ENOSPC;
goto exit;
}
} else {
@@ -1087,6 +1094,7 @@ static int do_fat_write(const char *filename, void
*buffer, loff_t size,
ret = set_contents(mydata, retdent, buffer, size, actwrite);
if (ret < 0) {
printf("Error: writing contents\n");
+ ret = -EIO;
goto exit;
}
debug("attempt to write 0x%llx bytes\n", *actwrite);
@@ -1095,14 +1103,17 @@ static int do_fat_write(const char *filename, void
*buffer, loff_t size,
ret = flush_dirty_fat_buffer(mydata);
if (ret) {
printf("Error: flush fat buffer\n");
+ ret = -EIO;
goto exit;
}
/* Write directory table to device */
ret = set_cluster(mydata, dir_curclust, get_dentfromdir_block,
mydata->clust_size * mydata->sect_size);
- if (ret)
+ if (ret) {
printf("Error: writing directory entry\n");
+ ret = -EIO;
+ }
exit:
free(mydata->fatbuf);
@@ -1114,7 +1125,7 @@ int file_fat_write(const char *filename, void *buffer,
loff_t offset,
{
if (offset != 0) {
printf("Error: non zero offset is currently not supported.\n");
-
[U-Boot] [PATCH 03/17] fs: fat: make directory iterator global for write use
Directory iterator was introduced in major re-work of read operation by
Rob. We want to use it for write operation extensively as well.
This patch makes relevant functions, as well as iterator defition, visible
outside of fat.c.
Signed-off-by: AKASHI Takahiro
---
fs/fat/fat.c | 39 ++-
include/fat.h | 32
2 files changed, 38 insertions(+), 33 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index fd6523c66b..0f82cbe1bd 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -634,25 +634,6 @@ static int get_fs_info(fsdata *mydata)
* For more complete example, see fat_itr_resolve()
*/
-typedef struct {
- fsdata*fsdata;/* filesystem parameters */
- unsigned clust; /* current cluster */
- intlast_cluster; /* set once we've read last cluster */
- intis_root; /* is iterator at root directory */
- intremaining; /* remaining dent's in current cluster */
-
- /* current iterator position values: */
- dir_entry *dent; /* current directory entry */
- char l_name[VFAT_MAXLEN_BYTES];/* long (vfat) name */
- char s_name[14];/* short 8.3 name */
- char *name; /* l_name if there is one, else s_name */
-
- /* storage for current cluster in memory: */
- u8 block[MAX_CLUSTSIZE] __aligned(ARCH_DMA_MINALIGN);
-} fat_itr;
-
-static int fat_itr_isdir(fat_itr *itr);
-
/**
* fat_itr_root() - initialize an iterator to start at the root
* directory
@@ -661,7 +642,7 @@ static int fat_itr_isdir(fat_itr *itr);
* @fsdata: filesystem data for the partition
* @return 0 on success, else -errno
*/
-static int fat_itr_root(fat_itr *itr, fsdata *fsdata)
+int fat_itr_root(fat_itr *itr, fsdata *fsdata)
{
if (get_fs_info(fsdata))
return -ENXIO;
@@ -693,7 +674,7 @@ static int fat_itr_root(fat_itr *itr, fsdata *fsdata)
* @parent: the iterator pointing at a directory entry in the
*parent directory of the directory to iterate
*/
-static void fat_itr_child(fat_itr *itr, fat_itr *parent)
+void fat_itr_child(fat_itr *itr, fat_itr *parent)
{
fsdata *mydata = parent->fsdata; /* for silly macros */
unsigned clustnum = START(parent->dent);
@@ -713,7 +694,7 @@ static void fat_itr_child(fat_itr *itr, fat_itr *parent)
itr->last_cluster = 0;
}
-static void *next_cluster(fat_itr *itr)
+void *next_cluster(fat_itr *itr)
{
fsdata *mydata = itr->fsdata; /* for silly macros */
int ret;
@@ -834,7 +815,7 @@ static dir_entry *extract_vfat_name(fat_itr *itr)
* @return boolean, 1 if success or 0 if no more entries in the
*current directory
*/
-static int fat_itr_next(fat_itr *itr)
+int fat_itr_next(fat_itr *itr)
{
dir_entry *dent;
@@ -879,19 +860,11 @@ static int fat_itr_next(fat_itr *itr)
* @itr: the iterator
* @return true if cursor is at a directory
*/
-static int fat_itr_isdir(fat_itr *itr)
+int fat_itr_isdir(fat_itr *itr)
{
return !!(itr->dent->attr & ATTR_DIR);
}
-/*
- * Helpers:
- */
-
-#define TYPE_FILE 0x1
-#define TYPE_DIR 0x2
-#define TYPE_ANY (TYPE_FILE | TYPE_DIR)
-
/**
* fat_itr_resolve() - traverse directory structure to resolve the
* requested path.
@@ -907,7 +880,7 @@ static int fat_itr_isdir(fat_itr *itr)
* @type: bitmask of allowable file types
* @return 0 on success or -errno
*/
-static int fat_itr_resolve(fat_itr *itr, const char *path, unsigned type)
+int fat_itr_resolve(fat_itr *itr, const char *path, unsigned type)
{
const char *next;
diff --git a/include/fat.h b/include/fat.h
index 0c88b59a4a..577e6b4592 100644
--- a/include/fat.h
+++ b/include/fat.h
@@ -187,6 +187,38 @@ static inline u32 sect_to_clust(fsdata *fsdata, int sect)
return (sect - fsdata->data_begin) / fsdata->clust_size;
}
+/*
+ * Directory iterator
+ */
+
+#define TYPE_FILE 0x1
+#define TYPE_DIR 0x2
+#define TYPE_ANY (TYPE_FILE | TYPE_DIR)
+
+typedef struct {
+ fsdata*fsdata;/* filesystem parameters */
+ unsigned clust; /* current cluster */
+ intlast_cluster; /* set once we've read last cluster */
+ intis_root; /* is iterator at root directory */
+ intremaining; /* remaining dent's in current cluster */
+
+ /* current iterator position values: */
+ dir_entry *dent; /* current directory entry */
+ char l_name[VFAT_MAXLEN_BYTES];/* long (vfat) name */
+ char s_name[14];/* short 8.3 name */
+ char *name; /* l_name if there is one, else s_name */
+
+ /* storage for current cluster in memory: */
+ u8 block[MAX_CLUSTSIZE] __aligned(ARCH_DMA_MINALIGN);
+} fat_itr;
+
+int fat_itr_root(fat_itr *itr, fsdata *fsdata);
+void fat_itr_child(fat_itr *itr, fat_itr *parent);
+void *next_cluster(fat_itr
[U-Boot] [PATCH 05/17] fs: fat: check and normailze file name
FAT file system's long file name support is a bit complicated and has some
restrictions on its naming. We should be careful about it especially for
write as it may easily end up with wrong file system.
normalize_longname() check for the rules and normalize a file name
if necessary. Please note, however, that this function is yet to be
extended to fully comply with the standard.
Signed-off-by: AKASHI Takahiro
---
fs/fat/fat_write.c | 52 +++---
1 file changed, 44 insertions(+), 8 deletions(-)
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 3b77557b3e..6c715a70f4 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -899,6 +899,44 @@ static dir_entry *find_directory_entry(fsdata *mydata, int
startsect,
return NULL;
}
+static int normalize_longname(char *l_filename, const char *filename)
+{
+ const char *p, legal[] = "!#$%&\'()-.@^`_{}~";
+ char c;
+ int name_len;
+
+ /* Check that the filename is valid */
+ for (p = filename; p < filename + strlen(filename); p++) {
+ c = *p;
+
+ if (('0' <= c) && (c <= '9'))
+ continue;
+ if (('A' <= c) && (c <= 'Z'))
+ continue;
+ if (('a' <= c) && (c <= 'z'))
+ continue;
+ if (strchr(legal, c))
+ continue;
+ /* extended code */
+ if ((0x80 <= c) && (c <= 0xff))
+ continue;
+
+ return -1;
+ }
+
+ /* Normalize it */
+ name_len = strlen(filename);
+ if (name_len >= VFAT_MAXLEN_BYTES)
+ /* should return an error? */
+ name_len = VFAT_MAXLEN_BYTES - 1;
+
+ memcpy(l_filename, filename, name_len);
+ l_filename[name_len] = 0; /* terminate the string */
+ downcase(l_filename, INT_MAX);
+
+ return 0;
+}
+
static int do_fat_write(const char *filename, void *buffer, loff_t size,
loff_t *actwrite)
{
@@ -910,7 +948,7 @@ static int do_fat_write(const char *filename, void *buffer,
loff_t size,
fsdata datablock;
fsdata *mydata =
int cursect;
- int ret = -1, name_len;
+ int ret = -1;
char l_filename[VFAT_MAXLEN_BYTES];
*actwrite = size;
@@ -971,13 +1009,11 @@ static int do_fat_write(const char *filename, void
*buffer, loff_t size,
}
dentptr = (dir_entry *) do_fat_read_at_block;
- name_len = strlen(filename);
- if (name_len >= VFAT_MAXLEN_BYTES)
- name_len = VFAT_MAXLEN_BYTES - 1;
-
- memcpy(l_filename, filename, name_len);
- l_filename[name_len] = 0; /* terminate the string */
- downcase(l_filename, INT_MAX);
+ if (normalize_longname(l_filename, filename)) {
+ printf("FAT: illegal filename (%s)\n", filename);
+ ret = -EINVAL;
+ goto exit;
+ }
startsect = mydata->rootdir_sect;
retdent = find_directory_entry(mydata, startsect,
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 04/17] fs: fat: assure iterator's ->dent belongs to ->clust
In my attempt to re-work write operation, it was revealed that iterator's
"clust" does not always point to a cluster to which a current directory
entry ("dent") belongs.
This patch assures that it is always true by adding "next_clust" which is
used solely for dereferencing a cluster chain.
Signed-off-by: AKASHI Takahiro
---
fs/fat/fat.c | 24
include/fat.h | 1 +
2 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 0f82cbe1bd..d9bfb08d97 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -649,6 +649,7 @@ int fat_itr_root(fat_itr *itr, fsdata *fsdata)
itr->fsdata = fsdata;
itr->clust = fsdata->root_cluster;
+ itr->next_clust = fsdata->root_cluster;
itr->dent = NULL;
itr->remaining = 0;
itr->last_cluster = 0;
@@ -684,9 +685,11 @@ void fat_itr_child(fat_itr *itr, fat_itr *parent)
itr->fsdata = parent->fsdata;
if (clustnum > 0) {
itr->clust = clustnum;
+ itr->next_clust = clustnum;
itr->is_root = 0;
} else {
itr->clust = parent->fsdata->root_cluster;
+ itr->next_clust = parent->fsdata->root_cluster;
itr->is_root = 1;
}
itr->dent = NULL;
@@ -704,7 +707,7 @@ void *next_cluster(fat_itr *itr)
if (itr->last_cluster)
return NULL;
- sect = clust_to_sect(itr->fsdata, itr->clust);
+ sect = clust_to_sect(itr->fsdata, itr->next_clust);
debug("FAT read(sect=%d), clust_size=%d, DIRENTSPERBLOCK=%zd\n",
sect, itr->fsdata->clust_size, DIRENTSPERBLOCK);
@@ -725,18 +728,19 @@ void *next_cluster(fat_itr *itr)
return NULL;
}
+ itr->clust = itr->next_clust;
if (itr->is_root && itr->fsdata->fatsize != 32) {
- itr->clust++;
- sect = clust_to_sect(itr->fsdata, itr->clust);
+ itr->next_clust++;
+ sect = clust_to_sect(itr->fsdata, itr->next_clust);
if (sect - itr->fsdata->rootdir_sect >=
itr->fsdata->rootdir_size) {
- debug("cursect: 0x%x\n", itr->clust);
+ debug("nextclust: 0x%x\n", itr->next_clust);
itr->last_cluster = 1;
}
} else {
- itr->clust = get_fatent(itr->fsdata, itr->clust);
- if (CHECK_CLUST(itr->clust, itr->fsdata->fatsize)) {
- debug("cursect: 0x%x\n", itr->clust);
+ itr->next_clust = get_fatent(itr->fsdata, itr->next_clust);
+ if (CHECK_CLUST(itr->next_clust, itr->fsdata->fatsize)) {
+ debug("nextclust: 0x%x\n", itr->next_clust);
itr->last_cluster = 1;
}
}
@@ -752,8 +756,11 @@ static dir_entry *next_dent(fat_itr *itr)
itr->fsdata->clust_size;
/* have we reached the last cluster? */
- if (!dent)
+ if (!dent) {
+ /* a sign for no more entries left */
+ itr->dent = NULL;
return NULL;
+ }
itr->remaining = nbytes / sizeof(dir_entry) - 1;
itr->dent = dent;
@@ -906,6 +913,7 @@ int fat_itr_resolve(fat_itr *itr, const char *path,
unsigned type)
(((next - path) == 2) && !strncmp(path, "..", 2))) {
/* point back to itself */
itr->clust = itr->fsdata->root_cluster;
+ itr->next_clust = itr->fsdata->root_cluster;
itr->dent = NULL;
itr->remaining = 0;
itr->last_cluster = 0;
diff --git a/include/fat.h b/include/fat.h
index 577e6b4592..bc0f77abb5 100644
--- a/include/fat.h
+++ b/include/fat.h
@@ -198,6 +198,7 @@ static inline u32 sect_to_clust(fsdata *fsdata, int sect)
typedef struct {
fsdata*fsdata;/* filesystem parameters */
unsigned clust; /* current cluster */
+ unsigned next_clust;/* next cluster if remaining == 0 */
intlast_cluster; /* set once we've read last cluster */
intis_root; /* is iterator at root directory */
intremaining; /* remaining dent's in current cluster */
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 02/17] fs: fat: handle "." and ".." of root dir correctly with fat_itr_resolve()
FAT's root directory does not have "." nor ".."
So care must be taken when scanning root directory with fat_itr_resolve().
Without this patch, any file path starting with "." or ".." will not be
resolved at all.
Signed-off-by: AKASHI Takahiro
---
fs/fat/fat.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index b48f48a751..fd6523c66b 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -927,6 +927,27 @@ static int fat_itr_resolve(fat_itr *itr, const char *path,
unsigned type)
while (next[0] && !ISDIRDELIM(next[0]))
next++;
+ if (itr->is_root) {
+ /* root dir doesn't have "." nor ".." */
+ if next - path) == 1) && !strncmp(path, ".", 1)) ||
+ (((next - path) == 2) && !strncmp(path, "..", 2))) {
+ /* point back to itself */
+ itr->clust = itr->fsdata->root_cluster;
+ itr->dent = NULL;
+ itr->remaining = 0;
+ itr->last_cluster = 0;
+
+ if (next[0] == 0) {
+ if (type & TYPE_DIR)
+ return 0;
+ else
+ return -ENOENT;
+ }
+
+ return fat_itr_resolve(itr, next, type);
+ }
+ }
+
while (fat_itr_next(itr)) {
int match = 0;
unsigned n = max(strlen(itr->name), (size_t)(next - path));
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 01/17] fs: fat: extend get_fs_info() for write use
get_fs_info() was introduced in major re-work of read operation by Rob.
We want to reuse this function in write operation by extending it with
additional members in fsdata structure.
Signed-off-by: AKASHI Takahiro
---
fs/fat/fat.c | 3 +++
include/fat.h | 2 ++
2 files changed, 5 insertions(+)
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 4efe8a3eda..b48f48a751 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -556,6 +556,9 @@ static int get_fs_info(fsdata *mydata)
return ret;
}
+ mydata->bs_total_sect = bs.total_sect;
+ mydata->bs_fats = bs.fats;
+
if (mydata->fatsize == 32) {
mydata->fatlength = bs.fat32_length;
} else {
diff --git a/include/fat.h b/include/fat.h
index 09e1423685..0c88b59a4a 100644
--- a/include/fat.h
+++ b/include/fat.h
@@ -173,6 +173,8 @@ typedef struct {
int fatbufnum; /* Used by get_fatent, init to -1 */
int rootdir_size; /* Size of root dir for non-FAT32 */
__u32 root_cluster; /* First cluster of root dir for FAT32 */
+ __u32 bs_total_sect; /* Boot sector's number of sectors */
+ __u8bs_fats;/* Boot sector's number of FATs */
} fsdata;
static inline u32 clust_to_sect(fsdata *fsdata, u32 clust)
--
2.17.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 00/17] fs: fat: extend FAT write operations
This patch series is an attempt to address FAT write related issues in an effort of running UEFI SCT (Self-Certification Test) to verify UEFI support on u-boot. SCT is a test platform as well as an extentisive collection of test cases for UEFI specification. It can run all the tests automatically and save test results to dedicated log files. AFAIK, what's missing in the current fat file system to safely run SCT without errors (I don't mean test case failures) are: * write a file located under sub-directories * write a file with non-zero offset * delete a file * create a directory Patch#1 to patch#6 are some sort of preparatory ones. Patch#7 implements write with sub-directories path. Patch#8 to patch#10 implement write with non-zero offset. Patch#11 to patch#15 are related to creating a directory. Patch#16 provides delete, but it doesn't actually delete a file but instead return 0 with purging a file content, which is good enough to run SCT for now. Finally, patch#17 fixes a minor bug in fs-test.sh. I applied this patch set on top of v2018.07 along with a couple of yet-to--be-upstreamed UEFI-related patches, and could successfully run unmodified SCT[1] on qemu-arm. [1] http://uefi.org/testtools AKASHI Takahiro (17): fs: fat: extend get_fs_info() for write use fs: fat: handle "." and ".." of root dir correctly with fat_itr_resolve() fs: fat: make directory iterator global for write use fs: fat: assure iterator's ->dent belongs to ->clust fs: fat: check and normailze file name fs: fat: write returns error code instead of -1 fs: fat: support write with sub-directory path fs: fat: refactor write interface for a file offset fs: fat: support write with non-zero offset cmd: fat: add offset parameter to fatwrite fs: add mkdir interface fs: fat: remember the starting cluster number of directory fs: fat: support mkdir cmd: fat: add fatmkdir command efi_loader: file: support creating a directory efi_loader: implement a pseudo "file delete" fs-test: fix false positive error at Test Case 12 cmd/fat.c | 22 +- fs/fat/fat.c | 98 ++-- fs/fat/fat_write.c| 1051 +++-- fs/fs.c | 46 ++ include/fat.h | 37 ++ include/fs.h | 10 + lib/efi_loader/efi_file.c | 24 +- test/fs/fs-test.sh|2 +- 8 files changed, 825 insertions(+), 465 deletions(-) -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] ext4: Issue with ext4write
Hi all, I am sometimes seeing issues when using ext4write where fsck later complains that the group descriptor has an invalid number of unused inodes. Is this a known problem? Also, I think the assert(offset == sizeof(*desc)); in ext4fs_checksum_update() is invalid since with ext4 the descriptor is larger than the offset. When debugging was enabled I'd always hit this assert. Also, in ext4fs_write, the debug statement should say blocks and not bytes. -Aaron -- Aaron Williams Senior Software Engineer Cavium, Inc. (408) 943-7198 (510) 789-8988 (cell) ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: fix fdtdec_setup_memory_banksize()
Hi Jens, On 19 July 2018 at 09:49, Jens Wiklander wrote: > On Thu, Jul 19, 2018 at 3:32 AM, Simon Glass wrote: >> Hi Jens, >> >> On 17 July 2018 at 09:42, Jens Wiklander wrote: >>> On Sun, Jul 15, 2018 at 11:20:39PM -0600, Simon Glass wrote: On 13 July 2018 at 04:12, Jens Wiklander wrote: > Prior to this patch is fdtdec_setup_memory_banksize() incorrectly > ignoring the "status" field. This patch fixes that by testing the status > with fdtdec_get_is_enabled() before using a memory node. > > Signed-off-by: Jens Wiklander > --- > lib/fdtdec.c | 20 +++- > 1 file changed, 15 insertions(+), 5 deletions(-) Reviewed-by: Simon Glass But can you convert this to livetree at the same time? E.g. use ofnode functions. >>> >>> I can try, but the ofnode concept is new to me. >>> >>> This patch is based on the fdt_node_offset_by_prop_value() function. I >>> can't find any such ofnode function or any other suitable helper >>> function. Perhaps I'm missing something, or should I add an >>> ofnode_by_prop_value() function (similar to ofnode_by_compatible())? >>> >>> Please advice. >> >> advise :-) >> >> Yes, you could add that function. Sorry it doesn't already exists. > > I'll give it a shot after my vacation. In the meantime can we take this patch > or > would you rather wait for the livetree version? We can take it. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] tpm: allow TPM v1 and v2 to be compiled at the same time
On 19 July 2018 at 14:35, Miquel Raynal wrote: > While there is probably no reason to do so in a real life situation, it > will allow to compile test both stacks with the same sandbox defconfig. > > As we cannot define two 'tpm' commands at the same time, the command for > TPM v1 is still called 'tpm' and the one for TPM v2 'tpm2'. While this > is the exact command name that must be written into eg. test files, any > user already using the TPM v2 stack can continue to do so by just writing > 'tpm' because as long as TPM v1 support is not compiled, U-Boot prompt > will search for the closest command named after 'tpm'. > > The command set can also be changed at runtime (not supported yet, but > ready to be), but as one can compile only either one stack or the other, > there is still one spot in the code where conditionals are used: to > retrieve the v1 or v2 command set. > > Signed-off-by: Miquel Raynal > --- > cmd/tpm-common.c | 24 +++- > cmd/tpm-v1.c | 2 +- > cmd/tpm-v2.c | 4 ++-- > drivers/tpm/Kconfig| 7 ++- > drivers/tpm/tpm-uclass.c | 3 --- > drivers/tpm/tpm2_tis_sandbox.c | 3 +++ > drivers/tpm/tpm2_tis_spi.c | 4 > include/tpm-common.h | 40 ++-- > 8 files changed, 69 insertions(+), 18 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] binman: ensure temp filenames don't collide
Hi Stephen,
On 19 July 2018 at 15:14, Stephen Warren wrote:
> On 07/18/2018 07:32 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On 16 July 2018 at 16:51, Stephen Warren wrote:
>>> From: Stephen Warren
>>>
>>> The U-Boot Makefile can invoke binman multiple times in parallel. This
>>> is problematic because binman uses a static hard-coded temporary file
>>> name. If two instances of binman use that filename at the same time, one
>>> writing one reading, they may silently read the wrong content or actively
>>> detect missing signatures and error out the build process. Fix this by
>>> using a PID-specific filename instead.
>>>
>>> Signed-off-by: Stephen Warren
>>> ---
>>> tools/binman/control.py | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/tools/binman/control.py b/tools/binman/control.py
>>> index a40b300fdacb..515999278949 100644
>>> --- a/tools/binman/control.py
>>> +++ b/tools/binman/control.py
>>> @@ -121,7 +121,7 @@ def Binman(options, args):
>>> # output into a file in our output directly. Then scan it for
>>> use
>>> # in binman.
>>> dtb_fname = fdt_util.EnsureCompiled(dtb_fname)
>>> -fname = tools.GetOutputFilename('u-boot-out.dtb')
>>> +fname = tools.GetOutputFilename('u-boot-out.dtb') +
>>> str(os.getpid())
>>> with open(dtb_fname) as infd:
>>> with open(fname, 'wb') as outfd:
>>> outfd.write(infd.read())
>>> --
>>> 2.18.0
>>>
>>
>> But the output directory is itself (normally) a temporary dir. That
>> determines the directly which GetOutputFilename() uses. So I am not
>> sure how this can happen in practice?
>
> IIRC, the output directory for all 3 files was the same; the root of the
> build output directory. Perhaps the fact I run "make O=build-xxx" rather
> than just "make" makes a difference?
Yes you are right - the -O flag sets the output directory and it
no-longer uses a temporary directory.
But if we add a PID to every filename then we end up with multiple
output files and we don't know which is right.
I think the correct fix is to change the Makefile to only run binman
once. It makes no sense to run it multiple times.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/7] tpm: remove stale symbol in Kconfig
On 19 July 2018 at 14:35, Miquel Raynal wrote: > The TPM_DRIVER_SELECTED symbol was used in one of the initial series > about TPMv2 but its use has been dropped, making these selects > useless, remove them. > > Signed-off-by: Miquel Raynal > --- > drivers/tpm/Kconfig | 3 --- > 1 file changed, 3 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] watchdog: dm: Support manual relocation for watchdogs
Hi, On 19 July 2018 at 09:47, Tom Rini wrote: > On Thu, Jul 19, 2018 at 09:21:39AM -0600, Simon Glass wrote: >> +Tom >> >> Hi Michal, >> >> On 19 July 2018 at 00:52, Michal Simek wrote: >> > Hi Simon, >> > >> > On 19.7.2018 03:31, Simon Glass wrote: >> >> Hi Michal, >> >> >> >> On 15 July 2018 at 23:34, Michal Simek wrote: >> >>> On 15.7.2018 23:21, Simon Glass wrote: >> Hi Michal, >> >> On 11 July 2018 at 23:47, Michal Simek wrote: >> > On 11.7.2018 22:13, Simon Glass wrote: >> >> On 11 July 2018 at 08:41, Michal Simek >> >> wrote: >> >>> Relocate watchdog ops as was done by: >> >>> "dm: Add support for all targets which requires MANUAL_RELOC" >> >>> (sha1: 484fdf5ba058b07be5ca82763aa2b72063540ef3) >> >>> >> >>> Signed-off-by: Michal Simek >> >>> --- >> >>> >> >>> based on https://lists.denx.de/pipermail/u-boot/2018-July/334227.html >> >>> >> >>> --- >> >>> drivers/watchdog/wdt-uclass.c | 23 +++ >> >>> 1 file changed, 23 insertions(+) >> >>> >> >> >> >> Reviewed-by: Simon Glass >> >> >> >> When will the toolchain be fixed? >> > >> > It is really several years back when I have looked at it last time but >> > I >> > think that toolchain is fixed for quite some time and only changes in >> > microblaze u-boot code are needed but really I would have to check and >> > start to play with it. >> >> I think someone should sort this out. It would be good to remove this >> code. Is there a toolchain group at Xilinx? >> >>> >> >>> Xilinx has a toolchain group. I just looked a I was playing with it in >> >>> January 2015 but didn't finish that. It is still on my long todo list. >> >>> Will see when I have a time to look at it. >> >> >> >> Hoe about next week? -:) I think this is pretty important. >> > >> > will see but I need to do some Linux work first. Based on grep I see >> > that m68k is also enabling CONFIG_NEEDS_MANUAL_RELOC. >> > Is m68k going to be removed soon? >> >> I am not sure about that. Tom, do you know? > > m68k is still active, so no, it's not being removed and we can't drop > CONFIG_NEEDS_MANUAL_RELOC just yet. Thanks Tom. That begs the question - how is relocation support coming along with m68k? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] fdt_support: make FDT_FIXUP_PARTITIONS depend on CMD_MTDPARTS
fdt_fixup_mtdparts() calls mtdparts_init() and device_find(), which are defined in cmd/mtdparts.c The combination of FDT_FIXUP_PARTITIONS=y and CMD_MTDPARTS=n emits the following link error: common/fdt_support.c:903: undefined reference to `mtdparts_init' common/fdt_support.c:914: undefined reference to `device_find' Signed-off-by: Masahiro Yamada --- lib/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/Kconfig b/lib/Kconfig index a77bf1c..622f3c2 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -334,7 +334,7 @@ config SPL_OF_LIBFDT config FDT_FIXUP_PARTITIONS bool "overwrite MTD partitions in DTS through defined in 'mtdparts'" depends on OF_LIBFDT - default n + depends on CMD_MTDPARTS help Allow overwriting defined partitions in the device tree blob using partition info defined in the 'mtdparts' environment -- 2.7.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] sunxi: support multiple memory banks
On Fri, 20 Jul 2018 04:13:24 +0300 Siarhei Siamashka wrote: > On Wed, 18 Jul 2018 23:42:07 +0200 > michael vogt wrote: > > > Hi > > > > I would like to support 4 memory chips for a sunxi board (a20). > > > > the current configuration in the sunxi-common.h looks like this: > > > > #define CONFIG_NR_DRAM_BANKS1 > > #define PHYS_SDRAM_0CONFIG_SYS_SDRAM_BASE > > #define PHYS_SDRAM_0_SIZE 0x8000 /* 2 GiB */ > > > > which seems to match the memory map for the a20. > > > > Question: > > While addressing 2gb ram works using one dram bank - will it work if there > > are two dram banks needed? > > These defines in U-Boot are not directly related to the DRAM > controller setup. They just allow to have multiple disconnected > DRAM areas in the physical address space, but on Allwinner > hardware the DRAM is typically (or even always?) represented > as a single contiguous chunk of memory in the address space. > > Did you actually mean support for multiple ranks? > https://en.wikipedia.org/wiki/Memory_rank > > To the best of my knowledge the A20 SoC has one chip select > pin (SCS), so it might support more than one rank. That said, > I'm not aware of any existing A10 or A20 board with a > double rank DRAM configuration. And the DRAM init code in > U-Boot for the A10/A13/A20 SoCs does not support multiple > ranks at the moment (since it was not possible to test > such configuration on real hardware). > > If somebody wants to use 2GB on an A20 board in a two ranks > configuration, then it's probably best to design such board > using the boot0 bootloader from the Allwinner's BSP for the > initial testing. And then after everything works correctly, > add the necessary changes to the DRAM init code in U-boot. > I could provide some help with getting this done. Hmm, actually with just a single chip select pin, A20 probably only supports one rank. There was a blog post from Olimex about the differences between A10 and A20: https://olimex.wordpress.com/2013/04/05/allwinners-a10-and-a20-are-they-really-pin-to-pin-compatible-and-drop-in-replacement/ Basically, the second chip select pin (SCS1) had been replaced by an extra address line (A15) in A20, which allowed to have 2GB RAM using four x8 DRAM chips in a single rank configuration. A good example of such board is Cubietruck. It is A10 SoC that theoretically supports multiple ranks. But again, I'm not aware of any real A10 device with 2GB of RAM and using the double rank configuration. -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] efi: app: Add a sysreset driver
On Thu, Jul 19, 2018 at 11:21 PM, Simon Glass wrote: > On 19 July 2018 at 04:07, Bin Meng wrote: >> This adds the DM sysreset driver for EFI application support. >> >> Signed-off-by: Bin Meng >> >> --- >> >> Changes in v2: >> - drop patches already applied >> - new patch to add a sysreset driver for efi app >> >> lib/efi/efi_app.c | 28 +++- >> 1 file changed, 27 insertions(+), 1 deletion(-) > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/5] dm: sysreset: Add a standard message when doing reset
On Thu, Jul 19, 2018 at 11:21 PM, Simon Glass wrote: > On 19 July 2018 at 04:07, Bin Meng wrote: >> It's good to print a message when doing reset. >> >> Signed-off-by: Bin Meng >> >> --- >> >> Changes in v2: >> - new patch per Wolfgang's suggestion to add a standard message when >> doing reset >> >> drivers/sysreset/sysreset-uclass.c | 2 ++ >> 1 file changed, 2 insertions(+) > > Reviewed-by: Simon Glass > > I wonder how many platforms will actually show this message and how > many will just put it in their serial buffer and then discard it? applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] x86: tangier: Add a sysreset driver
On Thu, Jul 19, 2018 at 11:21 PM, Simon Glass wrote: > On 19 July 2018 at 04:07, Bin Meng wrote: >> This adds a reset driver for tangier processor. >> >> Signed-off-by: Bin Meng >> >> --- >> >> Changes in v2: >> - new patch to add a reset driver for tangier processor >> >> arch/x86/cpu/tangier/Makefile | 2 +- >> arch/x86/cpu/tangier/sysreset.c | 48 >> + >> 2 files changed, 49 insertions(+), 1 deletion(-) >> create mode 100644 arch/x86/cpu/tangier/sysreset.c > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] x86: Switch to use DM sysreset driver
On Thu, Jul 19, 2018 at 11:21 PM, Simon Glass wrote: > On 19 July 2018 at 04:07, Bin Meng wrote: >> This converts all x86 boards over to DM sysreset. >> >> Signed-off-by: Bin Meng >> >> --- >> >> Changes in v2: >> - remove include of "reset.dsti" in edison.dts >> - add SYSRESET for efi-x86_app and edison >> >> arch/Kconfig | 2 ++ >> arch/x86/cpu/baytrail/valleyview.c| 6 -- >> arch/x86/cpu/braswell/braswell.c | 6 -- >> arch/x86/cpu/cpu.c| 26 >> -- >> arch/x86/cpu/ivybridge/early_me.c | 7 --- >> arch/x86/cpu/ivybridge/sdram.c| 3 ++- >> arch/x86/cpu/qemu/qemu.c | 6 -- >> arch/x86/cpu/quark/quark.c| 6 -- >> arch/x86/cpu/tangier/tangier.c| 6 -- >> arch/x86/dts/bayleybay.dts| 1 + >> arch/x86/dts/baytrail_som-db5800-som-6867.dts | 1 + >> arch/x86/dts/broadwell_som-6896.dts | 1 + >> arch/x86/dts/cherryhill.dts | 1 + >> arch/x86/dts/chromebook_link.dts | 1 + >> arch/x86/dts/chromebook_samus.dts | 1 + >> arch/x86/dts/chromebox_panther.dts| 1 + >> arch/x86/dts/conga-qeval20-qa3-e3845.dts | 1 + >> arch/x86/dts/cougarcanyon2.dts| 1 + >> arch/x86/dts/crownbay.dts | 1 + >> arch/x86/dts/dfi-bt700.dtsi | 1 + >> arch/x86/dts/edison.dts | 5 + >> arch/x86/dts/efi-x86_app.dts | 5 + >> arch/x86/dts/efi-x86_payload.dts | 1 + >> arch/x86/dts/galileo.dts | 1 + >> arch/x86/dts/minnowmax.dts| 1 + >> arch/x86/dts/qemu-x86_i440fx.dts | 1 + >> arch/x86/dts/qemu-x86_q35.dts | 1 + >> arch/x86/dts/reset.dtsi | 6 ++ >> arch/x86/include/asm/processor.h | 5 - >> arch/x86/include/asm/u-boot-x86.h | 1 - >> configs/chromebook_link64_defconfig | 1 + >> 31 files changed, 41 insertions(+), 66 deletions(-) >> create mode 100644 arch/x86/dts/reset.dtsi > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/5] x86: fsp: Eliminate the reset_cpu() call
On Thu, Jul 19, 2018 at 11:21 PM, Simon Glass wrote: > On 19 July 2018 at 04:07, Bin Meng wrote: >> In preparation for the reset driver conversion, eliminate the >> reset_cpu() call in the FSP init path as it's too early for the >> reset driver to work. >> >> Signed-off-by: Bin Meng >> --- >> >> Changes in v2: None >> >> arch/x86/lib/fsp/fsp_common.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) > > Adding back > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] x86: acpi: Prevent acpi_table.h from being included more than once
On Thu, Jul 19, 2018 at 11:21 PM, Simon Glass wrote: > On 18 July 2018 at 22:42, Bin Meng wrote: >> The wrapper #ifndef is currently missing in acpi_table.h. Add it to >> prevent it from being included multiple times. >> >> Signed-off-by: Bin Meng >> >> --- >> >> Changes in v2: None >> >> arch/x86/include/asm/acpi_table.h | 5 + >> 1 file changed, 5 insertions(+) > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] x86: acpi: Don't touch ACPI hardware in write_acpi_tables()
On Thu, Jul 19, 2018 at 11:21 PM, Simon Glass wrote: > On 18 July 2018 at 22:42, Bin Meng wrote: >> write_acpi_tables() currently touches ACPI hardware to switch to >> ACPI mode at the end. Move such operation out of this function, >> so that it only does what the function name tells us. >> >> Signed-off-by: Bin Meng >> >> --- >> >> Changes in v2: >> - move variable definition to the first line in the function >> >> arch/x86/cpu/cpu.c| 21 ++--- >> arch/x86/lib/acpi_table.c | 11 --- >> 2 files changed, 18 insertions(+), 14 deletions(-) > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] x86: acpi: Move APIs unrelated to ACPI tables generation to a separate library
On Thu, Jul 19, 2018 at 11:21 PM, Simon Glass wrote: > On 18 July 2018 at 22:42, Bin Meng wrote: >> acpi_find_fadt(), acpi_find_wakeup_vector() and enter_acpi_mode() >> are something unrelated to ACPI tables generation. Move these to >> a separate library. >> >> This also fixes several style issues reported by checkpatch in the >> original codes. >> >> Signed-off-by: Bin Meng >> --- >> >> Changes in v2: None >> >> arch/x86/cpu/cpu.c| 1 + >> arch/x86/include/asm/acpi.h | 41 +++ >> arch/x86/include/asm/acpi_table.h | 28 -- >> arch/x86/lib/Makefile | 1 + >> arch/x86/lib/acpi.c | 108 >> ++ >> arch/x86/lib/acpi_s3.c| 1 + >> arch/x86/lib/acpi_table.c | 101 +-- >> 7 files changed, 153 insertions(+), 128 deletions(-) >> create mode 100644 arch/x86/include/asm/acpi.h >> create mode 100644 arch/x86/lib/acpi.c > > Reviewed-by: Simon Glass applied to u-boot-x86, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] sunxi: support multiple memory banks
On Wed, 18 Jul 2018 23:42:07 +0200 michael vogt wrote: > Hi > > I would like to support 4 memory chips for a sunxi board (a20). > > the current configuration in the sunxi-common.h looks like this: > > #define CONFIG_NR_DRAM_BANKS 1 > #define PHYS_SDRAM_0 CONFIG_SYS_SDRAM_BASE > #define PHYS_SDRAM_0_SIZE 0x8000 /* 2 GiB */ > > which seems to match the memory map for the a20. > > Question: > While addressing 2gb ram works using one dram bank - will it work if there > are two dram banks needed? These defines in U-Boot are not directly related to the DRAM controller setup. They just allow to have multiple disconnected DRAM areas in the physical address space, but on Allwinner hardware the DRAM is typically (or even always?) represented as a single contiguous chunk of memory in the address space. Did you actually mean support for multiple ranks? https://en.wikipedia.org/wiki/Memory_rank To the best of my knowledge the A20 SoC has one chip select pin (SCS), so it might support more than one rank. That said, I'm not aware of any existing A10 or A20 board with a double rank DRAM configuration. And the DRAM init code in U-Boot for the A10/A13/A20 SoCs does not support multiple ranks at the moment (since it was not possible to test such configuration on real hardware). If somebody wants to use 2GB on an A20 board in a two ranks configuration, then it's probably best to design such board using the boot0 bootloader from the Allwinner's BSP for the initial testing. And then after everything works correctly, add the necessary changes to the DRAM init code in U-boot. I could provide some help with getting this done. -- Best regards, Siarhei Siamashka ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/4] arm: zynq: implement FPGA load from SPL
Hi Michal,
On Thu, Jul 19, 2018 at 2:23 AM Michal Simek wrote:
> On 18.7.2018 20:02, Luis Araneda wrote:
> > [...]
> > I didn't send them because just changing the defconfig isn't enough,
>
> It should be enough. It is configuration option and just enabling that
> feature. You should still be able to use just u-boot.img in legacy or
> fit format without any issue.
Ok. Should I send a patch only for the Zybo or all zynq boards? Also,
for than one board, should I create one patch per board or only one
big patch for all of them?
> I think it will be good if you can look at my patch and also compare
> boot up time when you setup compression to gzip. I expect some changes
> in connection to this code.
>
> if (IS_ENABLED(CONFIG_SPL_OS_BOOT) &&
> IS_ENABLED(CONFIG_SPL_GZIP) &&
> image_comp == IH_COMP_GZIP &&
> type == IH_TYPE_KERNEL) {
>
> And I would expect that copying smaller fit with unziping bitstream will
> be faster then what you have now. Especially on boards which bigger fpga.
I made some modifications to make gzip work, and another one dirty
(non-upstremeable) to make external data work.
Additionally, I added time reporting on three places. The
modifications are attached.
I tested several bitstreams, with different compression levels:
> gzip -c -n >
The results, for a fit image with embedded data, are:
file size (bytes) time1 time2 time3
uncompressed 2,434,112 567 597 623
compressed -1446,028 208 1165 1190
compressed -4407,764 205 1063 1088
compressed -5398,346 203 1094 1119
compressed -9376,821 200 1141 1166
The time for a fit image with external data (-E option for mkimage) is
~100 time units (ms?) less, and time1 remains constant at ~12 time
units.
At least on my setup (Zybo Z7-20), gzip just increase the boot time.
> > I have an idea to automate the FIT generation. The build system could
> > scan for the existence of a file, for example
> > "board/xilinx/zynq//preboot.bin", and add the fpga node
> > automatically (to .its) if the file exists. Because I think that
> > storing .bin files in the U-Boot repository is infeasible. That will
> > require additions and modifications to the current way the build
> > system works, and I'm still thinking how to implement them.
>
> Take a look at pmufw handling for zynqmp for inspiration.
Will do, thanks for the heads up.
Thanks,
Luis Araneda.
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index 8ab6a2def1..95870a7594 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -3,7 +3,6 @@
* Copyright (C) 2016 Google, Inc
* Written by Simon Glass
*/
-
#include
#include
#include
@@ -205,7 +204,7 @@ static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
if (fit_image_get_data_size(fit, node, ))
return -ENOENT;
- load_ptr = (load_addr + align_len) & ~align_len;
+ load_ptr = ((load_addr + align_len) & ~align_len) + 400;
length = len;
overhead = get_aligned_image_overhead(info, offset);
@@ -245,8 +244,7 @@ static int spl_load_fit_image(struct spl_load_info *info, ulong sector,
if (IS_ENABLED(CONFIG_SPL_OS_BOOT) &&
IS_ENABLED(CONFIG_SPL_GZIP) &&
- image_comp == IH_COMP_GZIP &&
- type == IH_TYPE_KERNEL) {
+ image_comp == IH_COMP_GZIP) {
size = length;
if (gunzip((void *)load_addr, CONFIG_SYS_BOOTM_LEN,
src, )) {
@@ -345,6 +343,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
int images, ret;
int base_offset, align_len = ARCH_DMA_MINALIGN - 1;
int index = 0;
+ unsigned long ts = get_timer(0);
/*
* For FIT with external data, figure out where the external images
@@ -380,6 +379,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
sector, sectors, fit, count);
if (count == 0)
return -EIO;
+ printf("time1: %lu\n", get_timer(ts));
/* find the node holding the images information */
images = fdt_path_offset(fit, FIT_IMAGES_PATH);
@@ -398,6 +398,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
printf("%s: Cannot load the FPGA: %i\n", __func__, ret);
return ret;
}
+ printf("time2: %lu\n", get_timer(ts));
debug("FPGA bitstream at: %x, size: %x\n",
(u32)spl_image->load_addr, spl_image->size);
@@ -409,6 +410,7 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
__func__);
return ret;
}
+ printf("time3: %lu\n", get_timer(ts));
puts("FPGA image loaded from FIT\n");
node = -1;
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v3 2/2] disk: part: Remove redundant error message
On Fri, Jul 20, 2018 at 01:28:43AM +0300, Sam Protsenko wrote:
> Underlying API should already print some meaningful error message, so
> this one is just brings more noise. E.g. we can see log like this:
>
> MMC: no card present
> ** Bad device mmc 0 **
>
> Obviously, second error message is unwanted. Let's remove it to make log
> more short and clear.
>
> Signed-off-by: Sam Protsenko
> ---
> disk/part.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/disk/part.c b/disk/part.c
> index 9266a09ec3..0762a0750f 100644
> --- a/disk/part.c
> +++ b/disk/part.c
> @@ -400,7 +400,6 @@ int blk_get_device_by_str(const char *ifname, const char
> *dev_hwpart_str,
>
> *dev_desc = get_dev_hwpart(ifname, dev, hwpart);
> if (!(*dev_desc) || ((*dev_desc)->type == DEV_TYPE_UNKNOWN)) {
> - printf("** Bad device %s %s **\n", ifname, dev_hwpart_str);
> dev = -ENOENT;
> goto cleanup;
> }
We should move this to debug() I think.
--
Tom
signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH v3 2/2] disk: part: Remove redundant error message
Underlying API should already print some meaningful error message, so
this one is just brings more noise. E.g. we can see log like this:
MMC: no card present
** Bad device mmc 0 **
Obviously, second error message is unwanted. Let's remove it to make log
more short and clear.
Signed-off-by: Sam Protsenko
---
disk/part.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/disk/part.c b/disk/part.c
index 9266a09ec3..0762a0750f 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -400,7 +400,6 @@ int blk_get_device_by_str(const char *ifname, const char
*dev_hwpart_str,
*dev_desc = get_dev_hwpart(ifname, dev, hwpart);
if (!(*dev_desc) || ((*dev_desc)->type == DEV_TYPE_UNKNOWN)) {
- printf("** Bad device %s %s **\n", ifname, dev_hwpart_str);
dev = -ENOENT;
goto cleanup;
}
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH v3 1/2] env: Don't print "Failed" error message
This only clutters the log with unnecessary details, as we already have
all needed warnings by the time. Example:
Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)
Remove this "Failed" message to keep log short and clear.
Signed-off-by: Sam Protsenko
---
env/env.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/env/env.c b/env/env.c
index 5c0842ac07..3ab4ec4237 100644
--- a/env/env.c
+++ b/env/env.c
@@ -196,9 +196,7 @@ int env_load(void)
printf("Loading Environment from %s... ", drv->name);
ret = drv->load();
- if (ret)
- printf("Failed (%d)\n", ret);
- else
+ if (!ret)
printf("OK\n");
if (!ret)
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC PATCH v3 0/2] env: Make environment loading log more clear
This is another attempt to make boot log better, without hackery this time. Basically here we just remove unwanted error messages, relying on the message from most deep API to be printed (like mmc subsystem). This approach *might* have its shortcomings, though: 1. With no "Failed" message, at some point we *can* end up with no error messages printed at all 2. Removing some collateral error messages *may* lead to loss of useful debug info in other use-cases (env_load() is not only user of those APIs). That being said, at the moment this looks like most clean solution to cluttered log problem, as any other solution either will be hackish or will require some big architectural changes. If one of mentioned shortcomings occur, we can fix it ad hoc. With this patch set applied we will see something like this: Loading Environment from FAT... MMC: no card present Loading Environment from MMC... OK instead of: Loading Environment from FAT... MMC: no card present ** Bad device mmc 0 ** Failed (-5) Loading Environment from MMC... OK Sam Protsenko (2): env: Don't print "Failed" error message disk: part: Remove redundant error message disk/part.c | 1 - env/env.c | 4 +--- 2 files changed, 1 insertion(+), 4 deletions(-) -- 2.18.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/6] board: ge: Move VPD EEPROM configuration to the defconfig
Hi Tom, On Thu, Jul 19, 2018 at 04:31:01PM -0400, Tom Rini wrote: > On Tue, Jun 26, 2018 at 07:43:00PM +0200, Sebastian Reichel wrote: > > > From: Denis Zalevskiy > > > > Use standard configuration logic to define EEPROM constants. Names are > > based on > > VPD_EEPROM_ prefix because EEPROM_ is already used by i2c_eeprom driver. > > > > Signed-off-by: Denis Zalevskiy > > Signed-off-by: Sebastian Reichel > > --- > > board/ge/bx50v3/Kconfig | 2 ++ > > board/ge/bx50v3/bx50v3.c| 17 - > > board/ge/mx53ppd/Kconfig| 2 ++ > > board/ge/mx53ppd/mx53ppd.c | 14 -- > > configs/ge_bx50v3_defconfig | 9 + > > configs/mx53ppd_defconfig | 10 ++ > > 6 files changed, 31 insertions(+), 23 deletions(-) > > > > diff --git a/board/ge/bx50v3/Kconfig b/board/ge/bx50v3/Kconfig > > index 993b0559302b..05938560abda 100644 > > --- a/board/ge/bx50v3/Kconfig > > +++ b/board/ge/bx50v3/Kconfig > > @@ -15,4 +15,6 @@ config SYS_SOC > > config SYS_CONFIG_NAME > > default "ge_bx50v3" > > > > +source "board/ge/common/Kconfig" > > The new file board/ge/common/Kconfig is missing, please repost the > series with the file added, thanks! Oops, I just wondered how my test-built worked, but it's just me being too stupid to read git output Untracked files: (use "git add ..." to include in what will be committed) board/ge/common/Kconfig Anyways, thanks for the review, I will resend the series! -- Sebastian signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] binman: ensure temp filenames don't collide
On 07/18/2018 07:32 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 16 July 2018 at 16:51, Stephen Warren wrote:
>> From: Stephen Warren
>>
>> The U-Boot Makefile can invoke binman multiple times in parallel. This
>> is problematic because binman uses a static hard-coded temporary file
>> name. If two instances of binman use that filename at the same time, one
>> writing one reading, they may silently read the wrong content or actively
>> detect missing signatures and error out the build process. Fix this by
>> using a PID-specific filename instead.
>>
>> Signed-off-by: Stephen Warren
>> ---
>> tools/binman/control.py | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tools/binman/control.py b/tools/binman/control.py
>> index a40b300fdacb..515999278949 100644
>> --- a/tools/binman/control.py
>> +++ b/tools/binman/control.py
>> @@ -121,7 +121,7 @@ def Binman(options, args):
>> # output into a file in our output directly. Then scan it for
>> use
>> # in binman.
>> dtb_fname = fdt_util.EnsureCompiled(dtb_fname)
>> -fname = tools.GetOutputFilename('u-boot-out.dtb')
>> +fname = tools.GetOutputFilename('u-boot-out.dtb') +
>> str(os.getpid())
>> with open(dtb_fname) as infd:
>> with open(fname, 'wb') as outfd:
>> outfd.write(infd.read())
>> --
>> 2.18.0
>>
>
> But the output directory is itself (normally) a temporary dir. That
> determines the directly which GetOutputFilename() uses. So I am not
> sure how this can happen in practice?
IIRC, the output directory for all 3 files was the same; the root of the
build output directory. Perhaps the fact I run "make O=build-xxx" rather
than just "make" makes a difference?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 6/7] tpm: make TPM_V2 be compiled by default
TPM_V1 was already compiled by default. Now that both can be compiled at the same time, compiled them both by default. Signed-off-by: Miquel Raynal Reviewed-by: Simon Glass --- drivers/tpm/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tpm/Kconfig b/drivers/tpm/Kconfig index 782a620f91..94629dffd2 100644 --- a/drivers/tpm/Kconfig +++ b/drivers/tpm/Kconfig @@ -120,6 +120,7 @@ endif # TPM_V1 config TPM_V2 bool "TPMv2.x support" depends on TPM + default y help Major TPM versions are not compatible at all, choose either one or the other. This option enables TPMv2.x drivers/commands. -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 5/7] test/py: tpm2: switch from 'tpm' to 'tpm2' command
While using the 'tpm' command should work on most cases, this test suite
only works with TPMv2 and since the work to make both versions build at
the same time, we might end up having both 'tpm' (TPMv1) and 'tpm2'
(TPMv2) commands available at the same time. Ensure this test suite
always use the right one.
Signed-off-by: Miquel Raynal
Reviewed-by: Simon Glass
---
test/py/tests/test_tpm2.py | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/test/py/tests/test_tpm2.py b/test/py/tests/test_tpm2.py
index 01ffb3178d..3e1f42d83e 100644
--- a/test/py/tests/test_tpm2.py
+++ b/test/py/tests/test_tpm2.py
@@ -29,22 +29,22 @@ def force_init(u_boot_console, force=False):
twice will spawn an error used to detect that the TPM was not reset and no
initialization code should be run.
"""
-output = u_boot_console.run_command('tpm init')
+output = u_boot_console.run_command('tpm2 init')
if force or not 'Error' in output:
u_boot_console.run_command('echo --- start of init ---')
-u_boot_console.run_command('tpm startup TPM2_SU_CLEAR')
-u_boot_console.run_command('tpm self_test full')
-u_boot_console.run_command('tpm clear TPM2_RH_LOCKOUT')
+u_boot_console.run_command('tpm2 startup TPM2_SU_CLEAR')
+u_boot_console.run_command('tpm2 self_test full')
+u_boot_console.run_command('tpm2 clear TPM2_RH_LOCKOUT')
output = u_boot_console.run_command('echo $?')
if not output.endswith('0'):
-u_boot_console.run_command('tpm clear TPM2_RH_PLATFORM')
+u_boot_console.run_command('tpm2 clear TPM2_RH_PLATFORM')
u_boot_console.run_command('echo --- end of init ---')
@pytest.mark.buildconfigspec('cmd_tpm_v2')
def test_tpm2_init(u_boot_console):
"""Init the software stack to use TPMv2 commands."""
-u_boot_console.run_command('tpm init')
+u_boot_console.run_command('tpm2 init')
output = u_boot_console.run_command('echo $?')
assert output.endswith('0')
@@ -55,7 +55,7 @@ def test_tpm2_startup(u_boot_console):
Initiate the TPM internal state machine.
"""
-u_boot_console.run_command('tpm startup TPM2_SU_CLEAR')
+u_boot_console.run_command('tpm2 startup TPM2_SU_CLEAR')
output = u_boot_console.run_command('echo $?')
assert output.endswith('0')
@@ -66,7 +66,7 @@ def test_tpm2_self_test_full(u_boot_console):
Ask the TPM to perform all self tests to also enable full capabilities.
"""
-u_boot_console.run_command('tpm self_test full')
+u_boot_console.run_command('tpm2 self_test full')
output = u_boot_console.run_command('echo $?')
assert output.endswith('0')
@@ -78,7 +78,7 @@ def test_tpm2_continue_self_test(u_boot_console):
to enter a fully operational state.
"""
-u_boot_console.run_command('tpm self_test continue')
+u_boot_console.run_command('tpm2 self_test continue')
output = u_boot_console.run_command('echo $?')
assert output.endswith('0')
@@ -95,11 +95,11 @@ def test_tpm2_clear(u_boot_console):
PLATFORM hierarchies are also available.
"""
-u_boot_console.run_command('tpm clear TPM2_RH_LOCKOUT')
+u_boot_console.run_command('tpm2 clear TPM2_RH_LOCKOUT')
output = u_boot_console.run_command('echo $?')
assert output.endswith('0')
-u_boot_console.run_command('tpm clear TPM2_RH_PLATFORM')
+u_boot_console.run_command('tpm2 clear TPM2_RH_PLATFORM')
output = u_boot_console.run_command('echo $?')
assert output.endswith('0')
@@ -115,13 +115,13 @@ def test_tpm2_change_auth(u_boot_console):
force_init(u_boot_console)
-u_boot_console.run_command('tpm change_auth TPM2_RH_LOCKOUT unicorn')
+u_boot_console.run_command('tpm2 change_auth TPM2_RH_LOCKOUT unicorn')
output = u_boot_console.run_command('echo $?')
assert output.endswith('0')
-u_boot_console.run_command('tpm clear TPM2_RH_LOCKOUT unicorn')
+u_boot_console.run_command('tpm2 clear TPM2_RH_LOCKOUT unicorn')
output = u_boot_console.run_command('echo $?')
-u_boot_console.run_command('tpm clear TPM2_RH_PLATFORM')
+u_boot_console.run_command('tpm2 clear TPM2_RH_PLATFORM')
assert output.endswith('0')
@pytest.mark.buildconfigspec('cmd_tpm_v2')
@@ -140,7 +140,7 @@ def test_tpm2_get_capability(u_boot_console):
force_init(u_boot_console)
ram = u_boot_utils.find_ram_base(u_boot_console)
-read_cap = u_boot_console.run_command('tpm get_capability 0x6 0x20e 0x200
1') #0x%x 1' % ram)
+read_cap = u_boot_console.run_command('tpm2 get_capability 0x6 0x20e 0x200
1') #0x%x 1' % ram)
output = u_boot_console.run_command('echo $?')
assert output.endswith('0')
assert 'Property 0x020e: 0x' in read_cap
@@ -163,12 +163,12 @@ def test_tpm2_dam_parameters(u_boot_console):
ram = u_boot_utils.find_ram_base(u_boot_console)
# Set the DAM parameters to known
[U-Boot] [PATCH v2 4/7] tpm: allow TPM v1 and v2 to be compiled at the same time
While there is probably no reason to do so in a real life situation, it
will allow to compile test both stacks with the same sandbox defconfig.
As we cannot define two 'tpm' commands at the same time, the command for
TPM v1 is still called 'tpm' and the one for TPM v2 'tpm2'. While this
is the exact command name that must be written into eg. test files, any
user already using the TPM v2 stack can continue to do so by just writing
'tpm' because as long as TPM v1 support is not compiled, U-Boot prompt
will search for the closest command named after 'tpm'.
The command set can also be changed at runtime (not supported yet, but
ready to be), but as one can compile only either one stack or the other,
there is still one spot in the code where conditionals are used: to
retrieve the v1 or v2 command set.
Signed-off-by: Miquel Raynal
---
cmd/tpm-common.c | 24 +++-
cmd/tpm-v1.c | 2 +-
cmd/tpm-v2.c | 4 ++--
drivers/tpm/Kconfig| 7 ++-
drivers/tpm/tpm-uclass.c | 3 ---
drivers/tpm/tpm2_tis_sandbox.c | 3 +++
drivers/tpm/tpm2_tis_spi.c | 4
include/tpm-common.h | 40 ++--
8 files changed, 69 insertions(+), 18 deletions(-)
diff --git a/cmd/tpm-common.c b/cmd/tpm-common.c
index 6cf9fcc9ac..56443862c2 100644
--- a/cmd/tpm-common.c
+++ b/cmd/tpm-common.c
@@ -273,12 +273,34 @@ int do_tpm_init(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
int do_tpm(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
cmd_tbl_t *tpm_commands, *cmd;
+ struct tpm_chip_priv *priv;
+ struct udevice *dev;
unsigned int size;
+ int ret;
if (argc < 2)
return CMD_RET_USAGE;
- tpm_commands = get_tpm_commands();
+ ret = get_tpm();
+ if (ret)
+ return ret;
+
+ priv = dev_get_uclass_priv(dev);
+
+ /* Below getters return NULL if the desired stack is not built */
+ switch (priv->version) {
+ case TPM_V1:
+ tpm_commands = get_tpm1_commands();
+ break;
+ case TPM_V2:
+ tpm_commands = get_tpm2_commands();
+ break;
+ default:
+ tpm_commands = NULL;
+ }
+
+ if (!tpm_commands)
+ return CMD_RET_USAGE;
cmd = find_cmd_tbl(argv[1], tpm_commands, size);
if (!cmd)
diff --git a/cmd/tpm-v1.c b/cmd/tpm-v1.c
index 0874c4d7ba..69870002d4 100644
--- a/cmd/tpm-v1.c
+++ b/cmd/tpm-v1.c
@@ -608,7 +608,7 @@ static cmd_tbl_t tpm1_commands[] = {
#endif /* CONFIG_TPM_LIST_RESOURCES */
};
-cmd_tbl_t *get_tpm_commands(unsigned int *size)
+cmd_tbl_t *get_tpm1_commands(unsigned int *size)
{
*size = ARRAY_SIZE(tpm1_commands);
diff --git a/cmd/tpm-v2.c b/cmd/tpm-v2.c
index 38add4f462..ffbf35a75c 100644
--- a/cmd/tpm-v2.c
+++ b/cmd/tpm-v2.c
@@ -319,14 +319,14 @@ static cmd_tbl_t tpm2_commands[] = {
do_tpm_pcr_setauthvalue, "", ""),
};
-cmd_tbl_t *get_tpm_commands(unsigned int *size)
+cmd_tbl_t *get_tpm2_commands(unsigned int *size)
{
*size = ARRAY_SIZE(tpm2_commands);
return tpm2_commands;
}
-U_BOOT_CMD(tpm, CONFIG_SYS_MAXARGS, 1, do_tpm, "Issue a TPMv2.x command",
+U_BOOT_CMD(tpm2, CONFIG_SYS_MAXARGS, 1, do_tpm, "Issue a TPMv2.x command",
" []\n"
"\n"
"info\n"
diff --git a/drivers/tpm/Kconfig b/drivers/tpm/Kconfig
index da1ed8fd87..782a620f91 100644
--- a/drivers/tpm/Kconfig
+++ b/drivers/tpm/Kconfig
@@ -4,9 +4,6 @@
menu "TPM support"
-comment "Please select only one TPM revision"
- depends on TPM_V1 && TPM_V2
-
config TPM_V1
bool "TPMv1.x support"
depends on TPM
@@ -15,7 +12,7 @@ config TPM_V1
Major TPM versions are not compatible at all, choose either
one or the other. This option enables TPMv1.x drivers/commands.
-if TPM_V1 && !TPM_V2
+if TPM_V1
config TPM_TIS_SANDBOX
bool "Enable sandbox TPM driver"
@@ -127,7 +124,7 @@ config TPM_V2
Major TPM versions are not compatible at all, choose either
one or the other. This option enables TPMv2.x drivers/commands.
-if TPM_V2 && !TPM_V1
+if TPM_V2
config TPM2_TIS_SANDBOX
bool "Enable sandbox TPMv2.x driver"
diff --git a/drivers/tpm/tpm-uclass.c b/drivers/tpm/tpm-uclass.c
index 412697eedc..c83f53ab86 100644
--- a/drivers/tpm/tpm-uclass.c
+++ b/drivers/tpm/tpm-uclass.c
@@ -7,11 +7,8 @@
#include
#include
#include
-#if defined(CONFIG_TPM_V1)
#include
-#elif defined(CONFIG_TPM_V2)
#include
-#endif
#include "tpm_internal.h"
int tpm_open(struct udevice *dev)
diff --git a/drivers/tpm/tpm2_tis_sandbox.c b/drivers/tpm/tpm2_tis_sandbox.c
index 3240cc5dba..532d27ddd9 100644
--- a/drivers/tpm/tpm2_tis_sandbox.c
+++ b/drivers/tpm/tpm2_tis_sandbox.c
@@ -590,6 +590,9 @@ static int sandbox_tpm2_probe(struct udevice *dev)
struct sandbox_tpm2 *tpm =
[U-Boot] [PATCH v2 7/7] sandbox: compile both TPM stack versions and drivers
Now that TPMv1 and TPMv2 can be compiled at the same time, let's compile them both with Sandbox as well as both drivers (and, it is already implied in Kconfig: both commands). Signed-off-by: Miquel Raynal Reviewed-by: Simon Glass --- configs/sandbox_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig index 2fc84a16c9..d5756d1173 100644 --- a/configs/sandbox_defconfig +++ b/configs/sandbox_defconfig @@ -176,6 +176,7 @@ CONFIG_TIMER=y CONFIG_TIMER_EARLY=y CONFIG_SANDBOX_TIMER=y CONFIG_TPM_TIS_SANDBOX=y +CONFIG_TPM2_TIS_SANDBOX=y CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_EMUL=y @@ -192,6 +193,8 @@ CONFIG_FS_CBFS=y CONFIG_FS_CRAMFS=y CONFIG_CMD_DHRYSTONE=y CONFIG_TPM=y +CONFIG_TPM_V1=y +CONFIG_TPM_V2=y CONFIG_LZ4=y CONFIG_ERRNO_STR=y CONFIG_OF_LIBFDT_OVERLAY=y -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/7] tpm: fix typo in kernel doc
The udevice given to the open() function of course must be opened,
not closed.
Signed-off-by: Miquel Raynal
Reviewed-by: Simon Glass
---
include/tpm-common.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/tpm-common.h b/include/tpm-common.h
index 734c2c9d53..68bf8fd627 100644
--- a/include/tpm-common.h
+++ b/include/tpm-common.h
@@ -71,7 +71,7 @@ struct tpm_ops {
* After all commands have been completed the caller should call
* close().
*
-* @dev:Device to close
+* @dev:Device to open
* @return 0 ok OK, -ve on error
*/
int (*open)(struct udevice *dev);
--
2.14.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 3/7] tpm: remove stale symbol in Kconfig
The TPM_DRIVER_SELECTED symbol was used in one of the initial series about TPMv2 but its use has been dropped, making these selects useless, remove them. Signed-off-by: Miquel Raynal --- drivers/tpm/Kconfig | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/tpm/Kconfig b/drivers/tpm/Kconfig index 5e3fb3267f..da1ed8fd87 100644 --- a/drivers/tpm/Kconfig +++ b/drivers/tpm/Kconfig @@ -63,7 +63,6 @@ config TPM_TIS_I2C_BURST_LIMITATION_LEN config TPM_TIS_LPC bool "Enable support for Infineon SLB9635/45 TPMs on LPC" depends on TPM_V1 && X86 - select TPM_DRIVER_SELECTED help This driver supports Infineon TPM devices connected on the LPC bus. The usual tpm operations and the 'tpm' command can be used to talk @@ -134,7 +133,6 @@ config TPM2_TIS_SANDBOX bool "Enable sandbox TPMv2.x driver" depends on TPM_V2 && SANDBOX default y - select TPM_DRIVER_SELECTED help This driver emulates a TPMv2.x, providing access to base functions such as basic configuration, PCR extension and PCR read. Extended @@ -143,7 +141,6 @@ config TPM2_TIS_SANDBOX config TPM2_TIS_SPI bool "Enable support for TPMv2.x SPI chips" depends on TPM_V2 && DM_SPI - select TPM_DRIVER_SELECTED help This driver supports TPMv2.x devices connected on the SPI bus. The usual TPM operations and the 'tpm' command can be used to talk -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/7] tpm: compile Sandbox driver by default
When Sandbox and the TPM stack are both selected, compile Sandbox TPM driver by default. Signed-off-by: Miquel Raynal Reviewed-by: Simon Glass --- drivers/tpm/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/tpm/Kconfig b/drivers/tpm/Kconfig index 93264ddd34..5e3fb3267f 100644 --- a/drivers/tpm/Kconfig +++ b/drivers/tpm/Kconfig @@ -20,6 +20,7 @@ if TPM_V1 && !TPM_V2 config TPM_TIS_SANDBOX bool "Enable sandbox TPM driver" depends on TPM_V1 && SANDBOX + default y help This driver emulates a TPMv1.x, providing access to base functions such as reading and writing TPM private data. This is enough to @@ -132,6 +133,7 @@ if TPM_V2 && !TPM_V1 config TPM2_TIS_SANDBOX bool "Enable sandbox TPMv2.x driver" depends on TPM_V2 && SANDBOX + default y select TPM_DRIVER_SELECTED help This driver emulates a TPMv2.x, providing access to base functions -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 0/7] Allow both TPM stacks to be compiled at the same time
It was first decided that the user would choose the TPM version (1.x or 2.x) that he wants to use at compile time. After some time the decision has been made to change this and allow both stacks (and drivers) to be compiled at the same time. The primary benefit would be to be able to compile the maximum of code with only one Sandbox configuration. This series removes this limitation by creating a 'tpm2' command (instead of two commands named 'tpm'). While test suites must be updated to use 'tpm2' instead of 'tpm' (in case both stacks are compiled), the user will not have to change anything as U-Boot prompt will find the closest matching command by default. In the TPM private data a version entry is added, updated by TPMv2 drivers in the ->set_version() hook added in the uclass. This has been tested with the tpm2.py test suite on Sandbox with either only the V1, only the V2 and with both versions selected. Thanks, Miquèl Changes since v1: = * Added Simon's Reviewed-by tags. * Added a patch to remove TPM_DRIVER_SELECTED stale symbol from Kconfig. * s/int rc/int ret/ * Removed conditionals from the code. * Moved the TPM stack version selection in the probe, removed the ->set_version() helper. Miquel Raynal (7): tpm: fix typo in kernel doc tpm: compile Sandbox driver by default tpm: remove stale symbol in Kconfig tpm: allow TPM v1 and v2 to be compiled at the same time test/py: tpm2: switch from 'tpm' to 'tpm2' command tpm: make TPM_V2 be compiled by default sandbox: compile both TPM stack versions and drivers cmd/tpm-common.c | 24 +++- cmd/tpm-v1.c | 2 +- cmd/tpm-v2.c | 4 ++-- configs/sandbox_defconfig | 3 +++ drivers/tpm/Kconfig| 13 + drivers/tpm/tpm-uclass.c | 3 --- drivers/tpm/tpm2_tis_sandbox.c | 3 +++ drivers/tpm/tpm2_tis_spi.c | 4 include/tpm-common.h | 42 +++--- test/py/tests/test_tpm2.py | 40 10 files changed, 96 insertions(+), 42 deletions(-) -- 2.14.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] tpm: allow TPM v1 and v2 to be compiled at the same time
Hi Simon,
Simon Glass wrote on Wed, 18 Jul 2018 19:31:41 -0600:
> Hi Miquel,
>
> On 14 July 2018 at 06:16, Miquel Raynal wrote:
> > While there is probably no reason to do so in a real life situation, it
> > will allow to compile test both stacks with the same sandbox defconfig.
> >
> > As we cannot define two 'tpm' commands at the same time, the command for
> > TPM v1 is still called 'tpm' and the one for TPM v2 'tpm2'. While this
> > is the exact command name that must be written into eg. test files, any
> > user already using the TPM v2 stack can continue using just 'tpm' as
> > command as long as TPM v1 support is not compiled (because U-Boot prompt
> > will search for the closest command named after 'tpm'.b)
> >
> > The command set can also be changed at runtime (not supported yet, but
> > ready to be), but as one can compile only either one stack or the other,
> > there is still one spot in the code where conditionals are used: to
> > retrieve the v1 or v2 command set.
> >
> > Signed-off-by: Miquel Raynal
> > ---
> > cmd/tpm-common.c | 24 +++-
> > cmd/tpm-v1.c | 2 +-
> > cmd/tpm-v2.c | 4 ++--
> > drivers/tpm/Kconfig| 7 ++-
> > drivers/tpm/tpm-uclass.c | 13 ++---
> > drivers/tpm/tpm2_tis_sandbox.c | 11 +++
> > drivers/tpm/tpm2_tis_spi.c | 15 +++
> > include/tpm-common.h | 36 ++--
> > lib/tpm-common.c | 4
> > lib/tpm-utils.h| 9 +
> > 10 files changed, 107 insertions(+), 18 deletions(-)
> >
>
> Reviewed-by: Simon Glass
>
> Some comments below.
>
> > diff --git a/cmd/tpm-common.c b/cmd/tpm-common.c
> > index 6cf9fcc9ac..69cc02b599 100644
> > --- a/cmd/tpm-common.c
> > +++ b/cmd/tpm-common.c
> > @@ -273,12 +273,34 @@ int do_tpm_init(cmd_tbl_t *cmdtp, int flag, int argc,
> > char * const argv[])
> > int do_tpm(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> > {
> > cmd_tbl_t *tpm_commands, *cmd;
> > + struct tpm_chip_priv *priv;
> > + struct udevice *dev;
> > unsigned int size;
> > + int rc;
>
> Can we use 'ret'? That is more common.
Of course.
>
> >
> > if (argc < 2)
> > return CMD_RET_USAGE;
> >
> > - tpm_commands = get_tpm_commands();
> > + rc = get_tpm();
> > + if (rc)
> > + return rc;
> > +
> > + priv = dev_get_uclass_priv(dev);
> > +
> > + switch (priv->version) {
> > +#if defined(CONFIG_TPM_V1)
> > + case TPM_V1:
>
> if (IS_ENABLED(CONFIG_TPM_V1))
>
> (I think #ifdef is worse)
Actually, in the present state, get_tpmx_commands symbol is only
available if the file if TPM_Vx is selected in Kconfig.
I created two dummy functions in tpm-common.h which return NULL for
each symbol if their respective TPM version is not compiled. This way it
removes any conditionals in the code.
>
> > + tpm_commands = get_tpm1_commands();
> > + break;
> > +#endif
> > +#if defined(CONFIG_TPM_V2)
> > + case TPM_V2:
> > + tpm_commands = get_tpm2_commands();
> > + break;
> > +#endif
> > + default:
> > + return CMD_RET_USAGE;
> > + }
[...]
> >
> > +static int sandbox_tpm2_set_version(struct udevice *dev)
> > +{
> > + struct tpm_chip_priv *priv = dev_get_uclass_priv(dev);
> > +
> > + /* Use the TPM v2 stack */
> > + priv->version = TPM_V2;
>
> Don't you think this could be done in the probe() method?
When I first wrote this I faced some issues. As I did not remembered
why it would fail I tried again and indeed, moving this
selection in the probe works.
>
> > +
> > + return 0;
> > +}
> > +
[...]
> > @@ -65,6 +78,16 @@ struct tpm_chip_priv {
> > * to bytes which are sent and received.
> > */
> > struct tpm_ops {
> > + /**
> > +* set_version() - Set the right TPM stack version to use
> > +*
> > +* Default is TPM_V1. TPM of newer versions can implement this
> > +* optional hook to set another value.
> > +*
> > +* @dev:TPM device
> > +*/
> > + int (*set_version)(struct udevice *dev);
>
> I think this could just be a helper function provided by the uclass,
> rather than a device method.
Actually there is no need for this hook or any helper anymore, I
removed them all as the version selection is done in the driver
->probe().
I'll let other people that would need to change the version at runtime
adding support for that if they want, it should not be too tricky
anyway.
Thanks,
Miquèl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, 2/6] board: ge: Move VPD EEPROM configuration to the defconfig
On Tue, Jun 26, 2018 at 07:43:00PM +0200, Sebastian Reichel wrote: > From: Denis Zalevskiy > > Use standard configuration logic to define EEPROM constants. Names are based > on > VPD_EEPROM_ prefix because EEPROM_ is already used by i2c_eeprom driver. > > Signed-off-by: Denis Zalevskiy > Signed-off-by: Sebastian Reichel > --- > board/ge/bx50v3/Kconfig | 2 ++ > board/ge/bx50v3/bx50v3.c| 17 - > board/ge/mx53ppd/Kconfig| 2 ++ > board/ge/mx53ppd/mx53ppd.c | 14 -- > configs/ge_bx50v3_defconfig | 9 + > configs/mx53ppd_defconfig | 10 ++ > 6 files changed, 31 insertions(+), 23 deletions(-) > > diff --git a/board/ge/bx50v3/Kconfig b/board/ge/bx50v3/Kconfig > index 993b0559302b..05938560abda 100644 > --- a/board/ge/bx50v3/Kconfig > +++ b/board/ge/bx50v3/Kconfig > @@ -15,4 +15,6 @@ config SYS_SOC > config SYS_CONFIG_NAME > default "ge_bx50v3" > > +source "board/ge/common/Kconfig" The new file board/ge/common/Kconfig is missing, please repost the series with the file added, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [U-Boot, v2] spl: Kconfig: SPL_LOAD_FIT_ADDRESS to Kconfig
On Tue, Jun 26, 2018 at 05:55:58PM +0100, Ibai Erkiaga wrote: > Create a new KConfig entry to define FIT image position for > SPL RAM mode. > > Signed-off-by: Ibai Erkiaga > --- > > Changes in v2: > -Converted zynqmp and dra7xx_evm defconfig files The changes I request against v1 (sorry) still need to be addressed, thanks. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Xilinx changes for v2018.09
On Thu, Jul 19, 2018 at 05:11:40PM +0200, Michal Simek wrote: > Hi Tom, > > please pull these changes to your tree. > Buildman and travis looks good > https://travis-ci.org/michalsimek/u-boot/builds/405716862 > > My pull request contains some change out of xilinx folders because one > function name has been changed. I got a confirmation from Marek to go > with this to the tree. > And also some small changes in common area which were reviewed. usb_kdb > is an exception because probably none cares. > > You can find more details below. > > Thanks, > Michal > > > The following changes since commit 1adbf2966adebe67de3dd17094749d387604194e: > > Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2018-07-17 > 14:28:47 -0400) > > are available in the git repository at: > > > git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-for-v2018.09 > > for you to fetch changes up to 577012da71ea9dcf07272c7f458218aa8ab29984: > > arm: zynq: spl: fix FPGA initialization (2018-07-19 10:49:57 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 2/2] env: Add prefix to error messages when loading env
On Thu, Jul 19, 2018 at 10:52 PM, Wolfgang Denk wrote: > Dear Sam, > > In message > you > wrote: >> >> Also, I figured how to do prefixing (to display MMC errors as nested >> w.r.t. "Loading environment), without adding new field to gd. We can >> just add some new GD_LG_ and print prefix when it's installed. I'm >> gonna send new RFC soon. Please let me know what you think about [1]. > > This is IMO a totally wrong approach. We don't want to add more > code (and more output) jsut to paper over inconsistent error > reporting. This problem should be fixed at the root cause, i. e. > we should report errors where they are detected, and only once. > If all callers can rely that, in the error path, their callees which > return error codes, have already printed appropriate messages, there > is no need to print even more lines. > > What we need is not fancy code, but consistent (and consequent) > error handling. > As a matter of fact, that was first thing that came into my mind when I started looking into this (and actually I mentioned that way in my first RFC, I guess). I will try to investigate it further and come back with more meaningful patch. My concern w.r.t. this approach is next: if we suppress consequent warning messages, there might be some other use-case (other than loading environment), where there is another caller of that API, and we would just lose all error messages at all. I'll try to check if we have such cases as well. Overall: agree with your review, thanks. > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > "One day," said a dull voice from down below, "I'm going to be back > in form again and you're going to be very sorry you said that. For a > very long time. I might even go so far as to make even more Time just > for you to be sorry in." - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC v2] env: Fix errors printing on env loading
Dear Sam Protsenko, In message <20180719193028.814-1-semen.protse...@linaro.org> you wrote: > This is just a draft to discuss ideas related to "Make U-Boot log great > again" thread. > > With this patch we will have something like this: > > Attempting to load environment from FAT: > -> MMC: no card present > -> ** Bad device mmc 0 ** > -> Failed (-5) > Attempting to load environment from MMC: OK > > instead of this: > > Loading Environment from FAT... MMC: no card present > ** Bad device mmc 0 ** > Failed (-5) > Loading Environment from MMC... OK > > Two things were done in this patch: > - print messages from drivers in nested style (with "->" prefix); to do >so, add GD_FLG_PR_PREFIX flag and check it in puts() > - make "OK" to be printed on the same line as main message; to do so, >issue ASCII escape codes [1] to move cursor back to main message line Naked-by: Wolfgang Denk Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The IQ of the group is the lowest IQ of a member of the group divided by the number of people in the group. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 2/2] env: Add prefix to error messages when loading env
Dear Sam, In message you wrote: > > Also, I figured how to do prefixing (to display MMC errors as nested > w.r.t. "Loading environment), without adding new field to gd. We can > just add some new GD_LG_ and print prefix when it's installed. I'm > gonna send new RFC soon. Please let me know what you think about [1]. This is IMO a totally wrong approach. We don't want to add more code (and more output) jsut to paper over inconsistent error reporting. This problem should be fixed at the root cause, i. e. we should report errors where they are detected, and only once. If all callers can rely that, in the error path, their callees which return error codes, have already printed appropriate messages, there is no need to print even more lines. What we need is not fancy code, but consistent (and consequent) error handling. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de "One day," said a dull voice from down below, "I'm going to be back in form again and you're going to be very sorry you said that. For a very long time. I might even go so far as to make even more Time just for you to be sorry in." - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 2/2] env: Add prefix to error messages when loading env
Dear Tom, In message <20180719125230.GJ4609@bill-the-cat> you wrote: > > > > > Loading Environment from FAT... MMC: no card present > > > > ** Bad device mmc 0 ** > > > > Failed (-5) > > > > Loading Environment from MMC... OK ... > > In the non-error case, the output should be a single (ideally short) > > line. > > > > Rationale: to many lines of ourput clutter your screen and make you > > miss context faster; to many/long lines take time to print so they > > make booting slower. > > > > In the error case, the user should be able to understand what the > > problem was and decide if it was critical or can be ignored (like > > here when intentionally booting without SDCard). > > I understand, but I don't know if we can get there still. The problem > is we don't know if we've succeeded until we've done the relevant > probing and that in turn is what's breaking the single line, and got us > to where we are now. Well, IMO the approach should be the other way round - think about where we print errror messages, and when. In the example above the "MMC: no card present" makes most sense. When we come to printing the "** Bad device mmc 0 **" we should be in an error path, where all possible causes have already printed an appropriate message, so this line can be removed. Ditto for the "Failed (-5)" which is pretty useless anyway - if error handling was consequent, this message should never be needed, as all error paths ending there would have printed proper messages long before. So instead of adding prefixes or fancy postformatting we should clean up error handling and use a consistent style to report the errors where they are found and the causes for the errors are known. Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Die meisten Menschen pflegen im Kindesalter vom Zeigen auf Gegenstän- de (Mausbewegung) und "ga" sagen (Mausklick) abzukommen, zugunsten eines mächtigeren und langwierig zu erlernenden Tools (Sprache). -- Achim Linder in de.comp.os.linux.misc ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC] env: Fix errors printing on env loading
Dear Sam, In message <20180718213736.22650-1-semen.protse...@linaro.org> you wrote: > This is just a draft to discuss ideas related to "Make U-Boot log great > again" thread. > > With this patch we will have something like this: > > Attempting to load environment from FAT: > MMC: no card present > ** Bad device mmc 0 ** > Failed (-5) > Attempting to load environment from MMC: OK > > instead of this: > > Loading Environment from FAT... MMC: no card present > ** Bad device mmc 0 ** > Failed (-5) > Loading Environment from MMC... OK The new output is worse, as it consumes even more lines of output. > The only way I see to do so is to use ASCII escape codes for moving the > cursor (in non-error case). NAK!!! Please keep in mind that output usually goes to a serial port, and should not assume any speific "terminal" capabilities. Even simple in-line "editing" like "overprinting by outputting backspace characters causes a LOT of hassle when you try to parse output for example in automatic test suites. Adding more complex terminal control or other fancy stuff (like colors etc) is a _strict_ no, no! > I'd also like to add prefixes to error messages, like it's done in [2], > but it requires adding one pointer to global data struct. As I explained befoire, this has a lot of negative consequences. You think about beauty, but please keep functionality and efficiency (boot time) in mind! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There's an old proverb that says just about whatever you want it to. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC v2] env: Fix errors printing on env loading
This is just a draft to discuss ideas related to "Make U-Boot log great
again" thread.
With this patch we will have something like this:
Attempting to load environment from FAT:
-> MMC: no card present
-> ** Bad device mmc 0 **
-> Failed (-5)
Attempting to load environment from MMC: OK
instead of this:
Loading Environment from FAT... MMC: no card present
** Bad device mmc 0 **
Failed (-5)
Loading Environment from MMC... OK
Two things were done in this patch:
- print messages from drivers in nested style (with "->" prefix); to do
so, add GD_FLG_PR_PREFIX flag and check it in puts()
- make "OK" to be printed on the same line as main message; to do so,
issue ASCII escape codes [1] to move cursor back to main message line
[1] https://en.wikipedia.org/wiki/ANSI_escape_code#CSI_sequences
Signed-off-by: Sam Protsenko
---
common/console.c | 6 ++
env/env.c | 17 +
include/asm-generic/global_data.h | 1 +
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/common/console.c b/common/console.c
index 2ba33dc574..a0db0ffea6 100644
--- a/common/console.c
+++ b/common/console.c
@@ -533,6 +533,12 @@ void putc(const char c)
void puts(const char *s)
{
+ if (gd->flags & GD_FLG_PR_PREFIX) {
+ gd->flags &= ~GD_FLG_PR_PREFIX;
+ puts(" -> ");
+ gd->flags |= GD_FLG_PR_PREFIX;
+ }
+
#ifdef CONFIG_DEBUG_UART
if (!gd || !(gd->flags & GD_FLG_SERIAL_READY)) {
while (*s) {
diff --git a/env/env.c b/env/env.c
index 5c0842ac07..ff044ccee1 100644
--- a/env/env.c
+++ b/env/env.c
@@ -187,6 +187,7 @@ int env_load(void)
for (prio = 0; (drv = env_driver_lookup(ENVOP_LOAD, prio)); prio++) {
int ret;
+ char msg[75];
if (!drv->load)
continue;
@@ -194,12 +195,20 @@ int env_load(void)
if (!env_has_inited(drv->location))
continue;
- printf("Loading Environment from %s... ", drv->name);
+ snprintf(msg, 75, "Attempting to load environment from %s:\n",
+drv->name);
+ puts(msg);
+ gd->flags |= GD_FLG_PR_PREFIX;
ret = drv->load();
- if (ret)
+ if (ret) {
printf("Failed (%d)\n", ret);
- else
- printf("OK\n");
+ gd->flags &= ~GD_FLG_PR_PREFIX;
+ } else {
+ size_t len = strlen(msg);
+
+ gd->flags &= ~GD_FLG_PR_PREFIX;
+ printf("\033[1A\033[%zuC OK\n", len - 1);
+ }
if (!ret)
return 0;
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 0fd4900392..7e83617664 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -150,5 +150,6 @@ typedef struct global_data {
#define GD_FLG_ENV_DEFAULT 0x02000 /* Default variable flag */
#define GD_FLG_SPL_EARLY_INIT 0x04000 /* Early SPL init is done */
#define GD_FLG_LOG_READY 0x08000 /* Log system is ready for use */
+#define GD_FLG_PR_PREFIX 0x1 /* Print prefix before message */
#endif /* __ASM_GENERIC_GBL_DATA_H */
--
2.18.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 21/25] fastboot: sunxi: Update fastboot mmc default device
On Thu, Jul 19, 2018 at 2:26 PM Maxime Ripard wrote: > > On Wed, Jul 18, 2018 at 08:15:23PM +0100, Alex Kiernan wrote: > > On Tue, Jul 17, 2018 at 12:57 PM Maxime Ripard > > wrote: > > > > > > On Mon, Jul 16, 2018 at 12:11:59PM +0100, Alex Kiernan wrote: > > > > On Mon, Jul 16, 2018 at 11:13 AM Jagan Teki > > > > wrote: > > > > > > > > > > On Mon, Jul 16, 2018 at 3:16 PM, Maxime Ripard > > > > > wrote: > > > > > > On Mon, Jul 16, 2018 at 01:49:52PM +0530, Jagan Teki wrote: > > > > > >> Usually eMMC is default env fat device for environment, > > > > > >> if MMC_SUNXI_SLOT_EXTRA != 1 Sunxi always probed emmc > > > > > >> device as 1. but with DM_MMC it can be more possible to > > > > > >> probe eMMC as device 2 since for most of the sunxi platforms > > > > > >> eMMC is configured mmc2. > > > > > >> > > > > > >> So update the fastboot mmc default device as 2 if DM_MMC and > > > > > >> MMC_SUNXI_SLOT_EXTRA != 1 slot is 2 defined but some boards > > > > > >> may not use all possible mmc devices or partly disabled in DT, > > > > > >> for those update the device in board specific defconfig. > > > > > >> > > > > > >> Cc: Olliver Schinagl > > > > > >> Cc: Chen-Yu Tsai > > > > > >> Signed-off-by: Jagan Teki > > > > > >> --- > > > > > >> configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 + > > > > > >> configs/Sinlinx_SinA33_defconfig | 1 + > > > > > >> configs/amarula_a64_relic_defconfig| 1 + > > > > > >> drivers/fastboot/Kconfig | 3 ++- > > > > > >> 4 files changed, 5 insertions(+), 1 deletion(-) > > > > > >> > > > > > >> diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > > > >> b/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > > > >> index 5657fc2594..20ea254191 100644 > > > > > >> --- a/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > > > >> +++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > > > >> @@ -29,4 +29,5 @@ CONFIG_AXP_ALDO4_VOLT=2800 > > > > > >> CONFIG_SCSI=y > > > > > >> CONFIG_USB_EHCI_HCD=y > > > > > >> CONFIG_USB_MUSB_GADGET=y > > > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 > > > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y > > > > > >> diff --git a/configs/Sinlinx_SinA33_defconfig > > > > > >> b/configs/Sinlinx_SinA33_defconfig > > > > > >> index 394534b8b5..7841219a65 100644 > > > > > >> --- a/configs/Sinlinx_SinA33_defconfig > > > > > >> +++ b/configs/Sinlinx_SinA33_defconfig > > > > > >> @@ -21,5 +21,6 @@ CONFIG_DFU_RAM=y > > > > > >> CONFIG_FASTBOOT_CMD_OEM_FORMAT=y > > > > > >> CONFIG_USB_EHCI_HCD=y > > > > > >> CONFIG_USB_MUSB_GADGET=y > > > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 > > > > > > > > > > > > Your commit doesn't make any sense: the SinaA33 and the Lime2 both > > > > > > have the eMMC on MMC2, and you claim you want to update the default > > > > > > to > > > > > > point to MMC2, but you're changing both these boards to point to > > > > > > MMC1 > > > > > > instead? > > > > > > > > > > If DM_MMC and SLOT != 1 => default device 2 which is updated by > > > > > kconfig, this is with all relevant mmc nodes are enabled > > > > > but these two boards mmc1 is not enabled so emmc will detected in > > > > > device 1 > > > > > > > > > > > > > > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y > > > > > >> CONFIG_USB_FUNCTION_MASS_STORAGE=y > > > > > >> diff --git a/configs/amarula_a64_relic_defconfig > > > > > >> b/configs/amarula_a64_relic_defconfig > > > > > >> index b72cbfabc6..caeb3f6008 100644 > > > > > >> --- a/configs/amarula_a64_relic_defconfig > > > > > >> +++ b/configs/amarula_a64_relic_defconfig > > > > > >> @@ -12,4 +12,5 @@ > > > > > >> CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-amarula-relic" > > > > > >> # CONFIG_SPL_DOS_PARTITION is not set > > > > > >> # CONFIG_SPL_EFI_PARTITION is not set > > > > > >> CONFIG_USB_MUSB_GADGET=y > > > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 > > > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y > > > > > >> diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig > > > > > >> index bc25ea1d9c..4a1bfd119c 100644 > > > > > >> --- a/drivers/fastboot/Kconfig > > > > > >> +++ b/drivers/fastboot/Kconfig > > > > > >> @@ -88,7 +88,8 @@ config FASTBOOT_FLASH_MMC_DEV > > > > > >> int "Define FASTBOOT MMC FLASH default device" > > > > > >> depends on FASTBOOT_FLASH_MMC > > > > > >> default 0 if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA = -1 > > > > > >> - default 1 if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA != -1 > > > > > >> + default 1 if ARCH_SUNXI && !DM_MMC && MMC_SUNXI_SLOT_EXTRA > > > > > >> != -1 > > > > > >> + default 2 if ARCH_SUNXI && DM_MMC && MMC_SUNXI_SLOT_EXTRA != > > > > > >> -1 > > > > > > > > > > > > It'd be better to be fixed properly, instead of just relying on a > > > > > > broken index. > > > > > > > > > > I don't think we can't do anything with this now, since this INDEX > > > > > more rely on SPL for pinctrl enablement. if you have any suggestion > > > > > please share. > > > > > > > > Would another answer (at least for this
Re: [U-Boot] [PATCH] ARM: mx6ul: Apply ERR011115 errata workaround
Hi Marcin, On Thu, Jul 19, 2018 at 8:37 AM, Marcin Niestroj wrote: > ERR05 in IMX6UL errata says to use OCRAM memory above > 0x908000 (instead of 0x907000) for silicon revision 1.2 shipped > prior date code 1740. > > As we cannot check affected targets in runtime, apply that > workaround by default for all IMX6UL platforms. Leave possibility > to disable that workaround for non-affected targets, so more OCRAM > area can be used by SPL (e.g. for featureful SPL images). > > Signed-off-by: Marcin Niestroj It seems this is the best we can do, thanks: Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 22/25] env: sunxi: Update default env fat device
On Tue, Jul 17, 2018 at 5:24 PM, Maxime Ripard wrote: > On Mon, Jul 16, 2018 at 03:46:10PM +0530, Jagan Teki wrote: >> On Mon, Jul 16, 2018 at 3:17 PM, Maxime Ripard >> wrote: >> > On Mon, Jul 16, 2018 at 01:49:53PM +0530, Jagan Teki wrote: >> >> Usually eMMC is default env fat device for environment, >> >> if MMC_SUNXI_SLOT_EXTRA != 1 Sunxi always probed emmc >> >> device as 1. but with DM_MMC it can be more possible to >> >> probe eMMC as device 2 since for most of the sunxi platforms >> >> eMMC is configured mmc2. >> >> >> >> So update the env default device as 2 if DM_MMC and >> >> MMC_SUNXI_SLOT_EXTRA != 1 but some boards may not use all >> >> possible mmc devices or partly disabled in DT, for those update >> >> the device in board specific defconfig. >> >> >> >> Cc: Olliver Schinagl >> >> Cc: Hans de Goede >> >> Cc: Marcus Cooper >> >> Cc: Stefan Mavrodiev >> >> Cc: Paul Kocialkowski >> >> Cc: Chen-Yu Tsai >> >> Signed-off-by: Jagan Teki >> >> --- >> >> configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 + >> >> configs/A20-OLinuXino_MICRO-eMMC_defconfig | 1 + >> >> configs/A20-OLinuXino_MICRO_defconfig| 1 + >> >> configs/A20-Olimex-SOM-EVB_defconfig | 1 + >> >> configs/A20-Olimex-SOM204-EVB-eMMC_defconfig | 1 + >> >> configs/Mele_M3_defconfig| 1 + >> >> configs/Orangepi_mini_defconfig | 1 + >> >> configs/Sinlinx_SinA33_defconfig | 1 + >> >> configs/Yones_Toptech_BD1078_defconfig | 1 + >> >> configs/amarula_a64_relic_defconfig | 1 + >> >> env/Kconfig | 3 ++- >> >> 11 files changed, 12 insertions(+), 1 deletion(-) >> >> >> >> diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig >> >> b/configs/A20-OLinuXino-Lime2-eMMC_defconfig >> >> index 20ea254191..98a8ceb178 100644 >> >> --- a/configs/A20-OLinuXino-Lime2-eMMC_defconfig >> >> +++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig >> >> @@ -5,6 +5,7 @@ CONFIG_MACH_SUN7I=y >> >> CONFIG_DRAM_CLK=384 >> >> CONFIG_MMC0_CD_PIN="PH1" >> >> CONFIG_MMC_SUNXI_SLOT_EXTRA=2 >> >> +CONFIG_ENV_FAT_DEVICE_AND_PART="1:auto" >> >> CONFIG_USB0_VBUS_PIN="PC17" >> >> CONFIG_USB0_VBUS_DET="PH5" >> >> CONFIG_I2C1_ENABLE=y >> >> diff --git a/configs/A20-OLinuXino_MICRO-eMMC_defconfig >> >> b/configs/A20-OLinuXino_MICRO-eMMC_defconfig >> >> index f7e7cbab0a..1552960d88 100644 >> >> --- a/configs/A20-OLinuXino_MICRO-eMMC_defconfig >> >> +++ b/configs/A20-OLinuXino_MICRO-eMMC_defconfig >> >> @@ -5,6 +5,7 @@ CONFIG_MACH_SUN7I=y >> >> CONFIG_DRAM_CLK=384 >> >> CONFIG_MMC0_CD_PIN="PH1" >> >> CONFIG_MMC_SUNXI_SLOT_EXTRA=2 >> >> +CONFIG_ENV_FAT_DEVICE_AND_PART="1:auto" >> >> CONFIG_I2C1_ENABLE=y >> >> CONFIG_VIDEO_VGA=y >> >> CONFIG_SATAPWR="PB8" >> >> diff --git a/configs/A20-OLinuXino_MICRO_defconfig >> >> b/configs/A20-OLinuXino_MICRO_defconfig >> >> index 8dcbdc08f9..b5f1b7efe2 100644 >> >> --- a/configs/A20-OLinuXino_MICRO_defconfig >> >> +++ b/configs/A20-OLinuXino_MICRO_defconfig >> >> @@ -6,6 +6,7 @@ CONFIG_DRAM_CLK=384 >> >> CONFIG_MMC0_CD_PIN="PH1" >> >> CONFIG_MMC3_CD_PIN="PH11" >> >> CONFIG_MMC_SUNXI_SLOT_EXTRA=3 >> >> +CONFIG_ENV_FAT_DEVICE_AND_PART="1:auto" >> >> CONFIG_I2C1_ENABLE=y >> >> CONFIG_VIDEO_VGA=y >> >> CONFIG_SATAPWR="PB8" >> >> diff --git a/configs/A20-Olimex-SOM-EVB_defconfig >> >> b/configs/A20-Olimex-SOM-EVB_defconfig >> >> index a06499e2d0..58f6fbad91 100644 >> >> --- a/configs/A20-Olimex-SOM-EVB_defconfig >> >> +++ b/configs/A20-Olimex-SOM-EVB_defconfig >> >> @@ -7,6 +7,7 @@ CONFIG_MMC0_CD_PIN="PH1" >> >> CONFIG_MMC3_CD_PIN="PH0" >> >> CONFIG_MMC3_PINS="PH" >> >> CONFIG_MMC_SUNXI_SLOT_EXTRA=3 >> >> +CONFIG_ENV_FAT_DEVICE_AND_PART="1:auto" >> >> CONFIG_USB0_VBUS_PIN="PB9" >> >> CONFIG_USB0_VBUS_DET="PH5" >> >> CONFIG_SATAPWR="PC3" >> >> diff --git a/configs/A20-Olimex-SOM204-EVB-eMMC_defconfig >> >> b/configs/A20-Olimex-SOM204-EVB-eMMC_defconfig >> >> index 3bb8c4c7e6..ac4f841c4e 100644 >> >> --- a/configs/A20-Olimex-SOM204-EVB-eMMC_defconfig >> >> +++ b/configs/A20-Olimex-SOM204-EVB-eMMC_defconfig >> >> @@ -5,6 +5,7 @@ CONFIG_MACH_SUN7I=y >> >> CONFIG_DRAM_CLK=384 >> >> CONFIG_MMC0_CD_PIN="PH1" >> >> CONFIG_MMC_SUNXI_SLOT_EXTRA=2 >> >> +CONFIG_ENV_FAT_DEVICE_AND_PART="1:auto" >> >> CONFIG_USB0_VBUS_PIN="PC17" >> >> CONFIG_USB0_VBUS_DET="PH5" >> >> CONFIG_I2C1_ENABLE=y >> >> diff --git a/configs/Mele_M3_defconfig b/configs/Mele_M3_defconfig >> >> index 9f48bd91e0..93a2395aee 100644 >> >> --- a/configs/Mele_M3_defconfig >> >> +++ b/configs/Mele_M3_defconfig >> >> @@ -5,6 +5,7 @@ CONFIG_MACH_SUN7I=y >> >> CONFIG_DRAM_CLK=384 >> >> CONFIG_MMC0_CD_PIN="PH1" >> >> CONFIG_MMC_SUNXI_SLOT_EXTRA=2 >> >> +CONFIG_ENV_FAT_DEVICE_AND_PART="1:auto" >> >> CONFIG_VIDEO_VGA=y >> >> CONFIG_VIDEO_COMPOSITE=y >> >> CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-m3" >> >> diff --git a/configs/Orangepi_mini_defconfig >> >> b/configs/Orangepi_mini_defconfig >> >> index 46f27be254..d562273bef 100644 >> >> ---
Re: [U-Boot] [linux-sunxi] [PATCH 00/13] Allwinner H6 support (w/ SPL)
On Mon, Jun 25, 2018 at 6:32 PM, Jagan Teki wrote: > On Mon, Jun 25, 2018 at 6:19 PM, Icenowy Zheng wrote: >> >> >> 于 2018年6月25日 GMT+08:00 下午8:40:21, Jagan Teki 写到: >>>On Mon, Jun 25, 2018 at 4:07 PM, Icenowy Zheng wrote: This patch trys to add support for Allwinner H6 SoC to U-Boot. Allwinner H6 is a quite new Allwinner SoC, with several parts changed >>>a lot (memory map, DRAM controller, CCU, so on). The position which SPL will be loaded (SRAM A1) also changed to 0x2. The Pine H64 board support comes with this patchset, as this is the first H6 board that I can get (being early bird). Icenowy Zheng (13): sunxi: change SUNXI_HIGH_SRAM option to SUNXI_SRAM_ADDRESS sunxi: add basical memory map definitions of H6 SoC sunxi: change RMR64's RVBAR address for H6 sunxi: change ATF position for H6 sunxi: add config for SPL at 0x2 on H6 sunxi: change GIC address on H6 sunxi: add clock code for H6 sunxi: use sun6i-style watchdog for H6 sunxi: add UART0 setup for H6 sunxi: add MMC support for H6 sunxi: add DRAM support to H6 sunxi: add support for Allwinner H6 SoC sunxi: add support for Pine H64 board >>> >>>is it on top of master? unable to apply for testing on master, point >>>me the branch would help. >> >> sunxi/next. > > please send it, on top of master Are you planning to send v2, if so please rebase it on master. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 21/25] fastboot: sunxi: Update fastboot mmc default device
On Thu, Jul 19, 2018 at 6:56 PM, Maxime Ripard wrote: > On Wed, Jul 18, 2018 at 08:15:23PM +0100, Alex Kiernan wrote: >> On Tue, Jul 17, 2018 at 12:57 PM Maxime Ripard >> wrote: >> > >> > On Mon, Jul 16, 2018 at 12:11:59PM +0100, Alex Kiernan wrote: >> > > On Mon, Jul 16, 2018 at 11:13 AM Jagan Teki >> > > wrote: >> > > > >> > > > On Mon, Jul 16, 2018 at 3:16 PM, Maxime Ripard >> > > > wrote: >> > > > > On Mon, Jul 16, 2018 at 01:49:52PM +0530, Jagan Teki wrote: >> > > > >> Usually eMMC is default env fat device for environment, >> > > > >> if MMC_SUNXI_SLOT_EXTRA != 1 Sunxi always probed emmc >> > > > >> device as 1. but with DM_MMC it can be more possible to >> > > > >> probe eMMC as device 2 since for most of the sunxi platforms >> > > > >> eMMC is configured mmc2. >> > > > >> >> > > > >> So update the fastboot mmc default device as 2 if DM_MMC and >> > > > >> MMC_SUNXI_SLOT_EXTRA != 1 slot is 2 defined but some boards >> > > > >> may not use all possible mmc devices or partly disabled in DT, >> > > > >> for those update the device in board specific defconfig. >> > > > >> >> > > > >> Cc: Olliver Schinagl >> > > > >> Cc: Chen-Yu Tsai >> > > > >> Signed-off-by: Jagan Teki >> > > > >> --- >> > > > >> configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 + >> > > > >> configs/Sinlinx_SinA33_defconfig | 1 + >> > > > >> configs/amarula_a64_relic_defconfig| 1 + >> > > > >> drivers/fastboot/Kconfig | 3 ++- >> > > > >> 4 files changed, 5 insertions(+), 1 deletion(-) >> > > > >> >> > > > >> diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig >> > > > >> b/configs/A20-OLinuXino-Lime2-eMMC_defconfig >> > > > >> index 5657fc2594..20ea254191 100644 >> > > > >> --- a/configs/A20-OLinuXino-Lime2-eMMC_defconfig >> > > > >> +++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig >> > > > >> @@ -29,4 +29,5 @@ CONFIG_AXP_ALDO4_VOLT=2800 >> > > > >> CONFIG_SCSI=y >> > > > >> CONFIG_USB_EHCI_HCD=y >> > > > >> CONFIG_USB_MUSB_GADGET=y >> > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 >> > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y >> > > > >> diff --git a/configs/Sinlinx_SinA33_defconfig >> > > > >> b/configs/Sinlinx_SinA33_defconfig >> > > > >> index 394534b8b5..7841219a65 100644 >> > > > >> --- a/configs/Sinlinx_SinA33_defconfig >> > > > >> +++ b/configs/Sinlinx_SinA33_defconfig >> > > > >> @@ -21,5 +21,6 @@ CONFIG_DFU_RAM=y >> > > > >> CONFIG_FASTBOOT_CMD_OEM_FORMAT=y >> > > > >> CONFIG_USB_EHCI_HCD=y >> > > > >> CONFIG_USB_MUSB_GADGET=y >> > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 >> > > > > >> > > > > Your commit doesn't make any sense: the SinaA33 and the Lime2 both >> > > > > have the eMMC on MMC2, and you claim you want to update the default >> > > > > to >> > > > > point to MMC2, but you're changing both these boards to point to MMC1 >> > > > > instead? >> > > > >> > > > If DM_MMC and SLOT != 1 => default device 2 which is updated by >> > > > kconfig, this is with all relevant mmc nodes are enabled >> > > > but these two boards mmc1 is not enabled so emmc will detected in >> > > > device 1 >> > > > >> > > > > >> > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y >> > > > >> CONFIG_USB_FUNCTION_MASS_STORAGE=y >> > > > >> diff --git a/configs/amarula_a64_relic_defconfig >> > > > >> b/configs/amarula_a64_relic_defconfig >> > > > >> index b72cbfabc6..caeb3f6008 100644 >> > > > >> --- a/configs/amarula_a64_relic_defconfig >> > > > >> +++ b/configs/amarula_a64_relic_defconfig >> > > > >> @@ -12,4 +12,5 @@ >> > > > >> CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-amarula-relic" >> > > > >> # CONFIG_SPL_DOS_PARTITION is not set >> > > > >> # CONFIG_SPL_EFI_PARTITION is not set >> > > > >> CONFIG_USB_MUSB_GADGET=y >> > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 >> > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y >> > > > >> diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig >> > > > >> index bc25ea1d9c..4a1bfd119c 100644 >> > > > >> --- a/drivers/fastboot/Kconfig >> > > > >> +++ b/drivers/fastboot/Kconfig >> > > > >> @@ -88,7 +88,8 @@ config FASTBOOT_FLASH_MMC_DEV >> > > > >> int "Define FASTBOOT MMC FLASH default device" >> > > > >> depends on FASTBOOT_FLASH_MMC >> > > > >> default 0 if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA = -1 >> > > > >> - default 1 if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA != -1 >> > > > >> + default 1 if ARCH_SUNXI && !DM_MMC && MMC_SUNXI_SLOT_EXTRA != >> > > > >> -1 >> > > > >> + default 2 if ARCH_SUNXI && DM_MMC && MMC_SUNXI_SLOT_EXTRA != >> > > > >> -1 >> > > > > >> > > > > It'd be better to be fixed properly, instead of just relying on a >> > > > > broken index. >> > > > >> > > > I don't think we can't do anything with this now, since this INDEX >> > > > more rely on SPL for pinctrl enablement. if you have any suggestion >> > > > please share. >> > > >> > > Would another answer (at least for this specific case) to change the >> > > fastboot code so it doesn't need the device number in advance? Given >> > > we
Re: [U-Boot] [RFC PATCH 4/4] arm: zynq: spl: implement FPGA load from FIT
Hi Michal,
On Thu, Jul 19, 2018 at 2:16 AM Michal Simek wrote:
> Also on zc706 without FULL_FIT my path in spl_load_fit_image is not
> jumping to "if (external_data) {" branch where spl_load_fpga_image is
> which is kind of interesting because it looks like you are going there.
To enter the path "if (external_data) {" branch where spl_load_fpga_image is}"
you have to create the FIT image with the "-E" option, I'm creating it with:
> ./tools/mkimage -f -E
I started to use the option because my initial tests weren't entering
the path either, and I found it when analyzing the (generated)
.u-boot.img.cmd file.
I just tested your patch with and without the "-E" option, and it
works on both cases :)
Thanks,
Luis Araneda.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/5] dm: sysreset: Add a standard message when doing reset
On Thu, 2018-07-19 at 09:21 -0600, Simon Glass wrote: > On 19 July 2018 at 04:07, Bin Meng wrote: > > It's good to print a message when doing reset. > > > > Signed-off-by: Bin Meng > > > > --- > > > > Changes in v2: > > - new patch per Wolfgang's suggestion to add a standard message when > > doing reset > > > > drivers/sysreset/sysreset-uclass.c | 2 ++ > > 1 file changed, 2 insertions(+) > > Reviewed-by: Simon Glass > > I wonder how many platforms will actually show this message and how > many will just put it in their serial buffer and then discard it? Edison does. -- Andy Shevchenko Intel Finland Oy ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] env: Merge Rockchip, Sunxi, Zynq and ZynqMP
On Thu, Jul 19, 2018 at 10:53:44AM -0400, Tom Rini wrote: > On Thu, Jul 19, 2018 at 03:45:11PM +0200, Michal Simek wrote: > > On 19.7.2018 13:13, Maxime Ripard wrote: > > > Hi, > > > > > > On Thu, Jul 19, 2018 at 08:45:45AM +0200, Michal Simek wrote: > > >> There is no reason to have the same Kconfig options for different SoCs > > >> separately. The patch is merging them together. > > >> > > >> Signed-off-by: Michal Simek > > >> --- > > >> > > >> Patch is based on > > >> https://lists.denx.de/pipermail/u-boot/2018-July/335126.html > > >> > > >> I have ENV_SECT_SIZE just for zynq/zynqmp because rockchip and sunxi > > >> have this in their configs. When they decide to move then can enable > > >> that option for them too. > > >> I expect when more platforms extend this we will have less constrain > > >> Kconfig setup. > > >> > > >> --- > > >> env/Kconfig | 66 > > >> - > > >> 1 file changed, 17 insertions(+), 49 deletions(-) > > >> > > >> diff --git a/env/Kconfig b/env/Kconfig > > >> index b37dcd78eb75..0ded003d7d41 100644 > > >> --- a/env/Kconfig > > >> +++ b/env/Kconfig > > >> @@ -431,23 +431,37 @@ config ENV_EXT4_FILE > > >>It's a string of the EXT4 file name. This file use to store > > >> the > > >>environment (explicit path to the file) > > >> > > >> -if ARCH_SUNXI > > >> +if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP > > > > > > Can we have a depends on instead? That would be more flexible. > > > > In what sense? If depends is used below then the same 4 platforms will > > be listed on all options below. (I want to also add ZYNQMP_R5 there too) > > And changing this in one place seems to me better then on four. > > For now I like the "if" method for now as we can't (or couldn't a while > ago) globally migrate everyone over. I think trying to move everyone > over again is something I should give another try. Ack. > > >> config ENV_OFFSET > > >> hex "Environment Offset" > > >> depends on !ENV_IS_IN_UBI > > >> depends on !ENV_IS_NOWHERE > > >> +default 0x3f8000 if ARCH_ROCKCHIP > > >> default 0x88000 if ARCH_SUNXI > > >> +default 0xE if ARCH_ZYNQ > > >> +default 0x1E0 if ARCH_ZYNQMP > > >> help > > >>Offset from the start of the device (or partition) > > >> > > >> config ENV_SIZE > > >> hex "Environment Size" > > >> -depends on !ENV_IS_NOWHERE > > >> -default 0x2 if ARCH_SUNXI > > >> +default 0x8000 if ARCH_ROCKCHIP && !ENV_IS_NOWHERE > > >> +default 0x2 if ARCH_SUNXI && !ENV_IS_NOWHERE > > > > > > I'm not sure why you removed the depends on !ENV_IS_NOWHERE. Do you > > > have a case where the environment is not store anywhere but still need > > > a size? > > > > yes, I had a compilation warning for that case. > > > > in include/environment.h at line 145 it is written this > > #define ENV_SIZE (CONFIG_ENV_SIZE - ENV_HEADER_SIZE) > > > > ENV_SIZE is also used in typedef struct environment_s some lines below. > > And this structure is used a lot. > > > > How did you find out that this can't be used for ENV_IS_NOWHERE? > > I would have sworn that ENV_SIZE is used for ENV_IS_NOWHERE as that's > how much space we have for environment when it's in memory as well. Argh, sorry for that I was abused by sunxi-common still having that: https://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/sunxi-common.h#l161 While i was convinced that we were relying solely on Kconfig. I'll send a subsequent patch, that one works for me. Sorry, Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] fdt: fix fdtdec_setup_memory_banksize()
On Thu, Jul 19, 2018 at 3:32 AM, Simon Glass wrote: > Hi Jens, > > On 17 July 2018 at 09:42, Jens Wiklander wrote: >> On Sun, Jul 15, 2018 at 11:20:39PM -0600, Simon Glass wrote: >>> On 13 July 2018 at 04:12, Jens Wiklander wrote: >>> > Prior to this patch is fdtdec_setup_memory_banksize() incorrectly >>> > ignoring the "status" field. This patch fixes that by testing the status >>> > with fdtdec_get_is_enabled() before using a memory node. >>> > >>> > Signed-off-by: Jens Wiklander >>> > --- >>> > lib/fdtdec.c | 20 +++- >>> > 1 file changed, 15 insertions(+), 5 deletions(-) >>> >>> Reviewed-by: Simon Glass >>> >>> But can you convert this to livetree at the same time? E.g. use ofnode >>> functions. >> >> I can try, but the ofnode concept is new to me. >> >> This patch is based on the fdt_node_offset_by_prop_value() function. I >> can't find any such ofnode function or any other suitable helper >> function. Perhaps I'm missing something, or should I add an >> ofnode_by_prop_value() function (similar to ofnode_by_compatible())? >> >> Please advice. > > advise :-) > > Yes, you could add that function. Sorry it doesn't already exists. I'll give it a shot after my vacation. In the meantime can we take this patch or would you rather wait for the livetree version? Thanks, Jens ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] watchdog: dm: Support manual relocation for watchdogs
On Thu, Jul 19, 2018 at 09:21:39AM -0600, Simon Glass wrote: > +Tom > > Hi Michal, > > On 19 July 2018 at 00:52, Michal Simek wrote: > > Hi Simon, > > > > On 19.7.2018 03:31, Simon Glass wrote: > >> Hi Michal, > >> > >> On 15 July 2018 at 23:34, Michal Simek wrote: > >>> On 15.7.2018 23:21, Simon Glass wrote: > Hi Michal, > > On 11 July 2018 at 23:47, Michal Simek wrote: > > On 11.7.2018 22:13, Simon Glass wrote: > >> On 11 July 2018 at 08:41, Michal Simek wrote: > >>> Relocate watchdog ops as was done by: > >>> "dm: Add support for all targets which requires MANUAL_RELOC" > >>> (sha1: 484fdf5ba058b07be5ca82763aa2b72063540ef3) > >>> > >>> Signed-off-by: Michal Simek > >>> --- > >>> > >>> based on https://lists.denx.de/pipermail/u-boot/2018-July/334227.html > >>> > >>> --- > >>> drivers/watchdog/wdt-uclass.c | 23 +++ > >>> 1 file changed, 23 insertions(+) > >>> > >> > >> Reviewed-by: Simon Glass > >> > >> When will the toolchain be fixed? > > > > It is really several years back when I have looked at it last time but I > > think that toolchain is fixed for quite some time and only changes in > > microblaze u-boot code are needed but really I would have to check and > > start to play with it. > > I think someone should sort this out. It would be good to remove this > code. Is there a toolchain group at Xilinx? > >>> > >>> Xilinx has a toolchain group. I just looked a I was playing with it in > >>> January 2015 but didn't finish that. It is still on my long todo list. > >>> Will see when I have a time to look at it. > >> > >> Hoe about next week? -:) I think this is pretty important. > > > > will see but I need to do some Linux work first. Based on grep I see > > that m68k is also enabling CONFIG_NEEDS_MANUAL_RELOC. > > Is m68k going to be removed soon? > > I am not sure about that. Tom, do you know? m68k is still active, so no, it's not being removed and we can't drop CONFIG_NEEDS_MANUAL_RELOC just yet. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/5] x86: fsp: Eliminate the reset_cpu() call
On 19 July 2018 at 04:07, Bin Meng wrote: > In preparation for the reset driver conversion, eliminate the > reset_cpu() call in the FSP init path as it's too early for the > reset driver to work. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/lib/fsp/fsp_common.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Adding back Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/5] dm: sysreset: Add a standard message when doing reset
On 19 July 2018 at 04:07, Bin Meng wrote: > It's good to print a message when doing reset. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - new patch per Wolfgang's suggestion to add a standard message when > doing reset > > drivers/sysreset/sysreset-uclass.c | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Simon Glass I wonder how many platforms will actually show this message and how many will just put it in their serial buffer and then discard it? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] fdt_support: make fdt_fixup_mtdparts() prototype more specific
Hi Masahiro, On 19 July 2018 at 01:28, Masahiro Yamada wrote: > The second argument of fdt_fixup_mtdparts() is an opaque pointer, > 'void *node_info', hence callers can pass any pointer. > > Obviously, fdt_fixup_mtdparts() expects 'struct node_info *' > otherwise, it crashes run-time. > > Change the prototype so that it is compile-time checked. > > Also, add 'const' qualifier to it so that callers can constify > the struct node_info arrays. > > Signed-off-by: Masahiro Yamada > --- > > common/fdt_support.c | 13 +++-- > include/fdt_support.h | 11 --- > 2 files changed, 15 insertions(+), 9 deletions(-) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] x86: Switch to use DM sysreset driver
On 19 July 2018 at 04:07, Bin Meng wrote: > This converts all x86 boards over to DM sysreset. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - remove include of "reset.dsti" in edison.dts > - add SYSRESET for efi-x86_app and edison > > arch/Kconfig | 2 ++ > arch/x86/cpu/baytrail/valleyview.c| 6 -- > arch/x86/cpu/braswell/braswell.c | 6 -- > arch/x86/cpu/cpu.c| 26 -- > arch/x86/cpu/ivybridge/early_me.c | 7 --- > arch/x86/cpu/ivybridge/sdram.c| 3 ++- > arch/x86/cpu/qemu/qemu.c | 6 -- > arch/x86/cpu/quark/quark.c| 6 -- > arch/x86/cpu/tangier/tangier.c| 6 -- > arch/x86/dts/bayleybay.dts| 1 + > arch/x86/dts/baytrail_som-db5800-som-6867.dts | 1 + > arch/x86/dts/broadwell_som-6896.dts | 1 + > arch/x86/dts/cherryhill.dts | 1 + > arch/x86/dts/chromebook_link.dts | 1 + > arch/x86/dts/chromebook_samus.dts | 1 + > arch/x86/dts/chromebox_panther.dts| 1 + > arch/x86/dts/conga-qeval20-qa3-e3845.dts | 1 + > arch/x86/dts/cougarcanyon2.dts| 1 + > arch/x86/dts/crownbay.dts | 1 + > arch/x86/dts/dfi-bt700.dtsi | 1 + > arch/x86/dts/edison.dts | 5 + > arch/x86/dts/efi-x86_app.dts | 5 + > arch/x86/dts/efi-x86_payload.dts | 1 + > arch/x86/dts/galileo.dts | 1 + > arch/x86/dts/minnowmax.dts| 1 + > arch/x86/dts/qemu-x86_i440fx.dts | 1 + > arch/x86/dts/qemu-x86_q35.dts | 1 + > arch/x86/dts/reset.dtsi | 6 ++ > arch/x86/include/asm/processor.h | 5 - > arch/x86/include/asm/u-boot-x86.h | 1 - > configs/chromebook_link64_defconfig | 1 + > 31 files changed, 41 insertions(+), 66 deletions(-) > create mode 100644 arch/x86/dts/reset.dtsi Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] efi: app: Add a sysreset driver
On 19 July 2018 at 04:07, Bin Meng wrote: > This adds the DM sysreset driver for EFI application support. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - drop patches already applied > - new patch to add a sysreset driver for efi app > > lib/efi/efi_app.c | 28 +++- > 1 file changed, 27 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 03/15] cmd: fpga: Move fpga_get_op to avoid local function declaration
Hi Michal, On 19 July 2018 at 00:55, Michal Simek wrote: > On 19.7.2018 03:32, Simon Glass wrote: >> On 18 July 2018 at 09:16, Michal Simek wrote: >>> Move fpga_get_op() to top of file to remove local function declaration >>> and also remove useless retyping. >>> >>> Signed-off-by: Michal Simek >>> --- >>> >>> cmd/fpga.c | 85 >>> ++ >>> 1 file changed, 41 insertions(+), 44 deletions(-) >>> >> >> Reviewed-by: Simon Glass >> >> But can this not use a sub-command array? > > As you see the whole series is coming to that direction. > I just needed to do some preparation steps before doing that. Yes I t see that, thanks. - Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] x86: acpi: Move APIs unrelated to ACPI tables generation to a separate library
On 18 July 2018 at 22:42, Bin Meng wrote: > acpi_find_fadt(), acpi_find_wakeup_vector() and enter_acpi_mode() > are something unrelated to ACPI tables generation. Move these to > a separate library. > > This also fixes several style issues reported by checkpatch in the > original codes. > > Signed-off-by: Bin Meng > --- > > Changes in v2: None > > arch/x86/cpu/cpu.c| 1 + > arch/x86/include/asm/acpi.h | 41 +++ > arch/x86/include/asm/acpi_table.h | 28 -- > arch/x86/lib/Makefile | 1 + > arch/x86/lib/acpi.c | 108 > ++ > arch/x86/lib/acpi_s3.c| 1 + > arch/x86/lib/acpi_table.c | 101 +-- > 7 files changed, 153 insertions(+), 128 deletions(-) > create mode 100644 arch/x86/include/asm/acpi.h > create mode 100644 arch/x86/lib/acpi.c Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/5] x86: tangier: Add a sysreset driver
On 19 July 2018 at 04:07, Bin Meng wrote: > This adds a reset driver for tangier processor. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - new patch to add a reset driver for tangier processor > > arch/x86/cpu/tangier/Makefile | 2 +- > arch/x86/cpu/tangier/sysreset.c | 48 > + > 2 files changed, 49 insertions(+), 1 deletion(-) > create mode 100644 arch/x86/cpu/tangier/sysreset.c Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] watchdog: dm: Support manual relocation for watchdogs
+Tom Hi Michal, On 19 July 2018 at 00:52, Michal Simek wrote: > Hi Simon, > > On 19.7.2018 03:31, Simon Glass wrote: >> Hi Michal, >> >> On 15 July 2018 at 23:34, Michal Simek wrote: >>> On 15.7.2018 23:21, Simon Glass wrote: Hi Michal, On 11 July 2018 at 23:47, Michal Simek wrote: > On 11.7.2018 22:13, Simon Glass wrote: >> On 11 July 2018 at 08:41, Michal Simek wrote: >>> Relocate watchdog ops as was done by: >>> "dm: Add support for all targets which requires MANUAL_RELOC" >>> (sha1: 484fdf5ba058b07be5ca82763aa2b72063540ef3) >>> >>> Signed-off-by: Michal Simek >>> --- >>> >>> based on https://lists.denx.de/pipermail/u-boot/2018-July/334227.html >>> >>> --- >>> drivers/watchdog/wdt-uclass.c | 23 +++ >>> 1 file changed, 23 insertions(+) >>> >> >> Reviewed-by: Simon Glass >> >> When will the toolchain be fixed? > > It is really several years back when I have looked at it last time but I > think that toolchain is fixed for quite some time and only changes in > microblaze u-boot code are needed but really I would have to check and > start to play with it. I think someone should sort this out. It would be good to remove this code. Is there a toolchain group at Xilinx? >>> >>> Xilinx has a toolchain group. I just looked a I was playing with it in >>> January 2015 but didn't finish that. It is still on my long todo list. >>> Will see when I have a time to look at it. >> >> Hoe about next week? -:) I think this is pretty important. > > will see but I need to do some Linux work first. Based on grep I see > that m68k is also enabling CONFIG_NEEDS_MANUAL_RELOC. > Is m68k going to be removed soon? I am not sure about that. Tom, do you know? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4] watchdog: Convert Xilinx Axi watchdog driver to driver model
On 19 July 2018 at 01:15, Michal Simek wrote: > From: Shreenidhi Shedi > > Xilinx Axi wdt driver conversion to driver model & Kconfig update > for the same. > > Signed-off-by: Shreenidhi Shedi > Signed-off-by: Michal Simek > --- > > Changes in v4: > - Fix Kconfig typo - by sjg > - Use debug instead of puts in drivers - by sjg > - Use EBUSY instead of -1 - by sjg > > Changes in v3: > - Fix commit message > - s/Axi/AXI > - Use platdata instead of private data. > - Remove \n from wdt reset to catch logs > - Add debug to wdt_start > > Changes in v2: > - Rectified print message > - Removed stop instruction from probe > > Changes in v1: > - Xilinx Axi wdt driver conversion to DM initial version > > drivers/watchdog/Kconfig | 8 +++ > drivers/watchdog/xilinx_tb_wdt.c | 111 > ++- > 2 files changed, 93 insertions(+), 26 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/3] x86: acpi: Prevent acpi_table.h from being included more than once
On 18 July 2018 at 22:42, Bin Meng wrote: > The wrapper #ifndef is currently missing in acpi_table.h. Add it to > prevent it from being included multiple times. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: None > > arch/x86/include/asm/acpi_table.h | 5 + > 1 file changed, 5 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/3] x86: acpi: Don't touch ACPI hardware in write_acpi_tables()
On 18 July 2018 at 22:42, Bin Meng wrote: > write_acpi_tables() currently touches ACPI hardware to switch to > ACPI mode at the end. Move such operation out of this function, > so that it only does what the function name tells us. > > Signed-off-by: Bin Meng > > --- > > Changes in v2: > - move variable definition to the first line in the function > > arch/x86/cpu/cpu.c| 21 ++--- > arch/x86/lib/acpi_table.c | 11 --- > 2 files changed, 18 insertions(+), 14 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [GIT PULL] Xilinx changes for v2018.09
Hi Tom, please pull these changes to your tree. Buildman and travis looks good https://travis-ci.org/michalsimek/u-boot/builds/405716862 My pull request contains some change out of xilinx folders because one function name has been changed. I got a confirmation from Marek to go with this to the tree. And also some small changes in common area which were reviewed. usb_kdb is an exception because probably none cares. You can find more details below. Thanks, Michal The following changes since commit 1adbf2966adebe67de3dd17094749d387604194e: Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2018-07-17 14:28:47 -0400) are available in the git repository at: git://www.denx.de/git/u-boot-microblaze.git tags/xilinx-for-v2018.09 for you to fetch changes up to 577012da71ea9dcf07272c7f458218aa8ab29984: arm: zynq: spl: fix FPGA initialization (2018-07-19 10:49:57 +0200) Xilinx changes for v2018.09 clk: - Fix zynqmp clock driver common: - Handle CMD_RET_USAGE in cmd_process_error - Use return macros in cmd_process_error - Fix duplication of CONFIG_SYS_PROMPT_HUSH_PS2 - Support watchdog in usb_kbd.c - Fix name usage in usb_kbd.c - Support systems with non zero memory start initialized from DT only gpio: - Add support for manual relocation in uclass - zynq - use live tree - zynq - fix match data reading - zynq - setup bank name - xilinx - convert driver to DM microblaze: - Use generic iounmap/ioremap implementations - Redesign reset logic with sysreset features - Use watchdog and gpio over DM - Remove unused macros and fix some checkpatch issues - Fix timer initialization not to be called twice serial: - zynq - Use platdata intead of priv data sysreset: - Add support for manual relocation in uclass - Add gpio-restart driver - Add microblaze soft reset driver watchdog: - Add support for aliases in uclass - Add support for manual relocation in uclass - Convert xilinx driver to DM - cadence - update info in the driver and not stop wdt in probe xilinx: - Enable LED gpio for some targets with gpio-leds DT node - Setup variables via Kconfig zynq: - Add support for watchdog aliases - Add support for mini nand/nor configurations - Wire FPGA initalization in SPL zynqmp: - Enable mass storage for zcu100 - Handle external pmufw files - Add support for secure images - Some Kconfig movements and alignments - Add support for watchdog aliases - Use subcommands style for platform command - Add mmio_read/write platform commands - DT updates - Add support for mini qspi configuration Luca Ceresoli (1): arm/arm64: zynq/zynqmp: pass the PS init file as a kconfig variable Luis Araneda (3): spl: fit: display a message when an FPGA image is loaded drivers: fpga: zynqpl: fix compilation with SPL arm: zynq: spl: fix FPGA initialization Michal Simek (36): gpio: zynq: Use live-tree function arm64: zynqmp: Enable usb mass storage command and functionality common: command: Use command_ret_t enum values instead of values common: command: Handle USAGE failure separately hush: Remove default CONFIG_SYS_PROMPT_HUSH_PS2 setting from board files usb_kbd: Add support for watchdog usb_kdb: Get stdio_dev directly from sdev pointer serial: zynq: Use platdata for storing static data instead of priv microblaze: Use default implementation from include/linux/io.h microblaze: Guard do_reset by CONFIG_SYSRESET arm64: zcu100: Enable USB host ether and ASIX via defconfig watchdog: dm: Change uclass name to watchdog and enable DM_UC_FLAG_SEQ_ALIAS watchdog: dm: Support manual relocation for watchdogs arm64: zynqmp: Sync defconfigs in connection to DEFINE_TCM_OCM_MMAP microblaze: Remove unused XILINX_BOARD_NAME macro gpio: zynq: Fix typo in one error message sysreset: dm: Support manual relocation for sysreset gpio: dm: Support manual relocation for gpio gpio: zynq: Read of mach data in platdata with dev_get_driver_data microblaze: Do not call timer init that early gpio: zynq: Setup bank_name to dev->name arm64: zynqmp: Try to enable the first watchdog via aliases arm: zynq: Try to enable the first watchdog via aliases sysreset: Add support for gpio-restart sysreset: Add support for Microblaze soft reset jump gpio: xilinx: Convert driver to DM microblaze: Enable watchdog via defconfig arm64: xilinx: Setup default number of chipselects for zcu100 microblaze: Convert generic platform to DM gpio microblaze: Do not force saving variables to flash watchdog: cdns: Add comment for expire_now function xilinx: Enable led support for some boards watchdog: cadence: Do not stop wdt in probe microblaze: Remove XILINX_SPI_FLASH_BASEADDR logic arm: zynq: Setup ENV_SIZE via Kconfig
Re: [U-Boot] [PATCH] env: Merge Rockchip, Sunxi, Zynq and ZynqMP
On Thu, Jul 19, 2018 at 03:45:11PM +0200, Michal Simek wrote: > On 19.7.2018 13:13, Maxime Ripard wrote: > > Hi, > > > > On Thu, Jul 19, 2018 at 08:45:45AM +0200, Michal Simek wrote: > >> There is no reason to have the same Kconfig options for different SoCs > >> separately. The patch is merging them together. > >> > >> Signed-off-by: Michal Simek > >> --- > >> > >> Patch is based on > >> https://lists.denx.de/pipermail/u-boot/2018-July/335126.html > >> > >> I have ENV_SECT_SIZE just for zynq/zynqmp because rockchip and sunxi > >> have this in their configs. When they decide to move then can enable > >> that option for them too. > >> I expect when more platforms extend this we will have less constrain > >> Kconfig setup. > >> > >> --- > >> env/Kconfig | 66 > >> - > >> 1 file changed, 17 insertions(+), 49 deletions(-) > >> > >> diff --git a/env/Kconfig b/env/Kconfig > >> index b37dcd78eb75..0ded003d7d41 100644 > >> --- a/env/Kconfig > >> +++ b/env/Kconfig > >> @@ -431,23 +431,37 @@ config ENV_EXT4_FILE > >> It's a string of the EXT4 file name. This file use to store the > >> environment (explicit path to the file) > >> > >> -if ARCH_SUNXI > >> +if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP > > > > Can we have a depends on instead? That would be more flexible. > > In what sense? If depends is used below then the same 4 platforms will > be listed on all options below. (I want to also add ZYNQMP_R5 there too) > And changing this in one place seems to me better then on four. For now I like the "if" method for now as we can't (or couldn't a while ago) globally migrate everyone over. I think trying to move everyone over again is something I should give another try. > >> config ENV_OFFSET > >>hex "Environment Offset" > >>depends on !ENV_IS_IN_UBI > >>depends on !ENV_IS_NOWHERE > >> + default 0x3f8000 if ARCH_ROCKCHIP > >>default 0x88000 if ARCH_SUNXI > >> + default 0xE if ARCH_ZYNQ > >> + default 0x1E0 if ARCH_ZYNQMP > >>help > >> Offset from the start of the device (or partition) > >> > >> config ENV_SIZE > >>hex "Environment Size" > >> - depends on !ENV_IS_NOWHERE > >> - default 0x2 if ARCH_SUNXI > >> + default 0x8000 if ARCH_ROCKCHIP && !ENV_IS_NOWHERE > >> + default 0x2 if ARCH_SUNXI && !ENV_IS_NOWHERE > > > > I'm not sure why you removed the depends on !ENV_IS_NOWHERE. Do you > > have a case where the environment is not store anywhere but still need > > a size? > > yes, I had a compilation warning for that case. > > in include/environment.h at line 145 it is written this > #define ENV_SIZE (CONFIG_ENV_SIZE - ENV_HEADER_SIZE) > > ENV_SIZE is also used in typedef struct environment_s some lines below. > And this structure is used a lot. > > How did you find out that this can't be used for ENV_IS_NOWHERE? I would have sworn that ENV_SIZE is used for ENV_IS_NOWHERE as that's how much space we have for environment when it's in memory as well. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 00/32] i.MX: Add i.MX8QXP support
Hi Peng, On Thu, 19 Jul 2018 14:02:43 + Peng Fan peng@nxp.com wrote: ... > > Also, in order to test this series we need a README file. > > Please prepare one so that we can test it. > > Currently there is no public available code for atf and scfw, so > There will no link in the README, I could only add steps > on how to build out images. Is this ok? I'd like to test this series, too. It would be good if a README existed in the board directory, with some instructions how to build and install an image on SD card (or other boot source, if already supported). E.g. like board/freescale/mx6sabresd/README. Thanks! -- Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 00/32] i.MX: Add i.MX8QXP support
On Thu, Jul 19, 2018 at 11:02 AM, Peng Fan wrote: > Currently there is no public available code for atf and scfw, so > There will no link in the README, I could only add steps > on how to build out images. Is this ok? Yes, a REAME file with the steps for generating a bootable SD card would be very helpful for us to test it. Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/11] arch: arm: mach-rockchip: rk3288: Enable regulators in board_init
Hi Philipp, Am 18.07.2018 um 11:05 schrieb Dr. Philipp Tomsich: > Janine, > >> On 18 Jul 2018, at 10:46, Janine Hagemann wrote: >> >> At start-up, the regulators have to be enabled. Let's use >> regulators_enable_boot_on() to enable the regulators needed >> for boot. >> >> Signed-off-by: Wadim Egorov >> Signed-off-by: Janine Hagemann > An equivalent change from Carlo has already been applied to U-Boot master. > Please review whether there’s additional changes needed, otherwise I’ll just > skip this one when processing. I don't see this patch on master. Anyway, Carlos patch enables the regulators only for the google veyrons. Regards, Wadim > > Thanks, > Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 29/32] fsl_esdhc: Update usdhc driver to support i.MX8
Hi Fabio, > -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: 2018年7月19日 22:01 > To: Peng Fan > Cc: Stefano Babic ; Fabio Estevam > ; U-Boot-Denx ; dl-linux-imx > > Subject: Re: [U-Boot] [PATCH V2 29/32] fsl_esdhc: Update usdhc driver to > support i.MX8 > > On Tue, Jul 17, 2018 at 10:35 PM, Peng Fan wrote: > > From: Ye Li > > > > Add CONFIG_ARCH_IMX8 to use the 64bits support in usdhc driver. > > > > Signed-off-by: Ye Li > > Signed-off-by: Peng Fan > > Cc: Jaehoon Chung > > --- > > drivers/mmc/fsl_esdhc.c | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c index > > 4528345c67..785b9e87a6 100644 > > --- a/drivers/mmc/fsl_esdhc.c > > +++ b/drivers/mmc/fsl_esdhc.c > > @@ -257,7 +257,7 @@ static int esdhc_setup_data(struct fsl_esdhc_priv > *priv, struct mmc *mmc, > > int timeout; > > struct fsl_esdhc *regs = priv->esdhc_regs; #if > > defined(CONFIG_FSL_LAYERSCAPE) || defined(CONFIG_S32V234) || \ > > - defined(CONFIG_MX8M) > > + defined(CONFIG_ARCH_IMX8) || defined(CONFIG_MX8M) > > I am a bit confused: why do we need the || here? > > Doesn't CONFIG_ARCH_IMX8 also relate to MX8M? There is i.MX8/8X/8M, 8M is for i.MX8MQ and i.MX8MM i.MX8/8X has different SoC architecture compared with i.MX8M, such as there is SCU inside i.MX8/8X. So add a new macro dedicated for i.MX8/8X. Thanks, Peng. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 26/32] serial_lpuart: Update lpuart driver to support i.MX8
On Tue, Jul 17, 2018 at 10:35 PM, Peng Fan wrote: > Add i.MX8 compatible string and cpu type support to lpuart driver, > to use little endian 32 bits configurations. > > Also, accroding to RM, the Receive FIFO Enable (RXFE) field in LPUART > FIFO register is bit 3, so the definition should change to 0x08 not 0x40 > for i.MX8, otherwise the Receive FIFO is not disabled. > > Signed-off-by: Peng Fan > Signed-off-by: Ye Li Who is the original author here? If it is Ye Li, then his name should appear in the From field. The driver part could be sent independently of this series. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 00/32] i.MX: Add i.MX8QXP support
Hi Fabio, > -Original Message- > From: Fabio Estevam [mailto:feste...@gmail.com] > Sent: 2018年7月19日 21:42 > To: Peng Fan > Cc: Stefano Babic ; Fabio Estevam > ; U-Boot-Denx ; dl-linux-imx > ; Diego Dorta > Subject: Re: [U-Boot] [PATCH V2 00/32] i.MX: Add i.MX8QXP support > > Hi Peng, > > On Tue, Jul 17, 2018 at 10:35 PM, Peng Fan wrote: > > This patchset is to upstream i.MX8QXP and mek board support, with some > > drivers update to support i.MX8QXP. The information about the > > processor could be found > > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > > .nxp.com%2Fproducts%2Fprocessors-and-microcontrollers%2Fapplications-p > > rocessors%2Fi.mx-applications-processors%2Fi.mx-8-processors%2Fi.mx-8x > > -family-arm-cortex-a35-3d-graphics-4k-video-dsp-error-correcting-code- > > > on-ddr%3Ai.MX8Xdata=02%7C01%7Cpeng.fan%40nxp.com%7C3ec36c6b > 06ef45 > > > caefc608d5ed7d5a5d%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C > 636676 > > > 044997454563sdata=LweMZY4wGqxws%2BDk%2FYZuwuCXZtj%2FKzEV > M98%2Be2z > > m2tA%3Dreserved=0 > > > > The architecture of i.MX8QXP is different from i.MX6/7/8M, inside > > i.MX8QXP, there is a dedicated processor(SCU) used for > > power/clock/pin/ pad/resource management/thermal and etc. > > I understand you are adding MX8QXP support in this series, but what happened > to the previous MX8M one? > > I think we should get MX8M supported in U-Boot first. As you could see from our internal maillist, Jacky has posted out i.MX8MM the Restricted DDR code for review today. i.MX8MQ ddr code restructure is his next step. After Jacky done that internally, the ddr and board code will be posted out to community. I understand the ddr part block i.MX8MQ support in community for months. But i.MX8QXP is totally different new architecture and it does not have the ddr code issue. Also the scfw part has been restructured in the patchset v2. Please consider reviewing the patchset > > Also, in order to test this series we need a README file. Please prepare one > so > that we can test it. Currently there is no public available code for atf and scfw, so There will no link in the README, I could only add steps on how to build out images. Is this ok? > > I hope you have managed to get rid of the custom mkimage by now :-) Still not. I have been working on other areas in the past days. Hope I could port imx-mkimage to uboot. Thanks, Peng. > > Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 29/32] fsl_esdhc: Update usdhc driver to support i.MX8
On Tue, Jul 17, 2018 at 10:35 PM, Peng Fan wrote: > From: Ye Li > > Add CONFIG_ARCH_IMX8 to use the 64bits support in usdhc driver. > > Signed-off-by: Ye Li > Signed-off-by: Peng Fan > Cc: Jaehoon Chung > --- > drivers/mmc/fsl_esdhc.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c > index 4528345c67..785b9e87a6 100644 > --- a/drivers/mmc/fsl_esdhc.c > +++ b/drivers/mmc/fsl_esdhc.c > @@ -257,7 +257,7 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv, > struct mmc *mmc, > int timeout; > struct fsl_esdhc *regs = priv->esdhc_regs; > #if defined(CONFIG_FSL_LAYERSCAPE) || defined(CONFIG_S32V234) || \ > - defined(CONFIG_MX8M) > + defined(CONFIG_ARCH_IMX8) || defined(CONFIG_MX8M) I am a bit confused: why do we need the || here? Doesn't CONFIG_ARCH_IMX8 also relate to MX8M? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 14/32] armv8: add cpu core helper functions
Hi Peng,
On Tue, Jul 17, 2018 at 10:35 PM, Peng Fan wrote:
> Add helper functions to identify different armv8 variants.
>
> Signed-off-by: Peng Fan
> ---
> arch/arm/include/asm/armv8/cpu.h | 26 ++
> 1 file changed, 26 insertions(+)
> create mode 100644 arch/arm/include/asm/armv8/cpu.h
>
> diff --git a/arch/arm/include/asm/armv8/cpu.h
> b/arch/arm/include/asm/armv8/cpu.h
> new file mode 100644
> index 00..40d54dc85a
> --- /dev/null
> +++ b/arch/arm/include/asm/armv8/cpu.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright 2018 NXP
> + */
> +
> +#define MIDR_PARTNUM_CORTEX_A350xD04
> +#define MIDR_PARTNUM_CORTEX_A530xD03
> +#define MIDR_PARTNUM_CORTEX_A720xD08
> +#define MIDR_PARTNUM_SHIFT 0x4
> +#define MIDR_PARTNUM_MASK (0xFFF << 0x4)
> +
> +static inline unsigned int read_midr(void)
> +{
> + unsigned long val;
> +
> + asm volatile("mrs %0, midr_el1" : "=r" (val));
> +
> + return val;
> +}
> +
> +#define is_cortex_a35() (((read_midr() & MIDR_PARTNUM_MASK) >> \
> +MIDR_PARTNUM_SHIFT) == MIDR_PARTNUM_CORTEX_A35)
> +#define is_cortex_a53() (((read_midr() & MIDR_PARTNUM_MASK) >> \
> +MIDR_PARTNUM_SHIFT) == MIDR_PARTNUM_CORTEX_A53)
> +#define is_cortex_a72() (((read_midr() & MIDR_PARTNUM_MASK) >>\
> +MIDR_PARTNUM_SHIFT) == MIDR_PARTNUM_CORTEX_A72)
This is not mx8 specific, so this header could be on a more common location.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/16] pico-imx7d: Convert to distro config
Hi Otavio
On Fri, Jun 29, 2018 at 8:19 PM, Otavio Salvador
wrote:
> From: Fabio Estevam
>
> Instead of keeping a custom environment, use a more generic approach
> by switching to disto config.
>
> Signed-off-by: Fabio Estevam
> Signed-off-by: Otavio Salvador
> ---
>
For all the series please add Tested-by: Michael Trimarchi
> include/configs/pico-imx7d.h | 55 +---
> 1 file changed, 14 insertions(+), 41 deletions(-)
>
> diff --git a/include/configs/pico-imx7d.h b/include/configs/pico-imx7d.h
> index d2ffa70fc5..243c12faea 100644
> --- a/include/configs/pico-imx7d.h
> +++ b/include/configs/pico-imx7d.h
> @@ -41,48 +41,21 @@
> "console=ttymxc4\0" \
> "fdt_high=0x\0" \
> "initrd_high=0x\0" \
> - "fdt_file=imx7d-pico-pi.dtb\0" \
> + "fdtfile=imx7d-pico-pi.dtb\0" \
> "fdt_addr=0x8300\0" \
> - "ip_dyn=yes\0" \
> - "mmcdev="__stringify(CONFIG_SYS_MMC_ENV_DEV)"\0" \
> - "mmcpart=" __stringify(CONFIG_SYS_MMC_IMG_LOAD_PART) "\0" \
> - "finduuid=part uuid mmc 0:2 uuid\0" \
> - "mmcargs=setenv bootargs console=${console},${baudrate} " \
> - "root=PARTUUID=${uuid} rootwait rw\0" \
> - "loadimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
> - "loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
> - "mmcboot=echo Booting from mmc ...; " \
> - "run finduuid; " \
> - "run mmcargs; " \
> - "if run loadfdt; then " \
> - "bootz ${loadaddr} - ${fdt_addr}; " \
> - "else " \
> - "echo WARN: Cannot load the DT; " \
> - "fi;\0" \
> - "netargs=setenv bootargs console=${console},${baudrate} " \
> - "root=/dev/nfs " \
> - "ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0" \
> - "netboot=echo Booting from net ...; " \
> - "run netargs; " \
> - "if test ${ip_dyn} = yes; then " \
> - "setenv get_cmd dhcp; " \
> - "else " \
> - "setenv get_cmd tftp; " \
> - "fi; " \
> - "${get_cmd} ${image}; " \
> - "if ${get_cmd} ${fdt_addr} ${fdt_file}; then " \
> - "bootz ${loadaddr} - ${fdt_addr}; " \
> - "else " \
> - "echo WARN: Cannot load the DT; " \
> - "fi;\0"
> -
> -#define CONFIG_BOOTCOMMAND \
> - "if mmc rescan; then " \
> - "if run loadimage; then " \
> - "run mmcboot; " \
> - "else run netboot; " \
> - "fi; " \
> - "else run netboot; fi"
> + "fdt_addr_r=0x8300\0" \
> + "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
> + "pxefile_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
> + "ramdisk_addr_r=0x8300\0" \
> + "ramdiskaddr=0x8300\0" \
> + "scriptaddr=" __stringify(CONFIG_LOADADDR) "\0" \
> + BOOTENV
> +
> +#define BOOT_TARGET_DEVICES(func) \
> + func(MMC, mmc, 0) \
> + func(DHCP, dhcp, na)
> +
> +#include
>
> #define CONFIG_SYS_MEMTEST_START 0x8000
> #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START +
> 0x2000)
> --
> 2.18.0
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
--
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO - Founder Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
| [`as] http://www.amarulasolutions.com |
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] env: Merge Rockchip, Sunxi, Zynq and ZynqMP
On 19.7.2018 13:13, Maxime Ripard wrote: > Hi, > > On Thu, Jul 19, 2018 at 08:45:45AM +0200, Michal Simek wrote: >> There is no reason to have the same Kconfig options for different SoCs >> separately. The patch is merging them together. >> >> Signed-off-by: Michal Simek >> --- >> >> Patch is based on >> https://lists.denx.de/pipermail/u-boot/2018-July/335126.html >> >> I have ENV_SECT_SIZE just for zynq/zynqmp because rockchip and sunxi >> have this in their configs. When they decide to move then can enable >> that option for them too. >> I expect when more platforms extend this we will have less constrain >> Kconfig setup. >> >> --- >> env/Kconfig | 66 >> - >> 1 file changed, 17 insertions(+), 49 deletions(-) >> >> diff --git a/env/Kconfig b/env/Kconfig >> index b37dcd78eb75..0ded003d7d41 100644 >> --- a/env/Kconfig >> +++ b/env/Kconfig >> @@ -431,23 +431,37 @@ config ENV_EXT4_FILE >>It's a string of the EXT4 file name. This file use to store the >>environment (explicit path to the file) >> >> -if ARCH_SUNXI >> +if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP > > Can we have a depends on instead? That would be more flexible. In what sense? If depends is used below then the same 4 platforms will be listed on all options below. (I want to also add ZYNQMP_R5 there too) And changing this in one place seems to me better then on four. >> config ENV_OFFSET >> hex "Environment Offset" >> depends on !ENV_IS_IN_UBI >> depends on !ENV_IS_NOWHERE >> +default 0x3f8000 if ARCH_ROCKCHIP >> default 0x88000 if ARCH_SUNXI >> +default 0xE if ARCH_ZYNQ >> +default 0x1E0 if ARCH_ZYNQMP >> help >>Offset from the start of the device (or partition) >> >> config ENV_SIZE >> hex "Environment Size" >> -depends on !ENV_IS_NOWHERE >> -default 0x2 if ARCH_SUNXI >> +default 0x8000 if ARCH_ROCKCHIP && !ENV_IS_NOWHERE >> +default 0x2 if ARCH_SUNXI && !ENV_IS_NOWHERE > > I'm not sure why you removed the depends on !ENV_IS_NOWHERE. Do you > have a case where the environment is not store anywhere but still need > a size? yes, I had a compilation warning for that case. in include/environment.h at line 145 it is written this #define ENV_SIZE (CONFIG_ENV_SIZE - ENV_HEADER_SIZE) ENV_SIZE is also used in typedef struct environment_s some lines below. And this structure is used a lot. How did you find out that this can't be used for ENV_IS_NOWHERE? Thanks, Michal ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH V2 00/32] i.MX: Add i.MX8QXP support
Hi Peng, On Tue, Jul 17, 2018 at 10:35 PM, Peng Fan wrote: > This patchset is to upstream i.MX8QXP and mek board support, with some > drivers update to support i.MX8QXP. The information about the processor > could be found > https://www.nxp.com/products/processors-and-microcontrollers/applications-processors/i.mx-applications-processors/i.mx-8-processors/i.mx-8x-family-arm-cortex-a35-3d-graphics-4k-video-dsp-error-correcting-code-on-ddr:i.MX8X > > The architecture of i.MX8QXP is different from i.MX6/7/8M, inside i.MX8QXP, > there is a dedicated processor(SCU) used for power/clock/pin/ > pad/resource management/thermal and etc. I understand you are adding MX8QXP support in this series, but what happened to the previous MX8M one? I think we should get MX8M supported in U-Boot first. Also, in order to test this series we need a README file. Please prepare one so that we can test it. I hope you have managed to get rid of the custom mkimage by now :-) Thanks ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 21/25] fastboot: sunxi: Update fastboot mmc default device
On Wed, Jul 18, 2018 at 08:15:23PM +0100, Alex Kiernan wrote: > On Tue, Jul 17, 2018 at 12:57 PM Maxime Ripard > wrote: > > > > On Mon, Jul 16, 2018 at 12:11:59PM +0100, Alex Kiernan wrote: > > > On Mon, Jul 16, 2018 at 11:13 AM Jagan Teki > > > wrote: > > > > > > > > On Mon, Jul 16, 2018 at 3:16 PM, Maxime Ripard > > > > wrote: > > > > > On Mon, Jul 16, 2018 at 01:49:52PM +0530, Jagan Teki wrote: > > > > >> Usually eMMC is default env fat device for environment, > > > > >> if MMC_SUNXI_SLOT_EXTRA != 1 Sunxi always probed emmc > > > > >> device as 1. but with DM_MMC it can be more possible to > > > > >> probe eMMC as device 2 since for most of the sunxi platforms > > > > >> eMMC is configured mmc2. > > > > >> > > > > >> So update the fastboot mmc default device as 2 if DM_MMC and > > > > >> MMC_SUNXI_SLOT_EXTRA != 1 slot is 2 defined but some boards > > > > >> may not use all possible mmc devices or partly disabled in DT, > > > > >> for those update the device in board specific defconfig. > > > > >> > > > > >> Cc: Olliver Schinagl > > > > >> Cc: Chen-Yu Tsai > > > > >> Signed-off-by: Jagan Teki > > > > >> --- > > > > >> configs/A20-OLinuXino-Lime2-eMMC_defconfig | 1 + > > > > >> configs/Sinlinx_SinA33_defconfig | 1 + > > > > >> configs/amarula_a64_relic_defconfig| 1 + > > > > >> drivers/fastboot/Kconfig | 3 ++- > > > > >> 4 files changed, 5 insertions(+), 1 deletion(-) > > > > >> > > > > >> diff --git a/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > > >> b/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > > >> index 5657fc2594..20ea254191 100644 > > > > >> --- a/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > > >> +++ b/configs/A20-OLinuXino-Lime2-eMMC_defconfig > > > > >> @@ -29,4 +29,5 @@ CONFIG_AXP_ALDO4_VOLT=2800 > > > > >> CONFIG_SCSI=y > > > > >> CONFIG_USB_EHCI_HCD=y > > > > >> CONFIG_USB_MUSB_GADGET=y > > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 > > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y > > > > >> diff --git a/configs/Sinlinx_SinA33_defconfig > > > > >> b/configs/Sinlinx_SinA33_defconfig > > > > >> index 394534b8b5..7841219a65 100644 > > > > >> --- a/configs/Sinlinx_SinA33_defconfig > > > > >> +++ b/configs/Sinlinx_SinA33_defconfig > > > > >> @@ -21,5 +21,6 @@ CONFIG_DFU_RAM=y > > > > >> CONFIG_FASTBOOT_CMD_OEM_FORMAT=y > > > > >> CONFIG_USB_EHCI_HCD=y > > > > >> CONFIG_USB_MUSB_GADGET=y > > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1 > > > > > > > > > > Your commit doesn't make any sense: the SinaA33 and the Lime2 both > > > > > have the eMMC on MMC2, and you claim you want to update the default to > > > > > point to MMC2, but you're changing both these boards to point to MMC1 > > > > > instead? > > > > > > > > If DM_MMC and SLOT != 1 => default device 2 which is updated by > > > > kconfig, this is with all relevant mmc nodes are enabled > > > > but these two boards mmc1 is not enabled so emmc will detected in > > > > device 1 > > > > > > > > > > > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y > > > > >> CONFIG_USB_FUNCTION_MASS_STORAGE=y > > > > >> diff --git a/configs/amarula_a64_relic_defconfig > > > > >> b/configs/amarula_a64_relic_defconfig > > > > >> index b72cbfabc6..caeb3f6008 100644 > > > > >> --- a/configs/amarula_a64_relic_defconfig > > > > >> +++ b/configs/amarula_a64_relic_defconfig > > > > >> @@ -12,4 +12,5 @@ > > > > >> CONFIG_DEFAULT_DEVICE_TREE="sun50i-a64-amarula-relic" > > > > >> # CONFIG_SPL_DOS_PARTITION is not set > > > > >> # CONFIG_SPL_EFI_PARTITION is not set > > > > >> CONFIG_USB_MUSB_GADGET=y > > > > >> +CONFIG_FASTBOOT_FLASH_MMC_DEV=0 > > > > >> CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y > > > > >> diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig > > > > >> index bc25ea1d9c..4a1bfd119c 100644 > > > > >> --- a/drivers/fastboot/Kconfig > > > > >> +++ b/drivers/fastboot/Kconfig > > > > >> @@ -88,7 +88,8 @@ config FASTBOOT_FLASH_MMC_DEV > > > > >> int "Define FASTBOOT MMC FLASH default device" > > > > >> depends on FASTBOOT_FLASH_MMC > > > > >> default 0 if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA = -1 > > > > >> - default 1 if ARCH_SUNXI && MMC_SUNXI_SLOT_EXTRA != -1 > > > > >> + default 1 if ARCH_SUNXI && !DM_MMC && MMC_SUNXI_SLOT_EXTRA != > > > > >> -1 > > > > >> + default 2 if ARCH_SUNXI && DM_MMC && MMC_SUNXI_SLOT_EXTRA != -1 > > > > > > > > > > It'd be better to be fixed properly, instead of just relying on a > > > > > broken index. > > > > > > > > I don't think we can't do anything with this now, since this INDEX > > > > more rely on SPL for pinctrl enablement. if you have any suggestion > > > > please share. > > > > > > Would another answer (at least for this specific case) to change the > > > fastboot code so it doesn't need the device number in advance? Given > > > we get device names along the lines of 'mmcsda1', we could parse out > > > the 'a' to figure out the device number (and then use the alias code > > > so your board can expose a portable
Re: [U-Boot] [PATCH v2] Add Beaglebone Enhanced support
On Thu, Jul 19, 2018 at 03:07:55PM +0200, Marek Vasut wrote: > On 07/19/2018 03:02 PM, Tom Rini wrote: > > On Thu, Jul 19, 2018 at 02:55:37PM +0200, Marek Vasut wrote: > >> On 07/18/2018 10:13 AM, Koen Kooi wrote: > >>> The "Beaglebone Enhanced" by Sancloud is based on the Beaglebone Black, > >>> but with the following differences: > >>> > >>> * Gigabit capable PHY > >>> * Extra USB hub, optional i2c control > >>> * lps3331ap barometer connected over i2c > >>> * MPU6050 6 axis MEMS accelerometer/gyro connected over i2c > >>> * 1GiB DDR3 RAM > >>> * RTL8723 Wifi/Bluetooth connected over USB > >>> > >>> Signed-off-by: Koen Kooi > >>> > >>> --- > >>> > >> [...] > >> > >>> diff --git a/board/ti/am335x/board.h b/board/ti/am335x/board.h > >>> index 652b10b..48df914 100644 > >>> --- a/board/ti/am335x/board.h > >>> +++ b/board/ti/am335x/board.h > >>> @@ -43,9 +43,15 @@ static inline int board_is_bbg1(void) > >>> return board_is_bone_lt() && !strncmp(board_ti_get_rev(), "BBG1", 4); > >>> } > >>> > >>> +static inline int board_is_bben(void) > >> > >> Should be just static int ... the compiler can decide. > > > > No, it should be inline like all of the others in the file are. And > > then yes, if someone wants to do a size comparison with or without > > inlining on all of those functions, sure. > > Can you explain why it should be static inline ? > Last time this discussion came up in Linux kernel ML (decisions from > which we seem to apply, cfr the SPDX C++ comments and DTC), static > inline was frowned upon with the argument that the compiler can decide. Ah, alright. So yeah, as people want to convert areas, that's fine. But no, just like how we also stay consistent within a file on other things, or fix those inconsistencies then add more stuff, no, we shouldn't have this be inconsistent. Fixing it in either order is fine with me. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC 2/2] env: Add prefix to error messages when loading env
On Thu, Jul 19, 2018 at 3:52 PM, Tom Rini wrote: > On Wed, Jul 18, 2018 at 04:09:33PM +0200, Wolfgang Denk wrote: >> Dear Tom, >> >> In message <20180718125351.GE4609@bill-the-cat> you wrote: >> > >> > > Loading Environment from FAT... >> > >--> MMC: no card present >> > >--> ** Bad device mmc 0 ** >> > >--> Failed (-5) >> > > Loading Environment from MMC... >> > >--> OK >> > > >> > > instead of: >> > > >> > > Loading Environment from FAT... MMC: no card present >> > > ** Bad device mmc 0 ** >> > > Failed (-5) >> > > Loading Environment from MMC... OK >> > >> > So, I think maybe (and given Wolfgang's comments) we should think about >> > how the output might want to look, and how to get there without GD >> > changes. Perhaps: >> > Attempting to load Environment from FAT (do we have more easily >> > available info at this point?): >> > MMC: no card present >> > ** Bad device mmc 0 ** >> > Failed (-5) >> > Loading Environment from MMC... >> > Attempting to load Environment from MMC: >> > Succeeded >> >> Just my 0.02€: >> >> In the non-error case, the output should be a single (ideally short) >> line. >> >> Rationale: to many lines of ourput clutter your screen and make you >> miss context faster; to many/long lines take time to print so they >> make booting slower. >> >> In the error case, the user should be able to understand what the >> problem was and decide if it was critical or can be ignored (like >> here when intentionally booting without SDCard). > > I understand, but I don't know if we can get there still. The problem > is we don't know if we've succeeded until we've done the relevant > probing and that in turn is what's breaking the single line, and got us > to where we are now. > Actually we can, please see my new RFC patch [1]. It's a bit hacky, but the only other way to do so is to rework drivers (MMC, etc). Also, I figured how to do prefixing (to display MMC errors as nested w.r.t. "Loading environment), without adding new field to gd. We can just add some new GD_LG_ and print prefix when it's installed. I'm gonna send new RFC soon. Please let me know what you think about [1]. [1] https://lists.denx.de/pipermail/u-boot/2018-July/335223.html > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Add Beaglebone Enhanced support
On 07/19/2018 03:02 PM, Tom Rini wrote: > On Thu, Jul 19, 2018 at 02:55:37PM +0200, Marek Vasut wrote: >> On 07/18/2018 10:13 AM, Koen Kooi wrote: >>> The "Beaglebone Enhanced" by Sancloud is based on the Beaglebone Black, >>> but with the following differences: >>> >>> * Gigabit capable PHY >>> * Extra USB hub, optional i2c control >>> * lps3331ap barometer connected over i2c >>> * MPU6050 6 axis MEMS accelerometer/gyro connected over i2c >>> * 1GiB DDR3 RAM >>> * RTL8723 Wifi/Bluetooth connected over USB >>> >>> Signed-off-by: Koen Kooi >>> >>> --- >>> >> [...] >> >>> diff --git a/board/ti/am335x/board.h b/board/ti/am335x/board.h >>> index 652b10b..48df914 100644 >>> --- a/board/ti/am335x/board.h >>> +++ b/board/ti/am335x/board.h >>> @@ -43,9 +43,15 @@ static inline int board_is_bbg1(void) >>> return board_is_bone_lt() && !strncmp(board_ti_get_rev(), "BBG1", 4); >>> } >>> >>> +static inline int board_is_bben(void) >> >> Should be just static int ... the compiler can decide. > > No, it should be inline like all of the others in the file are. And > then yes, if someone wants to do a size comparison with or without > inlining on all of those functions, sure. Can you explain why it should be static inline ? Last time this discussion came up in Linux kernel ML (decisions from which we seem to apply, cfr the SPDX C++ comments and DTC), static inline was frowned upon with the argument that the compiler can decide. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
