from:"Grant"





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 track
mainline Linux DTB schema.

I've been looking into a generic config for adding a separate OS-dtb to
U-Boot that is not used internally and is only passed to the OS. That
would solve the problem you're seeing above.


What would be the advantage of building said second device-tree into
U-Boot instead of loading it from a (possibly signed) file?


I would see that as an implementation detail, but from the OS point of 
view EBBR requires the firmware to provide a DTB to the OS without the 
OS having any involvement in providing it. The easiest solution is to 
embed the OS dtb into U-Boot, but it could be loaded and verified from a 
file as well.


g.

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL





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.

However there is another way to approach it which I think Francois
touched on. If instead a UEFI stub was added to the FIT image, in the
same way that the kernel has a UEFI stub, then the logic of decoding
the
FIT and choosing the correct DTB & initrd can be part of the image and
it becomes applicable to any UEFI implementation. It would also address

Ard's concern of loading the FIT into memory, and then copying due to
the EFI_FILE_LOAD2 path. The FIT stub would already know the image is
in
RAM, that is is reserved correctly, and just pass the correct addresses

to the kernel as part of the normal boot flow.

Signing would also be taken care of because the whole FIT can be
signed,
and that signature would be checked when it gets loaded.

Thoughts?



The gain of a fit image in U-Boot used for calling the Linux kernel via the EFI 
stub vs calling the legacy entry point comes down to providing the 
EFI_RNG_PROTOCOL to be used for KASLR.


I agree with that, but that is not my concern.

My concern is that the FIT image format will only be supported by U-Boot.
Other UEFI implementations do not implement it.

On the other hand, adding a UEFI Stub to the FIT image format makes it a
generic solution that can be used by any UEFI implementation. This would be
separate from the linux kernel's UEFI stub, and should only deal with
choosing the appropriate kernel/initrd/dtb from the FIT and then calling
into the kernel's stub to actually boot the kernel.


If we are considering a cross-firmware solution for this why base it on FIT?
Wouldn't a single EFI application (that's aware of the signatures and how
to verify them) do the job? Just to inherit the work on signatures already done
in FIT?


Hahaha! I wasn't going to bring that up because I didn't want to cause 
extra trouble. :-) But yes, you're right. If we have a UEFI stub on the 
container, then it doesn't matter what the container format is. cpio, 
tar.gz, zip, FAT image, etc. Any of those would work.



For initrd a stub UEFI binary will work. But if you want to provide a kernel 
specific  dtb with the same stub binary it will require a new service for 
device-tree fixups.


Devicetree fixups indeed needs to be solved. I would propose registering a
new protocol for fixups. If the protocol is present, then stub can call it.
If not, then the DTB from the fit should be used unmodified.

g.


So if you do this in a single EFI app, you wont need an extra protocol for it
right?


True, you could embed the DT fixups into the EFI stub itself, but that 
would end up being completely separate logic from the fixup code already 
in U-Boot.


g.

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

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?usp=sharing

We have two boot flows under consideration (not saying others are bad,

just to say they are on focus):
A.1 typical distro (slide 2): --> -->
--> Linux; Linux is here defined as the tuple {vmlinuz}, vmlinuz is
verified through EFI mechanism by either efi firmware or shim, ACPI
tables are verified by firmware, initrd is not verified
A.2 typical embedded (slide 3): -> Linux ; Linux is here
defined as the tuple {vmlinuz, initrd, dtb} that is folded into a FIT
and are verified via signature, it avoid errors/attacks about mixing
vmlinuz/initrd/dtb.

We want EBBR "equivalent" flows (Equivalent meaning with the same level
of security and accepting the weaknesses).
B.1 typical distro (slide 4): --> -->
--> Linux
B.2 typical embedded (slide 5): -> Linux

For B.1 to be equivalent to A.1, we need the DT to be authenticated
(ACPI is embedded in the firmware in A.1).
For B2. to be equivalent to A.2, we need the DT and initrd to be
authenticated

_
We can first validate this point: let's check whether we want to do this
(regardless of the implementation details, focusing on the intention).

On the implementation side, last call we discussed Trusting DT and we
ended up talking about trusting initrd too (probably because B.2 in the
back of our minds, without being explicit about this).

After giving some additional thoughts, it sounds like a good approach is
to "lead by example": let's implement what we think are the "archetype"
flows for Qemu and maintain it over time. We would make all changes we
think are good in all relevant projects (tfa, op-tee, u-boot,
devicetree, linux kernel, qemu...). Being an "archetype" flow does not
prevent systems to be EBBR compliant, we just have reference flows.

_
We can validate this second point: are we in agreement that leading by
an end-to-end example on a platform, rather by technology layers
(trusting DT PoC was in that spirit) ?

What are the implementation details of B.1 and B.2?

B.1
To trust DT the proposal is to make its use closer to ACPI: this is a
platform attribute that is verified by firmware and handed over to OS.
To achieve that:
- we create a platform repo in devicetree.org ,
add the Qemu-bsa DT (coming from current Linux kernel ), and maintain it
over time. We shall ensure forward/backward compatibility of relevant
Linux drivers.
- the resulting DTB is compiled and integrated by the platform vendor in
its TF-A FIP at NT_FW_CONFIG section.

When building OpenSBI you can specify a device-tree using environment
variable FW_PAYLOAD_FDT_PATH.

- at boot time, TF-A verifies DTB, pass it to U-Boot, U-Boot passes that
DTB to the shim as a config table and boot flow continues; the platform
DTB can be overridden by grub (without any verification, that can be
seen as a weaker than ACPI case); the Linux EFI-STUB uses EFI_LOAD_FILE2
protocol to get the initrd (unverified). Linux command line dtb= is disabled

B.2
To trust DT the proposal is to make its use closer to ACPI: this is a
platform attribute that is verified by firmware and handed over to OS.
To trust the initrd the proposal is to leverage the same concept as A.2:
create a tuple with {vmlinuz, initrd, dtb}
To achieve that:
- we create a platform repo in devicetree.org ,
add the Qemu-bsa DT (coming from current Linux kernel ), and maintain it
over time. We shall ensure forward/backward compatibility of relevant
Linux drivers.

QEMU provides its own device-tree to the firmware. Why would we need a
Linux device-tree for QEMU?

The Linux Foundation is unable to ensure that their device-trees are
usable. With a Linux DTB after v5.3 I cannot start my MacchiatoBin with
v5.4-v5.7.

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 track
mainline Linux DTB schema.

I've been looking into a generic config for adding a separate OS-dtb to
U-Boot that is not used internally and is only passed to the OS. That
would solve the problem you're seeing above.

That doesn't solve the problem of DTB schema stability, but it at least
decouples the problem so we're not stuck.

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL





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 consideration (not saying others are bad, 
just to say they are on focus):
A.1 typical distro (slide 2):  -->  -->  
--> Linux; Linux is here defined as the tuple {vmlinuz}, vmlinuz is 
verified through EFI mechanism by either efi firmware or shim,  ACPI 
tables are verified by firmware, initrd is not verified
A.2 typical embedded (slide 3):  -> Linux ; Linux is here 
defined as the tuple {vmlinuz, initrd, dtb} that is folded into a FIT 
and are verified via signature, it avoid errors/attacks about mixing 
vmlinuz/initrd/dtb.


We want EBBR "equivalent" flows (Equivalent meaning with the same level 
of security and accepting the weaknesses).
B.1 typical distro (slide 4):  -->  -->  
--> Linux

B.2 typical embedded (slide 5):  -> Linux

For B.1 to be equivalent to A.1, we need the DT to be authenticated 
(ACPI is embedded in the firmware in A.1).


Current EBBR requires DT to be embedded in firmware by default. OS has 
option to replace it, but the firmware provided DT can be verified with 
the firmware image.


For B2. to be equivalent to A.2, we need the DT and initrd to be 
authenticated


I'm proposing an alternative to B2:
 -> FIT Shim (payload of kernel+initrd+dt) -> Linux

g.

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL





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 provided the possibility to specify a device path
(CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
served via the EFI_FILE_LOAD2_PROTOCOL.

Ard extended the Linux EFI stub to allow loading the initial RAM disk
via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.

With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
IH_OS_EFI") Cristian enabled signed FIT images that contain a device
tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).

In the DTE calls we have discussed that it is unfortunate that we do

not

have a method to validate initial RAM images in the UEFI context.

To me it would look like a good path forward to combine the two

ideas:


* Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk
* Pass location and size to the UEFI subsystem and serve them via
the EFI_FILE_LOAD2_PROTOCOL.

We could also extend the bootefi command to be callable as

 bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r

like the booti command to serve an initial RAM disk.

What are your thoughts?


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.

However there is another way to approach it which I think Francois
touched on. If instead a UEFI stub was added to the FIT image, in the
same way that the kernel has a UEFI stub, then the logic of decoding
the
FIT and choosing the correct DTB & initrd can be part of the image and
it becomes applicable to any UEFI implementation. It would also address

Ard's concern of loading the FIT into memory, and then copying due to
the EFI_FILE_LOAD2 path. The FIT stub would already know the image is
in
RAM, that is is reserved correctly, and just pass the correct addresses

to the kernel as part of the normal boot flow.

Signing would also be taken care of because the whole FIT can be
signed,
and that signature would be checked when it gets loaded.

Thoughts?



The gain of a fit image in U-Boot used for calling the Linux kernel via the EFI 
stub vs calling the legacy entry point comes down to providing the 
EFI_RNG_PROTOCOL to be used for KASLR.


I agree with that, but that is not my concern.

My concern is that the FIT image format will only be supported by 
U-Boot. Other UEFI implementations do not implement it.


On the other hand, adding a UEFI Stub to the FIT image format makes it a 
generic solution that can be used by any UEFI implementation. This would 
be separate from the linux kernel's UEFI stub, and should only deal with 
choosing the appropriate kernel/initrd/dtb from the FIT and then calling 
into the kernel's stub to actually boot the kernel.



For initrd a stub UEFI binary will work. But if you want to provide a kernel 
specific  dtb with the same stub binary it will require a new service for 
device-tree fixups.


Devicetree fixups indeed needs to be solved. I would propose registering 
a new protocol for fixups. If the protocol is present, then stub can 
call it. If not, then the DTB from the fit should be used unmodified.


g.

Re: Fit images and EFI_LOAD_FILE2_PROTOCOL

2020-10-05 Thread 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 provided the possibility to specify a device path
(CONFIG_EFI_INITRD_FILESPEC) from which an initial RAM disk can be
served via the EFI_FILE_LOAD2_PROTOCOL.

Ard extended the Linux EFI stub to allow loading the initial RAM disk
via the EFI_FILE_LOAD2_PROTOCOL with the utmost priority.

With commit ecc7fdaa9ef1 ("bootm: Add a bootm command for type
IH_OS_EFI") Cristian enabled signed FIT images that contain a device
tree and a UEFI binary (enabled by CONFIG_BOOTM_EFI=y).

In the DTE calls we have discussed that it is unfortunate that we do not
have a method to validate initial RAM images in the UEFI context.

To me it would look like a good path forward to combine the two ideas:

* Let the signed FIT image (of type IH_OS_EFI) contain a RAM disk
* Pass location and size to the UEFI subsystem and serve them via
   the EFI_FILE_LOAD2_PROTOCOL.

We could also extend the bootefi command to be callable as

bootefi $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r

like the booti command to serve an initial RAM disk.

What are your thoughts?


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.


However there is another way to approach it which I think Francois 
touched on. If instead a UEFI stub was added to the FIT image, in the 
same way that the kernel has a UEFI stub, then the logic of decoding the 
FIT and choosing the correct DTB & initrd can be part of the image and 
it becomes applicable to any UEFI implementation. It would also address 
Ard's concern of loading the FIT into memory, and then copying due to 
the EFI_FILE_LOAD2 path. The FIT stub would already know the image is in 
RAM, that is is reserved correctly, and just pass the correct addresses 
to the kernel as part of the normal boot flow.


Signing would also be taken care of because the whole FIT can be signed, 
and that signature would be checked when it gets loaded.


Thoughts?

g.

Re: Debian boot failure with UEFI runtime variables enabled

2020-07-23 Thread Grant Likely

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,
> >>>
> >>> 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 runtime services; but I haven't dug in yet.
> >>>
> >>> I'm not doing anything exotic with this build. Mainline U-Boot,
> >>> mainline TFA, and booting the kernel with an up-to-date dtb.
> >>>
> >>> g.
> >>
> >> Hello Grant,
> >>
> >> this is the patch you are needing:
> >>
> >> https://lists.denx.de/pipermail/u-boot/2020-July/421193.html
> >> [PATCH 1/1] efi_loader: efi_current_var after SetVirtualAddressMap
> >
> > Got it. Working now. Thanks!
> > g.
> >
>
> There is also an issue to current Linux kernels fixed by:
>
> efi/efivars: Expose RT service availability via efivars abstraction
>
> https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=f88814cc2578c121e6edef686365036db72af0ed
>
> Without the patch if SetVariable() is not available, you cannot access
> GetVariable() in Linux.

Also helpful. Thanks.
g.

>
> Best regards
>
> Heinrich

Re: Debian boot failure with UEFI runtime variables enabled

2020-07-23 Thread Grant Likely

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_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 runtime services; but I haven't dug in yet.
> >
> > I'm not doing anything exotic with this build. Mainline U-Boot,
> > mainline TFA, and booting the kernel with an up-to-date dtb.
> >
> > g.
>
> Hello Grant,
>
> this is the patch you are needing:
>
> https://lists.denx.de/pipermail/u-boot/2020-July/421193.html
> [PATCH 1/1] efi_loader: efi_current_var after SetVirtualAddressMap

Got it. Working now. Thanks!
g.

Debian boot failure with UEFI runtime variables enabled

2020-07-23 Thread Grant Likely

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 runtime services; but I haven't dug in yet.

I'm not doing anything exotic with this build. Mainline U-Boot,
mainline TFA, and booting the kernel with an up-to-date dtb.

g.



Found valid image at boot postion 0x000
lNOTICE:  Starting binary extension
NOTICE:  SVC: SW Revision 0x0. SVC is not supported
mv_ddr: mv_ddr-devel-18.08.0-ga881467-dirty (Jul 23 2020 - 13:16:48)
mv_ddr: completed successfully
NOTICE:  Cold boot
lNOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.3(release):v2.3-377-gd95c3de34 (Marvell-devel-18.12.0)
NOTICE:  BL1: Built : 13:16:54, Jul 23 2020
NOTICE:  BL1: Booting BL2
lNOTICE:  BL2: v2.3(release):v2.3-377-gd95c3de34 (Marvell-devel-18.12.0)
NOTICE:  BL2: Built : 13:16:56, Jul 23 2020
NOTICE:  SCP_BL2 contains 5 concatenated images
NOTICE:  Skipping MSS CP3 related image
NOTICE:  Skipping MSS CP2 related image
NOTICE:  Load image to CP1 MSS AP0
NOTICE:  Loading MSS image from addr. 0x40269f4 Size 0x1cd8 to MSS at 0xf428
NOTICE:  Done
NOTICE:  Load image to CP0 MSS AP0
NOTICE:  Loading MSS image from addr. 0x40286cc Size 0x1cd8 to MSS at 0xf228
NOTICE:  Done
NOTICE:  Load image to AP0 MSS
NOTICE:  Loading MSS image from addr. 0x402a3a4 Size 0x5420 to MSS at 0xf058
NOTICE:  Done
NOTICE:  SCP Image doesn't contain PM firmware
NOTICE:  BL1: Booting BL31
lNOTICE:  MSS PM is not supported in this build
NOTICE:  BL31: v2.3(release):v2.3-377-gd95c3de34 (Marvell-devel-18.12.0)
NOTICE:  BL31: Built : 13:16:59, Jul 23 2020
l

U-Boot 2020.07-00629-gb02a707152 (Jul 23 2020 - 13:16:23 +0100)

DRAM:  16 GiB
Comphy chip #0:
Comphy-0: PEX0
Comphy-1: PEX0
Comphy-2: PEX0
Comphy-3: PEX0
Comphy-4: SFI
Comphy-5: SATA1
Comphy chip #1:
Comphy-0: SGMII11.25 Gbps
Comphy-1: SATA0
Comphy-2: USB3_HOST0
Comphy-3: SATA1
Comphy-4: SFI
Comphy-5: UNCONNECTED
UTMI PHY 0 initialized to USB Host0
UTMI PHY 1 initialized to USB Host1
UTMI PHY 2 initialized to USB Host0
SATA link 0 timeout.
SATA link 1 timeout.
AHCI 0001. 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs
PCIE-0: Link down
MMC:   sdhci@6e: 0, sdhci@78: 1
Loading Environment from SPI Flash... SF: Detected w25q32 with page
size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: MACCHIATOBin-8040
Net:
Warning: mvpp2-1 (eth0) using random MAC address - ce:ac:be:d4:7c:30
eth0: mvpp2-1
Hit any key to stop autoboot:  0
=> load mmc 1:1 ${fdt_addr_r} armada-8040-mcbin.dtb
32886 bytes read in 18 ms (1.7 MiB/s)
=> run bootcmd_mmc0
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found EFI removable media binary efi/boot/bootaa64.efi
Scanning disk sd...@6e.blk...
Scanning disk sd...@78.blk...
Found 5 disks
** Unable to read file ubootefi.var **
Failed to load EFI variables
BootOrder not defined
EFI boot manager: Cannot load any image
1799536 bytes read in 152 ms (11.3 MiB/s)
Welcome to GRUB!

mvpp2-1 Waiting for PHY auto negotiation to complete... done
error: no suitable video mode found.


GNU GRUB  version 2.04-7

 
┌───┐
 │*Debian GNU/Linux


│
 │ Advanced options for Debian GNU/Linux


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 │


│
 
└───┘

  Use the ▲ and ▼ keys to select which entry is

Re: [PATCH 3/8] qemu: arm64: Add support for efi firmware management protocol routines

2020-05-18 Thread Grant Likely

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, 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 are
> part of the efi firmware management protocol.
>
> The current implementation uses the set_image routine for
updating the
> u-boot binary image for the qemu arm64 platform. This is
supported
> using the capsule-on-disk feature of the uefi
specification,
wherein
> the firmware image to be updated is placed on the efi
system
partition
> as a efi capsule under EFI/UpdateCapsule/ directory.
Support
has been
> added for updating the u-boot image on platforms booting
with arm
> trusted firmware(tf-a), where the u-boot image gets
booted as
the BL33
> payload(bl33.bin).
>
> The feature can be enabled by the following config options
>
> CONFIG_EFI_CAPSULE_ON_DISK=y
> CONFIG_EFI_FIRMWARE_MANAGEMENT_PROTOCOL=y
>
> Signed-off-by: Sughosh Ganu mailto:sughosh.g...@linaro.org>>

U-Boot's UEFI subsystem should work in the same way for x86,
ARM, and
RISC-V. Please, come up with an architecture independent
solution.

Please check the explanation that I gave in the other mail. If you
check
the patch series, the actual capsule authentication logic has been
kept
architecture agnostic, in efi_capsule.c. The fmp protocol is very
much
intended for allowing platforms to define their firmware update
routines. Edk2 also has platform specific implementation of the fmp
protocol under the edk2-platforms directory.

-sughosh

My idea is that for most platforms it will be enough to have a common
FMP implementation that consumes a capsule

* with one or more binaries
* a media device path, a start address, and a truncation flag
  for each of the binaries

The protocol implementation then will write the binaries to the
device
paths:

* to an SD-Card or eMMC exposing the Block IO protocol
  for most devices
* to a file in case of the Raspberry Pi or the Sandbox or QEMU
  (and truncate it if the truncation flag is set)

Does U-Boot have a common device path protocol that can be backed by
either a block device or a file on a filesystem? I didn't think it
did.

A block device, a partition, and a file all can be described by an UEFI
media device path.

Sure, from a UEFI media path, but does the underlying U-Boot
implementation have that abstraction?

With a file media path we can find the partition device path on which
the Simple file protocol is already installed by U-Boot.

In the mean time, there are at least three backends that the FMP is
going to have to deal with; the two you list above (block device &
file)
and SMC backed when updating firmware is managed by the secure world.
This first implementation only handles the file-backed use case.
Can we
start with that limitation and refactor when the block-device and SMC
use cases are added in? I would hate to see this functionality held up
on having to refactor other functionality in U-Boot.

I would prefer one single FMP driver for all SMC use cases. Everything
device specific should be handled in the secure world.

Not all platforms will be able to put firmware update into the secure
world. For instance, Not many Arm v7 platforms have trustzone accessible
to open source developers. On non-secure platforms (e.g., anything that
loads firmware from a regular filesystem on SD or eMMC) it doesn't make
much sense to loop out to secure firmware when U-Boot owns the
filesystem and the secure world would then need to coordinate with
U-Boot to commit the writes.

All of the code can certainly be in the same location, but I do think
there are three distinct generic backends for firmware updates:
- normal-world file-backed (using filesystem)
- normal-world block-backed (offsets from start of device)

These two could be in one instance of the FMP protocol.

- secure device backed (needs to go into secure world for unpacking and
processing regardless)

There doesn't need to be platform-specific code in any of those back
ends, but they do have different behaviour.

Is there already a protocol defined for the communication of capsule
updates between the firmware and the secure monitor, e.g. in EDK2?

Nothing defined yet (see below)

Would we simply use the UpdateCapsule() call parameters and pass them
via an SMC call?

If secure world is handling the update? Yes, I think a t

Re: [PATCH v2 1/1] efi_loader: put device tree into EfiACPIReclaimMemory

2020-05-12 Thread Grant Likely





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 Biesheuvel 
Cc: Grant Likely 
Signed-off-by: Heinrich Schuchardt 
---
v2:
 adjust the unit test


Is there any impact to changing the memory type for current users? Does
the kernel currently expect the EFI_BOOT_SERVICES_DATA memory type? What
happens if Grub or another EFI application replaces the DTB table? Will
it try to use a different memory type, and will that matter?


If we are using GRUB, linux_boot() allocates EFI_LOADER_DATA memory and
copies the FDT to it. When the devicetree command is used GRUB also
allocates EFI_LOADER_DATA.

So changes in U-Boot have no effect on what Linux sees if booted via GRUB.

Both EFI_BOOT_SERVICES_DATA and EFI_LOADER_DATA are meant to be gone
past ExitBootServices(). EfiACPIReclaimMemory is were the UEFI payload
is adviced to consider if keeping the memory at runtime is needed.

The current patch therefore makes no difference to Linux before
ExitBootServices(). A side effect could be that Linux unnecessarily
keeps the EfiACPIReclaimMemory instead of reusing it. But Linux's
is_usable_memory() in drivers/firmware/efi/arm-init.c treats
EFI_ACPI_RECLAIM_MEMORY, EFI_ACPI_RECLAIM_MEMORY,
EFI_ACPI_RECLAIM_MEMORY just the same.


Okay. Works for me.

g.


@Daniel, Leif
A patch for the EBBR specification suggests to use
EFI_ACPI_RECLAIM_MEMORY for the devicetree passed to Linux. Please,
consider if you would apply this in GRUB too.

Best regards

Heinrich



g.


---
   cmd/bootefi.c  | 4 ++--
   lib/efi_selftest/efi_selftest_memory.c | 4 ++--
   2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 54b4b8f984..06573b14e9 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -127,13 +127,13 @@ static efi_status_t copy_fdt(void **fdtp)
   new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 +
    fdt_size, 0);
   ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
