Re: [U-Boot] [PATCH v2 1/3] USB: make usb_kbd obey USB DMA alignment requirements
Dear Allen Martin,
On Tue, Oct 23, 2012 at 03:03:34PM -0700, Marek Vasut wrote:
Dear Allen Martin,
On Tue, Oct 23, 2012 at 09:51:06AM -0700, Stephen Warren wrote:
On 10/22/2012 11:47 PM, Allen Martin wrote:
Change usb_kbd driver to obey alignment requirements for USB DMA on
the buffer used for data transfer. This is necessary for
architectures that enable dcache and enable USB DMA.
The series,
Tested-by: Stephen Warren swar...@nvidia.com
BTW, I tested tegra-kbc too, and that does indeed currently work (at
least in my local dev branch based on u-boot/master).
Yes, I also tried on a seaboard with internal keyboard and it works,
although once the USB keyboard driver loads the internal keyboard
stops working. I haven't tracked down why, but it seems like a bug I
can live with for now as seaboards with internal keyboards are pretty
rare these days, and how many keyboards do you need in u-boot anyway?
Good thing you pointed it out. Please let's not ignore a bug. How come it
happens? What happens if you have two usb keyboards connected?
I'm pretty sure the USB keyboard driver doesn't support multiple
devices, I see this in drv_usb_kbd_init():
/* We found a keyboard, check if it is already
registered. */
USB_KBD_PRINTF(USB KBD: found set up device.\n);
old_dev = stdio_get_by_name(DEVNAME);
if (old_dev) {
/* Already registered, just return ok. */
USB_KBD_PRINTF(USB KBD: is already
registered.\n);
return 1;
}
The bug is almost certainly inside the tegra kbd driver, which is why
I'm not terribly concerned about it. The only boards that use that
driver are inside NVIDIA, and even those are rare.
[...]
Good, now please fix the bug. I'm terribly unhappy seeing there is a bug that
is
about to go unfixed.
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/lcd: fix eldk 4.2 compile warning
Dear Marek Vasut, On 24.10.2012 00:09, Marek Vasut wrote: Dear Andreas Bießmann, [..] yes, I am. This patch is runtime tested on an at91sam9263ek. I first tried to consolidate the cmap and just use the ushort as in the else path. But unfortunately this require some more rework of this driver. Can you do such rework? You're the atmel guy afterall. I can do such rework, although I have currently not much time to work on that issue. Until 2013.01 release in January this should be doable but not in the next few days until MW closes. Why is the atmel LCD driver so separate anyway? Sorry, I don't know. This should really be reworked some time. But I think for now this quick fix can be applied to silence your eldk-4.2 warning. I don't like hiding problems, can we aim for a proper solution please? You are right, we should do so. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MX5: fix warning in clock.c
Patch fix warnings compiling with ELDK-4.2:
clock.c: In function 'get_standard_pll_sel_clk':
clock.c:341: warning: 'freq' may be used uninitialized in this function
Reported-by : Marek Vasut ma...@denx.de
Signed-off-by: Stefano Babic sba...@denx.de
---
arch/arm/cpu/armv7/mx5/clock.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/mx5/clock.c b/arch/arm/cpu/armv7/mx5/clock.c
index 2709860..1c9223f 100644
--- a/arch/arm/cpu/armv7/mx5/clock.c
+++ b/arch/arm/cpu/armv7/mx5/clock.c
@@ -338,7 +338,7 @@ static u32 get_ipg_per_clk(void)
/* Get the output clock rate of a standard PLL MUX for peripherals. */
static u32 get_standard_pll_sel_clk(u32 clk_sel)
{
- u32 freq;
+ u32 freq = 0;
switch (clk_sel 0x3) {
case 0:
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v3 13/13] omap3_beagle: use new MUSB intstead of the old one
Dear Marek, On Tue, Oct 23, 2012 at 11:20 AM, Marek Vasut ma...@denx.de wrote: Signed-off-by: Ilya Yanok ya...@cogentembedded.com Signed-off-by: Ilya Yanok ilya.ya...@cogentembedded.com Double SoB line Yeah, it's a mess with SoBs, I'm sorry. I think it's not only this patch but others too... Regards, Ilya. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v3 0/13] Port of MUSB driver from Linux (changes from Linux)
Hi Tom,
On Tue, Oct 23, 2012 at 1:45 AM, Tom Rini tr...@ti.com wrote:
This is not a replacement for existing MUSB driver (at least for
now), cause there are still consumers of USB serial gadget which
uses old API and there is no support for serial with new API
for now.
I'm a little lost. In the kernel, you can't use CONFIG_USB_G_SERIAL
with CONFIG_USB_MUSB_${hw glue} ?
You can. But we don't have g_serial in U-Boot yet.
In general, things look OK but please run it through checkpatch.pl, use
just one Signed-off-by line and fixup if (...) { ... one line ... } in
the glue code you add that's not synced up from the kernel (I saw one in
the am335x bits). Thanks! And lets move this out of RFC...
Ok.
Regards, Ilya.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Where can I get a copy of ePAPR?
Hello all, I am trying to obtain a copy of ePAPR in order to have a canonical reference for my FDT files. The U-Boot website (and my Embedded Linux Primer and the FDTWiki!) quotes the URL for: http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf But they have a Page Not Found for this address. Has the URL moved? Has it been withdrawn? Is there a source the community can refer to for the FDT/.dts definition? Please help. Tim -- Tim Brown tim.br...@cityc.co.uk | City Computing Limited| T: +44 20 8770 2110| City House, Sutton Park Road | F: +44 20 8770 2130| Sutton, Surrey, SM1 2AE, GB | ---| BEAUTY: What's in your eye when you have a bee in your hand | ---' City Computing Limited registered in London No. 1767817. Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE VAT number 372 8290 34. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Where can I get a copy of ePAPR?
On 24/10/12 10:10, Tim Brown wrote: Hello all, I am trying to obtain a copy of ePAPR in order to have a canonical reference for my FDT files. The U-Boot website (and my Embedded Linux Primer and the FDTWiki!) quotes the URL for: http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf After a search on power.org, they provide a Permalink: https://www.power.org/documentation/embedded-power-architecture-platform-requirements-epapr/ From which the PDF file can be downloaded (after registering for free). Should the U-Boot website be updated to reflect this? http://www.denx.de/wiki/U-Boot/UBootFdtInfo#Background_Information_on_Flatte Tim -- Tim Brown tim.br...@cityc.co.uk | City Computing Limited| T: +44 20 8770 2110| City House, Sutton Park Road | F: +44 20 8770 2130| Sutton, Surrey, SM1 2AE, GB | ---| BEAUTY: What's in your eye when you have a bee in your hand | ---' City Computing Limited registered in London No. 1767817. Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE VAT number 372 8290 34. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] Fix some ELDK 4.2 build issues
A number of boards don't build with older tool chains like ELDK 4.2 (GCC 4.2.2). Some of these have long been EOLed, and there are no known users of these any more, so let's get rid of the dead weight and remove these. For some others, adjust the linker scripts to make the code fit again. Wolfgang Denk (3): PPC: remove dead boards (AMX860, c2mon, ETX094, IAD210, LANTEC, SCM) TQM8xx: adjust linker script to grown code size ESTEEM192E: adjust linker script to grown code size MAINTAINERS |6 - README |4 +- arch/powerpc/cpu/mpc8xx/fec.c|2 +- arch/powerpc/cpu/mpc8xx/scc.c| 16 +- board/c2mon/Makefile | 44 --- board/c2mon/c2mon.c | 236 --- board/c2mon/flash.c | 570 --- board/c2mon/pcmcia.c | 282 -- board/c2mon/u-boot.lds | 106 - board/c2mon/u-boot.lds.debug | 137 --- board/esteem192e/u-boot.lds |1 - board/etx094/Makefile| 44 --- board/etx094/etx094.c| 384 -- board/etx094/flash.c | 687 board/etx094/u-boot.lds | 107 - board/lantec/Makefile| 44 --- board/lantec/flash.c | 625 -- board/lantec/lantec.c| 208 -- board/lantec/u-boot.lds | 107 - board/lantec/u-boot.lds.debug| 137 --- board/siemens/IAD210/IAD210.c| 299 -- board/siemens/IAD210/Makefile| 44 --- board/siemens/IAD210/atm.c | 652 --- board/siemens/IAD210/atm.h | 287 -- board/siemens/IAD210/flash.c | 502 board/siemens/IAD210/u-boot.lds | 107 - board/siemens/SCM/Makefile | 49 --- board/siemens/SCM/flash.c| 488 --- board/siemens/SCM/fpga_scm.c | 104 - board/siemens/SCM/scm.c | 541 -- board/siemens/SCM/scm.h | 89 - board/siemens/common/README | 27 -- board/siemens/common/fpga.c | 369 -- board/siemens/common/fpga.h | 53 --- board/tqc/tqm8xx/u-boot.lds |4 +- board/westel/amx860/Makefile | 44 --- board/westel/amx860/amx860.c | 93 - board/westel/amx860/flash.c | 637 -- board/westel/amx860/u-boot.lds | 107 - board/westel/amx860/u-boot.lds.debug | 138 --- boards.cfg |7 - doc/README.scrapyard |8 +- include/commproc.h | 131 +-- include/configs/AMX860.h | 299 -- include/configs/ETX094.h | 357 - include/configs/IAD210.h | 381 -- include/configs/LANTEC.h | 358 - include/configs/SCM.h| 710 -- include/configs/c2mon.h | 417 include/pcmcia.h |2 - include/status_led.h | 36 -- post/cpu/mpc8xx/ether.c | 45 +--- 52 files changed, 18 insertions(+), 4 deletions(-) delete mode 100644 board/c2mon/Makefile delete mode 100644 board/c2mon/c2mon.c delete mode 100644 board/c2mon/flash.c delete mode 100644 board/c2mon/pcmcia.c delete mode 100644 board/c2mon/u-boot.lds delete mode 100644 board/c2mon/u-boot.lds.debug delete mode 100644 board/etx094/Makefile delete mode 100644 board/etx094/etx094.c delete mode 100644 board/etx094/flash.c delete mode 100644 board/etx094/u-boot.lds delete mode 100644 board/lantec/Makefile delete mode 100644 board/lantec/flash.c delete mode 100644 board/lantec/lantec.c delete mode 100644 board/lantec/u-boot.lds delete mode 100644 board/lantec/u-boot.lds.debug delete mode 100644 board/siemens/IAD210/IAD210.c delete mode 100644 board/siemens/IAD210/Makefile delete mode 100644 board/siemens/IAD210/atm.c delete mode 100644 board/siemens/IAD210/atm.h delete mode 100644 board/siemens/IAD210/flash.c delete mode 100644 board/siemens/IAD210/u-boot.lds delete mode 100644 board/siemens/SCM/Makefile delete mode 100644 board/siemens/SCM/flash.c delete mode 100644 board/siemens/SCM/fpga_scm.c delete mode 100644 board/siemens/SCM/scm.c delete mode 100644 board/siemens/SCM/scm.h delete mode 100644 board/siemens/common/README delete mode 100644 board/siemens/common/fpga.c delete mode 100644 board/siemens/common/fpga.h delete mode 100644 board/westel/amx860/Makefile delete mode 100644 board/westel/amx860/amx860.c delete mode 100644 board/westel/amx860/flash.c delete mode 100644 board/westel/amx860/u-boot.lds
[U-Boot] [PATCH 3/3] ESTEEM192E: adjust linker script to grown code size
Once more, some of the previous changes caused the code to grow, which causes errors like u-boot.lds:74 cannot move location counter backwards (from 40008384 to 40008000) when building with some older tool chains (like ELDK 4.2). Adjust the linker script to make fit again. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Conn Clark cl...@esteem.com --- board/esteem192e/u-boot.lds |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/board/esteem192e/u-boot.lds b/board/esteem192e/u-boot.lds index 69f1500..fe5cf09 100644 --- a/board/esteem192e/u-boot.lds +++ b/board/esteem192e/u-boot.lds @@ -36,7 +36,6 @@ SECTIONS arch/powerpc/cpu/mpc8xx/traps.o(.text*) net/libnet.o (.text*) board/esteem192e/libesteem192e.o (.text*) -*(.text.*printf) . = env_offset; common/env_embedded.o (.text*) -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] TQM8xx: adjust linker script to grown code size
Once more, some of the previous changes caused the code to grow, which causes errors like u-boot.lds:80 cannot move location counter backwards (from 400082a4 to 40008000) when building with some older tool chains (like ELDK 4.2). Adjust the linker script to make fit again. Signed-off-by: Wolfgang Denk w...@denx.de --- board/tqc/tqm8xx/u-boot.lds |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/board/tqc/tqm8xx/u-boot.lds b/board/tqc/tqm8xx/u-boot.lds index 7cc41cd..e1e1ccd 100644 --- a/board/tqc/tqm8xx/u-boot.lds +++ b/board/tqc/tqm8xx/u-boot.lds @@ -1,5 +1,5 @@ /* - * (C) Copyright 2000 + * (C) Copyright 2000-2012 * Wolfgang Denk, DENX Software Engineering, w...@denx.de. * * See file CREDITS for list of people who contributed to this @@ -41,8 +41,6 @@ SECTIONS drivers/net/libnet.o (.text*) drivers/pcmcia/libpcmcia.o (.text.pcmcia_on) drivers/pcmcia/libpcmcia.o (.text.pcmcia_hardware_enable) -drivers/rtc/librtc.o (.text*) -drivers/misc/libmisc.o (.text*) . = DEFINED(env_offset) ? env_offset : .; common/env_embedded.o (.ppcenv*) -- 1.7.7.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Merging device trees at runtime for module-based systems
Hi, a project I'm involved in uses a module/baseboard combo, and components on either board are described in DT. I'm currently using separate dts files which build upon each other with include statements, which works fine for development. In production though, we will certainly have running changes (and hence different versions) over the lifetime of the product for both the baseboard and the module, and the hardware has support for identifying the versions of both sides at runtime. So let's say we have n versions of the baseboard and m versions of the module, we would much like to only prepare n + m files, instead of n * m by pre-compiling every possible combination (some of which may actually never occur 'in the wild'). So my question is: is it possible to do that kind of assembly of a number of files at runtime in U-Boot? I guess all it takes is merging a number of trees together, right? I browsed through the APIs but couldn't yet find an clear approach to that kind of problem. If not, what would it take to add that functionality? I can probably help with the implementation if someone tells me what would be the right way. Any pointer greatly appreciated. Thanks, Daniel ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Where can I get a copy of ePAPR?
Dear Tim, In message 5087be77.7060...@cityc.co.uk you wrote: After a search on power.org, they provide a Permalink: https://www.power.org/documentation/embedded-power-architecture-platform-requirements-epapr/ Actualy the current version is here: https://www.power.org/documentation/epapr-version-1-1/ From which the PDF file can be downloaded (after registering for free). Should the U-Boot website be updated to reflect this? http://www.denx.de/wiki/U-Boot/UBootFdtInfo#Background_Information_on_Flatte Done. 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 The only perfect science is hind-sight. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v3 0/13] Port of MUSB driver from Linux (changes from Linux)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/24/12 01:42, Ilya Yanok wrote:
Hi Tom,
On Tue, Oct 23, 2012 at 1:45 AM, Tom Rini tr...@ti.com
mailto:tr...@ti.com wrote:
This is not a replacement for existing MUSB driver (at least for
now), cause there are still consumers of USB serial gadget which
uses old API and there is no support for serial with new API for
now.
I'm a little lost. In the kernel, you can't use
CONFIG_USB_G_SERIAL with CONFIG_USB_MUSB_${hw glue} ?
You can. But we don't have g_serial in U-Boot yet.
So we would need to port that, in order to remove the serial gadget we
have, and drop the previous musb core?
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQh/obAAoJENk4IS6UOR1WCIMQAJgsWQ9TxeklFiavkFZKEXh2
BnKklSOjzuJd3+Wz0WXqBpcRYa2hl3UviG84ZUyjfAcZnFj+zn1xhfDRVmvCzARe
JXOOZuoWJdVDRNUVHzsOpKqzdRIqwkYnOJQuj9HAmnXrnr6sqLDCs1/hM0raNC+5
Ry0S1Fi0kA6DfwTSSPba8aTMqPAFWS5SMiJzrdx7BjNVw8Roq5v/NPJO2A/Jsrfj
rLgI++JzyY+UYilJI58+zyPcjg213/Tnx8eJq+my8nW9w2Z13A9Xa76DCAnBfqPy
ndwe29Lqa8sfz1/MFkl1v4vIYOTtIDnfr4siOkKfIbwBCh6/a0VfDOiYbOi0YdLs
0nPlowC4Z2dYJezEk4kCA1ano8SZucg5QtDwh491SO2vIcZ6HplOgpWDIamu/bxt
79VpDRU/nBKWseB3gESPBhYSt31OA+FH00plsYJFM3PocjuCc4SMvXQP6MWxC2rJ
KzOv/cUGzxDHTA4a+xkq3F315v8Ib7De0XK/cgmGxiba53v/BHaST/qu5TOcABG+
Wp0qpAn0OcEjAXPVJk6cGIcBKj/ahgxbGtly6aDSgxipRQo75rBGmlTfpz0IZ/Ie
Tdz/VJRhX818Ce2suZeqShN/zhWwkzCliXqMi43aUsq3YTOCDbrRMNxiWpnP7VJZ
EJFQQhcuUe732txbvfjW
=RRrb
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-coldfire/master
Hi, Tom, The following changes since commit c4d22de817738e9f1f6a7c34664fc4ac112024a3: km83xx: add kmvect1 board (2012-10-23 15:23:26 -0500) are available in the git repository at: git://git.denx.de/u-boot-coldfire.git master Alison Wang (3): ColdFire: Fix unused variable in cpu_init.c ColdFire: Add MCF5441x CPU support ColdFire: Add Freescale MCF54418TWR ColdFire development board support arch/m68k/cpu/mcf5227x/cpu_init.c |8 +- arch/m68k/cpu/mcf5445x/config.mk | 10 + arch/m68k/cpu/mcf5445x/cpu.c | 17 + arch/m68k/cpu/mcf5445x/cpu_init.c | 313 +++-- arch/m68k/cpu/mcf5445x/speed.c| 80 +++- arch/m68k/cpu/mcf5445x/start.S| 273 ++- arch/m68k/include/asm/cache.h | 11 +- arch/m68k/include/asm/immap.h | 43 ++- arch/m68k/include/asm/immap_5441x.h | 387 ++ arch/m68k/include/asm/m5441x.h| 887 + board/freescale/m54418twr/Makefile| 43 ++ board/freescale/m54418twr/config.mk | 25 + board/freescale/m54418twr/m54418twr.c | 129 + board/freescale/m54418twr/u-boot.lds | 97 boards.cfg|6 + doc/README.m54418twr | 244 + include/configs/M54418TWR.h | 448 + 17 files changed, 2964 insertions(+), 57 deletions(-) create mode 100644 arch/m68k/include/asm/immap_5441x.h create mode 100644 arch/m68k/include/asm/m5441x.h create mode 100644 board/freescale/m54418twr/Makefile create mode 100644 board/freescale/m54418twr/config.mk create mode 100644 board/freescale/m54418twr/m54418twr.c create mode 100644 board/freescale/m54418twr/u-boot.lds create mode 100644 doc/README.m54418twr create mode 100644 include/configs/M54418TWR.h Thanks. Best Regards, Jason ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v3 0/13] Port of MUSB driver from Linux (changes from Linux)
Hi Tom,
On Wed, Oct 24, 2012 at 4:24 PM, Tom Rini tr...@ti.com wrote:
I'm a little lost. In the kernel, you can't use
CONFIG_USB_G_SERIAL with CONFIG_USB_MUSB_${hw glue} ?
You can. But we don't have g_serial in U-Boot yet.
So we would need to port that, in order to remove the serial gadget we
have, and drop the previous musb core?
Yes, we need to port g_serial, but removing the old usbtty driver is
probably too harsh: this will render a bunch of old udc driver (not only
old MUSB code) not useful for anything.
Regards, Ilya.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 0/6] am33xx: support non-ti boards
Peter == Peter Korsgaard peter.korsga...@barco.com writes:
Hi,
Peter The am33xx code currently contains a number of details specific
Peter to the ti(-derived) boards in the common code. This series
Peter restructures the arch code to make it possible to add other
Peter boards.
Peter This series does not yet any new boards, as the board I'm
Peter working on is using nand flash, and omap_gpmc hasn't been
Peter updated for bch8 / elm support yet. I've started looking at it,
Peter but no code so far.
Peter Instead it has been tested on Beaglebone.
Hi Tom,
You mentioned on IRC that you were happy with this series, but it
doesn't seem to be merged yet. Is there anything blocking it? It isn't
particular complicated, but it is bound to cause conflicts with any
other am33xx changes, so it would be good to get it merged.
Peter Changes since v1:
Peter - Rebased against u-boot-ti
Peter - Take Tom Rini's feedback into account
Peter - evm.{c,h} - board.{c,h}
Peter - use DDR part numbers in defines and leave in ddr_defs.h
Peter (without MICRON_ prefix to stay 80 chars)
Peter Peter Korsgaard (6):
Peter am33xx/board.c: make wdtimer/uart_base static
Peter am33xx: move ti i2c baseboard header handling to board/ti/am335x/
Peter am33xx/board: use cpu_mmc_init() for default mmc initialization
Peter am33xx: move generic parts of pinmux handling out from
Peter board/ti/am335x
Peter am33xx: support board specific ddr settings
Peter am33xx/ddr_defs.h: rename DDR2/DDR3 defines to their actual part
Peter numbers
Peter arch/arm/cpu/armv7/am33xx/Makefile |1 +
Peter arch/arm/cpu/armv7/am33xx/board.c | 244
+-
Peter arch/arm/cpu/armv7/am33xx/emif4.c | 114 +
Peter arch/arm/cpu/armv7/am33xx/mux.c| 33 +++
Peter arch/arm/include/asm/arch-am33xx/ddr_defs.h| 69 +++---
Peter arch/arm/include/asm/arch-am33xx/mux.h | 261
Peter arch/arm/include/asm/arch-am33xx/sys_proto.h | 27 --
Peter board/ti/am335x/Makefile |1 +
Peter .../cpu/armv7/am33xx = board/ti/am335x}/board.c | 138 +++
Peter .../sys_proto.h = board/ti/am335x/board.h | 24 +-
Peter board/ti/am335x/mux.c | 250
+--
Peter 11 files changed, 447 insertions(+), 715 deletions(-)
Peter create mode 100644 arch/arm/cpu/armv7/am33xx/mux.c
Peter create mode 100644 arch/arm/include/asm/arch-am33xx/mux.h
Peter copy {arch/arm/cpu/armv7/am33xx = board/ti/am335x}/board.c (64%)
Peter copy arch/arm/include/asm/arch-am33xx/sys_proto.h =
board/ti/am335x/board.h (75%)
Peter --
Peter 1.7.10.4
Peter ___
Peter U-Boot mailing list
Peter U-Boot@lists.denx.de
Peter http://lists.denx.de/mailman/listinfo/u-boot
--
Bye, Peter Korsgaard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/4] am335x_evm: Enable use of UART{1, 2, 3, 4, 5}
On Mon, 22 Oct 2012 15:23:29 -0400
Andrew Bradford and...@bradfordembedded.com wrote:
Add targets of am335x_evm_uart{1,2,3,4,5} to have serial input/output
on UART{1,2,3,4,5} for use with the Beaglebone RS232 cape, am335x_evm
daughterboard, and other custom configurations.
Signed-off-by: Andrew Bradford and...@bradfordembedded.com
Tested-by: Matt Porter mpor...@ti.com
---
Changes from v1:
Add UART3 target and register location
boards.cfg |5 +
include/configs/am335x_evm.h | 33 -
2 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/boards.cfg b/boards.cfg
index df62251..0944690 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -226,6 +226,11 @@ integratorap_cm946es arm
arm946esintegrator armltd integratorcp_cm946es
arm arm946esintegrator armltd
- integratorcp:CM946ES ca9x4_ct_vxp
arm armv7 vexpressarmltd
am335x_evm arm armv7
am335x ti am33xx
+am335x_evm_uart1 arm armv7
am335x ti am33xx
am335x_evm:AM33XX_UART_SELECT=1 +am335x_evm_uart2
arm armv7 am335x ti
am33xx am335x_evm:AM33XX_UART_SELECT=2
+am335x_evm_uart3 arm armv7
am335x ti am33xx
am335x_evm:AM33XX_UART_SELECT=3 +am335x_evm_uart4
arm armv7 am335x ti
am33xx am335x_evm:AM33XX_UART_SELECT=4
+am335x_evm_uart5 arm armv7
am335x ti am33xx
am335x_evm:AM33XX_UART_SELECT=5 highbank
arm armv7 highbank- highbank
mx51_efikamx arm armv7
mx51_efikamxgenesi mx5
mx51_efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKAMX,IMX_CONFIG=board/genesi/mx51_efikamx/imximage_mx.cfg
mx51_efikasb arm armv7
mx51_efikamxgenesi mx5
mx51_efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKASB,IMX_CONFIG=board/genesi/mx51_efikamx/imximage_sb.cfg
diff --git a/include/configs/am335x_evm.h
b/include/configs/am335x_evm.h index 339d4bd..d138e45 100644 ---
a/include/configs/am335x_evm.h +++ b/include/configs/am335x_evm.h @@
-158,9 +158,15 @@ /* NS16550 Configuration */ #define
CONFIG_SYS_NS16550 #define CONFIG_SYS_NS16550_SERIAL +#define
CONFIG_SERIAL_MULTI #define CONFIG_SYS_NS16550_REG_SIZE (-4)
#define CONFIG_SYS_NS16550_CLK(4800) #define
CONFIG_SYS_NS16550_COM1 0x44e09000 /* Base EVM
has UART0 */ +#define CONFIG_SYS_NS16550_COM2
0x48022000/* UART1 */ +#define
CONFIG_SYS_NS16550_COM3 0x48024000 /* UART2 */
+#define CONFIG_SYS_NS16550_COM4 0x481a6000 /*
UART3 */ +#define CONFIG_SYS_NS16550_COM5
0x481a8000/* UART4 */ +#define
CONFIG_SYS_NS16550_COM6 0x481aa000 /* UART5
*/ /* I2C Configuration */ #define CONFIG_I2C @@ -182,11 +188,36 @@
#define CONFIG_SYS_BAUDRATE_TABLE { 110, 300, 600, 1200, 2400,
\ 4800, 9600, 14400, 19200, 28800, 38400, 56000, 57600, 115200 }
+#define CONFIG_ENV_OVERWRITE 1 + /*
- * select serial console configuration
+ * select serial console configuration, uart0 always enabled
*/
#define CONFIG_SERIAL1 1
+#ifndef CONFIG_AM33XX_UART_SELECT
#define CONFIG_CONS_INDEX1
+#endif /* CONFIG_AM33XX_UART_SELECT */
+
+#if CONFIG_AM33XX_UART_SELECT == 1
+#define CONFIG_SERIAL2 1
+#define CONFIG_CONS_INDEX2
+#endif /* CONFIG_AM33XX_UART_SELECT == 1 */
+#if CONFIG_AM33XX_UART_SELECT == 2
+#define CONFIG_SERIAL3 1
+#define CONFIG_CONS_INDEX3
+#endif /* CONFIG_AM33XX_UART_SELECT == 2 */
+#if CONFIG_AM33XX_UART_SELECT == 3
+#define CONFIG_SERIAL4 1
+#define CONFIG_CONS_INDEX4
+#endif /* CONFIG_AM33XX_UART_SELECT == 3 */
+#if CONFIG_AM33XX_UART_SELECT == 4
+#define CONFIG_SERIAL5 1
+#define CONFIG_CONS_INDEX5
+#endif /* CONFIG_AM33XX_UART_SELECT == 4 */
+#if CONFIG_AM33XX_UART_SELECT == 5
+#define CONFIG_SERIAL6 1
+#define CONFIG_CONS_INDEX6
+#endif /* CONFIG_AM33XX_UART_SELECT == 5 */
#define CONFIG_SYS_CONSOLE_INFO_QUIET
#define CONFIG_ENV_IS_NOWHERE
Having all of this in include/configs/am335x_evm.h is rather ugly and
hard to read. I have a v3 cleanup patchset coming shortly to fix this
by just setting SERIALX and CONS_INDEX in the boards.cfg. It's much
easier to read.
Please do not apply this v2 series.
Thanks,
Andrew
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 0/6] am33xx: support non-ti boards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/24/12 08:41, Peter Korsgaard wrote: Peter == Peter Korsgaard peter.korsga...@barco.com writes: Hi, Peter The am33xx code currently contains a number of details specific Peter to the ti(-derived) boards in the common code. This series Peter restructures the arch code to make it possible to add other Peter boards. Peter This series does not yet any new boards, as the board I'm Peter working on is using nand flash, and omap_gpmc hasn't been Peter updated for bch8 / elm support yet. I've started looking at it, Peter but no code so far. Peter Instead it has been tested on Beaglebone. Hi Tom, You mentioned on IRC that you were happy with this series, but it doesn't seem to be merged yet. Is there anything blocking it? It isn't particular complicated, but it is bound to cause conflicts with any other am33xx changes, so it would be good to get it merged. Just trying to give a window between posting and merging. I've been holding at around a week which puts this at tomorrow. - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQiBDgAAoJENk4IS6UOR1W7loQAJMs/ejH8J76sagGI7Lc1ogq ktDu4KkK9hTQCewLBhKn/N3wCwm7E3KgXvLLd1zF31jQTFcMJaHFjZJLO5wXr5Cb xElPaK9xUDSbAUB0eYPf+mfq+VvplW8fA/adMorjAWCMHfJN8ksaBc248rir1uaD L47CqBqBYUnkr7ZuUrjmUkalLt0udWaDb9Vr13sNa+FyZMWU+X5jbGSxBbf811WB flK8VrHQY4eFuDskVUgy6pM+6SX+8hiluF8y6WqfzdN+mtPnAlSMt6PPOZuFhLX8 rplOvBMuobgCjObW+pDsrdJ/yggfgzLF1p6Vy/KRdlv4e+V90jLKfpxsDGpFWRQ4 BZIjLgZl/xv/HjbQY0uyeHV9VGhzgT7ulLFl1wsosSl6GzJNBQDmamLeFFBoTYGg +vvWLD+1uQ2bL5iJ475K6kmtVLS4tWswPviXT9YI7K692QzbD8NKTzyQ8LmpAhyM ct1Wat1Nup2fggO14QA4bah1tf37b0MwjYEZfDXszVxR7OjtBa2b3/QdL8uBsCC5 gNrE5/Dpc+3hla71hkOMh7D/UPu0iYbcS3bQsXeTx8zON/1wixY5L53sAOzyL0kp hkMZh/5ygT1+5SvRB48kUPxxQIIsvybrz3bnRxYzFeDGo6h8HuATMS8XaRhRi9Ui WoIYL6dl3WlCHXT9GhMh =KJ4+ -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/spl: Mark arguments as unused
On 10/23/2012 11:14:34 PM, Vikram Narayanan wrote:
On 10/24/2012 7:22 AM, Scott Wood wrote:
On 10/23/2012 12:15:11 PM, Vikram Narayanan wrote:
On 10/23/2012 9:15 PM, Tom Rini wrote:
On Tue, Oct 23, 2012 at 12:26:53PM +0200, Stefan Roese wrote:
On 10/23/2012 12:05 PM, Vikram Narayanan wrote:
As dummy{1,2} are not used anywhere, mark it with __maybe_unused
Signed-off-by: Vikram Narayananvikram...@gmail.com
Cc: Stefan Roeses...@denx.de
---
common/spl/spl.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/spl/spl.c b/common/spl/spl.c
index 0d829c0..62fd3bd 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -145,7 +145,7 @@ static void spl_ram_load_image(void)
}
#endif
-void board_init_r(gd_t *dummy1, ulong dummy2)
+void board_init_r(__maybe_unused gd_t *dummy1, __maybe_unused
ulong dummy2)
{
u32 boot_device;
debug(spl:board_init_r()\n);
Perhaps even __always_unused instead of __maybe_unused as these
variables are never used?
Also, what does this give us? Fixing a sparse warning?
Not a sparse warning. I noticed this while looking at the code.
If there's no warning, why do we need to ugly up the code with
__maybe_unused?
I'd rather call this a proper way of coding, than calling it ugly.
But perceptions differ.
If you want to push for a change to the official coding style, and
changing the warning options to go with it, go ahead (I'll argue
against it of course), but until and unless you succeed at that, this
isn't the way U-Boot code is written. I don't see a single instance of
__maybe_unused in an argument list, or a single instance of
__always_unused anywhere in U-Boot other than its definition.
Unnecessary clutter is harmful to readability.
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] USB: make usb_kbd obey USB DMA alignment requirements
On Wed, Oct 24, 2012 at 12:31:40AM -0700, Marek Vasut wrote:
Dear Allen Martin,
On Tue, Oct 23, 2012 at 03:03:34PM -0700, Marek Vasut wrote:
Dear Allen Martin,
On Tue, Oct 23, 2012 at 09:51:06AM -0700, Stephen Warren wrote:
On 10/22/2012 11:47 PM, Allen Martin wrote:
Change usb_kbd driver to obey alignment requirements for USB DMA on
the buffer used for data transfer. This is necessary for
architectures that enable dcache and enable USB DMA.
The series,
Tested-by: Stephen Warren swar...@nvidia.com
BTW, I tested tegra-kbc too, and that does indeed currently work (at
least in my local dev branch based on u-boot/master).
Yes, I also tried on a seaboard with internal keyboard and it works,
although once the USB keyboard driver loads the internal keyboard
stops working. I haven't tracked down why, but it seems like a bug I
can live with for now as seaboards with internal keyboards are pretty
rare these days, and how many keyboards do you need in u-boot anyway?
Good thing you pointed it out. Please let's not ignore a bug. How come it
happens? What happens if you have two usb keyboards connected?
I'm pretty sure the USB keyboard driver doesn't support multiple
devices, I see this in drv_usb_kbd_init():
/* We found a keyboard, check if it is already
registered. */
USB_KBD_PRINTF(USB KBD: found set up device.\n);
old_dev = stdio_get_by_name(DEVNAME);
if (old_dev) {
/* Already registered, just return ok. */
USB_KBD_PRINTF(USB KBD: is already
registered.\n);
return 1;
}
The bug is almost certainly inside the tegra kbd driver, which is why
I'm not terribly concerned about it. The only boards that use that
driver are inside NVIDIA, and even those are rare.
[...]
Good, now please fix the bug. I'm terribly unhappy seeing there is a bug that
is
about to go unfixed.
I didn't say the bug will go unfixed, I've opened an issue in our
internal bug tracker so it doesn't go forgotten. It's just a matter
of prioritization. It's just not important to fix a corner case bug
in a driver that noone outside of NVIDIA can actually use when there
are major functionality holes and regressions (like your change to
serial_assign() that broke serial output on tegra). I only work on
u-boot on the side, so I have to pick my battles carefully.
-Allen
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] Standardize on run-time board ID variables
Hey all, I've been thinking about one of the problems we need to solve over in TI AM335x land and that is given that we support a number of different boards with a single binary (and we have an i2c eeprom that tells us what board and revision we are on), the user needs to be able to easily determine what board we are on so they know what dtb file to load so they can boot. To this end I've added CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG to the README which says when set we have board_name and board_rev set at run-time. Then for am335x[1] set that and CONFIG_BOARD_LATE_INIT which will set the variables and add a command, findfdt to compare and set fdtfile correctly. Further distro-specific logic can then augment this to figure out what filesystem / partition to read from. [1]: Yes, this will need re-working after merging Peter K's patches to allow for non-TI boards. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] README: Document CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
This option is intended to be set by boards which will set the board_name and board_rev environment variables. These are to be used when the U-Boot binary can support more than one board type at run-time and the user needs an easy way (for example for scripting to determine what device tree to load) to determine what board they are on. Signed-off-by: Tom Rini tr...@ti.com --- README |6 ++ 1 file changed, 6 insertions(+) diff --git a/README b/README index 69da2b8..430fc16 100644 --- a/README +++ b/README @@ -2309,6 +2309,12 @@ CBFS (Coreboot Filesystem) support - CONFIG_SYS_VENDOR - CONFIG_SYS_SOC + CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG + + Define this in order to add variables describing certain + run-time determined information about the hardware to the + environment. These will be named board_name, board_rev. + - DataFlash Support: CONFIG_HAS_DATAFLASH -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] am335x_evm: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support
We add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG, CONFIG_BOARD_LATE_INIT to
set the variables and then fdtfile and findfdt to make us of this. It
is now possible to do 'run findfdt' to have fdtfile be set to the value
of the dtb file to load for the board we are running on.
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/am33xx/board.c | 20
include/configs/am335x_evm.h | 10 ++
2 files changed, 30 insertions(+)
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 978b184..a138848 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -223,6 +223,26 @@ int board_init(void)
return 0;
}
+#ifdef CONFIG_BOARD_LATE_INIT
+int board_late_init(void)
+{
+#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+ char safe_string[HDR_NAME_LEN + 1];
+
+ /* Now set variables based on the header. */
+ strncpy(safe_string, (char *)header.name, sizeof(header.name));
+ safe_string[sizeof(header.name)] = 0;
+ setenv(board_name, safe_string);
+
+ strncpy(safe_string, (char *)header.version, sizeof(header.version));
+ safe_string[sizeof(header.version)] = 0;
+ setenv(board_rev, safe_string);
+#endif
+
+ return 0;
+}
+#endif
+
#ifdef CONFIG_DRIVER_TI_CPSW
static void cpsw_control(int enabled)
{
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 339d4bd..3adf548 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -29,6 +29,7 @@
#define CONFIG_SYS_LONGHELP/* undef to save memory */
#define CONFIG_SYS_HUSH_PARSER /* use hush command parser */
#define CONFIG_SYS_PROMPT U-Boot#
+#define CONFIG_BOARD_LATE_INIT
#define CONFIG_SYS_NO_FLASH
#define MACH_TYPE_TIAM335EVM 3589/* Until the next sync */
#define CONFIG_MACH_TYPE MACH_TYPE_TIAM335EVM
@@ -46,11 +47,13 @@
/* set to negative value for no autoboot */
#define CONFIG_BOOTDELAY 1
+#define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
#define CONFIG_EXTRA_ENV_SETTINGS \
loadaddr=0x8020\0 \
fdtaddr=0x80F8\0 \
rdaddr=0x8100\0 \
bootfile=/boot/uImage\0 \
+ fdtfile=\0 \
console=ttyO0,115200n8\0 \
optargs=\0 \
mmcdev=0\0 \
@@ -79,6 +82,13 @@
ramboot=echo Booting from ramdisk ...; \
run ramargs; \
bootm ${loadaddr}\0 \
+ findfdt=\
+ if test $board_name = A335BONE; then \
+ setenv fdtfile am335x-bone.dtb; fi; \
+ if test $board_name = A33515BB; then \
+ setenv fdtfile am335x-evm.dtb; fi; \
+ if test $board_name = A335X_SK; then \
+ setenv fdtfile am335x-evmsk.dtb; fi\0 \
#define CONFIG_BOOTCOMMAND \
if mmc rescan ${mmcdev}; then \
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-coldfire/master
On Wed, Oct 24, 2012 at 02:37:05PM +, Jin Zhengxiong-R64188 wrote: Hi, Tom, The following changes since commit c4d22de817738e9f1f6a7c34664fc4ac112024a3: km83xx: add kmvect1 board (2012-10-23 15:23:26 -0500) are available in the git repository at: git://git.denx.de/u-boot-coldfire.git master Alison Wang (3): ColdFire: Fix unused variable in cpu_init.c ColdFire: Add MCF5441x CPU support ColdFire: Add Freescale MCF54418TWR ColdFire development board support arch/m68k/cpu/mcf5227x/cpu_init.c |8 +- arch/m68k/cpu/mcf5445x/config.mk | 10 + arch/m68k/cpu/mcf5445x/cpu.c | 17 + arch/m68k/cpu/mcf5445x/cpu_init.c | 313 +++-- arch/m68k/cpu/mcf5445x/speed.c| 80 +++- arch/m68k/cpu/mcf5445x/start.S| 273 ++- arch/m68k/include/asm/cache.h | 11 +- arch/m68k/include/asm/immap.h | 43 ++- arch/m68k/include/asm/immap_5441x.h | 387 ++ arch/m68k/include/asm/m5441x.h| 887 + board/freescale/m54418twr/Makefile| 43 ++ board/freescale/m54418twr/config.mk | 25 + board/freescale/m54418twr/m54418twr.c | 129 + board/freescale/m54418twr/u-boot.lds | 97 boards.cfg|6 + doc/README.m54418twr | 244 + include/configs/M54418TWR.h | 448 + 17 files changed, 2964 insertions(+), 57 deletions(-) create mode 100644 arch/m68k/include/asm/immap_5441x.h create mode 100644 arch/m68k/include/asm/m5441x.h create mode 100644 board/freescale/m54418twr/Makefile create mode 100644 board/freescale/m54418twr/config.mk create mode 100644 board/freescale/m54418twr/m54418twr.c create mode 100644 board/freescale/m54418twr/u-boot.lds create mode 100644 doc/README.m54418twr create mode 100644 include/configs/M54418TWR.h Applied to u-boot/master. Where can I find a toolchain that supports 54418 CPUs? I had picked up an m68k-uclinux toolchain from the uclinux project but that has 4 false negatives (mismatch against libgcc on a few boards) and it doesn't support 54418 CPUs. Thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Standardize on run-time board ID variables
On 10/24/2012 11:28 AM, Tom Rini wrote:
Hey all,
I've been thinking about one of the problems we need to solve over in TI
AM335x land and that is given that we support a number of different
boards with a single binary (and we have an i2c eeprom that tells us
what board and revision we are on), the user needs to be able to easily
determine what board we are on so they know what dtb file to load so
they can boot. To this end I've added
CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG to the README which says when set
we have board_name and board_rev set at run-time. Then for am335x[1]
With CONFIG_ENV_VARS_UBOOT_CONFIG set, there's a environment variable
named $board that indicates which board U-Boot is running on (and other
related variables). The idea is that the user can:
fsload ${devtype} ${devnum}:${rootpart} ${fdt_addr_r} \
/boot/${soc}-${board}.dtb
Now, CONFIG_ENV_VARS_UBOOT_CONFIG sets $board at compile-time, since the
config variable was created in the context on a U-Boot that runs on a
single board. However, I see no reason why we can't maintain the
user-visible results of this config option even in other cases, so that
everything is consistent to the user
To that end, can we make CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG set $board
instead of $board_name?
Adding $board_rev sounds like a very good idea; the filename in the
above command could be modified to:
${soc}-${board}${boardrev}.dtb
Or, do you think it'd be better for boot.scr to always reference
$fdtfile, and so modify Tegra's default environment to derive $fdtfile
from $soc, $board, $boardrev?
(This general discussion might usefully happen on the cross-distro
mailing list too?)
set that and CONFIG_BOARD_LATE_INIT which will set the variables and add a
command, findfdt to compare and set fdtfile correctly. Further
distro-specific logic can then augment this to figure out what
filesystem / partition to read from.
[1]: Yes, this will need re-working after merging Peter K's patches to
allow for non-TI boards.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/3] USB: make usb_kbd obey USB DMA alignment requirements
Change usb_kbd driver to obey alignment requirements for USB DMA on
the buffer used for data transfer. This is necessary for
architectures that enable dcache and enable USB DMA.
Signed-off-by: Allen Martin amar...@nvidia.com
---
v4: dynamically allocate xfer buffer, add alignment and roundup to buffer
instead of entire pdata struct
v3: add comment about alignemnt requirement
v2: use memalign instead of __align()
---
common/usb_kbd.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/common/usb_kbd.c b/common/usb_kbd.c
index 19f01db..24467ce 100644
--- a/common/usb_kbd.c
+++ b/common/usb_kbd.c
@@ -112,7 +112,7 @@ struct usb_kbd_pdata {
uint32_tusb_out_pointer;
uint8_t usb_kbd_buffer[USB_KBD_BUFFER_LEN];
- uint8_t new[8];
+ uint8_t *new;
uint8_t old[8];
uint8_t flags;
@@ -435,6 +435,9 @@ static int usb_kbd_probe(struct usb_device *dev, unsigned
int ifnum)
/* Clear private data */
memset(data, 0, sizeof(struct usb_kbd_pdata));
+ /* allocate input buffer aligned and sized to USB DMA alignment */
+ data-new = memalign(USB_DMA_MINALIGN, roundup(8, USB_DMA_MINALIGN));
+
/* Insert private data into USB device structure */
dev-privptr = data;
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 3/3] tegra: Enable USB keyboard
Enable USB keyboard for seaboard and ventana Signed-off-by: Allen Martin amar...@nvidia.com Acked-by: Stephen Warren swar...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com --- v4: no changes v3: no changes v2: added ventana --- include/configs/seaboard.h |3 +++ include/configs/ventana.h |3 +++ 2 files changed, 6 insertions(+) diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h index 2cb3ac9..332970c 100644 --- a/include/configs/seaboard.h +++ b/include/configs/seaboard.h @@ -98,6 +98,9 @@ #define CONFIG_TEGRA_KEYBOARD #define CONFIG_KEYBOARD +/* USB keyboard */ +#define CONFIG_USB_KEYBOARD + #include tegra-common-post.h /* NAND support */ diff --git a/include/configs/ventana.h b/include/configs/ventana.h index b751d58..4c9b31c 100644 --- a/include/configs/ventana.h +++ b/include/configs/ventana.h @@ -75,6 +75,9 @@ #define CONFIG_CMD_NET #define CONFIG_CMD_DHCP +/* USB keyboard */ +#define CONFIG_USB_KEYBOARD + #include tegra-common-post.h #endif /* __CONFIG_H */ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/3] tegra: move TEGRA_DEVICE_SETTINGS to tegra-common-post.h
Move environment settings for stdin/stdout/stderr to tegra-common-post.h and generate them automaticaly based on input device selection. Signed-off-by: Allen Martin amar...@nvidia.com Acked-by: Stephen Warren swar...@nvidia.com Tested-by: Stephen Warren swar...@nvidia.com --- v4: no changes v3: no changes v2: new patch --- include/configs/seaboard.h |5 - include/configs/tegra-common-post.h | 19 +++ include/configs/tegra20-common.h|4 3 files changed, 19 insertions(+), 9 deletions(-) diff --git a/include/configs/seaboard.h b/include/configs/seaboard.h index 0727a4c..2cb3ac9 100644 --- a/include/configs/seaboard.h +++ b/include/configs/seaboard.h @@ -98,11 +98,6 @@ #define CONFIG_TEGRA_KEYBOARD #define CONFIG_KEYBOARD -#undef TEGRA_DEVICE_SETTINGS -#define TEGRA_DEVICE_SETTINGS stdin=serial,tegra-kbc\0 \ - stdout=serial\0 \ - stderr=serial\0 - #include tegra-common-post.h /* NAND support */ diff --git a/include/configs/tegra-common-post.h b/include/configs/tegra-common-post.h index 9698c23..8d21d9c 100644 --- a/include/configs/tegra-common-post.h +++ b/include/configs/tegra-common-post.h @@ -140,6 +140,25 @@ #endif +#ifdef CONFIG_TEGRA_KEYBOARD +#define STDIN_KBD_KBC ,tegra-kbc +#else +#define STDIN_KBD_KBC +#endif + +#ifdef CONFIG_USB_KEYBOARD +#define STDIN_KBD_USB ,usbkbd +#define CONFIG_SYS_USB_EVENT_POLL +#define CONFIG_PREBOOT usb start +#else +#define STDIN_KBD_USB +#endif + +#define TEGRA_DEVICE_SETTINGS \ + stdin=serial STDIN_KBD_KBC STDIN_KBD_USB \0 \ + stdout=serial\0 \ + stderr=serial\0 \ + #define CONFIG_EXTRA_ENV_SETTINGS \ TEGRA_DEVICE_SETTINGS \ fdt_load=0x0100\0 \ diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h index 9d532f4..c3bd7ca 100644 --- a/include/configs/tegra20-common.h +++ b/include/configs/tegra20-common.h @@ -124,12 +124,8 @@ #define CONFIG_SYS_NO_FLASH -/* Environment information, boards can override if required */ #define CONFIG_CONSOLE_MUX #define CONFIG_SYS_CONSOLE_IS_IN_ENV -#define TEGRA_DEVICE_SETTINGS stdin=serial\0 \ - stdout=serial\0 \ - stderr=serial\0 #define CONFIG_LOADADDR0x408000/* def. location for kernel */ #define CONFIG_BOOTDELAY 2 /* -1 to disable auto boot */ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Standardize on run-time board ID variables
On Wed, Oct 24, 2012 at 11:50:38AM -0600, Stephen Warren wrote:
On 10/24/2012 11:28 AM, Tom Rini wrote:
Hey all,
I've been thinking about one of the problems we need to solve over in TI
AM335x land and that is given that we support a number of different
boards with a single binary (and we have an i2c eeprom that tells us
what board and revision we are on), the user needs to be able to easily
determine what board we are on so they know what dtb file to load so
they can boot. To this end I've added
CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG to the README which says when set
we have board_name and board_rev set at run-time. Then for am335x[1]
With CONFIG_ENV_VARS_UBOOT_CONFIG set, there's a environment variable
named $board that indicates which board U-Boot is running on (and other
related variables). The idea is that the user can:
fsload ${devtype} ${devnum}:${rootpart} ${fdt_addr_r} \
/boot/${soc}-${board}.dtb
Now, CONFIG_ENV_VARS_UBOOT_CONFIG sets $board at compile-time, since the
config variable was created in the context on a U-Boot that runs on a
single board. However, I see no reason why we can't maintain the
user-visible results of this config option even in other cases, so that
everything is consistent to the user
This works assuming that board maps to the device tree name. A bit more
below...
To that end, can we make CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG set $board
instead of $board_name?
I had talked with Joe about this on IRC briefly and he seemed to be
against overwriting board
Adding $board_rev sounds like a very good idea; the filename in the
above command could be modified to:
${soc}-${board}${boardrev}.dtb
Indeed, I know we'll need to do this in the future for one of the boards
in this family.
Or, do you think it'd be better for boot.scr to always reference
$fdtfile, and so modify Tegra's default environment to derive $fdtfile
from $soc, $board, $boardrev?
Or uEnv.txt, but yes, fdtfile seems to be the standard variable name for
the device tree to use. Doing something to derive this also means that
custom development can be a bit easier too since you can just set
fdtfile directly and work out the logic for auto-detection later. Also
not hard-coding in the path makes it easier for whichever distro to fill
in that logic.
(This general discussion might usefully happen on the cross-distro
mailing list too?)
Yes. Where? :)
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 1/3] USB: make usb_kbd obey USB DMA alignment requirements
On 10/24/2012 12:32 PM, Allen Martin wrote: Change usb_kbd driver to obey alignment requirements for USB DMA on the buffer used for data transfer. This is necessary for architectures that enable dcache and enable USB DMA. Tested-by: Stephen Warren swar...@nvidia.com Reviewed-by: Stephen Warren swar...@nvidia.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Standardize on run-time board ID variables
On 10/24/2012 12:41 PM, Tom Rini wrote:
On Wed, Oct 24, 2012 at 11:50:38AM -0600, Stephen Warren wrote:
On 10/24/2012 11:28 AM, Tom Rini wrote:
Hey all,
I've been thinking about one of the problems we need to solve
over in TI AM335x land and that is given that we support a
number of different boards with a single binary (and we have an
i2c eeprom that tells us what board and revision we are on),
the user needs to be able to easily determine what board we are
on so they know what dtb file to load so they can boot. To
this end I've added CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG to the
README which says when set we have board_name and board_rev set
at run-time. Then for am335x[1]
With CONFIG_ENV_VARS_UBOOT_CONFIG set, there's a environment
variable named $board that indicates which board U-Boot is
running on (and other related variables). The idea is that the
user can:
fsload ${devtype} ${devnum}:${rootpart} ${fdt_addr_r} \
/boot/${soc}-${board}.dtb
Now, CONFIG_ENV_VARS_UBOOT_CONFIG sets $board at compile-time,
since the config variable was created in the context on a U-Boot
that runs on a single board. However, I see no reason why we
can't maintain the user-visible results of this config option
even in other cases, so that everything is consistent to the
user
This works assuming that board maps to the device tree name. A bit
more below...
True. I've made sure of that for Tegra.
To that end, can we make CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG set
$board instead of $board_name?
I had talked with Joe about this on IRC briefly and he seemed to
be against overwriting board
Why is that? Perhaps alternatively, CONFIG_ENV_VARS_UBOOT_CONFIG
should set both board and a default value for board_name.
Adding $board_rev sounds like a very good idea; the filename in
the above command could be modified to:
${soc}-${board}${boardrev}.dtb
Indeed, I know we'll need to do this in the future for one of the
boards in this family.
Or, do you think it'd be better for boot.scr to always reference
$fdtfile, and so modify Tegra's default environment to derive
$fdtfile from $soc, $board, $boardrev?
Or uEnv.txt, but yes, fdtfile seems to be the standard variable
name for the device tree to use.
Ah, I do see quite a few U-Boot config headers defining that.
Doing something to derive this also means that custom development
can be a bit easier too since you can just set fdtfile directly and
work out the logic for auto-detection later.
Hmm. So I can't really put the following into Tegra's default environment:
fdtfile=${soc}-${board}${boardrev}.dtb
... since that would require any use of ${fdtfile} in a command to
first expand fdtfile itself, then expand it a second time to pick up
the actual soc/board/... values, and that's not how the shell works.
That implies that e.g. Tegra's scriptboot (seed BOOTCMDS_COMMON in
include/configs/tegra-common-post.h) would need to do something like:
setenv fdtfile ${soc}-${board}${boardrev}.dtb
... before executing the loaded boot.scr. But then, how would it know
whether to do that, or whether the user wanted to override the fdtfile
value?
In theory, I could do the following in Tegra's default environment:
fdtfile= CONFIG_SYS_SOC - CONFIG_SYS_BOARD .dtb
But then that wouldn't allow for the fdtfile value to vary at run-time
based on $boardrev.
Also not hard-coding in the path makes it easier for whichever
distro to fill in that logic.
By the path, do you mean /boot, or the way the filename is
construced? /boot in my fsload example above was a quote from the
boot.scr I use, not something U-Boot provides, so I'd expect distros
could customize it to their needs. If you mean the filename - I'd
certainly advocate enforcing that U-Boot and the kernel board names
and DT filenames be in sync.
(This general discussion might usefully happen on the
cross-distro mailing list too?)
Yes. Where? :)
cross-dis...@lists.linaro.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] am335x_evm: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support
On 10/24/2012 11:28 AM, Tom Rini wrote: We add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG, CONFIG_BOARD_LATE_INIT to set the variables and then fdtfile and findfdt to make us of this. It is now possible to do 'run findfdt' to have fdtfile be set to the value of the dtb file to load for the board we are running on. diff --git a/arch/arm/cpu/armv7/am33xx/board.c b/arch/arm/cpu/armv7/am33xx/board.c +#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG + char safe_string[HDR_NAME_LEN + 1]; + + /* Now set variables based on the header. */ + strncpy(safe_string, (char *)header.name, sizeof(header.name)); + safe_string[sizeof(header.name)] = 0; + setenv(board_name, safe_string); + + strncpy(safe_string, (char *)header.version, sizeof(header.version)); + safe_string[sizeof(header.version)] = 0; + setenv(board_rev, safe_string); +#endif By the way, is there any way to flag these variables as not being saved in the environment by saveenv? With the code above, the values will get over-written every time, so it's not such a big deal; the only issue is that the value needlessly gets saved into flash or uEnv.txt. But what about a runtime-calculated variable that is only sometimes set? I suppose the answer there is to explicitly clear it if you aren't setting it. Or what about if the environment gets saved to uEnv.txt on an SD card which gets moved to a compatible but different board or board revision, running an older U-Boot that doesn't have this patch; then, the values stick around even though they're stale. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Standardize on run-time board ID variables
On Wed, Oct 24, 2012 at 01:05:16PM -0600, Stephen Warren wrote:
On 10/24/2012 12:41 PM, Tom Rini wrote:
On Wed, Oct 24, 2012 at 11:50:38AM -0600, Stephen Warren wrote:
On 10/24/2012 11:28 AM, Tom Rini wrote:
Hey all,
I've been thinking about one of the problems we need to solve
over in TI AM335x land and that is given that we support a
number of different boards with a single binary (and we have an
i2c eeprom that tells us what board and revision we are on),
the user needs to be able to easily determine what board we are
on so they know what dtb file to load so they can boot. To
this end I've added CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG to the
README which says when set we have board_name and board_rev set
at run-time. Then for am335x[1]
With CONFIG_ENV_VARS_UBOOT_CONFIG set, there's a environment
variable named $board that indicates which board U-Boot is
running on (and other related variables). The idea is that the
user can:
fsload ${devtype} ${devnum}:${rootpart} ${fdt_addr_r} \
/boot/${soc}-${board}.dtb
Now, CONFIG_ENV_VARS_UBOOT_CONFIG sets $board at compile-time,
since the config variable was created in the context on a U-Boot
that runs on a single board. However, I see no reason why we
can't maintain the user-visible results of this config option
even in other cases, so that everything is consistent to the
user
This works assuming that board maps to the device tree name. A bit
more below...
True. I've made sure of that for Tegra.
To that end, can we make CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG set
$board instead of $board_name?
I had talked with Joe about this on IRC briefly and he seemed to
be against overwriting board
Why is that? Perhaps alternatively, CONFIG_ENV_VARS_UBOOT_CONFIG
should set both board and a default value for board_name.
Joe?
[snip]
Doing something to derive this also means that custom development
can be a bit easier too since you can just set fdtfile directly and
work out the logic for auto-detection later.
Hmm. So I can't really put the following into Tegra's default environment:
fdtfile=${soc}-${board}${boardrev}.dtb
... since that would require any use of ${fdtfile} in a command to
first expand fdtfile itself, then expand it a second time to pick up
the actual soc/board/... values, and that's not how the shell works.
That implies that e.g. Tegra's scriptboot (seed BOOTCMDS_COMMON in
include/configs/tegra-common-post.h) would need to do something like:
setenv fdtfile ${soc}-${board}${boardrev}.dtb
I hope that a longer term thing would be trying to share more of the
bootcmd related magic between all our parts. How we deal with this on
TI stuff is that in uEnv.txt if we find the file, we load the file into
the environment (so fdtfile=mylocalstuff.dtb will overwrite the default)
and if uenvcmd is set execute that command.
... before executing the loaded boot.scr. But then, how would it know
whether to do that, or whether the user wanted to override the fdtfile
value?
In theory, I could do the following in Tegra's default environment:
fdtfile= CONFIG_SYS_SOC - CONFIG_SYS_BOARD .dtb
But then that wouldn't allow for the fdtfile value to vary at run-time
based on $boardrev.
It's not an imutable variable, so you could change it, if you do that
early in the process.
Also not hard-coding in the path makes it easier for whichever
distro to fill in that logic.
By the path, do you mean /boot, or the way the filename is
construced? /boot in my fsload example above was a quote from the
boot.scr I use, not something U-Boot provides, so I'd expect distros
could customize it to their needs. If you mean the filename - I'd
certainly advocate enforcing that U-Boot and the kernel board names
and DT filenames be in sync.
Agreed all around. fdtfile should be the basename(1) of the file and
let the rest be done elsewhere. And it should be set to the expect
default coming out of the kernel or wherever the master device tree repo
is.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] mx53loco: Allow booting a zImage kernel
From: Fabio Estevam fabio.este...@freescale.com Allow booting a zImage kernel. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx53loco.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h index 0658dd3..25672c0 100644 --- a/include/configs/mx53loco.h +++ b/include/configs/mx53loco.h @@ -103,6 +103,7 @@ /* Command definition */ #include config_cmd_default.h +#define CONFIG_CMD_BOOTZ #undef CONFIG_CMD_IMLS -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] mx25pdk: Allow booting a zImage kernel
From: Fabio Estevam fabio.este...@freescale.com Allow booting a zImage kernel. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx25pdk.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/mx25pdk.h b/include/configs/mx25pdk.h index bd000a7..1dddf50 100644 --- a/include/configs/mx25pdk.h +++ b/include/configs/mx25pdk.h @@ -83,6 +83,7 @@ /* U-Boot commands */ #include config_cmd_default.h +#define CONFIG_CMD_BOOTZ #define CONFIG_CMD_CACHE /* Ethernet */ -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] mx51evk: Allow booting a zImage kernel
From: Fabio Estevam fabio.este...@freescale.com Allow booting a zImage kernel. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx51evk.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h index d3edcba..8cf59fe 100644 --- a/include/configs/mx51evk.h +++ b/include/configs/mx51evk.h @@ -144,7 +144,7 @@ ***/ #include config_cmd_default.h - +#define CONFIG_CMD_BOOTZ #undef CONFIG_CMD_IMLS #define CONFIG_CMD_DATE -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] mx6qsabre_common: Allow booting a zImage kernel
From: Fabio Estevam fabio.este...@freescale.com Allow booting a zImage kernel. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx6qsabre_common.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/mx6qsabre_common.h b/include/configs/mx6qsabre_common.h index bfb9cd4..fa38d79 100644 --- a/include/configs/mx6qsabre_common.h +++ b/include/configs/mx6qsabre_common.h @@ -72,6 +72,7 @@ /* Command definition */ #include config_cmd_default.h +#define CONFIG_CMD_BOOTZ #undef CONFIG_CMD_IMLS #define CONFIG_BOOTDELAY 3 -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] mx35pdk: Allow booting a zImage kernel
From: Fabio Estevam fabio.este...@freescale.com Allow booting a zImage kernel. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx35pdk.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/mx35pdk.h b/include/configs/mx35pdk.h index 826c912..d8f28f3 100644 --- a/include/configs/mx35pdk.h +++ b/include/configs/mx35pdk.h @@ -94,6 +94,7 @@ #include config_cmd_default.h +#define CONFIG_CMD_BOOTZ #define CONFIG_CMD_PING #define CONFIG_CMD_DHCP #define CONFIG_BOOTP_SUBNETMASK -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 0/6] am33xx: support non-ti boards
Tom == Tom Rini tr...@ti.com writes: Tom Just trying to give a window between posting and merging. I've Tom been holding at around a week which puts this at tomorrow. Ok, great - Thanks. -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 0/4] am335x_evm: Enable UART{1,2,3,4,5}
To support serial ports other than UART0 on am335x based systems like
the Beaglebone with the RS232 cape and am335x_evm with daughterboard.
Changes from v2:
Patch 4/4 cleaned up to define CONS_INDEX and SERIALX in the
target options.
Changes from v1:
Reduced from 6 patches to 4.
Reworked on Marek Vasut's serial changes.
Added UART3 for am335x_evm profile 5.
Andrew Bradford (4):
am33xx: Enable UART{1,2,3,4,5} clocks
am33xx: Enable UART{1,2,3,4,5} pin-mux
serial: ns16550: Enable COM5 and COM6
am335x_evm: Enable use of UART{1,2,3,4,5}
arch/arm/cpu/armv7/am33xx/board.c| 17
arch/arm/cpu/armv7/am33xx/clock.c| 35 +
arch/arm/include/asm/arch-am33xx/sys_proto.h |7 +++-
board/ti/am335x/mux.c| 54 ++
boards.cfg |5 +++
drivers/serial/serial_ns16550.c | 36 +++--
include/configs/am335x_evm.h | 12 +-
7 files changed, 161 insertions(+), 5 deletions(-)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] am33xx: Enable UART{1,2,3,4,5} clocks
If configured to use UART{1,2,3,4,5} such as on the Beaglebone RS232
cape or the am335x_evm daughterboard, enable the required clocks for
the UART in use.
Signed-off-by: Andrew Bradford and...@bradfordembedded.com
---
Changes from v2:
No changes
Changes from v1:
Also enable UART3 clocks
arch/arm/cpu/armv7/am33xx/clock.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/cpu/armv7/am33xx/clock.c
b/arch/arm/cpu/armv7/am33xx/clock.c
index 2b19506..b34f969 100644
--- a/arch/arm/cpu/armv7/am33xx/clock.c
+++ b/arch/arm/cpu/armv7/am33xx/clock.c
@@ -114,6 +114,41 @@ static void enable_per_clocks(void)
while (readl(cmwkup-wkup_uart0ctrl) != PRCM_MOD_EN)
;
+ /* UART1 */
+#ifdef CONFIG_SERIAL2
+ writel(PRCM_MOD_EN, cmper-uart1clkctrl);
+ while (readl(cmper-uart1clkctrl) != PRCM_MOD_EN)
+ ;
+#endif /* CONFIG_SERIAL2 */
+
+ /* UART2 */
+#ifdef CONFIG_SERIAL3
+ writel(PRCM_MOD_EN, cmper-uart2clkctrl);
+ while (readl(cmper-uart2clkctrl) != PRCM_MOD_EN)
+ ;
+#endif /* CONFIG_SERIAL3 */
+
+ /* UART3 */
+#ifdef CONFIG_SERIAL4
+ writel(PRCM_MOD_EN, cmper-uart3clkctrl);
+ while (readl(cmper-uart3clkctrl) != PRCM_MOD_EN)
+ ;
+#endif /* CONFIG_SERIAL4 */
+
+ /* UART4 */
+#ifdef CONFIG_SERIAL5
+ writel(PRCM_MOD_EN, cmper-uart4clkctrl);
+ while (readl(cmper-uart4clkctrl) != PRCM_MOD_EN)
+ ;
+#endif /* CONFIG_SERIAL5 */
+
+ /* UART5 */
+#ifdef CONFIG_SERIAL6
+ writel(PRCM_MOD_EN, cmper-uart5clkctrl);
+ while (readl(cmper-uart5clkctrl) != PRCM_MOD_EN)
+ ;
+#endif /* CONFIG_SERIAL6 */
+
/* MMC0*/
writel(PRCM_MOD_EN, cmper-mmc0clkctrl);
while (readl(cmper-mmc0clkctrl) != PRCM_MOD_EN)
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/4] am33xx: Enable UART{1,2,3,4,5} pin-mux
If configured to use UART{1,2,3,4,5} such as on the Beaglebone RS232
cape or on the am335x_evm daughterboard, enable the proper pin-muxing.
Signed-off-by: Andrew Bradford and...@bradfordembedded.com
---
Changes from v2:
No changes
Changes from v1:
Also enable UART3 pin mux
arch/arm/cpu/armv7/am33xx/board.c| 17
arch/arm/include/asm/arch-am33xx/sys_proto.h |7 +++-
board/ti/am335x/mux.c| 54 ++
3 files changed, 77 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/am33xx/board.c
b/arch/arm/cpu/armv7/am33xx/board.c
index 978b184..e324265 100644
--- a/arch/arm/cpu/armv7/am33xx/board.c
+++ b/arch/arm/cpu/armv7/am33xx/board.c
@@ -152,7 +152,24 @@ void s_init(void)
/* UART softreset */
u32 regVal;
+#ifdef CONFIG_SERIAL1
enable_uart0_pin_mux();
+#endif /* CONFIG_SERIAL1 */
+#ifdef CONFIG_SERIAL2
+ enable_uart1_pin_mux();
+#endif /* CONFIG_SERIAL2 */
+#ifdef CONFIG_SERIAL3
+ enable_uart2_pin_mux();
+#endif /* CONFIG_SERIAL3 */
+#ifdef CONFIG_SERIAL4
+ enable_uart3_pin_mux();
+#endif /* CONFIG_SERIAL4 */
+#ifdef CONFIG_SERIAL5
+ enable_uart4_pin_mux();
+#endif /* CONFIG_SERIAL5 */
+#ifdef CONFIG_SERIAL6
+ enable_uart5_pin_mux();
+#endif /* CONFIG_SERIAL6 */
regVal = readl(uart_base-uartsyscfg);
regVal |= UART_RESET;
diff --git a/arch/arm/include/asm/arch-am33xx/sys_proto.h
b/arch/arm/include/asm/arch-am33xx/sys_proto.h
index 819ea65..3ef1ff2 100644
--- a/arch/arm/include/asm/arch-am33xx/sys_proto.h
+++ b/arch/arm/include/asm/arch-am33xx/sys_proto.h
@@ -53,11 +53,16 @@ void ddr_pll_config(unsigned int ddrpll_M);
/*
* We have three pin mux functions that must exist. We must be able to enable
- * uart0, for initial output and i2c0 to read the main EEPROM. We then have a
+ * a uart for initial output and i2c0 to read the main EEPROM. We then have a
* main pinmux function that can be overridden to enable all other pinmux that
* is required on the board.
*/
void enable_uart0_pin_mux(void);
+void enable_uart1_pin_mux(void);
+void enable_uart2_pin_mux(void);
+void enable_uart3_pin_mux(void);
+void enable_uart4_pin_mux(void);
+void enable_uart5_pin_mux(void);
void enable_i2c0_pin_mux(void);
void enable_board_pin_mux(struct am335x_baseboard_id *header);
#endif
diff --git a/board/ti/am335x/mux.c b/board/ti/am335x/mux.c
index 80becd5..82b5852 100644
--- a/board/ti/am335x/mux.c
+++ b/board/ti/am335x/mux.c
@@ -259,6 +259,36 @@ static struct module_pin_mux uart0_pin_mux[] = {
{-1},
};
+static struct module_pin_mux uart1_pin_mux[] = {
+ {OFFSET(uart1_rxd), (MODE(0) | PULLUP_EN | RXACTIVE)}, /* UART1_RXD */
+ {OFFSET(uart1_txd), (MODE(0) | PULLUDEN)}, /* UART1_TXD */
+ {-1},
+};
+
+static struct module_pin_mux uart2_pin_mux[] = {
+ {OFFSET(spi0_sclk), (MODE(1) | PULLUP_EN | RXACTIVE)}, /* UART2_RXD */
+ {OFFSET(spi0_d0), (MODE(1) | PULLUDEN)},/* UART2_TXD */
+ {-1},
+};
+
+static struct module_pin_mux uart3_pin_mux[] = {
+ {OFFSET(spi0_cs1), (MODE(1) | PULLUP_EN | RXACTIVE)}, /* UART3_RXD */
+ {OFFSET(ecap0_in_pwm0_out), (MODE(1) | PULLUDEN)}, /* UART3_TXD */
+ {-1},
+};
+
+static struct module_pin_mux uart4_pin_mux[] = {
+ {OFFSET(gpmc_wait0), (MODE(6) | PULLUP_EN | RXACTIVE)}, /* UART4_RXD */
+ {OFFSET(gpmc_wpn), (MODE(6) | PULLUDEN)}, /* UART4_TXD */
+ {-1},
+};
+
+static struct module_pin_mux uart5_pin_mux[] = {
+ {OFFSET(lcd_data9), (MODE(4) | PULLUP_EN | RXACTIVE)}, /* UART5_RXD */
+ {OFFSET(lcd_data8), (MODE(4) | PULLUDEN)}, /* UART5_TXD */
+ {-1},
+};
+
static struct module_pin_mux mmc0_pin_mux[] = {
{OFFSET(mmc0_dat3), (MODE(0) | RXACTIVE | PULLUP_EN)}, /* MMC0_DAT3 */
{OFFSET(mmc0_dat2), (MODE(0) | RXACTIVE | PULLUP_EN)}, /* MMC0_DAT2 */
@@ -381,6 +411,30 @@ void enable_uart0_pin_mux(void)
configure_module_pin_mux(uart0_pin_mux);
}
+void enable_uart1_pin_mux(void)
+{
+ configure_module_pin_mux(uart1_pin_mux);
+}
+
+void enable_uart2_pin_mux(void)
+{
+ configure_module_pin_mux(uart2_pin_mux);
+}
+
+void enable_uart3_pin_mux(void)
+{
+ configure_module_pin_mux(uart3_pin_mux);
+}
+
+void enable_uart4_pin_mux(void)
+{
+ configure_module_pin_mux(uart4_pin_mux);
+}
+
+void enable_uart5_pin_mux(void)
+{
+ configure_module_pin_mux(uart5_pin_mux);
+}
void enable_i2c0_pin_mux(void)
{
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] serial: ns16550: Enable COM5 and COM6
Increase the possible number of ns16550 serial devices from 4 to 6.
Signed-off-by: Andrew Bradford and...@bradfordembedded.com
---
Changes from v2:
No changes
Changes from v1:
Consolidation of patches 3, 4, and 5 on top of Marek Vasut's
recent serial changes.
drivers/serial/serial_ns16550.c | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
diff --git a/drivers/serial/serial_ns16550.c b/drivers/serial/serial_ns16550.c
index b5d1248..5fb3841 100644
--- a/drivers/serial/serial_ns16550.c
+++ b/drivers/serial/serial_ns16550.c
@@ -34,7 +34,7 @@
DECLARE_GLOBAL_DATA_PTR;
#if !defined(CONFIG_CONS_INDEX)
-#elif (CONFIG_CONS_INDEX 1) || (CONFIG_CONS_INDEX 4)
+#elif (CONFIG_CONS_INDEX 1) || (CONFIG_CONS_INDEX 6)
#error Invalid console index value.
#endif
@@ -46,12 +46,16 @@ DECLARE_GLOBAL_DATA_PTR;
#error Console port 3 defined but not configured.
#elif CONFIG_CONS_INDEX == 4 !defined(CONFIG_SYS_NS16550_COM4)
#error Console port 4 defined but not configured.
+#elif CONFIG_CONS_INDEX == 5 !defined(CONFIG_SYS_NS16550_COM5)
+#error Console port 5 defined but not configured.
+#elif CONFIG_CONS_INDEX == 6 !defined(CONFIG_SYS_NS16550_COM6)
+#error Console port 6 defined but not configured.
#endif
/* Note: The port number specified in the functions is 1 based.
* the array is 0 based.
*/
-static NS16550_t serial_ports[4] = {
+static NS16550_t serial_ports[6] = {
#ifdef CONFIG_SYS_NS16550_COM1
(NS16550_t)CONFIG_SYS_NS16550_COM1,
#else
@@ -68,7 +72,17 @@ static NS16550_t serial_ports[4] = {
NULL,
#endif
#ifdef CONFIG_SYS_NS16550_COM4
- (NS16550_t)CONFIG_SYS_NS16550_COM4
+ (NS16550_t)CONFIG_SYS_NS16550_COM4,
+#else
+ NULL,
+#endif
+#ifdef CONFIG_SYS_NS16550_COM5
+ (NS16550_t)CONFIG_SYS_NS16550_COM5,
+#else
+ NULL,
+#endif
+#ifdef CONFIG_SYS_NS16550_COM6
+ (NS16550_t)CONFIG_SYS_NS16550_COM6
#else
NULL
#endif
@@ -231,6 +245,12 @@ struct serial_device eserial3_device =
DECLARE_ESERIAL_FUNCTIONS(4);
struct serial_device eserial4_device =
INIT_ESERIAL_STRUCTURE(4, eserial3);
+DECLARE_ESERIAL_FUNCTIONS(5);
+struct serial_device eserial5_device =
+ INIT_ESERIAL_STRUCTURE(5, eserial4);
+DECLARE_ESERIAL_FUNCTIONS(6);
+struct serial_device eserial6_device =
+ INIT_ESERIAL_STRUCTURE(6, eserial5);
__weak struct serial_device *default_serial_console(void)
{
@@ -242,6 +262,10 @@ __weak struct serial_device *default_serial_console(void)
return eserial3_device;
#elif CONFIG_CONS_INDEX == 4
return eserial4_device;
+#elif CONFIG_CONS_INDEX == 5
+ return eserial5_device;
+#elif CONFIG_CONS_INDEX == 6
+ return eserial6_device;
#else
#error Bad CONFIG_CONS_INDEX.
#endif
@@ -261,4 +285,10 @@ void ns16550_serial_initialize(void)
#if defined(CONFIG_SYS_NS16550_COM4)
serial_register(eserial4_device);
#endif
+#if defined(CONFIG_SYS_NS16550_COM5)
+ serial_register(eserial5_device);
+#endif
+#if defined(CONFIG_SYS_NS16550_COM6)
+ serial_register(eserial6_device);
+#endif
}
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 4/4] am335x_evm: Enable use of UART{1,2,3,4,5}
Add targets of am335x_evm_uart{1,2,3,4,5} to have serial input/output on
UART{1,2,3,4,5} for use with the Beaglebone RS232 cape, am335x_evm
daughterboard, and other custom configurations.
Signed-off-by: Andrew Bradford and...@bradfordembedded.com
---
Changes from v2:
Set CONS_INDEX and SERIALX in the target options instead of
using AM33XX_UART_SELECT resulting in an easier to read config.
Changes from v1:
Add UART3 target and register location
boards.cfg |5 +
include/configs/am335x_evm.h | 12 +++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/boards.cfg b/boards.cfg
index b14a08f..0024033 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -226,6 +226,11 @@ integratorap_cm946es arm arm946es
integrator armltd
integratorcp_cm946es arm arm946esintegrator
armltd - integratorcp:CM946ES
ca9x4_ct_vxp arm armv7 vexpressarmltd
am335x_evm arm armv7 am335x ti
am33xx
+am335x_evm_uart1 arm armv7 am335x ti
am33xx am335x_evm:SERIAL2=1,CONS_INDEX=2
+am335x_evm_uart2 arm armv7 am335x ti
am33xx am335x_evm:SERIAL3=1,CONS_INDEX=3
+am335x_evm_uart3 arm armv7 am335x ti
am33xx am335x_evm:SERIAL4=1,CONS_INDEX=4
+am335x_evm_uart4 arm armv7 am335x ti
am33xx am335x_evm:SERIAL5=1,CONS_INDEX=5
+am335x_evm_uart5 arm armv7 am335x ti
am33xx am335x_evm:SERIAL6=1,CONS_INDEX=6
highbank arm armv7 highbank-
highbank
mx51_efikamx arm armv7 mx51_efikamx
genesi mx5
mx51_efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKAMX,IMX_CONFIG=board/genesi/mx51_efikamx/imximage_mx.cfg
mx51_efikasb arm armv7 mx51_efikamx
genesi mx5
mx51_efikamx:MACH_TYPE=MACH_TYPE_MX51_EFIKASB,IMX_CONFIG=board/genesi/mx51_efikamx/imximage_sb.cfg
diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
index 339d4bd..b2df711 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -158,9 +158,15 @@
/* NS16550 Configuration */
#define CONFIG_SYS_NS16550
#define CONFIG_SYS_NS16550_SERIAL
+#define CONFIG_SERIAL_MULTI
#define CONFIG_SYS_NS16550_REG_SIZE(-4)
#define CONFIG_SYS_NS16550_CLK (4800)
#define CONFIG_SYS_NS16550_COM10x44e09000 /* Base EVM has
UART0 */
+#define CONFIG_SYS_NS16550_COM20x48022000 /* UART1 */
+#define CONFIG_SYS_NS16550_COM30x48024000 /* UART2 */
+#define CONFIG_SYS_NS16550_COM40x481a6000 /* UART3 */
+#define CONFIG_SYS_NS16550_COM50x481a8000 /* UART4 */
+#define CONFIG_SYS_NS16550_COM60x481aa000 /* UART5 */
/* I2C Configuration */
#define CONFIG_I2C
@@ -182,11 +188,15 @@
#define CONFIG_SYS_BAUDRATE_TABLE { 110, 300, 600, 1200, 2400, \
4800, 9600, 14400, 19200, 28800, 38400, 56000, 57600, 115200 }
+#define CONFIG_ENV_OVERWRITE 1
+
/*
- * select serial console configuration
+ * select serial console configuration, uart0 always enabled
*/
#define CONFIG_SERIAL1 1
+#ifndef CONFIG_CONS_INDEX
#define CONFIG_CONS_INDEX 1
+#endif /* CONFIG_CONS_INDEX */
#define CONFIG_SYS_CONSOLE_INFO_QUIET
#define CONFIG_ENV_IS_NOWHERE
--
1.7.10.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] USB: make usb_kbd obey USB DMA alignment requirements
Dear Allen Martin, [...] [...] Good, now please fix the bug. I'm terribly unhappy seeing there is a bug that is about to go unfixed. I didn't say the bug will go unfixed, I've opened an issue in our internal bug tracker so it doesn't go forgotten. It's just a matter of prioritization. Yes, the bug is really simple to fix, so instead of arguing, please get to work. It could have been fixed already! It's just not important to fix a corner case bug I'm sorry, I really need to be careful with wording here. I'm always baffled how an engineer can ignore a bug. in a driver that noone outside of NVIDIA can actually use when there are major functionality holes and regressions (like your change to serial_assign() that broke serial output on tegra). Stop being personal, this hurts and doesn't help. Care to send a patch for this? I don't have a working tegra setup (yet), but you can test this. I already outlined the fix, so it's just a matter to implement it. I only work on u-boot on the side, so I have to pick my battles carefully. I'm glad for any contribution from your end, don't be mistaken. I really appreciate it, sorry if my working is sometimes way too blunt or heartless. -Allen Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] am335x_evm: Enable use of UART{1, 2, 3, 4, 5}
On Wed, Oct 24, 2012 at 04:23:02PM -0400, Andrew Bradford wrote:
Add targets of am335x_evm_uart{1,2,3,4,5} to have serial input/output on
UART{1,2,3,4,5} for use with the Beaglebone RS232 cape, am335x_evm
daughterboard, and other custom configurations.
Signed-off-by: Andrew Bradford and...@bradfordembedded.com
---
Changes from v2:
Set CONS_INDEX and SERIALX in the target options instead of
using AM33XX_UART_SELECT resulting in an easier to read config.
Changes from v1:
Add UART3 target and register location
boards.cfg |5 +
include/configs/am335x_evm.h | 12 +++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/boards.cfg b/boards.cfg
index b14a08f..0024033 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -226,6 +226,11 @@ integratorap_cm946es arm arm946es
integrator armltd
integratorcp_cm946es arm arm946esintegrator
armltd - integratorcp:CM946ES
ca9x4_ct_vxp arm armv7 vexpress
armltd
am335x_evm arm armv7 am335x ti
am33xx
+am335x_evm_uart1 arm armv7 am335x ti
am33xx am335x_evm:SERIAL2=1,CONS_INDEX=2
This could just be am335x_evm:SERIAL2,CONS_INDEX=2 right? We don't
check the value of CONFIG_SERIAL2 (or 3 or ..) just tha it's set,
correct?
[snip]
/*
- * select serial console configuration
+ * select serial console configuration, uart0 always enabled
*/
#define CONFIG_SERIAL1 1
+#ifndef CONFIG_CONS_INDEX
#define CONFIG_CONS_INDEX1
+#endif /* CONFIG_CONS_INDEX */
Just amke CONS_INDEX=1 be the default in boards.cfg. Makes it clear all
around when folks add new config targets they must set that.
--
Tom
signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] USB: make usb_kbd obey USB DMA alignment requirements
On 10/24/2012 02:17 PM, Marek Vasut wrote: Dear Allen Martin, [...] [...] Good, now please fix the bug. I'm terribly unhappy seeing there is a bug that is about to go unfixed. I didn't say the bug will go unfixed, I've opened an issue in our internal bug tracker so it doesn't go forgotten. It's just a matter of prioritization. Yes, the bug is really simple to fix, so instead of arguing, please get to work. It could have been fixed already! I'm sorry, but that's not a constructive response. If you want it fixed so badly, I'm sure we'd gratefully receive a patch from you for it. As Allen pointed out, there are currently more important issues to concentrate on, such as Tegra not booting at all. I'm sure that once we've made the system work at all, then we can concentrate on the minor use-cases that simply aren't causing anyone any problems right now. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] am335x_evm: Add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/24/12 12:21, Stephen Warren wrote: On 10/24/2012 11:28 AM, Tom Rini wrote: We add CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG, CONFIG_BOARD_LATE_INIT to set the variables and then fdtfile and findfdt to make us of this. It is now possible to do 'run findfdt' to have fdtfile be set to the value of the dtb file to load for the board we are running on. diff --git a/arch/arm/cpu/armv7/am33xx/board.c b/arch/arm/cpu/armv7/am33xx/board.c +#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG + char safe_string[HDR_NAME_LEN + 1]; + + /* Now set variables based on the header. */ +strncpy(safe_string, (char *)header.name, sizeof(header.name)); + safe_string[sizeof(header.name)] = 0; + setenv(board_name, safe_string); + + strncpy(safe_string, (char *)header.version, sizeof(header.version)); + safe_string[sizeof(header.version)] = 0; + setenv(board_rev, safe_string); +#endif By the way, is there any way to flag these variables as not being saved in the environment by saveenv? With the code above, the values will get over-written every time, so it's not such a big deal; the only issue is that the value needlessly gets saved into flash or uEnv.txt. But what about a runtime-calculated variable that is only sometimes set? I suppose the answer there is to explicitly clear it if you aren't setting it. Joe? Am I thinking right that your env work leads us down the path of being able to do this? Or what about if the environment gets saved to uEnv.txt on an SD card which gets moved to a compatible but different board or board revision, running an older U-Boot that doesn't have this patch; then, the values stick around even though they're stale. Yes, there's potential problems, but I think we can work around it or live with it. And FYI, uEnv.txt is (more or less) an un-mkimage'd boot.scr file :) - -- Tom -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iQIcBAEBAgAGBQJQiFYXAAoJENk4IS6UOR1WyIMP/iGYC6j001RpBgV3zn3AgAvG 5h+2f9C/LgSrEiuH2FarginkbOqyRR1fn/GYbwK/hK3+UMyPU7bY2m++VJ1RobQ8 j8A4HGHxBh/afrpkly/TtgXjJeK5NPxB7AH0mu0UBsBAFg7b64dVjVc1ZUuwkqBO zddoFhLOvpUAuBOPiVZLBUREdgGs23pG7HO7yfyEbdUsZv6U09zlY/FQR06JgANu 2AjUZ932oH54448qmXdX2ePdX8zpWeXmsHwEDWX8kgJbGiUSe2oQbBc/u27/g1KS LiJKfh9YaJV8EYkeF+i/CDwWNI81ykuHsSOem/AsXNhk3/r2Ua54WB3oUXHEZji1 h6J+3wxF1pS/9r5/FzHsKaeR5GCGXDDEDONlDuJb4PB0ZCuDfzGmsAOBxtA/0GiU U6S3Cxwk7ajmXdtbVpZ+kzIemsqHbJd2wXKR2UDPa7fNqiTDa0XLfvWuwx6PdAmJ aZoz344padFBdv/qVmF8657pUMaPW8A4YuTFmf1sj2QD3BtA5ATbMKD2Wu5RXbjY feb/BxbZihfnCSA3RoyDCZC7Bh/OHz9v2lK6aSBQR1Jh+4ozmn6njla5iNVKcLuX SbRyjJk1kmaAOUcdhDV6py9I+Fs8CmGFynBSCSkY+8nIiCzVl8587z8bcAOp6lHn Fq0Kcoybbkp2lhyqAUG0 =sttt -END PGP SIGNATURE- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 4/4] am335x_evm: Enable use of UART{1, 2, 3, 4, 5}
On Wed, 24 Oct 2012 13:39:06 -0700
Tom Rini tr...@ti.com wrote:
On Wed, Oct 24, 2012 at 04:23:02PM -0400, Andrew Bradford wrote:
Add targets of am335x_evm_uart{1,2,3,4,5} to have serial
input/output on UART{1,2,3,4,5} for use with the Beaglebone RS232
cape, am335x_evm daughterboard, and other custom configurations.
Signed-off-by: Andrew Bradford and...@bradfordembedded.com
---
Changes from v2:
Set CONS_INDEX and SERIALX in the target options instead of
using AM33XX_UART_SELECT resulting in an easier to read
config. Changes from v1:
Add UART3 target and register location
boards.cfg |5 +
include/configs/am335x_evm.h | 12 +++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/boards.cfg b/boards.cfg
index b14a08f..0024033 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -226,6 +226,11 @@ integratorap_cm946es arm
arm946esintegrator armltd integratorcp_cm946es
arm arm946esintegrator armltd
- integratorcp:CM946ES ca9x4_ct_vxp
arm armv7 vexpressarmltd
am335x_evm arm armv7
am335x ti am33xx
+am335x_evm_uart1 arm armv7
am335x ti am33xx
am335x_evm:SERIAL2=1,CONS_INDEX=2
This could just be am335x_evm:SERIAL2,CONS_INDEX=2 right?
Right.
We don't
check the value of CONFIG_SERIAL2 (or 3 or ..) just tha it's set,
correct?
Correct.
[snip]
/*
- * select serial console configuration
+ * select serial console configuration, uart0 always enabled
*/
#define CONFIG_SERIAL1 1
+#ifndef CONFIG_CONS_INDEX
#define CONFIG_CONS_INDEX 1
+#endif /* CONFIG_CONS_INDEX */
Just amke CONS_INDEX=1 be the default in boards.cfg. Makes it clear
all around when folks add new config targets they must set that.
Will do.
v4 coming.
Thanks,
Andrew
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/32] Initial sparse fix series
On Thu, Oct 18, 2012 at 09:53:36AM -0700, Tom Rini wrote: On Tue, Oct 16, 2012 at 07:28:16PM -0500, Kim Phillips wrote: This 32-patch series only begins to address making u-boot source more 'sparseable,' or sparse-clean, ultimately to catch type, address space, and endianness mismatches and generally improve code quality. E.g., in this initial dose whose main purpose is to reduce the output volume to workable levels, a couple of endianness bugs are found and fixed in of_bus_default_translate() and fdt_get_base_address(). See [PATCH 14/32] common/fdt_support.c: sparse fixes. Patch 1 adds endianness attributes to byteorder.h helpers, e.g., cpu_to_be32(). This is required for correct operation and prevents sparse from emitting false-positives. Patches 2-6 fix issues where u-boot had imported linux header code and the importer simply force-#defined sparse-specific attributes to nothing, to allow u-boot to build. Patches 7-10 are general sparse fixes to common header areas. Patch 11 is too, which also changes the long-standing u-boot image header types to __be32, as per u-boot image definition. Patches 12-14 address further misc. sparse issues in common/. Patches 15-16 do the same for the net subsystem. Patches 17-18 do the same for lib/. Patch 19 for include/fdt.h. Patches 20-23 for Power Arch's mpc8xxx, 83xx, and 85xx subsystems. I've assigned in patchwork some of these patches to the area custodians, once reviewed please hand them back to me. For the rest of the series, I'm giving things a read and review. To this end I'm preparing to merge some of these patches today. However, even cutting out a number of patches with changes requested already I'm seeing various failures on MAKEALL --arch arm. I'll let you know at what point I stop taking the patches in and what the error is. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/32] include/linux/compat.h: fix warning: preprocessor token __iomem redefined
On Tue, Oct 16, 2012 at 07:28:18PM -0500, Kim Phillips wrote: include/linux/compat.h:4:9: warning: preprocessor token __user redefined include/linux/compiler.h:7:10: this was the original definition include/linux/compat.h:5:9: warning: preprocessor token __iomem redefined include/linux/compiler.h:12:10: this was the original definition fixup __iomem, __user definitions in compat.h code appears to be placed there as a cover up from a code import from linux when u-boot didn't yet have a compiler.h, introduced by commit 932394ac43e2e778e664eeb6e456fecd0fae6e59 Rewrite of NAND code based on what is in 2.6.12 Linux kernel. Signed-off-by: Kim Phillips kim.phill...@freescale.com include/linux/mtd/mtd-api.h now blows up on a number of omap3 boards with: In file included from .../u-boot/u-boot/include/linux/mtd/mtd.h:12:0, from mtdcore.c:10: .../u-boot/include/linux/mtd/mtd-abi.h:22:23: error: expected ':', ',', ';', '}' or '__attribute__' before '*' token I can get past this locally by adding linux/compiler.h to the file in question. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/15] x86: Add functions to access MSRs
Hi Stefan, On Thu, Oct 25, 2012 at 8:15 AM, Stefan Reinauer reina...@google.com wrote: Graeme, Reusing code from the Linux kernel is generally a great idea. However for simplicity I'd rather have 25 lines than 870 lines for reading MSRs. It seems a lot of code in those files doesn't really apply for u-boot Understood, however the code I extracted from the Linux kernel: - Makes it more likely that all the corner cases have been dealt with - Brings in all the 'magic numbers' for a wide range of CPUs, thus avoiding a continuing stream of patches (pulling them in from the Linux kernel code) - Includes MTTR functions and defines. I know coreboot is doing the memory init, but coreboot will not always be the only way to launch U-Boot and MTTRs will be needed - It's simply easier to keep synchronising with the Linux kernel when new defines and/or functions get added/removed/modified - I doubt it increases the compiled code size, and if it does, there's probably a good reason for it (corner cases) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] Standardize on run-time board ID variables
On 10/24/2012 01:32 PM, Tom Rini wrote:
On Wed, Oct 24, 2012 at 01:05:16PM -0600, Stephen Warren wrote:
On 10/24/2012 12:41 PM, Tom Rini wrote:
...
Doing something to derive this also means that custom
development can be a bit easier too since you can just set
fdtfile directly and work out the logic for auto-detection
later.
Hmm. So I can't really put the following into Tegra's default
environment:
fdtfile=${soc}-${board}${boardrev}.dtb
... since that would require any use of ${fdtfile} in a command
to first expand fdtfile itself, then expand it a second time to
pick up the actual soc/board/... values, and that's not how the
shell works.
That implies that e.g. Tegra's scriptboot (seed BOOTCMDS_COMMON
in include/configs/tegra-common-post.h) would need to do
something like:
setenv fdtfile ${soc}-${board}${boardrev}.dtb
I hope that a longer term thing would be trying to share more of
the bootcmd related magic between all our parts. How we deal with
this on TI stuff is that in uEnv.txt if we find the file, we load
the file into the environment (so fdtfile=mylocalstuff.dtb will
overwrite the default) and if uenvcmd is set execute that command.
Ah, so uEnv.txt is some user-managed file along the same lines as
boot.scr. I had thought it was the file behind CONFIG_ENV_IS_IN_FAT.
... before executing the loaded boot.scr. But then, how would it
know whether to do that, or whether the user wanted to override
the fdtfile value?
In theory, I could do the following in Tegra's default
environment:
fdtfile= CONFIG_SYS_SOC - CONFIG_SYS_BOARD .dtb
But then that wouldn't allow for the fdtfile value to vary at
run-time based on $boardrev.
It's not an imutable variable, so you could change it, if you do
that early in the process.
Sure. My point was that would end up duplicating the method to
construct the value in two places; one in includes/configs/xxx.h for
the default, and one in code in U-Boot for the case where we override
the default to include some version number. That doesn't seem ideal.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/2] socfpga/spl: Cleanup
On Tue 2012-10-23 10:27:41, Dinh Nguyen wrote: Hi Vikram, On Tue, 2012-10-23 at 15:49 +0530, Vikram Narayanan wrote: Cleanups for SPL/socfpga. Cc: Dinh Nguyen dingu...@altera.com Vikram Narayanan (2): arm/socfpga: Remove timer_init from spl_board_init socfpga/spl: Remove malloc.h Do you need to split up the patches? Otherwise, Acked-by: Dinh Nguyen dingu...@altera.com The patches are single-(functional)-line each, I think they are split up pretty perfectly. Acked-by: Pavel Machek pa...@denx.de Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/32] Initial sparse fix series
On Wed, 24 Oct 2012 14:21:20 -0700 Tom Rini tr...@ti.com wrote: On Thu, Oct 18, 2012 at 09:53:36AM -0700, Tom Rini wrote: On Tue, Oct 16, 2012 at 07:28:16PM -0500, Kim Phillips wrote: This 32-patch series only begins to address making u-boot source more 'sparseable,' or sparse-clean, ultimately to catch type, address space, and endianness mismatches and generally improve code quality. E.g., in this initial dose whose main purpose is to reduce the output volume to workable levels, a couple of endianness bugs are found and fixed in of_bus_default_translate() and fdt_get_base_address(). See [PATCH 14/32] common/fdt_support.c: sparse fixes. Patch 1 adds endianness attributes to byteorder.h helpers, e.g., cpu_to_be32(). This is required for correct operation and prevents sparse from emitting false-positives. Patches 2-6 fix issues where u-boot had imported linux header code and the importer simply force-#defined sparse-specific attributes to nothing, to allow u-boot to build. Patches 7-10 are general sparse fixes to common header areas. Patch 11 is too, which also changes the long-standing u-boot image header types to __be32, as per u-boot image definition. Patches 12-14 address further misc. sparse issues in common/. Patches 15-16 do the same for the net subsystem. Patches 17-18 do the same for lib/. Patch 19 for include/fdt.h. Patches 20-23 for Power Arch's mpc8xxx, 83xx, and 85xx subsystems. I've assigned in patchwork some of these patches to the area custodians, once reviewed please hand them back to me. For the rest of the series, I'm giving things a read and review. To this end I'm preparing to merge some of these patches today. However, even cutting out a number of patches with changes requested already I'm seeing various failures on MAKEALL --arch arm. I'll let you know at what point I stop taking the patches in and what the error is. I was going to resubmit the whole series after I'd re-done the libfdt ones to suit the dtc and the kernel libfdt copies, but patches 1 through 6 are the most important. Whether I tangled things up in my rebases, sure, there might be issues; I just wanted to partition by importance and subsystem, so the subsystem maintainers can ack/apply freely (as one did). I will definitely re-submit 14 and 19, and run checkpatch over any others you don't end up applying. I'm just caught up doing other stuff right now... Kim ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Multiple stdin/out without CONFIG_CONSOLE_MUX?
Mathieu, John, While looking into a CONFIG_CONSOLE_MUX-related issue, I noticed the following: include/configs/u8500_href.h:136: stdin=serial,usbtty\0 include/configs/u8500_href.h:135: stdout=serial,usbtty\0 include/configs/snowball.h:180: stdout=serial,usbtty\0 Those all include multiple devices in the stdin/stdout definitions. However, those config files don't set CONFIG_CONSOLE_MUX. I assume this causes usbtty to be ignored, and only serial used? Or perhaps U-Boot even fails to parse the variable at all, since CONFIG_SYS_CONSOLE_IS_IN_ENV isn't set on those boards? Actually, there are a few more boards with that problem: include/configs/km/keymile-common.h:258: stdout=serial\0 \ include/configs/MVBC_P.h:146: stdout=serial\0 \ include/configs/MVBLM7.h:460: stdout=serial\0 \ include/configs/MVSMR.h:129: stdout=serial\0 \ include/configs/sandbox.h:91: stdout=serial\0 \ include/configs/snowball.h:180: stdout=serial,usbtty\0 \ include/configs/u8500_href.h:135: stdout=serial,usbtty\0 \ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/32] common/cmd_*.c: sparse fixes
On Tue, Oct 16, 2012 at 07:28:28PM -0500, Kim Phillips wrote: [snip] cmd_mtdparts.c:157:4: warning: symbol 'current_mtd_partnum' was not declared. Should it be static? [snip] /* current active device and partition number */ -struct mtd_device *current_mtd_dev = NULL; -u8 current_mtd_partnum = 0; +static struct mtd_device *current_mtd_dev = NULL; +static u8 current_mtd_partnum = 0; This is wrong, cmd_jffs.c also uses current_mtd_partnum and has an extern in the C file for it :( -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v9] [RFC] Add dmmalloc module for DM.
Add pointer to the first early heap into GD structure.
Implement simple early_malloc and early_free functions.
Prepare for additional heaps and automated heap initialization.
Add temporary early_malloc_active function (to be replaced in future by
more coarse DM init flags).
Add DM specific malloc calls - dmmalloc, dmfree, dmrealloc and dmcalloc.
Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
---
Changes in v9:
- Rework early_malloc to keep track of allocated block size.
- Add early_free and dmfree functions.
- Rework dmrealloc.
- Add kerneldoc comments to dmmalloc.h.
Changes in v8:
- Add dmcalloc() implmentation.
- Add comments to function prototypes in dmmalloc.h.
Changes in v7:
- Rework check of first heap in early_brk().
Changes in v6:
- Move dmmalloc() and all dm* functions to dmmalloc.h.
- Fix bool expression in early_malloc_active().
arch/arm/include/asm/global_data.h|3 +
arch/avr32/include/asm/global_data.h |3 +
arch/blackfin/include/asm/global_data.h |3 +
arch/m68k/include/asm/global_data.h |3 +
arch/microblaze/include/asm/global_data.h |3 +
arch/mips/include/asm/global_data.h |3 +
arch/nds32/include/asm/global_data.h |3 +
arch/nios2/include/asm/global_data.h |3 +
arch/openrisc/include/asm/global_data.h |3 +
arch/powerpc/include/asm/global_data.h|3 +
arch/sandbox/include/asm/global_data.h|3 +
arch/sh/include/asm/global_data.h |3 +
arch/sparc/include/asm/global_data.h |3 +
arch/x86/include/asm/global_data.h|3 +
common/Makefile |1 +
common/dmmalloc.c | 188
include/dmmalloc.h| 194 +
17 files changed, 425 insertions(+)
create mode 100644 common/dmmalloc.c
create mode 100644 include/dmmalloc.h
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 2b9af93..9045829 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -82,6 +82,9 @@ typedef struct global_data {
unsigned long post_log_res; /* success of POST test */
unsigned long post_init_f_time; /* When post_init_f started */
#endif
+#ifdef CONFIG_SYS_EARLY_MALLOC
+ void*early_heap;/* heap for early_malloc */
+#endif
} gd_t;
#include asm-generic/global_data_flags.h
diff --git a/arch/avr32/include/asm/global_data.h
b/arch/avr32/include/asm/global_data.h
index bf661e2..f18f480 100644
--- a/arch/avr32/include/asm/global_data.h
+++ b/arch/avr32/include/asm/global_data.h
@@ -48,6 +48,9 @@ typedef struct global_data {
#endif
void**jt; /* jump table */
charenv_buf[32];/* buffer for getenv() before reloc. */
+#ifdef CONFIG_SYS_EARLY_MALLOC
+ void*early_heap;/* heap for early_malloc */
+#endif
} gd_t;
#include asm-generic/global_data_flags.h
diff --git a/arch/blackfin/include/asm/global_data.h
b/arch/blackfin/include/asm/global_data.h
index d91e5a4..0725d55 100644
--- a/arch/blackfin/include/asm/global_data.h
+++ b/arch/blackfin/include/asm/global_data.h
@@ -57,6 +57,9 @@ typedef struct global_data {
void**jt; /* jump table */
charenv_buf[32];/* buffer for getenv() before reloc. */
+#ifdef CONFIG_SYS_EARLY_MALLOC
+ void*early_heap;/* heap for early_malloc */
+#endif
} gd_t;
#include asm-generic/global_data_flags.h
diff --git a/arch/m68k/include/asm/global_data.h
b/arch/m68k/include/asm/global_data.h
index 0cdb11c..ab73499 100644
--- a/arch/m68k/include/asm/global_data.h
+++ b/arch/m68k/include/asm/global_data.h
@@ -66,6 +66,9 @@ typedef struct global_data {
#endif
void**jt; /* Standalone app jump table */
charenv_buf[32];/* buffer for getenv() before reloc. */
+#ifdef CONFIG_SYS_EARLY_MALLOC
+ void*early_heap;/* heap for early_malloc */
+#endif
} gd_t;
#include asm-generic/global_data_flags.h
diff --git a/arch/microblaze/include/asm/global_data.h
b/arch/microblaze/include/asm/global_data.h
index 2111c7c..f991e5d 100644
--- a/arch/microblaze/include/asm/global_data.h
+++ b/arch/microblaze/include/asm/global_data.h
@@ -46,6 +46,9 @@ typedef struct global_data {
unsigned long fb_base;/* base address of frame buffer */
void**jt; /* jump table */
charenv_buf[32];/* buffer for getenv() before reloc. */
+#ifdef CONFIG_SYS_EARLY_MALLOC
+ void*early_heap;/* heap for early_malloc */
+#endif
} gd_t;
#include asm-generic/global_data_flags.h
diff --git a/arch/mips/include/asm/global_data.h
b/arch/mips/include/asm/global_data.h
index a735a8a..8167d39 100644
---
Re: [U-Boot] [PATCH v9] [RFC] Add dmmalloc module for DM.
Hi Tomas,
Overall impression - Very nice indeed :)
A couple of nit-picks (some of which may be wrong on my part) and one
lingering question around the switch over from early to late heap...
On Thu, Oct 25, 2012 at 10:49 AM, Tomas Hlavacek tmshl...@gmail.com wrote:
Add pointer to the first early heap into GD structure.
Implement simple early_malloc and early_free functions.
Prepare for additional heaps and automated heap initialization.
Add temporary early_malloc_active function (to be replaced in future by
more coarse DM init flags).
Add DM specific malloc calls - dmmalloc, dmfree, dmrealloc and dmcalloc.
Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
---
Changes in v9:
- Rework early_malloc to keep track of allocated block size.
- Add early_free and dmfree functions.
- Rework dmrealloc.
- Add kerneldoc comments to dmmalloc.h.
Changes in v8:
- Add dmcalloc() implmentation.
- Add comments to function prototypes in dmmalloc.h.
Changes in v7:
- Rework check of first heap in early_brk().
Changes in v6:
- Move dmmalloc() and all dm* functions to dmmalloc.h.
- Fix bool expression in early_malloc_active().
arch/arm/include/asm/global_data.h|3 +
arch/avr32/include/asm/global_data.h |3 +
arch/blackfin/include/asm/global_data.h |3 +
arch/m68k/include/asm/global_data.h |3 +
arch/microblaze/include/asm/global_data.h |3 +
arch/mips/include/asm/global_data.h |3 +
arch/nds32/include/asm/global_data.h |3 +
arch/nios2/include/asm/global_data.h |3 +
arch/openrisc/include/asm/global_data.h |3 +
arch/powerpc/include/asm/global_data.h|3 +
arch/sandbox/include/asm/global_data.h|3 +
arch/sh/include/asm/global_data.h |3 +
arch/sparc/include/asm/global_data.h |3 +
arch/x86/include/asm/global_data.h|3 +
common/Makefile |1 +
common/dmmalloc.c | 188
include/dmmalloc.h| 194
+
17 files changed, 425 insertions(+)
create mode 100644 common/dmmalloc.c
create mode 100644 include/dmmalloc.h
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 2b9af93..9045829 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -82,6 +82,9 @@ typedef struct global_data {
unsigned long post_log_res; /* success of POST test */
unsigned long post_init_f_time; /* When post_init_f started */
#endif
+#ifdef CONFIG_SYS_EARLY_MALLOC
+ void*early_heap;/* heap for early_malloc */
+#endif
Why not early_heap_header *early_heap; ?
diff --git a/common/Makefile b/common/Makefile
index fdfead7..bfb4d7a 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -209,6 +209,7 @@ COBJS-y += dlmalloc.o
COBJS-y += image.o
COBJS-y += memsize.o
COBJS-y += stdio.o
+COBJS-$(CONFIG_DM) += dmmalloc.o
COBJS-$(CONFIG_SYS_EARLY_MALLOC) += dmmalloc.o ?
COBJS := $(sort $(COBJS-y))
diff --git a/common/dmmalloc.c b/common/dmmalloc.c
new file mode 100644
index 000..41589dd
--- /dev/null
+++ b/common/dmmalloc.c
@@ -0,0 +1,188 @@
+/*
+ * (C) Copyright 2012
+ * Tomas Hlavacek (tmshl...@gmail.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.
+ *
+ * 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
+ */
+
+#include common.h /* for ROUND_UP */
+#include asm/u-boot.h
+#include asm/global_data.h /* for gd_t and gd */
+#include asm/types.h /* for phys_addr_t and size_addt_t */
+
+#include dmmalloc.h
+#include malloc.h
+
+#include linux/compiler.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_SYS_EARLY_MALLOC
If you use COBJS-$(CONFIG_SYS_EARLY_MALLOC) += dmmalloc.o in the Makefile,
you can drop this #ifdef
+__weak struct early_heap_header *early_brk(size_t size)
+{
+ struct early_heap_header *h;
+ struct early_block_header *b;
+
+ if (gd-early_heap != NULL)
+ return NULL;
+
+ h = (struct early_heap_header *)CONFIG_SYS_EARLY_HEAP_ADDR;
+ b = (struct early_block_header *)(h + 1);
Hmmm,
Re: [U-Boot] [PATCH 1/5] mx53loco: Allow booting a zImage kernel
On Wed, Oct 24, 2012 at 2:44 PM, Fabio Estevam feste...@gmail.com wrote: From: Fabio Estevam fabio.este...@freescale.com Allow booting a zImage kernel. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- include/configs/mx53loco.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h index 0658dd3..25672c0 100644 --- a/include/configs/mx53loco.h +++ b/include/configs/mx53loco.h @@ -103,6 +103,7 @@ /* Command definition */ #include config_cmd_default.h +#define CONFIG_CMD_BOOTZ Fabio, Any thoughts on also enabling define CONFIG_SUPPORT_RAW_INITRD at the same time, otherwise you'd still have to run mkimage on the other half initrd.img-$(uname -r) when using booting an initramfs with your main kernel image.. Regards, -- Robert Nelson http://www.rcn-ee.com/ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] mx53loco: Allow booting a zImage kernel
Hi Robert, On Thu, Oct 25, 2012 at 12:07 AM, Robert Nelson robertcnel...@gmail.com wrote: Fabio, Any thoughts on also enabling define CONFIG_SUPPORT_RAW_INITRD at the same time, otherwise you'd still have to run mkimage on the other half initrd.img-$(uname -r) when using booting an initramfs with your main kernel image.. Sure, no problem. We can enable CONFIG_SUPPORT_RAW_INITRD as well. Stefano, Should I enable CONFIG_SUPPORT_RAW_INITRD as part of the same patch series or on a separate one? Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
