date:20150207

Re: [U-Boot] [PATCH sunxi-tools] WIP: fel: Add a command for loading U-Boot SPL binaries in eGON format

2015-02-07 Thread Hans de Goede

Hi,

On 02/07/2015 04:17 AM, Siarhei Siamashka wrote:
On Thu, 5 Feb 2015 22:49:39 -0700
Simon Glass s...@chromium.org wrote:

Hi Siarhei,

On 5 February 2015 at 02:36, Siarhei Siamashka
siarhei.siamas...@gmail.com wrote:
!!! Works only on Allwinner A20 so far and needs a bit more
!!! debugging. And even on A20, the transition from the SPL to
!!! the main U-boot binary has some glitches.

Now it should be possible to load and execute the same U-Boot SPL,
as used for booting from SD cards. The only argument for this new
command is the name of the SPL binary file (with eGON header).
It can be run as:

fel spl u-boot-sunxi-with-spl.bin

This looks great! Does it write only the SPL portion or does it write
U-Boot also?

Yes, it only takes care of the SPL part at the moment, but surely
this can be improved later.

The biggest inconvenience is that we need to provide the 'fel' tool
with with the magic address for the main u-boot binary. This address
is hidden in the u-boot sources:

http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/sunxi-common.h;h=6cfd7e148900#l28

But the users need to know it in order to set in as the command
line argument for the 'fel' tool.

We could probably do a better job and store the necessary addresses
in the SPL header. Currently 'mksunxiboot' provides only a
minimalistic header with the eGON.BT0 signature and a checksum,
because otherwise it will refuse to boot from the SD card:

http://git.denx.de/?p=u-boot.git;a=blob;f=tools/mksunxiboot.c

But probably we can extend this header and also add the
CONFIG_SYS_TEXT_BASE value there. Together with kernel_addr_r,
fdt_addr_r, scriptaddr and ramdisk_addr_r values.
After this change, the 'fel' tool will be able to extract all
the necessary information from u-boot-sunxi-with-spl.bin
file without relying on the command line too much.
Moreover, these addresses are sometimes changing, and some
users are IMHO rightfully upset whenever this happens:

I think that adding a new header for this sounds like a good idea, this
header should start with some 8 byte magic marker so that the fel tool
can be 100% sure if it is there.

http://permalink.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/14919

I don't really understand how it works but will leave that to you and Hans.

OK :) Anyway, now I have finally pushed a supposedly properly working
implementation to the following github branch:

https://github.com/ssvb/sunxi-tools/commits/20150206-fel-large-spl-support