- EFI_BOOT_SERVICES_DATA, fdt_pages,
+ EFI_ACPI_RECLAIM_MEMORY, fdt_pages,
    _fdt_addr);
   if (ret != EFI_SUCCESS) {
   /* If we can't put it there, put it somewhere */
   new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size);
   ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
- EFI_BOOT_SERVICES_DATA, fdt_pages,
+ EFI_ACPI_RECLAIM_MEMORY, fdt_pages,
    _fdt_addr);
   if (ret != EFI_SUCCESS) {
   printf("ERROR: Failed to reserve space for FDT\n");
diff --git a/lib/efi_selftest/efi_selftest_memory.c
b/lib/efi_selftest/efi_selftest_memory.c
index e71732dc6d..4d32a28006 100644
--- a/lib/efi_selftest/efi_selftest_memory.c
+++ b/lib/efi_selftest/efi_selftest_memory.c
@@ -176,9 +176,9 @@ static int execute(void)
   /* Check memory reservation for the device tree */
   if (fdt_addr &&
   find_in_memory_map(map_size, memory_map, desc_size, fdt_addr,
-   EFI_BOOT_SERVICES_DATA) != EFI_ST_SUCCESS) {
+   EFI_ACPI_RECLAIM_MEMORY) != EFI_ST_SUCCESS) {
   efi_st_error
-    ("Device tree not marked as boot services data\n");
+    ("Device tree not marked as ACPI reclaim memory\n");
   return EFI_ST_FAILURE;
   }
   return EFI_ST_SUCCESS;
--
2.26.2

Re: [PATCH v2 1/1] efi_loader: put device tree into EfiACPIReclaimMemory

2020-05-11 Thread Grant Likely


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


Is there any impact to changing the memory type for current users? Does 
the kernel currently expect the EFI_BOOT_SERVICES_DATA memory type? What 
happens if Grub or another EFI application replaces the DTB table? Will 
it try to use a different memory type, and will that matter?


g.


---
  cmd/bootefi.c  | 4 ++--
  lib/efi_selftest/efi_selftest_memory.c | 4 ++--
  2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/cmd/bootefi.c b/cmd/bootefi.c
index 54b4b8f984..06573b14e9 100644
--- a/cmd/bootefi.c
+++ b/cmd/bootefi.c
@@ -127,13 +127,13 @@ static efi_status_t copy_fdt(void **fdtp)
new_fdt_addr = (uintptr_t)map_sysmem(fdt_ram_start + 0x7f0 +
 fdt_size, 0);
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
-EFI_BOOT_SERVICES_DATA, fdt_pages,
+EFI_ACPI_RECLAIM_MEMORY, fdt_pages,
 _fdt_addr);
if (ret != EFI_SUCCESS) {
/* If we can't put it there, put it somewhere */
new_fdt_addr = (ulong)memalign(EFI_PAGE_SIZE, fdt_size);
ret = efi_allocate_pages(EFI_ALLOCATE_MAX_ADDRESS,
-EFI_BOOT_SERVICES_DATA, fdt_pages,
+EFI_ACPI_RECLAIM_MEMORY, fdt_pages,
 _fdt_addr);
if (ret != EFI_SUCCESS) {
printf("ERROR: Failed to reserve space for FDT\n");
diff --git a/lib/efi_selftest/efi_selftest_memory.c 
b/lib/efi_selftest/efi_selftest_memory.c
index e71732dc6d..4d32a28006 100644
--- a/lib/efi_selftest/efi_selftest_memory.c
+++ b/lib/efi_selftest/efi_selftest_memory.c
@@ -176,9 +176,9 @@ static int execute(void)
/* Check memory reservation for the device tree */
if (fdt_addr &&
find_in_memory_map(map_size, memory_map, desc_size, fdt_addr,
-  EFI_BOOT_SERVICES_DATA) != EFI_ST_SUCCESS) {
+  EFI_ACPI_RECLAIM_MEMORY) != EFI_ST_SUCCESS) {
efi_st_error
-   ("Device tree not marked as boot services data\n");
+   ("Device tree not marked as ACPI reclaim memory\n");
return EFI_ST_FAILURE;
}
return EFI_ST_SUCCESS;
--
2.26.2

Re: [PATCH 3/8] qemu: arm64: Add support for efi firmware management protocol routines

2020-05-06 Thread Grant Likely

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 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 are
   > part of the efi firmware management protocol.
   >
   > The current implementation uses the set_image routine for
updating the
   > u-boot binary image for the qemu arm64 platform. This is
supported
   > using the capsule-on-disk feature of the uefi specification,
wherein
   > the firmware image to be updated is placed on the efi system
partition
   > as a efi capsule under EFI/UpdateCapsule/ directory. Support
has been
   > added for updating the u-boot image on platforms booting
with arm
   > trusted firmware(tf-a), where the u-boot image gets booted as
the BL33
   > payload(bl33.bin).
   >
   > The feature can be enabled by the following config options
   >
   > CONFIG_EFI_CAPSULE_ON_DISK=y
   > CONFIG_EFI_FIRMWARE_MANAGEMENT_PROTOCOL=y
   >
   > Signed-off-by: Sughosh Ganu mailto:sughosh.g...@linaro.org>>

   U-Boot's UEFI subsystem should work in the same way for x86,
ARM, and
   RISC-V. Please, come up with an architecture independent
solution.

Please check the explanation that I gave in the other mail. If you
check
the patch series, the actual capsule authentication logic has been
kept
architecture agnostic, in efi_capsule.c. The fmp protocol is very much
intended for allowing platforms to define their firmware update
routines. Edk2 also has platform specific implementation of the fmp
protocol under the edk2-platforms directory.

-sughosh

My idea is that for most platforms it will be enough to have a common
FMP implementation that consumes a capsule

* with one or more binaries
* a media device path, a start address, and a truncation flag
 for each of the binaries

The protocol implementation then will write the binaries to the device
paths:

* to an SD-Card or eMMC exposing the Block IO protocol
 for most devices
* to a file in case of the Raspberry Pi or the Sandbox or QEMU
 (and truncate it if the truncation flag is set)

Does U-Boot have a common device path protocol that can be backed by
either a block device or a file on a filesystem? I didn't think it did.

A block device, a partition, and a file all can be described by an UEFI
media device path.

Sure, from a UEFI media path, but does the underlying U-Boot
implementation have that abstraction?

With a file media path we can find the partition device path on which
the Simple file protocol is already installed by U-Boot.

In the mean time, there are at least three backends that the FMP is
going to have to deal with; the two you list above (block device & file)
and SMC backed when updating firmware is managed by the secure world.
This first implementation only handles the file-backed use case. Can we
start with that limitation and refactor when the block-device and SMC
use cases are added in? I would hate to see this functionality held up
on having to refactor other functionality in U-Boot.

I would prefer one single FMP driver for all SMC use cases. Everything
device specific should be handled in the secure world.

Not all platforms will be able to put firmware update into the secure
world. For instance, Not many Arm v7 platforms have trustzone accessible
to open source developers. On non-secure platforms (e.g., anything that
loads firmware from a regular filesystem on SD or eMMC) it doesn't make
much sense to loop out to secure firmware when U-Boot owns the
filesystem and the secure world would then need to coordinate with
U-Boot to commit the writes.

All of the code can certainly be in the same location, but I do think
there are three distinct generic backends for firmware updates:
- normal-world file-backed (using filesystem)
- normal-world block-backed (offsets from start of device)

These two could be in one instance of the FMP protocol.

- secure device backed (needs to go into secure world for unpacking and
processing regardless)

There doesn't need to be platform-specific code in any of those back
ends, but they do have different behaviour.

Is there already a protocol defined for the communication of capsule
updates between the firmware and the secure monitor, e.g. in EDK2?

Nothing defined yet (see below)

Would we simply use the UpdateCapsule() call parameters and pass them
via an SMC call?

If secure world is handling the update? Yes, I think a thin
UpdateCapsule() SMC makes sense, with the bonus that UpdateCapsule() at
runtime becomes feasible on U-Boot.

Re: [PATCH 3/8] qemu: arm64: Add support for efi firmware management protocol routines

2020-05-05 Thread Grant Likely

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:36 PM, Sughosh Ganu wrote:
  > Add support for the get_image_info and set_image routines,
which are
  > part of the efi firmware management protocol.
  >
  > The current implementation uses the set_image routine for
updating the
  > u-boot binary image for the qemu arm64 platform. This is
supported
  > using the capsule-on-disk feature of the uefi specification,
wherein
  > the firmware image to be updated is placed on the efi system
partition
  > as a efi capsule under EFI/UpdateCapsule/ directory. Support
has been
  > added for updating the u-boot image on platforms booting with arm
  > trusted firmware(tf-a), where the u-boot image gets booted as
the BL33
  > payload(bl33.bin).
  >
  > The feature can be enabled by the following config options
  >
  > CONFIG_EFI_CAPSULE_ON_DISK=y
  > CONFIG_EFI_FIRMWARE_MANAGEMENT_PROTOCOL=y
  >
  > Signed-off-by: Sughosh Ganu mailto:sughosh.g...@linaro.org>>

  U-Boot's UEFI subsystem should work in the same way for x86,
ARM, and
  RISC-V. Please, come up with an architecture independent solution.

Please check the explanation that I gave in the other mail. If you check
the patch series, the actual capsule authentication logic has been kept
architecture agnostic, in efi_capsule.c. The fmp protocol is very much
intended for allowing platforms to define their firmware update
routines. Edk2 also has platform specific implementation of the fmp
protocol under the edk2-platforms directory.

-sughosh

My idea is that for most platforms it will be enough to have a common
FMP implementation that consumes a capsule

* with one or more binaries
* a media device path, a start address, and a truncation flag
for each of the binaries

The protocol implementation then will write the binaries to the device
paths:

* to an SD-Card or eMMC exposing the Block IO protocol
for most devices
* to a file in case of the Raspberry Pi or the Sandbox or QEMU
(and truncate it if the truncation flag is set)

Does U-Boot have a common device path protocol that can be backed by
either a block device or a file on a filesystem? I didn't think it did.

A block device, a partition, and a file all can be described by an UEFI
media device path.

Sure, from a UEFI media path, but does the underlying U-Boot
implementation have that abstraction?

In the mean time, there are at least three backends that the FMP is
going to have to deal with; the two you list above (block device & file)
and SMC backed when updating firmware is managed by the secure world.
This first implementation only handles the file-backed use case. Can we
start with that limitation and refactor when the block-device and SMC
use cases are added in? I would hate to see this functionality held up
on having to refactor other functionality in U-Boot.

I would prefer one single FMP driver for all SMC use cases. Everything
device specific should be handled in the secure world.

Not all platforms will be able to put firmware update into the secure
world. For instance, Not many Arm v7 platforms have trustzone accessible
to open source developers. On non-secure platforms (e.g., anything that
loads firmware from a regular filesystem on SD or eMMC) it doesn't make
much sense to loop out to secure firmware when U-Boot owns the
filesystem and the secure world would then need to coordinate with
U-Boot to commit the writes.

All of the code can certainly be in the same location, but I do think
there are three distinct generic backends for firmware updates:
- normal-world file-backed (using filesystem)
- normal-world block-backed (offsets from start of device)
- secure device backed (needs to go into secure world for unpacking and
processing regardless)

There doesn't need to be platform-specific code in any of those back
ends, but they do have different behaviour.

Is there already a protocol defined for the communication of capsule
updates between the firmware and the secure monitor, e.g. in EDK2?

Nothing defined yet (see below)

Would we simply use the UpdateCapsule() call parameters and pass them
via an SMC call?

If secure world is handling the update? Yes, I think a thin
UpdateCapsule() SMC makes sense, with the bonus that UpdateCapsule() at
runtime becomes feasible on U-Boot. There are a couple of people inside
Arm looking at possible interfaces. In this situation there is very
little done in normal-world at all.

[...]

According to my call with Sughosh the whole semihosting thing is about
providing a testing possibility not about any real use case.

Yes, it's for testing, but it

Re: [PATCH 3/8] qemu: arm64: Add support for efi firmware management protocol routines

2020-05-05 Thread Grant Likely

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 are
 > part of the efi firmware management protocol.
 >
 > The current implementation uses the set_image routine for updating the
 > u-boot binary image for the qemu arm64 platform. This is supported
 > using the capsule-on-disk feature of the uefi specification, wherein
 > the firmware image to be updated is placed on the efi system partition
 > as a efi capsule under EFI/UpdateCapsule/ directory. Support has been
 > added for updating the u-boot image on platforms booting with arm
 > trusted firmware(tf-a), where the u-boot image gets booted as the BL33
 > payload(bl33.bin).
 >
 > The feature can be enabled by the following config options
 >
 > CONFIG_EFI_CAPSULE_ON_DISK=y
 > CONFIG_EFI_FIRMWARE_MANAGEMENT_PROTOCOL=y
 >
 > Signed-off-by: Sughosh Ganu mailto:sughosh.g...@linaro.org>>

 U-Boot's UEFI subsystem should work in the same way for x86, ARM, and
 RISC-V. Please, come up with an architecture independent solution.

Please check the explanation that I gave in the other mail. If you check
the patch series, the actual capsule authentication logic has been kept
architecture agnostic, in efi_capsule.c. The fmp protocol is very much
intended for allowing platforms to define their firmware update
routines. Edk2 also has platform specific implementation of the fmp
protocol under the edk2-platforms directory.

-sughosh

My idea is that for most platforms it will be enough to have a common
FMP implementation that consumes a capsule

* with one or more binaries
* a media device path, a start address, and a truncation flag
   for each of the binaries

The protocol implementation then will write the binaries to the device
paths:

* to an SD-Card or eMMC exposing the Block IO protocol
   for most devices
* to a file in case of the Raspberry Pi or the Sandbox or QEMU
   (and truncate it if the truncation flag is set)

Does U-Boot have a common device path protocol that can be backed by
either a block device or a file on a filesystem? I didn't think it did.

In the mean time, there are at least three backends that the FMP is
going to have to deal with; the two you list above (block device & file)
and SMC backed when updating firmware is managed by the secure world.
This first implementation only handles the file-backed use case. Can we
start with that limitation and refactor when the block-device and SMC
use cases are added in? I would hate to see this functionality held up
on having to refactor other functionality in U-Boot.

If for some devices like a SPI flash we do not have a media device path
yet, then the only platform specific bit would be the block device
driver exposing the media device path.

Same with a semi-hosted file: just add a driver exposing it as a media
path with an EFI_BLOCK_IO_PROTOCOL.

Sughosh and I chatted about this and took a look a the semihosting
driver. Right now it is a standalone component implementing only the
smhload command. It looks like it easily maps onto fstype_info
operations which would be a better fit than the block IO protocol. Am I
correct in assuming that would also make semihosting available to the
EFI_FILE_PROTOCOL? The FMP backend code could be common for all
filesystem targets, with the only platform specific bit being the path
to the firmware files.

How does that sound?

g.

For security reasons it may be advisable to make the device read-only
when reaching ExitBootServices() or even better before the first
execution of StartImage(). For this purpose we could use the Reset()
service of the EFI_BLOCK_IO_PROTOCOL or provide a U-Boot specific
service in the EFI_BLOCK_IO_PROTOCOL.

Best regards

Heinrich

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

[U-Boot] Rpi4 u-boot

2019-10-14 Thread Al Grant

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 when I added one, it still went to the Suse GRUB.
I note that when I tried to compile u-boot 2019 v10 it seemed to compile
ok, but no dtb files where generated?
If I copied just the uboot.bin file there is no output on my serial port to
indicate that it is working? And again without the ability to make any
changes via uEnv.txt I am a bit stuck.

Any help would be much appreciated.

Thanks

Al


-- 
"Beat it punk!"
- Clint Eastwood
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] RSA in U-Boot

2019-08-27 Thread Grant Likely

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 been able to find any recent postings.

Thanks,
g.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] U-Boot/EBBR plugfest at ELC-EU?

2019-08-08 Thread Grant Likely



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 issues between OS distros and upstream U-Boot SBC 
> support. The idea is to get a number of SBCs supported by mainline U-Boot 
> with UEFI features turned on, along with U-Boot & OS developers and hold a 1 
> day debug sprint to work out how many platforms can work with ‘stock’ OS 
> images. Details to be worked out if this looks viable.
> 
> I’ve asked the LF folks if they have space on either Thursday 31st Oct or 
> Friday 1st Nov. They are checking availability, but no commitments have been 
> made. It would help to know if this date and location is feasible.
> 
> What do you think? Would you come to a plug fest attached to ELC-EU? Would 
> you be interested in helping to organise? Or, is there another time & 
> location that would work better?
> 
> Cheers,
> g.

At this point I've only had about 3 people say they'd be able to attend. 
That's not enough for critical mass. I think we should defer to another 
event.

I'm going to tell the LF that they can release the space they've 
reserved for us and I'll look at the calendar and come up with some new 
options.

g.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] (Offlist) Re: U-Boot/EBBR plugfest at ELC-EU?

2019-08-08 Thread Grant Likely

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
>>> expert drop me a line.
>>
>> Thanks Daniel,
>>
>> It is certainly a worthy discussion topic for LPC. I’ll see if I can
>> draft something for the CfP on Friday. Unfortunately, I may not be at
> 
> Please do it!
> 
>> LPC. I’m not even on the waiting list yet.
> 
> I cannot promise anything but if we accept your proposal then there is a
> chance that you will get a pass from us.
> 
> Daniel

Hi Daniel,

Sorry, I wasn't able to get anything submitted before the deadline, and 
I'm not going to be able to attend LPC this year anyway. I think it is a 
worthwhile to discuss UEFI & UEFI Secure Boot support in U-Boot, but it 
depends entirely on who will be in the room. I'll let someone else pick 
up the thread if they are attending.

g.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] (Offlist) Re: U-Boot/EBBR plugfest at ELC-EU?

2019-07-30 Thread Grant Likely

>> 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 date hasn't been decided yet,
> and is likely to end up around the same time. And actually another
> unrelated event too.
>
> Certainly, Lyon is a quite convenient train journey from here :)
>
> But I'm also happy to look into GRUB issues on 32-bit systems remotely
> if someone could point me at them.

 I am not planning to be at ELC-E but I can help remotely if it is
 needed. However, there is another option. There is pretty good chance
 that I will get a MC slot at LPC. I am looking for people who want to
 talk. The overall plan is to devote this MC for boot stuff with focus
 on security. So, this maybe good place to discuss this. However, I am
 not ARM expert, so, I would like to see Leif and/or Alex or somebody
 else familiar with ARM stuff there too.
>>>
>>> If I can get a ticket, I'm already intending to attend plumbers.
>>>
>>> Registered on the waiting list.
>
> Folks, our LPC MC was accepted:
>  
> https://linuxplumbersconf.org/event/4/page/34-accepted-microconferences#security
>  
> https://www.linuxplumbersconf.org/blog/2019/system-boot-and-security-microconference-accepted-into-2019-linux-plumbers-conference/
>
> 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
> expert drop me a line.

Thanks Daniel,

It is certainly a worthy discussion topic for LPC. I’ll see if I can draft 
something for the CfP on Friday. Unfortunately, I may not be at LPC. I’m not 
even on the waiting list yet.

Having an LPC topic is separate from the plugfest idea which is intended to be 
a hacking sprint. I need to make a decision ASAP so I can give the LF an answer 
by 8th Aug. Who is available Monday at 16:00BST to discuss?

g.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] U-Boot/EBBR plugfest at ELC-EU?

