Re: [U-Boot] Pull request u-boot-marvell.git
Hi Prafulla, Le 06/05/2011 22:43, Prafulla Wadaskar a écrit : -Original Message- From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net] Sent: Saturday, May 07, 2011 1:30 AM To: Prafulla Wadaskar Cc: Wolfgang Denk; 'u-boot@lists.denx.de'; Ashish Karkare; Prabhanjan Sarnaik Subject: Re: Pull request u-boot-marvell.git Hi Prafulla, Please do not use my former address; use my current From: one. Le 06/05/2011 15:25, Prafulla Wadaskar a écrit : Hi Albert Please kindly pull The following changes since commit 2fa8ca98c37d5b1bb0328b19ddb7e9d162cd9683: Grant Likely (1): Add CONFIG_OF_LIBFDT to more boards. are available in the git repository at: u-boot-marvell.git master branch. Clint Adams (4): Rename openrd_base files to openrd Add definitions for OpenRD-Client and OpenRD-Ultimate Initialize second PHY on OpenRD-Client and OpenRD-Ultimate Enable multiple fs options for Marvell SoC family on OpenRD boards Simon Guinot (2): Kirkwood: allow to override CONFIG_SYS_TCLK mv-common.h: fix DRAM banks configuration Seems like you've got more than these 6 patches on your master branch above mine. On my side I see Yes, you are correct Even I have mentioned this in my mail. Sorry, I'd missed this as I directly went to check the list of commits. Clint Adams (4): Rename openrd_base files to openrd Add definitions for OpenRD-Client and OpenRD-Ultimate Initialize second PHY on OpenRD-Client and OpenRD-Ultimate Enable multiple fs options for Marvell SoC family on OpenRD boards Jason Liu (2): mx53loco: set mmc env to MMC slot1 MX5: Enable flat-device-tree support on mx53 loco board Liu Hui-R64343 (1): MX53: support for freescale MX53LOCO board Minkyu Kang (1): Don't grab memory for LCD if FB address is defined Simon Guinot (2): Kirkwood: allow to override CONFIG_SYS_TCLK mv-common.h: fix DRAM banks configuration Some of which, IIRC, are not to be applied yet (the MX53LOCO ones, for instance) and some which are already (the don't grab LCD... one). Can you double-check your tree? I have rebased with u-boot-arm.git master and those are available there. What should I do now to resolve this? BTW: This is first time I am facing this problem. What is root cause of it? I has the same issue, caused by some patches in IMX that were initially accepted then rejected, only after I had pulled the IMX tree. I had to do an interactive rebase to select which patches I needed. Here is what you should do: 1) checkout your current master branch (with the spurious commits) 2) do a 'git rebase -i u-boot-arm/master'. The -i will cause the list of commits to be presented to you in an editor, and you will be able to remove those which you do not want. You'll need to re-push the master (and possibly next, if you need to rebase and export it too) with the -f option. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ti/master
Hi Sandeep, Le 29/04/2011 22:39, s-paul...@ti.com a écrit : The following changes since commit e2b1fb98dab08f18e456fd8d846440fe81567785: Sandeep Paulraj (1): Merge branch 'master' of git://git.denx.de/u-boot-arm are available in the git repository at: git://git.denx.de/u-boot-ti.git master Ben Gardiner (1): da850evm: fix NAND WSTROBE and TA timings board/davinci/da8xxevm/da850evm.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Actually commit e2b1fb98dab08f18e456fd8d846440fe81567785 is a merge commit of the u-boot-arm/master branch into yours, whereas the pull request should have been based on the u-boot-arm/master branch itself, commit 2fa8ca98c37d5b1bb0328b19ddb7e9d162cd9683 (seems you have done a merge of u-boot-arm/master into u-boot-ti rather than a rebase of u-boot-ti onto u-boot-arm). However, seeing as there is only one commit in the request, I'll simply cherry-pick it on top of my master and consider it as: Applied, thanks. Prafulla : take note that u-boot-arm/master has moved; if you have not already prepared your pull request, please rebase it, sorry for the inconvenience. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: auto-generate ARM mach-types.h file from ARM machine database
Hi Wolfgang, Le 06/05/2011 12:14, Wolfgang Denk a écrit : Dear Michael Schwingen, In message20110505214836.ga5...@discworld.dascon.de you wrote: to conclude the discussion in the thread Re: [U-Boot] Update and Cut down mach types, I tried a short patch that demonstrates how to automatically generate the mach-types.h file from a database dump (from http://www.arm.linux.org.uk/developer/machines/?action=new). This has multiple advantages: - pulling in new machine types is easier (drop in a new downloaded database dump), and produces a much smaller diff. - adding new machines is decoupled from the time they appear in Linux. - boards that are not in mainline Linux will not be break due to removal of their mach types from the Linux headers. The AWK and Makefile fragment script is taken verbatim from Linux 2.6.38.3. I think the AWK script is simple enough that it will not require big maintenance efforts (unless the machine database format changes). The patch is edited down - I removed the diff for the deletion of the old mach-types.h file, and shortened the new mach-types file to a few entries just to show the concept - otherwise, the patch would be much too big for the list. Is this an acceptable solution? Should I go on and produce a full-fledged patch? I agree with the comments alreay made by Mike Frysinger. In addition, I would like to point out that I consider it mandatory thatthe normal build process does NOT involve any network download. Instead, it must be run completely based on files checked into the git repository only. That means, that the update-mach-types target Mike mentions is something that the ARM maintainer can use to update the in-tree copy of the mach-types.h file, which then gets commited into the git repository. Also users can run this if they want to use the latest version, but it MUST NOT be used for a regular build. Agreed on all points. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: auto-generate ARM mach-types.h file from ARM machine database
Am 05/06/2011 07:09 AM, schrieb Mike Frysinger:
On Thu, May 5, 2011 at 17:48, Michael Schwingen wrote:
--- a/Makefile
+++ b/Makefile
@@ -469,7 +469,7 @@ $(obj)System.map: $(obj)u-boot
# This target actually generates 2 files; autoconf.mk and autoconf.mk.dep.
# the dep file is only include in this top level makefile to determine when
# to regenerate the autoconf.mk file.
-$(obj)include/autoconf.mk.dep: $(obj)include/config.h include/common.h
+$(obj)include/autoconf.mk.dep: $(obj)include/config.h include/common.h
$(obj)include/asm/mach-types.h
@$(XECHO) Generating $@ ; \
set -e ; \
: Generate the dependancies ; \
@@ -530,13 +530,18 @@ unconfig:
$(obj)board/*/config.tmp $(obj)board/*/*/config.tmp \
$(obj)include/autoconf.mk $(obj)include/autoconf.mk.dep
-%_config:: unconfig
+%_config:: unconfig $(obj)include/asm/mach-types.h
@$(MKCONFIG) -A $(@:_config=)
sinclude $(obj).boards.depend
$(obj).boards.depend: boards.cfg
awk '(NF $$1 !~ /^#/) { print $$1 : $$1 _config; $$(MAKE) }'
$ $@
+
+$(obj)include/asm/mach-types.h: arch/arm/tools/gen-mach-types
arch/arm/tools/mach-types
+ @mkdir -p $(obj)include/asm
+ awk -f $^ $@ || { rm -f $@; /bin/false; }
+
#
# Functions to generate common board directory names
#
this all belongs in arch/arm/config.mk and not the toplevel makefile
Fine with me, however, I am hitting a big problem with the Makefile
structure:
mach-types.h needs to be built before autoconf.mk can be generated, and
the rules for autoconf.mk are in the top-level Makefile.
If I put rules in arch/arm/config.mk, then the first of these rules
becomes the default rule which is executed in subdir makes (like make
-C arch), which breaks compilation completely, since config.mk is
included before the rules are defined in the subdir Makefiles.
It seems the current scheme allows only variable definitions in
config.mk files, which is not sufficient here.
rules.mk would be fine, however, there is no provision to include rules
from lower directories, since all the building in subdirectories is
handled by recursively calling make (this is one of the problems that
arise by recursively calling make for each directory, but that is a
different topic).
Any ideas? Using the current Makefile structure, I see no other solution
than defining the mach-types.h generation rules in the toplevel Makefile.
also, dont hardcode full paths to things. there's no reason for it.
Which of these can be omitted?
When putting the rules in arch/arm/config.mk, I can make them trigger
only when compiling for ARM, and I can use $(ARCH) instead of arm/, but
apart from that, I think I need to specify the paths, no?
might want to add an update-mach-types target so people can type
`make update-mach-types` and it'll automatically wget the right file
to the right place ...
Good idea.
I agree with Wolfgang that this is intended to be used by the maintainer
mainly, so the mach-types file should be included in the source so that
a normal user does not need to download the file.
cu
Michael
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot on x86 reloaded
Hi Rodulf, On 04/05/11 22:37, Rudolf Marek wrote: Hello all, [snip] - The build warnings and errors you incurred are probably fixed in mainline (x86 is a bit of a forgotten cousin which gets broken when global patches are made to Makefile, linker scripts etc). If you still have problems compiling the latest U-Boot git head, please post them to the mailing list and I'll sort them out ASAP The links to the coreboot mailing list contain some patches. Ok - I see two fixes needed (one in bios_setup.c and one in realmode.c). These are both effectively in my realmode re-write, but if you can send through a patch to fix them in the meantime, that would be great - When launching U-Boot as a payload from Coreboot, you really don't need to worry about what is at the end of the image (reset vector and jump to protected mode). All the fun begins at the first byte of u-boot.bin which is the first line of code in start.S I think it jumps to _start which is 32 bit entry point. The coreboot is in flat mode 32bit. If you look at start.S, you will see a tiny bit of code before _start which is the 'warm boot' entry point: cli cld /* Turn of cache (this might require a 486-class CPU) */ movl%cr0, %eax orl $(X86_CR0_NW | X86_CR0_CD), %eax movl%eax, %cr0 wbinvd /* Tell 32-bit code it is being entered from an in-RAM copy */ movw$GD_FLG_WARM_BOOT, %bx Looking at coreboot in src/arch/x86/lib/c_start.S it appears coreboot and U-Boot use the same GDT for code (0x10) and data (0x18) in a flat protected mode configuration. We can probably make that a little more robust by jumping over the segment register loads during warm-boot and just use whatever coreboot gives us. U-Boot will wipe it all clean later anyway (see arch/x86/cpu/x86_cpu_init_r) - x86_cpu_init_r calls reload_gdt() after U-Boot has been relocated. So if you build u-boot.bin with TEXT_BASE set wherever it will end up in the coreboot image then you can just have coreboot jump to TEXT_BASE. Now as for booting an ELF image, maybe the linker script needs to be tweaked to set the entry point to _x86boot_start rather than _start - CONFIG_SYS_INIT_SP_ADDR is a temporary stack pointer which is used during the relocation of U-Boot from ROM (Flash) into SDRAM. Typically the CPU's Cache-As-RAM (CAR) capability is used. However, if SDRAM is already initialised, you can set CONFIG_SYS_INIT_SP_ADDR to anywhere in SDRAM that will not get clobbered by the relocation Yes I set it to 256KB boundary. Sounds reasonable - but you really need to set it to somewhere you know there is physical RAM. Maybe this could be passed in a register in the warm boot scenario and the address determined by coreboot [big snip - we'll deal with real-mode / BIOS later] I would really like to see some U-Boot patches on the mailing list - Technically U-Boot is meant to be a stand-alone and self-sufficient, but I think for x86 there is merit in creating board configuration that gets boot-strapped by Coreboot (we just need to make sure the documentation is up-to-scratch) The patches are just now on coreboot mailing list. It is just a hack, because there are places which needs to be fixed, the computation of place for the realmode and bios sections needs to be fixed. I added the coreboot as a board and subarchitecture. I've had a chance to look at them, and the impact on U-Boot is surprisingly minimal. A few comments: -PLATFORM_CPPFLAGS += -DCONFIG_X86 -D__I386__ -march=i386 -Werror +PLATFORM_CPPFLAGS += -DCONFIG_X86 -D__I386__ -march=i386 NACK - Do not remove -Werror -LDPPFLAGS += -DRESET_SEG_START=0x +LDPPFLAGS += -DRESET_SEG_START=0xFF NACK - As mentioned above, I see no reason to mess with this. Set TEXT_BASE to be the location of U-Boot in the coreboot flash image and simply jump to it. In /arch/x86/cpu/interrupts.c you add setup_i8259() and call it in cpu_init_interrupts() which is called from cpu_init_r() - This is the wrong place to be setting up the PIC (this file initialises the CPU interrupt sub-system, not the external glue logic). And how is setup_i8259() different from interrupt_init() found in arch/x86/lib/pcat_interrupt.c? Now the problem could be that interrupt_init() is called after cpu_init_r() - i.e. the CPU interrupt sub-system is setup before the PIC has been configured. Maybe the PIC should be configured prior to relocation (and therefore prior to initialisation of the CPU interrupt sub-system). Lets look at moving that to board_early_init_f() Apart from that, the patches look 'promising' ;) Now, for me to officially consider them, they need to be posted to the U-Boot mailing list using git format-patch / git send-email AFTER they have been run through checkpatch (which can be found in the Linux source under scripts/). You patches will end up in patchwork where they will be managed What is specific is that we will need
[U-Boot] [PATCH v6 0/2] Add support for LaCie NAS Network Space v2
This patch series adds support for Network Space v2 board and parents.
Changes for v2:
- netconsole: restore NetOurIP check
- add entries to MAINTAINERS file
- move boards from root Makefile to boards.cfg
- move MACH_TYPE definition into netspace_v2.h
- remove CONFIG_SYS_HZ redefinition
- turn PHY initialization message into debug()
Changes for v3:
- drop patch for Macronix MX25L4005A
- rewrite patch sf: disable write protection for Macronix flash,
using the common spi flash code
- fix Definitions typo in mv-common.h
- netconsole: add a /* Fall through */ comment before the NETCONS
case label
Changes for v4:
- sf macronix: use spi_flash_cmd_write_enable()
- enhance commit message for patch Add support for Network Space v2
Changes for v5:
- add a changelog per patch
Changes for v6:
- drop accepted patches
- enable device tree support for netspace_v2
- clean some #define in netspace_v2.h
- enhance commit message for patch Add support for Network Space v2:
provide description URL and mention SoC family
- rebase patch Add support for Network Space v2 against
u-boot-{arm,marvell}/master branches
- enhance commit message for patch netconsole: remove `serverip'
check
Simon Guinot (2):
netconsole: remove `serverip' check
Add support for Network Space v2
MAINTAINERS |6 +
board/LaCie/netspace_v2/Makefile | 49 ++
board/LaCie/netspace_v2/kwbimage.cfg | 162 +
board/LaCie/netspace_v2/netspace_v2.c | 144 +
board/LaCie/netspace_v2/netspace_v2.h | 39
boards.cfg|3 +
include/configs/netspace_v2.h | 153 +++
net/net.c |3 +-
8 files changed, 558 insertions(+), 1 deletions(-)
create mode 100644 board/LaCie/netspace_v2/Makefile
create mode 100644 board/LaCie/netspace_v2/kwbimage.cfg
create mode 100644 board/LaCie/netspace_v2/netspace_v2.c
create mode 100644 board/LaCie/netspace_v2/netspace_v2.h
create mode 100644 include/configs/netspace_v2.h
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 1/2] netconsole: remove `serverip' check
This patch allows to enable the netconsole even if `serverip' is not set.
Because netconsole use the environment variable `ncip' to configure the
destination IP, `serverip' don't need to be defined.
Signed-off-by: Simon Guinot sgui...@lacie.com
---
Changes for v2:
- restore NetOurIP check
Changes for v3:
- add a /* Fall through */ comment before the NETCONS case label
Changes for v4,5: none
Changes for v6:
- enhance commit message
net/net.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/net.c b/net/net.c
index e50bdf1..19ac019 100644
--- a/net/net.c
+++ b/net/net.c
@@ -1718,7 +1718,6 @@ static int net_check_prereq (proto_t protocol)
#if defined(CONFIG_CMD_NFS)
case NFS:
#endif
- case NETCONS:
case TFTP:
if (NetServerIP == 0) {
puts (*** ERROR: `serverip' not set\n);
@@ -1728,7 +1727,9 @@ static int net_check_prereq (proto_t protocol)
defined(CONFIG_CMD_DNS)
common:
#endif
+ /* Fall through */
+ case NETCONS:
if (NetOurIP == 0) {
puts (*** ERROR: `ipaddr' not set\n);
return (1);
--
1.6.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 2/2] Add support for Network Space v2
This patch add support for the Network Space v2 board and parents, based
on the Marvell Kirkwood 6281 SoC. This include Network Space (Max) v2
and Internet Space v2.
Additional information is available at:
http://lacie-nas.org/doku.php?id=network_space_v2
Signed-off-by: Simon Guinot sgui...@lacie.com
---
Changes for v2:
- add entries to MAINTAINERS file
- move boards from root Makefile to boards.cfg
- move MACH_TYPE definition into netspace_v2.h
- remove CONFIG_SYS_HZ redefinition
- turn PHY initialization message into debug()
Changes for v3: none
Changes for v4:
- enhance commit message: add SoC information
Changes for v5: none
Changes for v6:
- enable device tree support
- clean some #define in netspace_v2.h
- enhance commit message: provide description URL and mention SoC
family
- rebase against u-boot-{arm,marvell}/master branches
MAINTAINERS |6 +
board/LaCie/netspace_v2/Makefile | 49 ++
board/LaCie/netspace_v2/kwbimage.cfg | 162 +
board/LaCie/netspace_v2/netspace_v2.c | 144 +
board/LaCie/netspace_v2/netspace_v2.h | 39
boards.cfg|3 +
include/configs/netspace_v2.h | 153 +++
7 files changed, 556 insertions(+), 0 deletions(-)
create mode 100644 board/LaCie/netspace_v2/Makefile
create mode 100644 board/LaCie/netspace_v2/kwbimage.cfg
create mode 100644 board/LaCie/netspace_v2/netspace_v2.c
create mode 100644 board/LaCie/netspace_v2/netspace_v2.h
create mode 100644 include/configs/netspace_v2.h
diff --git a/MAINTAINERS b/MAINTAINERS
index fc793f5..9d6c458 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -646,6 +646,12 @@ Sedji Gaouaousedji.gaou...@atmel.com
at91sam9g10ek ARM926EJS (AT91SAM9G10 SoC)
at91sam9m10g45ekARM926EJS (AT91SAM9G45 SoC)
+Simon Guinot simon.gui...@sequanux.org
+
+ inetspace_v2ARM926EJS (Kirkwood SoC)
+ netspace_v2 ARM926EJS (Kirkwood SoC)
+ netspace_max_v2 ARM926EJS (Kirkwood SoC)
+
Marius Gröger m...@sysgo.de
impa7 ARM720T (EP7211)
diff --git a/board/LaCie/netspace_v2/Makefile b/board/LaCie/netspace_v2/Makefile
new file mode 100644
index 000..a245f2c
--- /dev/null
+++ b/board/LaCie/netspace_v2/Makefile
@@ -0,0 +1,49 @@
+#
+# Copyright (C) 2011 Simon Guinot sgui...@lacie.com
+#
+# Based on Kirkwood support:
+# (C) Copyright 2009
+# Marvell Semiconductor www.marvell.com
+# Written-by: Prafulla Wadaskar prafu...@marvell.com
+#
+# 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 Foundation; 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.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).o
+
+COBJS := netspace_v2.o
+
+SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS := $(addprefix $(obj),$(COBJS))
+SOBJS := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+ $(call cmd_link_o_target, $(OBJS) $(SOBJS))
+
+clean:
+ rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+ rm -f $(LIB) core *.bak .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/LaCie/netspace_v2/kwbimage.cfg
b/board/LaCie/netspace_v2/kwbimage.cfg
new file mode 100644
index 000..361feeb
--- /dev/null
+++ b/board/LaCie/netspace_v2/kwbimage.cfg
@@ -0,0 +1,162 @@
+#
+# Copyright (C) 2011 Simon Guinot sgui...@lacie.com
+#
+# Based on Kirkwood support:
+# (C) Copyright 2009
+# Marvell Semiconductor www.marvell.com
+# Written-by: Prafulla Wadaskar prafu...@marvell.com
+#
+# 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 Foundation; 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.
+#
+# Refer docs/README.kwimage for more details about how-to configure
+# and create kirkwood boot image
+#
+
+# Boot Media configurations
+BOOT_FROM
Re: [U-Boot] [coreboot] u-boot on x86 reloaded
On Wed, May 04, 2011 at 09:35:46PM +1000, Graeme Russ wrote: - I'm in the middle of re-writing the entire real-mode switch code and real-mode support in U-Boot. The new code allows you to write real-mode code in C - I even have the Linux real-mode printf ported :) This will make writing your own 'BIOS' code for your board a lot easier FYI - SeaBIOS ( http://seabios.org/ ) uses gcc for real-mode code. Indeed, the name SeaBIOS is a play on words - it's a BIOS written in C code. -Kevin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] examples: add smc911x_eeprom to clean target
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 3b5e137..6f17e3b 100644
--- a/Makefile
+++ b/Makefile
@@ -1124,7 +1124,7 @@ clean:
$(obj)examples/standalone/interrupt\
$(obj)examples/standalone/mem_to_mem_idma2intr \
$(obj)examples/standalone/sched\
- $(obj)examples/standalone/smc9_eeprom \
+ $(obj)examples/standalone/smc911{11,x}_eeprom \
$(obj)examples/standalone/test_burst \
$(obj)examples/standalone/timer
@rm -f $(obj)examples/api/demo{,.bin}
--
1.7.5.rc3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