Cool (note I've not looked at the actual code yet), this all sounds quite
nice.

It would be really cool if when the new header is present and with a new
enough fel tool + u-boot bin we could do:

fel spl u-boot-sunxi-with-spl.bin zImage - dtb

or:

fel spl u-boot-sunxi-with-spl.bin zImage initrd dtb

And everything would just work, note that the zImage initrd dtb order
is the same as u-boot's bootm command, and the - is there to indicate
there is no initrd.

Maybe we should also do something for old kernels where script.bin needs
to be loaded, maybe:

fel spl-old-kernel ... ??

Yes, we can handle most of this stuff with Hans. But some communication
with you is still needed. In particular, we still need to decide a way
to distinguish between booting from the SD card and over USB. Your
RFC/WIP patch from
http://lists.denx.de/pipermail/u-boot/2015-February/203858.html
was checking the value in the 'lr' register, but this is not going to
work anymore. To address this, right now I'm just replacing the
eGON.BT0 signature in memory to a new eGON.FEL signature at the
address 0x0004. The idea is that this signature is critical for booting
from the SD card. If there is some other value instead, then we are
pretty sure that the SPL was not booted from the SD card. And having it
as eGON.FEL serves as an indication of what exactly it is.

I think that replacing eGON.BT0 with eGON.FEL when loading the SPL
through the new mode is a good way of doing this, ACK to that.

Additionally, we might even not need to store the lr and sp
registers in save_boot_params(). If we settle on using the eGON.FEL
signature in memory for distinguishing between the FEL and the SD boot,
then we can also reuse the other parts of of header (for example,
the checksum) to store the return address.

We'll have to see how this all works out to determine whether or not that
is a good idea.

As you have figured out earlier, avoiding setting VBAR and CP15
stuff is important. Right now the FEL code in the BROM has an
active interrupt handler in use (which I'm suppressing by disabling
interrupts early) and the SPL needs to keep interrupts disabled,
while trying not to mess its configuration.

Ack.

Regards,

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

[U-Boot] [PATCH v2] config_distro_bootcmd.h: Enable CONFIG_CMD_PART

2015-02-07 Thread Hans de Goede

The recent changes to config_distro_bootcmd.h require CONFIG_CMD_PART to be
defined, as the default bootcmd now uses the part command.

This fixes sunxi boards not booting with v2015.04-rc1.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 include/config_distro_bootcmd.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index 49674f4..07a0b3b 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -10,6 +10,10 @@
 #ifndef _CONFIG_CMD_DISTRO_BOOTCMD_H
 #define _CONFIG_CMD_DISTRO_BOOTCMD_H
 
+/* We need the part command */
+#define CONFIG_PARTITION_UUIDS
+#define CONFIG_CMD_PART
+
 #define BOOTENV_SHARED_BLKDEV_BODY(devtypel) \
if  #devtypel  dev ${devnum}; then  \
setenv devtype  #devtypel ;  \
-- 
2.2.2

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

[U-Boot] [PATCH v2] config_distro_bootcmd.h: Enable CONFIG_CMD_PART

2015-02-07 Thread Hans de Goede

Hi Stephen  Tom,

Here is v2 of the patch to fix config_distro_bootcmd usage for sunxi
(and possibly others). As requested I've removed the enabling of
CONFIG_CMD_PART to config_distro_bootcmd.h .

Stephen, can you please review and ack ?

Tom, can you please merge this once acked ?

Regards,

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

Re: [U-Boot] recent tools on FreeBSD

2015-02-07 Thread Jeroen Hofstee


Hi Simon,

On 06-02-15 22:00, Simon Glass wrote:

Hi,

On 6 February 2015 at 13:40, Andreas Bießmann
andreas.de...@googlemail.com wrote:

Hi,

On 06.02.15 20:56, Jeroen Hofstee wrote:

Hello Simon, +Andreas,

On 06-02-15 04:05, Simon Glass wrote:

Hi Jeroen,

On 5 February 2015 at 12:51, Jeroen Hofsteejer...@myspectrum.nl  wrote:

Hello Guilherme,

Thanks for commenting on this,

On 02/05/15 13:27, Guilherme Maciel Ferreira wrote:

Hi Jeroen,

My apologies, I didn't test the tools on BSD. The answers are inline.

Best regards,
Guilherme

Am 04.02.2015 19:37 schrieb Jeroen Hofsteejer...@myspectrum.nl:

Regarding the linking problem, there is nothing special about FreeBSD ld,
it just is based on a version which has no idea what INSERT BEFORE .data
means.

there are several option I guess (not tested):
1) include a complete linker script so INSERT BEFORE .data is not needed
2) teach FreeBSD ld what INSERT BEFORE .data is supposed to mean
3) don't use linker magic in tools (and use a linux box for sandbox, at
least for now)

1) sounds like a bad idea, the target/host might be any arch e.g.
2) won't magically fix problems as well, even if FreeBSD trunk can be
teached to understand
this, things will still be broken on releases. And u-boot tools work on
more host systems,
Andreas, can you check if Darwin is still able to compile tools from
u-boot master?

unfortunately it does not.

---8---
andreas@imac % git describe
v2015.04-rc1-4-g7f641d5
andreas@imac %
PATH=/Volumes/crosstool-ng/arm-unknown-linux-uclibcgnueabi/bin:$PATH
make CROSS_COMPILE=arm-unknown-linux-uclibcgnueabi- V=1
...
gcc  -T ./tools/imagetool.lds -o tools/envcrc tools/envcrc.o
tools/lib/crc32.o tools/common/env_embedded.o tools/lib/sha1.o
ld: unknown option: -T
collect2: error: ld returned 1 exit status
make[1]: *** [tools/envcrc] Error 1
make: *** [tools] Error 2
andreas@imac % gcc --version
gcc (MacPorts gcc49 4.9.2_1) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
---8---


3) the option I would be tempted to choose, just don't do linker magic
for tools. This would
make sure at least mkimage etc can be build everywhere. sandbox won't
build, but as said
it is already broken because of other issues. (and I doubt there is even
an single user around
besides me to even try to build sandbox on FreeBSD).

So as far as I am concerned we go for option 3.

+1

Dynamic list-sections is in general a good thing. But beside the linker
problem here we will get another problem on darwin hosts when we want to
read the sections. I added a patch to linux kernel to get around [1].

So I have another option here:

4) setup the lists sections in code, add the magic handling for Mach-O
binaries and remove the linker foo.

The lower-common-denominator approach is a bit frustrating. How does
FreeBSD compile U-Boot?


I guess I am missing the point here. U-boot v2015.01 builds fine
on FreeBSD and as far as I know on a mac as well. It is v2015.04-rc1
which no longer builds mkimage on FreeBSD and Darwin.


What are you actually using that system for if
it cannot build U-Boot?


I am missing the point, u-boot and its tools build fine until v2015.04-rc1
on FreeBSD and a mac. And this is easily fixed by not using linker magic
for tools. (and yes sandbox likely fails to build, but I don't care that 
much)

Re 1) I found an open in ld to produce the standard link script. I
actually used that before I found INSERT BEFORE.