2019-06-28 Thread Grant Likely

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 to get a number of SBCs supported by mainline U-Boot with 
UEFI features turned on, along with U-Boot & OS developers and hold a 1 day 
debug sprint to work out how many platforms can work with ‘stock’ OS images. 
Details to be worked out if this looks viable.

I’ve asked the LF folks if they have space on either Thursday 31st Oct or 
Friday 1st Nov. They are checking availability, but no commitments have been 
made. It would help to know if this date and location is feasible.

What do you think? Would you come to a plug fest attached to ELC-EU? Would you 
be interested in helping to organise? Or, is there another time & location that 
would work better?

Cheers,
g.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] EFIBootGuard for CIP and SecureBoot

2019-04-26 Thread Grant Likely

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
> 
> Conceptually, it can. It's a matter of validating the update by the 
> trusted world before using it. A trusted instance can allow an untrusted 
> one to write version 2, validate that before switching to it, and stick 
> with version 1 if that fails.
> 
>> 2) what the UEFI implementation does with the capsule is platform 
>> specific
>> 3) the update capsule payload is opaque
>>
>> 1) is a "philosophy" decision. When you have a root of trust down to
>> the operating system. So in theory everything should be fine. But the
>> attack surface is such that we can't rule out hacking (and history
>> prove this is unfortunately a safe assumption). In addition, there may
>> be liability aspects related to the who does the update: the hardware
>> platform administrator may not be the legal entity than the operating
>> system administrator. For instance:
>> -  on Packet.net could, a customer can flash up to the BL33 untrusted
>> firmware but that is all.
>> - A surveillance camera can be operated by city personnel but only law
>> enforcement agency can see raw video (un-blurred faces and licence
>> plates). This can be implemented by a derivative of OPTEE SecureMedia
>> Path but if you allow untrusted world to update the trusted one, city
>> personnel can overcome the legal restriction.
>> With 1) this means that even U-Boot code shall not be able/allowed to
>> update S-EL3 firmware (be it Trusted Firmware A or something else),
>> Secure EL1/0 software (OPTEE and its applications or something else).
>> If possible, allowing the operating system administrator to
>> selectively (BL33 is OK but not S-EL3) update firmware is at least
>> platform dependent. Hence defeats 0)
>>
>> With 2) we do not impose reboot to update. Some platform may impose
>> reboot or some designers will prefer reboot. We say that there is a
>> chain of responsibility for updates.
>> So it is perfectly OK to have a Linux software agent receive an update
>> by any mean (network, USB, serial...). The agent will pack this (or
>> those) into a capsule and push it to UEFI implementation.
>> The UEFI implementation (U-Boot or Tianocore) will then do whatever it
>> pleases for the update providing it complies with 1) So the UEFI
>> implementation can live update up to BL33 firmware.
>> Should the update be targeted to secure world, then the UEFI
>> implementation can pass it to S-EL3 for update (platform specific)
>> which means the update can also be live. It is a designer decision.
>>
>> With 3) we have flexibility but sometimes too much flexibility is a
>> problem. Alexander Graf suggested we can use a FIT object to pass
>> diverse objects. It is "half" opaque but I really like the idea.
>> The contents of individual FIT components can be blocks to be placed
>> at a fix location in a NOR flash or a file, no importance.
>>
>> What do everyone think about those design principles ?
>>
> 
> UEFI and capsules can be fine for those platform that support it (and 
> it's still a rare feature) and for stuff like boot and peripheral 
> firmware. I don't think it's a wise, future-proof idea to use it for more.
> 
> UEFI is not a very healthy ecosystem yet, and I'm personally skeptical 
> it will evolve towards that (looking at that as both a user as well as 
> an OEM). It's not even present in quite a few of our use cases. In some 
> it will never be - think of safety-critical system: not affordable with 
> such a complex approach like UEFI.

Can I challenge that view a bit? On the Tianocore side I agree that the 
ecosystem isn't very healthy. That project in particular struggles with 
what to do with board support, having decided early on that board 
support generally doesn't need to be in the main repository.

However, U-Boot support for the UEFI ABI is improving in leaps and 
bounds. SUSE and Fedora both depend on U-Boot UEFI for booting on all 
the Arm SBCs that they support, and enabling UEFI in U-Boot is just a 
config option or two. There is a fair bit of encouragement from within 
the project to enable UEFI by default.

UEFI gets a bad rap at being complicated, but I think the U-Boot work 
has shown that implementing the core UEFI ABI doesn't require much code 
and isn't the complicated mess they everyone fears it to be.

I don't see the conflict with safety critical for boot services. I can 
however see the arguement against UEFI runtime services as a poor 
implementation could result in unbounded execution times. There's been 
recent movement on the UEFI spec to make runtime services optional, and 
in U-Boot they are mostly empty stubs.

> It should not expand further into OS 
> domains. Updating complete filesystems and their content is beyond its 
>

Re: [U-Boot] EFIBootGuard for CIP and SecureBoot

2019-04-24 Thread Grant Likely

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 send this reply and hope it will not be 
> blocked. I have also added the u-boot mailing list to Cc, as Tom suggested 
> (although I'm not a member), the CIP mailing list, Jan Kiszka (one of the 
> main developers of Efibootguard) and Christian (an expert in software 
> updates).

Hmmm, that's weird. The boot-architecture list doesn't require approval 
to subscribe. It just requires confirmation of email address. I think 
there is a problem with lists.linaro.org. I'll send an IT support 
request to Linaro.

Regardless, I've approved this post and added you to the allowed senders 
list. You can post freely. :-)

g.

> Background: during the last Linaro connect in Bangkok I was told that Linaro 
> Edge (LEDGE) were working on a secure software update mechanism based on UEFI 
> capsules that would flash firmware updates from a UEFI application, instead 
> of using a Linux agent such as SWUpdate. Then, I had an online meeting with 
> Francois, director of LEDGE. I explained to Francois that in CIP we are using 
> the Linux agent approach right now, and we are also considering the use of a 
> UEFI application (Efibootguard) to arm a watchdog and deal with the 
> state-machine variables (installed, testing, ok, failed..) needed for A/B 
> software updates. Efibootguard sounds like an excellent place to collaborate 
> with Linaro (particularly on the watchdog drivers front) because it does not 
> strictly depend on where the firmware is flashed (UEFI capsule or Linux 
> agent).
> 
>> On Fri, Apr 19, 2019 at 12:48:51PM +0200, Francois Ozog wrote:
>>> Hi Daniel,
>>>
>>> We will be conducting a UEFI gap analysis to support EFIBootGuard in U-Boot.
>>>
>>> As we are working on UEFI SecureBoot implementation in U-Boot, how do
>>> you expect the boot process to be secured? Would U-Boot UEFI
>>> SecureBoot verify EFIBootGuard signature and in turn EFIBootGuard will
>>> check either grub or Linux signature?
>>>
>>> Please elaborate on your vision of a secured boot process.
> 
> Efibootguard is composed of two parts.
>- A UEFI application that can arm a watchdog and decide what environment 
> (kernel, boot args, etc.) to use next depending on a set of variables (update 
> status, highest revision, etc.) stored in FAT16 partitions.
>- A Linux application that can read and set those variables from Linux 
> (similar to u-boot's fw_setenv). This functionality is also available in the 
> form of a library.
> 
> As far as I know, there is no concept of "Secure Booting" in Efibootguard at 
> the moment. Adding signature checks before booting into the selected kernel 
> would be a possible solution.
> 
> Thanks,
> Daniel
> 
> 
> 
> ___
> boot-architecture mailing list
> boot-architect...@lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Can't boot my FIT image: 'Could not find configuration node'

2018-08-08 Thread Grant Jurgensen

Hi Johann,

I apologize, that typo is actually just in the email. My actual file has
"kernel-0" in both locations. It seems my fit image is formed correctly
based on the header information:

...$ mkimage -F sel4.itb
FIT description: SeL4
Created: Tue Aug  7 10:56:42 2018
 Image 0 (kernel-0)
  Description:  SeL4 image
  Created:  Tue Aug  7 10:56:42 2018
  Type: Kernel Image
  Compression:  uncompressed
  Data Size:1033080 Bytes = 1008.87 kB = 0.99 MB
  Architecture: ARM
  OS:   QNX
  Load Address: 0x4800
  Entry Point:  0x4800
 Default Configuration: '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...@dh-electronics.de> wrote:

> Dear Grant,
>
> I see there is a typo in your kernel node name.
>
> In the image section you wrote kerne-0 and in the config section you wrote
> kernel = "kernel-0";
> Probably this is the issue that no config and kernel  image is found.
>
> Regards,
>
> Johann Neuhauser
>
> > -Ursprüngliche Nachricht-
> > Von: U-Boot [mailto:u-boot-boun...@lists.denx.de] Im Auftrag von Grant
> > Jurgensen
> > Gesendet: Montag, 6. August 2018 19:50
> > An: u-boot@lists.denx.de
> > Betreff: [U-Boot] Can't boot my FIT image: 'Could not find configuration
> > node'
> >
> > Hi,
> >
> > I'm using U-boot to boot an ELF image. I am easily able to load the
> image into
> > memory and boot it with the `bootelf` command. However, I'd like to
> create
> > a FIT image in order to make use of the convenient hashing and secure
> boot
> > features, but I'm having trouble getting my image to boot.
> >
> > Here is my current `.its` file (currently as simple as possible until I
> get it to
> > boot):
> >
> > /dts-v1/;
> >
> > / {
> > description = "SeL4";
> > #address-cells = <1>;
> >
> > images {
> > kerne-0 {
> > description = "SeL4 image";
> > data = /incbin/("./test_app-image-arm-exynos5");
> > type = "kernel";
> > arch = "arm";
> > os = "qnx";
> > compression = "none";
> > load = <0x4800>;
> > entry = <0x4800>;
> > };
> > };
> >
> > configurations {
> > default = "config-0";
> > config-0 {
> >  description = "default config";
> >  kernel = "kernel-0";
> > };
> > };
> > };
> >
> > By the way, my ELF image isn't actually a qnx kernel. It is a sel4
> kernel,
> > however "sel4" is not an option. (I can make a uImage with `mkimage -A
> arm
> > -a 0x4800 -e 0x4800 -C none -T kernel -O qnx -d
> > test_app-image-exynos5 image` and can actually boot the resulting image
> > here with `bootm` no problem, so I believe using the qnx OS setting
> > shouldn't be a problem.)
> >
> > I am then able to create the FIT image with `mkimage -f sel4.its
> sel4.itb`.
> > I copy this image to my SD card, successfully load the fit image into
> memory
> > (with `fatload`), but then `bootm` fails with the following message:
> >
> > ## Loading kernel from FIT Image at 5000 ...
> > Could not find configuration node
> > ERROR: can'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
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Can't boot my FIT image: 'Could not find configuration node'

2018-08-06 Thread Grant Jurgensen

Hi,

I'm using U-boot to boot an ELF image. I am easily able to load the image
into memory and boot it with the `bootelf` command. However, I'd like to
create a FIT image in order to make use of the convenient hashing and
secure boot features, but I'm having trouble getting my image to boot.

Here is my current `.its` file (currently as simple as possible until I get
it to boot):

/dts-v1/;

/ {
description = "SeL4";
#address-cells = <1>;

images {
kerne-0 {
description = "SeL4 image";
data = /incbin/("./test_app-image-arm-exynos5");
type = "kernel";
arch = "arm";
os = "qnx";
compression = "none";
load = <0x4800>;
entry = <0x4800>;
};
};

configurations {
default = "config-0";
config-0 {
 description = "default config";
 kernel = "kernel-0";
};
};
};

By the way, my ELF image isn't actually a qnx kernel. It is a sel4 kernel,
however "sel4" is not an option. (I can make a uImage with `mkimage -A arm
-a 0x4800 -e 0x4800 -C none -T kernel -O qnx -d
test_app-image-exynos5 image` and can actually boot the resulting image
here with `bootm` no problem, so I believe using the qnx OS setting
shouldn't be a problem.)

I am then able to create the FIT image with `mkimage -f sel4.its sel4.itb`.
I copy this image to my SD card, successfully load the fit image into
memory (with `fatload`), but then `bootm` fails with the following message:

## Loading kernel from FIT Image at 5000 ...
Could not find configuration node
ERROR: can'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

[U-Boot] EBBR v0.6 Release Announcement

2018-07-13 Thread Grant Likely

I'm pleased to announce the release of version 0.6 of the Embedded Base 
Boot Requirements (EBBR) specification.


https://github.com/ARM-software/ebbr/releases/tag/v0.6

EBBR is a new specification defining a standard boot environment 
suitable for full feature operating systems running on embedded platforms...


Well, it will when it's finished.

It is well know that firmware for embedded systems is a fragmented area 
with each platform behaving in subtly incompatible ways. It is also 
completely different from the firmware interface used on general purpose 
desktops and servers. For OSes, this makes supporting more than a 
handful of platforms a nearly impossible affair. EBBR aims to solve this 
problem by defining a standard boot interface that can easily be 
implemented using either U-Boot or Tianocore, and is based on the same 
UEFI specification used on general purpose computers.


By adopting EBBR, platform vendors can reduce the amount of engineering 
effort required to support their products and make them easier to use. 
As EBBR is being developed in conjunction with the U-Boot, Tianocore, 
and Trusted Firmware projects, most of the functionality required is 
already implemented and ready to be used if one uses an up to date 
release of U-Boot or Tianocore.


For OS vendors, this makes far easier to support embedded platforms 
because they don't need to tailor the boot process for each platform. 
The same boot infrastructure works on both desktop/servers and on EBBR 
compliant embedded platforms.


And finally, for end users, working with an EBBR compliant platform 
means they can boot the OS of their choice without needing to learn low 
level details of the platform firmware.


This v0.6 release of EBBR is a pre-release document. The contents are 
not final. The purpose of this release is to raise awareness of the EBBR 
project, and to solicit feedback on the current draft. Please do read 
and provide comments on the boot-architect...@lists.linaro.org mailing list.


The plan is to release v1.0 before the end of the 2018.

Thanks to the EBBR committee members who contributed to this release:

  Andreas Färber (SUSE)
  Alex Graf (SUSE)
  Ryan Harkin (Linaro)
  Rob Herring (Linaro)
  Udit Kumar (NXP)
  Leif Lindholm (Linaro)
  Bill Mills (TI)
  Peter Robinson (Red Hat)
  Tom Rini (Konsulko)
  Daniel Thompson (Linaro)
  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 written before EBBR v1.0 is released.


There is also work ongoing to get the UEFI Self Certification Test 
running on U-Boot. Once working, this will be a tool for vendors to test 
their platforms for EBBR compliance.


FAQ
---
1. Does EBBR define a new interface?

   No. EBBR builds on the existing UEFI spec by requiring a specific 
subset that can be implemented today using U-Boot, and either Devicetree 
or ACPI.


2. Does EBBR require Devicetree? ACPI?

   EBBR allows platforms to provide either ACPI or Devicetree. Linux 
supports both system description languages equally well, and Devicetree 
is in common use on embedded platforms. As long as the platform supplies 
a system description that can boot a mainline operating system.


   EBBR does not attempt to define a common base standard for 
Devicetree platforms because of the wide variety of platforms needed to 
be supported. The one assumption EBBR does make is that the target 
operating system already has support for the SoC on the platform.


3. Is EBBR only for U-Boot and Linux embedded systems?

   No. While U-Boot+Linux platforms were certainly the primary audience 
when EBBR was first conceived, the spec is very purposefully written to 
be OS-independent. EBBR requires specific interfaces, but those 
interface can be implemented by any firmware project.


   We would absolutely like to have review, feedback and contributions 
from non-Linux, non-U-Boot users.


4. Can I contribute to the EBBR specification?

   Yes. The EBBR source document is on GitHub, and we use the 
boot-architect...@lists.linaro.org mailing list.


   https://github.com/ARM-Software/ebbr
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Devicetree specification process

2016-04-30 Thread Grant Likely

On Sat, Apr 30, 2016 at 12:23 AM, Grant Likely <grant.lik...@linaro.org> 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 announcing it now along with the new devicetree.org organization
> which will handle governance for the spec.
>
> We're still in the process of getting all the details sorted out (not
> everything on the website is accurate at the moment), but in the mean
> time you can look at the current state of the document. At the moment,
> it is little more than repackaging the ePAPR text. The next step will
> be pulling in the new core bindings that were never covered by ePAPR.
> You can look at a draft copy of the document here:
>
> https://github.com/kvekaria/devicetree-specification-released/blob/master/prerelease/DevicetreeSpecification-20160429-pre1.pdf

Oops, wrong link. This should be:

https://github.com/devicetree-org/devicetree-specification-released/blob/master/prerelease/devicetree-specification-v0.1-pre1-20160429.pdf

g.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Devicetree specification process

2016-04-29 Thread Grant Likely

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 governance for the spec.

We're still in the process of getting all the details sorted out (not
everything on the website is accurate at the moment), but in the mean
time you can look at the current state of the document. At the moment,
it is little more than repackaging the ePAPR text. The next step will
be pulling in the new core bindings that were never covered by ePAPR.
You can look at a draft copy of the document here:

https://github.com/kvekaria/devicetree-specification-released/blob/master/prerelease/DevicetreeSpecification-20160429-pre1.pdf

If you want to help out, the document source markup can be cloned from
GitHub. You can find the project page here:

https://github.com/devicetree-org/devicetree-specification

Feedback is greatly appreciate. Please send any comments and/or
changes to the devicetree specification mailing list:

devicetree-s...@vger.kernel.org

For more information, you can refer to the slides presented at BKK16 and ELC[1].

[1] 
http://elinux.org/images/b/b7/Devicetree_specification_linaro_connect_bangkok_2016.pdf

Thanks,
g.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] sunxi: video: Add simplefb support

2014-11-17 Thread Grant Likely

On Sun, Nov 16, 2014 at 7:39 PM, Hans de Goede hdego...@redhat.com wrote:
 From: Luc Verhaegen l...@skynet.be

 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 l...@skynet.be
 [hdego...@redhat.com: Use pre-populated simplefb node under /chosen as
  disussed on the devicetree list]
 Signed-off-by: Hans de Goede hdego...@redhat.com

I'm not a U-Boot maintainer, so take my comments with a grain of salt...

This patch seems quite short sighted. The code that calculates and
updates the simple framebuffer node addresses is pretty much going to
be identical for all platforms. Why is sunxi open coding it?
Particularly when there could be fiddly bits around dealing with
#address-cells/#size-cells.

I would think the code to update a simplefb node would be a common
library function.

