On 31/01/2022 09:19, Masami Hiramatsu wrote:
Add a config option to reset system soon after processing capsule update
on disk. This is required in UEFI specification 2.9 Section 8.5.5
"Delivery of Capsules via file on Mass Storage device" as;
In all cases that a capsule is identified for
7;make savedefconfig' looks _nothing_
like the starting vendors_defconfig. The new defconfig generates the
same .config file as the vendors_defconfig file. But the
vendors_defconfig file is arranged completely differently with
different/extra comments, extra blank lines, etc.
--
Grant
On 2022-01-25, Grant Edwards wrote:
> I'm working on a Renesas supplied port of U-Boot, and it seems that
> 'make' always compiles every single (configured) source file instead
> compiling only the source files that have been changed since the
> previous 'ma
that use
'make', and it makes development of U-Boot rather grueling.
Is that due to something Renesas broke?
Or is that a "feature" of the standard U-Boot Makefile?
--
Grant
On Tue, Nov 9, 2021 at 5:55 PM Tom Rini wrote:
>
> On Tue, Nov 09, 2021 at 11:19:01AM +0100, Heinrich Schuchardt wrote:
>
> > The UEFI specification requires for ExitBootServices() that "the boot
> > services watchdog timer is disabled". We already disable the software
> > watchdog. We should addi
ver or whether that
would work (because of a missing firmware table).
But it indeed sounds like a rather generic problem, and there might
indeed
be a solution generic enough for UEFI.
Do you have anything in mind?
Cheers,
Andre
Hello Grant, hello Ozog,
according to the UEFI spec the watchd
The missing trailing newline could confuse check-config.sh if the
definition of an option was on the first line of the next file that
find(1) happened to return.
Signed-off-by: William Grant
---
arch/arm/mach-stm32mp/cmd_stm32prog/Kconfig | 3 +--
1 file changed, 1 insertion(+), 2 deletions
On Wed, Aug 11, 2021 at 1:58 PM Simon Glass wrote:
>
> Hi Grant,
>
> On Wed, 11 Aug 2021 at 03:58, Grant Likely wrote:
> >
> > On Mon, Aug 9, 2021 at 8:11 PM Tom Rini wrote:
> > >
> > > On Sat, Aug 07, 2021 at 04:23:36PM -0600, Simon Glass wrote:
>
On Mon, Aug 9, 2021 at 8:11 PM Tom Rini wrote:
>
> On Sat, Aug 07, 2021 at 04:23:36PM -0600, Simon Glass wrote:
> > Comments welcome!
>
> I think what this is really showing is that Yamada-san was right. All
> the games we need to do so that "make fooboard_config all" results in
> building the N
On Wed, Apr 7, 2021 at 8:32 AM Icenowy Zheng wrote:
>
>
>
> 于 2021年4月7日 GMT+08:00 下午3:28:53, Frank Wang 写到:
> >Hi,
> >
> >
> >On 2021/4/7 14:43, Icenowy Zheng wrote:
> >>
> >> 于 2021年4月7日 GMT+08:00 下午2:42:34, Frank Wang
> > 写到:
> >>> Hi Icenowy Zheng,
> >>>
> >>> In my view, it is better to imple
On 29/03/2021 08:42, Simon Glass wrote:
> Hi Raghu,
>
> On Sat, 27 Mar 2021 at 03:59, wrote:
>
>> Julius, Simon,
>>
>>
>>
>> It appears there are opinions you carry around UUID being complicated,
>> bloated, code being an eyesore, parsing these lists early with
MMU/Caches
>> disabled, calculat
> the 'sntp' to update the RTC with the time from a network time server.
> See CONFIG_CMD_SNTP and CONFIG_BOOTP_NTPSERVER. The RTC time is
> advanced according to CPU ticks.
>
> Signed-off-by: Heinrich Schuchardt
Looks good to me, and tested on RockPro64 w/ UEFI
On 06/10/2020 13:52, Heinrich Schuchardt wrote:
On 06.10.20 14:43, Grant Likely wrote:
Current U-Boot by default uses the same DT image for both U-Boot
internal setup and to provide to the OS. This should be split so that
the U-Boot internal version has what U-Boot needs without needs to
On 06/10/2020 13:41, Ilias Apalodimas wrote:
Hi Grant,
[...]
Hi Heinrich,
I've got concerns about this approach. Even though it uses the UEFI
infrastructure, images deployed in this way are U-Boot specific and
won't ever be applicable on EDK2 or other UEFI implementations.
How
On 06/10/2020 13:36, Heinrich Schuchardt wrote:
On 06.10.20 14:04, François Ozog wrote:
As always, Ard made a good point, and I feel compelled to top post and
restate stuff.
Here is the supporting deck:
https://docs.google.com/presentation/d/1JK00su6e7vt8lRfwSt2C9EuuzwcBHLyoLRRrdcYfVWY/edit?
On 06/10/2020 13:04, François Ozog wrote:
As always, Ard made a good point, and I feel compelled to top post and
restate stuff.
Here is the supporting deck:
https://docs.google.com/presentation/d/1JK00su6e7vt8lRfwSt2C9EuuzwcBHLyoLRRrdcYfVWY/edit?usp=sharing
We have two boot flows under cons
On 06/10/2020 05:35, Heinrich Schuchardt wrote:
Am 6. Oktober 2020 00:37:58 MESZ schrieb Grant Likely :
On 03/10/2020 09:51, Heinrich Schuchardt wrote:
Hello Ilias, hello Christian,
with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for
initramfs
loading") Ilias pr
On 03/10/2020 09:51, Heinrich Schuchardt wrote:
Hello Ilias, hello Christian,
with commit ec80b4735a59 ("efi_loader: Implement FileLoad2 for initramfs
loading") Ilias provided the possibility to specify a device path
(CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
served vi
On Thu, Jul 23, 2020 at 4:18 PM Heinrich Schuchardt wrote:
>
> On 23.07.20 17:07, Grant Likely wrote:
> > On Thu, Jul 23, 2020 at 3:40 PM Heinrich Schuchardt
> > wrote:
> >>
> >> On 23.07.20 14:23, Grant Likely wrote:
> >>> Hi Heinrich,
> >
On Thu, Jul 23, 2020 at 3:40 PM Heinrich Schuchardt wrote:
>
> On 23.07.20 14:23, Grant Likely wrote:
> > Hi Heinrich,
> >
> > I've run into a problem with mainline U-Boot. Debian unstable (distro
> > kernel) fails to boot after commit b02a707152, "efi_load
Hi Heinrich,
I've run into a problem with mainline U-Boot. Debian unstable (distro
kernel) fails to boot after commit b02a707152, "efi_loader: enable
UEFI variables at runtime". Kernel boots fine before that commit. Boot
log is attached. Looks like it is failing in a workqueue that is
calling runt
On 09/05/2020 11:04, Heinrich Schuchardt wrote:
On 5/6/20 5:04 PM, Grant Likely wrote:
On 05/05/2020 18:57, Heinrich Schuchardt wrote:
On 05.05.20 19:23, Grant Likely wrote:
On 05/05/2020 18:04, Heinrich Schuchardt wrote:
On 05.05.20 13:15, Grant Likely wrote:
On 01/05/2020 10:33
On 11/05/2020 12:55, Heinrich Schuchardt wrote:
On 11.05.20 10:48, Grant Likely wrote:
On 07/05/2020 19:19, Heinrich Schuchardt wrote:
According to the UEFI spec ACPI tables should be placed in
EfiACPIReclaimMemory. Let's do the same with the device tree.
Suggested-by: Ard Biesheuve
On 07/05/2020 19:19, Heinrich Schuchardt wrote:
According to the UEFI spec ACPI tables should be placed in
EfiACPIReclaimMemory. Let's do the same with the device tree.
Suggested-by: Ard Biesheuvel
Cc: Grant Likely
Signed-off-by: Heinrich Schuchardt
---
v2:
adjust the unit test
On 05/05/2020 18:57, Heinrich Schuchardt wrote:
On 05.05.20 19:23, Grant Likely wrote:
On 05/05/2020 18:04, Heinrich Schuchardt wrote:
On 05.05.20 13:15, Grant Likely wrote:
On 01/05/2020 10:33, Heinrich Schuchardt wrote:
On 4/30/20 9:13 PM, Sughosh Ganu wrote:
On Fri, 1 May 2020 at
On 05/05/2020 18:04, Heinrich Schuchardt wrote:
On 05.05.20 13:15, Grant Likely wrote:
On 01/05/2020 10:33, Heinrich Schuchardt wrote:
On 4/30/20 9:13 PM, Sughosh Ganu wrote:
On Fri, 1 May 2020 at 00:09, Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:
On 4/30/20 7
On 01/05/2020 10:33, Heinrich Schuchardt wrote:
On 4/30/20 9:13 PM, Sughosh Ganu wrote:
On Fri, 1 May 2020 at 00:09, Heinrich Schuchardt mailto:xypron.g...@gmx.de>> wrote:
On 4/30/20 7:36 PM, Sughosh Ganu wrote:
> Add support for the get_image_info and set_image routines, which ar
Hello,
I am hoping please for some assistance getting u-boot to run on a Rpi4.
I had downloaded the image contained at :
https://download.opensuse.org/repositories/home:/mbrugger:/branches:/RPi4/openSUSE_Tumbleweed_ARM/
And dd that to my SD card. This runs fine, but there is no uEnv.txt and
even wh
Hi Takahiro,
On 17/05/2019 01:12, AKASHI Takahiro wrote:
[...]
> In fact, I have already imported relevant kernel code into U-Boot
> and it now works perfectly with my experimental UEFI secure boot patch,
Speaking of which, where can I find the experimental UEFI secure boot
patches? I've not bee
On 28/06/2019 09:19, Grant Likely wrote:
> Quick poll: who would be interested in a U-Boot/EBBR plugfest event
> collocates with ELC-EU this year (week of 28th Oct)?
>
> In the EBBR meetings we’ve tossed around the idea of an U-Boot/EBBR plugfest
> to work out compatibility is
On 31/07/2019 20:16, Daniel Kiper wrote:
> On Tue, Jul 30, 2019 at 03:33:27PM +0000, Grant Likely wrote:
>>> If you want to discuss something there please put a topic proposal on
>>> LPC site. CfP closes on 2nd of August. If you need a pass or invite an
>>> exper
>> On 24 Jul 2019, at 14:39, Daniel Kiper wrote:
>>
>>> On Mon, Jul 08, 2019 at 01:27:11PM +, Steve McIntyre wrote:
>>> On Mon, Jul 08, 2019 at 11:18:56AM +0100, Leif Lindholm wrote:
>>> On Mon, Jul 08, 2019 at 12:13:07PM +0200, Daniel Kiper wrote:
> I don't know yet - UEFI Asia plugfest
Quick poll: who would be interested in a U-Boot/EBBR plugfest event collocates
with ELC-EU this year (week of 28th Oct)?
In the EBBR meetings we’ve tossed around the idea of an U-Boot/EBBR plugfest to
work out compatibility issues between OS distros and upstream U-Boot SBC
support. The idea is
On 26/04/2019 10:49, Jan Kiszka wrote:
> On 26.04.19 11:07, Francois Ozog wrote:
[...]
>> Here are the guiding principles of our efforts :
>> 0) we want a cross architecture (x86/Arm/...), cross vendor and cross
>> processor model update solution
>> 1) untrusted world cannot update trusted world
>
On 24/04/2019 02:23, daniel.sangor...@toshiba.co.jp wrote:
> Hello Francois, Jan, Christian, and all
>
> Sorry for the late reply, I was waiting for the administrator of the Boot
> Architecture mailing list to accept my subscription request, but it seems it
> will take a bit more time. I will se
figuration: 'config-0'
Configuration 0 (config-0)
Description: default config
Kernel: kernel-0
Likewise, I get the same information using the `iminfo` command within
u-boot.
Sorry again for the typo,
Grant
On Tue, Aug 7, 2018 at 12:16 AM Johann Neuhauser <
jneuhau...@d
27;t get kernel image!
I can't make sense of this error. `iminfo` recognizes my default
configuration, yet `bootm` can't find the configuration node?
Thanks,
Grant
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Dong Wei (Arm)
Sincerely,
Grant Likely, EBBR committee co-chair
Note on U-Boot implementations
--
It is expected that EBBR compliant can be achieved by using a recent
version of U-Boot with the appropriate configuration options. An
implementers guide for U-Boot will be writ
On Sat, Apr 30, 2016 at 12:23 AM, Grant Likely wrote:
> I'm pleased to announce the first *very early draft* of the new
> devicetree specification that I and several others have been working
> on since January. This document picks up where ePAPR left off in 2012.
> I'm a
I'm pleased to announce the first *very early draft* of the new
devicetree specification that I and several others have been working
on since January. This document picks up where ePAPR left off in 2012.
I'm announcing it now along with the new devicetree.org organization
which will handle governan
On Mon, Nov 17, 2014 at 10:14 AM, Ian Campbell wrote:
> On Mon, 2014-11-17 at 09:58 +0000, Grant Likely wrote:
>> I /DO/ want comments though. Putting the node in /chosen is
>> unconventional. I want to hear if anyone has a good reason why the
>> framebuffers shouldn
ure misses, Luc's original
>> version was posted before the v2014.10 merge window.
>
> I'm afraid I don't agree that just because it has taken a long time to
> get something right we should commit to it before it is ready,
> especially when it is an ABI, which is what
On Sun, Nov 16, 2014 at 7:39 PM, Hans de Goede wrote:
> From: Luc Verhaegen
>
> Add simplefb support, note this depends on the kernel having support for
> the clocks property which has recently been added to the simplefb devicetree
> binding.
>
> Signed-off-by: Luc Verhaegen
> [hdego...@redhat.c
On Mon, 4 Mar 2013 18:03:23 -0600, Kim Phillips
wrote:
> On Mon, 4 Mar 2013 10:30:45 -0800
> Curt Brune wrote:
>
> > Hello -
> >
> > I want to pass a number of arguments from u-boot to the booted kernel.
> > The arguments are needed by user space applications, not the kernel.
> >
> > I can t
> > How can I tell u-boot to boot with the ramboot= definition instead of
> > mmcboot= ?
> >
> > - Grant
>
> You need to change environmental variable bootcmd
>
> setenv bootcmd ramboot
> saveenv
> run bootcmd
>
> or simpler:
>
> Stop u-b
How can I tell u-boot to boot with the ramboot= definition instead of
mmcboot= ?
- Grant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On Wed, Oct 31, 2012 at 11:00 PM, Daniel Mack wrote:
> cc devicetree-discuss. Here's a reference to the full thread:
>
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/145221/
Interesting. I only just was made aware of this thread. There is a
similar discussion going on kicked off by th
execute /init. Attempting defaults...
> Kernel panic - not syncing: No init found. Try passing init= option to
kernel.
>
> Can anyone tell me how to load uCore so init works?
>
> - Grant
I've gotten farther along, but I get one of these two errors when loading
the ramdisk:
RA
VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
devtmpfs: error mounting -2
Freeing init memory: 144K
Failed to execute /init. Attempting defaults...
Kernel panic - not syncing: No init found. Try passing init= option to
kernel.
Can anyone te
or if anyone knows.
>
> omap3_beagle is for the beagleboard and beagleboard xM boards.
> am335x_evm as you noticed is for the beaglebone (And am335x GP EVM and
> am335x EVM SK).
Got it, thank you Tom.
- Grant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
ried 'make
omap3_beagle_config && make' but the resultant MLO and u-boot.img did
not work at all. am335x_evm_config works fine, but I'm curious what
omap3_beagle_config is for if anyone knows.
- Grant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
l commandline:
# cat /proc/cmdline
console=ttyO0,115200n8 ip=none root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait
I tried adding the following to uEnv.txt with no luck:
bootargs="console=ttyO0,115200n8 ip=none root=/dev/mmcblk0p2 rw
rootfstype=ext3 rootwait"
Can you see what I&#x
FIG_SPL_YMODEM_SUPPORT:
https://github.com/kientzle/freebsd-beaglebone/issues/1#issuecomment-5953658
Can anyone tell me how to do that?
- Grant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
. Availability for respective links.
Brilliant! I've been looking for that for a while...
Thanks again,
--
Grant Edwards grant.b.edwardsYow! Will it improve my
at CASH FLOW?
gmail.com
_
On 2012-05-22, Wolfgang Denk wrote:
> In message Grant Edwards wrote:
[...]
>> somebody told me that if I was using U-Boot, I could build the zImage
>> and rootfs separately and then combine them into a single uImage file
>> for distribution.
>
> The (deprecated)
that some bootloaders will detect any "extra" bytes after
the end of the zImage data and assume that they are a rootfs image. Is
that how U-Boot does it? I just cat the ziminage and rootfs.cpio.gz
files together and then prepend a uImage header?
--
Grant Edwards grant.b.e
ck-names" in the cases
> >> where it isn't strictly necessary. Just because some vendors don't want
> >> to define an order between their clocks doesn't mean it's a good idea
> >> for everybody to use that model. In this case, just declaring that
On Jan 5, 2012, at 3:18 PM, Mike Frysinger wrote:
> On Thursday 22 December 2011 13:39:35 Grant Erickson wrote:
>> This patch fixes the make infrastructure for the fw_printenv tool such
>> that it is built, by default, as a cross-compilation for the target
>> board w
On Jan 4, 2012, at 8:14 AM, Tom Rini wrote:
> On 01/04/2012 09:10 AM, Grant Erickson wrote:
>> On Jan 3, 2012, at 6:31 AM, Tom Rini wrote:
>>> On 12/22/2011 12:28 PM, Grant Erickson wrote:
>>>> Only attempt to configure and add DRAM at chip select 1 if the board has
On Jan 3, 2012, at 6:31 AM, Tom Rini wrote:
> On 12/22/2011 12:28 PM, Grant Erickson wrote:
>> Only attempt to configure and add DRAM at chip select 1 if the board has
>> configured more than one bank of DRAM.
>>
>> This prevents boards that have CONFIG_NR_DRAM_BAN
On Dec 22, 2011, at 1:08 PM, Wolfgang Denk wrote:
> In message <1324577816-26198-1-git-send-email-maratho...@gmail.com> you wrote:
>> This patch adds optional support for strndup.
>>
>> Signed-off-by: Grant Erickson
>> ---
>> include/linux/string.h |
Only attempt to configure and add DRAM at chip select 1 if the board has
configured more than one bank of DRAM.
This prevents boards that have CONFIG_NR_DRAM_BANKS set to 1 from getting an
incorrect DRAM size.
Signed-off-by: Grant Erickson
Cc: Tom Rini
---
arch/arm/cpu/armv7/omap3/sdrc.c
the U-Boot command line.
Signed-off-by: Grant Erickson
---
tools/env/fw_env.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c
index 996682e..2185be9 100644
--- a/tools/env/fw_env.c
+++ b/tools/env/fw_env.c
@@ -45,6 +45
This patch fixes the make infrastructure for the fw_printenv tool such
that it is built, by default, as a cross-compilation for the target
board when so requested with TOOLSUBDIRS on the U-Boot make command
line.
Signed-off-by: Grant Erickson
---
tools/env/Makefile | 18
This patch adds optional support for strndup.
Signed-off-by: Grant Erickson
---
include/linux/string.h |3 +++
lib/string.c | 21 +
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/include/linux/string.h b/include/linux/string.h
index 6239039
On Thu, Oct 13, 2011 at 3:50 PM, Stephen Warren wrote:
> Simon Glass wrote at Thursday, October 13, 2011 3:25 PM:
>> Hi Stephen,
>>
>> On Thu, Oct 13, 2011 at 2:21 PM, Stephen Warren wrote:
>> > Simon Glass wrote at Tuesday, October 11, 2011 4:26 PM:
>> >> This new option allows U-Boot to embed a
On Wed, Sep 14, 2011 at 2:11 PM, Wolfgang Denk wrote:
> Dear Grant Likely,
>
> In message <20110914164528.gm3...@ponder.secretlab.ca> you wrote:
>>
>> May I suggest an alternate approach? Rather than hard linking the dtb
>> into the u-boot image, this would
On Wed, Sep 14, 2011 at 12:03 PM, Simon Glass wrote:
> if the fdt is not in the U-Boot tree, where does it go? When will the
> kernel fdt be set up? That sounds very promising.
Into a separate git tree. Possibly on devicetree.org,
git.secretlab.ca, or git.linaro.org. I don't really want it on l
On Mon, Sep 12, 2011 at 03:04:24PM -0700, Simon Glass wrote:
> This adds support for an FDT to be build as a separate binary file called
> u-boot.dtb. This can be concatenated with the U-Boot binary to provide a
> device tree located at run-time by U-Boot.
Hahaha, I should the entire thread of pat
On Mon, Sep 12, 2011 at 03:04:23PM -0700, Simon Glass wrote:
> This new option allows U-Boot to embed a binary device tree into its image
> to allow run-time control of peripherals. This device tree is for U-Boot's
> own use and is not necessarily the same one as is passed to the kernel.
>
> The d
On Sat, Jul 16, 2011 at 12:06:33PM -0400, Jerry Van Baren wrote:
> On 07/09/2011 04:40 PM, David A. Long wrote:
> >From: David A. Long
> >
> >Add a new "fdt_high" enviroment variable. This can be used to control (or
> >prevent) the
> >relocation of the flattened device tree on boot. It can be used
On Thu, Jul 14, 2011 at 03:12:25PM -0400, David Long wrote:
> On Fri, 2011-07-15 at 03:50 +0900, Grant Likely wrote:
>
>
> > Regardless of this patch, the pandaboard uboot still needs to be
> > fixed. Setting an fdt_high variable is useful for debug, but it is not
> &g
mory beyond about 3/4G (HIGHMEM) during early boot.
>
Regardless of this patch, the pandaboard uboot still needs to be
fixed. Setting an fdt_high variable is useful for debug, but it is not
a fix.
g.
> -dl
>
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
much overhead FDT support is not that much a problem IMHO.
>
> Regards
> Simon
>
> (Sorry Detlev for the repost - forgot the ML...)
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinf
if ((phandle == 0) || (phandle == -1))
> return -FDT_ERR_BADPHANDLE;
> phandle = cpu_to_fdt32(phandle);
> +
> + /* First check for a matching "phandle" property */
> + ret = fdt_node_offset_by_prop_value(fdt, -1, "phandle",
> + &phandle, sizeof(phandle));
> + if (ret > 0)
> + return ret;
> +
> + /* No "phandle", so check "linux,phandle" */
> return fdt_node_offset_by_prop_value(fdt, -1, "linux,phandle",
> &phandle, sizeof(phandle));
> }
> --
> 1.7.3.4
>
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Thanks guys.
g.
On Wed, Apr 27, 2011 at 1:47 PM, Wolfgang Denk wrote:
> Dear Gerald Van Baren,
>
> In message <4db630eb.20...@cideas.com> you wrote:
>> Dear Wolfgang,
>>
>> The following pull request is for Grant Likely's changes "[PATCH 0/6]
>>
From: Grant Likely
The initrd_end variable contains the address immediately *after* the
initrd blob, not the last address containing data. This patch fixes
an inadvertent off-by-one when setting up the initrd reserved map.
Signed-off-by: Grant Likely
---
common/fdt_support.c |2 +-
1
From: Grant Likely
The following boards gain device tree support with this patch:
ca9x4_ct_vxp - Versatile Express
i.mx5 boards:
efikamx
mx51evk
mx53evk
OMAP boards:
devkit8000
igep0020
igep0030
omap3_overo
omap3_pandora
omap4_sdp3430
omap3_zoom1
omap3_zoom2
omap4_panda
omap4_sdp4430
Tegra
From: Grant Likely
If a regions is reserved in the fdt, then it should not be used. Add
the memreserve regions to the lmb so that u-boot doesn't use them to
store the initrd.
Signed-off-by: Grant Likely
---
arch/arm/lib/bootm.c |2 ++
arch/powerpc/lib/bootm.c |4
c
From: Grant Likely
The previous patch makes u-boot use the full accessible size of ram as
the default boot mapped size if CONFIG_SYS_BOOTMAPSZ is not defined,
which means boot_relocate_fdt() can be changed to depend solely on
CONFIG_OF_LIBFDT.
Signed-off-by: Grant Likely
---
arch/powerpc/lib
From: Grant Likely
This patch adds a function getenv_bootm_mapsize() for obtaining the
size of the early mapped region accessible by the kernel during early
boot. It defaults to CONFIG_SYS_BOOTMAPSZ, or if not defined,
defaults to getenv_bootm_size(), which in turn defaults to the size of
RAM
From: Grant Likely
For the calls to boot_relocate_fdt(), boot_get_cmdline(), and
boot_get_kbd(), the value of bootmem_base is always obtained by
calling getenv_bootm_low(). Since the value always comes from the
same source, the calling signature for those functions can be
simplified by making
ase? Or would you prefer me to send
you a pull request?
g.
---
Grant Likely (6):
Stop passing around bootmem_base value.
Default to bootm_size() when CONFIG_SYS_BOOTMAPSZ is not defined
Remove device tree booting dependency on CONFIG_SYS_BOOTMAPSZ
Fix off-by-one error in
On 2/6/11 12:41 PM, Grant Erickson wrote:
> I recently updated my TI AM37x EVM from U-Boot 2010.09 to 2010.12 and noticed
> that, in doing so, saveenv / env save no longer seems to work. The following
> example demonstrates [ELIDED]:
I subsequently found the following patch and commit:
=> printenv foo
foo=bar
--
Principal
Nuovations
998 Alpine Terrace Suite 3
Sunnyvale, CA 94086-2469
US
T +1-408-749-0495
F +1-205-449-0495
M +1-408-489-5710
gerick...@nuovations.com
http://www.nuovations.com/
Best,
Grant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On Wed, Jan 26, 2011 at 11:30 AM, Wolfgang Denk wrote:
> Dear Grant Likely,
>
> In message <20110126165340.14306.98359.stgit@localhost6.localdomain6> you
> wrote:
>> LMB doesn't currently handle allocating regions based at physical
>> address 0. This patch
On Wed, Jan 26, 2011 at 9:57 AM, Grant Likely wrote:
> LMB doesn't currently handle allocating regions based at physical
> address 0. This patch reworks the lmb_alloc functions to return
> all ones when allocation fails instead of zero so that callers can
> differentiate
LMB doesn't currently handle allocating regions based at physical
address 0. This patch reworks the lmb_alloc functions to return
all ones when allocation fails instead of zero so that callers can
differentiate between a region allocated at zero and a failed
allocation
Signed-off-by:
ocumentation or procedure to do that?
Send the hex file to the flash distributor and have them do it.
--
Grant Edwards grant.b.edwardsYow! I'm meditating on
at the FORMALDEHYDE and the
gmail.com
part of the SAM-BA utility -- and that's only because I'm too
lazy to fix Atmel's Makefiles so they call the compiler with the
proper flags.
--
Grant Edwards grant.b.edwardsYow! Are we THERE yet?
at
On 2010-08-23, Detlev Zundel wrote:
> Hi Grant,
>
>>>>> Maybe you can implement a server on your hardware?
>>>>
>>>> What sort of server?
>>>
>>> It would be a tftp server of course but that is out of the question
>>> without
On 2010-08-23, Ben Warren wrote:
> On 8/23/2010 2:10 PM, Grant Edwards wrote:
>> Now that you mention it, I have implemented a tftp server for U-Boot.
>>
>> We needed a way to recover "bricked" units in the field, and there's
>> simply no way we cou
Making U-Boot the tftp server and our "restore"
program the client solved several problems. I also find have U-Boot
be the server is a lot more convenient for development use. [It also
U-Boot commands to be sent via the tftp protocol.]
I thought about submitting patches (it's pret
;t "our bareboard system doesn't support Ethernet" preclude the
use of Ethernet (UDP or otherwise)?
> Maybe you can implement a server on your hardware?
What sort of server?
--
Grant Edwards grant.b.edwardsYow! If I pull
On 2010-08-16, Scott Wood wrote:
> On Fri, Aug 13, 2010 at 09:22:21PM +0000, Grant Edwards wrote:
> At one point in the legacy NAND code, a distinction was made when
> reading between completely skipping bad blocks, and filling the
> buffer with zeroes in place of the bad blocks. I
On 2010-08-13, Grant Edwards wrote:
> On 2010-07-09, Scott Wood wrote:
>> On Fri, Jul 09, 2010 at 08:56:40AM -0400, Ben Gardiner wrote:
>>
>>> If you are putting an MTD filesystem in that partition then the
>>> filesystem itself will take care of bad blocks that
something like this:
nand_info[0].read(nand_info+0, offset, sizeof(buffer), &len, buffer)
nand_info[0].write(nand_info+0, offset, bytecount, &len, buffer)
but, I have a feeling that's not right (though it seems to work, I
On Tue, Aug 10, 2010 at 3:03 PM, John Rigby wrote:
> Kumar, Grant:
>
> On Tue, Aug 10, 2010 at 1:39 PM, Grant Likely
> wrote:
>> On Thu, Aug 5, 2010 at 5:36 PM, John Rigby wrote:
>>> On Thu, Aug 5, 2010 at 5:26 PM, Kumar Gala
>>> wrote:
>>>>
&
On Tue, Aug 10, 2010 at 2:17 PM, Dan Malek wrote:
>
> On Aug 10, 2010, at 12:39 PM, Grant Likely wrote:
>
>> . At the
>> moment, I think firmware should be restricted to only touching the
>> /chosen node, the /memory node,
>
> I don't even want i
APSZ
> if ((fdt_blob + *of_size + CONFIG_SYS_FDT_PAD) >=
> ((char *)CONFIG_SYS_BOOTMAPSZ + bootmap_base))
> relocate = 1;
> +#endif
>
> /* move flattend device tree if needed */
> if (relocate) {
> diff --git a/include/image.h b/include/image.h
> index bcc08d1..8f06cdc 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -339,7 +339,7 @@ int boot_relocate_fdt (struct lmb *lmb, ulong
> bootmap_base,
> char **of_flat_tree, ulong *of_size);
> #endif
>
> -#if defined(CONFIG_PPC) || defined(CONFIG_M68K)
> +#if defined(CONFIG_PPC) || defined(CONFIG_M68K) || defined(CONFIG_ARM)
> int boot_ramdisk_high (struct lmb *lmb, ulong rd_data, ulong rd_len,
> ulong *initrd_start, ulong *initrd_end);
>
> --
> 1.7.0.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
1 - 100 of 134 matches
Mail list logo
