Re: [U-Boot] recommended place to add some custom settings to u-boot environment?
On Wed, 14 Sep 2016, Wolfgang Denk wrote: > Dear Robert, > > In message you > wrote: > > > > > Why not simply putting this as text (or wrapped with an uImage > > > header) into some storage (or even a file) and then use "env import" > > > to load it? > > > > the problem is that that additional "environment" info is on the > > target board because of a legacy non-linux OS -- it's at a > > well-known address in flash, and we have no freedom to change it, > > we can only read it, make some adjustments, then incorporate it > > into the current environment. > > Which format is used? Can it not be made to work with "env import" > using this well-known address? I mean, if it's plain text, it > should just work. If it's some other, more exotic format, you could > probably implement a custom import format? it needs to be done programatically, and i *believe* himport_r() can handle it, as the string is space-separated and null-terminated, so i'm about to test that. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] really weird return codes in mcf5373l.c, misc_init_r()
ok, now i'm just being entertained by the truly strange code i'm
running across. here's a snippet from board/astro/mcf5373l/mcf5373l.c;
what strikes you as odd about it?
int misc_init_r(void)
{
int retval = 0;
puts("Configure Xilinx FPGA...");
retval = astro5373l_xilinx_load();
if (!retval) {
puts("failed!\n");
return retval;
}
puts("done\n");
puts("Configure Altera FPGA...");
retval = astro5373l_altera_load();
if (!retval) {
puts("failed!\n");
return retval;
}
puts("done\n");
return retval;
}
yes, if astro5373l_xilinx_load() returns zero, then "!retval" is true,
at which point that call will have failed, and this routine will
return ... zero. same with the code below that. so under what
circumstances can that routine return zero? oh ... it can't:
/* Initialize the fpga. Return 1 on success, 0 on failure. */
int astro5373l_xilinx_load(void)
{
int i;
fpga_init();
for (i = 0; i < CONFIG_FPGA_COUNT; i++) {
/*
* I did not yet manage to get relocation work properly,
* so set stuff here instead of static initialisation:
*/
xilinx_fns.pre = xilinx_pre_config_fn;
xilinx_fns.pgm = xilinx_pgm_config_fn;
xilinx_fns.clk = xilinx_clk_config_fn;
xilinx_fns.init = xilinx_init_config_fn;
xilinx_fns.done = xilinx_done_config_fn;
xilinx_fns.wr = xilinx_wr_config_fn;
xilinx_fns.bwr = xilinx_fastwr_config_fn;
xilinx_fpga[i].iface_fns = (void *)&xilinx_fns;
fpga_add(fpga_xilinx, &xilinx_fpga[i]);
}
return 1;
i've seen other strange examples like this.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] eb_cpu5282.c board returns failure(?) from misc_init_r()
i was just perusing the underlying code for invoking initcalls
(mostly because i forgot to return the correct value, and bricked my
target board), and i see this in lib/initcall.c:
ret = (*init_fnc_ptr)();
if (ret) {
printf("initcall sequence %p failed at call %p (err=%d)\n",
init_sequence,
(char *)*init_fnc_ptr - reloc_ofs, ret);
return -1;
}
so, perfectly reasonably, if an initcall returns a non-zero value,
that's failure, which is why misc_init_r() should, as long as
everything succeeds, return zero, correct?
but there's this in board/BuS/eb_cpu5282/eb_cpu5282.c:
int misc_init_r(void)
{
#ifdef CONFIG_HW_WATCHDOG
hw_watchdog_init();
#endif
return 1;
}
i haven't dug into this any further to see if that's a special case,
but isn't that going to return failure every time it's invoked?
it may be that that board doesn't define the watchdog or the use of
misc_init_r(), but that just seems ... wrong? thoughts?
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] recommended place to add some custom settings to u-boot environment?
On Wed, 14 Sep 2016, Wolfgang Denk wrote: > Dear Robert, > > In message you > wrote: > > > > on my target board, there is some non-linux environment info in > > "var=val" form that i want to drag into the current environment > > whenever u-boot starts up. my plan is just to import that content > > into a (new) hash table, then tweak it a bit before further adding > > it to "env_htab". the logistics seem pretty straightforward, i'm > > just curious as to where the *right*(?) place is to do this. > > Sounds complicated... > > > does that make sense? at that point, all of the normal > > environment will have been initialized, and i'll have access to > > "env_htab". thoughts? is there a better place to "adjust" the > > u-boot environment once u-boot has done its normal work? thanks. > > Why not simply putting this as text (or wrapped with an uImage > header) into some storage (or even a file) and then use "env import" > to load it? the problem is that that additional "environment" info is on the target board because of a legacy non-linux OS -- it's at a well-known address in flash, and we have no freedom to change it, we can only read it, make some adjustments, then incorporate it into the current environment. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] recommended place to add some custom settings to u-boot environment?
on my target board, there is some non-linux environment info in "var=val" form that i want to drag into the current environment whenever u-boot starts up. my plan is just to import that content into a (new) hash table, then tweak it a bit before further adding it to "env_htab". the logistics seem pretty straightforward, i'm just curious as to where the *right*(?) place is to do this. currently, we're not taking advantage of CONFIG_MISC_INIT_R, so it seems that would be a reasonable place to do that, in the board source file. does that make sense? at that point, all of the normal environment will have been initialized, and i'll have access to "env_htab". thoughts? is there a better place to "adjust" the u-boot environment once u-boot has done its normal work? thanks. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] PWM: Correct misspellings of "module" in context of PWM
Signed-off-by: Robert P. J. Day --- diff --git a/README b/README index f41a6af..30076bc 100644 --- a/README +++ b/README @@ -1405,7 +1405,7 @@ The following options need to be configured: - PWM Support: CONFIG_PWM_IMX - Support for PWM modul on the imx6. + Support for PWM module on the imx6. - TPM Support: CONFIG_TPM diff --git a/drivers/pwm/pwm-imx-util.c b/drivers/pwm/pwm-imx-util.c index f92c370..285564a 100644 --- a/drivers/pwm/pwm-imx-util.c +++ b/drivers/pwm/pwm-imx-util.c @@ -2,7 +2,7 @@ * (C) Copyright 2014 * Heiko Schocher, DENX Software Engineering, h...@denx.de. * - * Basic support for the pwm modul on imx6. + * Basic support for the pwm module on imx6. * * Based on linux:drivers/pwm/pwm-imx.c * from diff --git a/drivers/pwm/pwm-imx-util.h b/drivers/pwm/pwm-imx-util.h index 45465c4..5c18651 100644 --- a/drivers/pwm/pwm-imx-util.h +++ b/drivers/pwm/pwm-imx-util.h @@ -2,7 +2,7 @@ * (C) Copyright 2014 * Heiko Schocher, DENX Software Engineering, h...@denx.de. * - * Basic support for the pwm modul on imx6. + * Basic support for the pwm module on imx6. * * SPDX-License-Identifier:GPL-2.0 */ diff --git a/drivers/pwm/pwm-imx.c b/drivers/pwm/pwm-imx.c index 47799fc..3f808f9 100644 --- a/drivers/pwm/pwm-imx.c +++ b/drivers/pwm/pwm-imx.c @@ -2,7 +2,7 @@ * (C) Copyright 2014 * Heiko Schocher, DENX Software Engineering, h...@denx.de. * - * Basic support for the pwm modul on imx6. + * Basic support for the pwm module on imx6. * * SPDX-License-Identifier:GPL-2.0+ */ -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] question about himport_r() and possible separator
admittedly a simple question that i'll be able to test once i get into the lab later today, but if someone knows the answer, terrific. putting u-boot on a target board where there already exists, at a well-known address, a set of "var=val" settings, with the format: var1=val1 var2=val2 ... varn=valn\0 that is: 1) single space-separated 2) terminated by null byte will current himport_r() handle importing this into a hashtable if i specify a space character as separator, ***given*** that there is no terminating space character after the final assignment? perusing the code, it *looks* like that will work, given that i can get the exact length of the values with strlen(), and i hand that off to himport_r(), it appears that all will be well. am i overlooking any subtle gotcha here? rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] pedantry: is a FIT image really an enhanced type of uImage?
a matter of picky terminology, but i'm reading the docs on FIT images, and in doc/uImage.FIT/source_file_format.txt, early on, i read: "U-Boot new uImage source file format (bindings definition) ... This document defines new uImage structure ..." and so on and so on ... a number of references that appear to describe FIT images as newer and enhanced types of uImage. but i understood that the proper definition of uImage is the "legacy" form for u-boot, and there are now alternates such as zImage and, yes, FIT images. the man page for "mkimage" reads: SYNOPSIS mkimage -l [uimage file name] mkimage [options] -f [image tree source file] [uimage file name] mkimage [options] -F [uimage file name] mkimage [options] (legacy mode) and further down reads: OPTIONS List image information: -l [uimage file name] mkimage lists the information contained in the header of an existing U-Boot image. Create old legacy image: ... snip ... Create FIT image: ... snip ... and that latter part seems to suggest that FIT images are *distinct* from the legacy images. so what is the technically proper way to describe a FIT image? just another type of uImage? or a wholly new type of image? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] search.h: Numerous grammatical fixes, comment updates
Tweaks (no functional changes) to include/search.h, including:
* use standard multiple inclusion check
* fix spelling mistakes
* have comments match actual names in function prototypes
* remove obsolete reference to "do_apply"
* replace "hashing table" with "hash table"
Signed-off-by: Robert P. J. Day
---
compile-tested, should be no functional changes.
diff --git a/include/search.h b/include/search.h
index 343dbc3..402dfd8 100644
--- a/include/search.h
+++ b/include/search.h
@@ -12,8 +12,8 @@
* Copyright (C) 2010-2013 Wolfgang Denk
*/
-#ifndef _SEARCH_H
-#define_SEARCH_H 1
+#ifndef _SEARCH_H_
+#define _SEARCH_H_
#include
@@ -25,7 +25,7 @@ enum env_op {
env_op_overwrite,
};
-/* Action which shall be performed in the call the hsearch. */
+/* Action which shall be performed in the call to hsearch. */
typedef enum {
FIND,
ENTER
@@ -45,7 +45,7 @@ struct _ENTRY;
/*
* Family of hash table handling functions. The functions also
* have reentrant counterparts ending with _r. The non-reentrant
- * functions all work on a signle internal hashing table.
+ * functions all work on a single internal hash table.
*/
/* Data type for reentrant functions. */
@@ -55,38 +55,38 @@ struct hsearch_data {
unsigned int filled;
/*
* Callback function which will check whether the given change for variable
- * "item" to "newval" may be applied or not, and possibly apply such change.
+ * "__item" to "newval" may be applied or not, and possibly apply such change.
* When (flag & H_FORCE) is set, it shall not print out any error message and
* shall force overwriting of write-once variables.
-.* Must return 0 for approval, 1 for denial.
+ * Must return 0 for approval, 1 for denial.
*/
int (*change_ok)(const ENTRY *__item, const char *newval, enum env_op,
int flag);
};
-/* Create a new hashing table which will at most contain NEL elements. */
+/* Create a new hash table which will contain at most "__nel" elements. */
extern int hcreate_r(size_t __nel, struct hsearch_data *__htab);
-/* Destroy current internal hashing table. */
+/* Destroy current internal hash table. */
extern void hdestroy_r(struct hsearch_data *__htab);
/*
- * Search for entry matching ITEM.key in internal hash table. If
+ * Search for entry matching __item.key in internal hash table. If
* ACTION is `FIND' return found entry or signal error by returning
* NULL. If ACTION is `ENTER' replace existing data (if any) with
- * ITEM.data.
+ * __item.data.
* */
extern int hsearch_r(ENTRY __item, ACTION __action, ENTRY ** __retval,
struct hsearch_data *__htab, int __flag);
/*
- * Search for an entry matching `MATCH'. Otherwise, Same semantics
+ * Search for an entry matching "__match". Otherwise, Same semantics
* as hsearch_r().
*/
extern int hmatch_r(const char *__match, int __last_idx, ENTRY ** __retval,
struct hsearch_data *__htab);
-/* Search and delete entry matching ITEM.key in internal hash table. */
+/* Search and delete entry matching "__key" in internal hash table. */
extern int hdelete_r(const char *__key, struct hsearch_data *__htab,
int __flag);
@@ -97,8 +97,6 @@ extern ssize_t hexport_r(struct hsearch_data *__htab,
/*
* nvars: length of vars array
* vars: array of strings (variable names) to import (nvars == 0 means all)
- * do_apply: whether to call callback function to check the new argument,
- * and possibly apply changes (false means accept everything)
*/
extern int himport_r(struct hsearch_data *__htab,
const char *__env, size_t __size, const char __sep,
@@ -123,4 +121,4 @@ extern int hwalk_r(struct hsearch_data *__htab, int
(*callback)(ENTRY *));
#define H_PROGRAMMATIC (1 << 9) /* indicate that an import is from setenv() */
#define H_ORIGIN_FLAGS (H_INTERACTIVE | H_PROGRAMMATIC)
-#endif /* search.h */
+#endif /* _SEARCH_H_ */
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] "_ENTRY" is both a struct and a typedef?
from lib/hashtable.c:
typedef struct _ENTRY {
int used;
ENTRY entry;
} _ENTRY;
ok, that's just kind of creepy ... defining a typedef over top of a
struct of the same name. does anyone else find that strange?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Various, accumulated typos collected from around the tree.
Fix various misspellings of:
* deprecated
* partition
* preceding,preceded
* preparation
* its versus it's
* export
* existing
* scenario
* redundant
* remaining
* value
* architecture
Signed-off-by: Robert P. J. Day
---
just rebased against master so it should apply, tried to CC various
relevant people depending on location of typos.
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 1864ab9..6b46078 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -45,7 +45,7 @@ static inline void *phys_to_virt(unsigned long x)
/*
* Virtual <-> DMA view memory address translations
* Again, these are *only* valid on the kernel direct mapped RAM
- * memory. Use of these is *depreciated*.
+ * memory. Use of these is *deprecated*.
*/
#define virt_to_bus(x) (__virt_to_bus((unsigned long)(x)))
#define bus_to_virt(x) ((void *)(__bus_to_virt((unsigned long)(x
@@ -127,7 +127,7 @@ static inline void *phys_to_virt(unsigned long x)
#endif
/*
- * We should really eliminate virt_to_bus() here - it's depreciated.
+ * We should really eliminate virt_to_bus() here - it's deprecated.
*/
#define page_to_bus(page) (virt_to_bus(page_address(page)))
diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index 78a7fac..3a4e902 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -132,7 +132,7 @@ struct tag_ramdisk {
/* describes where the compressed ramdisk image lives (virtual address) */
/*
* this one accidentally used virtual addresses - as such,
- * its depreciated.
+ * it's deprecated.
*/
#define ATAG_INITRD0x54410005
diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index ef08489..cabf64c 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -489,7 +489,7 @@ static void dump_spd_ddr_reg(void)
for (i = 0; i < CONFIG_NUM_DDR_CONTROLLERS; i++)
fsl_ddr_get_spd(spd[i], i, CONFIG_DIMM_SLOTS_PER_CTLR);
- puts("SPD data of all dimms (zero vaule is omitted)...\n");
+ puts("SPD data of all dimms (zero value is omitted)...\n");
puts("Byte (hex) ");
k = 1;
for (i = 0; i < CONFIG_NUM_DDR_CONTROLLERS; i++) {
@@ -543,7 +543,7 @@ static void dump_spd_ddr_reg(void)
}
}
printf("DDR registers dump for all controllers "
- "(zero vaule is omitted)...\n");
+ "(zero value is omitted)...\n");
puts("Offset (hex) ");
for (i = 0; i < CONFIG_NUM_DDR_CONTROLLERS; i++)
printf(" Base + 0x%04x", (u32)ddr[i] & 0x);
diff --git a/board/technexion/twister/twister.c
b/board/technexion/twister/twister.c
index 48d207f..4a3d094 100644
--- a/board/technexion/twister/twister.c
+++ b/board/technexion/twister/twister.c
@@ -140,7 +140,7 @@ int board_mmc_init(bd_t *bis)
#ifdef CONFIG_SPL_OS_BOOT
/*
- * Do board specific preperation before SPL
+ * Do board specific preparation before SPL
* Linux boot
*/
void spl_board_prepare_for_linux(void)
diff --git a/board/timll/devkit8000/devkit8000.c
b/board/timll/devkit8000/devkit8000.c
index 965252f..f785dbe 100644
--- a/board/timll/devkit8000/devkit8000.c
+++ b/board/timll/devkit8000/devkit8000.c
@@ -157,7 +157,7 @@ int board_eth_init(bd_t *bis)
#ifdef CONFIG_SPL_OS_BOOT
/*
- * Do board specific preperation before SPL
+ * Do board specific preparation before SPL
* Linux boot
*/
void spl_board_prepare_for_linux(void)
diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index b67563b..9ca5cb5 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -15,7 +15,7 @@
*
* The "environment" is stored on external storage as a list of '\0'
* terminated "name=value" strings. The end of the list is marked by
- * a double '\0'. The environment is preceeded by a 32 bit CRC over
+ * a double '\0'. The environment is preceded by a 32 bit CRC over
* the data part and, in case of redundant environment, a byte of
* flags.
*
@@ -838,7 +838,7 @@ static int do_env_delete(cmd_tbl_t *cmdtp, int flag,
* With "-c" and size is NOT given, then the export command will
* format the data as currently used for the persistent storage,
* i. e. it will use CONFIG_ENV_SECT_SIZE as output block size and
- * prepend a valid CRC32 checksum and, in case of resundant
+ * prepend a valid CRC32 checksum and, in case of redundant
* environment, a "current" redundancy flag. If size is given, this
* value will be used instead of CONFIG_ENV_SECT_SIZE; again, CRC32
* checksum and redundancy flag will be inserted.
@@ -847,12 +847,12 @@ static int do_env_delete(cmd_tbl_t *cmdtp, int flag,
* terminating '\0' byte) will be written; here the optional size
* argument will be
Re: [U-Boot] why does only zynqmp check GD_FLG_ENV_DEFAULT?
On Wed, 7 Sep 2016, Michal Simek wrote: > Hi, > > zynqmp is using it because we don't want to rewrite boot sequence if > variables are saved already. > > You should look at these patches > git show 340b0e3bb6e88 > git show b72894f14da79 > > I expect you will find out thread about it too. > > Thanks, > Michal ah, thanks. i guess it's just odd that no one else takes advantage of that, it seems like a reasonable thing to do. rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] why does only zynqmp check GD_FLG_ENV_DEFAULT?
another curiosity, if i might ... notice:
$ grep -r GD_FLG_ENV_DEFAULT *
board/xilinx/zynqmp/zynqmp.c: if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
common/env_common.c: gd->flags |= GD_FLG_ENV_DEFAULT;
include/asm-generic/global_data.h:#define GD_FLG_ENV_DEFAULT 0x02000 /*
Default variable flag */
$
it seems a bit odd that there is a u-boot-wide global data flag that
is tested by only a single board. what exactly does that flag
represent?
rday
--
========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] is anyone using CONFIG_DELAY_ENVIRONMENT?
still crawling through env code and noticed this: $ grep -r DELAY_ENVIRONMENT * common/board_r.c:#elif defined CONFIG_DELAY_ENVIRONMENT README: CONFIG_DELAY_ENVIRONMENT $ so, absolutely no one is using that configuration setting? just curious. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] is it necessary to set "gd->env_valid = 0" in getenv_default()?
still wandering through the bowels of u-boot environment
manipulation code, and i see this in common/env_common.c:
/*
* Look up the variable from the default environment
*/
char *getenv_default(const char *name)
{
char *ret_val;
unsigned long really_valid = gd->env_valid;
unsigned long real_gd_flags = gd->flags;
/* Pretend that the image is bad. */
gd->flags &= ~GD_FLG_ENV_READY;
gd->env_valid = 0; <--- ?
ret_val = getenv(name);
gd->env_valid = really_valid;
gd->flags = real_gd_flags;
return ret_val;
}
fair enough ... in order to read a variable explicitly from the
(default) environment, temporarily fake that there is nothing in the
hash table, so this statement makes sense:
gd->flags &= ~GD_FLG_ENV_READY;
but is this one immediately afterwards also necessary?
gd->env_valid = 0;
because once you get to getenv() as defined in cmd/nvedit.c:
char *getenv(const char *name)
{
if (gd->flags & GD_FLG_ENV_READY) { /* after import into hashtable */
ENTRY e, *ep;
WATCHDOG_RESET();
e.key = name;
e.data = NULL;
hsearch_r(e, FIND, &ep, &env_htab, 0);
return ep ? ep->data : NULL;
}
/* restricted capabilities before import */
if (getenv_f(name, (char *)(gd->env_buf), sizeof(gd->env_buf)) > 0)
return (char *)(gd->env_buf);
return NULL;
}
it seems that the only test is for GD_ENV_FLG_READY, so setting
gd->env_valid=0 seems unnecessary. but perhaps i'm not reading far
enough.
rday
p.s. just to be clear, the meanings of those two gd members is:
gd->flags & GD_FLG_ENV_READY means the environment has been imported
into a hash table, and
gd->env_valid means the CRC for the environment in persistent
storage is correct.
do i understand that correctly?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] any value to XTRN_DECLARE_GLOBAL_DATA_PTR these days?
current usage/references:
$ grep -r XTRN_DECLARE_GLOBAL_DATA_PTR *
arch/powerpc/include/asm/global_data.h:#define XTRN_DECLARE_GLOBAL_DATA_PTR
extern
arch/powerpc/include/asm/global_data.h:#define DECLARE_GLOBAL_DATA_PTR
XTRN_DECLARE_GLOBAL_DATA_PTR \
common/board_f.c:#ifdef XTRN_DECLARE_GLOBAL_DATA_PTR
common/board_f.c:#undef XTRN_DECLARE_GLOBAL_DATA_PTR
common/board_f.c:#define XTRN_DECLARE_GLOBAL_DATA_PTR /* empty = allocate
here */
$
where the powerpc header file reads simply:
#if 1
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r2")
#else /* We could use plain global data, but the resulting code is bigger */
#define XTRN_DECLARE_GLOBAL_DATA_PTRextern
#define DECLARE_GLOBAL_DATA_PTR XTRN_DECLARE_GLOBAL_DATA_PTR \
gd_t *gd
#endif
is any other architecture manually defining that macro?
rday
--
========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] global_data.h: Standardize tabs and alignment for comments
Line up comments for readibility.
Signed-off-by: Robert P. J. Day
---
missed the last few lines with patch v1, and if i'm going to do it,
i might as well do it properly.
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index a6d1d2a..dc4cbdb 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -28,18 +28,18 @@ typedef struct global_data {
bd_t *bd;
unsigned long flags;
unsigned int baudrate;
- unsigned long cpu_clk; /* CPU clock in Hz! */
+ unsigned long cpu_clk; /* CPU clock in Hz! */
unsigned long bus_clk;
/* We cannot bracket this with CONFIG_PCI due to mpc5xxx */
unsigned long pci_clk;
unsigned long mem_clk;
#if defined(CONFIG_LCD) || defined(CONFIG_VIDEO)
- unsigned long fb_base; /* Base address of framebuffer mem */
+ unsigned long fb_base; /* Base address of framebuffer mem */
#endif
#if defined(CONFIG_POST) || defined(CONFIG_LOGBUFFER)
- unsigned long post_log_word; /* Record POST activities */
- unsigned long post_log_res; /* success of POST test */
- unsigned long post_init_f_time; /* When post_init_f started */
+ unsigned long post_log_word;/* Record POST activities */
+ unsigned long post_log_res; /* success of POST test */
+ unsigned long post_init_f_time; /* When post_init_f started */
#endif
#ifdef CONFIG_BOARD_TYPES
unsigned long board_type;
@@ -48,14 +48,13 @@ typedef struct global_data {
#ifdef CONFIG_PRE_CONSOLE_BUFFER
unsigned long precon_buf_idx; /* Pre-Console buffer index */
#endif
- unsigned long env_addr; /* Address of Environment struct */
+ unsigned long env_addr; /* Address of Environment struct */
unsigned long env_valid;/* Checksum of Environment valid? */
- unsigned long ram_top; /* Top address of RAM used by U-Boot */
-
+ unsigned long ram_top; /* Top address of RAM used by U-Boot */
unsigned long relocaddr;/* Start address of U-Boot in RAM */
- phys_size_t ram_size; /* RAM size */
- unsigned long mon_len; /* monitor len */
+ phys_size_t ram_size; /* RAM size */
+ unsigned long mon_len; /* monitor len */
unsigned long irq_sp; /* irq stack pointer */
unsigned long start_addr_sp;/* start_addr_stackpointer */
unsigned long reloc_off;
@@ -67,14 +66,14 @@ typedef struct global_data {
struct list_head uclass_root; /* Head of core tree */
#endif
#ifdef CONFIG_TIMER
- struct udevice *timer; /* Timer instance for Driver Model */
+ struct udevice *timer; /* Timer instance for Driver Model */
#endif
- const void *fdt_blob; /* Our device tree, NULL if none */
- void *new_fdt; /* Relocated FDT */
- unsigned long fdt_size; /* Space reserved for relocated FDT */
+ const void *fdt_blob; /* Our device tree, NULL if none */
+ void *new_fdt; /* Relocated FDT */
+ unsigned long fdt_size; /* Space reserved for relocated FDT */
struct jt_funcs *jt;/* jump table */
- char env_buf[32]; /* buffer for getenv() before reloc. */
+ char env_buf[32]; /* buffer for getenv() before reloc. */
#ifdef CONFIG_TRACE
void*trace_buff;/* The trace buffer */
#endif
@@ -125,8 +124,8 @@ typedef struct global_data {
#define GD_FLG_SERIAL_READY0x00100 /* Pre-reloc serial console ready */
#define GD_FLG_FULL_MALLOC_INIT0x00200 /* Full malloc() is ready
*/
#define GD_FLG_SPL_INIT0x00400 /* spl_init() has been called
*/
-#define GD_FLG_SKIP_RELOC 0x00800 /* Don't relocate */
-#define GD_FLG_RECORD 0x01000 /* Record console */
-#define GD_FLG_ENV_DEFAULT 0x02000 /* Default variable flag */
+#define GD_FLG_SKIP_RELOC 0x00800 /* Don't relocate */
+#define GD_FLG_RECORD 0x01000 /* Record console */
+#define GD_FLG_ENV_DEFAULT 0x02000 /* Default variable flag */
#endif /* __ASM_GENERIC_GBL_DATA_H */
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AT91: Correct misspelling of "redundent" in partition names
Signed-off-by: Robert P. J. Day --- given that this misspelling is being used for partition names, i won't treat it as a normal typo, so sending a separate patch just for this. diff --git a/include/configs/at91-sama5_common.h b/include/configs/at91-sama5_common.h index 051186d..3e55d13 100644 --- a/include/configs/at91-sama5_common.h +++ b/include/configs/at91-sama5_common.h @@ -75,7 +75,7 @@ #define CONFIG_BOOTARGS \ "console=ttyS0,115200 earlyprintk " \ "mtdparts=atmel_nand:256k(bootstrap)ro,512k(uboot)ro," \ - "256K(env),256k(env_redundent),256k(spare),"\ + "256K(env),256k(env_redundant),256k(spare),"\ "512k(dtb),6M(kernel)ro,-(rootfs) " \ "rootfstype=ubifs ubi.mtd=7 root=ubi0:rootfs" diff --git a/include/configs/at91sam9rlek.h b/include/configs/at91sam9rlek.h index a383de6..0d24814 100644 --- a/include/configs/at91sam9rlek.h +++ b/include/configs/at91sam9rlek.h @@ -152,7 +152,7 @@ #define CONFIG_BOOTARGS\ "console=ttyS0,115200 earlyprintk " \ "mtdparts=atmel_nand:256k(bootstrap)ro,512k(uboot)ro," \ - "256K(env),256k(env_redundent),256k(spare)," \ + "256K(env),256k(env_redundant),256k(spare)," \ "512k(dtb),6M(kernel)ro,-(rootfs) " \ "rootfstype=ubifs ubi.mtd=7 root=ubi0:rootfs" -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] when does default env get written to flash on a new system?
On Thu, 1 Sep 2016, Robert P. J. Day wrote:
> i'm sure i'll figure this out if i keep reading the code, but if i
> have a new board where the env will be stored in flash, and i flash
> a fresh build of u-boot with a default environment, at what point
> will that default environment be written to persistent storage (as
> defined by CONFIG_ENV_ADDR)?
>
> is this done automatically at some point when u-boot runs for the
> first time? or does it require me to, at some point, do an "env
> save"? thanks.
just to follow up on my own question, i can see the first part of
what i'm after, in that common/board_f.c will, early on, invoke:
env_init, /* initialize environment */
where that routine is:
int env_init(void)
{
if (crc32(0, env_ptr->data, ENV_SIZE) == env_ptr->crc) {
gd->env_addr= (ulong)&(env_ptr->data);
gd->env_valid = 1;
return 0;
}
gd->env_addr= (ulong)&default_environment[0];
gd->env_valid = 0;
return 0;
}
so assuming there is no valid env in flash, i'll now have the global
data structure referring to the default environment, and indicating
there is no valid environment in persistent storage. so far, so good,
now i'm just tracing along, looking for the next step ...
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] when does default env get written to flash on a new system?
i'm sure i'll figure this out if i keep reading the code, but if i have a new board where the env will be stored in flash, and i flash a fresh build of u-boot with a default environment, at what point will that default environment be written to persistent storage (as defined by CONFIG_ENV_ADDR)? is this done automatically at some point when u-boot runs for the first time? or does it require me to, at some point, do an "env save"? thanks. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] global_data.h: Format with proper tabs so comments line up.
Add tabs or replace spaces so that all comments line up for easier
reading.
Signed-off-by: Robert P. J. Day
---
just to make for easier reading, compile-tested for MPC8315ERDB.
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index a6d1d2a..12f2f2e 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -28,18 +28,18 @@ typedef struct global_data {
bd_t *bd;
unsigned long flags;
unsigned int baudrate;
- unsigned long cpu_clk; /* CPU clock in Hz! */
+ unsigned long cpu_clk; /* CPU clock in Hz! */
unsigned long bus_clk;
/* We cannot bracket this with CONFIG_PCI due to mpc5xxx */
unsigned long pci_clk;
unsigned long mem_clk;
#if defined(CONFIG_LCD) || defined(CONFIG_VIDEO)
- unsigned long fb_base; /* Base address of framebuffer mem */
+ unsigned long fb_base; /* Base address of framebuffer mem */
#endif
#if defined(CONFIG_POST) || defined(CONFIG_LOGBUFFER)
- unsigned long post_log_word; /* Record POST activities */
- unsigned long post_log_res; /* success of POST test */
- unsigned long post_init_f_time; /* When post_init_f started */
+ unsigned long post_log_word;/* Record POST activities */
+ unsigned long post_log_res; /* success of POST test */
+ unsigned long post_init_f_time; /* When post_init_f started */
#endif
#ifdef CONFIG_BOARD_TYPES
unsigned long board_type;
@@ -48,14 +48,13 @@ typedef struct global_data {
#ifdef CONFIG_PRE_CONSOLE_BUFFER
unsigned long precon_buf_idx; /* Pre-Console buffer index */
#endif
- unsigned long env_addr; /* Address of Environment struct */
+ unsigned long env_addr; /* Address of Environment struct */
unsigned long env_valid;/* Checksum of Environment valid? */
- unsigned long ram_top; /* Top address of RAM used by U-Boot */
-
+ unsigned long ram_top; /* Top address of RAM used by U-Boot */
unsigned long relocaddr;/* Start address of U-Boot in RAM */
- phys_size_t ram_size; /* RAM size */
- unsigned long mon_len; /* monitor len */
+ phys_size_t ram_size; /* RAM size */
+ unsigned long mon_len; /* monitor len */
unsigned long irq_sp; /* irq stack pointer */
unsigned long start_addr_sp;/* start_addr_stackpointer */
unsigned long reloc_off;
@@ -67,14 +66,14 @@ typedef struct global_data {
struct list_head uclass_root; /* Head of core tree */
#endif
#ifdef CONFIG_TIMER
- struct udevice *timer; /* Timer instance for Driver Model */
+ struct udevice *timer; /* Timer instance for Driver Model */
#endif
- const void *fdt_blob; /* Our device tree, NULL if none */
- void *new_fdt; /* Relocated FDT */
- unsigned long fdt_size; /* Space reserved for relocated FDT */
+ const void *fdt_blob; /* Our device tree, NULL if none */
+ void *new_fdt; /* Relocated FDT */
+ unsigned long fdt_size; /* Space reserved for relocated FDT */
struct jt_funcs *jt;/* jump table */
- char env_buf[32]; /* buffer for getenv() before reloc. */
+ char env_buf[32]; /* buffer for getenv() before reloc. */
#ifdef CONFIG_TRACE
void*trace_buff;/* The trace buffer */
#endif
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] what means "extra-" versus "obj-" in Makefiles
really a Kbuild question, i realize, but i'm looking at common/Makefile, and i'm having trouble understanding the flipping back and forth, as in: obj-$(CONFIG_ENV_IS_IN_DATAFLASH) += env_dataflash.o obj-$(CONFIG_ENV_IS_IN_EEPROM) += env_eeprom.o extra-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o obj-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o extra-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o obj-$(CONFIG_ENV_IS_IN_NVRAM) += env_embedded.o what is the rationale for the jumping between "obj-" and "extra-"? thanks. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common/Kconfig: Fix various innocuous typos.
Correct a small number of spelling mistakes. Signed-off-by: Robert P. J. Day --- noticed one typo in this file so figured i might as well just do the whole thing. diff --git a/common/Kconfig b/common/Kconfig index 46e7173..4494112 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -9,13 +9,13 @@ config BOOTSTAGE give the entry a name with bootstage_mark_name(). You can also record elapsed time in a particular stage using bootstage_start() before starting and bootstage_accum() when finished. Bootstage will - add up all the accumated time and report it. + add up all the accumulated time and report it. Normally, IDs are defined in bootstage.h but a small number of - additional 'user' IDs can be used but passing BOOTSTAGE_ID_ALLOC + additional 'user' IDs can be used by passing BOOTSTAGE_ID_ALLOC as the ID. - Calls to show_boot_progress() wil also result in log entries but + Calls to show_boot_progress() will also result in log entries but these will not have names. config BOOTSTAGE_REPORT @@ -53,7 +53,7 @@ config BOOTSTAGE_FDT Stash the bootstage information in the FDT. A root 'bootstage' node is created with each bootstage id as a child. Each child has a 'name' property and either 'mark' containing the - mark time in microsecond, or 'accum' containing the + mark time in microseconds, or 'accum' containing the accumulated time for that bootstage id in microseconds. For example: @@ -114,7 +114,7 @@ config NAND_BOOT help Enabling this will make a U-Boot binary that is capable of being booted via NAND flash. This is not a must, some SoCs need this, - somes not. + some not. config ONENAND_BOOT bool "Support for booting from ONENAND" @@ -122,7 +122,7 @@ config ONENAND_BOOT help Enabling this will make a U-Boot binary that is capable of being booted via ONENAND. This is not a must, some SoCs need this, - somes not. + some not. config QSPI_BOOT bool "Support for booting from QSPI flash" @@ -130,7 +130,7 @@ config QSPI_BOOT help Enabling this will make a U-Boot binary that is capable of being booted via QSPI flash. This is not a must, some SoCs need this, - somes not. + some not. config SATA_BOOT bool "Support for booting from SATA" @@ -138,7 +138,7 @@ config SATA_BOOT help Enabling this will make a U-Boot binary that is capable of being booted via SATA. This is not a must, some SoCs need this, - somes not. + some not. config SD_BOOT bool "Support for booting from SD/EMMC" @@ -146,7 +146,7 @@ config SD_BOOT help Enabling this will make a U-Boot binary that is capable of being booted via SD/EMMC. This is not a must, some SoCs need this, - somes not. + some not. config SPI_BOOT bool "Support for booting from SPI flash" @@ -154,7 +154,7 @@ config SPI_BOOT help Enabling this will make a U-Boot binary that is capable of being booted via SPI flash. This is not a must, some SoCs need this, - somes not. + some not. endmenu @@ -174,7 +174,7 @@ config CONSOLE_RECORD bool "Console recording" help This provides a way to record console output (and provide console - input) through cirular buffers. This is mostly useful for testing. + input) through circular buffers. This is mostly useful for testing. Console output is recorded even when the console is silent. To enable console recording, call console_record_reset_enable() from your code. -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] what's the proper use (if any) of [CONFIG_]ENV_IS_EMBEDDED?
still crawling through environment manipulation code, and noticed: ... # ifdef CONFIG_ENV_IS_EMBEDDED # error "do not define CONFIG_ENV_IS_EMBEDDED in your board config" # error "it is calculated automatically for you" # endif ... but it seems there are a number of boards that are doing just that (as well as defining ENV_IS_EMBEDDED as well: $ grep -r "define.*ENV_IS_EMBEDDED$" include/configs include/configs/ibf-dsp561.h:#define ENV_IS_EMBEDDED include/configs/bf533-stamp.h:#define ENV_IS_EMBEDDED include/configs/cm-bf537u.h:#define ENV_IS_EMBEDDED include/configs/bct-brettl2.h:#define ENV_IS_EMBEDDED include/configs/sh7753evb.h:#define CONFIG_ENV_IS_EMBEDDED include/configs/bf537-pnav.h:#define ENV_IS_EMBEDDED include/configs/sh7757lcr.h:#define CONFIG_ENV_IS_EMBEDDED include/configs/bf537-stamp.h:#define ENV_IS_EMBEDDED include/configs/sh7752evb.h:#define CONFIG_ENV_IS_EMBEDDED include/configs/cm-bf537e.h:#define ENV_IS_EMBEDDED include/configs/tcm-bf537.h:#define ENV_IS_EMBEDDED include/configs/bf538f-ezkit.h:#define ENV_IS_EMBEDDED include/configs/dnp5370.h:#define ENV_IS_EMBEDDED $ and testing ENV_IS_EMBEDDED: $ grep -r "ifdef.*ENV_IS_EMBEDDED$" * common/env_onenand.c:#ifdef ENV_IS_EMBEDDED common/env_mmc.c:#ifdef ENV_IS_EMBEDDED common/env_flash.c:#ifdef ENV_IS_EMBEDDED common/env_remote.c:#ifdef ENV_IS_EMBEDDED include/environment.h:# ifdef CONFIG_ENV_IS_EMBEDDED include/environment.h:#ifdef CONFIG_ENV_IS_EMBEDDED include/environment.h:# ifdef ENV_IS_EMBEDDED include/environment.h:#ifdef ENV_IS_EMBEDDED include/configs/ibf-dsp561.h:#ifdef ENV_IS_EMBEDDED include/configs/bf533-stamp.h:#ifdef ENV_IS_EMBEDDED include/configs/cm-bf537u.h:#ifdef ENV_IS_EMBEDDED include/configs/bct-brettl2.h:#ifdef ENV_IS_EMBEDDED include/configs/bf537-pnav.h:#ifdef ENV_IS_EMBEDDED include/configs/bf537-stamp.h:#ifdef ENV_IS_EMBEDDED include/configs/cm-bf537e.h:#ifdef ENV_IS_EMBEDDED include/configs/tcm-bf537.h:#ifdef ENV_IS_EMBEDDED include/configs/bf538f-ezkit.h:#ifdef ENV_IS_EMBEDDED $ what is the proper usage of this construct? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] is there really a "CONFIG_RAMBOOT" config option?
just tripped across this in master branch: $ grep -rw CONFIG_RAMBOOT * doc/README.ramboot-ppc85xx: #ifdef CONFIG_RAMBOOT include/configs/at91rm9200ek.h:#ifdef CONFIG_RAMBOOT README: CONFIG_RAMBOOT and CONFIG_NFSBOOT $ i have looked no further than this, so it might be perfectly valid, but it seems odd that there are so few references to that config option -- is it possible those should be CONFIG_SYS_RAMBOOT? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] what means the "CONFIG_SYS_USE_PPCENV" config setting?
currently pawing my way through the mechanics of u-boot environment,
and noticed that a small number of boards support:
$ grep -r PPCENV *
common/env_embedded.c:#if defined(CONFIG_SYS_USE_PPCENV) && \
common/env_embedded.c:# define __PPCENV__ __attribute__
((section(".ppcenv")))
common/env_embedded.c:# define __PPCENV__ /*XXX DO_NOT_DEL_THIS_COMMENT*/
common/env_embedded.c:# define __PPCENV__ __attribute__
((section(".text")))
common/env_embedded.c:env_t redundand_environment __PPCENV__ = {
include/configs/TQM823M.h:#define CONFIG_SYS_USE_PPCENV
/* Environment embedded in sect .ppcenv */
include/configs/TQM855L.h:#define CONFIG_SYS_USE_PPCENV
/* Environment embedded in sect .ppcenv */
include/configs/TQM866M.h:#define CONFIG_SYS_USE_PPCENV
/* Environment embedded in sect .ppcenv */
include/configs/TQM850L.h:#define CONFIG_SYS_USE_PPCENV
/* Environment embedded in sect .ppcenv */
include/configs/TQM860M.h:#define CONFIG_SYS_USE_PPCENV
/* Environment embedded in sect .ppcenv */
include/configs/TQM850M.h:#define CONFIG_SYS_USE_PPCENV
/* Environment embedded in sect .ppcenv */
include/configs/TQM862M.h:#define CONFIG_SYS_USE_PPCENV
/* Environment embedded in sect .ppcenv */
include/configs/TQM862L.h:#define CONFIG_SYS_USE_PPCENV
/* Environment embedded in sect .ppcenv */
include/configs/inka4x0.h:#define CONFIG_SYS_USE_PPCENV /*
Environment embedded in sect .ppcenv */
include/configs/TQM855M.h:#define CONFIG_SYS_USE_PPCENV
/* Environment embedded in sect .ppcenv */
include/configs/TQM860L.h:#define CONFIG_SYS_USE_PPCENV
/* Environment embedded in sect .ppcenv */
include/configs/TQM823L.h:#define CONFIG_SYS_USE_PPCENV
/* Environment embedded in sect .ppcenv */
include/env_default.h:env_t environment __PPCENV__ = {
$
what is the rationale for that small selection of boards to put
their environment in a separate section? if i keep reading, i'm sure
it will become obvious.
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] a fair bit of code that could use ARRAY_SIZE() macro
a few years back, i wrote a number of scripts that ran through the kernel source tree and located places that were good candidates for "cleaning" or simplification. one of those cleanups was to replace occurrences of the general form: (sizeof(x) / sizeof((x)[0])) with: ARRAY_SIZE(x) where that macro was defined in include/linux/kernel.h. i just did a quick grep to find similar stuff in the u-boot tree ... first, here are the same defines in u-boot: $ grep -r "define ARRAY_SIZE" * common/env_flags.c:#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) include/linux/kernel.h:#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) tools/mxsimage.h:#define ARRAY_SIZE(x)(sizeof(x) / sizeof((x)[0])) tools/imagetool.h:#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0])) $ doing a fairly unintelligent search for that pattern gives me: $ grep -r "sizeof.*/.*sizeof" * | wc -l 109 $ and, sure, there are going to be some false positives in there, but quite a lot of the real thing, eg. drivers/spi/cf_spi.c: pbrcnt = sizeof(prescaler) / sizeof(int); drivers/spi/cf_spi.c: brcnt = sizeof(scaler) / sizeof(int); so a couple questions. first, is this worth doing? it, of course, should make no functional difference, simply aesthetics, so this may be one of those things where people conclude, "nah, it's just code churn." OTOH, that test is fairly widespread in the u-boot code base: $ grep -rw ARRAY_SIZE * | wc -l 1396 $ and, second, that macro in the kernel is defined as: #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr)) is that additional "+ __must_be_array(arr))" significant? if the kernel is doing that, would it be wise for u-boot to do the same? thoughts? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] how to combine new default env in new u-boot with current saved?
i'm wondering if "env import" and "env export" are the solutions to this question -- i want to be able to install a new u-boot binary, then combine the factory defaults in that new binary with what is currently saved, such that the current, saved values take precedence if the same variable appears in both places. i'd like to think that can't be hard, but i've been surprised before. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] usb: add CONIFG_USB_OHCI_HCD in Kconfig
"CONIFG"? rday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] should denx wiki page on bootcount mention "failbootcmd"?
it would seem that this wiki page:
http://www.denx.de/wiki/view/DULG/UBootBootCountLimit
could use a fair bit of updating, since it concludes with:
"At the moment, the Boot Count Limit feature is available only for
MPC8xx, MPC82xx and MPC5200 Power Architecture® processors."
which i suspect was written when it referred only to *hardware*
support, since saving bootcount in the environment would seem to be
available to pretty much everyone at this point.
in addition, i notice that if you've configured POST support,
there's also this from common/autobooot.c, the function
bootdelay_process():
...
#ifdef CONFIG_POST
if (gd->flags & GD_FLG_POSTFAIL) {
s = getenv("failbootcmd");
} else
#endif /* CONFIG_POST */
#ifdef CONFIG_BOOTCOUNT_LIMIT
if (bootlimit && (bootcount > bootlimit)) {
printf("Warning: Bootlimit (%u) exceeded. Using altbootcmd.\n",
(unsigned)bootlimit);
s = getenv("altbootcmd");
} else
#endif /* CONFIG_BOOTCOUNT_LIMIT */
s = getenv("bootcmd");
...
which suggests that if you've configured POST support, then that will
override the standard bootcount limit use of "altbootcmd" with the use
of "failbootcmd", correct?
is that worth mentioning? or is anyone actually taking advantage of
that?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] a few questions about saving bootcount in the environment
On Tue, 26 Jul 2016, Heiko Schocher wrote:
... snip ...
> > it appears that, no matter what, the environment *is* updated
> > every single time because of this line in the bootdelay_process()
> > routine:
> >
> >setenv_ulong("bootcount", bootcount);
> >
> > why? it seems, from the above, that no matter what boot counter
>
> Yes, the bootcount variable gets set here ... but the environment
> gets not written...
>
> > mechanism you use, the environment will be updated because of that
> > line.
>
> The Environment gets written when saveenv() gets called ... or?
... snip ...
yes, i already apologized to wolfgang for being so clueless, i
didn't see the difference between "setenv" and "saveenv". anyway, i'm
still writing a wiki page on this that i can use for future embedded
linux classes, so ... onward.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] a few questions about saving bootcount in the environment
On Tue, 26 Jul 2016, Wolfgang Denk wrote:
> Dear Robert,
>
> In message you
> wrote:
> >
> > ok, i am now *totally* confused, so let's start at the beginning.
> > it's my understanding that selecting CONFIG_BOOTCOUNT_LIMIT means you
>
> right.
>
> > want to use the boot counter, it does *not* select what method you
> > want to use to store the boot counter, correct? but here's the
> > confusing part.
>
> Which exact part is confusing?
>
> > #ifdef CONFIG_BOOTCOUNT_LIMIT
> > bootcount = bootcount_load();
> > bootcount++;
> > bootcount_store(bootcount);
> > setenv_ulong("bootcount", bootcount); <- ?
> > bootlimit = getenv_ulong("bootlimit", 10, 0);
> > #endif /* CONFIG_BOOTCOUNT_LIMIT */
>
> This is only the equivalent of a "setenv", so you have a variable in
> the environment which you can use in scripts or compare against
> "bootlimit".
>
> There is NO automatic "saveenv" here...
ah, you're right, you're right, sorry. little by little ...
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] a few questions about saving bootcount in the environment
On Mon, 25 Jul 2016, Heiko Schocher wrote:
... snip ...
> Yep ... why do we need "upgrade_available"?
>
> in ./common/autoboot.c on *every* boot bootcount_store() gets
> called, so on every boot (which can happen very often) the Environment
> would be written ... not good, for long life of your product (if
> you have the Env in raw nand flash for example, as for the siemens
> boards)
>
> If the bootcounter feature is only needed if you really did an
> update, to most writtes are unnecessary ... so the Userspace App can
> set also "upgrade_available" to enable the bootcount feature in case
> we save the bootcounter in the Environment ... and save a lot of
> writtes to the Env
>
> But if you say "I don;t care how often I write the Environment" you
> simply can set "upgrade_available" to 1 and have the "original"
> behaviour of the bootcount feature (incrementing bootcount on each
> reboot ...)
ok, i am now *totally* confused, so let's start at the beginning.
it's my understanding that selecting CONFIG_BOOTCOUNT_LIMIT means you
want to use the boot counter, it does *not* select what method you
want to use to store the boot counter, correct? but here's the
confusing part.
if i look in common/autoboot.c, i see:
const char *bootdelay_process(void)
{
char *s;
int bootdelay;
#ifdef CONFIG_BOOTCOUNT_LIMIT
unsigned long bootcount = 0;
unsigned long bootlimit = 0;
#endif /* CONFIG_BOOTCOUNT_LIMIT */
#ifdef CONFIG_BOOTCOUNT_LIMIT
bootcount = bootcount_load();
bootcount++;
bootcount_store(bootcount);
setenv_ulong("bootcount", bootcount); <- ?
bootlimit = getenv_ulong("bootlimit", 10, 0);
#endif /* CONFIG_BOOTCOUNT_LIMIT */
... snip ...
and that's what confuses the heck out of me. i thought that, depending
on the technique i wanted to use to store the boot counter (RAM, I2C,
whatever), it would use *exclusively* that technique, and while i can
see the use of the routines bootcount_load() and bootcount_store(),
which are redefined based on the technique you select:
$ grep -rw bootcount_store *
bootcount_at91.c:void bootcount_store(ulong a)
bootcount_blackfin.c:void bootcount_store(ulong cnt)
bootcount.c:__weak void bootcount_store(ulong a)
bootcount_davinci.c:void bootcount_store(ulong a)
bootcount_env.c:void bootcount_store(ulong a)
bootcount_i2c.c:void bootcount_store(ulong a)
bootcount_i2c.c: bootcount_store(0);
bootcount_ram.c:void bootcount_store(ulong a)
$
it appears that, no matter what, the environment *is* updated every
single time because of this line in the bootdelay_process() routine:
setenv_ulong("bootcount", bootcount);
why? it seems, from the above, that no matter what boot counter
mechanism you use, the environment will be updated because of that
line.
i can certainly see in bootcount_env.c where using
"upgrade_available" can deselect writing to the environment based on
invoking bootcount_store(), but that in no way stops that explicit
call to setenv_ulong() in that routine above.
so how am i misunderstanding this? it seems that no matter what boot
counter storage mechanism i select, i'll be writing to the environment
every time *anyway*.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] confused by "upgrade_available=0\0" in include/configs/taurus.h
a short followup to my earlier post after i did a bit more reading ... i can see a bit more clearly the purpose of the Kbuild variable CONFIG_BOOTCOUNT_AM33XX being used in drivers/bootcount/Makefile: obj-$(CONFIG_BOOTCOUNT_AM33XX) += bootcount_davinci.o since, apparently, only some(?) AM33xx targets use the corresponding davinci RTC that can be used for this (if i'm reading that correctly): $ grep -r "#define.*CONFIG_BOOTCOUNT_AM33XX" * include/configs/am335x_sl50.h:#define CONFIG_BOOTCOUNT_AM33XX include/configs/bav335x.h:#define CONFIG_BOOTCOUNT_AM33XX include/configs/baltos.h:#define CONFIG_BOOTCOUNT_AM33XX include/configs/am335x_evm.h:#define CONFIG_BOOTCOUNT_AM33XX include/configs/brppt1.h:#define CONFIG_BOOTCOUNT_AM33XX $ so i can appreciate that you can't just check CONFIG_AM33XX as that wouldn't apply to all of the other AM33xx targets. however, rather than invent a whole new variable for this, i think it would be clearer if that Makefile tested specifically for the property in question -- the presence of the davinci RTC or something similar, perhaps checking CONFIG_RTC_DAVINCI in conjunction with CONFIG_AM33XX? in short, i think it's cleaner to avoid creating whole new Kbuild variables if one can use existing ones that make Makefiles easier to understand. but now i admit i'm just being picky. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] confused by "upgrade_available=0\0" in include/configs/taurus.h
On Mon, 25 Jul 2016, Wolfgang Denk wrote: > Dear Robert, > > In message you > wrote: > > > > i'm not sure it's as bad as it looks, since those macros are used > > specifically in drivers/bootcount/Makefile: > > You are right, and apparently it is working fine so far. But it is > confusing, and... > > > obj-$(CONFIG_SOC_DA8XX) += bootcount_davinci.o > > obj-$(CONFIG_BOOTCOUNT_AM33XX) += bootcount_davinci.o > > ..this would make more sense to me if it was called > > CONFIG_BOOTCOUNT_DAVINCI after pondering on this, i'm going to disagree, and here's why. first, i think the *only* way you should be able to select the bootcount feature is by defining CONFIG_BOOTCOUNT_LIMIT -- that should be the only thing you need to select, and it should apply equally well to *everyone*, regardless of whether they need weird or special processing. this matches what you see in drivers/Makefile: obj-$(CONFIG_BOOTCOUNT_LIMIT) += bootcount/ which establishes that that config setting is the *only* way you get to further process what's in the bootcount directory. now, once you're *in* that directory, then you can start checking if you need any special processing based on processor or target board or whatever so, at that point, i'm no longer as offended as i once was by Makefile lines like: obj-$(CONFIG_SOC_DA8XX) += bootcount_davinci.o that simply says, "if it's this target, then i need that target-specific bootcount code." and that actually seems quite reasonable, now that i think about it. what now looks silly is a line like: obj-$(CONFIG_BOOTCOUNT_AM33XX) += bootcount_davinci.o because that config variable is somewhat redundant. we already know that the only way you get to process bootcount code is by setting CONFIG_BOOTCOUNT_LIMIT, so it's kind of goofy to further define *another* BOOTCOUNT variable that's target specific, since you still need the first one, which leads to the following silliness in include/configs/am335x_evm.h: #define CONFIG_BOOTCOUNT_LIMIT #define CONFIG_BOOTCOUNT_AM33XX<--- oh, yuck the first define already selects bootcount functionality; that second define just looks silly and somewhat redundant. i think it's fine to define further BOOTCOUNT-related variables that select general *classes* of bootcount functionality, like: CONFIG_BOOTCOUNT_ENV CONFIG_BOOTCOUNT_RAM CONFIG_BOOTCOUNT_I2C but for really target-specific bootcount implementations, i have no problem with tests like: obj-$(CONFIG_AT91SAM9XE)+= bootcount_at91.o obj-$(CONFIG_BLACKFIN) += bootcount_blackfin.o obj-$(CONFIG_SOC_DA8XX) += bootcount_davinci.o the one that now offends me is this one: obj-$(CONFIG_BOOTCOUNT_AM33XX) += bootcount_davinci.o which i think should be rewritten as simply: obj-$(CONFIG_AM33XX)+= bootcount_davinci.o (or using whatever CONFIG setting selects AM33XX). in short (and, yes, i'm waiting for a massive build to complete so i have time to kill), i would avoid creating any new Kbuild variables of the form CONFIG_BOOTCOUNT_target_board. in fact, in a perfect world, i would have the directory drivers/bootcount/ contain *only* general bootcount functionality (generic, RAM, I2C, ...), and perhaps move the target-specific stuff to those target-specific source directories. but that's just me. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] a few questions about saving bootcount in the environment
On Mon, 25 Jul 2016, Wolfgang Denk wrote: > Dear Robert, > > In message you > wrote: > > > > i'm sure i'm asking the obvious, but if every boot to user space is > > successful, bootcount will have a value of zero each time, yes? so if > > user space code checks it and it's zero, then, you're done, no need to > > write. > > As Heiko already explained, the update of the boot counter (= read > from env, increment, rewrite environment to persistent storage) is > done in U-Boot, and without "upgrade_available" it would happen on > each and every boot of the system. > > The boot counter is implemented in U-Boot - only the resetting is done > in user space (and requires another write). whoops, i missed that bit, just trying to catch up now. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] a few questions about saving bootcount in the environment
On Mon, 25 Jul 2016, Wolfgang Denk wrote: > Dear Tom, > > In message <20160725135754.GN14698@bill-the-cat> you wrote: > > > > > Right, it is only a last resort when you cannot find any better place > > > to storeit (in a hardware register that survives resets). > > > > That's not strictly true. One of the things I noticed recently is that > > Mender uses bootcount, in environment, as a least common denominator. > > And thrown in a file in a filesystem, in so far as you trust the > > underlying black box to be good about reads/writes and wear levelling, > > it's robust enough (for certain values of robust and enough). We're > > dipping into one of those areas where experts have varying opinions on > > what's good enough, hence all the qualifiers. But it is a useful > > option. And neatly circumvents the need for a "driver" to clear the > > count too. > > Agreed. Let me rephrase the warning, then: it is always a good idea > to minimize the number of writes to the environment, especially when > done automagically. One should at least avoid to re-write it on every > boot, especially when storage is some (flash based) storage device > with a limited number of erase/write cycles. And even on other stoage > each write access includes the risk of errors. i'm sure i'm asking the obvious, but if every boot to user space is successful, bootcount will have a value of zero each time, yes? so if user space code checks it and it's zero, then, you're done, no need to write. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] cmd: bootz: make CMD_BOOTZ depend on CMD_BOOTM
On Mon, 25 Jul 2016, Masahiro Yamada wrote: > The "bootz" command is implemented in the "bootm", so the dependency > should be reflected in Kconfig. > > Signed-off-by: Masahiro Yamada > --- > > Kconfig | 1 + > cmd/Kconfig | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/Kconfig b/Kconfig > index ef12f9f..0d6afd2 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -57,6 +57,7 @@ config DISTRO_DEFAULTS > bool "Select defaults suitable for booting general purpose Linux > distributions" > default y if ARCH_SUNXI > default n > + select CMD_BOOTM > select CMD_BOOTZ > select CMD_DHCP > select CMD_EXT2 > diff --git a/cmd/Kconfig b/cmd/Kconfig > index d69b817..171114d 100644 > --- a/cmd/Kconfig > +++ b/cmd/Kconfig > @@ -162,6 +162,7 @@ config CMD_BOOTM > > config CMD_BOOTZ > bool "bootz" > + depends on CMD_BOOTM > help > Boot the Linux zImage if bootz already depends on bootm, why then do you need to select both? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] suggested/stealable setups for robustness with switchable partitions?
On Mon, 25 Jul 2016, Stefano Babic wrote:
> Hi Robert,
>
> On 25/07/2016 12:42, Robert P. J. Day wrote:
> > p.s. i also noticed a few boards in u-boot that explicitly work with
> > "partition sets":
>
> Do not let be confused by digging the environment into U-Boot. There are
> much more boards as you can discover. In fact, you can see the "default"
> environment, but on many boards the right environment is loaded in
> factory as part of device tests. The default environment, linked with
> u-boot, is not so important for many products.
>
> It is also possible that what you are seeing here is not used at all
> later, and replaced with some other scripts.
>
> Best regards,
> Stefano Babic
>
> >
> > $ grep -r partitionset *
> > board/siemens/taurus/taurus.c: char *partitionset_active = NULL;
> > board/siemens/taurus/taurus.c: partitionset_active =
> > getenv("partitionset_active");
> > board/siemens/taurus/taurus.c: if (partitionset_active) {
> > board/siemens/taurus/taurus.c: if (partitionset_active[0] ==
> > 'A')
> > board/siemens/taurus/taurus.c:
> > setenv("partitionset_active", "B");
> > board/siemens/taurus/taurus.c:
> > setenv("partitionset_active", "A");
> > board/siemens/taurus/taurus.c: printf("partitionset_active
> > missing.\n");
> > include/configs/etamin.h: "setenv ${partitionset_active} true;" \
> > include/configs/siemens-am33x-common.h: "setenv
> > ${partitionset_active} true;" \
> > include/configs/siemens-am33x-common.h:
> > "setenv partitionset_active B; " \
> > include/configs/siemens-am33x-common.h:
> > "setenv partitionset_active A; " \
> > include/configs/siemens-am33x-common.h: "echo set
> > ${partitionset_active}...;" \
> > include/configs/siemens-am33x-common.h: "partitionset_active=A\0" \
> > include/configs/siemens-am33x-common.h: "echo Set
> > partitionset_active variable to 'A' " \
> > include/configs/siemens-am33x-common.h: "setenv
> > ${partitionset_active} true;" \
> > include/configs/siemens-am33x-common.h: "setenv
> > ${partitionset_active} true;" \
> > include/configs/taurus.h: "partitionset_active=A\0"
> > $
oh, i understand that, i was just noting another component that can
come into play if someone *wants* to do it as is being done above,
unless it's overridden at the factory.
a couple more bootlimit/autoboot questions coming later as i try to
pull all this together and finish writing it up, so others don't have
to do as much reading as me. :-)
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] suggested/stealable setups for robustness with switchable partitions?
On Fri, 22 Jul 2016, Wolfgang Denk wrote:
> Dear Robert,
>
> In message you
> wrote:
> >
> > followup to my earlier post, i'll keep this short as i want to
> > do some research first, but i'm looking for setups where target
> > boards have dual partitions that switch between active and
> > inactive for reliability.
>
> Switching partitions is usually not some isolated feature, but part
> of a software update and reliable fall back configuration. In
> U-Boot, it is usually found in combination with the boot counter
> feature; in Linux, it usually requires support of a (hardware)
> watchdog.
>
> Once you reached that point, you probably want to look at the
> swupdate [1] project and read it's documentation...
>
> [1] http://git.denx.de/?p=swupdate.git;a=summary
ironically, i was already digging into swupdate when you mentioned
it, since i saw it was one of stefano's projects so i assumed it would
play nicely with u-boot.
rday
p.s. i also noticed a few boards in u-boot that explicitly work with
"partition sets":
$ grep -r partitionset *
board/siemens/taurus/taurus.c: char *partitionset_active = NULL;
board/siemens/taurus/taurus.c: partitionset_active =
getenv("partitionset_active");
board/siemens/taurus/taurus.c: if (partitionset_active) {
board/siemens/taurus/taurus.c: if (partitionset_active[0] == 'A')
board/siemens/taurus/taurus.c: setenv("partitionset_active",
"B");
board/siemens/taurus/taurus.c: setenv("partitionset_active",
"A");
board/siemens/taurus/taurus.c: printf("partitionset_active
missing.\n");
include/configs/etamin.h: "setenv ${partitionset_active} true;" \
include/configs/siemens-am33x-common.h: "setenv
${partitionset_active} true;" \
include/configs/siemens-am33x-common.h: "setenv
partitionset_active B; " \
include/configs/siemens-am33x-common.h: "setenv
partitionset_active A; " \
include/configs/siemens-am33x-common.h: "echo set
${partitionset_active}...;" \
include/configs/siemens-am33x-common.h: "partitionset_active=A\0" \
include/configs/siemens-am33x-common.h: "echo Set partitionset_active
variable to 'A' " \
include/configs/siemens-am33x-common.h: "setenv ${partitionset_active}
true;" \
include/configs/siemens-am33x-common.h: "setenv ${partitionset_active}
true;" \
include/configs/taurus.h: "partitionset_active=A\0"
$
so i'm trying to collect all of this and write it up in one (public)
place, so i can use it for an upcoming embedded linux class.
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] confused by "upgrade_available=0\0" in include/configs/taurus.h
On Mon, 25 Jul 2016, Wolfgang Denk wrote: > Dear Robert, > > In message you > wrote: > > >3094 CONFIG_AT91SAM9XE > >3095 enable special bootcounter support on at91sam9xe > > based boards. > >3096 CONFIG_BLACKFIN > >3097 enable special bootcounter support on blackfin > > based boards. > >3098 CONFIG_SOC_DA8XX > >3099 enable special bootcounter support on da850 based > > boards. > > This is name space pollution t best, and has potential to cause > unwanted side effects. This needs thorough checking and cleanup, if > it should turn out thatthese macros are used only to select specific > bootcount implementations - in that case, they should be renamed > into something like CONFIG_BOOTCOUNT_* or such. > > Heiko, maybe you could have a look at that, please? i'm not sure it's as bad as it looks, since those macros are used specifically in drivers/bootcount/Makefile: obj-y += bootcount.o obj-$(CONFIG_AT91SAM9XE)+= bootcount_at91.o obj-$(CONFIG_BLACKFIN) += bootcount_blackfin.o obj-$(CONFIG_SOC_DA8XX) += bootcount_davinci.o obj-$(CONFIG_BOOTCOUNT_AM33XX) += bootcount_davinci.o obj-$(CONFIG_BOOTCOUNT_RAM) += bootcount_ram.o obj-$(CONFIG_BOOTCOUNT_ENV) += bootcount_env.o obj-$(CONFIG_BOOTCOUNT_I2C) += bootcount_i2c.o and drivers/bootcount/ is processed only if: obj-$(CONFIG_BOOTCOUNT_LIMIT) += bootcount/ but i do see the single, more precise example of CONFIG_BOOTCOUNT_AM33XX, so someone else can decide if anything should be renamed here. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] what does "CONFIG_U_QE" represent powerpc quicc engine?
On Sun, 24 Jul 2016, Robert P. J. Day wrote: > working with MPC83xx at the moment, i'm used to seeing "CONFIG_QE" > all over the place, but what means "CONFIG_U_QE"? it seems like some > sort of freescale special feature, but i can't figure it out. just to follow up my earlier question, i can see this in drivers/Makefile: obj-$(CONFIG_QE) += qe/ obj-$(CONFIG_U_QE) += qe/ and, further, i can see this in drivers/qe/Makefile: obj-$(CONFIG_QE) += qe.o uccf.o uec.o uec_phy.o obj-$(CONFIG_U_QE) += qe.o obj-$(CONFIG_OF_LIBFDT) += fdt.o so, clearly, setting CONFIG_U_QE represents *not* compiling in a number of files, but i'm still unclear on the fundamental, underlying difference in architecture or design between QE and U_QE. oh, and i also notice that while fdt.c is selected, the entire contents of that source file are wrapped in: #include #include #include #include #ifdef CONFIG_QE ... massive snip ... #endif so, obviously(?), device trees are not relevant for whatever U_QE represents? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] what does "CONFIG_U_QE" represent powerpc quicc engine?
working with MPC83xx at the moment, i'm used to seeing "CONFIG_QE" all over the place, but what means "CONFIG_U_QE"? it seems like some sort of freescale special feature, but i can't figure it out. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] a few questions about saving bootcount in the environment
a few quick questions about this feature before i move on to the more widely-used stuff involving bootcount. first, it seems that there's not a lot of saving bootcount in the environment ... as i see it, there's the taurus board, and there's the boards that include "siemens-am33x-common.h", of which i see six: include/configs/rut.h:#include "siemens-am33x-common.h" include/configs/draco.h:#include "siemens-am33x-common.h" include/configs/etamin.h:#include "siemens-am33x-common.h" include/configs/rastaban.h:#include "siemens-am33x-common.h" include/configs/pxm2.h:#include "siemens-am33x-common.h" include/configs/thuban.h:#include "siemens-am33x-common.h" so this tells me that there's not a whole lot of that feature being used, so i won't spend much time on it. also, just to confirm, the "upgrade_available" variable is used *exclusively* for the case of bootcount in the environment and nowhere else, correct? so, again, if i'm not using the environment, i don't care about it. finally, i read this in the README: CONFIG_BOOTCOUNT_ENV If no softreset save registers are found on the hardware "bootcount" is stored in the environment. To prevent a saveenv on all reboots, the environment variable "upgrade_available" is used. If "upgrade_available" is 0, "bootcount" is always 0, if "upgrade_available" is 1 "bootcount" is incremented in the environment. So the Userspace Applikation must set the "upgrade_available" and "bootcount" variable to 0, if a boot was successfully. now, i can see where one wants to reset "bootcount" to zero once you boot successfully, but why would you also set "upgrade_available" to zero? don't you want to keep using that feature when you boot in the future? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] confused by "upgrade_available=0\0" in include/configs/taurus.h
On Sat, 23 Jul 2016, Wolfgang Denk wrote: > You may also want to read the README: > > 911 - Bootcount: > ... > 917 CONFIG_BOOTCOUNT_ENV > 918 If no softreset save registers are found on the hardware > 919 "bootcount" is stored in the environment. To prevent a > 920 saveenv on all reboots, the environment variable > 921 "upgrade_available" is used. If "upgrade_available" is > 922 0, "bootcount" is always 0, if "upgrade_available" is > 923 1 "bootcount" is incremented in the environment. > 924 So the Userspace Applikation must set the > "upgrade_available" > 925 and "bootcount" variable to 0, if a boot was > successfully. i note there seems to be some redundancy in the README. early on: 911 - Bootcount: 912 CONFIG_BOOTCOUNT_LIMIT 913 Implements a mechanism for detecting a repeating reboot 914 cycle, see: 915 http://www.denx.de/wiki/view/DULG/UBootBootCountLimit 916 917 CONFIG_BOOTCOUNT_ENV 918 If no softreset save registers are found on the hardware 919 "bootcount" is stored in the environment. To prevent a 920 saveenv on all reboots, the environment variable 921 "upgrade_available" is used. If "upgrade_available" is 922 0, "bootcount" is always 0, if "upgrade_available" is 923 1 "bootcount" is incremented in the environment. 924 So the Userspace Applikation must set the "upgrade_available" 925 and "bootcount" variable to 0, if a boot was successfully. and much further down: 3088 - bootcount support: 3089 CONFIG_BOOTCOUNT_LIMIT 3090 3091 This enables the bootcounter support, see: 3092 http://www.denx.de/wiki/DULG/UBootBootCountLimit 3093 3094 CONFIG_AT91SAM9XE 3095 enable special bootcounter support on at91sam9xe based boards. 3096 CONFIG_BLACKFIN 3097 enable special bootcounter support on blackfin based boards. 3098 CONFIG_SOC_DA8XX 3099 enable special bootcounter support on da850 based boards. 3100 CONFIG_BOOTCOUNT_RAM 3101 enable support for the bootcounter in RAM 3102 CONFIG_BOOTCOUNT_I2C 3103 enable support for the bootcounter on an i2c (like RTC) device. 3104 CONFIG_SYS_I2C_RTC_ADDR = i2c chip address 3105 CONFIG_SYS_BOOTCOUNT_ADDR = i2c addr which is used for 3106 the bootcounter. 3107 CONFIG_BOOTCOUNT_ALEN = address len can these two sections not be combined? i can add that to my cleanup list as well. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] selecting CONFIG_BOOTCOUNT_RAM requires defining BOOTCOUNT_ADDR, yes?
clawing my way through bootcount code, and there are a few
variations for the macro name BOOTCOUNT_ADDR, that's for sure (but
that's for another post).
anyway, just noticed this relatively sparse use of the macro
BOOTCOUNT_ADDR:
$ grep -rw BOOTCOUNT_ADDR *
board/keymile/km_arm/km_arm.c: bootcountaddr = gd->ram_size - BOOTCOUNT_ADDR;
board/keymile/km_arm/km_arm.c: void* addr = (void *) (gd->ram_size -
BOOTCOUNT_ADDR + POST_WORD_OFF);
board/keymile/km_arm/km_arm.c: void* addr = (void *) (gd->ram_size -
BOOTCOUNT_ADDR + POST_WORD_OFF);
drivers/bootcount/bootcount_ram.c: save_addr = (ulong *)(size -
BOOTCOUNT_ADDR);
drivers/bootcount/bootcount_ram.c: save_addr = (ulong *)(size -
BOOTCOUNT_ADDR);
include/configs/km/km_arm.h:#define BOOTCOUNT_ADDR
(CONFIG_KM_RESERVED_PRAM)
include/configs/theadorable.h:/* Max size of RAM minus BOOTCOUNT_ADDR is the
bootcounter address */
include/configs/theadorable.h:#define BOOTCOUNT_ADDR0x1000
$
and since bootcount_ram.c simply assumes that macro has a value:
void bootcount_store(ulong a)
{
ulong *save_addr;
ulong size = 0;
int i;
for (i = 0; i < CONFIG_NR_DRAM_BANKS; i++)
size += gd->bd->bi_dram[i].size;
save_addr = (ulong *)(size - BOOTCOUNT_ADDR);
... snip ...
i conclude that if you're using CONFIG_BOOTCOUNT_RAM, you *better*
assign a value to BOOTCOUNT_ADDR in your board definition. i see in
the above that that feature isn't used all that often; still, the fact
that you need to set that macro doesn't seem to be mentioned anywhere,
so i'm adding that to my list of doc fixes for later (unless someone
has newer info about that setting they care to share).
onward ...
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] confused by "upgrade_available=0\0" in include/configs/taurus.h
On Sat, 23 Jul 2016, Wolfgang Denk wrote: > Dear "Robert P. J. Day", > > In message you > wrote: > > > > never embarrassed to make a fool of myself, i have to admit that, > > while crawling through examples of u-boot boards that define dual > > partitions, i am confused by the following in > > include/configs/taurus.h (only some lines reproduced): ... snip .. > So the code would run the "upgrade_available" _command_ as part of > the command sequences stored in the flash_nfs, flash_self resp. > flash_self_test environment variables. > > Note that it has to be a (builtin) command, as a variable reference > would require a "$upgrade_available". > > The "upgrade_available" is a board-specific command, implemented in > board/siemens/taurus/taurus.c, function do_upgrade_available(). ... more snip ... yes, my confusion was based on that i had no idea there was an "upgrade_available" builtin command defined in taurus.c (i was looking only at the header file at the time), in addition to the same-named variable. as soon as you pointed that out, it all fell into place. so i'm good, and it all makes sense. thanks muchly. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] confused by "upgrade_available=0\0" in include/configs/taurus.h
On Sat, 23 Jul 2016, Wolfgang Denk wrote: > Dear "Robert P. J. Day", > > In message you > wrote: > > > > never embarrassed to make a fool of myself, i have to admit that, > > while crawling through examples of u-boot boards that define dual > > partitions, i am confused by the following in > > include/configs/taurus.h (only some lines reproduced): > > This is your fault. You omit the important parts, i. e. the lines > which end with a "\0" marker which will actually terminate the > definition of one variable and start the next one. ... snip ... ack, you're right, totally my fault. i was tired. rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] confused by "upgrade_available=0\0" in include/configs/taurus.h
never embarrassed to make a fool of myself, i have to admit that,
while crawling through examples of u-boot boards that define dual
partitions, i am confused by the following in
include/configs/taurus.h (only some lines reproduced):
#define CONFIG_BOOTARGS_AXM \
"\0"\
"flash_nfs=run nand_kernel;run nfsargs;run addip;upgrade_available;"\
"flash_self=run nand_kernel;run setbootargs;upgrade_available;" \
"flash_self_test=run nand_kernel;run setbootargs addtest; " \
"upgrade_available;bootm ${kernel_ram};reset\0"
"net_nfs=run boot_file;tftp ${kernel_ram} ${bootfile};" \
"run nfsargs;run addip;upgrade_available;bootm "\
"${kernel_ram};reset\0" \
... snip ...
"upgrade_available=0\0"
#endif
what does it mean for "upgrade_available;" to be in the middle of some
of those command definitions? it's just a variable, what does it
represent? am i just clueless for never having noticed this sort of
thing before?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] suggested/stealable setups for robustness with switchable partitions?
followup to my earlier post, i'll keep this short as i want to do some research first, but i'm looking for setups where target boards have dual partitions that switch between active and inactive for reliability. first, i can see that there are some examples in u-boot already. there's the taurus board: http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/taurus.h;h=882a4e5db4aa59ca87a61548f1e0df224da1;hb=HEAD http://git.denx.de/?p=u-boot.git;a=blob;f=board/siemens/taurus/taurus.c;h=8da24be56838a23e064055fe3bfbea3eb78fb321;hb=HEAD etamin: http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/etamin.h;h=4919cfe3536462fa3a8d62a90f660d6ff5e0bf14;hb=HEAD siemens-am33x-common.h: http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/siemens-am33x-common.h;h=eab665c2866b66702593bd0feed04f85cdbe872a;hb=HEAD am335x_shc.h: http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_shc.h;h=f2484cb17020e541c47beb39fcce60943260d045;hb=HEAD so i'll do some reading before i ask more specific questions. but if you have pointers to other examples, i'm probably going to write a wiki page summarizing this so others can check it out. rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] "uEnv.txt" versus "fw_setenv" -- a question about style
curious about peoples' preferences when it comes to customizing u-boot on a running system -- using a "uEnv.txt" file that can be trivially edited from user space, as opposed to using the u-boot firmware tools to change the actual environment variables in persistent storage. this is based on something else i will ask about later -- suggestions for target disk layouts that incorporate dual (active and inactive) partitions for robustness and fallback in case of emergency. but for now, let's keep it simple. obviously, i can certainly combine the two approaches above, but because of the upcoming issue regarding robustness, i'm leaning towards the uEnv.txt approach, and here's why. if i support updating the env vars in persistent storage, and a system in the field suddenly stops booting properly, then i might be completely in the dark as to what's in the u-boot environment. how do i know what the user has been doing, or what variables he might have changed? however, if i keep all the changes in uEnv.txt, it's easy to get a look at that file and, also, simply removing that file effectively sets the machine back to "factory defaults." in addition, if i have filesystem corruption that wipes out uEnv.txt (among other things), then, again, i have effectively reduced the system back to factory defaults so it can boot to a known good state of some kind. i guess i'm more comfortable with the idea of a system having a solid and tested u-boot environment that rarely (if ever) changes, rather than regularly changing things in the persistent storage, but i'm open to being persuaded otherwise; i'm just curious about what others prefer. rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] what is the *recommended* split between defconfig file and header file?
On Tue, 19 Jul 2016, Tom Rini wrote: > On Tue, Jul 19, 2016 at 04:15:47AM -0400, Robert P. J. Day wrote: > > > > kind of a style question but what is the preferred way to define a > > board in the sense of what belongs in the defconfig file and what > > belongs in the header file? > > The header files will eventually go away. Most of the contents are > things that could be, but haven't yet been, converted. A few things > like default environment are going to be harder to figure out. perhaps i haven't thought this through sufficiently, but it seems like moving all target configuration to the *_defconfig files and Kbuild system is going to require a fair bit of variable renaming. as i recall from the linux kernel coding style, any variables that begin with "CONFIG_" are meant to be defined in a Kconfig file somewhere, so if variables are moved from header files to a Kconfig file to be part of Kbuild, would that not require renaming them if they don't begin with "CONFIG_"? unless there's no plan to try to keep that standard. rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted
On Wed, 20 Jul 2016, Mario Six wrote: > On Wed, Jul 20, 2016 at 3:56 PM, Robert P. J. Day > wrote: ... snip ... > > not really, since i always thought that the difficulty in loading > > and booting a second-stage u-boot was explained here: > > > > http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM > > > > that is, loading the second image to a different address is simple; > > the apparent difficulty is that the second-stage u-boot might not be > > able to handle the early setup already done by the first stage. > > > > so i'm still confused as to what is being proposed here, and how it > > works. > > > > rday > > > > Ah, alright. Look at the following quote from the page: > > "On machines with boot-ROM and U-Boot-SPL, you might have better luck." > > I'd venture that most SoCs these days have a boot-ROM; on these > U-Boot, is not as sensitive to not finding a "virgin" system > (because the boot-ROM does some initialization beforehand). The > system I tested with is a Armada 38x, and we've also use a similar > approach on a MPC85xx system (if you would like to dig that deep, > the code is upstream: board/gdsys/p1022/controlcenterd*). The whole > SPL concept would be a problem if the boot loader needed a virgin > CPU (since, well, the SPL *is* a second U-Boot), so the restrictions > mentioned in the page are not as relevant for modern SoCs. > > That's as far as my knowledge goes, if anyone wants to correct me, > you're welcome to do so :-) ok, so it appears that wiki page is a little on the pessimistic side, then. i was aware of the SPL, having worked with beaglebone black for a while. i've never looked *closely* at how limited or restrictive the SPL is, but i did know it had to do far less than the full-featured u-boot. maybe it's time to look into that far more closely to understand it better, and to appreciate what's possible. i can see this 2013 presentation, "TPL: SPL loading SPL (and, SPL as just another U-Boot config", from scott wood of freescale. that looks like it might be educational. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted
On Wed, 20 Jul 2016, Mario Six wrote:
> On Wed, Jul 20, 2016 at 2:59 PM, Robert P. J. Day
> wrote:
> > On Wed, 20 Jul 2016, Mario Six wrote:
> >
> >> In certain circumstances it comes in handy to be able to boot
> >> into a second U-Boot. But as of now it is not possible to boot a
> >> U-Boot binary that is inside a FIT image, which is problematic
> >> for projects that e.g. need to guarantee a unbroken chain of
> >> trust from SOC all the way into the OS, since the FIT signing
> >> mechanism cannot be used.
> >>
> >> This patch adds the capability to load such FIT images.
> >>
> >> An example .its snippet (utilizing signature verification) might
> >> look like the following:
> >>
> >> images {
> >> firmware@1 {
> >> description = "2nd stage U-Boot image";
> >> data = /incbin/("u-boot-dtb.img.gz");
> >> type = "firmware";
> >> arch = "arm";
> >> os = "u-boot";
> >> compression = "gzip";
> >> load = <0x8FFFC0>;
> >> entry = <0x90>;
> >> signature@1 {
> >> algo = "sha256,rsa4096";
> >> key-name-hint = "key";
> >> };
> >> };
> >> };
> >
> > i'm sure i'm about to embarrass myself, but the above represents
> > loading a second version of u-boot into RAM, no? but i thought
> > u-boot didn't support being run out of RAM (except in special
> > circumstances). so what am i misunderstanding here?
>
> Well, if by "special circumstances" you mean "load the U-Boot image
> exactly where CONFIG_SYS_TEXT_BASE expects it to be loaded," then
> these are special circumstances; the U-Boot in the example snippet
> has CONFIG_SYS_TEXT_BASE of 0x90, we load it to 0x8FFFC0 (offset
> for the 0x40 byte header), and the bootm routine simply jumps to the
> entry point.
>
> Accordingly, the second stage U-Boot you want to run must not have
> the save CONFIG_SYS_TEXT_BASE as the U-Boot you want to run it out
> of (otherwise you would overwrite the existing image in memory);
> something like
>
> #ifdef CONFIG_SECONDUBOOT
> #defineCONFIG_SYS_TEXT_BASE0x0080
> #else
> #defineCONFIG_SYS_TEXT_BASE0x0090
> #endif
>
> is needed if you want to build both with the same header file.
>
> Hope that makes things a bit clearer.
not really, since i always thought that the difficulty in loading
and booting a second-stage u-boot was explained here:
http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM
that is, loading the second image to a different address is simple;
the apparent difficulty is that the second-stage u-boot might not be
able to handle the early setup already done by the first stage.
so i'm still confused as to what is being proposed here, and how it
works.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] common: fit: Allow U-Boot images to be booted
On Wed, 20 Jul 2016, Mario Six wrote:
> In certain circumstances it comes in handy to be able to boot into a second
> U-Boot. But as of now it is not possible to boot a U-Boot binary that is
> inside
> a FIT image, which is problematic for projects that e.g. need to guarantee a
> unbroken chain of trust from SOC all the way into the OS, since the FIT
> signing
> mechanism cannot be used.
>
> This patch adds the capability to load such FIT images.
>
> An example .its snippet (utilizing signature verification) might look
> like the following:
>
> images {
> firmware@1 {
> description = "2nd stage U-Boot image";
> data = /incbin/("u-boot-dtb.img.gz");
> type = "firmware";
> arch = "arm";
> os = "u-boot";
> compression = "gzip";
> load = <0x8FFFC0>;
> entry = <0x90>;
> signature@1 {
> algo = "sha256,rsa4096";
> key-name-hint = "key";
> };
> };
> };
i'm sure i'm about to embarrass myself, but the above represents
loading a second version of u-boot into RAM, no? but i thought u-boot
didn't support being run out of RAM (except in special circumstances).
so what am i misunderstanding here?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] what is the *recommended* split between defconfig file and header file?
On Tue, 19 Jul 2016, Tom Rini wrote: > On Tue, Jul 19, 2016 at 04:15:47AM -0400, Robert P. J. Day wrote: > > > > > kind of a style question but what is the preferred way to define a > > board in the sense of what belongs in the defconfig file and what > > belongs in the header file? > > The header files will eventually go away. Most of the contents are > things that could be, but haven't yet been, converted. A few things > like default environment are going to be harder to figure out. and what about the advantage of header files that allow the inclusion of other header files to reduce duplication? will config files be extended to allow the same thing? (they don't do that now, do they?) rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] what is the *recommended* split between defconfig file and header file?
kind of a style question but what is the preferred way to define a board in the sense of what belongs in the defconfig file and what belongs in the header file? example: i'm now messing with a MPC8315ERDB, and here's configs/MPC8315ERDB_defconfig in its entirety: CONFIG_PPC=y CONFIG_MPC83xx=y CONFIG_TARGET_MPC8315ERDB=y CONFIG_OF_BOARD_SETUP=y CONFIG_OF_STDOUT_VIA_ALIAS=y CONFIG_BOOTDELAY=6 CONFIG_HUSH_PARSER=y CONFIG_CMD_I2C=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_MII=y CONFIG_CMD_PING=y CONFIG_CMD_EXT2=y CONFIG_SYS_NS16550=y CONFIG_OF_LIBFDT=y based on my current understanding, the absolute minimum i would need in this defconfig file is just the first three lines: CONFIG_PPC=y CONFIG_MPC83xx=y CONFIG_TARGET_MPC8315ERDB=y which is sufficient to get me to the corresponding header file include/configs/MPC8315ERDB.h, at which point we're good. but is there a recommended style for what belongs in the defconfig file, and what belongs in the header file? or is that all just personal preference? i do appreciate that if there is a family of closely-related target boards, the header file can further include a "common" header file to avoid duplication but, beyond that, any style rules? rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] online wiki page for "fdt" commands full of FDT_ERR_BADMAGIC msgs
On Mon, 18 Jul 2016, Wolfgang Denk wrote: > Dear Robert, > > In message you > wrote: > > > > i'm sure i mentioned this before but the denx wiki page describing > > the "fdt" command is loaded with pretty much nothing but error > > messages: > > > > http://www.denx.de/wiki/view/DULG/UBootCmdFDT > > Obviously the DULGData_%BOARD%.UBootFDTCmd* %INCLUDE files are broken. > Eventually Heiko might remember where this test case was run; > alternatively, someone could recreate these manually. > > Let's wait for comment from Heiko when he's back from vacation in a > week. i was going to tweak some of those %INCLUDEd snippets to bring them up to date, but i have no idea whether (or how) one is allowed to do that. i'm guessing those snippets are totally under the control of the folks at denx? or no? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] is minicom still discouraged as the serial comms program?
On Mon, 18 Jul 2016, Wolfgang Denk wrote: > Dear Måns, > > In message you wrote: > > > > It's an opinion shared by many. Minicom appears to be mainly intended > > for use with an actual modem, and when there isn't one involved, those > > features tend to get in the way. > > Right - now you mention it I remember that minicom at least in some > default installations issues a set of AT modem commands when > connecting to a serial line, which have caused funny effects with > U-Boot here and there... ah, that makes sense. so far, i've used picocom almost exclusively and never had a problem. i am unaware of picocom issuing any AT commands. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] supported image compression types?
reading u-boot wiki page on image formats:
http://www.denx.de/wiki/view/DULG/UBootImages
wherein one reads:
"Compression Type (Provisions for uncompressed, gzip, bzip2, lzo;
Currently supported: uncompressed, gzip, bzip2, lzo)."
clearly, that wiki page list is incomplete, but there's more here.
first, the full list appears to live in include/image.h:
/*
* Compression Types
*/
enum {
IH_COMP_NONE= 0,/* No Compression Used */
IH_COMP_GZIP, /* gzip Compression Used */
IH_COMP_BZIP2, /* bzip2 Compression Used */
IH_COMP_LZMA, /* lzma Compression Used */
IH_COMP_LZO,/* lzo Compression Used */
IH_COMP_LZ4,/* lz4 Compression Used */
IH_COMP_COUNT,
};
but how those types are selected seems a bit inconsistent.
first, gzip appears to be automatic(?) for everyone, from
include/config_defaults.h:
#define CONFIG_GZIP 1
however, of all 5 types of compression, only one has a Kconfig file
entry, LZ4, in lib/Kconfig:
menu "Compression Support"
config LZ4
bool "Enable LZ4 decompression support"
help
If this option is set, support for LZ4 compressed images
is included. The LZ4 algorithm can run in-place as long as the
compressed image is loaded to the end of the output buffer, and
trades lower compression ratios for much faster decompression.
NOTE: This implements the release version of the LZ4 frame
format as generated by default by the 'lz4' command line tool.
This is not the same as the outdated, less efficient legacy
frame format currently (2015) implemented in the Linux kernel
(generated by 'lz4 -l'). The two formats are incompatible.
endmenu
for consistency, isn't it standard for any CONFIG_* settings to be
defined in Kconfig files? the other compression types seem to be
selectable simply by manually setting them in config files, as in:
$ grep -r "define CONFIG_LZMA" *
include/configs/bfin_adi_common.h:#define CONFIG_LZMA
include/configs/VCMA9.h:#define CONFIG_LZMA
include/configs/ap143.h:#define CONFIG_LZMA
include/configs/qemu-mips.h:#define CONFIG_LZMA
include/configs/iconnect.h:#define CONFIG_LZMA
include/configs/ap121.h:#define CONFIG_LZMA
include/configs/nsa310s.h:#define CONFIG_LZMA
include/configs/mv-plug-common.h:#define CONFIG_LZMA
include/configs/ib62x0.h:#define CONFIG_LZMA
include/configs/qemu-mips64.h:#define CONFIG_LZMA
include/configs/tplink_wdr4300.h:#define CONFIG_LZMA
include/configs/sandbox.h:#define CONFIG_LZMA
include/configs/smdk2410.h:#define CONFIG_LZMA
$
should not all compression types get their own entries in lib/Kconfig?
anyway, i'll at least update the wiki page.
movin' on ...
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] online wiki page for "fdt" commands full of FDT_ERR_BADMAGIC msgs
i'm sure i mentioned this before but the denx wiki page describing the "fdt" command is loaded with pretty much nothing but error messages: http://www.denx.de/wiki/view/DULG/UBootCmdFDT rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] more "#if 0" pedantry related to moving macros in header files
TCSC_RTCIRQ_MASK * arch/powerpc/include/asm/8xx_immap.h:#define RTCSC_RTCIRQ_MASK ((ushort)0xff00) $ grep -r PISCR_PIRQ_MASK * arch/powerpc/include/asm/8xx_immap.h:#define PISCR_PIRQ_MASK ((ushort)0xff00) arch/powerpc/include/asm/immap_8260.h:#define PISCR_PIRQ_MASK ((ushort)0xff00) $ so what are they used for? -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] what is with the "#if 0"ed part of ARP hdr in include/net.h?
was poking around in include/net.h, and noticed this snippet:
/*
* Address Resolution Protocol (ARP) header.
*/
struct arp_hdr {
... snip ...
#define ar_sha ar_data[0]
#define ar_spa ar_data[ARP_HLEN]
#define ar_tha ar_data[ARP_HLEN + ARP_PLEN]
#define ar_tpa ar_data[ARP_HLEN + ARP_PLEN + ARP_HLEN]
#if 0
u8 ar_sha[]; /* Sender hardware address */
u8 ar_spa[]; /* Sender protocol address */
u8 ar_tha[]; /* Target hardware address */
u8 ar_tpa[]; /* Target protocol address */
#endif /* 0 */
};
i just checked, and that "#if 0" has been there since 2002:
2d966958 (Wolfgang Denk2002-10-31 22:12:35 + 421) #if 0
717234e0 (Sergey Temerkhanov 2015-04-08 01:41:23 -0500 422)
u8 ar_sha[]; /* Sender hardware address */
717234e0 (Sergey Temerkhanov 2015-04-08 01:41:23 -0500 423)
u8 ar_spa[]; /* Sender protocol address */
717234e0 (Sergey Temerkhanov 2015-04-08 01:41:23 -0500 424)
u8 ar_tha[]; /* Target hardware address */
717234e0 (Sergey Temerkhanov 2015-04-08 01:41:23 -0500 425)
u8 ar_tpa[]; /* Target protocol address */
2d966958 (Wolfgang Denk2002-10-31 22:12:35 + 426)
#endif /* 0 */
is it doing anything, like acting as a comment or something?
rday
p.s. there's quite a lot of "#if 0" throughout the source code, some
of which i may submit patches to get rid of just in the areas i'm
confortable with.
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] file "doc/README.mpc83xxads" seems way obsolete
that file talks about configuring with: $ make MPC8349ADS_config Configuring for MPC8349ADS board... but that was merged into MPC8349EMDS about a decade ago: commit 8fe9bf61efa6cab617dc99dfc5413e47f2ef969f Author: Kumar Gala Date: Thu Apr 20 13:45:32 2006 -0500 Merged MPC8349ADS and MPC8349EMDS ports into MPC8349EMDS port: - Removed MPC8349ADS port - Added PCI support to MPC8349ADS - reworked memory map to allow mapping of all regions with BATs Patch by Kumar Gala 20 Apr 2006 i'll let someone else decide if they want to do anything about that. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] is minicom still discouraged as the serial comms program?
i know that minicom has been discouraged for quite some time WRT u-boot, is that still the case? and what was the flaw with minicom, anyway? and is there any problem with picocom, which seems to work for me just fine. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] update u-boot BDM/JTAG debugger page?
On Fri, 15 Jul 2016, Tom Rini wrote: > On Fri, Jul 15, 2016 at 03:37:52PM -0400, Robert P. J. Day wrote: > > h ... https://tincantools.com/wiki/Flyswatter3_PIC32MX_How_To > > Well, it's not listed on the store yet, so I'd contact them > privately if I were you :) hm ... quite so. so, just more vaporware. too bad. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] update u-boot BDM/JTAG debugger page?
On Fri, 15 Jul 2016, Tom Rini wrote: > On Fri, Jul 15, 2016 at 03:29:54PM -0400, Robert P. J. Day wrote: > > On Fri, 15 Jul 2016, Tom Rini wrote: > > > > > On Fri, Jul 15, 2016 at 08:38:57AM -0400, Robert P. J. Day wrote: > > > > > > > i am in no way a BDM/JTAG authority, but i notice that on this > > > > u-boot page: > > > > > > > > http://www.denx.de/wiki/DULG/UBootInstallUsingBDM > > > > > > > > there is a recommendation for the BDI2000/BDI3000, but those are on > > > > their way out: > > > > > > > > http://www.abatron.ch/news/eol-bdi-products/ > > > > > > > > so are there any other recommendations for debuggers? is anyone using > > > > the flyswatter debuggers successfully? > > > > > > In general I use one of the FTDI based products. I've got a Flyswatter > > > 2, some Olimex ones and and XDS...something low numbered or two as well. > > > > as i read it, the flyswatter3 is MIPS-only, is that correct? an > > up-to-date debugging page would be immensely handy. > > Er, I don't see a Flyswatter 3, but I do see that Tin Can Tools has > adapters for MIPS for Flyswatter 2. h ... https://tincantools.com/wiki/Flyswatter3_PIC32MX_How_To rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] update u-boot BDM/JTAG debugger page?
On Fri, 15 Jul 2016, Tom Rini wrote: > On Fri, Jul 15, 2016 at 08:38:57AM -0400, Robert P. J. Day wrote: > > > i am in no way a BDM/JTAG authority, but i notice that on this > > u-boot page: > > > > http://www.denx.de/wiki/DULG/UBootInstallUsingBDM > > > > there is a recommendation for the BDI2000/BDI3000, but those are on > > their way out: > > > > http://www.abatron.ch/news/eol-bdi-products/ > > > > so are there any other recommendations for debuggers? is anyone using > > the flyswatter debuggers successfully? > > In general I use one of the FTDI based products. I've got a Flyswatter > 2, some Olimex ones and and XDS...something low numbered or two as well. as i read it, the flyswatter3 is MIPS-only, is that correct? an up-to-date debugging page would be immensely handy. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Various, unrelated tree-wide typo fixes.
Fix a number of typos, including:
* "compatble" -> "compatible"
* "eanbeld" -> "enabled"
* "envrionment" -> "environment"
* "FTD" -> "FDT" (for "flattened device tree")
* "ommitted" -> "omitted"
* "overriden" -> "overridden"
* "partiton" -> "partition"
* "propogate" -> "propagate"
* "resourse" -> "resource"
* "rest in piece" -> "rest in peace"
* "suport" -> "support"
* "varible" -> "variable"
Signed-off-by: Robert P. J. Day
---
i think this should do it.
diff --git a/README b/README
index 26d5ad2..932c71f 100644
--- a/README
+++ b/README
@@ -511,7 +511,7 @@ The following options need to be configured:
implemetation.
CONFIG_SYS_FSL_DDR2
- Board config to use DDR2. It can be eanbeld for SoCs with
+ Board config to use DDR2. It can be enabled for SoCs with
Freescale DDR2 or DDR3 controllers, depending on the board
implementation.
diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig
index afeaac8..bd6108e 100644
--- a/arch/arm/cpu/armv7/Kconfig
+++ b/arch/arm/cpu/armv7/Kconfig
@@ -21,7 +21,7 @@ config ARMV7_BOOT_SEC_DEFAULT
Say Y here to boot in secure mode by default even if non-secure mode
is supported. This option is useful to boot kernels which do not
suppport booting in non-secure mode. Only set this if you need it.
- This can be overriden at run-time by setting the bootm_boot_mode env.
+ This can be overridden at run-time by setting the bootm_boot_mode env.
variable to "sec" or "nonsec".
config ARMV7_VIRT
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
index da5e052..7867c37 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
+++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
@@ -128,7 +128,7 @@ mcinitcmd: This environment variable is defined to
initiate MC and DPL deploymen
during U-boot booting.However the MC, DPC and DPL can be
applied from
console independently.
The variable needs to be set from the console once and then on
- rebooting the parameters set in the varible will automatically
be
+ rebooting the parameters set in the variable will automatically
be
executed. The commmand is demostrated taking an example of mc
boot
using NOR Flash i.e. MC, DPL, and DPC is stored in the NOR
flash:
diff --git a/arch/arm/cpu/armv8/zynqmp/mp.c b/arch/arm/cpu/armv8/zynqmp/mp.c
index 58312a7..e10fc31 100644
--- a/arch/arm/cpu/armv8/zynqmp/mp.c
+++ b/arch/arm/cpu/armv8/zynqmp/mp.c
@@ -128,7 +128,7 @@ static void enable_clock_r5(void)
writel(tmp, &crlapb_base->cpu_r5_ctrl);
/* Give some delay for clock
-* to propogate */
+* to propagate */
udelay(0x500);
}
diff --git a/arch/arm/imx-common/ddrmc-vf610.c
b/arch/arm/imx-common/ddrmc-vf610.c
index daf3c7e..9bc56f6 100644
--- a/arch/arm/imx-common/ddrmc-vf610.c
+++ b/arch/arm/imx-common/ddrmc-vf610.c
@@ -212,7 +212,7 @@ void ddrmc_ctrl_init_ddr3(struct ddr3_jedec_timings const
*timings,
cr_setting++;
}
- /* perform default PHY settings (may be overriden by custom settings */
+ /* perform default PHY settings (may be overridden by custom settings */
phy_setting = default_phy_settings;
while (phy_setting->phy_rnum >= 0) {
writel(phy_setting->setting,
diff --git a/arch/arm/include/asm/arch-tegra/board.h
b/arch/arm/include/asm/arch-tegra/board.h
index 783bb3c..a3db7ed 100644
--- a/arch/arm/include/asm/arch-tegra/board.h
+++ b/arch/arm/include/asm/arch-tegra/board.h
@@ -20,7 +20,7 @@ void gpio_early_init(void); /* overrideable GPIO config
*/
/*
* Hooks to allow boards to set up the pinmux for a specific function.
* Has to be implemented in the board files as we don't yet support pinmux
- * setup from FTD. If a board file does not implement one of those functions
+ * setup from FDT. If a board file does not implement one of those functions
* an empty stub function will be called.
*/
diff --git a/arch/arm/include/asm/arch-tegra/clock.h
b/arch/arm/include/asm/arch-tegra/clock.h
index e56031d..7daf8bc 100644
--- a/arch/arm/include/asm/arch-tegra/clock.h
+++ b/arch/arm/include/asm/arch-tegra/clock.h
@@ -324,7 +324,7 @@ enum periph_id clk_id_to_periph_id(int clk_id);
* @param p post divider(DIVP)
* @param cpcon base PLL charge pump(CPCON)
* @return 0 if ok, -1 on error (the request
Re: [U-Boot] Various, unrelated tree-wide typo fixes.
On Fri, 15 Jul 2016, Tom Rini wrote: > On Fri, Jul 15, 2016 at 07:17:36AM -0400, Robert P. J. Day wrote: > > > Fix a number of typos, including: > > > > * "comptible", "compatble" -> "compatible" > > * "eanbeld" -> "enabled" > > * "envrionment" -> "environment" > > * "FTD" -> "FDT" (for "flattened device tree") > > * "ommitted" -> "omitted" > > * "overriden" -> "overridden" > > * "partiton" -> "partition" > > * "propogate" -> "propagate" > > * "resourse" -> "resource" > > * "rest in piece" -> "rest in peace" > > * "suport" -> "support" > > * "varible" -> "variable" > > > > Signed-off-by: Robert P. J. Day > [snip] > > diff --git a/arch/arm/dts/tegra124.dtsi b/arch/arm/dts/tegra124.dtsi > > index 275a509..82bf083 100644 > > --- a/arch/arm/dts/tegra124.dtsi > > +++ b/arch/arm/dts/tegra124.dtsi > > All of these DT ones are going to be lost, probably, when resynced with > the kernel again. Please push those upstream there instead, thanks! ack, of course. so resubmit after cleansing patch of all dts content? or will you take care of that? either way works for me. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] curious about "#ifndef CONFIG_ENV_OVERWRITE" test in lsxl.c
was perusing the wiki page on u-boot environment variables: http://www.denx.de/wiki/view/DULG/UBootPowerOn and just now learned about the ability to mark environment variables as "set once", that sort of thing, so i went looking for examples, and noticed, in board/buffalo/lsxl/lsxl.c: #ifndef CONFIG_ENV_OVERWRITE # error "You need to set CONFIG_ENV_OVERWRITE" #endif ok, but why not just add the line: #define CONFIG_ENV_OVERWRITE to include/configs/lsxl.h, and get rid of that test? or is this just a historical holdover when things were done differently? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] update u-boot BDM/JTAG debugger page?
i am in no way a BDM/JTAG authority, but i notice that on this u-boot page: http://www.denx.de/wiki/DULG/UBootInstallUsingBDM there is a recommendation for the BDI2000/BDI3000, but those are on their way out: http://www.abatron.ch/news/eol-bdi-products/ so are there any other recommendations for debuggers? is anyone using the flyswatter debuggers successfully? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Various, unrelated tree-wide typo fixes.
Fix a number of typos, including:
* "comptible", "compatble" -> "compatible"
* "eanbeld" -> "enabled"
* "envrionment" -> "environment"
* "FTD" -> "FDT" (for "flattened device tree")
* "ommitted" -> "omitted"
* "overriden" -> "overridden"
* "partiton" -> "partition"
* "propogate" -> "propagate"
* "resourse" -> "resource"
* "rest in piece" -> "rest in peace"
* "suport" -> "support"
* "varible" -> "variable"
Signed-off-by: Robert P. J. Day
---
been collecting these on a separate branch for a while, might as
well submit them before starting fresh. would it have been better to
break this into smaller pieces? happy to do that as well.
diff --git a/README b/README
index 26d5ad2..932c71f 100644
--- a/README
+++ b/README
@@ -511,7 +511,7 @@ The following options need to be configured:
implemetation.
CONFIG_SYS_FSL_DDR2
- Board config to use DDR2. It can be eanbeld for SoCs with
+ Board config to use DDR2. It can be enabled for SoCs with
Freescale DDR2 or DDR3 controllers, depending on the board
implementation.
diff --git a/arch/arm/cpu/armv7/Kconfig b/arch/arm/cpu/armv7/Kconfig
index afeaac8..bd6108e 100644
--- a/arch/arm/cpu/armv7/Kconfig
+++ b/arch/arm/cpu/armv7/Kconfig
@@ -21,7 +21,7 @@ config ARMV7_BOOT_SEC_DEFAULT
Say Y here to boot in secure mode by default even if non-secure mode
is supported. This option is useful to boot kernels which do not
suppport booting in non-secure mode. Only set this if you need it.
- This can be overriden at run-time by setting the bootm_boot_mode env.
+ This can be overridden at run-time by setting the bootm_boot_mode env.
variable to "sec" or "nonsec".
config ARMV7_VIRT
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
index da5e052..7867c37 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
+++ b/arch/arm/cpu/armv8/fsl-layerscape/doc/README.lsch3
@@ -128,7 +128,7 @@ mcinitcmd: This environment variable is defined to
initiate MC and DPL deploymen
during U-boot booting.However the MC, DPC and DPL can be
applied from
console independently.
The variable needs to be set from the console once and then on
- rebooting the parameters set in the varible will automatically
be
+ rebooting the parameters set in the variable will automatically
be
executed. The commmand is demostrated taking an example of mc
boot
using NOR Flash i.e. MC, DPL, and DPC is stored in the NOR
flash:
diff --git a/arch/arm/cpu/armv8/zynqmp/mp.c b/arch/arm/cpu/armv8/zynqmp/mp.c
index 58312a7..e10fc31 100644
--- a/arch/arm/cpu/armv8/zynqmp/mp.c
+++ b/arch/arm/cpu/armv8/zynqmp/mp.c
@@ -128,7 +128,7 @@ static void enable_clock_r5(void)
writel(tmp, &crlapb_base->cpu_r5_ctrl);
/* Give some delay for clock
-* to propogate */
+* to propagate */
udelay(0x500);
}
diff --git a/arch/arm/dts/tegra124.dtsi b/arch/arm/dts/tegra124.dtsi
index 275a509..82bf083 100644
--- a/arch/arm/dts/tegra124.dtsi
+++ b/arch/arm/dts/tegra124.dtsi
@@ -316,7 +316,7 @@
* driver and APB DMA based serial driver for higher baudrate
* and performace. To enable the 8250 based driver, the compatible
* is "nvidia,tegra124-uart", "nvidia,tegra20-uart" and to enable
-* the APB DMA based serial driver, the comptible is
+* the APB DMA based serial driver, the compatible is
* "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart".
*/
uarta: serial@70006000 {
diff --git a/arch/arm/dts/tegra20.dtsi b/arch/arm/dts/tegra20.dtsi
index 31223e4..0b55ee0 100644
--- a/arch/arm/dts/tegra20.dtsi
+++ b/arch/arm/dts/tegra20.dtsi
@@ -311,7 +311,7 @@
* driver and APB DMA based serial driver for higher baudrate
* and performace. To enable the 8250 based driver, the compatible
* is "nvidia,tegra20-uart" and to enable the APB DMA based serial
-* driver, the comptible is "nvidia,tegra20-hsuart".
+* driver, the compatible is "nvidia,tegra20-hsuart".
*/
uarta: serial@70006000 {
compatible = "nvidia,tegra20-uart";
diff --git a/arch/arm/imx-common/ddrmc-vf610.c
b/arch/arm/imx-common/ddrmc-vf610.c
index daf3c7e..9bc56f6 100644
--- a/arch/arm/imx-common/ddrmc-vf610.c
+++ b/arch/arm/imx-common/ddr
Re: [U-Boot] does u-boot automatically determine valid command abbreviations?
On Thu, 14 Jul 2016, Wolfgang Denk wrote: > Dear Robert, ... snip ... > Then, at some point, a new command (can't remember which one it was; > eventually "setdcr"?) was added, and "set" was no longer a unique > prefix, old habits and a ton of scripts broke. > > So habits had to be adjusted to type "sete" instead. So were > scripts. The word was fine again. > > You guess what happened? Right - then the command "setexpr" was > added, and again "sete" was no longer unique. > > Moral of the stroy: use "env set" ;-) i'm embarrassed to admit i didn't even know the "env" command existed. learn something new every day. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] best way to submit a patch for numerous, tree-wide typoz?
what is the best way to send in a patch for quite a number of tree-wide (ie., unrelated) typos throughout the source? almost all of them are innocuous -- either comments or in printed strings, so they *shouldn't* break anything. these days, i have a separate "typos" git branch where i just collect typos i run across, and keep rebasing it against "master" to stay up to date. and since this appears to be the u-boot merge window, i figure now is a good time to send it in. but, as i said, it's spread all over the tree, so is a single patch even a good idea, or should i try to break it into smaller, bite-size pieces? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] does u-boot automatically determine valid command abbreviations?
i just want to confirm that u-boot *automatically* determines the
valid prefix abbreviations for u-boot commands, correct? as in, there
is no registration or configuration to do that, it's done
automatically based on the commands that have been configured into
u-boot and whether a command abbreviation represents a unique prefix
for all configured commands, yes?
i'm making that assumption based on this routine from
common/command.c:
/* find command table entry for a command */
cmd_tbl_t *find_cmd_tbl(const char *cmd, cmd_tbl_t *table, int table_len)
{
#ifdef CONFIG_CMDLINE
cmd_tbl_t *cmdtp;
cmd_tbl_t *cmdtp_temp = table; /* Init value */
const char *p;
int len;
int n_found = 0;
if (!cmd)
return NULL;
/*
* Some commands allow length modifiers (like "cp.b");
* compare command name only until first dot.
*/
len = ((p = strchr(cmd, '.')) == NULL) ? strlen (cmd) : (p - cmd);
for (cmdtp = table; cmdtp != table + table_len; cmdtp++) {
if (strncmp(cmd, cmdtp->name, len) == 0) {
if (len == strlen(cmdtp->name))
return cmdtp; /* full match */
cmdtp_temp = cmdtp; /* abbreviated command ? */
n_found++;
}
}
if (n_found == 1) { /* exactly one match */
return cmdtp_temp;
}
#endif /* CONFIG_CMDLINE */
return NULL;/* not found or ambiguous command */
}
so am i reading that correctly that any unique prefix for configured
commands will work? i ask only because, recently, someone made the
claim in some u-boot instructions i'm reading:
* Use “setenv” command instead of “set” for target boards. u-boot
source is not yet modified to alias “setenv” to “set”. Other
commands like “printenv” and “saveenv” can still be called as
“print” and “save”.
huh? why would someone have to "modify" the source to allow "set" to
be a valid abbreviation for "setenv"? (aside: these instructions mix
advice for both current and very old versions of u-boot, so maybe that
claim is only for very old versions.)
anyway, clarifiation would be appreciated. thank you kindly.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] what are valid formats for initrd image downloaded and used by "bootm"
On Fri, 8 Jul 2016, Wolfgang Denk wrote: > Dear Robert, > > In message you > wrote: > > > > yup, i just went through most of the above, and built a > > *cpio.gz.u-boot format ramdisk, and it works just fine, so i'm happy. > > onward ... > > For now this is OK, but you might consider switching to FIT images > instead. These may look more complicated initially, but they are also > much more flexible and allow for things like signed / encrypted images > and such... already on my list ... in my copious free time. :-( rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] what are valid formats for initrd image downloaded and used by "bootm"
On Fri, 8 Jul 2016, Wolfgang Denk wrote:
> Dear Robert,
>
> In message you
> wrote:
> >
> > ok, and one last (admittedly a bit off-topic) followup ...
> > openembedded supplies a class, image_types_uboot.bbclass, that can
> > generate a pile of u-boot related images:
> >
> > IMAGE_TYPES += "ext2.u-boot ext2.gz.u-boot ext2.bz2.u-boot
> >ext2.lzma.u-boot ext3.gz.u-boot ext4.gz.u-boot cpio.gz.u-boot"
> >
> > if i want an immediately usable initrd i can download and pass off to
> > bootm, i'm assuming i can use any of those "u-boot" suffixed image
> > types, like, say, "cpio.gz.u-boot," which will generate a file with a
> > name like "blahblah...20160708082958.rootfs.cpio.gz.u-boot".
>
> What is your assumption based on? Just on the suffix ".u-boot"?
>
> > so more an openembedded question, but am i correct in assuming that
> > any of those OE "u-boot" files are usable as initrds? thanks.
>
> You need to look into the actual recipes to be sure what the ".u-boot"
> means, and how these images are built.
>
> "openembedded-core/meta/classes/image_types_uboot.bbclass" defines
> something like this:
>
> oe_mkimage () {
> mkimage -A ${UBOOT_ARCH} -O linux -T ramdisk -C $2 -n ${IMAGE_NAME} \
> -d ${DEPLOY_DIR_IMAGE}/$1 ${DEPLOY_DIR_IMAGE}/$1.u-boot
> if [ x$3 = x"clean" ]; then
> rm $1
> fi
> }
>
> This would indeed mean that ".u-boot" is, from U-Boot's point of
> view, a ramdisk image wrapped with the legacy image header, and as
> such usable with "bootm".
yup, i just went through most of the above, and built a
*cpio.gz.u-boot format ramdisk, and it works just fine, so i'm happy.
onward ...
rday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] what are valid formats for initrd image downloaded and used by "bootm"
On Fri, 8 Jul 2016, Wolfgang Denk wrote: > Dear Robert, > > In message you > wrote: > > > > using yocto project to build artifacts to tftp down to a board for > > "bootm" command -- what are the valid formats for the "initrd" object > > that can be recognized by "bootm"? since YP can generate a *ton* of > > different image types. thanks. > > "bootm" understands botht he (deprecated) legacy uImage format, plus > of course the (preferred) FIT images. ok, and one last (admittedly a bit off-topic) followup ... openembedded supplies a class, image_types_uboot.bbclass, that can generate a pile of u-boot related images: IMAGE_TYPES += "ext2.u-boot ext2.gz.u-boot ext2.bz2.u-boot ext2.lzma.u-boot ext3.gz.u-boot ext4.gz.u-boot cpio.gz.u-boot" if i want an immediately usable initrd i can download and pass off to bootm, i'm assuming i can use any of those "u-boot" suffixed image types, like, say, "cpio.gz.u-boot," which will generate a file with a name like "blahblah...20160708082958.rootfs.cpio.gz.u-boot". so more an openembedded question, but am i correct in assuming that any of those OE "u-boot" files are usable as initrds? thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] what are valid formats for initrd image downloaded and used by "bootm"
using yocto project to build artifacts to tftp down to a board for "bootm" command -- what are the valid formats for the "initrd" object that can be recognized by "bootm"? since YP can generate a *ton* of different image types. thanks. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] where *precisely* is u-boot's environment stored?
On Wed, 6 Jul 2016, Wolfgang Denk wrote: > Dear Robert, > > In message you > wrote: > > > > not to be overly pedantic (too late!), but is there a preferred > > expression for the environment stored at CONFIG_ENV_ADDR? is it > > "permanent environment" or "saved environment" or what? > > I tend to call it the "persistent copy" of the environment (resp. > copies in case of redundant environment), in contrast to the in > memory copy of it. Upon start, the memory copy gets initialized > from the persistent one, unless this turns out to be corrupt (or > uninitialized, the effect is the same), in which case the builtin > default environment is used to initialize the in memory copy. is there a way to tell whether you're getting the current environment from the persistent copy or from the default environment? i'm not sure i have a pressing need for that, i'm just curious. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] "(ulong)&default_environment[0]" vs "(ulong)default_environment"?
more pedantry ... as i was crawling through the env code, i noticed the common usage of "(ulong)&default_environment[0]" rather than what i thought was the more standard expression "(ulong)default_environment" to find the address of that array, so i did a quick grep: $ grep -r "gd->env_addr.*default_environment" * board/freescale/ls1043ardb/ls1043ardb.c:gd->env_addr = (ulong)&default_environment[0]; board/freescale/ls2080ardb/ls2080ardb.c:gd->env_addr = (ulong)&default_environment[0]; board/freescale/ls2080a/ls2080a.c: gd->env_addr = (ulong)&default_environment[0]; board/freescale/ls1043aqds/ls1043aqds.c:gd->env_addr = (ulong)&default_environment[0]; board/freescale/ls2080aqds/ls2080aqds.c:gd->env_addr = (ulong)&default_environment[0]; common/env_onenand.c: gd->env_addr = (ulong)&default_environment[0]; common/env_sf.c:gd->env_addr = (ulong)&default_environment[0]; common/env_dataflash.c: gd->env_addr = (ulong)&default_environment[0]; common/env_nowhere.c: gd->env_addr= (ulong)&default_environment[0]; common/env_nvram.c: gd->env_addr= (ulong)&default_environment[0]; common/env_fat.c: gd->env_addr = (ulong)&default_environment[0]; common/env_mmc.c: gd->env_addr= (ulong)&default_environment[0]; common/env_flash.c: gd->env_addr= (ulong)&default_environment[0]; common/env_remote.c:gd->env_addr = (ulong)default_environment; <- common/env_eeprom.c:gd->env_addr = (ulong)&default_environment[0]; common/env_nand.c: gd->env_addr= (ulong)&default_environment[0]; common/env_ubi.c: gd->env_addr = (ulong)&default_environment[0]; $ so everyone seems to be using one form of that calculation, except for that lonely expression in common/env_remote.c. :-( it all works, of course, it's just inconsistent. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] in Kbuild, what is the difference between "extra-" and "obj-"?
admittedly, this is more a kernel Kbuild question, but in common/Makefile, i see the snippet: extra-$(CONFIG_ENV_IS_EMBEDDED) += env_embedded.o obj-$(CONFIG_ENV_IS_IN_EEPROM) += env_embedded.o extra-$(CONFIG_ENV_IS_IN_FLASH) += env_embedded.o what is the functional difference between using "extra-" and "obj-" in the above? those three lines look ... inconsistent? anyway, what is going on there? thanks. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] where *precisely* is u-boot's environment stored?
On Wed, 6 Jul 2016, Wolfgang Denk wrote: > Dear Robert, > > In message you > wrote: > > > > not to be overly pedantic (too late!), but is there a preferred > > expression for the environment stored at CONFIG_ENV_ADDR? is it > > "permanent environment" or "saved environment" or what? > > I tend to call it the "persistent copy" of the environment (resp. > copies in case of redundant environment), in contrast to the in > memory copy of it. Upon start, the memory copy gets initialized > from the persistent one, unless this turns out to be corrupt (or > uninitialized, the effect is the same), in which case the builtin > default environment is used to initialize the in memory copy. ok, i'm good with that, thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] where *precisely* is u-boot's environment stored?
On Wed, 6 Jul 2016, Måns Rullgård wrote: > "Robert P. J. Day" writes: > > > On Wed, 6 Jul 2016, Måns Rullgård wrote: > > > >> "Robert P. J. Day" writes: > > > >> > p.s. how does the default environment get to the > >> > CONFIG_ENV_ADDR defined in the board header file? is that done > >> > automatically when u-boot starts to run and notices that there > >> > is no valid environment info at that address, and therefore > >> > copies it for you? > >> > >> If the stored environment is invalid (e.g. uninitialised), the > >> built-in default is used. Nothing is written until you issue a > >> saveenv command. This saves a copy of the live environment to the > >> configured location. > > > > ah, that's the final bit of the puzzle i was looking for ... the > > first time a "saveenv" is done is when the configured location is > > examined and, if uninitialized, the env is copied there and is > > used from then on. > > saveenv always writes whatever is in memory to the permanent location, and by "permanent location", you mean CONFIG_ENV_ADDR as defined in the board definition file, yes? > overwriting anything that was previously there. On startup, u-boot > checks if the saved environment is valid and uses it if it is. If and, again, by "saved environment", i assume you mean what is at CONFIG_ENV_ADDR. it's all a matter of terminology -- switching back and forth can make things confusing. not to be overly pedantic (too late!), but is there a preferred expression for the environment stored at CONFIG_ENV_ADDR? is it "permanent environment" or "saved environment" or what? > not, the defaults (as configured for the board) are used. Only the > saveenv command writes anything to nonvolatile storage. ok, i think i have a handle on this now, thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] where *precisely* is u-boot's environment stored?
On Wed, 6 Jul 2016, Måns Rullgård wrote: > "Robert P. J. Day" writes: > > p.s. how does the default environment get to the CONFIG_ENV_ADDR > > defined in the board header file? is that done automatically when > > u-boot starts to run and notices that there is no valid > > environment info at that address, and therefore copies it for you? > > If the stored environment is invalid (e.g. uninitialised), the > built-in default is used. Nothing is written until you issue a > saveenv command. This saves a copy of the live environment to the > configured location. ah, that's the final bit of the puzzle i was looking for ... the first time a "saveenv" is done is when the configured location is examined and, if uninitialized, the env is copied there and is used from then on. and it would appear that the location of the "current" environment is stored in "gd->env_addr", does that sound about right? i'm still going to write this up somewhere for future reference. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] where *precisely* is u-boot's environment stored?
oh, wait, i think i just answered some of my questions based on this
snippet from common/env_nvram.c:
/*
* Initialize Environment use
*
* We are still running from ROM, so data use is limited
*/
int env_init(void)
{
#if defined(CONFIG_SYS_NVRAM_ACCESS_ROUTINE)
ulong crc;
uchar data[ENV_SIZE];
nvram_read(&crc, CONFIG_ENV_ADDR, sizeof(ulong));
nvram_read(data, CONFIG_ENV_ADDR + sizeof(ulong), ENV_SIZE);
if (crc32(0, data, ENV_SIZE) == crc) {
gd->env_addr= (ulong)CONFIG_ENV_ADDR + sizeof(long);
#else
if (crc32(0, env_ptr->data, ENV_SIZE) == env_ptr->crc) {
gd->env_addr= (ulong)&env_ptr->data;
#endif
gd->env_valid = 1;
} else {
gd->env_addr= (ulong)&default_environment[0];
gd->env_valid = 0;
}
return 0;
}
so if there is a valid environment at the address specified by the
board header file, it's used, otherwise fall back to
default_environment[]. i had suspected it was something like that, i
just hadn't found the code yet.
is this written up somewhere?
rday
p.s. how does the default environment get to the CONFIG_ENV_ADDR
defined in the board header file? is that done automatically when
u-boot starts to run and notices that there is no valid environment
info at that address, and therefore copies it for you?
i will keep reading the source.
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] where *precisely* is u-boot's environment stored?
kind of embarrassed that i don't know the answer to this but, short
form of question, when i build a u-boot.bin and copy it to NOR flash
on my target board, where is the environment stored such that user
space fw_printenv and fw_setenv utilities can get at them?
longer form of question: i just used yocto project to build for my
MPC8315E-RDB target board, and one of the artifacts generated was
"u-boot.bin", apparently ready for copying to NOR flash on this board,
NOR flash being at 0xfe00. i poked around trying to figure out
where the environment was stored in that image, and i found the
following in include/env_default.h:
... snip ...
const uchar default_environment[] = {
#endif
#ifdef CONFIG_ENV_CALLBACK_LIST_DEFAULT
ENV_CALLBACK_VAR "=" CONFIG_ENV_CALLBACK_LIST_DEFAULT "\0"
#endif
#ifdef CONFIG_ENV_FLAGS_LIST_DEFAULT
ENV_FLAGS_VAR "=" CONFIG_ENV_FLAGS_LIST_DEFAULT "\0"
#endif
#ifdef CONFIG_BOOTARGS
"bootargs=" CONFIG_BOOTARGS "\0"
#endif
#ifdef CONFIG_BOOTCOMMAND
"bootcmd=" CONFIG_BOOTCOMMAND "\0"
#endif
... etc etc ...
i then checked u-boot.sym and found:
fe04c920 g O .text 0389 default_environment
and if i "hexdump -C" the "u-boot.bin" file, sure enough, there it is,
the apparent beginning of the default environment at 0x0004c920:
0004c900 8d ef 02 2d 25 2e 2a 73 00 00 00 00 25 73 25 64 |...-%.*s%s%d|
0004c910 2c 25 64 00 70 61 72 74 69 74 69 6f 6e 00 00 00 |,%d.partition...|
0004c920 62 6f 6f 74 63 6d 64 3d 73 65 74 65 6e 76 20 62 |bootcmd=setenv b|
0004c930 6f 6f 74 61 72 67 73 20 72 6f 6f 74 3d 2f 64 65 |ootargs root=/de|
0004c940 76 2f 6e 66 73 20 72 77 20 6e 66 73 72 6f 6f 74 |v/nfs rw nfsroot|
0004c950 3d 24 73 65 72 76 65 72 69 70 3a 24 72 6f 6f 74 |=$serverip:$root|
... and on and on ...
so AFAICT, the default_environment[] ends up in the executable (and,
consequently, in flash) i'm assuming based on wherever the linker
places it based on the "u-boot.lds" file, correct?
however, if i look at the defn file for this target board,
include/configs/MPC8315ERDB.h, i can see the various config settings
defining where the environment resides, things like
CONFIG_ENV_IS_IN_FLASH, CONFIG_ENV_ADDR and so on:
#if !defined(CONFIG_SYS_RAMBOOT)
#define CONFIG_ENV_IS_IN_FLASH 1
#define CONFIG_ENV_ADDR \
(CONFIG_SYS_MONITOR_BASE + CONFIG_SYS_MONITOR_LEN)
#define CONFIG_ENV_SECT_SIZE0x1 /* 64K(one sector) for env */
#define CONFIG_ENV_SIZE 0x2000
and if i build the package u-boot-fw-utils to get the user space
utilities "fw_printenv" and "fw_setenv", that package needs to be told
where the environment is stored, and that's based on what it gets from
the board's header file, which in this case defines:
#define CONFIG_SYS_MONITOR_LEN (384 * 1024) /* Reserve 384 kB for Mon */
which represents an env offset of 0x0006 into flash.
so what is the correlation between those two addresses? there's the
actual address of default_environment[] based on where the linker puts
it (0xfe04c920), as opposed to where fw-utils will (apparently) look
for the environment (0xfe06). what's the connection here?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] board/cirrus/edb93xx/edb93xx.c: "egpio" versus "epgio"?
On Mon, 27 Jun 2016, Robert P. J. Day wrote: > > possibly embarrassing myself here, but i just ran across this in > edb93xx.c, which looks ... weird, a mixture of "EGPIO" and "EPGIO" > toward the end of that source file: > > ... snip ... never mind, i just noticed that, first, the "edb" boards are listed in the scrapyard file: edb9301 arm arm920t716f7ad 2011-07-17 edb9302 arm arm920t716f7ad 2011-07-17 edb9302a arm arm920t716f7ad 2011-07-17 edb9307 arm arm920t716f7ad 2011-07-17 edb9307a arm arm920t716f7ad 2011-07-17 edb9312 arm arm920t716f7ad 2011-07-17 edb9315 arm arm920t716f7ad 2011-07-17 edb9315a arm arm920t716f7ad 2011-07-17 but, weirdly, that source file was added in 2014, with opening comment: /* * Board initialization for EP93xx so why is an EP93xx board init file being added under allegedly scrapped board directory board/cirrus/edb93xx? rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] board/cirrus/edb93xx/edb93xx.c: "egpio" versus "epgio"?
possibly embarrassing myself here, but i just ran across this in
edb93xx.c, which looks ... weird, a mixture of "EGPIO" and "EPGIO"
toward the end of that source file:
... snip ...
int board_mmc_init(bd_t *bis)
{
struct gpio_regs *regs = (struct gpio_regs *)GPIO_BASE;
ep93xx_set_epgio(CONFIG_MMC_SPI_CS_EPGIO);
ep93xx_dir_epgio_out(CONFIG_MMC_SPI_CS_EPGIO);
#ifdef CONFIG_MMC_SPI_POWER_EGPIO
ep93xx_dir_epgio_out(CONFIG_MMC_SPI_POWER_EGPIO);
ep93xx_set_epgio(CONFIG_MMC_SPI_POWER_EGPIO);
#elif defined(CONFIG_MMC_SPI_NPOWER_EGPIO)
ep93xx_dir_epgio_out(CONFIG_MMC_SPI_NPOWER_EGPIO);
ep93xx_clear_epgio(CONFIG_MMC_SPI_NPOWER_EGPIO);
#endif
... snip ...
is it just me, or does anyone else find that odd? all occurrences of
the string "epgio" are entirely contained within that single source
file:
$ grep -ri EPGIO *
board/cirrus/edb93xx/edb93xx.c:static void ep93xx_set_epgio(unsigned num)
board/cirrus/edb93xx/edb93xx.c:static void ep93xx_clear_epgio(unsigned num)
board/cirrus/edb93xx/edb93xx.c:static void ep93xx_dir_epgio_out(unsigned num)
board/cirrus/edb93xx/edb93xx.c: ep93xx_clear_epgio(slave->cs);
board/cirrus/edb93xx/edb93xx.c: ep93xx_set_epgio(slave->cs);
board/cirrus/edb93xx/edb93xx.c:#ifndef CONFIG_MMC_SPI_CS_EPGIO
board/cirrus/edb93xx/edb93xx.c:# define CONFIG_MMC_SPI_CS_EPGIO 4
board/cirrus/edb93xx/edb93xx.c: ep93xx_set_epgio(CONFIG_MMC_SPI_CS_EPGIO);
board/cirrus/edb93xx/edb93xx.c: ep93xx_dir_epgio_out(CONFIG_MMC_SPI_CS_EPGIO);
board/cirrus/edb93xx/edb93xx.c:
ep93xx_dir_epgio_out(CONFIG_MMC_SPI_POWER_EGPIO);
board/cirrus/edb93xx/edb93xx.c: ep93xx_set_epgio(CONFIG_MMC_SPI_POWER_EGPIO);
board/cirrus/edb93xx/edb93xx.c:
ep93xx_dir_epgio_out(CONFIG_MMC_SPI_NPOWER_EGPIO);
board/cirrus/edb93xx/edb93xx.c: ep93xx_clear_epgio(CONFIG_MMC_SPI_NPOWER_EGPIO);
board/cirrus/edb93xx/edb93xx.c: struct mmc *mmc = mmc_spi_init(0,
CONFIG_MMC_SPI_CS_EPGIO,
$
am i just being an idiot in not knowing that that means?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] uImage load address and entry point with Minnowboard
On Fri, 24 Jun 2016, Wolfgang Denk wrote: > Dear Vinoth, > > In message > you > wrote: > > > > I am using the following command to create uImage. Here in the architecture > > argument I am not seeing any option corresponding to the Intel-x86_64. So I > > had used x86, which I am not sure is valid or not. The kernel is 64 bit. > > > > mkimage -A x86 -O linux -T kernel -C none -a 0x10 -e 0x0 -n Linux > > -d vmlinux-4.4.6-ina uImage > > Image Name: Linux > > Created: Fri Jun 24 10:35:40 2016 > > Image Type: Intel x86 Linux Kernel Image (uncompressed) > > Data Size:21966248 Bytes = 21451.41 kB = 20.95 MB > > Load Address: 0010 > > Entry Point: > > This makes no sense to me. When the kernel image is loaded to RAM > starting at address 0x0010, then ther eis no valid code at address > 0x. So 0x cannot be a valid entry oint address. The > entry point address must be somewhare in the range between "load > address" and "load address + size of uncompressed kernel image". > > > Error: Invalid Boot Flag (found 0x, expected 0xaa55) > > Setup at 0x00 > > Magic signature not found > > > > Is is I need to load setup.bin also? i'm sure i'm not adding much to this discussion, but 0xaa55 is the last two bytes of an MBR that identifies that 512-byte block as a legitimate master boot record, so *something* is looking for an MBR and not finding it. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "image.h: Tighten up content using handy CONFIG_IS_ENABLED() macro."
On Tue, 31 May 2016, Masahiro Yamada wrote: ... lengthy explanation snipped ... thanks for that explanation; clearly, i had no idea what i was getting into here and, again, i apologize for submitting a patch that was not even remotely close to correct. le *sigh*. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "image.h: Tighten up content using handy CONFIG_IS_ENABLED() macro."
On Tue, 31 May 2016, Masahiro Yamada wrote:
> This reverts commit 56adbb38727320375b2f695bd04600d766d8a1b3.
>
> Since commit 56adbb387273 ("image.h: Tighten up content using handy
> CONFIG_IS_ENABLED() macro."), I found my boards fail to boot Linux
> because the commit changed the logic of macros it touched. Now,
> IMAGE_ENABLE_RAMDISK_HIGH and IMAGE_BOOT_GET_CMDLINE are 0 for all
> the boards.
>
> As you can see in include/linux/kconfig.h, CONFIG_IS_ENABLE() (and
> IS_ENABLED() as well) can only take a macro that is either defined
> as 1 or undefined. This is met for boolean options defined in
> Kconfig. On the other hand, CONFIG_SYS_BOOT_RAMDISK_HIGH and
> CONFIG_SYS_BOOT_GET_CMDLINE are defined without any value in
> arch/*/include/asm/config.h . This kind of clean-up is welcome,
> but the options should be moved to Kconfig beforehand.
... snip ...
whoops, that would be my fault, i never considered that possibility,
i thought this was a fairly straightforward (and mostly aesthetic)
change.
it seems that there is a fair amount of inconsistent usage of CONFIG
settings, as in, if one wants to test only if a setting is defined:
#ifdef CONFIG_FOO
then it's sufficient to manually set:
#define CONFIG_FOO
however, in the above, it doesn't hurt to also write:
#define CONFIG_FOO 1
but the instant you do that, you can *also* then test:
#if CONFIG_FOO
and i'm wondering how much there is of mixing both tests; that is,
once you write this:
#define CONFIG_FOO 1
you have a tendency to start using both tests:
#ifdef CONFIG_FOO
#if CONFIG_FOO
which is definitely messy. anyway, my fault for not looking at the
above carefully enough before submitting.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Remove unneeded remnants of bcopy().
Since bcopy() is no longer used, delete all remaining references to
it.
Signed-off-by: Robert P. J. Day
---
diff --git a/arch/microblaze/include/asm/string.h
b/arch/microblaze/include/asm/string.h
index 724f5bd..8f67ec7 100644
--- a/arch/microblaze/include/asm/string.h
+++ b/arch/microblaze/include/asm/string.h
@@ -17,13 +17,11 @@
#define __MICROBLAZE_STRING_H__
#if 0
-#define __HAVE_ARCH_BCOPY
#define __HAVE_ARCH_MEMCPY
#define __HAVE_ARCH_MEMSET
#define __HAVE_ARCH_MEMMOVE
extern void *memcpy (void *, const void *, __kernel_size_t);
-extern void bcopy (const char *, char *, int);
extern void *memset (void *, int, __kernel_size_t);
extern void *memmove (void *, const void *, __kernel_size_t);
#endif
diff --git a/arch/powerpc/lib/ppcstring.S b/arch/powerpc/lib/ppcstring.S
index 8152ac9..56bb3b8 100644
--- a/arch/powerpc/lib/ppcstring.S
+++ b/arch/powerpc/lib/ppcstring.S
@@ -92,13 +92,6 @@ memset:
bdnz8b
blr
- .globl bcopy
-bcopy:
- mr r6,r3
- mr r3,r4
- mr r4,r6
- b memcpy
-
.globl memmove
memmove:
cmplw 0,r3,r4
diff --git a/include/linux/string.h b/include/linux/string.h
index c7047ba..091ccab 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -20,10 +20,6 @@ extern __kernel_size_t strspn(const char *,const char *);
*/
#include
-#ifndef __HAVE_ARCH_BCOPY
-char *bcopy(const char *src, char *dest, int count);
-#endif
-
#ifndef __HAVE_ARCH_STRCPY
extern char * strcpy(char *,const char *);
#endif
diff --git a/lib/string.c b/lib/string.c
index 87c9a40..67d5f6a 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -461,30 +461,6 @@ void * memset(void * s,int c,size_t count)
}
#endif
-#ifndef __HAVE_ARCH_BCOPY
-/**
- * bcopy - Copy one area of memory to another
- * @src: Where to copy from
- * @dest: Where to copy to
- * @count: The size of the area.
- *
- * Note that this is the same as memcpy(), with the arguments reversed.
- * memcpy() is the standard, bcopy() is a legacy BSD function.
- *
- * You should not use this function to access IO space, use memcpy_toio()
- * or memcpy_fromio() instead.
- */
-char * bcopy(const char * src, char * dest, int count)
-{
- char *tmp = dest;
-
- while (count--)
- *tmp++ = *src++;
-
- return dest;
-}
-#endif
-
#ifndef __HAVE_ARCH_MEMCPY
/**
* memcpy - Copy one area of memory to another
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Remove remaining remnants of unused "bcopy".
On Mon, 30 May 2016, Michal Simek wrote: > Hi, > > 2016-05-29 11:36 GMT+02:00 Robert P. J. Day : > $ git diff --stat > arch/microblaze/include/asm/string.h | 2 -- > arch/powerpc/lib/ppcstring.S | 7 --- > include/linux/string.h | 4 > lib/string.c | 24 > 4 files changed, 37 deletions(-) > $ > > > Commit message is pretty weird. Just write there why you are doing it. > > Anyway for microblaze part here is my > Acked-by: Michal Simek > if you fix that commit message. ok, i'll resubmit a v2 shortly. rday -- ================ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] can the last traces of "bcopy" be removed?
On Mon, 23 May 2016, Michal Simek wrote: > Hi, > > 2016-05-22 20:54 GMT+02:00 Robert P. J. Day : > > just noticed that this is all that's left of "bcopy": > > $ grep -rw bcopy * > arch/powerpc/lib/ppcstring.S: .globl bcopy > arch/powerpc/lib/ppcstring.S:bcopy: > arch/microblaze/include/asm/string.h:extern void bcopy (const char *, > char *, int); > include/linux/string.h:char *bcopy(const char *src, char *dest, int > count); > lib/string.c: * bcopy - Copy one area of memory to another > lib/string.c: * memcpy() is the standard, bcopy() is a legacy BSD > function. > lib/string.c:char * bcopy(const char * src, char * dest, int count) > $ > > No problem to remove it. Please send the patch. done, also noticed that that entire microblaze string.h file could possibly have been tossed: #ifndef __MICROBLAZE_STRING_H__ #define __MICROBLAZE_STRING_H__ #if 0 #define __HAVE_ARCH_BCOPY #define __HAVE_ARCH_MEMCPY #define __HAVE_ARCH_MEMSET #define __HAVE_ARCH_MEMMOVE extern void *memcpy (void *, const void *, __kernel_size_t); extern void bcopy (const char *, char *, int); extern void *memset (void *, int, __kernel_size_t); extern void *memmove (void *, const void *, __kernel_size_t); #endif #endif /* __MICROBLAZE_STRING_H__ */ but i'll leave that in your capable hands, feel free to hack my patch to do that. rday -- ============ Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Remove remaining remnants of unused "bcopy".
$ git diff --stat
arch/microblaze/include/asm/string.h | 2 --
arch/powerpc/lib/ppcstring.S | 7 ---
include/linux/string.h | 4
lib/string.c | 24
4 files changed, 37 deletions(-)
$
Signed-off-by: Robert P. J. Day
---
diff --git a/arch/microblaze/include/asm/string.h
b/arch/microblaze/include/asm/string.h
index 724f5bd..8f67ec7 100644
--- a/arch/microblaze/include/asm/string.h
+++ b/arch/microblaze/include/asm/string.h
@@ -17,13 +17,11 @@
#define __MICROBLAZE_STRING_H__
#if 0
-#define __HAVE_ARCH_BCOPY
#define __HAVE_ARCH_MEMCPY
#define __HAVE_ARCH_MEMSET
#define __HAVE_ARCH_MEMMOVE
extern void *memcpy (void *, const void *, __kernel_size_t);
-extern void bcopy (const char *, char *, int);
extern void *memset (void *, int, __kernel_size_t);
extern void *memmove (void *, const void *, __kernel_size_t);
#endif
diff --git a/arch/powerpc/lib/ppcstring.S b/arch/powerpc/lib/ppcstring.S
index 8152ac9..56bb3b8 100644
--- a/arch/powerpc/lib/ppcstring.S
+++ b/arch/powerpc/lib/ppcstring.S
@@ -92,13 +92,6 @@ memset:
bdnz8b
blr
- .globl bcopy
-bcopy:
- mr r6,r3
- mr r3,r4
- mr r4,r6
- b memcpy
-
.globl memmove
memmove:
cmplw 0,r3,r4
diff --git a/include/linux/string.h b/include/linux/string.h
index c7047ba..091ccab 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -20,10 +20,6 @@ extern __kernel_size_t strspn(const char *,const char *);
*/
#include
-#ifndef __HAVE_ARCH_BCOPY
-char *bcopy(const char *src, char *dest, int count);
-#endif
-
#ifndef __HAVE_ARCH_STRCPY
extern char * strcpy(char *,const char *);
#endif
diff --git a/lib/string.c b/lib/string.c
index 87c9a40..67d5f6a 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -461,30 +461,6 @@ void * memset(void * s,int c,size_t count)
}
#endif
-#ifndef __HAVE_ARCH_BCOPY
-/**
- * bcopy - Copy one area of memory to another
- * @src: Where to copy from
- * @dest: Where to copy to
- * @count: The size of the area.
- *
- * Note that this is the same as memcpy(), with the arguments reversed.
- * memcpy() is the standard, bcopy() is a legacy BSD function.
- *
- * You should not use this function to access IO space, use memcpy_toio()
- * or memcpy_fromio() instead.
- */
-char * bcopy(const char * src, char * dest, int count)
-{
- char *tmp = dest;
-
- while (count--)
- *tmp++ = *src++;
-
- return dest;
-}
-#endif
-
#ifndef __HAVE_ARCH_MEMCPY
/**
* memcpy - Copy one area of memory to another
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] wanting to confirm i'm setting the MAC address the right way
On Wed, 25 May 2016, Bin Meng wrote:
> On Wed, May 25, 2016 at 12:31 AM, Robert P. J. Day
> wrote:
> >
> > i want to use the fdt_fixup_ethernet() routine to automate most
> > of the work of setting the MAC address in the FDT before passing
> > it to the kernel, so here's what i'm about to do, and i'd
> > appreciate someone saying, "yup, looks good" if it will indeed
> > work.
> >
> > on either a MPC8280 or MPC8360 system, i will first set up the
> > DTS file with some variation of:
>
> To make it clear, the DTS file is the Linux kernel's, not U-Boot's.
right, i knew that, should have been clearer.
> > aliases {
> > ethernet0 = &ucc0;
> > };
> >
> > ... snip ...
> >
> > ucc0:ucc@2000 {
> > device_type = "network";
> > compatible = "ucc_geth";
> > model = "UCC";
> > device-id = <1>;
> > reg = <0x2000 0x200>;
> > interrupts = <0x20>;
> > local-mac-address = [ 00 01 02 03 04 05 ];
>
> Make it all 00s
point taken, as i see numerous other examples which also add a
comment "Filled in by U-Boot", which never hurts.
... snip ...
> > is that about it? it *looks* like all i have to do, and
> > fdt_fixup_etherhet() will do all the rest.
>
> yup, looks good :)
thanks.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] wanting to confirm i'm setting the MAC address the right way
i want to use the fdt_fixup_ethernet() routine to automate most of
the work of setting the MAC address in the FDT before passing it to
the kernel, so here's what i'm about to do, and i'd appreciate someone
saying, "yup, looks good" if it will indeed work.
on either a MPC8280 or MPC8360 system, i will first set up the DTS
file with some variation of:
aliases {
ethernet0 = &ucc0;
};
... snip ...
ucc0:ucc@2000 {
device_type = "network";
compatible = "ucc_geth";
model = "UCC";
device-id = <1>;
reg = <0x2000 0x200>;
interrupts = <0x20>;
local-mac-address = [ 00 01 02 03 04 05 ];
rx-clock = <0x1c>; // CLK12
tx-clock = <0x1b>; // CLK11
phy-handle = <&PHY0>;
};
at that point, given all the work done in fdt_fixup_ethernet(), i
*think* that all i need to do in the board's ft_board_setup() routine
is:
eth_setenv_enetaddr("ethaddr", );
is that about it? it *looks* like all i have to do, and
fdt_fixup_etherhet() will do all the rest.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] why does fdt_fixup_ethernet() need to worry about an edited FDT?
looking at the code for fdt_fixup_ethernet() in fdt_support.c, and
i'm puzzled by the extra work being done ostensibly to take an
"edited" FDT into account:
void fdt_fixup_ethernet(void *fdt)
{
int i, j, prop;
char *tmp, *end;
char mac[16];
const char *path;
unsigned char mac_addr[6];
int offset;
if (fdt_path_offset(fdt, "/aliases") < 0)
return;
/* Cycle through all aliases */
for (prop = 0; ; prop++) {
const char *name;
int len = strlen("ethernet");
/* FDT might have been edited, recompute the offset */
offset = fdt_first_property_offset(fdt,
fdt_path_offset(fdt, "/aliases"));
/* Select property number 'prop' */
for (i = 0; i < prop; i++)
offset = fdt_next_property_offset(fdt, offset);
... snip ...
why is it that *this* routine has to worry about an edited FDT, but
nothing else i see in that entire source file has to? as a (hopefully)
relevant example:
#if defined(OF_STDOUT_PATH)
static int fdt_fixup_stdout(void *fdt, int chosenoff)
{
return fdt_setprop(fdt, chosenoff, "linux,stdout-path",
OF_STDOUT_PATH, strlen(OF_STDOUT_PATH) + 1);
}
that routine simply calls fdt_setprop() ... what is it about
fdt_fixup_ethernet() that needs to take extra care compared to every
other function in that file?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