g.


 ---
  arch/arm/include/asm/arch-sunxi/display.h |  4 ++
  board/sunxi/board.c   | 11 +
  drivers/video/sunxi_display.c | 73 
 +++
  include/configs/sunxi-common.h|  8 
  4 files changed, 96 insertions(+)

 diff --git a/arch/arm/include/asm/arch-sunxi/display.h 
 b/arch/arm/include/asm/arch-sunxi/display.h
 index 8d80ceb..4c694f8 100644
 --- a/arch/arm/include/asm/arch-sunxi/display.h
 +++ b/arch/arm/include/asm/arch-sunxi/display.h
 @@ -195,4 +195,8 @@ struct sunxi_hdmi_reg {
  #define SUNXI_HDMI_PLL_DBG0_PLL3   (0  21)
  #define SUNXI_HDMI_PLL_DBG0_PLL7   (1  21)

 +#ifdef CONFIG_VIDEO_DT_SIMPLEFB
 +void sunxi_simplefb_setup(void *blob);
 +#endif
 +
  #endif /* _SUNXI_DISPLAY_H */
 diff --git a/board/sunxi/board.c b/board/sunxi/board.c
 index e6ec5b8..d4530e8 100644
 --- a/board/sunxi/board.c
 +++ b/board/sunxi/board.c
 @@ -24,6 +24,7 @@
  #endif
  #include asm/arch/clock.h
  #include asm/arch/cpu.h
 +#include asm/arch/display.h
  #include asm/arch/dram.h
  #include asm/arch/gpio.h
  #include asm/arch/mmc.h
 @@ -237,3 +238,13 @@ int misc_init_r(void)
 return 0;
  }
  #endif
 +
 +#ifdef CONFIG_OF_BOARD_SETUP
 +void
 +ft_board_setup(void *blob, bd_t *bd)
 +{
 +#ifdef CONFIG_VIDEO_DT_SIMPLEFB
 +   sunxi_simplefb_setup(blob);
 +#endif
 +}
 +#endif /* CONFIG_OF_BOARD_SETUP */
 diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
 index 3f46c31..0bd273e 100644
 --- a/drivers/video/sunxi_display.c
 +++ b/drivers/video/sunxi_display.c
 @@ -13,6 +13,8 @@
  #include asm/arch/display.h
  #include asm/global_data.h
  #include asm/io.h
 +#include fdtdec.h
 +#include fdt_support.h
  #include linux/fb.h
  #include video_fb.h

 @@ -416,3 +418,74 @@ video_hw_init(void)

 return graphic_device;
  }
 +
 +/*
 + * Simplefb support.
 + */
 +#if defined(CONFIG_OF_BOARD_SETUP)  defined(CONFIG_VIDEO_DT_SIMPLEFB)
 +void
 +sunxi_simplefb_setup(void *blob)
 +{
 +   static GraphicDevice *graphic_device = sunxi_display.graphic_device;
 +   const char *node = /chosen/framebuffer0-hdmi;
 +   char name[32];
 +   fdt32_t cells[4];
 +   int i, offset, addrc, sizec, ret, stride;
 +
 +   if (!sunxi_display.enabled)
 +   return;
 +
 +   offset = fdt_path_offset(blob, node);
 +   if (offset  0) {
 +   eprintf(Cannot setup simplefb: %s node not found\n, node);
 +   return;
 +   }
 +
 +   snprintf(name, sizeof(name), framebuffer@%08lx, gd-fb_base);
 +   ret = fdt_set_name(blob, offset, name);
 +   if (ret  0)
 +   goto error;
 +
 +   of_bus_default_count_cells(blob, fdt_parent_offset(blob, offset),
 +  addrc, sizec);
 +   i = 0;
 +   if (addrc == 2)
 +   cells[i++] = 0;
 +   cells[i++] = cpu_to_fdt32(gd-fb_base);
 +   if (sizec == 2)
 +   cells[i++] = 0;
 +   cells[i++] = cpu_to_fdt32(CONFIG_SUNXI_FB_SIZE);
 +
 +   ret = fdt_setprop(blob, offset, reg, cells, sizeof(cells[0]) * i);
 +   if (ret  0)
 +   goto error;
 +
 +   cells[0] = cpu_to_fdt32(graphic_device-winSizeX);
 +   ret = fdt_setprop(blob, offset, width, cells, sizeof(cells[0]));
 +   if (ret  0)
 +   goto error;
 +
 +   cells[0] = cpu_to_fdt32(graphic_device-winSizeY);
 +   ret = fdt_setprop(blob, offset, height, cells, sizeof(cells[0]));
 +   if (ret  0)
 +   goto error;
 +
 +   stride = graphic_device-winSizeX * graphic_device-gdfBytesPP;
 +   cells[0] = cpu_to_fdt32(stride);
 +   ret = fdt_setprop(blob, offset, stride, cells, sizeof(cells[0]));
 +   if (ret  0)
 +   goto error;
 +
 +   ret = fdt_setprop_string(blob, offset, format, x8r8g8b8);
 +   if (ret  0)
 +   goto error;
 +
 +   ret = fdt_setprop_string(blob, offset, status, okay);
 +   if (ret  0)
 +   goto error;
 +
 +   return;
 +error:
 +

Re: [U-Boot] [PATCH 5/6] sunxi: video: Add simplefb support

2014-11-17 Thread Grant Likely

On Sun, Nov 16, 2014 at 4:11 PM, Ian Campbell i...@hellion.org.uk wrote:
On Sun, 2014-11-16 at 16:11 +0100, Hans de Goede wrote:
On 11/16/2014 03:38 PM, Ian Campbell wrote:
On Sun, 2014-11-16 at 14:52 +0100, Hans de Goede wrote:
Hardcoding a path is deliberate. I don't know if you've read the
previous u-boot code for this, but it did a lot of dt parsing to
find clocks and add phandles to them, the way we eventually settled
on when discussing this is for the dts to contain pre-populated simplefb
nodes which u-boot just needs to fill with the mode info and enable, this
way as we add support for more clocks (like the module clocks for the
various display pipeline blocks), we don't need to update u-boot in
lock-step,
we just add the clocks to the simplefb node in the dts file when they get
added to the dts file in the first place. See the updated bindings.

AFAICT this in no way invalidates what I suggested. There's no reason
why the need to populate/tweak a pre-existing node should have anything
to do with where the node is in the device-tree.

Right, I forgot to add one important bit to my explanation, sorry, if
you look at the binding then it says that the name should be suffixed
with the output type, so currently the sunxi u-boot code will look for
/chosen/framebuffer0-hdmi. Which will e.g. also happen on any A10
based tablets which typically have both hdmi out and an lcd screen,
in the future I hope we will also get lcd support in u-boot, and then
logically on tablets the lcd screen would take precedence, so then
unless overriden through some config mechanism u-boot will chose
to use the lcd, and will look for /chosen/framebuffer0-lcd which has
a different set of clocks then /chosen/framebuffer0-hdmi.

This sounds like a use for:
compatible = simple-framebuffer,hdmi, simple-framebuffer
or some such, that's almost exactly what multiople compatible strings
are for. Relying on specific naming and/or path is rather
unconventional.

Indeed, for a long time now finding nodes by path has been strongly
discouraged. It makes it hard to move nodes around when needed. I'm
not going to make a big deal about it because it doesn't affect the OS
interface, but Ian's suggestion is sane. simple-framebuffer is enough
to identify the binding, but you can use additional strings to
identify the specific hardware interface that U-Boot can use to locate
the node. ie. sunxi,framebuffer-hdml or some such. You can never be
sure when someone will produce a board that messes with your naming
assumptions. What if is suddenly needs to be named framebuffer1-hdmi
because they added and FPGA that they want as framebuffer0? (Yes, I'm
making stuff up, but I have to think about the corner cases)

The devicetree bindings have been going on for so long, that this
would be the 2nd merge window this feature 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 a DT binding is.

If this scheme was acked by a DT maintainer then I'd be fine with it,
but so far it hasn't been, at least not publicly in the threads I've
looked at.

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't be placed into /chosen.

AFAIK Grant agrees with v5

AFAIK Grant hasn't actually said that. If he does ack it (or if someone
points me to the correct mail) then I have no further objections.

My word also isn't gospel. On controversial stuff I want to have
consensus. For the clock patches and had a long conversation with Rob
to make sure we were both in agreement before giving my final ack.

In fact it's a bit odd to have a reg property under /chosen at all,
since it doesn't really fit in with the bus structure. I've done
something similar in some bindings I've authored[0], but AIUI I got that
wrong and really should have used a set of non-reg properties with a
single value so there was no need to parse using #*-cells (cf the
initrd-start + initrd-end properties under /chosen). Sadly DT is an ABI,
so for my bindings I'm kind of stuck with it for the foreseeable future.

[0]
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=08ed7751859dbe2d2c32d86d7df371057d7b45a4;hb=HEAD

Ironic isn't it that I though of that as precedence when I suggested
/chosen! :-)

I actually don't have a problem with it. We do need a way to specify
runtime memory usage, and /chosen is as good a place as any,
particularly when it represents things that won't necessarily be
relevant on kexec or dom0 boot.

The other options are under either the /memory or the /reserved-memory
tree. Rob and I talked about /reserved-memory quite a lot. We could
put all the framebuffer details into the memory

Re: [U-Boot] [PATCH 5/6] sunxi: video: Add simplefb support

2014-11-17 Thread Grant Likely

On Mon, Nov 17, 2014 at 10:14 AM, Ian Campbell i...@hellion.org.uk wrote:
On Mon, 2014-11-17 at 09:58 +, 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't be placed into /chosen.

I don't think putting it under /chosen is a problem at all. THe
semantics of some of hte convention properties are a bit odd under
there, but that's not insurmountable.

AFAIK Grant agrees with v5

AFAIK Grant hasn't actually said that. If he does ack it (or if someone
points me to the correct mail) then I have no further objections.

My word also isn't gospel.

I suppose I should have said something like I trust Grant's judgement
more than my own on things relating to DT ;-).

On controversial stuff I want to have
consensus. For the clock patches and had a long conversation with Rob
to make sure we were both in agreement before giving my final ack.

[0]
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=08ed7751859dbe2d2c32d86d7df371057d7b45a4;hb=HEAD

Ironic isn't it that I though of that as precedence when I suggested
/chosen! :-)

:-)

The main issue which was explained to me with my Xen bindings was that
reg = isn't all that meaningful under /chosen because it doesn't fit
into the bus structure, so the #address-/size-cells stuff gets a bit
strange. It's probably tolerable for things which are strictly physical
RAM addresses (as opposed to mmio) since RAM isn't typically behind a
visible bus.

The scheme used for initrds sidesteps all those issues by using separate
(multicellular) properties for the start and end regions and not using
reg= and therefore naturally breaking the expected semantic link with
bus topology which reg implies etc.

I quite dislike the initrd multi-property approach. It has to be
parsed in a completely separate way.

The other options are under either the /memory or the /reserved-memory
tree. Rob and I talked about /reserved-memory quite a lot. We could
put all the framebuffer details into the memory node that reserves the
framebuffer. However, I don't like that idea because it kind of makes
assumptions about how the framebuffer will be located inside the
memory region and doesn't allow for multiple framebuffers within a
single region.

Yes, that sounds strictly worse than the current solution to me.

Besides, the simple-framebuffer binding could easily be extended to
allow a reserved-memory reference instead of a reg property if/when
that becomes a better option for a specific platform.

g.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] dtb vs. kernel command line arguments

2013-04-15 Thread Grant Likely

On Mon, 4 Mar 2013 18:03:23 -0600, Kim Phillips kim.phill...@freescale.com 
wrote:
 On Mon, 4 Mar 2013 10:30:45 -0800
 Curt Brune c...@cumulusnetworks.com 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 think of two ways:
  
  1. append args by setting bootargs.
  2. add nodes to the dtb before booting.
  
  Is there a preferred way to pass information like this?
  
  Like I said the arguments are not needed by the kernel device drivers, 
  but by user space applications.
  
  I like the structure of nodes in the dtb.
 
 please don't dual-purpose device trees as a mechanism of getting
 arguments through the kernel into userspace - device trees strictly
 describe the hardware.

Why not? The chosen node in particular is for software configuration. I
don't have any problem with passing U-Boot extra data through the chosen
node. Just don't go crazy and please document it.

g.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Switch from mmcboot to ramboot?

2012-11-29 Thread Grant

  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-boot - and access prompt

 then,

 run ramboot

Hi Lucasz, that didn't work for me and I think it's because of the
variables set by 'make am335x_evm_defconfig'.  It seems like there are a
set of standard u-boot commands and a higher level of variables set by 'make
am335x_evm_defconfig' which appear in include/configs/am335x_evm.h and
prevent you from using the standard u-boot commands in uEnv.txt.

For example, even after adding the following to the top of my uEnv.txt:

setenv bootcmd ramboot
saveenv

I still get:

Booting from mmc ...

I'm struggling to figure out how to use the framework provided by 'make
am335x_evm_defconfig' in uEnv.txt.  Can you point me to info on how to do
that?

- Grant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Switch from mmcboot to ramboot?

2012-11-28 Thread Grant

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

Re: [U-Boot] Merging device trees at runtime for module-based systems

2012-11-06 Thread Grant Likely

On Wed, Oct 31, 2012 at 11:00 PM, Daniel Mack zon...@gmail.com 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 the BeagleBone folks where
they want to insert additional DT data from Linux userspace. Whether
the data is merged at U-Boot time or kernel time, I expect that the
required data format will be very similar.

https://lkml.org/lkml/2012/10/31/502
https://lkml.org/lkml/2012/11/5/615

I'm trying to draft up a document that captures the requirements and
lay out what needs to be done to the tools, U-Boot and the kernel.

g.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Loading a userland file

2012-11-03 Thread Grant

I'm trying to get Tiny Core working on the Beaglebone.  I'm stuck on
getting the Tiny Core userland file uCore to load so init works.  I'm
using this uEnv.txt:

bootfile=/uImage
optargs=init=/init rootwait
fatload mmc 0 0x4310 uCore
mmcboot=echo Booting from mmc ...; run mmcargs; bootm 0x8020 0x4310

I get the following data abort:

## Booting kernel from Legacy Image at 8020 ...
Image Name:   Linux-3.6.0-rc7-00219-g35e0f42
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:2878667 Bytes = 2.7 MiB
Load Address: 80008000
Entry Point:  80008000
Verifying Checksum ... OK
data abort
pc : [8ff99480]  lr : [8ff996ac]
sp : 8fe6abd0  ip : 8fe6d163 fp : 0001
r10: 0002  r9 :  r8 : 8fe6af68
r7 : 8ffbaebc  r6 : 4310 r5 : 8ffbaec0  r4 : 4310
r3 :   r2 : 0010 r1 :   r0 : 4310
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32
Resetting CPU ...

If I change mmcboot to:

mmcboot=echo Booting from mmc ...; run mmcargs; bootm 0x8020

The kernel loads, but init fails:

EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
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 tell me how to load uCore so init works?

- Grant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Loading a userland file

2012-11-03 Thread Grant

 I'm trying to get Tiny Core working on the Beaglebone.  I'm stuck on
getting the Tiny Core userland file uCore to load so init works.  I'm
using this uEnv.txt:

 bootfile=/uImage
 optargs=init=/init rootwait
 fatload mmc 0 0x4310 uCore
 mmcboot=echo Booting from mmc ...; run mmcargs; bootm 0x8020
0x4310

 I get the following data abort:

 ## Booting kernel from Legacy Image at 8020 ...
 Image Name:   Linux-3.6.0-rc7-00219-g35e0f42
 Image Type:   ARM Linux Kernel Image (uncompressed)
 Data Size:2878667 Bytes = 2.7 MiB
 Load Address: 80008000
 Entry Point:  80008000
 Verifying Checksum ... OK
 data abort
 pc : [8ff99480]  lr : [8ff996ac]
 sp : 8fe6abd0  ip : 8fe6d163 fp : 0001
 r10: 0002  r9 :  r8 : 8fe6af68
 r7 : 8ffbaebc  r6 : 4310 r5 : 8ffbaec0  r4 : 4310
 r3 :   r2 : 0010 r1 :   r0 : 4310
 Flags: nZCv  IRQs off  FIQs on  Mode SVC_32
 Resetting CPU ...

 If I change mmcboot to:

 mmcboot=echo Booting from mmc ...; run mmcargs; bootm 0x8020

 The kernel loads, but init fails:

 EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts:
(null)
 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 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:

RAMDISK: Couldn't find valid RAM disk image starting at 0.

Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid

Please let me know if you have any pointers.

- Grant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] sram overflowed

2012-10-10 Thread Grant

 As an aside, I noticed omap3_beagle in board.cfg, so I tried '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.

 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

Re: [U-Boot] sram overflowed

2012-10-09 Thread Grant

  git clone git://arago-project.org/git/projects/u-boot-am33x.git
 
  This is definitely NOT what you want to use when somebody mentions
  latest version.  This term always refers to top of tree in mainline
  U-Boot, see http://git.denx.de/?p=u-boot.git;a=summary  resp.
  git://git.denx.de/u-boot.git

 Thank you for that.  There is some outdated info here:

 Upstream U-Boot(the one you can download from www.denx.de)'s SPL
 support doesn't include the AM33XX chip, which is the one used in the
 Beaglebone. Progress is being done as of December 2011 to get it
 included. For this reason, we'll use a patched U-Boot provided from
 TI.

 Well, December 2011 is a long time ago.  As of v2012.10-rc1 am335x
 platforms are rather well supported in mainline, especially the
 beaglebone (which doesn't have NAND, the biggest gap between mainline
 and the u-boot-am33x.git tree, at least as of Dec 2011).  Using mainline
 and the toolchain you likely have from TI, or from Linaro (if you use
 v2012.10-rc3) or from ELDK 5.2 will produce functional binaries for your
 platform.

Thank you, I was able to boot the Beaglebone with mainline u-boot by
moving uImage to / and adding this to uEnv.txt:

bootfile=/uImage

As an aside, I noticed omap3_beagle in board.cfg, so I tried '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

Re: [U-Boot] sram overflowed

2012-10-08 Thread Grant

 git clone git://arago-project.org/git/projects/u-boot-am33x.git

 This is definitely NOT what you want to use when somebody mentions
 latest version.  This term always refers to top of tree in mainline
 U-Boot, see http://git.denx.de/?p=u-boot.git;a=summary  resp.
 git://git.denx.de/u-boot.git

Thank you for that.  There is some outdated info here:

Upstream U-Boot(the one you can download from www.denx.de)'s SPL
support doesn't include the AM33XX chip, which is the one used in the
Beaglebone. Progress is being done as of December 2011 to get it
included. For this reason, we'll use a patched U-Boot provided from
TI.

http://dev.gentoo.org/~armin76/arm/beaglebone/install.xml

I did:

git clone git://git.denx.de/u-boot.git
cd u-boot
make am335x_evm_config
make
cp MLO /boot
cp u-boot.img /boot

but I get the following at boot followed by the u-boot command line prompt:

Loaded environment from uEnv.txt
Importing environment from mmc ...
Loading file /boot/uImage from mmc device 0:2
** File not found /boot/uImage
ext2load - load binary file from a Ext2 filesystem

It seems like u-boot is missing the kernel 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'm doing wrong?

- Grant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] sram overflowed

2012-10-07 Thread Grant

When I try to boot the 3.6 kernel on my Beaglebone it hangs at
Starting kernel.  I read that I should try the latest version of
u-boot:

git clone git://arago-project.org/git/projects/u-boot-am33x.git

But I get this when I try to make:

ld: u-boot-spl section `.data' will not fit in region `.sram'
ld: region `.sram' overflowed by 163 bytes
make[1]: *** [/root/u-boot-am33x/spl/u-boot-spl] Error 1
make[1]: Leaving directory `/root/u-boot-am33x/spl'
make: *** [spl/u-boot-spl.bin] Error 2

I read here that I should try removing config options like
CONFIG_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

[U-Boot] Combine zImage and rootfs in single uImage

2012-05-22 Thread Grant Edwards

Currently, I build a linux kernel that contains the root fileystem in
the zImage file, when then gets converted into a uImage and booted
from NAND flash.  This is all working fine, but having the kernel
build depend on the rootfs build is a problem.

In another mailing list, 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.

I've been looking through the manual and FAQs, and can't figure out
how to do this.  I did find a vague reference in one of the Linux
kernel docs 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.edwardsYow! I selected E5 ... but
  at   I didn't hear Sam the Sham
  gmail.comand the Pharoahs!

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Combine zImage and rootfs in single uImage

2012-05-22 Thread Grant Edwards

On 2012-05-22, Wolfgang Denk w...@denx.de wrote:
 In message jpgbbm$1hk$1...@dough.gmane.org 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) old style way (using legacy image format) is called
 multi-file images.

 The modern, recommended way to do things like this is using FIT
 images.

 See the respective documentation.

Thanks!

All our build/update infrastcture expects the uImage legacy image
format, so I'm going to stick with the multi-file uImage format for
now.

FWIW, I couldn't find any documentation for FIT images (it's not
mentioned in in either FAQs, Table of Contents, or Index), and various
google searches didn't find anything except old mailing list messages.
Having the manual chopped up into hundreds of separate web pages makes
impossible to search when looking for something. It would be very nice
if the Manual was available as a single page.

-- 
Grant Edwards   grant.b.edwardsYow! BELA LUGOSI is my
  at   co-pilot ...
  gmail.com

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Combine zImage and rootfs in single uImage

2012-05-22 Thread Grant Edwards

On 2012-05-22, Wolfgang Denk w...@denx.de wrote:
 In message jpghr5$1at$1...@dough.gmane.org you wrote:

 FWIW, I couldn't find any documentation for FIT images (it's not
 mentioned in in either FAQs, Table of Contents, or Index), and
 various google searches didn't find anything except old mailing list
 messages.

 First, there is documentation in the doc/ directory - see the
 doc/uImage.FIT/ directory.

Doh!  I forgot to look in the source tree.

 Second, the man page for the mkimage command mentions it (not really
 extensively, though).

 Having the manual chopped up into hundreds of separate web pages
 makes impossible to search when looking for something. It would be
 very nice if the Manual was available as a single page.

 It is. It is available as single HTML, PDF and PostScript files. See
 section 2.3. 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

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: tegra: Define Tegra20 CAR binding

2012-01-23 Thread Grant Likely

On Fri, Jan 20, 2012 at 11:32:04PM -0800, Olof Johansson wrote:
 Hi,
 
 On Thu, Jan 19, 2012 at 9:17 AM, Stephen Warren swar...@nvidia.com wrote:
  Olof Johansson wrote at Wednesday, January 18, 2012 10:32 PM:
  On Wed, Jan 18, 2012 at 05:16:52PM -0700, Stephen Warren wrote:
   diff --git 
   a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
   +* NVIDIA Tegra20 Clock And Reset Controller
   +
   +This binding uses the common clock binding:
   +Documentation/devicetree/bindings/clock/clock-bindings.txt
   +
   +The CAR (Clock And Reset) Controller on Tegra is the HW module 
   responsible
   +for muxing and gating Tegra's clocks, and setting their rates.
   +
   +Required properties :
   +- compatible : Should be nvidia,chip-car
   +- reg : Should contain CAR registers location and length
   +- clocks : Should contain phandle and clock specifiers for two clocks:
   +  the 32 KHz 32k_in, and the board-specific oscillator osc.
   +- clock-names : Should contain a list of strings, with values 32k_in,
   +  and osc.
 
  Hmm. I'd prefer to just ditch the notion of clock-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 the
  two clocks refs have to be to those two clocks in that order should
  be sufficient.
 
  OK, that seems reasonable. I'm happy using of_clk_get() rather than
  of_clk_get_by_name(). I guess that means we should just avoid any
  discussion of clock-output-names too.
 
 Sounds good to me. Let's make sure Grant is OK with it too though.

Yes, I agree.

g.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] tools/env: fix cross-compilation

2012-01-05 Thread Grant Erickson

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 when so requested with TOOLSUBDIRS on the U-Boot make command
 line.
 
 how is this any simpler than the existing method ?
   make tools HOSTCC=some-random-target-gcc
 
 the current tools/ subdir is consistent in its handling.  this patch would 
 break that.

Mike,

