short form: is there an efficient way to add a new vendor and new
zynqmp-based board to the u-boot infrastructure without creating a
whole new vendor directory that (mostly) duplicates what is already
under board/xilinx/?
as i read it, if i configure u-boot for, say, a xilinx zynqmp-based
ZC
Various (mostly minor) spelling, grammar and punctuation tweaks for
arch/arm/Kconfig.
Signed-off-by: Robert P. J. Day
---
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f9dab073ea..36c9c2fecd 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -17,7 +17,7 @@ config
just tried to build docs on a fully-updated fedora 31 system, and
got:
$ make htmldocs
SPHINX htmldocs --> file:///home/rpjday/uboot/git/doc/output
make[2]: Nothing to be done for 'html'.
Running Sphinx v2.1.2
Extension error:
Could not import extension kerneldoc (exception: cannot import
long story short, colleague came to me with a petalinux project
wherein the compile of u-boot was failing due to a redefinition of the
macro "CONFIG_PANIC_HANG" ... rather than mess with petalinux, i just
set up the current master of u-boot (aarch64), used the same
configuration and, sure enoug
On Fri, 13 Dec 2019, Michal Simek wrote:
> On 13. 12. 19 15:05, Robert P. J. Day wrote:
> >
> > been a while since i wandered through the innards of u-boot so it's
> > possible this is a silly question.
> >
> > was just placed on a project that involve
#x27;m overlooking here?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
On Tue, 20 Aug 2019, Stephen Segal wrote:
> Hi all,
>
> I'm not sure if this has been noticed or handled already, but it appears
> there are two separate config options named CONFIG_OPTEE.
>
> In drivers/tee/optee/Kconfig:
>
> config OPTEE
> bool "OP-TEE"
> depends on ARM_SMCCC
>
rd compatibility)
%_config: %_defconfig
@:
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
Linke
A couple minor tweaks to printed strings in cmd/fpga.c.
Signed-off-by: Robert P. J. Day
---
diff --git a/cmd/fpga.c b/cmd/fpga.c
index b1f224bc6a..62453f0a8f 100644
--- a/cmd/fpga.c
+++ b/cmd/fpga.c
@@ -458,7 +458,7 @@ U_BOOT_CMD(fpga, 6, 1, do_fpga_wrapper,
"0-device key, 1
was going over README.kconfig and noticed these references:
$ grep -r autoconfig.mk *
doc/README.kconfig: - spl/include/autoconfig.mk(generated by the old
config for SPL)
doc/README.kconfig: - tpl/include/autoconfig.mk(generated by the old
config for TPL)
doc/README.kconfig:
FIG_NAME
default "ecovec"
which suggests that header file would have been included anyway.
thoughts?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
On Tue, 23 Apr 2019, Michal Simek wrote:
> On 19. 04. 19 13:27, Robert P. J. Day wrote:
> >
> > just noticed the oddness regarding those two Kbuild symbols:
> >
> > $ git grep ARM_DCC
> > arch/x86/include/asm/acpi_table.h:#define ACPI_
On Tue, 23 Apr 2019, Michal Simek wrote:
> On 20. 04. 19 12:44, Robert P. J. Day wrote:
> >
> > i've asked on the meta-xilinx mailing list, and rummaged around the
> > net, and have failed to do something that should be straightforward --
> > i want to simply bo
ard, i would be eternally grateful,
because i'm running out of ideas.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://cra
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
going over the u-boot.cfg generated from zynq_zed_defconfig, and
noticed the following:
#define CONFIG_OPTEE_TZDRAM_BASE 0x
#define CONFIG_OPTEE_TZDRAM_SIZE 0x000
i thought that was strange as CONFIG_OPTEE was not selected, so i
checked, and here's the relevant snippet from lib
This Kbuild option disappeared way back in 2014:
commit 75504e9592745021006cb8905b5ff5a51d9d1cb3
Author: Mateusz Zalega
Date: Wed Apr 30 13:07:48 2014 +0200
... snip ...
CONFIG_USB_CABLE_CHECK was removed.
Signed-off-by: Robert P. J. Day
---
diff --git a/include/configs
pose in
-different parts of the (ARM) code.
-Furthermore, the startup code (cpu//start.S) internally uses
-another variable (_TEXT_BASE) with the same content as _armboot_start.
-I agree that this mess should be cleaned up.
--
===============
bool "Luton SOC Family"
select SOC_VCOREIII
- select MSCC_BITBANG_SPI_GPIO
help
This supports MSCC Luton family of SOCs.
--
================
Robert P. J. Day Ott
iced a couple others that seem way out
of date.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter:
On Sun, 14 Apr 2019, Marek Vasut wrote:
> On 4/14/19 12:51 PM, Robert P. J. Day wrote:
> > On Sun, 14 Apr 2019, Marek Vasut wrote:
> >
> >> On 4/14/19 12:06 PM, Robert P. J. Day wrote:
> >>>
> >>> Kbuild "select" directives should not inc
On Sun, 14 Apr 2019, Marek Vasut wrote:
> On 4/14/19 12:06 PM, Robert P. J. Day wrote:
> >
> > Kbuild "select" directives should not include "CONFIG_" prefix.
> >
> > Signed-off-by: Robert P. J. Day
>
> The patch is correct, but does it h
On Fri, 12 Apr 2019, Robert P. J. Day wrote:
> rather than go to the trouble of whipping up a wiki page, i can
> present this in a short post to the list. here's the list of what my
> script identified as "badref selects" -- those identifiers for which
> there is
SPL
endchoice
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn:
Kbuild "select" directives should not include "CONFIG_" prefix.
Signed-off-by: Robert P. J. Day
---
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index ba1e6bfa43..96474f4e3b 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -20
n them on whatever part of the code base
amuses them. thanks for your patience.
rday
--
====
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http:/
nd* stuff like that,
but i'm nowhere confident that i'd know how to resolve it once it's
found.
one last cleanup post coming shortly ...
rday
--
================
Robert P. J. Day
RC32
support */
in any event, others are welcome to decide what to do about that short
list of suspicious "select" directives. i am not trying to be
annoying, i am merely succeeding.
rday
--
Ro
On Sat, 13 Apr 2019, Chris Packham wrote:
>
> On Sat, 13 Apr 2019, 4:56 AM Robert P. J. Day, wrote:
> one of the worst culprits appears to be CONFIG_SPL_BUILD, which
> appears all over the tree, but one can see a recent commit that takes
> that into account:
&
Kbuild "select" directive should not use "CONFIG_" prefix.
Signed-off-by: Robert P. J. Day
---
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 34e78beb2a..a89cc6edec 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -14
;>> DM644X_GPIO
./drivers/gpio/Makefile:obj-$(CONFIG_DM644X_GPIO) += da8xx_gpio.o
$
if anyone's interested, i can post those scripts on a couple more
wiki pages this weekend, with an example or two. and on that note, i
will shut up about this now.
rday
--
==
e code base for
which they are a maintainer, and see if any such things exist. and as
forrest gump once said, "that's all i have to say about that."
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
ist.
rday
--
========
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com
On Fri, 12 Apr 2019, Robert P. J. Day wrote:
> On Fri, 12 Apr 2019, Simon Glass wrote:
>
> > Hi Robert,
> >
> > On Fri, 12 Apr 2019 at 06:31, Robert P. J. Day
> > wrote:
> > >
> > >
> > > was tracing the ARM-based boo
On Fri, 12 Apr 2019, Simon Glass wrote:
> Hi Robert,
>
> On Fri, 12 Apr 2019 at 06:31, Robert P. J. Day wrote:
> >
> >
> > was tracing the ARM-based boot sequence and ended up at the call to
> > board_init_r():
> >
> > vo
gument being passed to
board_init_r()?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter:
On Wed, 10 Apr 2019, Andy Pont wrote:
> Robert wrote...
>
> > i'd never thought about it so, as a quick check, i just tried this
> >to see how many board files actually lived directly under
> >board// and got:
> >
> > $ ls board/*/board.c
> > board/sunxi/board.c
> > $
> >
> >i thought that
r??), at which point is there any need to support
vendorless boards?
or perhaps i am just misreading what i'm looking at. it's just a
curiosity i had no answer for when asked about.
rday
--
================
Ro
On Wed, 10 Apr 2019, Michal Simek wrote:
> On 09. 04. 19 13:00, Robert P. J. Day wrote:
> >
> > i'm rewriting a bunch of u-boot tutorial pages (publicly available
> > if anyone wants to read them),
>
> Would be easier to put link here that others can take a
more excruciatingly pedantic queries ... what is the best practice
for header files under include/configs including common header files
also in that same directory. i give you:
$ git grep zynq-common.h
bitmain_antminer_s9.h:#include
syzygy_hub.h: * See zynq-common.h for Zynq common configs
syz
i'm rewriting a bunch of u-boot tutorial pages (publicly available
if anyone wants to read them), and i want to clarify the proper
location to put configuration content -- a defconfig file versus a
header file -- knowing that the trend lately has been to move content
into defconfig files where a
ignore file:
embedded.c
fw_printenv
fw_printenv_unstripped
it is obviously not removed by "make distclean". is this deliberate?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
On Mon, 8 Apr 2019, Chris Packham wrote:
> Hi Robert,
>
> On Mon, Apr 8, 2019 at 4:51 AM Robert P. J. Day wrote:
> >
> >
> > short followup to earlier question ... i was going to check the file
> > .u-boot.map.cmd to see which command was used to generate
On Mon, 8 Apr 2019, Chris Packham wrote:
> On Mon, Apr 8, 2019 at 7:45 PM Chris Packham wrote:
> >
> > On Mon, Apr 8, 2019 at 4:29 AM Robert P. J. Day
> > wrote:
> > >
> > >
> > > i'm doing this in the context of building for ARM with a li
On Mon, 8 Apr 2019, Chris Packham wrote:
> Hi Robert,
>
> On Mon, Apr 8, 2019 at 4:51 AM Robert P. J. Day wrote:
> >
> >
> > short followup to earlier question ... i was going to check the file
> > .u-boot.map.cmd to see which command was used to generate
short followup to earlier question ... i was going to check the file
.u-boot.map.cmd to see which command was used to generate it but,
unlike numerous other files of that form, that file has no associated
.cmd file. any reason for that?
rday
___
U-Bo
i'm doing this in the context of building for ARM with a linaro
toolchain, but i'm sure it's equally valid in the context of a native
build.
i'm trying to generate the same output as u-boot.map, but more
condensed and with each symbol associated with its original source
file (if that's even p
s and so on to come up with the final .config.
if someone already did that once upon a time, that'd be great, but
i'm going to guess i'm on my own here. thoughts?
rday
--
================
Robert P. J. Day
Ensure that "make distclean" deletes an existing CHANGELOG file.
Signed-off-by: Robert P. J. Day
---
diff --git a/Makefile b/Makefile
index 3be9fc5c34..b9e8b0952c 100644
--- a/Makefile
+++ b/Makefile
@@ -1795,7 +1795,7 @@ distclean: mrproper
-o -name '.*.rej&#x
it's correct.
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca/dokuwiki
Twitter: http://twitter.com/rpjday
LinkedIn: http://
implemented.
*/
so should the comment be changed to refer to both x86 and arc, or is
there a long-term plan for all archs, or what?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
quot;config" definition for it
anywhere (not sure whether being in the whitelist.txt file means
anything relative to that). and so on, and so on.
i can see the OP's FPGA_LATTICE in my output:
>>>>> FPGA_LATTICE
drivers/fpga/Makefile:13:obj-$(CONFIG_FPGA_LATTICE) += ivm_co
clever things." - Doug Gwyn
yup, i eventually found that README.update file, this behaviour is
just fine for what i'm doing, thanks.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://cra
t.bin da3
sb save hostfs 0 14 /tmp/tmp7Cs2dr/loadables2-out.bin 11ef
reset
':
$
i could have sworn that, once upon a time, there was more output
than this. am i misremembering? is this what i should expect?
rday
--
=
an #error message saying that what seems
to be true is exactly what is "needed."
am i just misreading that?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
r
noticed that before.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http
ed routines to those
hostprogs, regardless of whether FIT support is selected? can someone
clarify this?
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
On Fri, 17 Mar 2017, Tom Rini wrote:
> On Wed, Mar 15, 2017 at 04:02:20AM -0400, Robert P. J. Day wrote:
> >
> > to build cross_tools, i ran:
> >
> > $ make sandbox_defconfig
> > $ make cross_tools
> >
> > and while it appeared to work, i got:
&
mage/test-fit.py", line 470, in run_tests
run_fit_test(mkimage, options.u_boot)
File "./test/image/test-fit.py", line 395, in run_fit_test
line = find_matching(stdout, 'Booting using the FDT blob at ')
File "./test/image/test-fit.py", line
s/.gitignore, which i will leave to someone higher up the food
chain.
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjd
env.h:12,
from :0:
/usr/include/features.h:166:0: note: this is the location of the previous
definition
# define _XOPEN_SOURCE 700
^
not sure if that concerns anyone enough to want to tweak it.
rday
--
=============
* Add note that execution needs Python development package installed
* Standardize on upper case "FIT", "FDT" as necessary for clarity
* Fix "tempoerary", "linex" typos
Signed-off-by: Robert P. J. Day
---
diff --git a/test/image/test-fit.py b/test/
Signed-off-by: Robert P. J. Day
---
am i safe in assuming that the top-level sandbox/ directory only
ever exists as the result of a build?
diff --git a/.gitignore b/.gitignore
index 7fac5b3..32a8d5b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -48,6 +48,7 @@
/LOG
/spl/
/tpl/
+/sandbox
Signed-off-by: Robert P. J. Day
---
Since it's just inline doc, should have no runtime effects.
diff --git a/drivers/gpio/db8500_gpio.c b/drivers/gpio/db8500_gpio.c
index db32db6..eefb56d 100644
--- a/drivers/gpio/db8500_gpio.c
+++ b/drivers/gpio/db8500_gpio.c
@@ -174,7 +174,7 @@
but, still, how is that name resolved to the corresponding error
message? what am i missing here?
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
Signed-off-by: Robert P. J. Day
---
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index a4cbc44..3c0696e 100644
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -1968,7 +1968,7 @@ static void *video_logo(void)
static int cfb_fb_is_in_dram(void
wiki/index.php/U-Boot_Kconfig_cleanup
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
L
IG_YAFFS2 -DNO_Y_INLINE \
anyway, that's it for today ... feel free to peruse that new list to
see what parts of Makefiles seem to not be compiled.
rday
--
Robert P. J. Day
bi/ubi.h:#ifdef CONFIG_MTD_UBI_BLOCK
include/ubi_uboot.h:#undef CONFIG_MTD_UBI_BLOCK
scripts/config_whitelist.txt:CONFIG_MTD_UBI_BLOCK
$
anyway, there's plenty of that sort of thing scattered through the
code base.
rday
--
=============
7;t offering to fix all this stuff. :-)
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
to it.
i have a second script that identified the opposite -- Kconfig
variables that *are* being tested but do not seem to be defined in any
Kconfig file, normally a more serious issue.
--
====
Robert P. J. Day
xp/mod_exp_uclass.c:.id =
UCLASS_MOD_EXP,
include/dm/uclass-id.h: UCLASS_MOD_EXP, /* RSA Mod Exp device */
lib/rsa/rsa-verify.c: ret = uclass_get_device(UCLASS_MOD_EXP, 0,
&mod_exp_dev);
$
there appears to be quite a lot of stuff like this.
rday
--
==
in that case, it would seem
inappropriate to have used that name for that variable, since it gives
the impression of being part of the Kbuild structure. i'm not
suggesting changing any of that (or maybe i am :-), it just seems
silly that using that name causes that variable to end up in the
wh
ely possible the above is entirely
correct, it just looks a bit weird.
in any event, that Kconfig file could still be refactored to avoid
new entries popping up in arbitrary places depending on what you
select or deselect.
thoughts?
rday
--
============
OTSTAGE to be selected
first?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn:
Some refactoring of the top-level Kconfig file which includes:
* using "if" to remove numerous identical dependency tests
* reordering config entries to group related ones
* spelling and grammar fixes
There should be no functional changes, only aesthetic ones.
Signed-off-by: Robert
people can see
what i'm talking about.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn:
umber of levels:
* entire architecture
* CPU
* target board
is there a recipe for how driver model is slowly added to u-boot,
based on updating Kconfig files for the above?
more questions coming as i keep reading ...
rday
--
=
ch only a single board
overrides that routine? or is there something else here i'm
overlooking?
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
f that variable is set, a further test is made of the
environment variable "flashchecksum."
is there still value to this CONFIG variable given that only a
half-dozen boards define it? am i overlooking something obvious?
rday
--
==============
erpc MPC8240309a292 2011-12-07
and i'm not sure anything needs that second test either, does it? can
that entire first preprocessor test be deleted? or am i missing
something?
rday
--
============
First, update the code snippet referenced in the README file. And
since there are only two boards that override flash_cmd_reset(),
might as well show them both.
Signed-off-by: Robert P. J. Day
---
figured since i was there, and there were only two boards in the
entire code base that defined
Signed-off-by: Robert P. J. Day
---
diff --git a/board/intercontrol/digsy_mtc/digsy_mtc.c
b/board/intercontrol/digsy_mtc/digsy_mtc.c
index 37eb6c7..05d673d 100644
--- a/board/intercontrol/digsy_mtc/digsy_mtc.c
+++ b/board/intercontrol/digsy_mtc/digsy_mtc.c
@@ -41,7 +41,7 @@ extern int
Minor update in code snippet in the doc file to match source.
Signed-off-by: Robert P. J. Day
---
diff --git a/doc/README.cfi b/doc/README.cfi
index 81e7cf1..6b8be41 100644
--- a/doc/README.cfi
+++ b/doc/README.cfi
@@ -1,7 +1,7 @@
The common CFI driver provides this weak default
].Device.area_list[j].protected =
protected;
}
is that not just setting the value to "protected" in both cases? what
is the point of that conditional?
rday
--
========
Robert P. J. Day
7;m poring over that file, i can
collect any other tweaks anyone else wants to suggest to make it worth
it. any other content in that file that needs updating or removal?
no rush.
rday
--
========
Robert
to do is extend
ft_board_setup() to set the env variable:
eth_setenv_enetaddr("ethaddr", );
is that what you'd call "best practice"?
rday
--
================
Robert P. J. Day Ottawa, Onta
there a coding standard in
cases where a macro invocation doesn't need a terminating semi-colon?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter:
}
... snip ...
i'm going to assume other net-related commands have this behaviour
as well, yes? like ping? which would explain why ping'ing even the
alleged gateway didn't work in this context.
rday
--
==
;
> e->callback = NULL;
>
> here?
that would be one solution, yes. i assume i would, of course, set
that callback before adding the entry to the hashtable; otherwise,
wouldn't do much good.
ok, i think we've settled this, thanks.
rday
--
=
he "env_htab" hashtable?
int
add_entry_to_env(ENTRY* e)
{
ENTRY* ep;
printf("Adding stuff k: [%s], d: [%s] to env.\n", e->key, e->data);
hsearch_r(*e, ENTER, &ep, &env_htab, 0);
return 0;
}
if that's the way to do it,
hat told me explicitly
that i *could* have additional hashtables; i just assumed, hey, it's
just another data structure, it has some useful functionality, i'll
just create another couple of them to save me some coding.
i *did* try to verify that there was no shared data; things like
mak
om one hashtable can
"bleed" into another one? i'm baffled.
rday
--
================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter:
nd example is also not defined by the Kbuild
system, is it somehow more acceptable because it begins with
"CONFIG_SYS_"? i'm having trouble appreciating the distinction.
rday
--
Robert P. J. Day
is (re)defining some GPIO-related flags ... is
there some reason it doesn't just use the flag definitions from the
earlier header file? or is that a silly question?
rday
--
================
Robert P. J. Day
or
later.
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedi
mp;env_htab, 0);
seems straightforward enough, just want to confirm i'm not overlooking
anything.
rday
--
============
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcou
;t
> > himport_r() properly handle that given a separator of space?
>
> Well, yes, but it sounds a bit fragile to me. Experience tells me
> that very soon someone _will_ use a space in a variable.
in this case, no ... it's legacy info that will never, ever change
trings being "imported" have no embedded space
characters in their values. so as long as that's the case, shouldn't
himport_r() properly handle that given a separator of space?
rday
--
=========
at's never called. i suspect
there's a lot of that with other routines as well.
or is there something else going on here more subtle that i don't
understand?
rday
--
============
Robert P. J. Day
1 - 100 of 461 matches
Mail list logo