Before giving up I think it would be worth exploring 1). It should
then be possible to make sandbox work also.


I am not giving up, I think it is sane if a tool which adds a header and
a checksum does not use linker magic.  Sandbox biggest problem is
not the linking, but the fact that linux headers and std* are included,
it is a different topic.


Finally, please point me to how I can install FreeBSD in viritualbox
or similar. I'm interested in that...


Just download an install image and start it in virtualbox, see 1.
You might need to change the motherboard type.

doc/README.clang explains how to use the host compiler to cross build
u-boot (for some boards). You can install a gcc cross compiler as well.

[1] https://www.freebsd.org/releases/10.1R/announce.html

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

Re: [U-Boot] [u-boot 00/40] dra7xx: am43xx: add dwc3 gadget driver support and enable dfu

2015-02-07 Thread Marek Vasut

On Friday, February 06, 2015 at 09:47:37 AM, Kishon Vijay Abraham I wrote:
 This patch series ports dwc3 gadget driver from linux kernel (3.19-rc1)
 to u-boot.
 
 Changes from RFC:
 *) A patch has been added to copy the driver from linux kernel to u-boot
 and then it's modfied to make it work in u-boot. This will help to
 understand the changes that's been done to make it work in u-boot and will
 also be easier to review. *) Implemented chained TRB support in dwc3 ep0
 so that we need not increase the size of bounce buffer
 
 Testing:
 *) tested DFU RAM and DFU MMC in dra7xx and am43xx
 
 TODO:
 *) Add Kconfig support
 *) Adapt dwc3 driver to use the driver model.
 *) Make composite driver similar to the one in linux kernel.
 
 Pushed these patches to
 git://git.ti.com/~kishon/ti-u-boot/kishons-ti-u-boot.git dwc3_upstream_v1

Hi!

I'm fine with this series, maybe just replace folder with directory in
the commit messages ;-) But I can do that myself if you don't mind, no need
to repost.

I'd like to hear what Lukasz thinks and then I'll likely just pick it up for
this MW.

Thanks!

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCHv1 13/22] arm: socfpga: spl: Add s_init

2015-02-07 Thread Marek Vasut

On Thursday, February 05, 2015 at 10:16:59 PM, Dinh Nguyen wrote:
 On 01/14/2015 05:54 PM, Marek Vasut wrote:

[...]

  +  /*
  +   * Private components security
  +   * U-Boot : configure private timer, global timer and cpu
  +   * component access as non secure for kernel stage (as required
  +   * by kernel)
  +   */
  +  setbits_le32(SOCFPGA_SCU_SNSAC, 0xfff);
  
  We do this in socfpga/misc.c in arch_early_init_r() already. You should
  consolidate this code so we don't have it twice I think.
 
 Yes, this can be removed.

Hi! Please use whichever place you think is better.

  +
  +#endif/* CONFIG_SPL_BUILD */
  +
  +  /* Configure the L2 controller to make SDRAM start at 0 */
  +  writel(0x1, (SOCFPGA_MPUL2_ADDRESS + SOCFPGA_MPUL2_ADRFLTR_START));
  
  This as well.
 
 This call has to stay because we want to map the SDRAM to 0x0 in the
 SPL. The call in arch_early_init_r() is in u-boot, and thus is too late.

Roger, but please remove the other invocation once the SPL is in place. OK?

[...]

  +/*
  + * SCU Non-secure Access Control
  + */
  +#define SOCFPGA_SCU_SNSAC (SOCFPGA_MPUSCU_ADDRESS + 0x54)
  +/*
  + * L2 PL-310
  + * for configuring L2 address filtering start address in assembly.
  + */
  +#define SOCFPGA_MPUL2_ADRFLTR_START   (0xC00)
  
  I think this is not needed if you use the code from misc.c , since these
  registers are already defined there.
 
 Yes, I can remove this and use the mappings already defined.

Please do :)

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

Re: [U-Boot] [u-boot 03/40] usb: gadget: udc: add udc-core from linux kernel to u-boot

2015-02-07 Thread Marek Vasut

On Friday, February 06, 2015 at 09:47:40 AM, Kishon Vijay Abraham I wrote:
 Added udc-core.c from linux kernel 3.19-rc1 (97bf6af1f9) to u-boot.
 This will be adapted to work with u-boot in the
 following patches.
 Adding support for udc will help to seamlessly port dwc3 driver from
 linux kernel to u-boot (since dwc3 uses udc-core) and it'll also help
 to add support for multiple gadget controllers to be functional at the
 same time.
 All other gadget drivers can also be adapted to use udc-core.
 
 Signed-off-by: Kishon Vijay Abraham I kis...@ti.com

Lukasz, do you have any comments on this ? I'd like to pick this whole
thing via u-boot-usb for this MW if possible.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

80 matches

Mail list logo