Because it's broken with respect to how the rest of U-Boot is built. I already 
specify the cross-compiler via CROSS_COMPILE when I build u-boot.bin and 
u-boot.img, that I need to specify the same compiler in two different ways to 
build executables for the same target platform is broken and, it sounds like, 
as are the rest of the tools subdirectories.

If fw_setenv were a build host-based tool or if it made sense as a build 
host-based tool, then using HOSTCC would be sensible.

Best,

Grant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm/omap3: limit chip select iteration based on board config

2012-01-04 Thread Grant Erickson

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_BANKS set to 1 from getting an 
 incorrect DRAM size.
 
 Signed-off-by: Grant Erickson maratho...@gmail.com
 Cc: Tom Rini tr...@ti.com
 
 OK, what problem (and on what board) are you seeing?  Many boards only
 have CS0 populated with DRAM but when we try and configure CS1 the
 mem_ok() call fails and we don't try and use it, so we don't get a wrong
 amount of memory.  Thanks!

Tom:

This is on an OMAP3EVM-derived board with 64 MiB of fixed Micron MDDR DRAM.

The board is bootstrapped in second stage boot using X-Loader 1.46 (it'll move 
to U-Boot SPL really soon now). The original X-Loader 1.46 + U-Boot 2010.09 
went successfully as follows:

Texas Instruments X-Loader 1.46 (Dec 21 2011 - 21:23:39)

Reading boot sector

229792 bytes read
Loading from MMC0, file u-boot.img
   Image Name:   U-Boot 2010.09
   Created:  2011-12-22   5:12:46 UTC
   Image Type:   ARM U-Boot Firmware (uncompressed)
   Data Size:229728 Bytes = 224.3 KiB
   Load Address: 80e8
   Entry Point:  
   Verifying Checksum ... OK
   Loading Firmware ... OK

Starting Firmware ...

U-Boot 2010.09 (Dec 21 2011 - 21:11:09)

U-Boot code: 80E8 - 80EB8160  BSS: - 80EFA604
OMAP36XX/37XX-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
I2C:   ready
RAM Configuration:
Bank #0: 8000 64 MiB
Bank #1: a000 0 Bytes
NAND:  256 MiB
In:serial
Out:   serial
Err:   serial
Board: Revision 6, Serial 10921256018
Build: development
Die ID #6f4400029e380160a7451000f006
Net:   No ethernet found.
### main_loop entered: bootdelay=1

### main_loop: bootcmd=run nandboot0 || run nandboot1 || run mmcboot 
|| reset
Hit any key to stop autoboot:  0 

With the same X-Loader but using U-Boot 2011.12-rc2 without the proposed patch, 
things failed as follows:

Texas Instruments X-Loader 1.46 (Dec 21 2011 - 21:23:39)

Reading boot sector

[ ... ]

U-Boot 2011.12-rc2 (Dec 21 2011 - 22:47:56)

U-Boot code: 80E8 - 80EC00E4  BSS: - 80F02800
OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
I2C:   ready
-- dram_init
-- get_sdr_cs_size
-- get_sdr_cs_size size 67108864
size0 67108864
-- get_sdr_cs_size
-- get_sdr_cs_size size 67108864
-- get_sdr_cs_size
-- get_sdr_cs_size size 67108864
size1 67108864
gd-ram_size 134217728
-- dram_init
monitor len: 00082800
ramsize: 0800
TLB table at: 87ff
Top of RAM usable for U-Boot at: 87ff
Reserving 522k for U-Boot at: 87f6d000
Reserving 512k for malloc() at: 87eed000
Reserving 32 Bytes for Board Info at: 87eecfe0
Reserving 120 Bytes for Global Data at: 87eecf68
New Stack Pointer is: 87eecf58
-- dram_init_banksize
-- get_sdr_cs_size
-- get_sdr_cs_size size 67108864
-- get_sdr_cs_size
-- get_sdr_cs_size size 67108864
size0 67108864
size1 67108864
-- dram_init_banksize
RAM Configuration:
Bank #0: 7461000a 1.1 GiB
Bank #1: 4806a000 1.1 GiB
relocation Offset is: 070ed000

[ Hangs ]

with the patch in place, things went successfully as follows:

Texas Instruments X-Loader 1.46 (Dec 21 2011 - 21:23:39)

Reading boot sector

[ ... ]

U-Boot 2011.12-rc2 (Dec 21 2011 - 23:54:24)

U-Boot code: 80E8 - 80EC018C  BSS: - 80F028A8
OMAP36XX/37XX-GP ES1.2, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
I2C:   ready
-- dram_init
-- get_sdr_cs_size
-- get_sdr_cs_size size 67108864
size0 67108864
size1 67108864
gd-ram_size 67108864
-- dram_init
monitor len: 000828A8
ramsize: 0400
TLB table at: 83ff
Top of RAM usable for U-Boot at: 83ff
Reserving 522k for U-Boot at: 83f6d000
Reserving 512k for malloc() at: 83eed000
Reserving 24 Bytes for Board Info at: 83eecfe8
Reserving 120 Bytes for Global Data at: 83eecf70
New Stack Pointer is: 83eecf60
-- dram_init_banksize
-- get_sdr_cs_size
-- get_sdr_cs_size size

Re: [U-Boot] [PATCH] arm/omap3: limit chip select iteration based on board config

2012-01-04 Thread Grant Erickson

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 
 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 maratho...@gmail.com
 Cc: Tom Rini tr...@ti.com
 
 OK, what problem (and on what board) are you seeing?  Many boards only
 have CS0 populated with DRAM but when we try and configure CS1 the
 mem_ok() call fails and we don't try and use it, so we don't get a wrong
 amount of memory.  Thanks!
 
 Tom:
 
 This is on an OMAP3EVM-derived board with 64 MiB of fixed Micron MDDR DRAM.
 
 The board is bootstrapped in second stage boot using X-Loader 1.46 (it'll 
 move to U-Boot SPL really soon now). The original X-Loader 1.46 + U-Boot 
 2010.09 went successfully as follows:
 
 X-Loader is misbehaving (and misconfiguring) here.  Actual OMAP3EVM also had 
 this problem until the SPL switch.

Tom:

That makes sense; however, I have deployed boards in the field for which an 
in-place X-Loader update isn't trivial and for which interoperability is key. 
In light of that, are you willing to accept the patch?

* For CONFIG_NR_DRAM_BANKS set to 1, we get interop with old second 
stage boot such as X-Loader.

* For CONFIG_NR_DRAM_BANKS set to 2 (most boards) the behavior is 
exactly as it is without the patch.

What do you think?

Thanks,

Grant
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] lib/string: added strndup

This patch adds optional support for strndup.

Signed-off-by: Grant Erickson maratho...@gmail.com
---
 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..5668290 100644
--- a/include/linux/string.h
+++ b/include/linux/string.h
@@ -59,6 +59,9 @@ extern __kernel_size_t strnlen(const char *,__kernel_size_t);
 #ifndef __HAVE_ARCH_STRDUP
 extern char * strdup(const char *);
 #endif
+#ifndef __HAVE_ARCH_STRNDUP
+extern char * strndup(const char *,__kernel_size_t);
+#endif
 #ifndef __HAVE_ARCH_STRSWAB
 extern char * strswab(const char *);
 #endif
diff --git a/lib/string.c b/lib/string.c
index 2c4f0ec..5fb6693 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -260,6 +260,27 @@ char * strdup(const char *s)
 }
 #endif
 
+#ifndef __HAVE_ARCH_STRNDUP
+char * strndup(const char *s, size_t n)
+{
+   size_t len;
+   char *new;
+
+   len = strnlen(s, n);
+
+   if ((s == NULL) ||
+   ((new = malloc (len + 1)) == NULL) ) {
+   return NULL;
+   }
+
+   strncpy (new, s, len);
+
+   new[len] = '\0';
+
+   return new;
+}
+#endif
+
 #ifndef __HAVE_ARCH_STRSPN
 /**
  * strspn - Calculate the length of the initial substring of @s which only
-- 
1.7.7.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] tools/env: fix cross-compilation

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 maratho...@gmail.com
---
 tools/env/Makefile |   18 +-
 tools/env/README   |   19 ++-
 2 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/tools/env/Makefile b/tools/env/Makefile
index 28b73da..705d5e8 100644
--- a/tools/env/Makefile
+++ b/tools/env/Makefile
@@ -23,24 +23,24 @@
 
 include $(TOPDIR)/config.mk
 
-HOSTSRCS := $(SRCTREE)/lib/crc32.c  fw_env.c  fw_env_main.c
+SRCS := $(SRCTREE)/lib/crc32.c  fw_env.c  fw_env_main.c
 HEADERS:= fw_env.h
 
 # Compile for a hosted environment on the target
-HOSTCPPFLAGS  = -idirafter $(SRCTREE)/include \
-   -idirafter $(OBJTREE)/include2 \
-   -idirafter $(OBJTREE)/include \
-   -DUSE_HOSTCC
+CPPFLAGS = -Wall \
+  -idirafter $(SRCTREE)/include \
+  -idirafter $(OBJTREE)/include2 \
+  -idirafter $(OBJTREE)/include \
+  -DUSE_HOSTCC
 
 ifeq ($(MTD_VERSION),old)
-HOSTCPPFLAGS += -DMTD_OLD
+CPPFLAGS += -DMTD_OLD
 endif
 
 all:   $(obj)fw_printenv
 
-# Some files complain if compiled with -pedantic, use HOSTCFLAGS_NOPED
-$(obj)fw_printenv: $(HOSTSRCS) $(HEADERS)
-   $(HOSTCC) $(HOSTCFLAGS_NOPED) $(HOSTLDFLAGS) -o $@ $(HOSTSRCS)
+$(obj)fw_printenv: $(SRCS) $(HEADERS)
+   $(CROSS_COMPILE)gcc $(CPPFLAGS) $(SRCS) -o $@
 
 clean:
rm -f $(obj)fw_printenv
diff --git a/tools/env/README b/tools/env/README
index 3f0d77e..5b02f7d 100644
--- a/tools/env/README
+++ b/tools/env/README
@@ -2,11 +2,20 @@
 This is a demo implementation of a Linux command line tool to access
 the U-Boot's environment variables.
 
-In the current version, there is an issue in cross-compilation.
-In order to cross-compile fw_printenv, run
-make HOSTCC=your CC cross-compiler env
-in the root directory of the U-Boot distribution. For example,
-make HOSTCC=arm-linux-gcc env
+To build it for your target board along with U-Boot itself, simply add:
+
+TOOLSUBDIRS=env
+
+to your make invocation such as:
+
+make -C u-boot/source \
+O=$(CURDIR)/u-boot/build \
+TOOLSUBDIRS=env \
+all
+
+and you will find, for example:
+
+$(CURDIR)/u-boot/build/tools/env/fw_printenv
 
 For the run-time utiltity configuration uncomment the line
 #define CONFIG_FILE  /etc/fw_env.config
-- 
1.7.7.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] tools/env: allow overwrite of ethaddr on default

This patch allows the U-Boot user space companion utility, fw_setenv,
to overwrite the 'ethaddr' key/value pair if the current value is set
to a per-board-configured default.

This change allows 'fw_setenv' to match the behavior of 'setenv' /
'env set' on the U-Boot command line.

Signed-off-by: Grant Erickson maratho...@gmail.com
---
 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,8 @@
 
 #include fw_env.h
 
+#include config.h
+
 #define WHITESPACE(c) ((c == '\t') || (c == ' '))
 
 #define min(x, y) ({   \
@@ -390,15 +392,23 @@ int fw_env_write(char *name, char *value)
 * Delete any existing definition
 */
if (oldval) {
+#ifndef CONFIG_ENV_OVERWRITE
+
/*
 * Ethernet Address and serial# can be set only once
 */
-   if ((strcmp (name, ethaddr) == 0) ||
-   (strcmp (name, serial#) == 0)) {
+   if (
+   (strcmp(name, serial#) == 0) ||
+   ((strcmp(name, ethaddr) == 0)
+#if defined(CONFIG_OVERWRITE_ETHADDR_ONCE)  defined(CONFIG_ETHADDR)
+(strcmp(oldval, MK_STR(CONFIG_ETHADDR)) != 0)
+#endif /* CONFIG_OVERWRITE_ETHADDR_ONCE  CONFIG_ETHADDR */
+  ) ) {
fprintf (stderr, Can't overwrite \%s\\n, name);
errno = EROFS;
return -1;
}
+#endif /* CONFIG_ENV_OVERWRITE */
 
if (*++nxt == '\0') {
*env = '\0';
-- 
1.7.7.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] arm/omap3: limit chip select iteration based on board config

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 maratho...@gmail.com
Cc: Tom Rini tr...@ti.com
---
 arch/arm/cpu/armv7/omap3/sdrc.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap3/sdrc.c b/arch/arm/cpu/armv7/omap3/sdrc.c
index a27b4b1..4c02214 100644
--- a/arch/arm/cpu/armv7/omap3/sdrc.c
+++ b/arch/arm/cpu/armv7/omap3/sdrc.c
@@ -213,6 +213,7 @@ int dram_init(void)
unsigned int size0 = 0, size1 = 0;
 
size0 = get_sdr_cs_size(CS0);
+#if CONFIG_NR_DRAM_BANKS  1
/*
 * We always need to have cs_cfg point at where the second
 * bank would be, if present.  Failure to do so can lead to
@@ -223,6 +224,7 @@ int dram_init(void)
make_cs1_contiguous();
do_sdrc_init(CS1, NOT_EARLY);
size1 = get_sdr_cs_size(CS1);
+#endif
 
gd-ram_size = size0 + size1;
 
-- 
1.7.7.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] lib/string: added strndup

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 maratho...@gmail.com
 ---
 include/linux/string.h |3 +++
 lib/string.c   |   21 +
 2 files changed, 24 insertions(+), 0 deletions(-)
 
 What is this good for?  There are no users for this function (neither
 in mainline nor in any of the patches you have submitted).

Wolfgang:

I have a new board addition coming along shortly that leverages this.

Best,

Grant Erickson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/6] fdt: Add support for embedded device tree (CONFIG_OF_EMBED)

2011-10-14 Thread Grant Likely

On Thu, Oct 13, 2011 at 3:50 PM, Stephen Warren swar...@nvidia.com 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 swar...@nvidia.com wrote:
  Simon Glass wrote at Tuesday, October 11, 2011 4:26 PM:
  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 device tree compiler output should be placed in the $(obj)
  rooted tree. Since $(OBJCOPY) insists on adding the path to the
  generated symbol names, to ensure consistency it should be
  invoked from the directory where the .dtb file is located and
  given the input file name without the path.
  ...
  +process_lds = \
  +     $(1) | sed -r -n 's/^OUTPUT_$(2)[ (]*([^)]*).*/\1/p'
  +
  +# Run the compiler and get the link script from the linker
  +GET_LDS = $(CC) $(CFLAGS) $(LDFLAGS) -Wl,--verbose 21
  +
  +$(obj)dt.o: $(DT_BIN)
  +     # We want the output format and arch.
  +     # We also hope to win a prize for ugliest Makefile / shell 
  interaction
  +     # We look in the LDSCRIPT first.
  +     # Then try the linker which should give us the answer.
  +     # Then check it worked.
  +     oformat=`$(call process_lds,cat $(LDSCRIPT),FORMAT)` ;\
  +     oarch=`$(call process_lds,cat $(LDSCRIPT),ARCH)` ;\
  +     \
  +     [ -z $${oformat} ]  \
  +             oformat=`$(call process_lds,$(GET_LDS),FORMAT)` ;\
  +     [ -z $${oarch} ]  \
  +             oarch=`$(call process_lds,$(GET_LDS),ARCH)` ;\
  +     \
  +     [ -z $${oformat} ]  \
  +             echo Cannot read OUTPUT_FORMAT from lds file $(LDSCRIPT) 
   \
  +             exit 1 || true ;\
  +     [ -z $${oarch} ]  \
  +             echo Cannot read OUTPUT_ARCH from lds file $(LDSCRIPT)  
  \
  +             exit 1 || true ;\
  +     \
  +     cd $(dir ${DT_BIN})  \
  +     $(OBJCOPY) -I binary -O $${oformat} -B $${oarch} \
  +             $(notdir ${DT_BIN}) $@
  +     rm $(DT_BIN)
 
  Instead of all that, can't you just run a trivial script to generate a .c
  file containing the data from DTB_BIN, and then use the compiler to compile
  that, i.e. spit out something like:
 
  const unsigned char dtb[] = {
   0xaa, 0x55, ..
  };
 
  That'd certainly drastically simplify the makefile, although waste a little
  more time and temp disk space.

 What, and withdraw my Makefile contest entry? :-)

 :-)

 I feel that objcopy is designed to do exactly this, and generating C
 code is a roundabout way of producing an object file with data in it.
 The difficulty of finding out the output format/architecture is
 something we might clean up in U-Boot generally at some point (e.g.
 figure it out as part of the original 'make ..._config') in which case
 this would all go away.

 Thoughts?

 Looking some more, dtc has option -O asm which writes directly to a text
 file that can be assembled; there'd be no extra temp files or conversions
 if you used that.

I recommend *not* using the asm output option.  It's not nearly as
well tested and it is likely to have some big-endian-isms in it that
don't work well.  I prefer the objcopy approach myself.  That's what
it is for.

g.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v2 2/6] fdt: Add support for embedded device tree (CONFIG_OF_EMBED)

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 device tree compiler output should be placed in the $(obj)
 rooted tree. Since $(OBJCOPY) insists on adding the path to the
 generated symbol names, to ensure consistency it should be
 invoked from the directory where the .dtb file is located and
 given the input file name without the path.
 
 This commit contains my entry for the ugliest Makefile / shell interaction
 competition.
 
 Signed-off-by: Simon Glass s...@chromium.org

May I suggest an alternate approach?  Rather than hard linking the dtb
into the u-boot image, this would be so much more useful if the dtb
can be concatenated to the u-boot binary so that it can be configured
at install time.  Otherwise, switching to .dtb doesn't seem to
actually buy much when it still requires a recompile of u-boot to
change the dtb configuration data.

The linker script would need to be modified to make sure the end of
the binary image is aligned, and that there is a label indicating the
beginning of the .dtb section.  The init code will also need to read
the .dtb header to get the dtb length so that it can be relocated into
RAM with the rest of u-boot.

Targets could even be added as u-boot.%.bin so that a single build
could spit out several variants as needed, but still produce a bare
u-boot.bin binary that can have the .dtb appended manually.

Using CONFIG_OF_EMBED may actually be harmful if it starts encouraging
developers to put .dts files into the u-boot tree.  Especially when
right now the plan for the kernel is to actually move .dts file out of
the Linux tree and into a separate  neutral repository.

 ---
  Makefile |4 ++
  README   |   11 +-
  config.mk|1 +
  dts/Makefile |  100 
 ++
  include/common.h |1 +
  5 files changed, 115 insertions(+), 2 deletions(-)
  create mode 100644 dts/Makefile
 
 diff --git a/Makefile b/Makefile
 index d5a1f0a..658a622 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -224,6 +224,9 @@ endif
  ifeq ($(CPU),ixp)
  LIBS += arch/arm/cpu/ixp/npe/libnpe.o
  endif
 +ifeq ($(CONFIG_OF_EMBED),y)
 +LIBS += dts/libdts.o
 +endif
  LIBS += arch/$(ARCH)/lib/lib$(ARCH).o
  LIBS += fs/cramfs/libcramfs.o fs/fat/libfat.o fs/fdos/libfdos.o 
 fs/jffs2/libjffs2.o \
   fs/reiserfs/libreiserfs.o fs/ext2/libext2fs.o fs/yaffs2/libyaffs2.o \
 @@ -962,6 +965,7 @@ clobber:  clean
   @rm -f $(obj)u-boot.kwb
   @rm -f $(obj)u-boot.imx
   @rm -f $(obj)u-boot.ubl
 + @rm -f $(obj)u-boot.dtb
   @rm -f $(obj)tools/{env/crc32.c,inca-swap-bytes}
   @rm -f $(obj)arch/powerpc/cpu/mpc824x/bedbug_603e.c
   @rm -fr $(obj)include/asm/proc $(obj)include/asm/arch $(obj)include/asm
 diff --git a/README b/README
 index 812805f..5a2f060 100644
 --- a/README
 +++ b/README
 @@ -803,8 +803,15 @@ The following options need to be configured:
   experimental and only available on a few boards. The device
   tree is available in the global data as gd-blob.
  
 - U-Boot needs to get its device tree from somewhere. This will
 - be enabled in a future patch.
 + U-Boot needs to get its device tree from somewhere. At present
 + the only way is to embed it in the image with CONFIG_OF_EMBED.
 +
 + CONFIG_OF_EMBED
 + If this variable is defined, U-Boot will embed a device tree
 + binary in its image. This device tree file should be in the
 + board directory and called soc-board.dts. The binary file
 + is then picked up in board_init_f() and made available through
 + the global data structure as gd-blob.
  
  - Watchdog:
   CONFIG_WATCHDOG
 diff --git a/config.mk b/config.mk
 index e2b440d..6e61eb6 100644
 --- a/config.mk
 +++ b/config.mk
 @@ -124,6 +124,7 @@ STRIP = $(CROSS_COMPILE)strip
  OBJCOPY = $(CROSS_COMPILE)objcopy
  OBJDUMP = $(CROSS_COMPILE)objdump
  RANLIB   = $(CROSS_COMPILE)RANLIB
 +DTC  = dtc
  
  #
  
 diff --git a/dts/Makefile b/dts/Makefile
 new file mode 100644
 index 000..e70a16b
 --- /dev/null
 +++ b/dts/Makefile
 @@ -0,0 +1,100 @@
 +#
 +# Copyright (c) 2011 The Chromium OS Authors.
 +#
 +# See file CREDITS for list of people who contributed to this
 +# project.
 +#
 +# This program is free software; you can redistribute it and/or
 +# modify it under the terms of the GNU General Public License as
 +# published by the Free Software Foundatio; either version 2 of
 +# the License, or (at your option) any later version.
 +#
 +# This program is distributed in the hope that it will be useful,
 +# but WITHOUT ANY WARRANTY;

Re: [U-Boot] [RFC PATCH v2 3/6] fdt: Add support for a separate device tree (CONFIG_OF_SEPARATE)

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 patches before commenting.  I
strongly feel that this should be the only method and that
CONFIG_OF_EMBED should be dropped.

 
 Signed-off-by: Simon Glass s...@chromium.org
 ---
  .gitignore |1 +
  Makefile   |5 ++
  README |   11 +++-
  doc/README.fdt-control |  168 
 
  4 files changed, 183 insertions(+), 2 deletions(-)
  create mode 100644 doc/README.fdt-control
 
 diff --git a/.gitignore b/.gitignore
 index dbf545f..c4ebd34 100644
 --- a/.gitignore
 +++ b/.gitignore
 @@ -34,6 +34,7 @@
  /u-boot.dis
  /u-boot.lds
  /u-boot.ubl
 +/u-boot.dtb
  
  #
  # Generated files
 diff --git a/Makefile b/Makefile
 index 658a622..d73efa1 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -352,9 +352,14 @@ ALL-$(CONFIG_ONENAND_U_BOOT) += $(obj)u-boot-onenand.bin
  ONENAND_BIN ?= $(obj)onenand_ipl/onenand-ipl-2k.bin
  ALL-$(CONFIG_MMC_U_BOOT) += $(obj)mmc_spl/u-boot-mmc-spl.bin
  ALL-$(CONFIG_SPL) += $(obj)spl/u-boot-spl.bin
 +ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb
  
  all: $(ALL-y)
  
 +$(obj)u-boot.dtb:$(obj)u-boot
 + $(MAKE) -C dts binary
 + mv $(obj)dts/dt.dtb $@
 +
  $(obj)u-boot.hex:$(obj)u-boot
   $(OBJCOPY) ${OBJCFLAGS} -O ihex $ $@
  
 diff --git a/README b/README
 index 5a2f060..0b8f338 100644
 --- a/README
 +++ b/README
 @@ -803,8 +803,8 @@ The following options need to be configured:
   experimental and only available on a few boards. The device
   tree is available in the global data as gd-blob.
  
 - U-Boot needs to get its device tree from somewhere. At present
 - the only way is to embed it in the image with CONFIG_OF_EMBED.
 + U-Boot needs to get its device tree from somewhere. This can
 + be done using one of the two options below:
  
   CONFIG_OF_EMBED
   If this variable is defined, U-Boot will embed a device tree
 @@ -813,6 +813,13 @@ The following options need to be configured:
   is then picked up in board_init_f() and made available through
   the global data structure as gd-blob.
  
 + CONFIG_OF_SEPARATE
 + If this variable is defined, U-Boot will build a device tree
 + binary. It will be called u-boot.dtb. Architecture-specific
 + code will locate it at run-time. Generally this works by:
 +
 + cat u-boot.bin u-boot.dtb image.bin
 +
  - Watchdog:
   CONFIG_WATCHDOG
   If this variable is defined, it enables watchdog
 diff --git a/doc/README.fdt-control b/doc/README.fdt-control
 new file mode 100644
 index 000..dfc8f06
 --- /dev/null
 +++ b/doc/README.fdt-control
 @@ -0,0 +1,168 @@
 +#
 +# Copyright (c) 2011 The Chromium OS Authors.
 +#
 +# See file CREDITS for list of people who contributed to this
 +# project.
 +#
 +# This program is free software; you can redistribute it and/or
 +# modify it under the terms of the GNU General Public License as
 +# published by the Free Software Foundatio; either version 2 of
 +# the License, or (at your option) any later version.
 +#
 +# This program is distributed in the hope that it will be useful,
 +# but WITHOUT ANY WARRANTY; without even the implied warranty of
 +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.   See the
 +# GNU General Public License for more details.
 +#
 +# You should have received a copy of the GNU General Public License
 +# along with this program; if not, write to the Free Software
 +# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 +# MA 02111-1307 USA
 +#
 +
 +Device Tree Control in U-Boot
 +=
 +
 +This feature provides for run-time configuration of U-Boot via a flat
 +device tree (fdt). U-Boot configuration has traditionally been done
 +using CONFIG options in the board config file. This feature aims to
 +make it possible for a single U-Boot binary to support multiple boards,
 +with the exact configuration of each board controlled by a flat device
 +tree (fdt). This is the approach recently taken by the ARM Linux kernel
 +and has been used by PowerPC for some time.
 +
 +The fdt is a convenient vehicle for implementing run-time configuration
 +for three reasons. Firstly it is easy to use, being a simple text file.
 +It is extensible since it consists of nodes and properties in a nice
 +hierarchical format.
 +
 +Finally, there is already excellent infrastructure for the fdt: a
 +compiler checks the text file and converts it to a compact binary
 +format, and a library is already available in U-Boot (libfdt) for
 +handling this format.
 +

Re: [U-Boot] [RFC PATCH v2 2/6] fdt: Add support for embedded device tree (CONFIG_OF_EMBED)

On Wed, Sep 14, 2011 at 12:03 PM, Simon Glass s...@chromium.org 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 linaro
or kernel.org though because I want to make it clear that it is
absolutely not intended to be Linux-specific.

g.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH v2 2/6] fdt: Add support for embedded device tree (CONFIG_OF_EMBED)

On Wed, Sep 14, 2011 at 2:11 PM, Wolfgang Denk w...@denx.de 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 be so much more useful if the dtb
 can be concatenated to the u-boot binary so that it can be configured
 at install time.  Otherwise, switching to .dtb doesn't seem to

 Actually the DTB address should _always_ be taken from an environment
 variable, so we have full flexibility.

That doesn't work so well when u-boot needs the dtb to initialize
itself.  However, once initialized, I completely agree that the dtb
address should be in the env so that it can be changed as needed.

g.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable

2011-07-17 Thread Grant Likely

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. Longdave.l...@linaro.org
 
 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 to prevent 
 relocation
 of the fdt into highmem.  The variable behaves similarly to the existing 
 initrd_high
 variable.
 
 Signed-off-by: David A. Longdave.l...@linaro.org
 
 While I agree in principle with Scott's point that it would be good
 to understand and fix/improve the ARM bootm_linux_fdt() function, I
 have bought into Dave's argument that this is a useful environment
 variable and is symmetric with initrd_high.
 
 Consequently, I've added this patch to the u-boot-fdt repo.  If
 anyone has strong objects, now is the time to object strongly. ;-)

No, I certainly don't object.  My point is simply that it isn't
actually a fix for the bug.  Either the panda, or the generic arm
config needs to have a safe CONFIG_SYS_BOOTMAPSZ set.

g.

 
 Thanks,
 gvb
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable

2011-07-14 Thread Grant Likely

On Thursday, July 14, 2011, David Long dave.l...@linaro.org wrote:







 On Thu, 2011-07-14 at 09:10 -0400, Jerry Van Baren wrote:


 Hi Dave,

 This looks reasonable, with one minor nit...






 Need spaces around the =

 I will add the spaces before applying the patch unless you send an
 updated patch.




 OK, thanks much.  Someone else recently pointed that out to me too.  I can 
 generate another update if you wish, but I'll let you handle that unless you 
 say otherwise.

 FYI:  In case it wasn't clear, this all came about because: 1) the Pandaboard 
 has 1GB of RAM;  2) the presence of an fdt causes u-boot to relocate the fdt 
 and ramdisk to the end of ram by default;  3) and the Linux kernel does not 
 like having to access memory 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

Re: [U-Boot] [uboot PATCH v2] Add uboot fdt_high enviroment variable

2011-07-14 Thread Grant Likely

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
  a fix.
  
 
 
 Then someone needs to own the issue of stopping  the current u-boot
 default behavior of relocating the initrd and fdt to the end of RAM when
 an fdt is present.  This is an issue for any Linux ARM system with more
 than 3/4GB of RAM, and probably for other 32-bit architectures.   The
 logic that causes the problem is in architecture-independent code, and
 I'm not sure I'm necessarily the right guy to go rummaging around in
 there.  There are too many implications for any other currently
 supported targets that use u-boot and fdt.

You should have everything you need to fix it.  If
CONFIG_SYS_BOOTMAPSZ is defined, then U-Boot will not use memory
larger that that for the dtb or atags.

Right now CONFIG_SYS_BOOTMAPSZ is not set by default, but we could
default it to a sane value for ARM platforms.

A better solution in the long term may be to figure out the actual
memory footprint required, and not make things any larger than that,
but that requires U-Boot to be given more data about the kernel, or
the zImage wrapper to be more intelligent about dtb and initrd ranges
when uncompressing

g.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-boot SPL direct Linux boot

2011-07-04 Thread Grant Likely

On Fri, Jul 1, 2011 at 10:42 AM, Simon Schwarz
simonschwarz...@googlemail.com wrote:
 Addition: As I read a bit about FDT it does not replace ATAGS
 (http://elinux.org/Device_Trees) - it is more a supplement to it. So
 it would not harm to implement minimal ATAGS support and later add the
 FDT to it.

That was true in an early prototype, but it is not actually true
anymore.  Passing a DT replaces ATAGs on arm now, and that code is in
mainline.


 I started a prototype for ATAGS creation by modifying bootm.c - which
 seems (so long) not be too hard. If this works and doesn't add too
 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/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

Re: [U-Boot] [PATCH 1/2] fdt: add support the ePAPR phandle property

2011-05-06 Thread Grant Likely

On Fri, May 6, 2011 at 11:56 AM, Timur Tabi ti...@freescale.com wrote:
 The ePAPR specification says that phandle properties should be called
 phandle, and not linux,phandle.  To facilitate the migration from
 linux,phandle to phandle, we update some functions to support both
 properties.

 Signed-off-by: Timur Tabi ti...@freescale.com

As discussed on IRC, upstream libfdt already supports the phandle
property, so u-boot needs to be updated to the latest version from the
dtc.git repo on git.jdl.com.  You'll still need the change to
common/fdt_support.c though.

g.

 ---
  common/fdt_support.c |    6 ++
  include/libfdt.h     |   10 ++
  lib/libfdt/fdt_ro.c  |   18 ++
  3 files changed, 34 insertions(+), 0 deletions(-)

 diff --git a/common/fdt_support.c b/common/fdt_support.c
 index 496040b..85715ff 100644
 --- a/common/fdt_support.c
 +++ b/common/fdt_support.c
 @@ -1187,6 +1187,12 @@ int fdt_alloc_phandle(void *blob)

        for (offset = fdt_next_node(blob, -1, NULL); offset = 0;
             offset = fdt_next_node(blob, offset, NULL)) {
 +               /* Check the ePAPR-compliant phandle property name */
 +               val = fdt_getprop(blob, offset, phandle, len);
 +               if (val)
 +                       phandle = max(*val, phandle);
 +
 +               /* Also check the deprecated linux,phandle property name */
                val = fdt_getprop(blob, offset, linux,phandle, len);
                if (val)
                        phandle = max(*val, phandle);
 diff --git a/include/libfdt.h b/include/libfdt.h
 index d23d40e..092dd34 100644
 --- a/include/libfdt.h
 +++ b/include/libfdt.h
 @@ -452,6 +452,11 @@ static inline void *fdt_getprop_w(void *fdt, int 
 nodeoffset,
  * fdt_get_phandle() retrieves the phandle of the device tree node at
  * structure block offset nodeoffset.
  *
 + * Both the ePAPR phandle property as well as the legacy linux,phandle
 + * property are supported.  If the device tree node contains both properties,
 + * then phandle is used.  However, it is considered an error if the two
 + * properties contain different values.
 + *
  * returns:
  *     the phandle of the node at nodeoffset, on success (!= 0, != -1)
  *     0, if the node has no phandle, or another error occurs
 @@ -662,6 +667,11 @@ int fdt_node_offset_by_phandle(const void *fdt, uint32_t 
 phandle);
  * 'compatible' property with the given string as one of its elements,
  * it returns non-zero otherwise, or on error.
  *
 + * Both the ePAPR phandle property as well as the legacy linux,phandle
 + * property are supported.  If the device tree node contains both properties,
 + * then phandle is used.  However, it is considered an error if the two
 + * properties contain different values.
 + *
  * returns:
  *     0, if the node has a 'compatible' property listing the given string
  *     1, if the node has a 'compatible' property, but it does not list
 diff --git a/lib/libfdt/fdt_ro.c b/lib/libfdt/fdt_ro.c
 index 1e1e322..57a901f 100644
 --- a/lib/libfdt/fdt_ro.c
 +++ b/lib/libfdt/fdt_ro.c
 @@ -278,6 +278,14 @@ uint32_t fdt_get_phandle(const void *fdt, int nodeoffset)
        const uint32_t *php;
        int len;

 +       /* First, check the phandle property */
 +       php = fdt_getprop(fdt, nodeoffset, phandle, len);
 +       if (php) {
 +               /* If the property exists, then use it if it's valid */
 +               return len == sizeof(*php) ? fdt32_to_cpu(*php) : 0;
 +       }
 +
 +       /* No phandle, so check linux,phandle */
        php = fdt_getprop(fdt, nodeoffset, linux,phandle, len);
        if (!php || (len != sizeof(*php)))
                return 0;
 @@ -440,9 +448,19 @@ int fdt_node_offset_by_prop_value(const void *fdt, int 
 startoffset,

  int fdt_node_offset_by_phandle(const void *fdt, uint32_t phandle)
  {
 +       int ret;
 +
        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

Re: [U-Boot] Pull request: u-boot-fdt

2011-04-27 Thread Grant Likely

Thanks guys.

g.

On Wed, Apr 27, 2011 at 1:47 PM, Wolfgang Denk w...@denx.de 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]
 ARM device tree support improvements.  I had to make two minor fixes, a
 missing ; in patch [1 of 6] and a misspelling in patch [2 of 6]
    s/getenv_bootm_base/getenv_bootm_low/

 Note that I did *not* include patch [6 of 6] Add CONFIG_OF_LIBFDT to
 more boards since that is an ARM patch and should be applied by the
 various ARM custodians.

 The following changes since commit a01ebd9679f07421ec5abfda5dc0ab76c7202d3b:
    Heiko Schocher (1):
          mpc52xx, digsy_mtc: add trickle charger support for rev5 boards.

 are available in the git repository at:

    git://git.denx.de/u-boot-fdt.git master

 Grant Likely (5):
        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 passing initrd end address via device tree
        Respect memreserve regions specified in the device tree

   README                         |   16 -
   arch/arm/lib/bootm.c           |    5 ++-
   arch/m68k/lib/bootm.c          |    7 +---
   arch/powerpc/lib/bootm.c       |   19 +-
   common/cmd_bootm.c             |    7 ++--
   common/fdt_support.c           |    2 +-
   common/image.c                 |   72
 ++--
   include/configs/omap3_beagle.h |    7 
   include/image.h                |   10 +++---
   9 files changed, 93 insertions(+), 52 deletions(-)

 Applied, thanks.

 Best regards,

 Wolfgang Denk

 --
 DENX Software Engineering GmbH,     MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
 For every complex problem, there is a solution that is simple,  neat,
 and wrong.                                           -- H. L. Mencken




-- 
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

[U-Boot] [PATCH 0/6] ARM device tree support improvements

Hi Jerry  Wolfgang,

The following series fixes a bug in the device tree code and
eliminates the CONFIG_OF_LIBFDT dependency on CONFIG_SYS_BOOTMAPSZ.
It also adds parsing of the reserved mem regions so that U-Boot
doesn't decide to use a regions set aside for another purpose.

Finally, the last patch adds CONFIG_OF_LIBFDT to a bunch of boards.
I'm not expecting the last patch to be picked up in mainline (yet),
but it will be picked up into the Linaro tree for the 11.05 release.

John, this same series applies cleanly on the linaro-stable u-boot
tree.  Can you pick them up please?  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 passing initrd end address via device tree
  Respect memreserve regions specified in the device tree
  Add CONFIG_OF_LIBFDT to more boards.


 README  |   16 -
 arch/arm/lib/bootm.c|5 ++-
 arch/m68k/lib/bootm.c   |7 +---
 arch/powerpc/lib/bootm.c|   19 +-
 common/cmd_bootm.c  |7 ++--
 common/fdt_support.c|2 +
 common/image.c  |   72 +--
 include/configs/ca9x4_ct_vxp.h  |2 +
 include/configs/devkit8000.h|2 +
 include/configs/efikamx.h   |2 +
 include/configs/igep0020.h  |2 +
 include/configs/igep0030.h  |2 +
 include/configs/mx51evk.h   |2 +
 include/configs/mx53evk.h   |2 +
 include/configs/omap3_beagle.h  |7 
 include/configs/omap3_overo.h   |2 +
 include/configs/omap3_pandora.h |2 +
 include/configs/omap3_sdp3430.h |2 +
 include/configs/omap3_zoom1.h   |2 +
 include/configs/omap3_zoom2.h   |2 +
 include/configs/omap4_panda.h   |2 +
 include/configs/omap4_sdp4430.h |2 +
 include/configs/tegra2-common.h |1 +
 include/image.h |   10 +++--
 24 files changed, 122 insertions(+), 52 deletions(-)

-- 
Signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/6] Stop passing around bootmem_base value.

From: Grant Likely grant.lik...@linaro.org

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 them call getenv_bootm_low() directly.

Signed-off-by: Grant Likely grant.lik...@linaro.org
---
 arch/arm/lib/bootm.c |3 +--
 arch/m68k/lib/bootm.c|7 ++-
 arch/powerpc/lib/bootm.c |9 +++--
 common/cmd_bootm.c   |3 +--
 common/image.c   |   25 +
 include/image.h  |8 +++-
 6 files changed, 19 insertions(+), 36 deletions(-)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 7734953..aba13f4 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -178,7 +178,6 @@ static int bootm_linux_fdt(int machid, bootm_headers_t 
*images)
 {
ulong rd_len;
void (*kernel_entry)(int zero, int dt_machid, void *dtblob);
-   ulong bootmap_base = getenv_bootm_low();
ulong of_size = images-ft_len;
char **of_flat_tree = images-ft_addr;
ulong *initrd_start = images-initrd_start;
@@ -194,7 +193,7 @@ static int bootm_linux_fdt(int machid, bootm_headers_t 
*images)
if (ret)
return ret;
 
-   ret = boot_relocate_fdt(lmb, bootmap_base, of_flat_tree, of_size);
+   ret = boot_relocate_fdt(lmb, of_flat_tree, of_size);
if (ret)
return ret;
 
diff --git a/arch/m68k/lib/bootm.c b/arch/m68k/lib/bootm.c
index 76a2fb2..1229ac7 100644
--- a/arch/m68k/lib/bootm.c
+++ b/arch/m68k/lib/bootm.c
@@ -71,7 +71,6 @@ int do_bootm_linux(int flag, int argc, char * const argv[], 
bootm_headers_t *ima
int ret;
 
ulong cmd_start, cmd_end;
-   ulong bootmap_base;
bd_t  *kbd;
void  (*kernel) (bd_t *, ulong, ulong, ulong, ulong);
struct lmb *lmb = images-lmb;
@@ -79,17 +78,15 @@ int do_bootm_linux(int flag, int argc, char * const argv[], 
bootm_headers_t *ima
if ((flag != 0)  (flag != BOOTM_STATE_OS_GO))
return 1;
 
-   bootmap_base = getenv_bootm_low();
-
/* allocate space and init command line */
-   ret = boot_get_cmdline (lmb, cmd_start, cmd_end, bootmap_base);
+   ret = boot_get_cmdline (lmb, cmd_start, cmd_end);
if (ret) {
puts(ERROR with allocation of cmdline\n);
goto error;
}
 
/* allocate space for kernel copy of board info */
-   ret = boot_get_kbd (lmb, kbd, bootmap_base);
+   ret = boot_get_kbd (lmb, kbd);
if (ret) {
puts(ERROR with allocation of kernel bd\n);
goto error;
diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index 116d81b..11a574a 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -181,7 +181,6 @@ static void boot_prep_linux(void)
 
 static int boot_cmdline_linux(bootm_headers_t *images)
 {
-   ulong bootmap_base = getenv_bootm_low();
ulong of_size = images-ft_len;
struct lmb *lmb = images-lmb;
ulong *cmd_start = images-cmdline_start;
@@ -191,7 +190,7 @@ static int boot_cmdline_linux(bootm_headers_t *images)
 
if (!of_size) {
/* allocate space and init command line */
-   ret = boot_get_cmdline (lmb, cmd_start, cmd_end, bootmap_base);
+   ret = boot_get_cmdline (lmb, cmd_start, cmd_end);
if (ret) {
puts(ERROR with allocation of cmdline\n);
return ret;
@@ -203,7 +202,6 @@ static int boot_cmdline_linux(bootm_headers_t *images)
 
 static int boot_bd_t_linux(bootm_headers_t *images)
 {
-   ulong bootmap_base = getenv_bootm_low();
ulong of_size = images-ft_len;
struct lmb *lmb = images-lmb;
bd_t **kbd = images-kbd;
@@ -212,7 +210,7 @@ static int boot_bd_t_linux(bootm_headers_t *images)
 
if (!of_size) {
/* allocate space for kernel copy of board info */
-   ret = boot_get_kbd (lmb, kbd, bootmap_base);
+   ret = boot_get_kbd (lmb, kbd);
if (ret) {
puts(ERROR with allocation of kernel bd\n);
return ret;
@@ -230,7 +228,6 @@ static int boot_body_linux(bootm_headers_t *images)
ulong *initrd_start = images-initrd_start;
ulong *initrd_end = images-initrd_end;
 #if defined(CONFIG_OF_LIBFDT)
-   ulong bootmap_base = getenv_bootm_low();
ulong of_size = images-ft_len;
char **of_flat_tree = images-ft_addr;
 #endif
@@ -253,7 +250,7 @@ static int boot_body_linux(bootm_headers_t *images)
return ret;
 
 #if defined(CONFIG_OF_LIBFDT)  defined(CONFIG_SYS_BOOTMAPSZ)
-   ret = boot_relocate_fdt(lmb, bootmap_base, of_flat_tree, of_size);
+   ret = boot_relocate_fdt(lmb, of_flat_tree, of_size

[U-Boot] [PATCH 2/6] Default to bootm_size() when CONFIG_SYS_BOOTMAPSZ is not defined

From: Grant Likely grant.lik...@linaro.org

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.

getenv_bootm_mapsize() can also be overridden with a bootm_mapsize
environmental variable.

Signed-off-by: Grant Likely grant.lik...@linaro.org
---
 README   |   16 ++--
 arch/powerpc/lib/bootm.c |2 +-
 common/image.c   |   22 +++---
 include/image.h  |1 +
 4 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/README b/README
index 21cd71b..b8c1833 100644
--- a/README
+++ b/README
@@ -2311,7 +2311,10 @@ Configuration Settings:
used) must be put below this limit, unless bootm_low
enviroment variable is defined and non-zero. In such case
all data for the Linux kernel must be between bootm_low
-   and bootm_low + CONFIG_SYS_BOOTMAPSZ.
+   and bootm_low + CONFIG_SYS_BOOTMAPSZ.  The environment
+   variable bootm_mapsize will override the value of
+   CONFIG_SYS_BOOTMAPSZ.  If CONFIG_SYS_BOOTMAPSZ is undefined,
+   then the value in bootm_size will be used instead.
 
 - CONFIG_SYS_BOOT_RAMDISK_HIGH:
Enable initrd_high functionality.  If defined then the
@@ -3147,7 +3150,16 @@ List of environment variables (most likely not complete):
  for use by the bootm command. See also bootm_size
  environment variable. Address defined by bootm_low is
  also the base of the initial memory mapping for the Linux
- kernel -- see the description of CONFIG_SYS_BOOTMAPSZ.
+ kernel -- see the description of CONFIG_SYS_BOOTMAPSZ and
+ bootm_mapsize.
+
+  bootm_mapsize- Size of the initial memory mapping for the Linux 
kernel.
+ This variable is given as a hexadecimal number and it
+ defines the size of the memory region starting at base
+ address bootm_low that is accessible by the Linux kernel
+ during early boot.  If unset, CONFIG_SYS_BOOTMAPSZ is used
+ as the default value if it is defined, and bootm_size is
+ used otherwise.
 
   bootm_size   - Memory range available for image processing in the bootm
  command can be restricted. This variable is given as
diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index 11a574a..1ee4f79 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -95,7 +95,7 @@ static void boot_jump_linux(bootm_headers_t *images)
debug (   Booting using OF flat tree...\n);
WATCHDOG_RESET ();
(*kernel) ((bd_t *)of_flat_tree, 0, 0, EPAPR_MAGIC,
-  CONFIG_SYS_BOOTMAPSZ, 0, 0);
+  getenv_bootm_mapsize(), 0, 0);
/* does not return */
} else
 #endif
diff --git a/common/image.c b/common/image.c
index c86b86f..a6247d8 100644
--- a/common/image.c
+++ b/common/image.c
@@ -454,6 +454,22 @@ phys_size_t getenv_bootm_size(void)
 #endif
 }
 
+phys_size_t getenv_bootm_mapsize(void)
+{
+   phys_size_t tmp;
+   char *s = getenv (bootm_mapsize);
+   if (s) {
+   tmp = (phys_size_t)simple_strtoull (s, NULL, 16);
+   return tmp;
+   }
+
+#if defined(CONFIG_SYS_BOOTMAPSZ)
+   return CONFIG_SYS_BOOTMAPSZ;
+#else
+   return getenv_bootm_size();
+#endif
+}
+
 void memmove_wd (void *to, void *from, size_t len, ulong chunksz)
 {
if (to == from)
@@ -1207,7 +1223,7 @@ int boot_relocate_fdt (struct lmb *lmb, char 
**of_flat_tree, ulong *of_size)
/* Pad the FDT by a specified amount */
of_len = *of_size + CONFIG_SYS_FDT_PAD;
of_start = (void *)(unsigned long)lmb_alloc_base(lmb, of_len, 0x1000,
-   CONFIG_SYS_BOOTMAPSZ + getenv_bootm_low());
+   getenv_bootm_mapsize() + getenv_bootm_low());
 
if (of_start == 0) {
puts(device tree - allocation error\n);
@@ -1581,7 +1597,7 @@ int boot_get_cmdline (struct lmb *lmb, ulong *cmd_start, 
ulong *cmd_end)
char *s;
 
cmdline = (char *)(ulong)lmb_alloc_base(lmb, CONFIG_SYS_BARGSIZE, 0xf,
-CONFIG_SYS_BOOTMAPSZ + getenv_bootm_low());
+   getenv_bootm_mapsize() + getenv_bootm_base());
 
if (cmdline == NULL)
return -1;
@@ -1617,7 +1633,7 @@ int boot_get_cmdline (struct lmb *lmb, ulong *cmd_start, 
ulong *cmd_end)
 int boot_get_kbd (struct lmb *lmb, bd_t **kbd)
 {
*kbd = (bd_t *)(ulong)lmb_alloc_base(lmb, sizeof(bd_t), 0xf,
-CONFIG_SYS_BOOTMAPSZ

[U-Boot] [PATCH 3/6] Remove device tree booting dependency on CONFIG_SYS_BOOTMAPSZ

From: Grant Likely grant.lik...@linaro.org

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 grant.lik...@linaro.org
---
 arch/powerpc/lib/bootm.c   |4 ++--
 common/cmd_bootm.c |2 +-
 common/image.c |4 ++--
 include/configs/omap3_beagle.h |7 ---
 4 files changed, 5 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index 1ee4f79..180ee30 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -249,7 +249,7 @@ static int boot_body_linux(bootm_headers_t *images)
if (ret)
return ret;
 
-#if defined(CONFIG_OF_LIBFDT)  defined(CONFIG_SYS_BOOTMAPSZ)
+#if defined(CONFIG_OF_LIBFDT)
ret = boot_relocate_fdt(lmb, of_flat_tree, of_size);
if (ret)
return ret;
@@ -288,7 +288,7 @@ static int boot_body_linux(bootm_headers_t *images)
if (*initrd_start  *initrd_end)
fdt_initrd(*of_flat_tree, *initrd_start, *initrd_end, 
1);
}
-#endif /* CONFIG_OF_LIBFDT  CONFIG_SYS_BOOTMAPSZ */
+#endif /* CONFIG_OF_LIBFDT */
return 0;
 }
 
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index a5c275f..8a0a99e 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -544,7 +544,7 @@ int do_bootm_subcommand (cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv
}
break;
 #endif
-#if defined(CONFIG_OF_LIBFDT)  defined(CONFIG_SYS_BOOTMAPSZ)
+#if defined(CONFIG_OF_LIBFDT)
case BOOTM_STATE_FDT:
{
ret = boot_relocate_fdt(images.lmb,
diff --git a/common/image.c b/common/image.c
index a6247d8..127eda2 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1202,7 +1202,7 @@ static int fit_check_fdt (const void *fit, int 
fdt_noffset, int verify)
  *  0 - success
  *  1 - failure
  */
-#if defined(CONFIG_SYS_BOOTMAPSZ)
+#if defined(CONFIG_OF_LIBFDT)
 int boot_relocate_fdt (struct lmb *lmb, char **of_flat_tree, ulong *of_size)
 {
void*fdt_blob = *of_flat_tree;
@@ -1252,7 +1252,7 @@ int boot_relocate_fdt (struct lmb *lmb, char 
**of_flat_tree, ulong *of_size)
 error:
return 1;
 }
-#endif /* CONFIG_SYS_BOOTMAPSZ */
+#endif /* CONFIG_OF_LIBFDT */
 
 /**
  * boot_get_fdt - main fdt handling routine
diff --git a/include/configs/omap3_beagle.h b/include/configs/omap3_beagle.h
index 5cfa4cb..a0f6829 100644
--- a/include/configs/omap3_beagle.h
+++ b/include/configs/omap3_beagle.h
@@ -56,13 +56,6 @@
 #define CONFIG_MISC_INIT_R
 
 #define CONFIG_OF_LIBFDT   1
-/*
- * The early kernel mapping on ARM currently only maps from the base of DRAM
- * to the end of the kernel image.  The kernel is loaded at DRAM base + 0x8000.
- * The early kernel pagetable uses DRAM base + 0x4000 to DRAM base + 0x8000,
- * so that leaves DRAM base to DRAM base + 0x4000 available.
- */
-#define CONFIG_SYS_BOOTMAPSZ   0x4000
 
 #define CONFIG_CMDLINE_TAG 1   /* enable passing of ATAGs */
 #define CONFIG_SETUP_MEMORY_TAGS   1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 5/6] Respect memreserve regions specified in the device tree

From: Grant Likely grant.lik...@linaro.org

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 grant.lik...@linaro.org
---
 arch/arm/lib/bootm.c |2 ++
 arch/powerpc/lib/bootm.c |4 
 common/cmd_bootm.c   |2 ++
 common/image.c   |   29 -
 include/image.h  |1 +
 5 files changed, 37 insertions(+), 1 deletions(-)

diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index aba13f4..802e833 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -187,6 +187,8 @@ static int bootm_linux_fdt(int machid, bootm_headers_t 
*images)
 
kernel_entry = (void (*)(int, int, void *))images-ep;
 
+   boot_fdt_add_mem_rsv_regions(lmb, *of_flat_tree);
+
rd_len = images-rd_end - images-rd_start;
ret = boot_ramdisk_high(lmb, images-rd_start, rd_len,
initrd_start, initrd_end);
diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
index 180ee30..4744313 100644
--- a/arch/powerpc/lib/bootm.c
+++ b/arch/powerpc/lib/bootm.c
@@ -234,6 +234,10 @@ static int boot_body_linux(bootm_headers_t *images)
 
int ret;
 
+#if defined(CONFIG_OF_LIBFDT)
+   boot_fdt_add_mem_rsv_regions(lmb, *of_flat_tree);
+#endif
+
/* allocate space and init command line */
ret = boot_cmdline_linux(images);
if (ret)
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 8a0a99e..8729852 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -547,6 +547,8 @@ int do_bootm_subcommand (cmd_tbl_t *cmdtp, int flag, int 
argc, char * const argv
 #if defined(CONFIG_OF_LIBFDT)
case BOOTM_STATE_FDT:
{
+   boot_fdt_add_mem_rsv_regions(images.lmb,
+images.ft_addr);
ret = boot_relocate_fdt(images.lmb,
images.ft_addr, images.ft_len);
break;
diff --git a/common/image.c b/common/image.c
index 127eda2..d783808 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1185,6 +1185,34 @@ static int fit_check_fdt (const void *fit, int 
fdt_noffset, int verify)
 #define CONFIG_SYS_FDT_PAD 0x3000
 #endif
 
+#if defined(CONFIG_OF_LIBFDT)
+/**
+ * boot_fdt_add_mem_rsv_regions - Mark the memreserve sections as unusable
+ * @lmb: pointer to lmb handle, will be used for memory mgmt
+ * @fdt_blob: pointer to fdt blob base address
+ *
+ * Adds the memreserve regions in the dtb to the lmb block.  Adding the
+ * memreserve regions prevents u-boot from using them to store the initrd
+ * or the fdt blob.
+ */
+void boot_fdt_add_mem_rsv_regions(struct lmb *lmb, void *fdt_blob)
+{
+   uint64_t addr, size;
+   int i, total;
+
+   if (fdt_check_header (fdt_blob) != 0)
+   return;
+
+   total = fdt_num_mem_rsv(fdt_blob);
+   for (i = 0; i  total; i++) {
+   if (fdt_get_mem_rsv(fdt_blob, i, addr, size) != 0)
+   continue;
+   printf(   reserving fdt memory region: addr=%llx size=%llx\n,
+   (unsigned long long)addr, (unsigned long long)size);
+   lmb_reserve(lmb, addr, size);
+   }
+}
+
 /**
  * boot_relocate_fdt - relocate flat device tree
  * @lmb: pointer to lmb handle, will be used for memory mgmt
@@ -1202,7 +1230,6 @@ static int fit_check_fdt (const void *fit, int 
fdt_noffset, int verify)
  *  0 - success
  *  1 - failure
  */
-#if defined(CONFIG_OF_LIBFDT)
 int boot_relocate_fdt (struct lmb *lmb, char **of_flat_tree, ulong *of_size)
 {
void*fdt_blob = *of_flat_tree;
diff --git a/include/image.h b/include/image.h
index b77cb79..43e6ab6 100644
--- a/include/image.h
+++ b/include/image.h
@@ -336,6 +336,7 @@ int boot_get_ramdisk (int argc, char * const argv[], 
bootm_headers_t *images,
 #ifdef CONFIG_OF_LIBFDT
 int boot_get_fdt (int flag, int argc, char * const argv[], bootm_headers_t 
*images,
char **of_flat_tree, ulong *of_size);
+void boot_fdt_add_mem_rsv_regions(struct lmb *lmb, void *fdt_blob);
 int boot_relocate_fdt (struct lmb *lmb, char **of_flat_tree, ulong *of_size);
 #endif
 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 6/6] Add CONFIG_OF_LIBFDT to more boards.

From: Grant Likely grant.lik...@linaro.org

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 boards:
Harmony

Signed-off-by: Grant Likely grant.lik...@linaro.org
---
 include/configs/ca9x4_ct_vxp.h  |2 ++
 include/configs/devkit8000.h|2 ++
 include/configs/efikamx.h   |2 ++
 include/configs/igep0020.h  |2 ++
 include/configs/igep0030.h  |2 ++
 include/configs/mx51evk.h   |2 ++
 include/configs/mx53evk.h   |2 ++
 include/configs/omap3_overo.h   |2 ++
 include/configs/omap3_pandora.h |2 ++
 include/configs/omap3_sdp3430.h |2 ++
 include/configs/omap3_zoom1.h   |2 ++
 include/configs/omap3_zoom2.h   |2 ++
 include/configs/omap4_panda.h   |2 ++
 include/configs/omap4_sdp4430.h |2 ++
 include/configs/tegra2-common.h |1 +
 15 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/include/configs/ca9x4_ct_vxp.h b/include/configs/ca9x4_ct_vxp.h
index 63f003d..8f52961 100644
--- a/include/configs/ca9x4_ct_vxp.h
+++ b/include/configs/ca9x4_ct_vxp.h
@@ -43,6 +43,8 @@
 #define CONFIG_L2_OFF  1
 #define CONFIG_INITRD_TAG  1
 
+#define CONFIG_OF_LIBFDT   1
+
 /* Size of malloc() pool */
 #define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 128 * 1024)
 
diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index d898b77..a8f5350 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -61,6 +61,8 @@
 #define CONFIG_INITRD_TAG  1
 #define CONFIG_REVISION_TAG1
 
+#define CONFIG_OF_LIBFDT   1
+
 /* Size of malloc() pool */
 #define CONFIG_ENV_SIZE(128  10) /* 128 KiB */
/* Sector */
diff --git a/include/configs/efikamx.h b/include/configs/efikamx.h
index 1424347..571c3cb 100644
--- a/include/configs/efikamx.h
+++ b/include/configs/efikamx.h
@@ -66,6 +66,8 @@
 #define CONFIG_SETUP_MEMORY_TAGS
 #define CONFIG_INITRD_TAG
 
+#define CONFIG_OF_LIBFDT   1
+
 /*
  * Size of malloc() pool
  */
diff --git a/include/configs/igep0020.h b/include/configs/igep0020.h
index c19ecc0..930d50c 100644
--- a/include/configs/igep0020.h
+++ b/include/configs/igep0020.h
@@ -53,6 +53,8 @@
 #define CONFIG_INITRD_TAG  1
 #define CONFIG_REVISION_TAG1
 
+#define CONFIG_OF_LIBFDT   1
+
 /*
  * NS16550 Configuration
  */
diff --git a/include/configs/igep0030.h b/include/configs/igep0030.h
index 1325bfa..dfccffc 100644
--- a/include/configs/igep0030.h
+++ b/include/configs/igep0030.h
@@ -53,6 +53,8 @@
 #define CONFIG_INITRD_TAG  1
 #define CONFIG_REVISION_TAG1
 
+#define CONFIG_OF_LIBFDT   1
+
 /*
  * NS16550 Configuration
  */
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index 591d6e1..e9d06af 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -46,6 +46,8 @@
 #define CONFIG_SETUP_MEMORY_TAGS   1
 #define CONFIG_INITRD_TAG  1
 
+#define CONFIG_OF_LIBFDT   1
+
 /*
  * Size of malloc() pool
  */
diff --git a/include/configs/mx53evk.h b/include/configs/mx53evk.h
index f2a5752..78122a7 100644
--- a/include/configs/mx53evk.h
+++ b/include/configs/mx53evk.h
@@ -38,6 +38,8 @@
 #define CONFIG_SETUP_MEMORY_TAGS   1
 #define CONFIG_INITRD_TAG  1
 
+#define CONFIG_OF_LIBFDT   1
+
 /* Size of malloc() pool */
 #define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 2 * 1024 * 1024)
 
diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
index 1b3d439..4b91b73 100644
--- a/include/configs/omap3_overo.h
+++ b/include/configs/omap3_overo.h
@@ -52,6 +52,8 @@
 #define CONFIG_INITRD_TAG  1
 #define CONFIG_REVISION_TAG1
 
+#define CONFIG_OF_LIBFDT   1
+
 /*
  * Size of malloc() pool
  */
diff --git a/include/configs/omap3_pandora.h b/include/configs/omap3_pandora.h
index 72b0cc2..b4f08c8 100644
--- a/include/configs/omap3_pandora.h
+++ b/include/configs/omap3_pandora.h
@@ -55,6 +55,8 @@
 #define CONFIG_INITRD_TAG  1
 #define CONFIG_REVISION_TAG1
 
+#define CONFIG_OF_LIBFDT   1
+
 /*
  * Size of malloc() pool
  */
diff --git a/include/configs/omap3_sdp3430.h b/include/configs/omap3_sdp3430.h
index 4708981..91354a9 100644
--- a/include/configs/omap3_sdp3430.h
+++ b/include/configs/omap3_sdp3430.h
@@ -71,6 +71,8 @@
 #define CONFIG_INITRD_TAG  1
 #define CONFIG_REVISION_TAG1
 
+#define CONFIG_OF_LIBFDT   1
+
 /*
  * Size of malloc() pool
  * Total Size Environment - 256k
diff --git a/include/configs/omap3_zoom1.h b/include/configs/omap3_zoom1.h
index f7d0652

[U-Boot] [PATCH 4/6] Fix off-by-one error in passing initrd end address via device tree

From: Grant Likely grant.lik...@linaro.org

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 grant.lik...@linaro.org
---
 common/fdt_support.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 6c98e5b..1b5f9c8 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -183,7 +183,7 @@ int fdt_initrd(void *fdt, ulong initrd_start, ulong 
initrd_end, int force)
}
}
 
-   err = fdt_add_mem_rsv(fdt, initrd_start, initrd_end - initrd_start + 1);
+   err = fdt_add_mem_rsv(fdt, initrd_start, initrd_end - initrd_start);
if (err  0) {
printf(fdt_initrd: %s\n, fdt_strerror(err));
return err;

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] U-Boot 2010.12 Cannot Successfully Save Variables with Redundant NAND Environment

2011-02-06 Thread Grant Erickson

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:

= version

U-Boot 2010.12 (Feb 04 2011 - 16:12:51)
= env print foo
## Error: foo not defined
= env set foo bar
= env save
Saving Environment to NAND...
Erasing redundant NAND...
Erasing at 0x3a -- 100% complete.
Writing to redundant NAND... done
= env print foo
foo=bar
= reset
resetting ...

...

Hit any key to stop autoboot:  0
= env print foo
## Error: foo not defined

However, I can successfully read and write NAND, for example, updating
u-boot.

Anyone else noticed this on OMAP-based boards? With NAND? With NOR?

Running a few more experiments, I find that I can entirely whack the
environment, set a variable once thereafter, but never again:

= printenv resetenv
resetenv=nand erase 0x34 0x1000  nand erase 0x3a 0x1000
= run resetenv

NAND erase: device 0 offset 0x34, size 0x1000
Erasing at 0x34 -- 100% complete.
OK

NAND erase: device 0 offset 0x3a, size 0x1000
Erasing at 0x3a -- 100% complete.
OK
= reset
resetting ...

...
*** Warning - bad CRC, using default environment
...
Hit any key to stop autoboot:  0

= saveenv
Saving Environment to NAND...
Erasing redundant NAND...
Erasing at 0x3a -- 100% complete.
Writing to redundant NAND... done
= setenv foo bar
= printenv foo
foo=bar
= saveenv
Saving Environment to NAND...
Erasing NAND...
Erasing at 0x34 -- 100% complete.
Writing to NAND... done
= printenv foo
foo=bar
= reset
resetting ...

...
Hit any key to stop autoboot:  0
= printenv foo
foo=bar
= env delete foo
Not implemented yet
= setenv foo
= printenv foo
## Error: foo not defined
= saveenv
Saving Environment to NAND...
Erasing redundant NAND...
Erasing at 0x3a -- 100% complete.
Writing to redundant NAND... done
= printenv foo
## Error: foo not defined
= reset
resetting ...

...
Hit any key to stop autoboot:  0
= 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

Re: [U-Boot] U-Boot 2010.12 Cannot Successfully Save Variables with Redundant NAND Environment

2011-02-06 Thread Grant Erickson

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:

http://www.mail-archive.com/u-boot@lists.denx.de/msg46834.html

http://git.denx.de/?p=u-boot.git;a=commitdiff;h=920a5dd2325438a82b6ac8102c5a
5e0c43276fd;hp=42d44f631c4e8e5359775bdc098f2fffde4e5c05

However, it's not clear how this patch can reasonably work outside of random
chance:

// Allocate a new environment on the stack. The environment structure is
// whatever random data is already on the stack.

env_tenv_new;

...

// At this point, the data field will be initialized; however, crc and
// flags are still random data.

res = (char *)env_new.data;
len = hexport_r(env_htab, '\0', res, ENV_SIZE);

// The crc field is now set.

env_new.crc   = crc32(0, env_new.data, ENV_SIZE);

// Preincrement random data.

++env_new.flags; /* increase the serial */

Unfortunately, preincrementing random data won't replicate the behavior of
2010.09, where the flags field was referenced through a global env_ptr such
that flag manipulation was handled (more) coherently as the environment was
read and written.

Best,

Grant


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Make it possible to allocate physical address 0 with lmb

2011-01-26 Thread Grant Likely

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: Grant Likely grant.lik...@secretlab.ca
---
 common/image.c |8 
 include/lmb.h  |1 +
 lib/lmb.c  |   21 -
 3 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/common/image.c b/common/image.c
index 11504de..c1757bd 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1053,7 +1053,7 @@ int boot_ramdisk_high (struct lmb *lmb, ulong rd_data, 
ulong rd_len,
else
*initrd_start = (ulong)lmb_alloc (lmb, rd_len, 
0x1000);
 
-   if (*initrd_start == 0) {
+   if (*initrd_start == LMB_ALLOC_ERROR) {
puts (ramdisk - allocation error\n);
goto error;
}
@@ -1228,7 +1228,7 @@ int boot_relocate_fdt (struct lmb *lmb, ulong 
bootmap_base,
of_start = (unsigned long)lmb_alloc_base(lmb, of_len, 0x1000,
(CONFIG_SYS_BOOTMAPSZ + bootmap_base));
 
-   if (of_start == 0) {
+   if (of_start == (unsigned long)LMB_ALLOC_ERROR) {
puts(device tree - allocation error\n);
goto error;
}
@@ -1614,7 +1614,7 @@ int boot_get_cmdline (struct lmb *lmb, ulong *cmd_start, 
ulong *cmd_end,
cmdline = (char *)(ulong)lmb_alloc_base(lmb, CONFIG_SYS_BARGSIZE, 0xf,
 CONFIG_SYS_BOOTMAPSZ + bootmap_base);
 
-   if (cmdline == NULL)
+   if (cmdline == (char*)(ulong)LMB_ALLOC_ERROR)
return -1;
 
if ((s = getenv(bootargs)) == NULL)
@@ -1651,7 +1651,7 @@ int boot_get_kbd (struct lmb *lmb, bd_t **kbd, ulong 
bootmap_base)
 {
*kbd = (bd_t *)(ulong)lmb_alloc_base(lmb, sizeof(bd_t), 0xf,
  CONFIG_SYS_BOOTMAPSZ + bootmap_base);
-   if (*kbd == NULL)
+   if (*kbd == (bd_t *)(ulong)LMB_ALLOC_ERROR)
return -1;
 
**kbd = *(gd-bd);
diff --git a/include/lmb.h b/include/lmb.h
index 43082a3..f927b86 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -15,6 +15,7 @@
  */
 
 #define MAX_LMB_REGIONS 8
+#define LMB_ALLOC_ERROR ((phys_addr_t) ~0)
 
 struct lmb_property {
phys_addr_t base;
diff --git a/lib/lmb.c b/lib/lmb.c
index c5e75fb..de3c325 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -114,6 +114,9 @@ static long lmb_add_region(struct lmb_region *rgn, 
phys_addr_t base, phys_size_t
unsigned long coalesced = 0;
long adjacent, i;
 
+   debug(lmb_add_region(lmb=%x, base=%.8lx, size=%.8lx)\n,
+   (ulong)rgn, (ulong)base, (ulong)size);
+
if ((rgn-cnt == 1)  (rgn-region[0].size == 0)) {
rgn-region[0].base = base;
rgn-region[0].size = size;
@@ -266,9 +269,11 @@ phys_addr_t lmb_alloc_base(struct lmb *lmb, phys_size_t 
size, ulong align, phys_
 
alloc = __lmb_alloc_base(lmb, size, align, max_addr);
 
-   if (alloc == 0)
-   printf(ERROR: Failed to allocate 0x%lx bytes below 0x%lx.\n,
+   if (alloc == LMB_ALLOC_ERROR) {
+   debug(ERROR: Failed to allocate 0x%lx bytes below 0x%lx.\n,
  (ulong)size, (ulong)max_addr);
+   lmb_dump_all(lmb);
+   }
 
return alloc;
 }
@@ -289,10 +294,15 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t 
size, ulong align, phy
phys_addr_t base = 0;
phys_addr_t res_base;
 
+   debug(lmb_alloc_base(lmb=%lx, size=%lx, align=%li, max_addr=%lx)\n,
+   (ulong)lmb, (ulong)size, (ulong)align, (ulong)max_addr);
+
for (i = lmb-memory.cnt-1; i = 0; i--) {
phys_addr_t lmbbase = lmb-memory.region[i].base;
phys_size_t lmbsize = lmb-memory.region[i].size;
 
+   debug(--loop i=%i, lmbbase=%lx, lmbsize=%lx\n,
+   i, (ulong)lmbbase, (ulong)lmbsize);
if (lmbsize  size)
continue;
if (max_addr == LMB_ALLOC_ANYWHERE)
@@ -303,14 +313,15 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb, phys_size_t 
size, ulong align, phy
} else
continue;
 
-   while (base  lmbbase = base) {
+   while (lmbbase = base) {
j = lmb_overlaps_region(lmb-reserved, base, size);
+   debug(loop base=%lx, j=%i\n, (ulong)base, j);
if (j  0) {
/* This area isn't reserved, take it */
if (lmb_add_region(lmb-reserved, base,
lmb_align_up(size

Re: [U-Boot] [PATCH] Make it possible to allocate physical address 0 with lmb

2011-01-26 Thread Grant Likely

On Wed, Jan 26, 2011 at 9:57 AM, Grant Likely grant.lik...@secretlab.ca 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 between a region allocated at zero and a failed
 allocation

 Signed-off-by: Grant Likely grant.lik...@secretlab.ca

Oops, sent this one out too early.  It will not apply against current
mainline since it it based on an older tree.  Still, please take a
look and let me know it this looks appropriate.  I'll get this rebased
and retested against top of tree.

g.

 ---
  common/image.c |    8 
  include/lmb.h  |    1 +
  lib/lmb.c      |   21 -
  3 files changed, 21 insertions(+), 9 deletions(-)

 diff --git a/common/image.c b/common/image.c
 index 11504de..c1757bd 100644
 --- a/common/image.c
 +++ b/common/image.c
 @@ -1053,7 +1053,7 @@ int boot_ramdisk_high (struct lmb *lmb, ulong rd_data, 
 ulong rd_len,
                        else
                                *initrd_start = (ulong)lmb_alloc (lmb, rd_len, 
 0x1000);

 -                       if (*initrd_start == 0) {
 +                       if (*initrd_start == LMB_ALLOC_ERROR) {
                                puts (ramdisk - allocation error\n);
                                goto error;
                        }
 @@ -1228,7 +1228,7 @@ int boot_relocate_fdt (struct lmb *lmb, ulong 
 bootmap_base,
                of_start = (unsigned long)lmb_alloc_base(lmb, of_len, 0x1000,
                                (CONFIG_SYS_BOOTMAPSZ + bootmap_base));

 -               if (of_start == 0) {
 +               if (of_start == (unsigned long)LMB_ALLOC_ERROR) {
                        puts(device tree - allocation error\n);
                        goto error;
                }
 @@ -1614,7 +1614,7 @@ int boot_get_cmdline (struct lmb *lmb, ulong 
 *cmd_start, ulong *cmd_end,
        cmdline = (char *)(ulong)lmb_alloc_base(lmb, CONFIG_SYS_BARGSIZE, 0xf,
                                         CONFIG_SYS_BOOTMAPSZ + bootmap_base);

 -       if (cmdline == NULL)
 +       if (cmdline == (char*)(ulong)LMB_ALLOC_ERROR)
                return -1;

        if ((s = getenv(bootargs)) == NULL)
 @@ -1651,7 +1651,7 @@ int boot_get_kbd (struct lmb *lmb, bd_t **kbd, ulong 
 bootmap_base)
  {
        *kbd = (bd_t *)(ulong)lmb_alloc_base(lmb, sizeof(bd_t), 0xf,
                                      CONFIG_SYS_BOOTMAPSZ + bootmap_base);
 -       if (*kbd == NULL)
 +       if (*kbd == (bd_t *)(ulong)LMB_ALLOC_ERROR)
                return -1;

        **kbd = *(gd-bd);
 diff --git a/include/lmb.h b/include/lmb.h
 index 43082a3..f927b86 100644
 --- a/include/lmb.h
 +++ b/include/lmb.h
 @@ -15,6 +15,7 @@
  */

  #define MAX_LMB_REGIONS 8
 +#define LMB_ALLOC_ERROR ((phys_addr_t) ~0)

  struct lmb_property {
        phys_addr_t base;
 diff --git a/lib/lmb.c b/lib/lmb.c
 index c5e75fb..de3c325 100644
 --- a/lib/lmb.c
 +++ b/lib/lmb.c
 @@ -114,6 +114,9 @@ static long lmb_add_region(struct lmb_region *rgn, 
 phys_addr_t base, phys_size_t
        unsigned long coalesced = 0;
        long adjacent, i;

 +       debug(lmb_add_region(lmb=%x, base=%.8lx, size=%.8lx)\n,
 +               (ulong)rgn, (ulong)base, (ulong)size);
 +
        if ((rgn-cnt == 1)  (rgn-region[0].size == 0)) {
                rgn-region[0].base = base;
                rgn-region[0].size = size;
 @@ -266,9 +269,11 @@ phys_addr_t lmb_alloc_base(struct lmb *lmb, phys_size_t 
 size, ulong align, phys_

        alloc = __lmb_alloc_base(lmb, size, align, max_addr);

 -       if (alloc == 0)
 -               printf(ERROR: Failed to allocate 0x%lx bytes below 0x%lx.\n,
 +       if (alloc == LMB_ALLOC_ERROR) {
 +               debug(ERROR: Failed to allocate 0x%lx bytes below 0x%lx.\n,
                      (ulong)size, (ulong)max_addr);
 +               lmb_dump_all(lmb);
 +       }

        return alloc;
  }
 @@ -289,10 +294,15 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb, 
 phys_size_t size, ulong align, phy
        phys_addr_t base = 0;
        phys_addr_t res_base;

 +       debug(lmb_alloc_base(lmb=%lx, size=%lx, align=%li, max_addr=%lx)\n,
 +               (ulong)lmb, (ulong)size, (ulong)align, (ulong)max_addr);
 +
        for (i = lmb-memory.cnt-1; i = 0; i--) {
                phys_addr_t lmbbase = lmb-memory.region[i].base;
                phys_size_t lmbsize = lmb-memory.region[i].size;

 +               debug(--loop i=%i, lmbbase=%lx, lmbsize=%lx\n,
 +                       i, (ulong)lmbbase, (ulong)lmbsize);
                if (lmbsize  size)
                        continue;
                if (max_addr == LMB_ALLOC_ANYWHERE)
 @@ -303,14 +313,15 @@ phys_addr_t __lmb_alloc_base(struct lmb *lmb, 
 phys_size_t size, ulong align, phy
                } else
                        continue;

 -               while (base  lmbbase = base) {
 +               while (lmbbase = base

Re: [U-Boot] [PATCH] Make it possible to allocate physical address 0 with lmb

2011-01-26 Thread Grant Likely

On Wed, Jan 26, 2011 at 11:30 AM, Wolfgang Denk w...@denx.de 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 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: Grant Likely grant.lik...@secretlab.ca
 ...
 --- a/lib/lmb.c
 +++ b/lib/lmb.c
 @@ -114,6 +114,9 @@ static long lmb_add_region(struct lmb_region *rgn, 
 phys_addr_t base, phys_size_t
 ...
 -     if (alloc == 0)
 -             printf(ERROR: Failed to allocate 0x%lx bytes below 0x%lx.\n,
 +     if (alloc == LMB_ALLOC_ERROR) {
 +             debug(ERROR: Failed to allocate 0x%lx bytes below 0x%lx.\n,
                     (ulong)size, (ulong)max_addr);
 +             lmb_dump_all(lmb);
 +     }

 Do you intentionally change the printf() into a debug() here?  If yes,
 what is your rationale for not printing a proper error message in
 production code?

No, that was a mistake.  I'll correct it.

g.


 Best regards,

 Wolfgang Denk

 --
 DENX Software Engineering GmbH,     MD: Wolfgang Denk  Detlev Zundel
 HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
 Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
 I knew then (in 1970) that a 4-kbyte minicomputer would cost as much
 as a house. So I reasoned  that  after  college,  I'd  have  to  live
 cheaply in an apartment and put all my money into owning a computer.
      - Apple co-founder Steve Wozniak, EE Times, June 6, 1988, pg 45




-- 
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

Re: [U-Boot] OT Flashing high volume of devices

2010-11-18 Thread Grant Edwards

On 2010-11-18, Hamilton Vera hamilton.lis...@gmail.com wrote:
 Hi folks this is probably out off topic, we are happily using uboot in
 our devices but I am wondering about the procedures to flash/deploy
 uboot (or any bootloader) in a high scale production environment.

 Are you guys aware of any documentation 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.comASBESTOS leaking into my
   PERSONAL SPACE!!

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [WIP] tools/env: cleanup host build flags

2010-11-10 Thread Grant Edwards

On 2010-11-10, Wolfgang Denk w...@denx.de wrote:
 Dear Mike Frysinger,

 In message 201011100423.13449.vap...@gentoo.org you wrote:

  - use the cross compiler again (fw_printenv is intended for a
hosted environment on the target).
 
 the cross-compiler used to create u-boot has no guarantee that it'll produce 
 executables useful for the target OS.  often this isnt the case.  HOSTCC 

 Really? You mean, you need different tool chains to build U-Boot, the
 Linux kernel or user space applications?  Frankly, I consider those
 tool chains broken. 

Sounds like somethings broken to me as well. I've always used the same
toolchain for U-Boot, Kernel, Atmel bootstrap, and user-space stuff
(vis buildroot).

The only think I use a separate toolchain for are Atmel's applets
that are 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   
  gmail.com

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?

On 2010-08-23, Detlev Zundel d...@denx.de wrote:
 Hi Jef,

 10) The system I work on is a bareboard embedded system using U-boot
 to start up. That is why we are trying to use S-record files for
 uploading new programs, and not the more efficient FTP used in Linux.
 So you do have a network interface on your board?  Heck, why don;t you
 use TFTP then???

 I didn't say that. I was trying to say that our bareboard system
 doesn't support Ethernet and does not have TCP/IP stack (like Linux).
 If our system was a Linux system, we wouldn't be having this
 conversation.

 We use tftp in U-Boot exactly because we also do not have a TCP/IP
 stack :)

 tftp needs only udp is thus not too complex to implement on bare
 ethernet.

Doesn'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 this SWITCH
  at   I'll be RITA HAYWORTH!!
  gmail.comOr a SCIENTOLOGIST!

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?

On 2010-08-23, Detlev Zundel d...@denx.de wrote:

 I didn't say that. I was trying to say that our bareboard system
 doesn't support Ethernet and does not have TCP/IP stack (like Linux).
 If our system was a Linux system, we wouldn't be having this
 conversation.

 We use tftp in U-Boot exactly because we also do not have a TCP/IP
 stack :)

 tftp needs only udp is thus not too complex to implement on bare
 ethernet.

 Doesn't our bareboard system doesn't support Ethernet preclude the
 use of Ethernet (UDP or otherwise)?

 Yes, sorry.  I was mislead by the and not the more efficient FTP
 used in Linux.  The pure mentioning of FTP which does not make any
 sense without a network port made me read the following statement not
 close enough.

I thought maybe I had lost track of who posted what. :)

 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 a network hardware.

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 could require out customers to install a tftp server
on their machines.  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 pretty much a stand-alone
addition except for 3-4 lines in net.[ch]).  But it was made
abundantly clear that tftp server code for U-Boot would never be
considered -- I was scolded for even asking about it.

-- 
Grant Edwards   grant.b.edwardsYow! Life is a POPULARITY
  at   CONTEST!  I'm REFRESHINGLY
  gmail.comCANDID!!

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?

On 2010-08-23, Ben Warren biggerbadder...@gmail.com 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 could require out customers to install a tftp server
 on their machines.  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 pretty much a stand-alone
 addition except for 3-4 lines in net.[ch]).  But it was made
 abundantly clear that tftp server code for U-Boot would never be
 considered -- I was scolded for even asking about it.

 I can see how this could be useful.  Please reconsider and we'll try to 
 keep the scolding to a minimum :)

OK.  I need clean up the sources a little.  There's still some debug
code that doesn't really need to be there any longer.

There's one bit of ugliness on which I could use some advice.  The
tftp server knows how to write to NAND flash, and uses a RAM buffer
the same size as an erase block.  Right now I just arbitrarily use a
128K block of RAM starting 256K below text base.  That works for my
board, but I'm sure isn't the right way to do things.  What is the
right way for a command to allocate a large, temporary buffer?
Increasing the stack/heap size to accomodate a 128K buffer doesn't
seem like the right thing to do, nor does statically allocating it.

It also only supports a single nand device.

In the meantime, here's the document describing how it works:




The U-Boot tftp server is run as a normal U-Boot command and uses
special filenames to specify source/destination of data and actions to
be performed:

  Destination (used with put or write requests)

   r...@12345678

   Writes receive data into ram starting at address
   12345678 (decimal).

   n...@0x2c0

   Writes receive data into nand flash starting at address
   0x2C0.  Nand will be erased before writing.  Writes to
   nand flash must start on 128K page boundaries and write
   sizes will be rounded up to the next 4K page boundary.

   c...@ubootcmdstring

   Discards any data sent. After transfer completes,
   interprets 'ubootcmdstring' as if it were entered at the
   U-Boot command prompt.  Command output will appear on
   normal console device.

  Source (used with get or read request)

   n...@0x12345678:4321

   Sends 4321 bytes of data from nand flash starting at
   address 0x12345678.  Reads from nand must start on a 512
   byte boundary.

   r...@0x12345678:0x4321

   Sends 0x4321 bytes of data from ram starting at address
   0x12345678.

   c...@ubootcmdstring

   Interprets 'ubootcmdstring' as if it were entered at the
   U-Boot command prompt and then sends the output of that
   command as tftp data.  If this is used for commands like
   boot, the transfer will hang because executing the
   command will terminate U-Boot.  Such commands should be
   executed using a write request rather than a read
   request.


  Either Destination or source (either put or get)

   The following filenames return 0 bytes of data when read from
   and will discard any data when written to.  After the 0 byte
   data transfer completes, they invoke the actions described.

   nander...@0x80:0x2

   Erases 0x2 bytes of nand flash starting at address
   0x80. Erase operation must start on 128K page boundary
   and erase size must be an integral multiple of 128K.

   g...@0x12345678

   Jump to address 0x12345678.

   reset@

   Reset the board.

   exitok@

   Exit tftp server with success status.

   exitfail@

   Exit tftp server with fail status.



When invoking the U-Boot tftp server, an idle-timeout (in seconds) may
be specified.  If no tftp requests are received within that time, the
server will terminate (with a success status).  If two arguments are
specified, the first is the idle-timeout at startup, and the second is
the idle-timeout that is used after the first tftp request has been
handled.  Timeout values of 0 mean 'run until somebody hits Ctrl-C on
the console'.

When the tftpserver terminates due to an idle timeout after an initial
command has been received, it exits with a failure status.




-- 
Grant Edwards   grant.b.edwardsYow! This is a NO-FRILLS
  at   flight -- hold th' CANADIAN

Re: [U-Boot] FW: which protocol do I use to send S-record files when using the loads command ?