Re: [U-Boot] A question about unconfigured pads check in omap24xx_i2c
Hello Lubomir,
Am 07.11.2013 08:57, schrieb Lubomir Popov:
Hi Heiko,
On 07-Nov-13 7:14, Heiko Schocher wrote:
Hello Lubomir,
Am 06.11.2013 14:19, schrieb Lubomir Popov:
On 06-Nov-13 14:12, Nikita Kiryanov wrote:
In drivers/i2c/omap24xx_i2c.c there are a few checks that attempt to
detect unconfigured pads for the i2c bus in use. These checks are
all in the form of
if (status == I2C_STAT_XRDY) {
printf(unconfigured pads\n);
return -1;
}
This check seems peculiar to me since the meaning of I2C_STAT_XRDY is
that new data is requested for transmission. Why is that indication that
the bus is not padconf'd for I2C?
Hi Nikita,
This has been empirically confirmed on OMAP4 and OMAP5. When the pads are not
configured, the I2C controller is actually disconnected from the bus. The clock
input for its state machine has to come from the bus however due to stretching
etc., although it is internally generated. So actually nothing changes within
the controller after a transaction attempt is made, and it keeps its initial
state with XRDY set only (ready to accept transmit data). I use this as an
indicator. Not perfect, but works in most cases.
Thanks for this explanation! Maybe we can document this somewhere in
the code?
bye,
Heiko
You are right, it would be good to document it. Unfortunately I have not
been on the U-Boot wave for some months now due to very heavy engagement
with other stuff; have even unsubscribed from the list. I think however
that in order to give definite statements and improve the driver, a new
round of experiments has to be made to cover the two major types of design
flaws (software and/or hardware): incorrect pad configuration, and missing
pullups (internal or external). I wrote this driver more that 6 months ago
with the goal to have something working properly (the then existing one was,
mildly put, not good), and this detection is just a bonus side effect.
In summary, the professional approach would require some more effort, which
I'm not sure when I could afford. Otherwise, if just an explanation for the
current algo is to be given, no problem - I can just add some comments.
I vote for the professional approach ;-) But if you have no time, and
can just send a comment for the current state (maybe with a short summary,
what should be done) I am fine with this too!
Thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] udoo: Improve stability of DDR3 setting
Hi Giuseppe, On 06/11/2013 21:30, Giuseppe Pagano wrote: Move udoo configuration files to board/udoo/ folder. Align clock configuration and DDR3 calibration to Seco suggested value to increase system stability. There are some basic issues with your patchset. First, patches are corrupted by your editor and/or by your mailer and cannot be applied. ERROR: DOS line endings #222: FILE: board/udoo/ddr-setup.cfg:71: +DATA 4, MX6_IOM_GRP_DDRMODE, 0x0002^M$ ERROR: DOS line endings #223: FILE: board/udoo/ddr-setup.cfg:72: +/* disable ddr pullups */^M$ Do not use editor that add carriage return at the end of the line. Instead of generating the patches with diff, use git format-patch, and then submit the patches to the mailing list with git send-email. This avoi Please take a look at the rules to submit patches : http://www.denx.de/wiki/U-Boot/Patches Do not fix multiple issues in the same patch if not strictly needed. The commit message is misleading: you say you are moving the configuration files, but they are not moved (they can't because they belong to nitrogen) and new files are generated. I do not understand what you mean with Align clock configuration and DDR3 calibration to Seco suggested value. Please explain: which values are wrong, what you have fix with your patch. There should be a good reason to copy files. Generally, we do not want to have copies of the same files. If you make change to a board, you should send your patches in CC to the board maintainer, too (for udoo, Fabio: I put him in CC). Signed-off-by: Giuseppe Pagano giuseppe.pag...@seco.com Cc: sba...@denx.de ... diff -uNr a/board/udoo/1066mhz_4x256mx16.cfg b/board/udoo/1066mhz_4x256mx16.cfg --- a/board/udoo/1066mhz_4x256mx16.cfg +++ b/board/udoo/1066mhz_4x256mx16.cfg General issue for generating patches. please use git format-patch as I explained befoe. @@ -0,0 +1,56 @@ +/* + * Copyright (C) 2013 Boundary Devices + * + * SPDX-License-Identifier: GPL-2.0+ + */ + + +DATA 4, MX6_MMDC_P0_MDPDC, 0x00020036 +DATA 4, MX6_MMDC_P0_MDOTC, 0x09444040 + +DATA 4, MX6_MMDC_P0_MDCFG0, 0x54597955 +DATA 4, MX6_MMDC_P0_MDCFG1, 0xFF328F64 +DATA 4, MX6_MMDC_P0_MDCFG2, 0x01FF00DB + +DATA 4, MX6_MMDC_P0_MDMISC, 0x1740 +DATA 4, MX6_MMDC_P0_MDSCR, 0x8000 +DATA 4, MX6_MMDC_P0_MDRWD, 0x26D2 + +DATA 4, MX6_MMDC_P0_MDOR, 0x00591023 +DATA 4, MX6_MMDC_P0_MDASP, 0x0027 +DATA 4, MX6_MMDC_P0_MDCTL, 0x831A + +DATA 4, MX6_MMDC_P0_MDSCR, 0x04088032 +DATA 4, MX6_MMDC_P0_MDSCR, 0x8033 + +DATA 4, MX6_MMDC_P0_MDSCR, 0x00048031 +DATA 4, MX6_MMDC_P0_MDSCR, 0x09408030 +DATA 4, MX6_MMDC_P0_MDSCR, 0x04008040 +DATA 4, MX6_MMDC_P0_MPZQHWCTRL, 0xA1380003 +DATA 4, MX6_MMDC_P1_MPZQHWCTRL, 0xA1380003 +DATA 4, MX6_MMDC_P0_MDREF, 0x5800 +DATA 4, MX6_MMDC_P0_MPODTCTRL, 0x0007 +DATA 4, MX6_MMDC_P1_MPODTCTRL, 0x0007 + +DATA 4, MX6_MMDC_P0_MPDGCTRL0, 0x43510360 +DATA 4, MX6_MMDC_P0_MPDGCTRL1, 0x0342033F +DATA 4, MX6_MMDC_P1_MPDGCTRL0, 0x033F033F +DATA 4, MX6_MMDC_P1_MPDGCTRL1, 0x03290266 + +DATA 4, MX6_MMDC_P0_MPRDDLCTL, 0x4B3E4141 +DATA 4, MX6_MMDC_P1_MPRDDLCTL, 0x47413B4A +DATA 4, MX6_MMDC_P0_MPWRDLCTL, 0x42404843 +DATA 4, MX6_MMDC_P1_MPWRDLCTL, 0x4C3F4C45 + +DATA 4, MX6_MMDC_P0_MPWLDECTRL0, 0x00350035 +DATA 4, MX6_MMDC_P0_MPWLDECTRL1, 0x001F001F +DATA 4, MX6_MMDC_P1_MPWLDECTRL0, 0x00010001 +DATA 4, MX6_MMDC_P1_MPWLDECTRL1, 0x00010001 + +DATA 4, MX6_MMDC_P0_MPMUR0, 0x0800 +DATA 4, MX6_MMDC_P1_MPMUR0, 0x0800 + +DATA 4, MX6_MMDC_P0_MDPDC, 0x00025576 +DATA 4, MX6_MMDC_P0_MAPSR, 0x00011006 +DATA 4, MX6_MMDC_P0_MDSCR, 0x + diff -uNr a/board/udoo/clocks.cfg b/board/udoo/clocks.cfg --- a/board/udoo/clocks.cfg +++ b/board/udoo/clocks.cfg @@ -0,0 +1,32 @@ +/* + * Copyright (C) 2013 Boundary Devices + * + * SPDX-License-Identifier: GPL-2.0+ + * + * Device Configuration Data (DCD) + * + * Each entry must have the format: + * Addr-type AddressValue + * + * where: + * Addr-type register length (1,2 or 4 bytes) + * Address absolute address of the register + * value value to be stored in the register + */ + +/* set the default clock gate to save power */ +DATA 4, CCM_CCGR0, 0x00C03F3F +DATA 4, CCM_CCGR1, 0x0030FC03 +DATA 4, CCM_CCGR2, 0x0FFFC000 +DATA 4, CCM_CCGR3, 0x3FF0 +DATA 4, CCM_CCGR4, 0x00FFF300 +DATA 4, CCM_CCGR5, 0x0FC3 +DATA 4, CCM_CCGR6, 0x03FF + +/* enable AXI cache for VDOA/VPU/IPU */ +DATA 4, MX6_IOMUXC_GPR4, 0xF0FF + +/* set IPU AXI-id0 Qos=0xf(bypass) AXI-id1 Qos=0x7 */ +DATA 4, MX6_IOMUXC_GPR6, 0x007F007F +DATA 4, MX6_IOMUXC_GPR7, 0x007F007F + diff -uNr a/board/udoo/ddr-setup.cfg b/board/udoo/ddr-setup.cfg --- a/board/udoo/ddr-setup.cfg +++ b/board/udoo/ddr-setup.cfg @@ -0,0 +1,87 @@ +/* + * Copyright (C) 2013 Boundary Devices + * + * SPDX-License-Identifier: GPL-2.0+ + * + * Device Configuration Data (DCD) + * + * Each
Re: [U-Boot] A question about unconfigured pads check in omap24xx_i2c
Heiko,
On 07-Nov-13 10:04, Heiko Schocher wrote:
Hello Lubomir,
Am 07.11.2013 08:57, schrieb Lubomir Popov:
Hi Heiko,
On 07-Nov-13 7:14, Heiko Schocher wrote:
Hello Lubomir,
Am 06.11.2013 14:19, schrieb Lubomir Popov:
On 06-Nov-13 14:12, Nikita Kiryanov wrote:
In drivers/i2c/omap24xx_i2c.c there are a few checks that attempt to
detect unconfigured pads for the i2c bus in use. These checks are
all in the form of
if (status == I2C_STAT_XRDY) {
printf(unconfigured pads\n);
return -1;
}
This check seems peculiar to me since the meaning of I2C_STAT_XRDY is
that new data is requested for transmission. Why is that
indication that
the bus is not padconf'd for I2C?
Hi Nikita,
This has been empirically confirmed on OMAP4 and OMAP5. When the
pads are not
configured, the I2C controller is actually disconnected from the
bus. The clock
input for its state machine has to come from the bus however due to
stretching
etc., although it is internally generated. So actually nothing
changes within
the controller after a transaction attempt is made, and it keeps
its initial
state with XRDY set only (ready to accept transmit data). I use
this as an
indicator. Not perfect, but works in most cases.
Thanks for this explanation! Maybe we can document this somewhere in
the code?
bye,
Heiko
You are right, it would be good to document it. Unfortunately I have not
been on the U-Boot wave for some months now due to very heavy engagement
with other stuff; have even unsubscribed from the list. I think however
that in order to give definite statements and improve the driver, a new
round of experiments has to be made to cover the two major types of
design
flaws (software and/or hardware): incorrect pad configuration, and
missing
pullups (internal or external). I wrote this driver more that 6
months ago
with the goal to have something working properly (the then existing
one was,
mildly put, not good), and this detection is just a bonus side effect.
In summary, the professional approach would require some more effort,
which
I'm not sure when I could afford. Otherwise, if just an explanation
for the
current algo is to be given, no problem - I can just add some comments.
I vote for the professional approach ;-) But if you have no time, and
can just send a comment for the current state (maybe with a short
summary,
what should be done) I am fine with this too!
OK, shall see to the easy way first - just add some comments, sometime
next week.
But, no promises ;-)
Lubo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Hello Wolfgang, Tom, Am 06.11.2013 08:50, schrieb Wolfgang Denk: Dear Tom, In message20131105203736.GM5925@bill-the-cat you wrote: We have the real problem, that we have a lot of old boards, which are unmaintained in U-Boot, and we have no chance to find out, if this boards are longer used/tested ... We also have a feature, lots of hardware support because lots of things don't change drastically, frequently. That's not to say that I wouldn't mind dropping old platforms (even that ones I have sentimental feelings towards), and would certainly like to see more and frequent sanity testing. Yep, thats the reason I had in mind. We must have more real tests on real hardware (or at least, get back the info, that this is done somewhere ...) ... thats the idea behind to force the board maintainers to give back us such info. I think Heiko's idea of documenting test reports is pretty cool - but of course we need to discuss in detail how to implement this, and also decide wether we use this for (semi-automatic) code cleanup (by removing boards that have not been tested for a long time). I vote for removing boards from which we get no such test info back. The board support code is just availiable, just not for current releases. If code does not change drastically, such a compile and try it on the hardware, give feedback to mainline should not cost much time the board maintainer, and maybe we add a script, which the board maintainer just have to call, to send an board tested EMail to the mailinglist ... Maybe a lot of boardmaintainers do this tests, and this info is important for mainline, but we have no mechanism to collect this info! And if code changes drastically (which it currently does and will do in future I think) a board maintainer must decide, if it makes sense to sync the board with current mainline or the board get dropped from mainline ... And I have this problem currently with i2c subsystem ... a lot of boards to convert to new framework, and I cannot decide, which are really maintained... or if currently, the converted boards, really work. (And I think, not only the i2c subsystem has this problem) This problem comes up when we talk about doing big changes, and I think that's the right time to talk about things. And I think the answer should be, we try and convert things forward and when it's not obvious if things will still work correctly, or how to do it, that's when we need to make a hard push on the board maintainers to find some time to work on things. Agreed. And here information how recently (or maybe even how frequently) a board has been tested (build tested, run on actual hardware) would come in really handy. we can probbaly automate build testing one way or another, but for actual runtime tests we will lways depend on the board maintainers, or board users. Hmm.. Is it always obvious, if changes are big? Do we really get feedback when doing such big changes? I just reworking the i2c framework, and I have not really much feedback from board maintainers for their boards I changed ... Does this change really work on all boards I converted? I have no chance to get this info. But if we have such a livetime feature, I can be sure, that after n releases all boards in mainline are tested ... automatically ... I want such a feature ... So, the question raises, should we introduce a column in boards.cfg, which shows the livetime of a board support in U-Boot? I sense a lot of conflicting patches. Again I agree. Also, I fear that boards.cfg is becoming more and more unreadable by adding even more stuff. If I see this correctly, the maximum line length in boards.cfg already exceeds 360 characters :-( Right, boards.cfg gets unhandy ... Hmm .. what with the column Staus ... instead of Active it would be more informative to have there the livetime counter, and a single digit saves some characters ;-) But you are right, that approach leads in a lot of conflicting patches ... but I think, we just pooled board information in boards.cfg, so this would be the right place in my eyes ... Maybe we get such Information a Boards is tested with current mainline inform of an EMail with an Text Board xy tested with commit mm. Please update livetime ... and we can add a script, which updates the livetime for this board, so we can prevent conflicting patches ... ? So nstead of adding this information to boards.cfg we could probably use separate files for such information. We could provide tools to make test reports really easy, say something like scripts/build_test scripts/run_test which the user would just call with a passed or failed argument; the scripts could then auto-detect which configuration and which exact U-Boot version were in use, and send an email. Whether that would be a patch against the source code or something that get's auto-added to a wiki page is just an implementation detail. But if we had something like this, we could get a muchbetter
Re: [U-Boot] [PATCH 4/4] udoo: fix watchdog setting
Hi Giuseppe, On 06/11/2013 21:44, Giuseppe Pagano wrote: To have watchdog quiet during kernel boot it is necessary to change gpio wdt trigger direction. Sorry, this is not a good explanation. You force a GPIO to drop a feture, instead of disabling the feature itself. And maybe some other people want to have this feature enabled. Which is the timeout for the watchdog ? Why is it hitting too soon ? Fix should be not done simply removing the effect, but checking the cause. Signed-off-by: Giuseppe Pagano giuseppe.pag...@seco.com Cc: sba...@denx.de --- diff -uNr a/board/udoo/udoo.c b/board/udoo/udoo.c --- a/board/udoo/udoo.c 2013-11-06 18:47:26.0 +0100 +++ b/board/udoo/udoo.c 2013-11-06 18:54:46.0 +0100 @@ -168,6 +168,7 @@ imx_iomux_v3_setup_multiple_pads(wdog_pads, ARRAY_SIZE(wdog_pads)); gpio_direction_output(WDT_TRG, 0); gpio_direction_output(WDT_EN, 1); + gpio_direction_input(WDT_TRG); I do not think this a right way to disable a watchdog. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/14] ARM: AM43xx: mux: Update mux data
On Wednesday 06 November 2013 10:11 PM, Vaibhav Bedia wrote:
On Wed, Nov 6, 2013 at 8:32 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
On Wednesday 06 November 2013 06:13 PM, Vaibhav Bedia wrote:
On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote:
Updating the mux data for UART, and adding data for i2c0 and mmc.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/include/asm/arch-am33xx/mux_am43xx.h |4 +++-
board/ti/am43xx/mux.c | 24
++--
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
index 0206912..e95efdd 100644
--- a/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
+++ b/arch/arm/include/asm/arch-am33xx/mux_am43xx.h
@@ -16,7 +16,9 @@
__raw_writel(value, (CTRL_BASE + offset));
/* PAD Control Fields */
-#define SLEWCTRL (0x1 19)
+#define DSPULLUDEN (0x1 27) /* DS0 mode Pull-Up/Down enable */
+#define DSPULLUDDIS(0x0 27) /* DS0 mode Pull-Up/Down Disable */
+#define SLEWCTRL (0x1 19) /* Slow slew rate selection */
#define RXACTIVE (0x1 18)
#define PULLDOWN_EN(0x0 17) /* Pull Down Selection */
#define PULLUP_EN (0x1 17) /* Pull Up Selection */
diff --git a/board/ti/am43xx/mux.c b/board/ti/am43xx/mux.c
index 700e9a7..818a046 100644
--- a/board/ti/am43xx/mux.c
+++ b/board/ti/am43xx/mux.c
@@ -12,8 +12,26 @@
#include board.h
static struct module_pin_mux uart0_pin_mux[] = {
- {OFFSET(uart0_rxd), (MODE(0) | RXACTIVE)}, /* UART0_RXD */
- {OFFSET(uart0_txd), (MODE(0))}, /* UART0_TXD */
+ {OFFSET(uart0_rxd),
+(MODE(0) | PULLUP_EN | RXACTIVE | SLEWCTRL | DSPULLUDEN)},
+ {OFFSET(uart0_txd),
+(MODE(0) | PULLUDDIS | PULLUP_EN | SLEWCTRL | DSPULLUDEN)},
+ {-1},
+};
+
+static struct module_pin_mux mmc0_pin_mux[] = {
+ {OFFSET(mmc0_clk), (MODE(0) | PULLUDDIS | RXACTIVE | DSPULLUDEN)},
+ {OFFSET(mmc0_cmd), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
+ {OFFSET(mmc0_dat0), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
+ {OFFSET(mmc0_dat1), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
+ {OFFSET(mmc0_dat2), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
+ {OFFSET(mmc0_dat3), (MODE(0) | PULLUP_EN | RXACTIVE | DSPULLUDEN)},
+ {-1},
Hmm i don't think updating the DSPULL here is a good idea. Since not
all the pins
are used in U-Boot, this is just partially updating the pulls for the
low power state.
I would suggest leaving this bit for the kernel where things can be
updated without
updating the bootloader.
These are the preferred settings given to me.
Any way if kernel is updating it overwrites these settings, it shouldn't
matter I guess..:)
It's better to clearly list down what configuration a particular
entity in the system is
responsible for. Doing partial updates her just makes issues harder to debug.
Ok, Ill update..
Thanks and regards,
Lokesh
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] udoo: Adjust default boot envirnment
Hi Giuseppe,
On 06/11/2013 21:44, Giuseppe Pagano wrote:
Change u-boot default environment for uDoo board to:
- mount /dev/mmcblk0p1 partition
- activate hdmi monitor by default (instead of nothing)
Signed-off-by: Giuseppe Pagano giuseppe.pag...@seco.com
Cc: sba...@denx.de
---
diff -uNr a/include/configs/udoo.h b/include/configs/udoo.h
--- a/include/configs/udoo.h 2013-11-06 18:51:57.0 +0100
+++ b/include/configs/udoo.h 2013-11-06 18:52:16.0 +0100
@@ -100,7 +100,7 @@
#define CONFIG_EXTRA_ENV_SETTINGS \
script=boot.scr\0 \
- uimage=uImage\0 \
+ uimage=/boot/uImage\0 \
console=ttymxc1\0 \
splashpos=m,m\0 \
fdt_high=0x\0 \
@@ -111,7 +111,7 @@
ip_dyn=yes\0 \
mmcdev=0\0 \
mmcpart=1\0 \
- mmcroot=/dev/mmcblk0p2 rootwait rw\0 \
+ mmcroot=/dev/mmcblk0p1 rootwait rw\0 \
update_sd_firmware_filename=u-boot.imx\0 \
update_sd_firmware= \
if test ${ip_dyn} = yes; then \
@@ -127,13 +127,14 @@
fi; \
fi\0 \
mmcargs=setenv bootargs console=${console},${baudrate} \
- root=${mmcroot}\0 \
+ root=${mmcroot} rootwait rw \
+ fbmem=24M video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24\0 \
loadbootscript= \
- fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0 \
+ ext2load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0 \
I have already explained my doubts regarding the abuse of
EXTRA_ENV_SETTINGS. The setup that should be minimal and general for
most of uses is then customized for a specific scope, that conflict with
other goals. You are changing the filesystem on the card: I cannot
estimate how this can be useful for everyone (maybe yes, maybe not).
I hope that Simon's patches to split the default environment from the
configuration file will find soon a way to mainline. Check in the ML for
env: Add support for environment files
Then it will be possible to define an own text file containing the
environment outside of the configuration file. And adding a new default
environment will mean only to specify the env file in boards.cfg.
bootscript=echo Running bootscript from mmc ...; \
source\0 \
- loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0
\
- loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0 \
+ loaduimage=ext2load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0
\
+ loadfdt=ext2load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0
\
mmcboot=echo Booting from mmc ...; \
run mmcargs; \
if test ${boot_fdt} = yes || test ${boot_fdt} = try; then \
@@ -189,7 +190,7 @@
/* Miscellaneous configurable options */
#define CONFIG_SYS_LONGHELP
#define CONFIG_SYS_HUSH_PARSER
-#define CONFIG_SYS_PROMPT =
+#define CONFIG_SYS_PROMPTuDoo board
#define CONFIG_AUTO_COMPLETE
#define CONFIG_SYS_CBSIZE 256
We had already some discussion on the mailing list about the meaning and
the usefulness of the U-Boot prompt. I will apply a patch for all
Freescale boards that remove a custom prompt, letting the default. Which
is the improvement to have a custom prompt ?
Maybe you are the second one asking for the feature:
http://u-boot.10912.n7.nabble.com/Changing-CONFIG-SYS-PROMPT-on-the-fly-td166105.html
As suggested by Simon (take a look at the whole thread), it is then
better to set the prompt from an environment variable. Feel free to
submit a patch for it.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] udoo: Add Ethernet support.
Hi Giuseppe,
On 06/11/2013 21:33, Giuseppe Pagano wrote:
Add Ethernet and networking support on uDoo board (FEC + phy Micrel)
Signed-off-by: Giuseppe Pagano giuseppe.pag...@seco.com
Cc: sba...@denx.de
---
diff -uNr a/board/udoo/udoo.c b/board/udoo/udoo.c
--- a/board/udoo/udoo.c
+++ b/board/udoo/udoo.c
@@ -9,6 +9,7 @@
#include asm/arch/clock.h
#include asm/arch/imx-regs.h
#include asm/arch/iomux.h
+#include malloc.h
#include asm/arch/mx6-pins.h
#include asm/errno.h
#include asm/gpio.h
@@ -18,6 +19,9 @@
#include asm/arch/crm_regs.h
#include asm/io.h
#include asm/arch/sys_proto.h
+#include micrel.h
+#include miiphy.h
+#include netdev.h
DECLARE_GLOBAL_DATA_PTR;
@@ -25,6 +29,9 @@
PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | \
PAD_CTL_SRE_FAST | PAD_CTL_HYS)
+#define ENET_PAD_CTRL (PAD_CTL_PUS_100K_UP | \
+ PAD_CTL_SPEED_MED | PAD_CTL_DSE_40ohm | PAD_CTL_HYS)
+
#define USDHC_PAD_CTRL (PAD_CTL_PUS_47K_UP | \
PAD_CTL_SPEED_LOW | PAD_CTL_DSE_80ohm | \
PAD_CTL_SRE_FAST | PAD_CTL_HYS)
@@ -58,6 +65,99 @@
MX6_PAD_EIM_D19__GPIO_3_19,
};
+int mx6_rgmii_rework(struct phy_device *phydev)
+{
+ /* To advertise only 10 Mbs */
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x4, 0x61);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x9, 0x0c00);
+
Why only 10 Mb/s ? I think the Micrel 9031 allows 1Gb/s.
Generally, use defines instead of hard coded values.
+ /* enable master mode, force phy to 100Mbps */
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x9, 0x1c00);
+
+ /* min rx data delay */
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x0b, 0x8105);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x0c, 0x);
+
+ /* max rx/tx clock delay, min rx/tx control delay */
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x0b, 0x8104);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x0c, 0xf0f0);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x0b, 0x104);
+
+ /* min rx data delay */
+ ksz9021_phy_extended_write(phydev,
+MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW, 0x0);
Is is 9021 or 9031 ?
+
+static void setup_iomux_enet(void)
+{
+ imx_iomux_v3_setup_multiple_pads(enet_pads1, ARRAY_SIZE(enet_pads1));
+ udelay(20);
+ gpio_direction_output(IMX_GPIO_NR(2, 31), 1); /* Power on of enet */
+
+ gpio_direction_output(IMX_GPIO_NR(3, 23), 0); /* SABRE Lite PHY rst */
+
+ gpio_direction_output(IMX_GPIO_NR(6, 24), 1);
+ gpio_direction_output(IMX_GPIO_NR(6, 25), 1);
+ gpio_direction_output(IMX_GPIO_NR(6, 27), 1);
+ gpio_direction_output(IMX_GPIO_NR(6, 28), 1);
+ gpio_direction_output(IMX_GPIO_NR(6, 29), 1);
+ udelay(1000 * 10);
+
+ gpio_set_value(IMX_GPIO_NR(3, 23), 1); /* SABRE Lite PHY rst */
SABRE as comment is maybe wrong
+#define CONFIG_PHY_MICREL_KSZ9021
Ok, it is 9021 - please be consistent with the comments avoiding mixing
9031 and 9021.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] udoo: Add SATA disk support.
Hi Giuseppe,
On 06/11/2013 21:37, Giuseppe Pagano wrote:
Add Sata support on uDoo Board.
Signed-off-by: Giuseppe Pagano giuseppe.pag...@seco.com
Cc: sba...@denx.de
---
diff -uNr a/board/udoo/udoo.c b/board/udoo/udoo.c
--- a/board/udoo/udoo.c 2013-11-06 18:45:22.0 +0100
+++ b/board/udoo/udoo.c 2013-11-06 18:46:00.0 +0100
@@ -208,6 +208,32 @@
return 0;
}
+#ifdef CONFIG_CMD_SATA
+int setup_sata(void)
+{
+ struct iomuxc_base_regs *const iomuxc_regs
+ = (struct iomuxc_base_regs *)IOMUXC_BASE_ADDR;
+
+ int ret = enable_sata_clock();
+ if (ret)
+ return ret;
+
+ clrsetbits_le32(iomuxc_regs-gpr[13],
+ IOMUXC_GPR13_SATA_MASK,
+ IOMUXC_GPR13_SATA_PHY_8_RXEQ_3P0DB
+ |IOMUXC_GPR13_SATA_PHY_7_SATA2M
+ |IOMUXC_GPR13_SATA_SPEED_3G
+ |(3IOMUXC_GPR13_SATA_PHY_6_SHIFT)
+ |IOMUXC_GPR13_SATA_SATA_PHY_5_SS_DISABLED
+ |IOMUXC_GPR13_SATA_SATA_PHY_4_ATTEN_9_16
+ |IOMUXC_GPR13_SATA_PHY_3_TXBOOST_0P00_DB
+ |IOMUXC_GPR13_SATA_PHY_2_TX_1P104V
+ |IOMUXC_GPR13_SATA_PHY_1_SLOW);
+
+ return 0;
+}
+#endif
Do not copy code ! If you want to reuse functions from nitrogen, please
factorize the function and put it into imx-common, thanks.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 0/5] mtd: nand: omap: optimize and clean-up of OMAP NAND driver
Hi Pekon, Thank you for your answers. Please find my answers/comments to your questions below. 2013/11/6 Gupta, Pekon pe...@ti.com Hi Matti and Matthias Sorry I was away from my mailbox so couldn't reply you earlier. I'm still away from my setup and other boards, so cannot replicate the issue below until early next week. But I'll surely do so asap.. However, please see my replies below, which might help you someway. From: matti kaasinen [mailto:matti.kaasi...@gmail.com] Hi Pekon, Thanks to Tom Rini's hint I have tried to execute your patch sets (http://patchwork.ozlabs.org/project/uboot/list/?submitter=17320state=* ) in order to get Linux and U-Boot working with same NAND flash. Set-up is pretty much like Mathias has before in this chain. Latest problem I faced with is that last versions of 1) [U-Boot,v8,3/5] mtd: nand: omap: optimize chip-ecc.calculate() for H/W ECC schemes and 2) [U-Boot,v2,2/3] mtd: nand: omap: add support for BCH16_ECC - NAND driver updates are not compatible any more. As I told in https://groups.google.com/forum/#!topic/beagleboard/7ofbE_Rrn_s versions v5..v7 of 1) could possibly be compatible. There is no change in ECC layout or other functional updates between v7 and v8 of this patch, so if there is any incompatibility then it would be in all versions of the patch.. I did not mean ECC layout-wisely incompatible but patching-wisely incompatible. Patching 2) v2 after 1) v8 stops to errors and it seems that with 1) v7 it could (possibly) succeed. Few questions.. (1) Which ECC scheme are you using ? Now I'm talking Linux 3.8.13 - U-Boot 10.04 combination that I have as currently as working environment. I have not managed getting above patches successfully through. - u-boot CONFIG_NAND_OMAP_ECCSCHEME as per doc/README.nand http://lists.denx.de/pipermail/u-boot/2013-October/164646.html U-Boot 10.04 does not seem to have such choices and in fact I have not selected it. - kernel OMAP_ECC_BCH8_CODE_HW OMAP_ECC_BCH8_CODE_HW_DETECTION_SW Or any other.. I believe OMAP_ECC_BCH8_CODE_HW gets selected with following options from kernel. CONFIG_MTD_NAND_OMAP2 CONFIG_MTD_NAND_OMAP_BCH CONFIG_MTD_NAND_OMAP_BCH8 ... and selecting following choice ti,nand-ecc-opt = bch8 in device tree. With these options boot process reports; [1.128154] enabling NAND BCH ecc with 8-bit correction [1.133985] ONFI param page 0 valid [1.137662] ONFI flash detected [1.140985] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08AAD), 256MiB, page size: 2048, OOB size: 64 First line seems coming from drivers/nand/mtd/omap2.c:omap3_init_bch that gets printed in this from only if OMAP_ECC_BCH8_CODE_HW == platform_data.ecc_opt I printed nand.ecc.layout.eccbytes = 52 ( from from drivers/nand/mtd/omap2.c:omap3_init_bch_tail ) and nand.ecc.layout-eccpos[] = 12..63 BTW it seems that similar layout has been defined in u-boot arch/arm/include/asm/arch-omap3/omap_gpmc.h There is one exception, though: eccbytes have been set 54 instead of 52 that seems to be in linux (and correct I suppose). (2) Is the problem related to incorrect read/write access to x16 NAND ? No using x8 NAND Or Is it incompatibility in ecc.layout ? You can check this by dumping raw nand page via 'nand dump' command from both u-boot and kernel. I'll try to check this (3) you should not pick BCH16 patch-series - because I have not rebased this patch, and re-tested since other base patch-series on which BCH16 will be build, is still not accepted. - Also BCH16 ecc scheme would work only for NAND device with pagesize=4K and oobsize=224. whereas current beaglebone capes have NAND device with pagesize=2K and oobsize=64, so you can only use BCH8 with current NAND capes (for now).. This is perfectly fine with me. This set seems to block patching. I need only BCH8 and if this patch set provides only BCH16 functionality and nothing else, I need not using it. 2013/11/1 Matthias Fuchs mfu...@ma-fu.de Hi Pekon, should I consider the U-Boot and Linux am335x NAND implementation to be compatible? So are the ECC schemes in a way identical that I can nandwrite a kernel image from Linux and nand read it from U-Boot? I tested with the 3.8.13 beaglebone kernel (which is of course not very representative) and it does not work. If it should work, do you know it that was already the case before your patches and with which Linux kernel? I don't think any earlier kernel versions ever supported beaglebone Its only recently that a major patch-series of NAND driver was accepted and tested on beaglebone. The patches are currently in l2-mtd.git tree which should make into 3.13 kernel, before being in linux-next for sometime. (a) Reference: http://lists.infradead.org/pipermail/linux-mtd/2013-October/049462.html (b) In addition to above series, you might need
Re: [U-Boot] [RFC][PATCH 0/5] SATA support for OMAP5 uevm
Hi Roger, Thanks for the patches! 2013/11/6 Roger Quadros rog...@ti.com: Hi, This series adds SATA support for OMAP5 uevm board. This is an RFC patchset for review only. Patches are based on v2013.10. cheers, -roger --- Roger Quadros (5): ahci: Error out with message on malloc() failure ARM: OMAP5: Add Pipe3 PHY driver ARM: OMAP5: Add PRCM and Control information for SATA ARM: OMAP5: Add SATA platform glue ARM: omap5_uevm: Add SATA support arch/arm/cpu/armv7/omap-common/Makefile| 7 + arch/arm/cpu/armv7/omap-common/pipe3-phy.c | 233 + arch/arm/cpu/armv7/omap-common/pipe3-phy.h | 36 + arch/arm/cpu/armv7/omap-common/sata.c | 78 ++ arch/arm/cpu/armv7/omap5/prcm-regs.c | 5 + arch/arm/include/asm/arch-omap5/clock.h| 3 + arch/arm/include/asm/arch-omap5/omap.h | 3 + arch/arm/include/asm/arch-omap5/sata.h | 48 ++ arch/arm/include/asm/omap_common.h | 3 + board/ti/omap5_uevm/evm.c | 7 + drivers/block/ahci.c | 16 +- include/configs/omap5_uevm.h | 10 ++ 12 files changed, 447 insertions(+), 2 deletions(-) create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.c create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.h create mode 100644 arch/arm/cpu/armv7/omap-common/sata.c create mode 100644 arch/arm/include/asm/arch-omap5/sata.h -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot I applied your patches and worked perfectly, however I've two small issues. The first issue is that I see the following error: scanning bus for devices... ERROR: v7_dcache_inval_range - start address is not aligned - 0xfee48618 ERROR: v7_dcache_inval_range - stop address is not aligned - 0xfee48818 The second issue, and I'm not sure if the problem should be solved at u-boot level, is that I'm not able to access to the SATA disk at kernel level. I meant, if I boot to the system with latest stable u-boot the kernel recognizes the SATA disk and I'm able to mount, read and write to the disk. If I boot using u-boot with your patches applied the kernel doesn't recognizes the SATA disk and doesn't work. In that case the kernel reports the following error: ata1: COMRESET failed (errno=-16) Note that the kernel version that I'm using is 3.8.13 from git.ti.com. Cheers, Enric ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: interrupt_init before relocation, write fails
Hi Joe, On Wed, 6 Nov 2013 09:18:53 -0700, Joe Kulikauskas jkulikaus...@cardinalpeak.com wrote: Hi, Rob, yes that's correct. To Albert's question: the disassembled instruction I had showed LDR R3,ff0a0fc0 is load of r3 with address of the variable holding the stack address; this write is the str which I've now copied in below. IRQ_STACK_START_IN = gd-irq_sp + 8; ff0a0fb0: e5992044 ldr r2, [r9, #68] ; 0x44 ff0a0fb4: e2822008 add r2, r2, #8 ff0a0fb8: e5832000 str r2, [r3] For my target, IIRC the write to flash caused problem in the flash controller hardware, breaking further instruction fetches. On other platforms the write to flash may fail silently. But the issue is that interrupt_init() moving into board_init_f (i.e. before relocation) generally just doesn't work right. Joe Thanks Rob and Joe for the clarification. Indeed interrupt_init() cannot execute before relocation as it sets globals. Further, interrupt_init() uses globals to communicate with start.S. This should be changed. I understand that is because the interrupt handlers actually set the interrupt stack when they are invoked -- and that is unnecessary; stacks should be set up as soon as their addresses are known. I'll revert the patch as soon as I finish getting the current PRs in. I have a start.S rewrite effort underway whcuh I should post soon. I'll add to it a change to the way stacks are initialized. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/8] Provide a mechanism to avoid using #ifdef everywhere
Hi Wolfgang, On Wed, 06 Nov 2013 08:24:44 +0100, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message 1382800457-26608-1-git-send-email-...@chromium.org you wrote: Many parts of the U-Boot code base are sprinkled with #ifdefs. This makes different boards compile different versions of the source code, meaning that we must build all boards to check for failures. It is easy to misspell an #ifdef and there is not as much checking of this by the compiler. Multiple dependent #ifdefs are harder to do than with if..then..else. Variable declarations must be #idefed as well as the code that uses them, often much later in the file/function. #ifdef indents don't match code indents and have their own separate indent feature. Overall, excessive use of #idef hurts readability and makes the code harder to modify and refactor. For people coming newly into the code base, #ifdefs can be a big barrier. The use of #ifdef in U-Boot has possibly got a little out of hand. In an attempt to turn the tide, this series includes a patch which provides a way to make CONFIG macros available to C code without using the preprocessor. This makes it possible to use standard C conditional features such as if/then instead of #ifdef. A README update exhorts compliance. As mentioned before, I'm really interested in seeing something like this going into mainline, but I have some doubts about the actual implementation. To summarize: Your current proposal was to convert code snippets like this: #ifdef CONFIG_VERSION_VARIABLE setenv(ver, version_string); /* set version variable */ #endif into if (autoconf_version_variable()) setenv(ver, version_string); /* set version variable */ By chance I ran about include/linux/kconfig.h in the Linux kernel tree, which provides (among other things) the IS_ENABLED() macro that implements essentially the very same feature. Using this, the same code would be written as: if (IS_ENABLED(CONFIG_VERSION_VARIABLE)) setenv(ver, version_string); /* set version variable */ I agree that this does not solve some of the isses that have been raised about this change (indentation level increses - which may in turn require reformatting of bigger parts of the code; code becomes less readable), but on the other hand it avoids the need for a new autoconf header file, and it should be possible to introduce this easily step by step. And I really like the idea of re-using existing code that is already known to Linux hackers, especially as we we are currently having our eyes on the Kconfig stuff anyway. What do you think? Agreed on the whole -- plus, introducing indentation in configuration option testing will make it easier to spot and understand nested configuration conditionals. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] test
test -- Regards, Igor. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Hello all together, On 11/07/2013 09:17 AM, Heiko Schocher wrote: Am 06.11.2013 08:50, schrieb Wolfgang Denk: In message20131105203736.GM5925@bill-the-cat you wrote: snip problem description Full ACK, we need some way to track which board is working with the current ToT or at least on a release basis. So, the question raises, should we introduce a column in boards.cfg, which shows the livetime of a board support in U-Boot? I sense a lot of conflicting patches. Again I agree. Also, I fear that boards.cfg is becoming more and more unreadable by adding even more stuff. If I see this correctly, the maximum line length in boards.cfg already exceeds 360 characters :-( Right, boards.cfg gets unhandy ... Hmm .. what with the column Staus ... instead of Active it would be more informative to have there the livetime counter, and a single digit saves some characters ;-) I can't understand the status field at all, just for the record ;) But you are right, that approach leads in a lot of conflicting patches ... but I think, we just pooled board information in boards.cfg, so this would be the right place in my eyes ... Maybe we get such Information a Boards is tested with current mainline inform of an EMail with an Text Board xy tested with commit mm. Please update livetime ... and we can add a script, which updates the livetime for this board, so we can prevent conflicting patches ... ? I agree here with Tom. Beside the possibility of conflicting pahces I see another problem here. We will get a lot of patches just for increasing the tested counter for a single board. These patches needs to be handled in some way. If we shift to some integrated system (gerrit comes to mind) this could be easier than today, but it will bind resources anyways. Therefore I think it is a bad idea to save a such often changing information in the source code repository. So nstead of adding this information to boards.cfg we could probably use separate files for such information. We could provide tools to make test reports really easy, say something like scripts/build_test scripts/run_test which the user would just call with a passed or failed argument; the scripts could then auto-detect which configuration and which exact U-Boot version were in use, and send an email. Whether that would be a patch against the source code or something that get's auto-added to a wiki page is just an implementation detail. But if we had something like this, we could get a muchbetter understanding how actively boards are being tested. Yes, that sound also good. I want to see the test information in the sourcecode, not somewhere on a wiki... I think another place than the source code repository would be best for gathering such frequently changing information. Why not use some wiki other other web service for that purpose? I don't want to search a web page for the information 'board X is not tested since ...' either. But we could easily write some scripts and add them to the source code repository to provide it. So when you're once again doing some change that requires touching files for some othe rboards, you could simply check that database. If you see that 3 out of the last 5 releases have reported succesful run-time tests you will probably decide to accept the needed efforts, Hmm.. that works, if you have to touch some (some 5) boards. But If you have to touch 5 boards, this gets unhandy... How about: MAKEALL --check-boards -s at91 ;) but when you see the last test report is more than 5 years old, you will probably rather decide to initiate a code removal process. Why not save the SHA1 with the build-/runtime-tested information? Then we could easily build helper scripts to query that database when this board was last tested. If we decide to delete older boards after n release cycles without testreports, we must not decide nor look in a database. We are sure, we have only good and working boards ... and we just do the necessary work for new features ... and we are sure, that we get back testreports within n release cycles ... So let us decide first, if we want to go this way ... Yes, we should introduce some mechanism to check when a specific board was last runtime tested. But I fear the overhead with patches that update a tested counter. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 0/5] mtd: nand: omap: optimize and clean-up of OMAP NAND driver
Pekon, Please find the nand dumps from oob area below. UBIFS volume created and edited in Linux. Linux: OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff 5c 87 73 23 OOB Data: ae 36 a6 16 fc 81 dd 8e f0 ff ff ff ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff U-Boot: OOB: ff ff ff ff ff ff ff ff ff ff ff ff 90 df 27 b0 f7 8c db 4c 0e 76 25 7e a9 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Best regards, Matti 2013/11/7 matti kaasinen matti.kaasi...@gmail.com Hi Pekon, Thank you for your answers. Please find my answers/comments to your questions below. 2013/11/6 Gupta, Pekon pe...@ti.com Hi Matti and Matthias Sorry I was away from my mailbox so couldn't reply you earlier. I'm still away from my setup and other boards, so cannot replicate the issue below until early next week. But I'll surely do so asap.. However, please see my replies below, which might help you someway. From: matti kaasinen [mailto:matti.kaasi...@gmail.com] Hi Pekon, Thanks to Tom Rini's hint I have tried to execute your patch sets ( http://patchwork.ozlabs.org/project/uboot/list/?submitter=17320state=*) in order to get Linux and U-Boot working with same NAND flash. Set-up is pretty much like Mathias has before in this chain. Latest problem I faced with is that last versions of 1) [U-Boot,v8,3/5] mtd: nand: omap: optimize chip-ecc.calculate() for H/W ECC schemes and 2) [U-Boot,v2,2/3] mtd: nand: omap: add support for BCH16_ECC - NAND driver updates are not compatible any more. As I told in https://groups.google.com/forum/#!topic/beagleboard/7ofbE_Rrn_s versions v5..v7 of 1) could possibly be compatible. There is no change in ECC layout or other functional updates between v7 and v8 of this patch, so if there is any incompatibility then it would be in all versions of the patch.. I did not mean ECC layout-wisely incompatible but patching-wisely incompatible. Patching 2) v2 after 1) v8 stops to errors and it seems that with 1) v7 it could (possibly) succeed. Few questions.. (1) Which ECC scheme are you using ? Now I'm talking Linux 3.8.13 - U-Boot 10.04 combination that I have as currently as working environment. I have not managed getting above patches successfully through. - u-boot CONFIG_NAND_OMAP_ECCSCHEME as per doc/README.nand http://lists.denx.de/pipermail/u-boot/2013-October/164646.html U-Boot 10.04 does not seem to have such choices and in fact I have not selected it. - kernel OMAP_ECC_BCH8_CODE_HW OMAP_ECC_BCH8_CODE_HW_DETECTION_SW Or any other.. I believe OMAP_ECC_BCH8_CODE_HW gets selected with following options from kernel. CONFIG_MTD_NAND_OMAP2 CONFIG_MTD_NAND_OMAP_BCH CONFIG_MTD_NAND_OMAP_BCH8 ... and selecting following choice ti,nand-ecc-opt = bch8 in device tree. With these options boot process reports; [1.128154] enabling NAND BCH ecc with 8-bit correction [1.133985] ONFI param page 0 valid [1.137662] ONFI flash detected [1.140985] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08AAD), 256MiB, page size: 2048, OOB size: 64 First line seems coming from drivers/nand/mtd/omap2.c:omap3_init_bch that gets printed in this from only if OMAP_ECC_BCH8_CODE_HW == platform_data.ecc_opt I printed nand.ecc.layout.eccbytes = 52 ( from from drivers/nand/mtd/omap2.c:omap3_init_bch_tail ) and nand.ecc.layout-eccpos[] = 12..63 BTW it seems that similar layout has been defined in u-boot arch/arm/include/asm/arch-omap3/omap_gpmc.h There is one exception, though: eccbytes have been set 54 instead of 52 that seems to be in linux (and correct I suppose). (2) Is the problem related to incorrect read/write access to x16 NAND ? No using x8 NAND Or Is it incompatibility in ecc.layout ? You can check this by dumping raw nand page via 'nand dump' command from both u-boot and kernel. I'll try to check this (3) you should not pick BCH16 patch-series - because I have not rebased this patch, and re-tested since other base patch-series on which BCH16 will be build, is still not accepted. - Also BCH16 ecc scheme would work only for NAND device with pagesize=4K and oobsize=224. whereas current beaglebone capes have NAND device with pagesize=2K and oobsize=64, so you can only use BCH8 with current NAND capes (for now).. This is perfectly fine with me. This set seems to block patching. I need only BCH8 and if this patch set provides only BCH16 functionality and nothing else, I need not using it. 2013/11/1 Matthias Fuchs mfu...@ma-fu.de Hi Pekon, should I consider the U-Boot and Linux am335x NAND implementation to be compatible? So are the ECC schemes in a way identical that I can
Re: [U-Boot] Pull request: u-boot-imx
Hi Stefano, On Tue, 05 Nov 2013 15:23:19 +0100, Stefano Babic sba...@denx.de wrote: Hi Albert, please pull from u-boot-imx, thanks ! The following changes since commit 262f08d6ea18a62f827b8ccb60f355ca2eaf6e2b: zynq: Use arch_cpu_init() instead of lowlevel_init() (2013-10-17 08:34:45 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-imx.git master for you to fetch changes up to c93addb5635630847e8a33f6dba4afef78a6d180: wandboard: README: Include the quad version (2013-11-04 09:56:25 +0100) Anatolij Gustschin (1): imx_watchdog: do not soft-reset while watchdog init Christoph G. Baumann (1): ARM: mxs: Configure 2 Gbit DDR2 RAM for BG0900 Eric Nelson (1): i.MX6: nitrogen6x: fix erase size in 6x_upgrade.txt Fabio Estevam (5): udoo: Add initial support for mx6q udoo board ARM: mx5: Enable L2 cache mx5: lowlevel_init: Remove unused macro configs: imx: Make CONFIG_SYS_PROMPT uniform across FSL boards wandboard: README: Include the quad version Marek Vasut (4): ARM: mxs: tools: Use mkimage for BootStream generation ARM: mxs: Add PPC-AG BG0900 board ARM: mxs: Setup stack in JTAG mode ARM: mxs: Enable DCDC converter for battery boot Otavio Salvador (1): mx6: Remove PAD_CTL_DSE_120ohm from i.MX6DL's IPU1_DI0_PIN4 pin Pierre Aubert (1): mx6: compute PLL PFD frequencies rather than using defines Stefano Babic (1): Revert configs: imx: Make CONFIG_SYS_PROMPT uniform across FSL boards arch/arm/cpu/arm926ejs/mxs/Makefile | 11 +- arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg |4 +- arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg |4 +- arch/arm/cpu/arm926ejs/mxs/spl_power_init.c |2 + arch/arm/cpu/arm926ejs/mxs/start.S |9 ++ arch/arm/cpu/armv7/mx5/lowlevel_init.S | 12 +- arch/arm/cpu/armv7/mx6/clock.c | 56 +-- arch/arm/include/asm/arch-mx6/crm_regs.h | 11 -- arch/arm/include/asm/arch-mx6/mx6dl_pins.h |2 +- arch/arm/include/asm/arch-mxs/sys_proto.h|2 + board/boundary/nitrogen6x/6x_upgrade.txt |2 +- board/ppcag/bg0900/Makefile | 31 board/ppcag/bg0900/bg0900.c | 86 +++ board/ppcag/bg0900/spl_boot.c| 153 +++ board/udoo/Makefile | 26 board/udoo/udoo.c| 110 ++ board/wandboard/README |4 +- boards.cfg |2 + doc/README.mxs | 39 - drivers/watchdog/imx_watchdog.c |3 +- include/configs/bg0900.h | 97 include/configs/udoo.h | 206 ++ 22 files changed, 819 insertions(+), 53 deletions(-) create mode 100644 board/ppcag/bg0900/Makefile create mode 100644 board/ppcag/bg0900/bg0900.c create mode 100644 board/ppcag/bg0900/spl_boot.c create mode 100644 board/udoo/Makefile create mode 100644 board/udoo/udoo.c create mode 100644 include/configs/bg0900.h create mode 100644 include/configs/udoo.h Applied to u-boot-arm/master, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request - arm/zynq
Hi Michal, On Wed, 06 Nov 2013 09:28:16 +0100, Michal Simek mon...@monstr.eu wrote: Hi Albert, please pull these two patches to your arm next branch. It depends on zynq: Use arch_cpu_init() instead of lowlevel_init() (sha1: 262f08d6ea18a62f827b8ccb60f355ca2eaf6e2b) patch which you have in your branch that's why I have rebased them on the top. Thanks, Michal Is this really for 'next' and not 'master'? IOW, do you really mean it *not* to go into 2014.01? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Hello Andreas, Am 07.11.2013 10:37, schrieb Andreas Bießmann: Hello all together, On 11/07/2013 09:17 AM, Heiko Schocher wrote: Am 06.11.2013 08:50, schrieb Wolfgang Denk: In message20131105203736.GM5925@bill-the-cat you wrote: snip problem description Full ACK, we need some way to track which board is working with the current ToT or at least on a release basis. So, the question raises, should we introduce a column in boards.cfg, which shows the livetime of a board support in U-Boot? I sense a lot of conflicting patches. Again I agree. Also, I fear that boards.cfg is becoming more and more unreadable by adding even more stuff. If I see this correctly, the maximum line length in boards.cfg already exceeds 360 characters :-( Right, boards.cfg gets unhandy ... Hmm .. what with the column Staus ... instead of Active it would be more informative to have there the livetime counter, and a single digit saves some characters ;-) I can't understand the status field at all, just for the record ;) Hmm.. good question ... But you are right, that approach leads in a lot of conflicting patches ... but I think, we just pooled board information in boards.cfg, so this would be the right place in my eyes ... Maybe we get such Information a Boards is tested with current mainline inform of an EMail with an Text Board xy tested with commit mm. Please update livetime ... and we can add a script, which updates the livetime for this board, so we can prevent conflicting patches ... ? I agree here with Tom. Beside the possibility of conflicting pahces I see another problem here. We will get a lot of patches just for increasing the tested counter for a single board. These patches needs to be handled in some way. If we shift to some integrated system (gerrit comes to mind) this could be easier than today, but it will bind resources anyways. Therefore I think it is a bad idea to save a such often changing information in the source code repository. I see this info just changing once when releasing a new U-Boot version. I not see anymore a patch for updating the livetime counter for every board, instead we should have a script which a board maintainer can call, after he did a board test, which sends an EMail to the U-Boot ML with a special format, saying: subject: livetime: board name Tested-by: ... with commit ... On the mailserver a script scans all incoming EMails for his Subject, (Is this possible?) and collect the infos, for which boards, such EMails arrived. When releasing a new U-Boot version, this collected info can be used to update this livetime counter through another script saying collect_livetime_info (also this script can automatically send EMails to board maintainers, for boards which had reached end of livetime, outputs a delete board lists ...) So (in current case Tom) should, before releasing a new U-Boot version, first call this script collect_livetime_info and he get: - one livetime counter patch for current release - one list for boards which reach end of life - one list for boards, which should be deleted All Infos are release info I think, and fully fit in the commit for the new release ... ... maybe deleting boards can be done automatically, but this is not a trivial job ... So, with such a solution, I see no big additional cost for adding such a feature (except the task deleting old boards, which is maybe not trivial) Do not understand me wrong, if we find another solution, I am happy also ... just spinning around ... So nstead of adding this information to boards.cfg we could probably use separate files for such information. We could provide tools to make test reports really easy, say something like scripts/build_test scripts/run_test which the user would just call with a passed or failed argument; the scripts could then auto-detect which configuration and which exact U-Boot version were in use, and send an email. Whether that would be a patch against the source code or something that get's auto-added to a wiki page is just an implementation detail. But if we had something like this, we could get a muchbetter understanding how actively boards are being tested. Yes, that sound also good. I want to see the test information in the sourcecode, not somewhere on a wiki... I think another place than the source code repository would be best for gathering such frequently changing information. Why not use some wiki other other web service for that purpose? See above explanation, I see this info not frequently changing, just always with a new U-Boot release ... and can nearly (except the delete old boards case) automatised ... I don't want to search a web page for the information 'board X is not tested since ...' either. But we could easily write some scripts and add them to the source code repository to provide it. Ok, fine with me too. I just thinking about this problem, and
Re: [U-Boot] [PATCH 0/4] udoo: Improve stability of DDR3 setting
Hi Stefano, On Thu, 2013-11-07 at 09:12 +0100, Stefano Babic wrote: Hi Giuseppe, On 06/11/2013 21:30, Giuseppe Pagano wrote: Move udoo configuration files to board/udoo/ folder. Align clock configuration and DDR3 calibration to Seco suggested value to increase system stability. There are some basic issues with your patchset. First, patches are corrupted by your editor and/or by your mailer and cannot be applied. . Instead of generating the patches with diff, use git format-patch, and then submit the patches to the mailing list with git send-email. Sorry, I used vim and imported patch as a file in evolution, I understood too late that I also need to change Format from normal to preformatted. In the future I will use git send-email. Please take a look at the rules to submit patches : http://www.denx.de/wiki/U-Boot/Patches Sure, I read it, nevertheless I made lots of errors. This was my first submit..sorry Do not fix multiple issues in the same patch if not strictly needed. The commit message is misleading: you say you are moving the configuration files, but they are not moved (they can't because they belong to nitrogen) and new files are generated. Maybe I was wrong in writing move configuration files.. I think [PATCH 0/4] can be consider an atomical change: Fabio first uDoo support adopt nitrogenx register setting for DDR3, clock, muxing, etc uDoo schematics is rather different from nitrogen6x, and it needs customized setting for most of the register (as every platform). It takes too long describe every single new setting. Previous configuration was very unstable and adopting those settings uDoo board has frequently crash. Seco had validated new setting I'm going to propose using climatic room and various tests, which stressed system and cpu for about 7 days long cycles. I do not understand what you mean with Align clock configuration and DDR3 calibration to Seco suggested value. Please explain: which values are wrong, what you have fix with your patch. See above. If you make change to a board, you should send your patches in CC to the board maintainer, too (for udoo, Fabio: I put him in CC). Fabio was abreast of this changes, but not in cc. I'll use CC in next post. Signed-off-by: Giuseppe Pagano giuseppe.pag...@seco.com Cc: sba...@denx.de ... Best regards, Stefano Babic Best Regards, Giuseppe Pagano ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH 0/5] SATA support for OMAP5 uevm
+Aneesh. Hi Enric, On 11/07/2013 10:52 AM, Enric Balletbo Serra wrote: Hi Roger, Thanks for the patches! 2013/11/6 Roger Quadros rog...@ti.com: Hi, This series adds SATA support for OMAP5 uevm board. This is an RFC patchset for review only. Patches are based on v2013.10. cheers, -roger --- Roger Quadros (5): ahci: Error out with message on malloc() failure ARM: OMAP5: Add Pipe3 PHY driver ARM: OMAP5: Add PRCM and Control information for SATA ARM: OMAP5: Add SATA platform glue ARM: omap5_uevm: Add SATA support arch/arm/cpu/armv7/omap-common/Makefile| 7 + arch/arm/cpu/armv7/omap-common/pipe3-phy.c | 233 + arch/arm/cpu/armv7/omap-common/pipe3-phy.h | 36 + arch/arm/cpu/armv7/omap-common/sata.c | 78 ++ arch/arm/cpu/armv7/omap5/prcm-regs.c | 5 + arch/arm/include/asm/arch-omap5/clock.h| 3 + arch/arm/include/asm/arch-omap5/omap.h | 3 + arch/arm/include/asm/arch-omap5/sata.h | 48 ++ arch/arm/include/asm/omap_common.h | 3 + board/ti/omap5_uevm/evm.c | 7 + drivers/block/ahci.c | 16 +- include/configs/omap5_uevm.h | 10 ++ 12 files changed, 447 insertions(+), 2 deletions(-) create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.c create mode 100644 arch/arm/cpu/armv7/omap-common/pipe3-phy.h create mode 100644 arch/arm/cpu/armv7/omap-common/sata.c create mode 100644 arch/arm/include/asm/arch-omap5/sata.h -- 1.8.3.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot I applied your patches and worked perfectly, however I've two small issues. The first issue is that I see the following error: scanning bus for devices... ERROR: v7_dcache_inval_range - start address is not aligned - 0xfee48618 ERROR: v7_dcache_inval_range - stop address is not aligned - 0xfee48818 I'm seeing this too. Not sure how to fix it. Aneesh, any pointers? The second issue, and I'm not sure if the problem should be solved at u-boot level, is that I'm not able to access to the SATA disk at kernel level. I meant, if I boot to the system with latest stable u-boot the kernel recognizes the SATA disk and I'm able to mount, read and write to the disk. If I boot using u-boot with your patches applied the kernel doesn't recognizes the SATA disk and doesn't work. In that case the kernel reports the following error: ata1: COMRESET failed (errno=-16) Note that the kernel version that I'm using is 3.8.13 from git.ti.com. There is a known issue with the SATA DPLL 1.52 SATA Lockup After SATA DPLL Unlock/Relock - Errata ID: i783 So, we'll need to do something in the kernel before these patches get into u-boot. I'll try to come up with a solution soon. Something on the lines of not re-initializing the SATA DPLL if it is already locked. cheers, -roger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] udoo: Improve stability of DDR3 setting
Hi Giuseppe, On 07/11/2013 11:41, Giuseppe Pagano wrote: Sorry, I used vim and imported patch as a file in evolution, I understood too late that I also need to change Format from normal to preformatted. In the future I will use git send-email. Ok Please take a look at the rules to submit patches : http://www.denx.de/wiki/U-Boot/Patches Sure, I read it, nevertheless I made lots of errors. This was my first submit..sorry No problem ;-) Do not fix multiple issues in the same patch if not strictly needed. The commit message is misleading: you say you are moving the configuration files, but they are not moved (they can't because they belong to nitrogen) and new files are generated. Maybe I was wrong in writing move configuration files.. I think [PATCH 0/4] can be consider an atomical change: Fabio first uDoo support adopt nitrogenx register setting for DDR3, clock, muxing, etc uDoo schematics is rather different from nitrogen6x, and it needs customized setting for most of the register (as every platform). It takes too long describe every single new setting. Previous configuration was very unstable and adopting those settings uDoo board has frequently crash. Ok - this is an explanation that can be simply added to the commit message. If you make change to a board, you should send your patches in CC to the board maintainer, too (for udoo, Fabio: I put him in CC). Fabio was abreast of this changes, but not in cc. I'll use CC in next post. Thanks ! Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Hi Heiko, On Thu, 07 Nov 2013 11:39:08 +0100, Heiko Schocher h...@denx.de wrote: Right, boards.cfg gets unhandy ... Hmm .. what with the column Staus ... instead of Active it would be more informative to have there the livetime counter, and a single digit saves some characters ;-) I'm not sure we need to save characters from boards.cfg. Note also that one goal of boards.cfg is to not have multiple files around that have to remain consistent. Still : I can't understand the status field at all, just for the record ;) Hmm.. good question ... There has been some discussion on this already; indeed, the status field is not really aptly named or defined and should be reworked. We could, for instance, have a Last tested field instead of the Active field. Ok, two decisions: - Do we want to collect board testinginformation? I'd say we might want to, if only because it tells us if a board maintainer is still active or not, instead of finding out long later. - Do we want to delete old boards automatically after we do not get some test reports after a time intervall? I don't, at least, not without a long enough period during which the board remains in unmaintained state. E.g., for each release, the list of unmaintained boards is produced along with the release notes, and boards which are still unmaintained when nearing the next release (roughly 90 days later) get deleted right before the new release. bye, Heiko Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Hello Heiko, On 11/07/2013 11:39 AM, Heiko Schocher wrote: Am 07.11.2013 10:37, schrieb Andreas Bießmann: On 11/07/2013 09:17 AM, Heiko Schocher wrote: Am 06.11.2013 08:50, schrieb Wolfgang Denk: In message20131105203736.GM5925@bill-the-cat you wrote: snip But you are right, that approach leads in a lot of conflicting patches ... but I think, we just pooled board information in boards.cfg, so this would be the right place in my eyes ... Maybe we get such Information a Boards is tested with current mainline inform of an EMail with an Text Board xy tested with commit mm. Please update livetime ... and we can add a script, which updates the livetime for this board, so we can prevent conflicting patches ... ? I agree here with Tom. Beside the possibility of conflicting pahces I see another problem here. We will get a lot of patches just for increasing the tested counter for a single board. These patches needs to be handled in some way. If we shift to some integrated system (gerrit comes to mind) this could be easier than today, but it will bind resources anyways. Therefore I think it is a bad idea to save a such often changing information in the source code repository. I see this info just changing once when releasing a new U-Boot version. The saved information how often a board was runtime tested with the correct SHA1 of the u-boot/master could be quite useful. In the end just the last tested commit will be interesting but it could give some information how often that specific board is used. The information must not be generated by a board maintainer ... the maintainer could then see if he needs to pull out a board or if one else run the test before. If we would save this in the repository we do not have this information in time. If we send the information to a list we need to parse it or use some other tool to provide the information. Beside that we will pollute the list with status updates about boards being tested. It could be hard to find real patches in that information flood then. snip mail proposal So (in current case Tom) should, before releasing a new U-Boot version, first call this script collect_livetime_info and he get: - one livetime counter patch for current release - one list for boards which reach end of life - one list for boards, which should be deleted Good idea, but the information could also be saved on a website or in another database. It should be easily filled by the tester and also easily queried by wherever is interested in. All Infos are release info I think, and fully fit in the commit for the new release ... I also think that should be done on release only. ... maybe deleting boards can be done automatically, but this is not a trivial job ... I think deleting should be done in next release then to give the board maintainer some time to check the boards. On a new release the board maintainer should be mailed that in the next release the board will be removed. We should also store this somewhere in the code (status in boards.cfg?). Next question is what to do if the mail bounces ;) So, with such a solution, I see no big additional cost for adding such a feature (except the task deleting old boards, which is maybe not trivial) Do not understand me wrong, if we find another solution, I am happy also ... just spinning around ... Me too. snip If we decide to delete older boards after n release cycles without testreports, we must not decide nor look in a database. We are sure, we have only good and working boards ... and we just do the necessary work for new features ... and we are sure, that we get back testreports within n release cycles ... So let us decide first, if we want to go this way ... Yes, we should introduce some mechanism to check when a specific board was last runtime tested. But I fear the overhead with patches that update a tested counter. I thought with decide: Do we want to delete old boards? With this, we do not need a MAKEALL --check-boards -s at91 when we introduce new features, as all boards in mainline are in a well tested shape ... Ok, two decisions: - Do we want to collect board testinginformation? I think we should do that i none way or another. - Do we want to delete old boards automatically after we do not get some test reports after a time intervall? And we should delete 'unmaintained' boards, when is to be discussed. I'm currently fiddling with at91 gpio and ask myself if I should adopt all the boards or just let them fail ... Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Hello Albert, Am 07.11.2013 12:13, schrieb Albert ARIBAUD: Hi Heiko, On Thu, 07 Nov 2013 11:39:08 +0100, Heiko Schocherh...@denx.de wrote: Right, boards.cfg gets unhandy ... Hmm .. what with the column Staus ... instead of Active it would be more informative to have there the livetime counter, and a single digit saves some characters ;-) I'm not sure we need to save characters from boards.cfg. Note also that one goal of boards.cfg is to not have multiple files around that have to remain consistent. Yep, exactly. Thats why I think we could collect this in boards.cfg. Still : I can't understand the status field at all, just for the record ;) Hmm.. good question ... There has been some discussion on this already; indeed, the status field is not really aptly named or defined and should be reworked. We could, for instance, have a Last tested field instead of the Active field. Yep. Ok, two decisions: - Do we want to collect board testinginformation? I'd say we might want to, if only because it tells us if a board maintainer is still active or not, instead of finding out long later. Yes. - Do we want to delete old boards automatically after we do not get some test reports after a time intervall? I don't, at least, not without a long enough period during which the board remains in unmaintained state. E.g., for each release, the list of unmaintained boards is produced along with the release notes, and boards which are still unmaintained when nearing the next release (roughly 90 days later) get deleted right before the new release. I proposed: livetime = 4 releases cycle without testing If livetime = 0 - EMail to board maintainer, please test or board get deleted. If livetime -1 - board deleted bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Hello Andreas, Am 07.11.2013 12:24, schrieb Andreas Bießmann: Hello Heiko, On 11/07/2013 11:39 AM, Heiko Schocher wrote: Am 07.11.2013 10:37, schrieb Andreas Bießmann: On 11/07/2013 09:17 AM, Heiko Schocher wrote: Am 06.11.2013 08:50, schrieb Wolfgang Denk: In message20131105203736.GM5925@bill-the-catyou wrote: snip But you are right, that approach leads in a lot of conflicting patches ... but I think, we just pooled board information in boards.cfg, so this would be the right place in my eyes ... Maybe we get such Information a Boards is tested with current mainline inform of an EMail with an Text Board xy tested with commit mm. Please update livetime ... and we can add a script, which updates the livetime for this board, so we can prevent conflicting patches ... ? I agree here with Tom. Beside the possibility of conflicting pahces I see another problem here. We will get a lot of patches just for increasing the tested counter for a single board. These patches needs to be handled in some way. If we shift to some integrated system (gerrit comes to mind) this could be easier than today, but it will bind resources anyways. Therefore I think it is a bad idea to save a such often changing information in the source code repository. I see this info just changing once when releasing a new U-Boot version. The saved information how often a board was runtime tested with the correct SHA1 of the u-boot/master could be quite useful. In the end just the last tested commit will be interesting but it could give some information how often that specific board is used. The information must not be generated by a board maintainer ... the maintainer could then see if he needs to pull out a board or if one else run the test before. If we would save this in the repository we do not have this information in time. If we send the information to a list we need to parse it or use some other tool to provide the information. Beside that we will pollute the list with status updates about boards being tested. It could be hard to find real patches in that information flood then. Hmm... I hope we get a lot of such EMails ... and think, this is not a big problem ... Or, maybe, if we get a lot of such EMails, maybe we open a u-boot-testing list? snip mail proposal So (in current case Tom) should, before releasing a new U-Boot version, first call this script collect_livetime_info and he get: - one livetime counter patch for current release - one list for boards which reach end of life - one list for boards, which should be deleted Good idea, but the information could also be saved on a website or in another database. It should be easily filled by the tester and also easily queried by wherever is interested in. Ok, if we have this info, we can show it wherever we want ... All Infos are release info I think, and fully fit in the commit for the new release ... I also think that should be done on release only. Yep! But collecting this infos can be done all the time. ... maybe deleting boards can be done automatically, but this is not a trivial job ... I think deleting should be done in next release then to give the board maintainer some time to check the boards. On a new release the board maintainer should be mailed that in the next release the board will be removed. We should also store this somewhere in the code (status in boards.cfg?). See my proposal for the livetime counter: livetime init value n (n=4) livetimer decrement on every new release livetimer set to n, if in release cycle comes a test report livetimer == 0 - EMail to board maintainer, board reached end of live in mainline, please send test report. livetimer == -1 - board get deleted So all info is in boards.cfg availiable ... Next question is what to do if the mail bounces ;) Board gets deleted, as board maintainer didn;t send an update patch for boards.cfg ... So, with such a solution, I see no big additional cost for adding such a feature (except the task deleting old boards, which is maybe not trivial) Do not understand me wrong, if we find another solution, I am happy also ... just spinning around ... Me too. snip If we decide to delete older boards after n release cycles without testreports, we must not decide nor look in a database. We are sure, we have only good and working boards ... and we just do the necessary work for new features ... and we are sure, that we get back testreports within n release cycles ... So let us decide first, if we want to go this way ... Yes, we should introduce some mechanism to check when a specific board was last runtime tested. But I fear the overhead with patches that update a tested counter. I thought with decide: Do we want to delete old boards? With this, we do not need a MAKEALL --check-boards -s at91 when we introduce new features, as all boards in mainline are in a well tested shape ... Ok, two decisions: - Do we want to collect board
Re: [U-Boot] Pull request - arm/zynq
Hi Albert, On 11/07/2013 10:50 AM, Albert ARIBAUD wrote: Hi Michal, On Wed, 06 Nov 2013 09:28:16 +0100, Michal Simek mon...@monstr.eu wrote: Hi Albert, please pull these two patches to your arm next branch. It depends on zynq: Use arch_cpu_init() instead of lowlevel_init() (sha1: 262f08d6ea18a62f827b8ccb60f355ca2eaf6e2b) patch which you have in your branch that's why I have rebased them on the top. Thanks, Michal Is this really for 'next' and not 'master'? IOW, do you really mean it *not* to go into 2014.01? Every maintainer has different strategies for branches. But anyway, I want to add these patches/fixes to the 2014.01. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] udoo: fix watchdog setting
Hi Stefano, On Thu, 2013-11-07 at 09:19 +0100, Stefano Babic wrote: Hi Giuseppe, On 06/11/2013 21:44, Giuseppe Pagano wrote: To have watchdog quiet during kernel boot it is necessary to change gpio wdt trigger direction. Sorry, this is not a good explanation. You force a GPIO to drop a feture, instead of disabling the feature itself. And maybe some other people want to have this feature enabled. Which is the timeout for the watchdog ? Why is it hitting too soon ? Fix should be not done simply removing the effect, but checking the cause. I know, my explanation was poor. uDoo use APX823-31W5 as watchdog chip. Timeout is about 1.2 seconds. To disabled watchdog during kernel boot, WDI pin of that chip needs to be in high impedance state. As far as I known mx6 gpio configuration does not contemplate tristate, so the option I choose is to set pin as input and in high impedance. If wdt gpio is leaved as output che chip resets. Best regards, Stefano Babic Best regards, Giuseppe Pagano ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] udoo: Adjust default boot envirnment
Hi Stefano, On Thu, 2013-11-07 at 09:33 +0100, Stefano Babic wrote: Hi Giuseppe, On 06/11/2013 21:44, Giuseppe Pagano wrote: Change u-boot default environment for uDoo board to: - mount /dev/mmcblk0p1 partition - activate hdmi monitor by default (instead of nothing) Signed-off-by: Giuseppe Pagano giuseppe.pag...@seco.com Cc: sba...@denx.de I have already explained my doubts regarding the abuse of EXTRA_ENV_SETTINGS. The setup that should be minimal and general for most of uses is then customized for a specific scope, that conflict with other goals. Ok I will leave unchanged default environment. @@ -189,7 +190,7 @@ /* Miscellaneous configurable options */ #define CONFIG_SYS_LONGHELP #define CONFIG_SYS_HUSH_PARSER -#define CONFIG_SYS_PROMPT = +#define CONFIG_SYS_PROMPT uDoo board #define CONFIG_AUTO_COMPLETE #define CONFIG_SYS_CBSIZE 256 We had already some discussion on the mailing list about the meaning and the usefulness of the U-Boot prompt. I will apply a patch for all Freescale boards that remove a custom prompt, letting the default. Which is the improvement to have a custom prompt ? And also I will leave unchanged u-boot prompt. I think I will support Simon idea, I think it is useful to recognize uboot console prompt if you have more than one serial console connected to your host. Maybe you are the second one asking for the feature: http://u-boot.10912.n7.nabble.com/Changing-CONFIG-SYS-PROMPT-on-the-fly-td166105.html As suggested by Simon (take a look at the whole thread), it is then better to set the prompt from an environment variable. Feel free to submit a patch for it. Best regards, Stefano Babic Best regards, Giuseppe Pagano ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Dear Andreas Bießmann, In message 527b7883.1080...@gmail.com you wrote: The saved information how often a board was runtime tested with the correct SHA1 of the u-boot/master could be quite useful. In the end just the last tested commit will be interesting but it could give some information how often that specific board is used. The information must not be generated by a board maintainer ... the s/must not/need not/ (faux ami in action, I guess) maintainer could then see if he needs to pull out a board or if one else run the test before. I fully agree - everybody should be able to provide such test information. Actually it would be a big help to board maintainers as well if these would get test reports from actual users of the hardware. If we would save this in the repository we do not have this information in time. If we send the information to a list we need to parse it or use some other tool to provide the information. Beside that we will pollute the list with status updates about boards being tested. It could be hard to find real patches in that information flood then. Agreed too. I doubt if a mailing list makes sense to collect such data. It would probably be more efficient to provide a web based service for this. It just has to be easy to submit reports, and to query the status for boards. - one livetime counter patch for current release - one list for boards which reach end of life - one list for boards, which should be deleted Good idea, but the information could also be saved on a website or in another database. It should be easily filled by the tester and also easily queried by wherever is interested in. Agreed. I definitely do not want to see such trafic on the regular U-Boot mailing list. All Infos are release info I think, and fully fit in the commit for the new release ... I also think that should be done on release only. Why? To me it makes a lot of sense to also collect information on intermediate snapshots. I think deleting should be done in next release then to give the board maintainer some time to check the boards. On a new release the board maintainer should be mailed that in the next release the board will be removed. We should also store this somewhere in the code (status in boards.cfg?). Next question is what to do if the mail bounces ;) Mail bounces (and new address of maintainer cannot be found, and no other user volunteers to take over maintenance) = board is unmaintained = board gets removed. - Do we want to delete old boards automatically after we do not get some test reports after a time intervall? And we should delete 'unmaintained' boards, when is to be discussed. I'm currently fiddling with at91 gpio and ask myself if I should adopt all the boards or just let them fail ... I hesitate to automatically remove existing boards. Why would we want to do that? To reduce efforts, right? So I vote to keep boards as long as they are either maintained, or they at least do not hurt. If a board just builds fine and does not cause any additional efforts we should keep it, no matter if there is an active maintainer or test reports or not. Only when a board becomes a pain to somebody - say, because it develops build errors, or wit would require efforts to adapt it to some new feature, _then_ we would check if this is one of the precious boards we want to keep or if it is just old cruft nobody cares about anyway. And only then I would remove it. 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 Simplicity boils down to two steps: Identify the essential. Eliminate the rest. - Leo Babauta ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Dear Heiko Schocher, In message 527b7cb0.6040...@denx.de you wrote: Note also that one goal of boards.cfg is to not have multiple files around that have to remain consistent. Yep, exactly. Thats why I think we could collect this in boards.cfg. No, we really want to have a database here, which collects more than just a timestamp. I would lile to be able to see the history as well as information which exact commit ID has been tested (and I strongly vote to allow testing at any time, not only for a end-of-release- cycle version). we should probably also collect information about the build environment (at least versions of make, gcc, bintuils), etc. This by far exceeds what could be done in boards.cfg, and it exceeds anything that could be run over the mailing list. 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 important thing about being a leader is not being right or wrong, but being *certain*.- Terry Pratchett, _Truckers_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Dear Heiko, In message 527b7ee6.4030...@denx.de you wrote: Hmm... I hope we get a lot of such EMails ... and think, this is not a big problem ... Or, maybe, if we get a lot of such EMails, maybe we open a u-boot-testing list? NAK. Mailing lists are good for some kind of information - especially for such information that is read by humans. All you want to do here is feed a database with data. This is not what mailing lists were made for, so we should really use a more appropriate interface. See my proposal for the livetime counter: livetime init value n (n=4) livetimer decrement on every new release livetimer set to n, if in release cycle comes a test report livetimer == 0 - EMail to board maintainer, board reached end of live in mainline, please send test report. livetimer == -1 - board get deleted This is too simple in one respect (as you are not including information that may be vital, like which exact commit ID has been tested, or which tool chain has been used to build it). Also we should probably not only allow for positive test reports, but also allow to report failures (to mark board support as broken). All this cannot be done in boards.cfg . And there is no need to as long as we provide tools to query for any information we might be interested in. 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 Every living thing wants to survive. -- Spock, The Ultimate Computer, stardate 4731.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Dear Wolfgang Denk, On 11/07/2013 01:01 PM, Wolfgang Denk wrote: In message 527b7883.1080...@gmail.com you wrote: The saved information how often a board was runtime tested with the correct SHA1 of the u-boot/master could be quite useful. In the end just the last tested commit will be interesting but it could give some information how often that specific board is used. The information must not be generated by a board maintainer ... the s/must not/need not/ (faux ami in action, I guess) You're right snip All Infos are release info I think, and fully fit in the commit for the new release ... I also think that should be done on release only. Why? To me it makes a lot of sense to also collect information on intermediate snapshots. Well, I think we should query that database on release and transform the testing information to some information maybe stored in release code and to trigger board maintainers to do tests. Maybe the proposed lifetime counter is the correct tooling here. We should introduce some service to gather testing information which should have quite high throughput. But we should also install some measures to see the 'liveliness' of some board's tests in the released source code. I think deleting should be done in next release then to give the board maintainer some time to check the boards. On a new release the board maintainer should be mailed that in the next release the board will be removed. We should also store this somewhere in the code (status in boards.cfg?). Next question is what to do if the mail bounces ;) Mail bounces (and new address of maintainer cannot be found, and no other user volunteers to take over maintenance) = board is unmaintained = board gets removed. Sounds good, but doesn't fit to your next statement ... - Do we want to delete old boards automatically after we do not get some test reports after a time intervall? And we should delete 'unmaintained' boards, when is to be discussed. I'm currently fiddling with at91 gpio and ask myself if I should adopt all the boards or just let them fail ... I hesitate to automatically remove existing boards. Why would we want to do that? To reduce efforts, right? So I vote to keep boards as long as they are either maintained, or they at least do not hurt. If a board just builds fine and does not cause any additional efforts we should keep it, no matter if there is an active maintainer or test reports or not. Only when a board becomes a pain to somebody - say, because it develops build errors, or wit would require efforts to adapt it to some new feature, _then_ we would check if this is one of the precious boards we want to keep or if it is just old cruft nobody cares about anyway. And only then I would remove it. Sounds good. Best regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Hello Wolfgang, Am 07.11.2013 13:06, schrieb Wolfgang Denk: Dear Heiko Schocher, In message527b7cb0.6040...@denx.de you wrote: Note also that one goal of boards.cfg is to not have multiple files around that have to remain consistent. Yep, exactly. Thats why I think we could collect this in boards.cfg. No, we really want to have a database here, which collects more than just a timestamp. I would lile to be able to see the history as well as information which exact commit ID has been tested (and I strongly vote to allow testing at any time, not only for a end-of-release- cycle version). we should probably also collect information about the build environment (at least versions of make, gcc, bintuils), etc. This by far exceeds what could be done in boards.cfg, and it exceeds anything that could be run over the mailing list. Ok, if we need all such information, it breaks boards.cfg, correct. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] ARM: OMAP5: Add Pipe3 PHY driver
On 11/06/2013 11:48 PM, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/06/2013 09:47 AM, Roger Quadros wrote: Pipe3 PHY is used by SATA, USB3 and PCIe modules. This is a driver for the Pipe3 PHY. Signed-off-by: Roger Quadros rog...@ti.com [snip] +#define perror(fmt, args...) printf(%s: fmt, __func__ , ##args) Please use the debug macro. But I want the message to be printed and not hidden if DEBUG is not defined. [snip[ +perror(%s: No DPLL configuration for %u Hz SYS CLK\n, +__func__, rate); Indent is wrong, we do like the kernel (and checkpatch.pl is in tools/ and will catch these). Thanks. you mean the function arguments '__func__' and 'rate' should be on the same line where perror is? cheers, -roger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] ARM: OMAP5: Add SATA platform glue
On 11/07/2013 12:11 AM, Tom Rini wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/06/2013 09:47 AM, Roger Quadros wrote: Add platform glue logic for the SATA controller. Signed-off-by: Roger Quadros rog...@ti.com [snip] diff --git a/arch/arm/cpu/armv7/omap-common/Makefile b/arch/arm/cpu/armv7/omap-common/Makefile index 6e4a0f0..0535b62 100644 --- a/arch/arm/cpu/armv7/omap-common/Makefile +++ b/arch/arm/cpu/armv7/omap-common/Makefile @@ -23,6 +23,9 @@ endif ifneq ($(CONFIG_OMAP54XX),) COBJS += pipe3-phy.o +ifdef CONFIG_SCSI_AHCI_PLAT +COBJS += sata.o +endif This should be: COBJS-$(CONFIG_SCSI_AHCI_PLAT) += sata.o, or obj-... with the recent changes. OK. endif ifeq ($(CONFIG_OMAP34XX),) diff --git a/arch/arm/cpu/armv7/omap-common/sata.c b/arch/arm/cpu/armv7/omap-common/sata.c new file mode 100644 index 000..eb079c3 --- /dev/null +++ b/arch/arm/cpu/armv7/omap-common/sata.c [snip] +#if defined(CONFIG_SCSI_AHCI_PLAT) The file already depends on this symbol to be built at all. Right. cheers, -roger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] udoo: Add Ethernet support.
Hi Stefano,
On Thu, 2013-11-07 at 09:38 +0100, Stefano Babic wrote:
Hi Giuseppe,
On 06/11/2013 21:33, Giuseppe Pagano wrote:
Add Ethernet and networking support on uDoo board (FEC + phy Micrel)
Signed-off-by: Giuseppe Pagano giuseppe.pag...@seco.com
Cc: sba...@denx.de
+int mx6_rgmii_rework(struct phy_device *phydev)
+{
+ /* To advertise only 10 Mbs */
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x4, 0x61);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x9, 0x0c00);
+
Why only 10 Mb/s ? I think the Micrel 9031 allows 1Gb/s.
I will check again, I remember this solves an issue present also in
sabrelite board; but not sure. Maybe we can remove.
Generally, use defines instead of hard coded values.
Ok
+ /* min rx data delay */
+ ksz9021_phy_extended_write(phydev,
+ MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW, 0x0);
Is is 9021 or 9031 ?
uDoo adopt a Micrel KSZ9031 phy.
Most of the register address are common to ksz9021 and ksz9031, and have
the same value. Maybe we should rename some variable to MII_KSZ90XX_...
+
+ gpio_set_value(IMX_GPIO_NR(3, 23), 1); /* SABRE Lite PHY rst */
SABRE as comment is maybe wrong
+#define CONFIG_PHY_MICREL_KSZ9021
Ok, it is 9021 - please be consistent with the comments avoiding mixing
9031 and 9021.
No, it is 9031. I will create a new define.
Best regards,
Stefano Babic
Best regards,
Giuseppe Pagano
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] hash.c: Correct non-hash subcommand crc32 addr-save support
In the case of not having CONFIG_CMD_HASH but having CONFIG_CMD_CRC32
enabled (and not CONFIG_CRC32_VERIFY), we end up in this part of the
code path on hash_command(). However, we will only have exactly 3 args
here, and 3 3 is false, and we will not try and store the hash at the
address given as arg #3. The next problem however is that we've been
moving argv around so the third value is now in argv[0] not argv[3].
Confirmed on AM335x Beaglebone White.
Signed-off-by: Tom Rini tr...@ti.com
---
common/hash.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/hash.c b/common/hash.c
index 722c40b..872cd85 100644
--- a/common/hash.c
+++ b/common/hash.c
@@ -325,8 +325,8 @@ int hash_command(const char *algo_name, int flags,
cmd_tbl_t *cmdtp, int flag,
printf(CRC32 for %08lx ... %08lx == %08lx\n,
addr, addr + len - 1, crc);
- if (argc 3) {
- ptr = (ulong *)simple_strtoul(argv[3], NULL, 16);
+ if (argc = 3) {
+ ptr = (ulong *)simple_strtoul(argv[0], NULL, 16);
*ptr = crc;
}
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] udoo: Add SATA disk support.
On Thu, 2013-11-07 at 09:40 +0100, Stefano Babic wrote:
Hi Giuseppe,
On 06/11/2013 21:37, Giuseppe Pagano wrote:
Add Sata support on uDoo Board.
Signed-off-by: Giuseppe Pagano giuseppe.pag...@seco.com
Cc: sba...@denx.de
---
+#ifdef CONFIG_CMD_SATA
+int setup_sata(void)
+{
+ struct iomuxc_base_regs *const iomuxc_regs
+ = (struct iomuxc_base_regs *)IOMUXC_BASE_ADDR;
+
+ int ret = enable_sata_clock();
+ if (ret)
+ return ret;
+
+ clrsetbits_le32(iomuxc_regs-gpr[13],
+ IOMUXC_GPR13_SATA_MASK,
+ IOMUXC_GPR13_SATA_PHY_8_RXEQ_3P0DB
+ |IOMUXC_GPR13_SATA_PHY_7_SATA2M
+ |IOMUXC_GPR13_SATA_SPEED_3G
+ |(3IOMUXC_GPR13_SATA_PHY_6_SHIFT)
+ |IOMUXC_GPR13_SATA_SATA_PHY_5_SS_DISABLED
+ |IOMUXC_GPR13_SATA_SATA_PHY_4_ATTEN_9_16
+ |IOMUXC_GPR13_SATA_PHY_3_TXBOOST_0P00_DB
+ |IOMUXC_GPR13_SATA_PHY_2_TX_1P104V
+ |IOMUXC_GPR13_SATA_PHY_1_SLOW);
+
+ return 0;
+}
+#endif
Do not copy code ! If you want to reuse functions from nitrogen, please
factorize the function and put it into imx-common, thanks.
Ok, I'll do.
I'm going to produce a new udoo patch with git send-patch and I'll
submit as v2 of this one.
Best regards,
Stefano Babic
Best regards,
Giuseppe Pagano
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 0/5] mtd: nand: omap: optimize and clean-up of OMAP NAND driver
Hi Pekon, It seems after patching without BCH16 patches that at least OMAP_ECC_BCH8_CODE_HW can't be compatible with Linux 3.8.13 mode. U-Boot drivers/mtd/nand/omap_gpmc.c:omap_select_ecc_scheme states that nand-ecc.bytes = 14 whereas in OMAP_ECC_BCH8_CODE_HW_DETECTION_SW mode setting seems to be 13. Therefore, OMAP_ECC_BCH8_CODE_HW_DETECTION_SW could possibly be compatible. I have not got change to try it, though as I do have Angstrom related problems (I need to fix license path/md5 checksum to get build pass). -Matti 2013/11/7 matti kaasinen matti.kaasi...@gmail.com Pekon, Please find the nand dumps from oob area below. UBIFS volume created and edited in Linux. Linux: OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff 5c 87 73 23 OOB Data: ae 36 a6 16 fc 81 dd 8e f0 ff ff ff ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff OOB Data: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff U-Boot: OOB: ff ff ff ff ff ff ff ff ff ff ff ff 90 df 27 b0 f7 8c db 4c 0e 76 25 7e a9 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Best regards, Matti 2013/11/7 matti kaasinen matti.kaasi...@gmail.com Hi Pekon, Thank you for your answers. Please find my answers/comments to your questions below. 2013/11/6 Gupta, Pekon pe...@ti.com Hi Matti and Matthias Sorry I was away from my mailbox so couldn't reply you earlier. I'm still away from my setup and other boards, so cannot replicate the issue below until early next week. But I'll surely do so asap.. However, please see my replies below, which might help you someway. From: matti kaasinen [mailto:matti.kaasi...@gmail.com] Hi Pekon, Thanks to Tom Rini's hint I have tried to execute your patch sets ( http://patchwork.ozlabs.org/project/uboot/list/?submitter=17320state=*) in order to get Linux and U-Boot working with same NAND flash. Set-up is pretty much like Mathias has before in this chain. Latest problem I faced with is that last versions of 1) [U-Boot,v8,3/5] mtd: nand: omap: optimize chip-ecc.calculate() for H/W ECC schemes and 2) [U-Boot,v2,2/3] mtd: nand: omap: add support for BCH16_ECC - NAND driver updates are not compatible any more. As I told in https://groups.google.com/forum/#!topic/beagleboard/7ofbE_Rrn_s versions v5..v7 of 1) could possibly be compatible. There is no change in ECC layout or other functional updates between v7 and v8 of this patch, so if there is any incompatibility then it would be in all versions of the patch.. I did not mean ECC layout-wisely incompatible but patching-wisely incompatible. Patching 2) v2 after 1) v8 stops to errors and it seems that with 1) v7 it could (possibly) succeed. Few questions.. (1) Which ECC scheme are you using ? Now I'm talking Linux 3.8.13 - U-Boot 10.04 combination that I have as currently as working environment. I have not managed getting above patches successfully through. - u-boot CONFIG_NAND_OMAP_ECCSCHEME as per doc/README.nand http://lists.denx.de/pipermail/u-boot/2013-October/164646.html U-Boot 10.04 does not seem to have such choices and in fact I have not selected it. - kernel OMAP_ECC_BCH8_CODE_HW OMAP_ECC_BCH8_CODE_HW_DETECTION_SW Or any other.. I believe OMAP_ECC_BCH8_CODE_HW gets selected with following options from kernel. CONFIG_MTD_NAND_OMAP2 CONFIG_MTD_NAND_OMAP_BCH CONFIG_MTD_NAND_OMAP_BCH8 ... and selecting following choice ti,nand-ecc-opt = bch8 in device tree. With these options boot process reports; [1.128154] enabling NAND BCH ecc with 8-bit correction [1.133985] ONFI param page 0 valid [1.137662] ONFI flash detected [1.140985] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron MT29F2G08AAD), 256MiB, page size: 2048, OOB size: 64 First line seems coming from drivers/nand/mtd/omap2.c:omap3_init_bch that gets printed in this from only if OMAP_ECC_BCH8_CODE_HW == platform_data.ecc_opt I printed nand.ecc.layout.eccbytes = 52 ( from from drivers/nand/mtd/omap2.c:omap3_init_bch_tail ) and nand.ecc.layout-eccpos[] = 12..63 BTW it seems that similar layout has been defined in u-boot arch/arm/include/asm/arch-omap3/omap_gpmc.h There is one exception, though: eccbytes have been set 54 instead of 52 that seems to be in linux (and correct I suppose). (2) Is the problem related to incorrect read/write access to x16 NAND ? No using x8 NAND Or Is it incompatibility in ecc.layout ? You can check this by dumping raw nand page via 'nand dump' command from both u-boot and kernel. I'll try to check this (3) you should not pick BCH16 patch-series - because I have not rebased this patch, and re-tested since other base patch-series on which BCH16 will be build, is still not accepted. - Also BCH16 ecc scheme would work only for
Re: [U-Boot] livetime of boards
Hello Wolfgang, Am 07.11.2013 13:01, schrieb Wolfgang Denk: Dear Andreas Bießmann, In message527b7883.1080...@gmail.com you wrote: [...] maintainer could then see if he needs to pull out a board or if one else run the test before. I fully agree - everybody should be able to provide such test information. Actually it would be a big help to board maintainers as well if these would get test reports from actual users of the hardware. Yep. If we would save this in the repository we do not have this information in time. If we send the information to a list we need to parse it or use some other tool to provide the information. Beside that we will pollute the list with status updates about boards being tested. It could be hard to find real patches in that information flood then. Agreed too. I doubt if a mailing list makes sense to collect such data. It would probably be more efficient to provide a web based service for this. It just has to be easy to submit reports, and to query the status for boards. Ok, how would look like such a web based service? - one livetime counter patch for current release - one list for boards which reach end of life - one list for boards, which should be deleted Good idea, but the information could also be saved on a website or in another database. It should be easily filled by the tester and also easily queried by wherever is interested in. Agreed. I definitely do not want to see such trafic on the regular U-Boot mailing list. Oh, ok ... then we must look for another way. All Infos are release info I think, and fully fit in the commit for the new release ... I also think that should be done on release only. Why? To me it makes a lot of sense to also collect information on intermediate snapshots. Hmm.. I thought we get a test report (however this looks like in the end) based on a commit id in u-boot/master ... isn;t this enough? I think deleting should be done in next release then to give the board maintainer some time to check the boards. On a new release the board maintainer should be mailed that in the next release the board will be removed. We should also store this somewhere in the code (status in boards.cfg?). Next question is what to do if the mail bounces ;) Mail bounces (and new address of maintainer cannot be found, and no other user volunteers to take over maintenance) = board is unmaintained = board gets removed. Full Ack. - Do we want to delete old boards automatically after we do not get some test reports after a time intervall? And we should delete 'unmaintained' boards, when is to be discussed. I'm currently fiddling with at91 gpio and ask myself if I should adopt all the boards or just let them fail ... I hesitate to automatically remove existing boards. Why would we want to do that? To reduce efforts, right? So I vote to keep boards as long as they are either maintained, or they at least do not hurt. Why the not hurt case? Is it really good to have a lot of boards, which compile clean, but we do not know, if the code really works? I prefer to have in current mainline only boards, which really work or at least maintained... if a board maintainer did the work to bring it into mainline, it should be interested in stay in mainline. If this interest is lost and no other volunteers ... board is useless in mainline. Code for old boards is not lost. If a board just builds fine and does not cause any additional efforts we should keep it, no matter if there is an active maintainer or test reports or not. Only when a board becomes a pain to somebody - say, because it develops build errors, or wit would require efforts to adapt it to some new feature, _then_ we would check if this is one of the precious boards we want to keep or if it is just old cruft nobody cares about anyway. And only then I would remove it. Ok, that is a way to go, if we have for all boards the information, in which maintainstate it is ... but think of for example the new i2c framework, how much boards use I2C? I have to check now all this boards, decide to delete it or convert it ... very time consuming frustrating work ... and maybe for a lot of do not hurt boards only waste of time ... :-( if we have a clean mainline state, where I know all boards are working the decision is clear, convert all ... and board maintainers will test it ... and we have always a clean compile state for mainline And if we have this test/delete cycle, I can be sure, that after a defined time all boards in mainline are working! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Hello Wolfgang, Am 07.11.2013 13:12, schrieb Wolfgang Denk: Dear Heiko, In message527b7ee6.4030...@denx.de you wrote: Hmm... I hope we get a lot of such EMails ... and think, this is not a big problem ... Or, maybe, if we get a lot of such EMails, maybe we open a u-boot-testing list? NAK. Mailing lists are good for some kind of information - especially for such information that is read by humans. All you want to do here is feed a database with data. This is not what mailing lists were made for, so we should really use a more appropriate interface. Ok. But this status report can be in readable text format ;-) See my proposal for the livetime counter: livetime init value n (n=4) livetimer decrement on every new release livetimer set to n, if in release cycle comes a test report livetimer == 0 - EMail to board maintainer, board reached end of live in mainline, please send test report. livetimer == -1 - board get deleted This is too simple in one respect (as you are not including information that may be vital, like which exact commit ID has been tested, or which tool chain has been used to build it). Ok. Also we should probably not only allow for positive test reports, but also allow to report failures (to mark board support as broken). Yep, this will set livetime = 0 - EMail to board maintainer ... All this cannot be done in boards.cfg . And there is no need to as long as we provide tools to query for any information we might be interested in. Ok, then we must define this way ... bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v1] arm: keep all sections in ELF file
Current LDS files /DISCARD/ a lot of sections when linking ELF
files, causing diagnostic tools such as readelf or objdump to
produce partial output. Keep all section at link stage, filter
only at objcopy time so that .bin remains minimal.
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
This is a repost of the previously posted RFC.
I have verified on an intermediate form of the patch (with .hash
and .got.plt kept in place) that the change was binary invariant
wrt master branch of ARM repo.
Please test on your HW to make sure the .bin is functional across
a selection of boards.
Makefile| 2 +-
arch/arm/config.mk | 3 +++
arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds | 16 +---
arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds | 16 +---
arch/arm/cpu/ixp/u-boot.lds | 15 +--
arch/arm/cpu/u-boot-spl.lds | 15 +--
arch/arm/cpu/u-boot.lds | 18 ++
board/actux1/u-boot.lds | 15 +--
board/actux2/u-boot.lds | 15 +--
board/actux3/u-boot.lds | 15 +--
board/dvlhost/u-boot.lds| 15 +--
board/freescale/mx31ads/u-boot.lds | 18 +-
board/ti/am335x/u-boot.lds | 15 +--
board/vpac270/u-boot-spl.lds| 18 +-
14 files changed, 113 insertions(+), 83 deletions(-)
diff --git a/Makefile b/Makefile
index dc04179..4720db5 100644
--- a/Makefile
+++ b/Makefile
@@ -428,7 +428,7 @@ $(obj)u-boot.hex: $(obj)u-boot
$(OBJCOPY) ${OBJCFLAGS} -O ihex $ $@
$(obj)u-boot.srec: $(obj)u-boot
- $(OBJCOPY) -O srec $ $@
+ $(OBJCOPY) ${OBJCFLAGS} -O srec $ $@
$(obj)u-boot.bin: $(obj)u-boot
$(OBJCOPY) ${OBJCFLAGS} -O binary $ $@
diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index bdabcf4..fd3e5fb 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -103,3 +103,6 @@ ALL-y += checkarmreloc
# such usage by requiring word relocations.
PLATFORM_CPPFLAGS += $(call cc-option, -mword-relocations)
endif
+
+# limit ourselves to the sections we want in the .bin.
+OBJCFLAGS += -j .text -j .rodata -j .data -j .u_boot_list -j .rel.dyn
diff --git a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
index 40bcc31..80fb9bd 100644
--- a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
+++ b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
@@ -51,11 +51,13 @@ SECTIONS
_end = .;
- /DISCARD/ : { *(.dynstr*) }
- /DISCARD/ : { *(.dynsym*) }
- /DISCARD/ : { *(.dynamic*) }
- /DISCARD/ : { *(.hash*) }
- /DISCARD/ : { *(.plt*) }
- /DISCARD/ : { *(.interp*) }
- /DISCARD/ : { *(.gnu*) }
+ .dynsym _end : { *(.dynsym) }
+ .dynbss : { *(.dynbss) }
+ .dynstr : { *(.dynstr*) }
+ .dynamic : { *(.dynamic*) }
+ .hash : { *(.hash*) }
+ .plt : { *(.plt*) }
+ .interp : { *(.interp*) }
+ .gnu : { *(.gnu*) }
+ .ARM.exidx : { *(.ARM.exidx*) }
}
diff --git a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
index 4927736..76b499d 100644
--- a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
+++ b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
@@ -51,11 +51,13 @@ SECTIONS
_end = .;
- /DISCARD/ : { *(.dynstr*) }
- /DISCARD/ : { *(.dynsym*) }
- /DISCARD/ : { *(.dynamic*) }
- /DISCARD/ : { *(.hash*) }
- /DISCARD/ : { *(.plt*) }
- /DISCARD/ : { *(.interp*) }
- /DISCARD/ : { *(.gnu*) }
+ .dynsym _end : { *(.dynsym) }
+ .dynbss : { *(.dynbss) }
+ .dynstr : { *(.dynstr*) }
+ .dynamic : { *(.dynamic*) }
+ .hash : { *(.hash*) }
+ .plt : { *(.plt*) }
+ .interp : { *(.interp*) }
+ .gnu : { *(.gnu*) }
+ .ARM.exidx : { *(.ARM.exidx*) }
}
diff --git a/arch/arm/cpu/ixp/u-boot.lds b/arch/arm/cpu/ixp/u-boot.lds
index c8d2e12..676ae2c 100644
--- a/arch/arm/cpu/ixp/u-boot.lds
+++ b/arch/arm/cpu/ixp/u-boot.lds
@@ -79,10 +79,13 @@ SECTIONS
KEEP(*(.__bss_end));
}
- /DISCARD/ : { *(.dynsym) }
- /DISCARD/ : { *(.dynstr*) }
- /DISCARD/ : { *(.dynamic*) }
- /DISCARD/ : { *(.plt*) }
- /DISCARD/ : { *(.interp*) }
- /DISCARD/ : { *(.gnu*) }
+ .dynsym _end : { *(.dynsym) }
+ .dynbss : { *(.dynbss) }
+ .dynstr : { *(.dynstr*) }
+ .dynamic : { *(.dynamic*) }
+ .hash : { *(.hash*) }
+ .plt : { *(.plt*) }
+ .interp : { *(.interp*) }
+ .gnu : { *(.gnu*) }
+ .ARM.exidx : { *(.ARM.exidx*) }
}
diff --git a/arch/arm/cpu/u-boot-spl.lds b/arch/arm/cpu/u-boot-spl.lds
index 36cc54a..4880d0f 100644
--- a/arch/arm/cpu/u-boot-spl.lds
+++ b/arch/arm/cpu/u-boot-spl.lds
Re: [U-Boot] [PATCH 1/2] ARM: bcm2835: add missing mbox overscan response field
Hi Andre, On Wed, 23 Oct 2013 21:46:31 +0200, Andre Heider a.hei...@gmail.com wrote: On Wed, Oct 23, 2013 at 05:54:13PM +0100, Stephen Warren wrote: On 10/22/2013 09:27 PM, Andre Heider wrote: Add the missing right field to struct bcm2835_mbox_tag_overscan. This one patch, Acked-by: Stephen Warren swar...@wwwdotorg.org You need to send/cc this patch to Albert Aribauld, since he applies ARM patches. Or, perhaps just make sure the patch gets assigned to him in patchwork? Okay, I did the patchwork dance :) Thanks, Andre In fact, the series could be applied as a whole by the same custodian -- and actually, I'd prefer it to be applied as a whole, since patch 1/2 alone looks like dead/useless code, whereas it makes sense if applied along with 2/2. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
On Thu, Nov 07, 2013 at 10:37:24AM +0100, Andreas Bie?mann wrote: Hello all together, On 11/07/2013 09:17 AM, Heiko Schocher wrote: Am 06.11.2013 08:50, schrieb Wolfgang Denk: [snip] So when you're once again doing some change that requires touching files for some othe rboards, you could simply check that database. If you see that 3 out of the last 5 releases have reported succesful run-time tests you will probably decide to accept the needed efforts, Hmm.. that works, if you have to touch some (some 5) boards. But If you have to touch 5 boards, this gets unhandy... How about: MAKEALL --check-boards -s at91 ;) I feel this is the hard part of the problem, and what we're glossing over. What has to be tested by the board maintainer? What are we going to leave to their discretion? Will am335x_evm not count if I don't dig up the NOR cape 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
Re: [U-Boot] [PATCH 07/14] ARM: AM43xx: Select clk source for Timer2
Hi Vaibhav, On Wednesday 06 November 2013 06:10 PM, Vaibhav Bedia wrote: On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote: Selecting the Master osc clk as Timer2 clock source. I obviously missed the first round of patches for AM43xx here. Why is timer2 being used here? Don't we use the synctimer and timer1 in the kernel? In u-boot there is already code present to handle timer2 in arch/arm/cpu/armv7/omap-common/timer.c(Registers offsets are different for timer1 and timer2) . Trying to reuse the same here. This is how it is done in am335x also. Correct me if I am wrong. Thanks and regards, Lokesh Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] designware_i2c: remove 10msec delay in i2c_xfer_finish
This delay applies to any data transfer on I2C bus. For example 1kB data read with per-byte access (which happens if environment is stored in I2C EEPROM) takes more than 10 seconds. Moreover data bus driver has to care about bus state and data transfer, but not about internal states of attached devices. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Tom Rini tr...@ti.com cc: Armando Visconti armando.visco...@st.com Cc: Stefan Roese s...@denx.de Cc: Albert ARIBAUD albert.u.b...@aribaud.net Cc: Heiko Schocher h...@denx.de Cc: Vipin KUMAR vipin.ku...@st.com Cc: Tom Rix tom@windriver.com Cc: Mischa Jonker mjon...@synopsys.com --- drivers/i2c/designware_i2c.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c index c5c6015..cb2ac04 100644 --- a/drivers/i2c/designware_i2c.c +++ b/drivers/i2c/designware_i2c.c @@ -249,9 +249,6 @@ static int i2c_xfer_finish(void) i2c_flush_rxfifo(); - /* Wait for read/write operation to complete on actual memory */ - udelay(1); - return 0; } -- 1.8.4.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_eeprom: fix i2c_{read|write} usage if env is in I2C EEPROM
Data offset is not used directly in case of I2C EEPROM. Istead it is split into block number and offset within mentioned block. Which are addr[0] and addr[1] respectively. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com cc: Peter Tyser pty...@xes-inc.com Cc: Heiko Schocher h...@denx.de Cc: Wolfgang Denk w...@denx.de Cc: Stefan Roese s...@denx.de Cc: Mischa Jonker mjon...@synopsys.com --- common/cmd_eeprom.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/common/cmd_eeprom.c b/common/cmd_eeprom.c index ef694d8..02539c4 100644 --- a/common/cmd_eeprom.c +++ b/common/cmd_eeprom.c @@ -161,7 +161,7 @@ int eeprom_read (unsigned dev_addr, unsigned offset, uchar *buffer, unsigned cnt #if defined(CONFIG_SPI) !defined(CONFIG_ENV_EEPROM_IS_ON_I2C) spi_read (addr, alen, buffer, len); #else - if (i2c_read (addr[0], offset, alen-1, buffer, len) != 0) + if (i2c_read (addr[0], addr[1], alen-1, buffer, len) != 0) rcode = 1; #endif buffer += len; @@ -339,7 +339,7 @@ int eeprom_write (unsigned dev_addr, unsigned offset, uchar *buffer, unsigned cn /* Write is enabled ... now write eeprom value. */ #endif - if (i2c_write (addr[0], offset, alen-1, buffer, len) != 0) + if (i2c_write (addr[0], addr[1], alen-1, buffer, len) != 0) rcode = 1; #endif -- 1.8.4.2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] designware_i2c: disable i2c controller during target address setup
As it is stated in DesignWare I2C databook: writes to IC_TAR (0x4)
register succeed only when IC_ENABLE[0] is set to 0.
Signed-off-by: Alexey Brodkin abrod...@synopsys.com
Cc: Tom Rini tr...@ti.com
cc: Armando Visconti armando.visco...@st.com
Cc: Stefan Roese s...@denx.de
Cc: Albert ARIBAUD albert.u.b...@aribaud.net
Cc: Heiko Schocher h...@denx.de
Cc: Vipin KUMAR vipin.ku...@st.com
Cc: Tom Rix tom@windriver.com
Cc: Mischa Jonker mjon...@synopsys.com
---
drivers/i2c/designware_i2c.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index c2f0662..c5c6015 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -151,7 +151,19 @@ void i2c_init(int speed, int slaveadd)
*/
static void i2c_setaddress(unsigned int i2c_addr)
{
+ unsigned int enbl;
+
+ /* Disable i2c */
+ enbl = readl(i2c_regs_p-ic_enable);
+ enbl = ~IC_ENABLE_0B;
+ writel(enbl, i2c_regs_p-ic_enable);
+
writel(i2c_addr, i2c_regs_p-ic_tar);
+
+ /* Enable i2c */
+ enbl = readl(i2c_regs_p-ic_enable);
+ enbl |= IC_ENABLE_0B;
+ writel(enbl, i2c_regs_p-ic_enable);
}
/*
--
1.8.4.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] arm: make _end compiler-generated
This prevents references to _end from generating absolute
relocation records.
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
Changes in v2: None
arch/arm/cpu/arm1136/u-boot-spl.lds| 6 +-
arch/arm/cpu/arm920t/ep93xx/u-boot.lds | 5 -
arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds | 5 -
arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds| 5 -
arch/arm/cpu/armv7/am33xx/u-boot-spl.lds | 6 +-
arch/arm/cpu/armv7/omap-common/u-boot-spl.lds | 6 +-
arch/arm/cpu/armv7/socfpga/u-boot-spl.lds | 6 +-
arch/arm/cpu/ixp/u-boot.lds| 5 -
arch/arm/cpu/u-boot-spl.lds| 5 -
arch/arm/cpu/u-boot.lds| 5 -
arch/arm/lib/Makefile | 2 +-
arch/arm/lib/sections.c| 1 +
board/actux1/u-boot.lds| 5 -
board/actux2/u-boot.lds| 5 -
board/actux3/u-boot.lds| 5 -
board/ait/cam_enc_4xx/u-boot-spl.lds | 6 +-
board/davinci/da8xxevm/u-boot-spl-da850evm.lds | 6 +-
board/davinci/da8xxevm/u-boot-spl-hawk.lds | 5 -
board/dvlhost/u-boot.lds | 5 -
board/freescale/mx31ads/u-boot.lds | 5 -
board/samsung/common/exynos-uboot-spl.lds | 6 +-
board/ti/am335x/u-boot.lds | 5 -
board/vpac270/u-boot-spl.lds | 5 -
23 files changed, 93 insertions(+), 22 deletions(-)
diff --git a/arch/arm/cpu/arm1136/u-boot-spl.lds
b/arch/arm/cpu/arm1136/u-boot-spl.lds
index bccde73..0299902 100644
--- a/arch/arm/cpu/arm1136/u-boot-spl.lds
+++ b/arch/arm/cpu/arm1136/u-boot-spl.lds
@@ -33,7 +33,11 @@ SECTIONS
.data : { *(SORT_BY_ALIGNMENT(.data*)) } .sram
. = ALIGN(4);
__image_copy_end = .;
- _end = .;
+
+ .end :
+ {
+ *(.__end)
+ }
.bss :
{
diff --git a/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
b/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
index 4bed4fc..9699404 100644
--- a/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
+++ b/arch/arm/cpu/arm920t/ep93xx/u-boot.lds
@@ -50,5 +50,8 @@ SECTIONS
.bss : { *(.bss*) }
__bss_end = .;
- _end = .;
+ .end :
+ {
+ *(.__end)
+ }
}
diff --git a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
index 40bcc31..e695058 100644
--- a/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
+++ b/arch/arm/cpu/arm926ejs/mxs/u-boot-spl.lds
@@ -49,7 +49,10 @@ SECTIONS
__bss_end = .;
}
- _end = .;
+ .end :
+ {
+ *(.__end)
+ }
/DISCARD/ : { *(.dynstr*) }
/DISCARD/ : { *(.dynsym*) }
diff --git a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
index 4927736..b7c9a9d 100644
--- a/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
+++ b/arch/arm/cpu/arm926ejs/spear/u-boot-spl.lds
@@ -49,7 +49,10 @@ SECTIONS
__bss_end = .;
}
- _end = .;
+ .end :
+ {
+ *(.__end)
+ }
/DISCARD/ : { *(.dynstr*) }
/DISCARD/ : { *(.dynsym*) }
diff --git a/arch/arm/cpu/armv7/am33xx/u-boot-spl.lds
b/arch/arm/cpu/armv7/am33xx/u-boot-spl.lds
index 9302856..33ef23b 100644
--- a/arch/arm/cpu/armv7/am33xx/u-boot-spl.lds
+++ b/arch/arm/cpu/armv7/am33xx/u-boot-spl.lds
@@ -38,7 +38,11 @@ SECTIONS
. = ALIGN(4);
__image_copy_end = .;
- _end = .;
+
+ .end :
+ {
+ *(.__end)
+ }
.bss :
{
diff --git a/arch/arm/cpu/armv7/omap-common/u-boot-spl.lds
b/arch/arm/cpu/armv7/omap-common/u-boot-spl.lds
index 5e93b34..9e8cd82 100644
--- a/arch/arm/cpu/armv7/omap-common/u-boot-spl.lds
+++ b/arch/arm/cpu/armv7/omap-common/u-boot-spl.lds
@@ -34,7 +34,11 @@ SECTIONS
. = ALIGN(4);
__image_copy_end = .;
- _end = .;
+
+ .end :
+ {
+ *(.__end)
+ }
.bss :
{
diff --git a/arch/arm/cpu/armv7/socfpga/u-boot-spl.lds
b/arch/arm/cpu/armv7/socfpga/u-boot-spl.lds
index a7c9c9d..4282beb 100644
--- a/arch/arm/cpu/armv7/socfpga/u-boot-spl.lds
+++ b/arch/arm/cpu/armv7/socfpga/u-boot-spl.lds
@@ -28,7 +28,11 @@ SECTIONS
. = ALIGN(4);
__image_copy_end = .;
- _end = .;
+
+ .end :
+ {
+ *(.__end)
+ }
.bss : {
. = ALIGN(4);
diff --git a/arch/arm/cpu/ixp/u-boot.lds b/arch/arm/cpu/ixp/u-boot.lds
index c8d2e12..0d2c81a 100644
--- a/arch/arm/cpu/ixp/u-boot.lds
+++ b/arch/arm/cpu/ixp/u-boot.lds
@@ -58,7 +58,10 @@ SECTIONS
*(.__rel_dyn_end)
}
- _end = .;
+ .end :
+ {
+ *(.__end)
+ }
/*
* Compiler-generated __bss_start and __bss_end, see arch/arm/lib/bss.c
diff --git
[U-Boot] [PATCH v2 2/2] arm: remove unneeded symbol offsets and _TEXT_BASE
Remove the last uses of symbol offsets in ARM U-Boot. Remove some needless uses of _TEXT_BASE. Remove all _TEXT_BASE definitions. Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net --- Changes in v2: - fixed use of _rel_dyn_end instead of _end README | 6 -- arch/arm/cpu/arm1136/start.S| 27 --- arch/arm/cpu/arm1176/start.S| 27 --- arch/arm/cpu/arm720t/start.S| 26 -- arch/arm/cpu/arm920t/start.S| 26 -- arch/arm/cpu/arm926ejs/at91/lowlevel_init.S | 14 +- arch/arm/cpu/arm926ejs/mxs/start.S | 27 --- arch/arm/cpu/arm926ejs/start.S | 27 --- arch/arm/cpu/arm946es/start.S | 26 -- arch/arm/cpu/arm_intcm/start.S | 26 -- arch/arm/cpu/armv7/omap3/lowlevel_init.S| 3 --- arch/arm/cpu/armv7/start.S | 23 --- arch/arm/cpu/ixp/start.S| 26 -- arch/arm/cpu/pxa/start.S| 27 --- arch/arm/cpu/sa1100/start.S | 26 -- arch/arm/lib/board.c| 12 ++-- board/armltd/integrator/lowlevel_init.S | 2 +- board/cm4008/flash.c| 2 +- board/cm41xx/flash.c| 2 +- board/mpl/vcma9/lowlevel_init.S | 5 + board/mx1ads/lowlevel_init.S| 4 board/samsung/goni/lowlevel_init.S | 3 --- board/samsung/smdk2410/lowlevel_init.S | 5 + board/samsung/smdk5250/lowlevel_init.S | 5 + board/samsung/smdkc100/lowlevel_init.S | 3 --- board/ti/omap5912osk/lowlevel_init.S| 4 board/ti/omap730p2/lowlevel_init.S | 3 --- common/board_f.c| 14 +++--- common/board_r.c| 4 ++-- include/asm-generic/sections.h | 26 +++--- 30 files changed, 25 insertions(+), 406 deletions(-) diff --git a/README b/README index 09662a4..67bc2aa 100644 --- a/README +++ b/README @@ -3532,12 +3532,6 @@ Configuration Settings: its config.mk file). If you find problems enabling this option on your board please report the problem and send patches! -- CONFIG_SYS_SYM_OFFSETS - This is set by architectures that use offsets for link symbols - instead of absolute values. So bss_start is obtained using an - offset _bss_start_ofs from CONFIG_SYS_TEXT_BASE, rather than - directly. You should not need to touch this setting. - - CONFIG_OMAP_PLATFORM_RESET_TIME_MAX_USEC (OMAP only) This is set by OMAP boards for the max time that reset should be asserted. See doc/README.omap-reset-time for details on how diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S index 00d1b30..3e2358e 100644 --- a/arch/arm/cpu/arm1136/start.S +++ b/arch/arm/cpu/arm1136/start.S @@ -70,32 +70,6 @@ _end_vect: * */ -.globl _TEXT_BASE -_TEXT_BASE: -#if defined(CONFIG_SPL_BUILD) defined(CONFIG_SPL_TEXT_BASE) - .word CONFIG_SPL_TEXT_BASE -#else - .word CONFIG_SYS_TEXT_BASE -#endif - -/* - * These are defined in the board-specific linker script. - * Subtracting _start from them lets the linker put their - * relative position in the executable instead of leaving - * them null. - */ -.globl _bss_start_ofs -_bss_start_ofs: - .word __bss_start - _start - -.globl _bss_end_ofs -_bss_end_ofs: - .word __bss_end - _start - -.globl _end_ofs -_end_ofs: - .word _end - _start - #ifdef CONFIG_USE_IRQ /* IRQ stack memory (calculated at run-time) */ .globl IRQ_STACK_START @@ -295,7 +269,6 @@ cpu_init_crit: #ifdef CONFIG_SPL_BUILD .align 5 do_hang: - ldr sp, _TEXT_BASE /* use 32 words about stack */ bl hang/* hang and never return */ #else /* !CONFIG_SPL_BUILD */ .align 5 diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S index ffd7dd0..ce62011 100644 --- a/arch/arm/cpu/arm1176/start.S +++ b/arch/arm/cpu/arm1176/start.S @@ -77,33 +77,6 @@ _end_vect: * */ -.globl _TEXT_BASE -_TEXT_BASE: -#if defined(CONFIG_SPL_BUILD) defined(CONFIG_SPL_TEXT_BASE) - .word CONFIG_SPL_TEXT_BASE -#else - .word CONFIG_SYS_TEXT_BASE -#endif - -/* - * These are defined in the board-specific linker script. - * Subtracting _start from them lets the linker put their - * relative position in the executable instead of leaving - * them null. - */ - -.globl _bss_start_ofs
Re: [U-Boot] livetime of boards
Dear Tom Rini, On 11/07/2013 02:31 PM, Tom Rini wrote: On Thu, Nov 07, 2013 at 10:37:24AM +0100, Andreas Bie?mann wrote: Hello all together, On 11/07/2013 09:17 AM, Heiko Schocher wrote: Am 06.11.2013 08:50, schrieb Wolfgang Denk: [snip] So when you're once again doing some change that requires touching files for some othe rboards, you could simply check that database. If you see that 3 out of the last 5 releases have reported succesful run-time tests you will probably decide to accept the needed efforts, Hmm.. that works, if you have to touch some (some 5) boards. But If you have to touch 5 boards, this gets unhandy... How about: MAKEALL --check-boards -s at91 ;) I feel this is the hard part of the problem, and what we're glossing over. What has to be tested by the board maintainer? What are we going to leave to their discretion? Will am335x_evm not count if I don't dig up the NOR cape for it? for the time being I'd glad to see reports of (un)successful boot with configured bootm command. But I see your point, there is another input vector for the tests. I think this could only be defined on a per board basis. To pick up your example, I think it is worth to know that one tested the am335x_evm to boot via NAND. At least for the maintainer, so he can skip that and just test the NOR booting. 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 0/2] OMAP5/DRA7: EMIF fixes for lowpower usecases
1) Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using software leveling. This was done since hardware leveling was not working. Now that the right sequence to do hw leveling is identified, use it. This is required for EMIF clockdomain to idle and come back during lowpower usecases 2) When core power domain hits oswr, then DDR3 memories does not come back while resuming. This is because when EMIF registers are lost, then the controller takes care of copying the values from the shadow registers. If the shadow registers are not updated with the right values, then this results in incorrect settings while resuming. So updating the shadow registers with the corresponding status registers here during the boot. Sricharan R (2): ARM: DRA: EMIF: Change DDR3 settings to use hw leveling ARM: DRA7/OMAP5: EMIF: Add workaround for bug 0039 arch/arm/cpu/armv7/omap-common/emif-common.c | 174 ++--- arch/arm/cpu/armv7/omap5/hw_data.c |9 +- arch/arm/cpu/armv7/omap5/hwinit.c| 12 +- arch/arm/cpu/armv7/omap5/sdram.c | 215 ++ arch/arm/include/asm/arch-omap5/omap.h |1 + arch/arm/include/asm/emif.h | 14 +- 6 files changed, 301 insertions(+), 124 deletions(-) -- 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] ARM: DRA7/OMAP5: EMIF: Add workaround for bug 0039
When core power domain hits oswr, then DDR3 memories does not come back
while resuming. This is because when EMIF registers are lost, then the
controller takes care of copying the values from the shadow registers.
If the shadow registers are not updated with the right values, then this
results in incorrect settings while resuming. So updating the shadow registers
with the corresponding status registers here during the boot.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 41 +++
arch/arm/cpu/armv7/omap5/sdram.c | 69 ++
arch/arm/include/asm/emif.h | 10 +++-
3 files changed, 119 insertions(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c
b/arch/arm/cpu/armv7/omap-common/emif-common.c
index c1f5838..cad6ffe 100644
--- a/arch/arm/cpu/armv7/omap-common/emif-common.c
+++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
@@ -1269,6 +1269,42 @@ void dmm_init(u32 base)
}
+static void do_bug0039_workaround(u32 base)
+{
+ u32 val, i, clkctrl;
+ struct emif_reg_struct *emif_base = (struct emif_reg_struct *)base;
+ const struct read_write_regs *bug_00339_regs;
+ u32 iterations;
+ u32 *phy_status_base = emif_base-emif_ddr_phy_status[0];
+ u32 *phy_ctrl_base = emif_base-emif_ddr_ext_phy_ctrl_1;
+
+ if (omap_revision() == DRA752_ES1_0)
+ phy_status_base++;
+
+ bug_00339_regs = get_bug_regs(iterations);
+
+ /* Put EMIF in to idle */
+ clkctrl = __raw_readl((*prcm)-cm_memif_clkstctrl);
+ __raw_writel(0x0, (*prcm)-cm_memif_clkstctrl);
+
+ /* Copy the phy status registers in to phy ctrl shadow registers */
+ for (i = 0; i iterations; i++) {
+ val = __raw_readl(phy_status_base +
+ bug_00339_regs[i].read_reg - 1);
+
+ __raw_writel(val, phy_ctrl_base +
+((bug_00339_regs[i].write_reg - 1) 1));
+
+ __raw_writel(val, phy_ctrl_base +
+(bug_00339_regs[i].write_reg 1) - 1);
+ }
+
+ /* Disable leveling */
+ writel(0x0, emif_base-emif_rd_wr_lvl_rmp_ctl);
+
+ __raw_writel(clkctrl, (*prcm)-cm_memif_clkstctrl);
+}
+
/*
* SDRAM initialization:
* SDRAM initialization has two parts:
@@ -1344,5 +1380,10 @@ void sdram_init(void)
debug(get_ram_size() successful);
}
+ if (!in_sdram !warm_reset()) {
+ do_bug0039_workaround(EMIF1_BASE);
+ do_bug0039_workaround(EMIF2_BASE);
+ }
+
debug(sdram_init()\n);
}
diff --git a/arch/arm/cpu/armv7/omap5/sdram.c b/arch/arm/cpu/armv7/omap5/sdram.c
index 2aae3ef..b5bf196 100644
--- a/arch/arm/cpu/armv7/omap5/sdram.c
+++ b/arch/arm/cpu/armv7/omap5/sdram.c
@@ -569,6 +569,75 @@ static const struct lpddr2_device_timings
dev_4G_S4_timings = {
.min_tck= min_tck,
};
+/*
+ * List of status registers to be controlled back to control registers
+ * after initial leveling
+ * readreg, writereg
+ */
+const struct read_write_regs omap5_bug_00339_regs[] = {
+ { 8, 5 },
+ { 9, 6 },
+ { 10, 7 },
+ { 14, 8 },
+ { 15, 9 },
+ { 16, 10 },
+ { 11, 2 },
+ { 12, 3 },
+ { 13, 4 },
+ { 17, 11 },
+ { 18, 12 },
+ { 19, 13 },
+};
+
+const struct read_write_regs dra_bug_00339_regs[] = {
+ { 7, 7 },
+ { 8, 8 },
+ { 9, 9 },
+ { 10, 10 },
+ { 11, 11 },
+ { 12, 2 },
+ { 13, 3 },
+ { 14, 4 },
+ { 15, 5 },
+ { 16, 6 },
+ { 17, 12 },
+ { 18, 13 },
+ { 19, 14 },
+ { 20, 15 },
+ { 21, 16 },
+ { 22, 17 },
+ { 23, 18 },
+ { 24, 19 },
+ { 25, 20 },
+ { 26, 21}
+};
+
+const struct read_write_regs *get_bug_regs(u32 *iterations)
+{
+ const struct read_write_regs *bug_00339_regs_ptr = NULL;
+
+ switch (omap_revision()) {
+ case OMAP5430_ES1_0:
+ case OMAP5430_ES2_0:
+ case OMAP5432_ES1_0:
+ case OMAP5432_ES2_0:
+ bug_00339_regs_ptr = omap5_bug_00339_regs;
+ *iterations = sizeof(omap5_bug_00339_regs)/
+sizeof(omap5_bug_00339_regs[0]);
+ break;
+ case DRA752_ES1_0:
+ bug_00339_regs_ptr = dra_bug_00339_regs;
+ *iterations = sizeof(dra_bug_00339_regs)/
+sizeof(dra_bug_00339_regs[0]);
+ printf(\n DRA iterations=%d, *iterations);
+ break;
+ default:
+ printf(\n Error: UnKnown SOC);
+ }
+
+ return bug_00339_regs_ptr;
+}
+
void emif_get_device_timings_sdp(u32 emif_nr,
const struct lpddr2_device_timings **cs0_device_timings,
const struct lpddr2_device_timings **cs1_device_timings)
diff --git
[U-Boot] [PATCH 1/2] ARM: DRA: EMIF: Change DDR3 settings to use hw leveling
Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using
software leveling. This was done since hardware leveling was not
working. Now that the right sequence to do hw leveling is identified,
use it. This is required for EMIF clockdomain to idle and come back
during lowpower usecases.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
arch/arm/cpu/armv7/omap-common/emif-common.c | 133 +--
arch/arm/cpu/armv7/omap5/hw_data.c |9 +-
arch/arm/cpu/armv7/omap5/hwinit.c| 12 ++-
arch/arm/cpu/armv7/omap5/sdram.c | 146 +++---
arch/arm/include/asm/arch-omap5/omap.h |1 +
arch/arm/include/asm/emif.h |4 +-
6 files changed, 182 insertions(+), 123 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap-common/emif-common.c
b/arch/arm/cpu/armv7/omap-common/emif-common.c
index b0e1caa..c1f5838 100644
--- a/arch/arm/cpu/armv7/omap-common/emif-common.c
+++ b/arch/arm/cpu/armv7/omap-common/emif-common.c
@@ -210,54 +210,76 @@ static void ddr3_leveling(u32 base, const struct
emif_regs *regs)
{
struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
- /* keep sdram in self-refresh */
- writel(((LP_MODE_SELF_REFRESH EMIF_REG_LP_MODE_SHIFT)
-EMIF_REG_LP_MODE_MASK), emif-emif_pwr_mgmt_ctrl);
- __udelay(130);
-
- /*
-* Set invert_clkout (if activated)--DDR_PHYCTRL_1
-* Invert clock adds an additional half cycle delay on the command
-* interface. The additional half cycle, is usually meant to enable
-* leveling in the situation that DQS is later than CK on the board.It
-* also helps provide some additional margin for leveling.
-*/
- writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1);
- writel(regs-emif_ddr_phy_ctlr_1, emif-emif_ddr_phy_ctrl_1_shdw);
- __udelay(130);
-
- writel(((LP_MODE_DISABLE EMIF_REG_LP_MODE_SHIFT)
-EMIF_REG_LP_MODE_MASK), emif-emif_pwr_mgmt_ctrl);
-
- /* Launch Full leveling */
- writel(DDR3_FULL_LVL, emif-emif_rd_wr_lvl_ctl);
+ if (omap_revision() != DRA752_ES1_0){
+ /* keep sdram in self-refresh */
+ writel(((LP_MODE_SELF_REFRESH EMIF_REG_LP_MODE_SHIFT)
+EMIF_REG_LP_MODE_MASK), emif-emif_pwr_mgmt_ctrl);
+ __udelay(130);
+
+ /*
+* Set invert_clkout (if activated)--DDR_PHYCTRL_1
+* Invert clock adds an additional half cycle delay on the
+* command interface. The additional half cycle, is usually
+* meant to enable leveling in the situation that DQS is later
+* than CK on the board.It also helps provide some additional
+* margin for leveling.
+*/
+ writel(regs-emif_ddr_phy_ctlr_1,
+ emif-emif_ddr_phy_ctrl_1);
+
+ writel(regs-emif_ddr_phy_ctlr_1,
+ emif-emif_ddr_phy_ctrl_1_shdw);
+ __udelay(130);
+
+ writel(((LP_MODE_DISABLE EMIF_REG_LP_MODE_SHIFT)
+EMIF_REG_LP_MODE_MASK), emif-emif_pwr_mgmt_ctrl);
+
+ /* Launch Full leveling */
+ writel(DDR3_FULL_LVL, emif-emif_rd_wr_lvl_ctl);
+
+ /* Wait till full leveling is complete */
+ readl(emif-emif_rd_wr_lvl_ctl);
+ __udelay(130);
+
+ /* Read data eye leveling no of samples */
+ config_data_eye_leveling_samples(base);
+
+ /*
+* Launch 8 incremental WR_LVL- to compensate for
+* PHY limitation.
+*/
+ writel(0x2 EMIF_REG_WRLVLINC_INT_SHIFT,
+ emif-emif_rd_wr_lvl_ctl);
+
+ __udelay(130);
+
+ /* Launch Incremental leveling */
+ writel(DDR3_INC_LVL, emif-emif_rd_wr_lvl_ctl);
+ __udelay(130);
+ } else {
+ u32 fifo_reg;
- /* Wait till full leveling is complete */
- readl(emif-emif_rd_wr_lvl_ctl);
- __udelay(130);
+ fifo_reg = readl(emif-emif_ddr_fifo_misaligned_clear_1);
+ writel(fifo_reg | 0x0100,
+ emif-emif_ddr_fifo_misaligned_clear_1);
- /* Read data eye leveling no of samples */
- config_data_eye_leveling_samples(base);
+ fifo_reg = readl(emif-emif_ddr_fifo_misaligned_clear_2);
+ writel(fifo_reg | 0x0100,
+ emif-emif_ddr_fifo_misaligned_clear_2);
- /* Launch 8 incremental WR_LVL- to compensate for PHY limitation */
- writel(0x2 EMIF_REG_WRLVLINC_INT_SHIFT, emif-emif_rd_wr_lvl_ctl);
- __udelay(130);
+ /* Launch Full leveling */
+ writel(DDR3_FULL_LVL, emif-emif_rd_wr_lvl_ctl);
- /* Launch Incremental
Re: [U-Boot] [PATCH 1/4] udoo: Add Ethernet support.
Hi Giuseppe,
On 07/11/2013 13:37, Giuseppe Pagano wrote:
+int mx6_rgmii_rework(struct phy_device *phydev)
+{
+ /* To advertise only 10 Mbs */
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x4, 0x61);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x9, 0x0c00);
+
Why only 10 Mb/s ? I think the Micrel 9031 allows 1Gb/s.
I will check again, I remember this solves an issue present also in
sabrelite board; but not sure. Maybe we can remove.
Ok - I know the Nitrogen (aka sabrelite) is working fine with 100Mb, I
am worrying that you will constrain the udoo to 10Mb/s
+ /* min rx data delay */
+ ksz9021_phy_extended_write(phydev,
+ MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW, 0x0);
Is is 9021 or 9031 ?
uDoo adopt a Micrel KSZ9031 phy.
Most of the register address are common to ksz9021 and ksz9031, and have
the same value. Maybe we should rename some variable to MII_KSZ90XX_...
+
+ gpio_set_value(IMX_GPIO_NR(3, 23), 1); /* SABRE Lite PHY rst */
SABRE as comment is maybe wrong
+#define CONFIG_PHY_MICREL_KSZ9021
Ok, it is 9021 - please be consistent with the comments avoiding mixing
9031 and 9021.
No, it is 9031. I will create a new define.
Mmmhh... I remember I did some work with KSZ9031 some times ago, let me see:
http://patchwork.ozlabs.org/patch/271947/
Joe, what is the current status of that patchset ?
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] udoo: Add Ethernet support.
Hi Giuseppe,
On 07/11/2013 13:37, Giuseppe Pagano wrote:
+int mx6_rgmii_rework(struct phy_device *phydev)
+{
+ /* To advertise only 10 Mbs */
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x4, 0x61);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x9, 0x0c00);
+
Why only 10 Mb/s ? I think the Micrel 9031 allows 1Gb/s.
I will check again, I remember this solves an issue present also in
sabrelite board; but not sure. Maybe we can remove.
Ok - I know the Nitrogen (aka sabrelite) is working fine with 100Mb, I
am worrying that you will constrain the udoo to 10Mb/s
+ /* min rx data delay */
+ ksz9021_phy_extended_write(phydev,
+ MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW, 0x0);
Is is 9021 or 9031 ?
uDoo adopt a Micrel KSZ9031 phy.
Most of the register address are common to ksz9021 and ksz9031, and have
the same value. Maybe we should rename some variable to MII_KSZ90XX_...
+
+ gpio_set_value(IMX_GPIO_NR(3, 23), 1); /* SABRE Lite PHY rst */
SABRE as comment is maybe wrong
+#define CONFIG_PHY_MICREL_KSZ9021
Ok, it is 9021 - please be consistent with the comments avoiding mixing
9031 and 9021.
No, it is 9031. I will create a new define.
Mmmhh... I remember I did some work with KSZ9031 some times ago, let me see:
http://patchwork.ozlabs.org/patch/271947/
Joe, what is the current status of that patchset ? Can you take a look
at it ?
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 1/2] driver:usb:s3c_udc: add support for Exynos4x12
This patch add new defines for usb phy for Exynos4x12.
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Minkyu Kang mk7.k...@samsung.com
---
Chnages for v3:
- removed unnecessary empty line
Changes for v2:
- no changes
drivers/usb/gadget/regs-otg.h|5 +
drivers/usb/gadget/s3c_udc_otg.c |9 +++--
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/regs-otg.h b/drivers/usb/gadget/regs-otg.h
index 84bfcc5..ac5d112 100644
--- a/drivers/usb/gadget/regs-otg.h
+++ b/drivers/usb/gadget/regs-otg.h
@@ -226,6 +226,11 @@ struct s3c_usbotg_reg {
#define CLK_SEL_12MHZ (0x2 0)
#define CLK_SEL_48MHZ (0x0 0)
+#define EXYNOS4X12_ID_PULLUP0 (0x01 3)
+#define EXYNOS4X12_COMMON_ON_N0(0x01 4)
+#define EXYNOS4X12_CLK_SEL_12MHZ (0x02 0)
+#define EXYNOS4X12_CLK_SEL_24MHZ (0x05 0)
+
/* Device Configuration Register DCFG */
#define DEV_SPEED_HIGH_SPEED_20 (0x0 0)
#define DEV_SPEED_FULL_SPEED_20 (0x1 0)
diff --git a/drivers/usb/gadget/s3c_udc_otg.c b/drivers/usb/gadget/s3c_udc_otg.c
index 7e20209..ba17a04 100644
--- a/drivers/usb/gadget/s3c_udc_otg.c
+++ b/drivers/usb/gadget/s3c_udc_otg.c
@@ -167,8 +167,13 @@ void otg_phy_init(struct s3c_udc *dev)
writel((readl(phy-phypwr) ~(OTG_DISABLE_0 | ANALOG_PWRDOWN)
~FORCE_SUSPEND_0), phy-phypwr);
- writel((readl(phy-phyclk) ~(ID_PULLUP0 | COMMON_ON_N0)) |
- CLK_SEL_24MHZ, phy-phyclk); /* PLL 24Mhz */
+ if (s5p_cpu_id == 0x4412)
+ writel((readl(phy-phyclk) ~(EXYNOS4X12_ID_PULLUP0 |
+ EXYNOS4X12_COMMON_ON_N0)) | EXYNOS4X12_CLK_SEL_24MHZ,
+ phy-phyclk); /* PLL 24Mhz */
+ else
+ writel((readl(phy-phyclk) ~(ID_PULLUP0 | COMMON_ON_N0)) |
+ CLK_SEL_24MHZ, phy-phyclk); /* PLL 24Mhz */
writel((readl(phy-rstcon) ~(LINK_SW_RST | PHYLNK_SW_RST))
| PHY_SW_RST0, phy-rstcon);
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V3 2/2] trats2: enable ums support on Trats2
This patch adds support for USB and enables 'ums' command on Trats2 board.
Signed-off-by: Piotr Wilczek p.wilc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
CC: Minkyu Kang mk7.k...@samsung.com
Acked-by: Jaehoon Chung jh80.ch...@samsung.com
---
This patch depends on the lated u-boot-usb/master.
Changes for v3:
- no changes
Changes for v2:
- rebased on current USB tree
- removed unnecessary pmic probing
board/samsung/trats2/trats2.c | 92 +
include/configs/trats2.h | 18
2 files changed, 110 insertions(+)
diff --git a/board/samsung/trats2/trats2.c b/board/samsung/trats2/trats2.c
index d44d825..41a7310 100644
--- a/board/samsung/trats2/trats2.c
+++ b/board/samsung/trats2/trats2.c
@@ -25,6 +25,9 @@
#include power/max77693_fg.h
#include libtizen.h
#include errno.h
+#include usb.h
+#include usb/s3c_udc.h
+#include usb_mass_storage.h
DECLARE_GLOBAL_DATA_PTR;
@@ -308,6 +311,95 @@ int board_mmc_init(bd_t *bis)
return err0 err2;
}
+#ifdef CONFIG_USB_GADGET
+static int s5pc210_phy_control(int on)
+{
+ int ret = 0;
+ unsigned int val;
+ struct pmic *p, *p_pmic, *p_muic;
+
+ p_pmic = pmic_get(MAX77686_PMIC);
+ if (!p_pmic)
+ return -ENODEV;
+
+ if (pmic_probe(p_pmic))
+ return -1;
+
+ p_muic = pmic_get(MAX77693_MUIC);
+ if (!p_muic)
+ return -ENODEV;
+
+ if (pmic_probe(p_muic))
+ return -1;
+
+ if (on) {
+ ret = max77686_set_ldo_mode(p_pmic, 12, OPMODE_ON);
+ if (ret)
+ return -1;
+
+ p = pmic_get(MAX77693_PMIC);
+ if (!p)
+ return -ENODEV;
+
+ if (pmic_probe(p))
+ return -1;
+
+ /* SAFEOUT */
+ ret = pmic_reg_read(p, MAX77693_SAFEOUT, val);
+ if (ret)
+ return -1;
+
+ val |= MAX77693_ENSAFEOUT1;
+ ret = pmic_reg_write(p, MAX77693_SAFEOUT, val);
+ if (ret)
+ return -1;
+
+ /* PATH: USB */
+ ret = pmic_reg_write(p_muic, MAX77693_MUIC_CONTROL1,
+ MAX77693_MUIC_CTRL1_DN1DP2);
+
+ } else {
+ ret = max77686_set_ldo_mode(p_pmic, 12, OPMODE_LPM);
+ if (ret)
+ return -1;
+
+ /* PATH: UART */
+ ret = pmic_reg_write(p_muic, MAX77693_MUIC_CONTROL1,
+ MAX77693_MUIC_CTRL1_UT1UR2);
+ }
+
+ if (ret)
+ return -1;
+
+
+ return 0;
+}
+
+struct s3c_plat_otg_data s5pc210_otg_data = {
+ .phy_control= s5pc210_phy_control,
+ .regs_phy = EXYNOS4X12_USBPHY_BASE,
+ .regs_otg = EXYNOS4X12_USBOTG_BASE,
+ .usb_phy_ctrl = EXYNOS4X12_USBPHY_CONTROL,
+ .usb_flags = PHY0_SLEEP,
+};
+
+int board_usb_init(int index, enum usb_init_type init)
+{
+ debug(USB_udc_probe\n);
+ return s3c_udc_probe(s5pc210_otg_data);
+}
+
+#ifdef CONFIG_USB_CABLE_CHECK
+int usb_cable_connected(void)
+{
+ struct pmic *muic = pmic_get(MAX77693_MUIC);
+ int cable_connected = muic-chrg-chrg_type(muic);
+
+ return !!cable_connected;
+}
+#endif
+#endif
+
static int pmic_init_max77686(void)
{
struct pmic *p = pmic_get(MAX77686_PMIC);
diff --git a/include/configs/trats2.h b/include/configs/trats2.h
index 0e93836..66b1c95 100644
--- a/include/configs/trats2.h
+++ b/include/configs/trats2.h
@@ -113,6 +113,16 @@
#define CONFIG_CMD_EXT4
#define CONFIG_CMD_EXT4_WRITE
+/* USB Composite download gadget - g_dnl */
+#define CONFIG_USBDOWNLOAD_GADGET
+#define CONFIG_DFU_FUNCTION
+#define CONFIG_DFU_MMC
+
+/* USB Samsung's IDs */
+#define CONFIG_G_DNL_VENDOR_NUM 0x04E8
+#define CONFIG_G_DNL_PRODUCT_NUM 0x6601
+#define CONFIG_G_DNL_MANUFACTURER Samsung
+
/* To use the TFTPBOOT over USB, Please enable the CONFIG_CMD_NET */
#undef CONFIG_CMD_NET
@@ -293,6 +303,11 @@
#define CONFIG_POWER_MUIC_MAX77693
#define CONFIG_POWER_FG_MAX77693
#define CONFIG_POWER_BATTERY_TRATS2
+#define CONFIG_USB_GADGET
+#define CONFIG_USB_GADGET_S3C_UDC_OTG
+#define CONFIG_USB_GADGET_DUALSPEED
+#define CONFIG_USB_GADGET_VBUS_DRAW2
+#define CONFIG_USB_CABLE_CHECK
/* LCD */
#define CONFIG_EXYNOS_FB
@@ -305,6 +320,9 @@
#define CONFIG_VIDEO_BMP_GZIP
#define CONFIG_SYS_VIDEO_LOGO_MAX_SIZE ((500 * 250 * 4) + (1 12))
+#define CONFIG_CMD_USB_MASS_STORAGE
+#define CONFIG_USB_GADGET_MASS_STORAGE
+
/* Pass open firmware flat tree */
#define CONFIG_OF_LIBFDT1
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: DRA: EMIF: Change DDR3 settings to use hw leveling
On Thu, Nov 07, 2013 at 08:17:39PM +0530, Sricharan R wrote:
Currently the DDR3 memory on DRA7 ES1.0 evm board is enabled using
software leveling. This was done since hardware leveling was not
working. Now that the right sequence to do hw leveling is identified,
use it. This is required for EMIF clockdomain to idle and come back
during lowpower usecases.
[snip]
@@ -210,54 +210,76 @@ static void ddr3_leveling(u32 base, const struct
emif_regs *regs)
{
struct emif_reg_struct *emif = (struct emif_reg_struct *)base;
- /* keep sdram in self-refresh */
[snip]
+ if (omap_revision() != DRA752_ES1_0){
+ /* keep sdram in self-refresh */
[snip]
+ } else {
+ u32 fifo_reg;
[snip]
+ /* Disable leveling */
+ writel(0x0, emif-emif_rd_wr_lvl_rmp_ctl);
+ }
Two things here. First, it seems that now ddr3_leveling has one
sequence for not DRA752_ES1_0 (so likely to get wrong when used on
DRA752 whatever comes after ES1.0) and another for DRA752_ES1_0. This
would be because the it's different EMIF blocks and related HW, so it's
a different sequence, yes? Second, the comment at the end of this
function about Disable leveling seems misleading, but maybe it's just
me. We're saying leveling sequence is complete now, yes?
For the second issue, we can expand / clarify the comment. For the
first issue, maybe we shouldn't have a single ddr3_leveling function
but per family ones? There's nothing in common between the two cases
here, so we're just gaining an indentation level when we could be
excluding code from the final binary instead (either ifdef or maybe just
separate files?).
--
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 1/4] udoo: Add Ethernet support.
On Thu, Nov 7, 2013 at 8:58 AM, Stefano Babic sba...@denx.de wrote:
Hi Giuseppe,
On 07/11/2013 13:37, Giuseppe Pagano wrote:
+int mx6_rgmii_rework(struct phy_device *phydev)
+{
+ /* To advertise only 10 Mbs */
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x4, 0x61);
+ phy_write(phydev, MDIO_DEVAD_NONE, 0x9, 0x0c00);
+
Why only 10 Mb/s ? I think the Micrel 9031 allows 1Gb/s.
I will check again, I remember this solves an issue present also in
sabrelite board; but not sure. Maybe we can remove.
Ok - I know the Nitrogen (aka sabrelite) is working fine with 100Mb, I
am worrying that you will constrain the udoo to 10Mb/s
+ /* min rx data delay */
+ ksz9021_phy_extended_write(phydev,
+ MII_KSZ9021_EXT_RGMII_RX_DATA_SKEW, 0x0);
Is is 9021 or 9031 ?
uDoo adopt a Micrel KSZ9031 phy.
Most of the register address are common to ksz9021 and ksz9031, and have
the same value. Maybe we should rename some variable to MII_KSZ90XX_...
+
+ gpio_set_value(IMX_GPIO_NR(3, 23), 1); /* SABRE Lite PHY rst */
SABRE as comment is maybe wrong
+#define CONFIG_PHY_MICREL_KSZ9021
Ok, it is 9021 - please be consistent with the comments avoiding mixing
9031 and 9021.
No, it is 9031. I will create a new define.
Mmmhh... I remember I did some work with KSZ9031 some times ago, let me see:
http://patchwork.ozlabs.org/patch/271947/
Joe, what is the current status of that patchset ? Can you take a look
at it ?
Got it... I'll pull that in shortly.
Thanks,
-Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 0/17] Driver model implementation, tests, demo and GPIO
Note: If you are reviewing this code, but don't have a lot of time, please consider starting with the 'demo' driver (patch 'dm: Add a demonstration/example driver') since it clearly shows how devices and uclasses work. Much of this series consists of test code and plumbing, so is of less interest to driver authors. This patch adds a driver model implementation. It is taken from the driver model code developed by: Marek Vasut ma...@denx.de Pavel Herrmann morpheus.i...@gmail.com Viktor Křivák viktor.kri...@gmail.com Tomas Hlavacek tmshl...@gmail.com Please see doc/driver-model/README.txt for details of how to run this and what to look for. So far the documentation in doc/driver-model has not been updated. You can find a test version of the code used here in branch dm6 at: http://git.denx.de/u-boot-x86.git (Branch dm contains the original implementation) Changes in v6: - Add a test script for driver model - Add dev_get_platdata to access devices's platdata - Add dev_get_priv() to access device's private data - Add new patch to fix sandbox link error - Add ofdata_to_pdata method to convert device tree data to platdata - Convert Makefiles to new Kconfig format - Rename platform_data to platdata - Revise and update README - Use ofdata_to_platdata feature - Use ofdata_to_platdata method to convert device tree data to platdata Changes in v5: - Adjust patch to completely remove old driver model documentation - Change to new SPDX license headers - Correct 80col line missed last time - Fix style nit on for() loop Changes in v4: - Change 'dm dump' command to 'dm tree' - Correct 'out.dtb' typo - Move common/dm to drivers/core - Remove duplicated .op line - device_chld_unbind() continues on error Changes in v3: - Add a flag for tracking whether DM allocates/frees platform_data - Add function/struct comments to tests - Add new patch to build a device tree file for sandbox - Add new patch to move driver model documentation - Fix up demo command help - Rename per_device_priv_size to per_device_auto_alloc_size, etc. - Tidy up commenting of functions and structures - Tidy up comments/documentation in GPIO module - Update GPIO support to use new struct member names - Update demo driver to use device tree - Update sandbox GPIO header file comments - Updated README.txt to cover changes since version 2 Changes in v2: - Add GPIO uclass and tests - Add U_BOOT_DEVICE to declare platform_data - Add a single include/dm.h to bring in driver model code - Add auto-probing feature for platform_data to avoid driver_bind() calls - Add automatic allocation of device-specific priv data for uclasses - Add automatic allocation of platform_data for FDT - Add automatic allocation of priv data for devices - Add device tree support in driver model - Add dm_warn() to warn about impending doom - Add integration tests for driver model - Add new header file for lists - Add new util file to hold utility functions - Add sandbox GPIO driver - Add script to run tests - Add simple unit test functions - Add test infrastructure for driver model - Add tests for core code - Allow a driver to bind to only one uclass - Allow driver_bind() to support a NULL parent - Put platform_data definitions in their own header file - Remove relocation functions - Remove unneeded arguments to uclass_bind(), uclass_unbind() - Removed pointer return values in favour of integer - Rename data structures to hopefully be clearer - Rename struct device's 'bus' to 'parent' - Standardise variable names (e.g. uclass instead of class) - Update gpio command to use driver model - Use driver_bind() in dm_init() instead of writing new code Simon Glass (17): sandbox: Add timer_read_counter() to avoid link error sandbox: Make map_to_sysmem() use a constant pointer sandbox: Correct data sizes and printf() strings in fdtdec.c sandbox: config: Don't use 64-bit physical memory sandbox: Build a device tree file for sandbox Add cmd_process_error() to report and process errors dm: Add README for driver model dm: Add base driver model support sandbox: config: Enable driver model dm: Set up driver model after relocation dm: Add basic tests dm: Add a 'dm' command for testing dm: Add a demonstration/example driver dm: Add GPIO support and tests sandbox: Convert GPIOs to use driver model dm: Enable gpio command to support driver model dm: Remove old driver model documentation Makefile | 4 + arch/sandbox/config.mk| 2 + arch/sandbox/include/asm/gpio.h | 14 +- arch/sandbox/include/asm/io.h | 2 +- arch/sandbox/include/asm/types.h | 4 +- board/sandbox/dts/sandbox.dts | 20 ++ board/sandbox/sandbox/sandbox.c | 13 +- common/Makefile | 1 + common/board_r.c | 33 +++ common/cmd_demo.c | 102 +++ common/cmd_gpio.c | 127 - common/command.c | 10 + doc/driver-model/README.txt |
[U-Boot] [PATCH v6 09/17] sandbox: config: Enable driver model
Use driver model in sandbox to permit running of driver model unit test. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None include/configs/sandbox.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h index 9dbbd3d..6855e7d 100644 --- a/include/configs/sandbox.h +++ b/include/configs/sandbox.h @@ -18,6 +18,7 @@ #define CONFIG_BOOTSTAGE #define CONFIG_BOOTSTAGE_REPORT +#define CONFIG_DM /* Number of bits in a C 'long' on this architecture */ #define CONFIG_SANDBOX_BITS_PER_LONG 64 -- 1.8.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 15/17] sandbox: Convert GPIOs to use driver model
Convert sandbox over to use driver model GPIOs.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v6:
- Rename platform_data to platdata
- Use ofdata_to_platdata feature
Changes in v5: None
Changes in v4: None
Changes in v3:
- Update sandbox GPIO header file comments
Changes in v2: None
arch/sandbox/include/asm/gpio.h | 14 +--
board/sandbox/sandbox/sandbox.c | 7 +-
drivers/gpio/sandbox.c | 217 +---
include/configs/sandbox.h | 1 +
4 files changed, 151 insertions(+), 88 deletions(-)
diff --git a/arch/sandbox/include/asm/gpio.h b/arch/sandbox/include/asm/gpio.h
index afb9c78..95b59da 100644
--- a/arch/sandbox/include/asm/gpio.h
+++ b/arch/sandbox/include/asm/gpio.h
@@ -29,7 +29,7 @@
* @param gp GPIO number
* @return -1 on error, 0 if GPIO is low, 0 if high
*/
-int sandbox_gpio_get_value(unsigned gp);
+int sandbox_gpio_get_value(struct device *dev, unsigned int offset);
/**
* Set the simulated value of a GPIO (used only in sandbox test code)
@@ -38,7 +38,7 @@ int sandbox_gpio_get_value(unsigned gp);
* @param valuevalue to set (0 for low, non-zero for high)
* @return -1 on error, 0 if ok
*/
-int sandbox_gpio_set_value(unsigned gp, int value);
+int sandbox_gpio_set_value(struct device *dev, unsigned int offset, int value);
/**
* Return the simulated direction of a GPIO (used only in sandbox test code)
@@ -46,7 +46,7 @@ int sandbox_gpio_set_value(unsigned gp, int value);
* @param gp GPIO number
* @return -1 on error, 0 if GPIO is input, 0 if output
*/
-int sandbox_gpio_get_direction(unsigned gp);
+int sandbox_gpio_get_direction(struct device *dev, unsigned int offset);
/**
* Set the simulated direction of a GPIO (used only in sandbox test code)
@@ -55,11 +55,7 @@ int sandbox_gpio_get_direction(unsigned gp);
* @param output 0 to set as input, 1 to set as output
* @return -1 on error, 0 if ok
*/
-int sandbox_gpio_set_direction(unsigned gp, int output);
-
-/* Display information about each GPIO */
-void gpio_info(void);
-
-#define gpio_status() gpio_info()
+int sandbox_gpio_set_direction(struct device *dev, unsigned int offset,
+ int output);
#endif
diff --git a/board/sandbox/sandbox/sandbox.c b/board/sandbox/sandbox/sandbox.c
index ee64fc4..8939a76 100644
--- a/board/sandbox/sandbox/sandbox.c
+++ b/board/sandbox/sandbox/sandbox.c
@@ -4,7 +4,7 @@
*/
#include common.h
-
+#include dm.h
#include os.h
/*
@@ -14,6 +14,11 @@
*/
gd_t *gd;
+/* Add a simple GPIO device */
+U_BOOT_DEVICE(gpio_sandbox) = {
+ .name = gpio_sandbox,
+};
+
void flush_cache(unsigned long start, unsigned long size)
{
}
diff --git a/drivers/gpio/sandbox.c b/drivers/gpio/sandbox.c
index 3c6cfec..22b6a5f 100644
--- a/drivers/gpio/sandbox.c
+++ b/drivers/gpio/sandbox.c
@@ -4,8 +4,13 @@
*/
#include common.h
+#include dm.h
+#include fdtdec.h
+#include malloc.h
#include asm/gpio.h
+DECLARE_GLOBAL_DATA_PTR;
+
/* Flags for each GPIO */
#define GPIOF_OUTPUT (1 0)/* Currently set as an output */
#define GPIOF_HIGH (1 1)/* Currently set high */
@@ -16,34 +21,30 @@ struct gpio_state {
u8 flags; /* flags (GPIOF_...) */
};
-/*
- * State of GPIOs
- * TODO: Put this into sandbox state
- */
-static struct gpio_state state[CONFIG_SANDBOX_GPIO_COUNT];
-
/* Access routines for GPIO state */
-static u8 *get_gpio_flags(unsigned gp)
+static u8 *get_gpio_flags(struct device *dev, unsigned offset)
{
- /* assert()'s could be disabled, so make sure we handle that */
- assert(gp ARRAY_SIZE(state));
- if (gp = ARRAY_SIZE(state)) {
+ struct gpio_dev_priv *uc_priv = dev-uclass_priv;
+ struct gpio_state *state = dev_get_priv(dev);
+
+ if (offset = uc_priv-gpio_count) {
static u8 invalid_flags;
- printf(sandbox_gpio: error: invalid gpio %u\n, gp);
+ printf(sandbox_gpio: error: invalid gpio %u\n, offset);
return invalid_flags;
}
- return state[gp].flags;
+ return state[offset].flags;
}
-static int get_gpio_flag(unsigned gp, int flag)
+static int get_gpio_flag(struct device *dev, unsigned offset, int flag)
{
- return (*get_gpio_flags(gp) flag) != 0;
+ return (*get_gpio_flags(dev, offset) flag) != 0;
}
-static int set_gpio_flag(unsigned gp, int flag, int value)
+static int set_gpio_flag(struct device *dev, unsigned offset, int flag,
+int value)
{
- u8 *gpio = get_gpio_flags(gp);
+ u8 *gpio = get_gpio_flags(dev, offset);
if (value)
*gpio |= flag;
@@ -53,11 +54,12 @@ static int set_gpio_flag(unsigned gp, int flag, int value)
return 0;
}
-static int check_reserved(unsigned gpio, const char *func)
+static int check_reserved(struct device *dev, unsigned offset,
+ const char *func)
{
- if (!get_gpio_flag(gpio,
[U-Boot] [PATCH v6 05/17] sandbox: Build a device tree file for sandbox
Add support for building a device tree for sandbox's CONFIG_OF_HOSTFILE
option to make it easier to use device tree with sandbox.
This adjusts the Makefile to build a u-boot.dtb file which can be passed
to sandbox U-Boot with:
./u-boot -d u-boot.dtb
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add new patch to build a device tree file for sandbox
Changes in v2: None
Makefile | 1 +
arch/sandbox/config.mk| 2 ++
board/sandbox/dts/sandbox.dts | 20
include/configs/sandbox.h | 1 +
4 files changed, 24 insertions(+)
create mode 100644 board/sandbox/dts/sandbox.dts
diff --git a/Makefile b/Makefile
index a2fd7f6..445b0b2 100644
--- a/Makefile
+++ b/Makefile
@@ -365,6 +365,7 @@ ALL-$(CONFIG_SPL) += $(obj)spl/u-boot-spl.bin
ALL-$(CONFIG_SPL_FRAMEWORK) += $(obj)u-boot.img
ALL-$(CONFIG_TPL) += $(obj)tpl/u-boot-tpl.bin
ALL-$(CONFIG_OF_SEPARATE) += $(obj)u-boot.dtb $(obj)u-boot-dtb.bin
+ALL-$(CONFIG_OF_HOSTFILE) += $(obj)u-boot.dtb
ifneq ($(CONFIG_SPL_TARGET),)
ALL-$(CONFIG_SPL) += $(obj)$(subst ,,$(CONFIG_SPL_TARGET))
endif
diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk
index 6142dd4..60b7262 100644
--- a/arch/sandbox/config.mk
+++ b/arch/sandbox/config.mk
@@ -7,3 +7,5 @@ PLATFORM_LIBS += -lrt
# Support generic board on sandbox
__HAVE_ARCH_GENERIC_BOARD := y
+
+CONFIG_ARCH_DEVICE_TREE := sandbox
diff --git a/board/sandbox/dts/sandbox.dts b/board/sandbox/dts/sandbox.dts
new file mode 100644
index 000..96a4438
--- /dev/null
+++ b/board/sandbox/dts/sandbox.dts
@@ -0,0 +1,20 @@
+/dts-v1/;
+
+/ {
+ triangle {
+ compatible = demo-shape;
+ colour = cyan;
+ sides = 3;
+ character = 83;
+ };
+ square {
+ compatible = demo-shape;
+ colour = blue;
+ sides = 4;
+ };
+ hexagon {
+ compatible = demo-simple;
+ colour = white;
+ sides = 6;
+ };
+};
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index bce889e..9dbbd3d 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -30,6 +30,7 @@
#define CONFIG_FIT_SIGNATURE
#define CONFIG_RSA
#define CONFIG_CMD_FDT
+#define CONFIG_DEFAULT_DEVICE_TREE sandbox
#define CONFIG_FS_FAT
#define CONFIG_FS_EXT4
--
1.8.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 06/17] Add cmd_process_error() to report and process errors
U-Boot now uses errors defined in include/errno.h which are negative
integers. Commands which fail need to report the error and return 1
to indicate failure. Add this functionality in cmd_process_error().
For now this merely reports the error number. It would be possible
also to produce a helpful error message by storing the error strings
in U-Boot.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
common/command.c | 10 ++
include/command.h | 9 +
2 files changed, 19 insertions(+)
diff --git a/common/command.c b/common/command.c
index 625571d..668aa8b 100644
--- a/common/command.c
+++ b/common/command.c
@@ -538,3 +538,13 @@ enum command_ret_t cmd_process(int flag, int argc, char *
const argv[],
rc = cmd_usage(cmdtp);
return rc;
}
+
+int cmd_process_error(cmd_tbl_t *cmdtp, int err)
+{
+ if (err) {
+ printf(Command '%s' failed: Error %d\n, cmdtp-name, err);
+ return 1;
+ }
+
+ return 0;
+}
diff --git a/include/command.h b/include/command.h
index f782779..d3f700f 100644
--- a/include/command.h
+++ b/include/command.h
@@ -64,6 +64,15 @@ extern int var_complete(int argc, char * const argv[], char
last_char, int maxv,
extern int cmd_auto_complete(const char *const prompt, char *buf, int *np, int
*colp);
#endif
+/**
+ * cmd_process_error() - report and process a possible error
+ *
+ * @cmdtp: Command which caused the error
+ * @err: Error code (0 if none, -ve for error, like -EIO)
+ * @return 0 if there is not error, 1 (CMD_RET_FAILURE) if an error is found
+ */
+int cmd_process_error(cmd_tbl_t *cmdtp, int err);
+
/*
* Monitor Command
*
--
1.8.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 13/17] dm: Add a demonstration/example driver
As an example of how to write a uclass and a driver, provide a demo version
of each, accessible through the 'demo' command.
To use these with driver model, define CONFIG_CMD_DEMO and CONFIG_DM_DEMO.
The two demo drivers are enabled with CONFIG_DM_DEMO_SIMPLE and
CONFIG_DM_DEMO_SHAPE.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Marek Vasut ma...@denx.de
Signed-off-by: Pavel Herrmann morpheus.i...@gmail.com
Signed-off-by: Viktor Křivák viktor.kri...@gmail.com
Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
---
Changes in v6:
- Convert Makefiles to new Kconfig format
- Rename platform_data to platdata
- Use ofdata_to_platdata method to convert device tree data to platdata
Changes in v5:
- Change to new SPDX license headers
Changes in v4:
- Remove duplicated .op line
Changes in v3:
- Fix up demo command help
- Update demo driver to use device tree
Changes in v2: None
Makefile | 1 +
common/Makefile| 1 +
common/cmd_demo.c | 102
drivers/demo/Makefile | 9
drivers/demo/demo-pdata.c | 47 +
drivers/demo/demo-shape.c | 127 +
drivers/demo/demo-simple.c | 47 +
drivers/demo/demo-uclass.c | 58 +
include/configs/sandbox.h | 4 ++
include/dm-demo.h | 36 +
10 files changed, 432 insertions(+)
create mode 100644 common/cmd_demo.c
create mode 100644 drivers/demo/Makefile
create mode 100644 drivers/demo/demo-pdata.c
create mode 100644 drivers/demo/demo-shape.c
create mode 100644 drivers/demo/demo-simple.c
create mode 100644 drivers/demo/demo-uclass.c
create mode 100644 include/dm-demo.h
diff --git a/Makefile b/Makefile
index f4badca..7eaf6c9 100644
--- a/Makefile
+++ b/Makefile
@@ -301,6 +301,7 @@ LIBS-y += post/libpost.o
LIBS-y += test/libtest.o
LIBS-$(CONFIG_DM) += drivers/core/libdm.o
LIBS-y += test/dm/libtestdm.o
+LIBS-$(CONFIG_DM_DEMO) += drivers/demo/libdemo.o
ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35 mxs vf610))
LIBS-y += arch/$(ARCH)/imx-common/libimx-common.o
diff --git a/common/Makefile b/common/Makefile
index 32acbf9..f67c7f7 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -63,6 +63,7 @@ obj-$(CONFIG_CMD_CONSOLE) += cmd_console.o
obj-$(CONFIG_CMD_CPLBINFO) += cmd_cplbinfo.o
obj-$(CONFIG_DATAFLASH_MMC_SELECT) += cmd_dataflash_mmc_mux.o
obj-$(CONFIG_CMD_DATE) += cmd_date.o
+obj-$(CONFIG_CMD_DEMO) += cmd_demo.o
obj-$(CONFIG_CMD_SOUND) += cmd_sound.o
ifdef CONFIG_4xx
obj-$(CONFIG_CMD_SETGETDCR) += cmd_dcr.o
diff --git a/common/cmd_demo.c b/common/cmd_demo.c
new file mode 100644
index 000..a3bba7f
--- /dev/null
+++ b/common/cmd_demo.c
@@ -0,0 +1,102 @@
+/*
+ * Copyright (c) 2013 Google, Inc
+ *
+ * (C) Copyright 2012
+ * Pavel Herrmann morpheus.i...@gmail.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm-demo.h
+#include asm/io.h
+
+struct device *demo_dev;
+
+static int do_demo_hello(cmd_tbl_t *cmdtp, int flag, int argc,
+char * const argv[])
+{
+ int ch = 0;
+
+ if (argc)
+ ch = *argv[0];
+
+ return demo_hello(demo_dev, ch);
+}
+
+static int do_demo_status(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ int status;
+ int ret;
+
+ ret = demo_status(demo_dev, status);
+ if (ret)
+ return ret;
+
+ printf(Status: %d\n, status);
+
+ return 0;
+}
+
+int do_demo_list(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ struct device *dev;
+ int i, ret;
+
+ puts(Demo uclass entries:\n);
+
+ for (i = 0, ret = uclass_first_device(UCLASS_DEMO, dev);
+dev;
+ret = uclass_next_device(dev)) {
+ printf(entry %d - instance %08x, ops %08x, platdata %08x\n,
+ i++, map_to_sysmem(dev),
+ map_to_sysmem(dev-driver-ops),
+ map_to_sysmem(dev_get_platdata(dev)));
+ }
+
+ return cmd_process_error(cmdtp, ret);
+}
+
+static cmd_tbl_t demo_commands[] = {
+ U_BOOT_CMD_MKENT(list, 0, 1, do_demo_list, , ),
+ U_BOOT_CMD_MKENT(hello, 2, 1, do_demo_hello, , ),
+ U_BOOT_CMD_MKENT(status, 1, 1, do_demo_status, , ),
+};
+
+static int do_demo(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ cmd_tbl_t *demo_cmd;
+ int devnum = 0;
+ int ret;
+
+ if (argc 2)
+ return CMD_RET_USAGE;
+ demo_cmd = find_cmd_tbl(argv[1], demo_commands,
+ ARRAY_SIZE(demo_commands));
+ argc -= 2;
+ argv += 2;
+ if (!demo_cmd || argc demo_cmd-maxargs)
+ return CMD_RET_USAGE;
+
+ if (argc) {
+ devnum = simple_strtoul(argv[0], NULL, 10);
+ ret = uclass_get_device(UCLASS_DEMO, devnum, demo_dev);
+
[U-Boot] [PATCH v6 03/17] sandbox: Correct data sizes and printf() strings in fdtdec.c
There are a few warnings in this file when building for sandbox. Addresses
coming from the device tree need to be treated as ulong as elsewhere in
U-Boot and we must use map_sysmem() to convert to a pointer when needed.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
lib/fdtdec.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 51fa868..207314f 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -86,10 +86,10 @@ fdt_addr_t fdtdec_get_addr_size(const void *blob, int node,
size = (fdt_size_t *)((char *)cell +
sizeof(fdt_addr_t));
*sizep = fdt_size_to_cpu(*size);
- debug(addr=%p, size=%p\n, (void *)addr,
- (void *)*sizep);
+ debug(addr=%08lx, size=%08x\n,
+ (ulong)addr, *sizep);
} else {
- debug(%p\n, (void *)addr);
+ debug(%08lx\n, (ulong)addr);
}
return addr;
}
@@ -611,7 +611,7 @@ int fdtdec_decode_region(const void *blob, int node,
if (!cell || (len != sizeof(fdt_addr_t) * 2))
return -1;
- *ptrp = (void *)fdt_addr_to_cpu(*cell);
+ *ptrp = map_sysmem(fdt_addr_to_cpu(*cell), *size);
*size = fdt_size_to_cpu(cell[1]);
debug(%s: size=%zx\n, __func__, *size);
return 0;
--
1.8.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 10/17] dm: Set up driver model after relocation
Make driver model available after relocation, by setting up data structures
and scanning for devices using compiled-in platform_data and (when available)
the device tree.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v6:
- Rename platform_data to platdata
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
common/board_r.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/common/board_r.c b/common/board_r.c
index 86ca1cb..162562b 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -18,6 +18,7 @@
#ifdef CONFIG_HAS_DATAFLASH
#include dataflash.h
#endif
+#include dm.h
#include environment.h
#include fdtdec.h
#if defined(CONFIG_CMD_IDE)
@@ -51,7 +52,9 @@
#ifdef CONFIG_X86
#include asm/init_helpers.h
#endif
+#include dm/root.h
#include linux/compiler.h
+#include linux/err.h
DECLARE_GLOBAL_DATA_PTR;
@@ -263,6 +266,33 @@ static int initr_malloc(void)
return 0;
}
+#ifdef CONFIG_DM
+static int initr_dm(void)
+{
+ int ret;
+
+ ret = dm_init();
+ if (ret) {
+ debug(dm_init() failed: %d\n, ret);
+ return ret;
+ }
+ ret = dm_scan_platdata();
+ if (ret) {
+ debug(dm_scan_platdata() failed: %d\n, ret);
+ return ret;
+ }
+#ifdef CONFIG_OF_CONTROL
+ ret = dm_scan_fdt(gd-fdt_blob);
+ if (ret) {
+ debug(dm_scan_fdt() failed: %d\n, ret);
+ return ret;
+ }
+#endif
+
+ return 0;
+}
+#endif
+
__weak int power_init_board(void)
{
return 0;
@@ -761,6 +791,9 @@ init_fnc_t init_sequence_r[] = {
initr_barrier,
initr_malloc,
bootstage_relocate,
+#ifdef CONFIG_DM
+ initr_dm,
+#endif
#ifdef CONFIG_ARCH_EARLY_INIT_R
arch_early_init_r,
#endif
--
1.8.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 16/17] dm: Enable gpio command to support driver model
Now that named GPIO banks are supported, along with a way of obtaining
the status of a GPIO (input or output), we can provide an enhanced
GPIO command for driver model. Where the driver provides its own operation
for obtaining the GPIO state, this is used, otherwise a generic version
is sufficient.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
common/cmd_gpio.c | 127 --
1 file changed, 114 insertions(+), 13 deletions(-)
diff --git a/common/cmd_gpio.c b/common/cmd_gpio.c
index 47eee89..c6758c1 100644
--- a/common/cmd_gpio.c
+++ b/common/cmd_gpio.c
@@ -8,7 +8,7 @@
#include common.h
#include command.h
-
+#include dm.h
#include asm/gpio.h
#ifndef name_to_gpio
@@ -22,25 +22,115 @@ enum gpio_cmd {
GPIO_TOGGLE,
};
+#if defined(CONFIG_DM_GPIO) !defined(gpio_status)
+static const char * const gpio_function[] = {
+ input,
+ output,
+ unknown,
+};
+
+static void show_gpio(struct device *dev, const char *bank_name, int offset)
+{
+ struct dm_gpio_ops *ops = gpio_get_ops(dev);
+ char buf[80];
+ int ret;
+
+ *buf = '\0';
+ if (ops-get_state) {
+ ret = ops-get_state(dev, offset, buf, sizeof(buf));
+ if (ret) {
+ puts(unknown);
+ return;
+ }
+ } else {
+ int func = GPIOF_UNKNOWN;
+ int ret;
+
+ if (ops-get_function) {
+ ret = ops-get_function(dev, offset);
+ if (ret = 0 ret ARRAY_SIZE(gpio_function))
+ func = ret;
+ }
+ sprintf(buf, %s%u: %8s %d, bank_name, offset,
+ gpio_function[func], ops-get_value(dev, offset));
+ }
+
+ puts(buf);
+ puts(\n);
+}
+
+static int do_gpio_status(const char *gpio_name)
+{
+ struct device *dev;
+ int newline = 0;
+ int ret;
+
+ if (gpio_name !*gpio_name)
+ gpio_name = NULL;
+ for (ret = uclass_first_device(UCLASS_GPIO, dev);
+dev;
+ret = uclass_next_device(dev)) {
+ const char *bank_name;
+ int num_bits;
+
+ bank_name = gpio_get_bank_info(dev, num_bits);
+
+ if (!gpio_name || !bank_name ||
+ !strncmp(gpio_name, bank_name, strlen(bank_name))) {
+ const char *p = NULL;
+ int offset;
+
+ if (bank_name) {
+ if (newline)
+ putc('\n');
+ printf(Bank %s:\n, bank_name);
+ }
+ newline = 1;
+ if (gpio_name bank_name) {
+ p = gpio_name + strlen(bank_name);
+ offset = simple_strtoul(p, NULL, 10);
+ show_gpio(dev, bank_name, offset);
+ } else {
+ for (offset = 0; offset num_bits; offset++)
+ show_gpio(dev, bank_name, offset);
+ }
+ }
+ }
+
+ return ret;
+}
+#endif
+
static int do_gpio(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
- int gpio;
+ unsigned int gpio;
enum gpio_cmd sub_cmd;
ulong value;
- const char *str_cmd, *str_gpio;
+ const char *str_cmd, *str_gpio = NULL;
+#ifdef CONFIG_DM_GPIO
+ int ret;
+#endif
+ if (argc 2)
+ show_usage:
+ return CMD_RET_USAGE;
+ str_cmd = argv[1];
+ if (argc 2)
+ str_gpio = argv[2];
+ if (!strcmp(str_cmd, status)) {
+ /* Support deprecated gpio_status() */
#ifdef gpio_status
- if (argc == 2 !strcmp(argv[1], status)) {
gpio_status();
return 0;
- }
+#elif defined(CONFIG_DM_GPIO)
+ return cmd_process_error(cmdtp, do_gpio_status(str_gpio));
+#else
+ goto show_usage;
#endif
+ }
- if (argc != 3)
- show_usage:
- return CMD_RET_USAGE;
- str_cmd = argv[1];
- str_gpio = argv[2];
+ if (!str_gpio)
+ goto show_usage;
/* parse the behavior */
switch (*str_cmd) {
@@ -51,11 +141,21 @@ static int do_gpio(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
default: goto show_usage;
}
+#if defined(CONFIG_DM_GPIO)
+ /*
+* TODO(s...@chromium.org): Convert this code over to use the GPIO
+* uclass interface instead of the numbered GPIO compatibility
+* layer.
+*/
+ ret = gpio_lookup_name(str_gpio, NULL, NULL, gpio);
+ if (ret)
+
[U-Boot] [PATCH v6 02/17] sandbox: Make map_to_sysmem() use a constant pointer
Very often a constant pointer is passed to this function, so we should
declare this, since map_to_sysmem() does not change the pointer.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
arch/sandbox/include/asm/io.h | 2 +-
include/common.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/sandbox/include/asm/io.h b/arch/sandbox/include/asm/io.h
index 9ac6a5f..7956041 100644
--- a/arch/sandbox/include/asm/io.h
+++ b/arch/sandbox/include/asm/io.h
@@ -38,6 +38,6 @@ static inline void unmap_sysmem(const void *vaddr)
}
/* Map from a pointer to our RAM buffer */
-phys_addr_t map_to_sysmem(void *ptr);
+phys_addr_t map_to_sysmem(const void *ptr);
#endif
diff --git a/include/common.h b/include/common.h
index 409515f..8ca67f6 100644
--- a/include/common.h
+++ b/include/common.h
@@ -923,7 +923,7 @@ static inline void unmap_sysmem(const void *vaddr)
{
}
-static inline phys_addr_t map_to_sysmem(void *ptr)
+static inline phys_addr_t map_to_sysmem(const void *ptr)
{
return (phys_addr_t)(uintptr_t)ptr;
}
--
1.8.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 01/17] sandbox: Add timer_read_counter() to avoid link error
The recent timer refactor caused sandbox to fail to build with an error.
lib/libgeneric.o: In function `get_ticks':
/home/sjg/c/src/third_party/u-boot/files/lib/time.c:45: undefined reference to
`timer_read_counter'
Add a definition for timer_read_counter() to avoid this.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v6:
- Add new patch to fix sandbox link error
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None
board/sandbox/sandbox/sandbox.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/board/sandbox/sandbox/sandbox.c b/board/sandbox/sandbox/sandbox.c
index f471cb7..ee64fc4 100644
--- a/board/sandbox/sandbox/sandbox.c
+++ b/board/sandbox/sandbox/sandbox.c
@@ -23,6 +23,12 @@ ulong get_tbclk(void)
return CONFIG_SYS_HZ;
}
+/* Provide this dummy function to avoid a link error */
+unsigned long timer_read_counter(void)
+{
+ return 0;
+}
+
unsigned long long get_ticks(void)
{
return get_timer(0);
--
1.8.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 12/17] dm: Add a 'dm' command for testing
This command is not required for driver model operation, but can be useful
for testing. It provides simple dumps of internal data structures.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Marek Vasut ma...@denx.de
Signed-off-by: Pavel Herrmann morpheus.i...@gmail.com
Signed-off-by: Viktor Křivák viktor.kri...@gmail.com
Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
---
Changes in v6: None
Changes in v5:
- Change to new SPDX license headers
Changes in v4:
- Change 'dm dump' command to 'dm tree'
Changes in v3: None
Changes in v2: None
include/configs/sandbox.h | 1 +
test/dm/Makefile | 1 +
test/dm/cmd_dm.c | 133 ++
3 files changed, 135 insertions(+)
create mode 100644 test/dm/cmd_dm.c
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index a41f372..66a6a89 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -19,6 +19,7 @@
#define CONFIG_BOOTSTAGE
#define CONFIG_BOOTSTAGE_REPORT
#define CONFIG_DM
+#define CONFIG_CMD_DM
#define CONFIG_DM_TEST
/* Number of bits in a C 'long' on this architecture */
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 6af85b9..4e9afe6 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -4,6 +4,7 @@
# SPDX-License-Identifier: GPL-2.0+
#
+obj-$(CONFIG_CMD_DM) += cmd_dm.o
obj-$(CONFIG_DM_TEST) += test-driver.o
obj-$(CONFIG_DM_TEST) += test-fdt.o
obj-$(CONFIG_DM_TEST) += test-main.o
diff --git a/test/dm/cmd_dm.c b/test/dm/cmd_dm.c
new file mode 100644
index 000..a03fe20
--- /dev/null
+++ b/test/dm/cmd_dm.c
@@ -0,0 +1,133 @@
+/*
+ * Copyright (c) 2013 Google, Inc
+ *
+ * (C) Copyright 2012
+ * Marek Vasut ma...@denx.de
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include malloc.h
+#include errno.h
+#include asm/io.h
+#include dm/root.h
+#include dm/test.h
+#include dm/uclass-internal.h
+
+static int display_succ(struct device *in, char *buf)
+{
+ int len;
+ int ip = 0;
+ char local[16];
+ struct device *pos, *n, *prev = NULL;
+
+ printf(%s- %s @ %08x, buf, in-name, map_to_sysmem(in));
+ if (in-flags DM_FLAG_ACTIVATED)
+ puts( - activated);
+ puts(\n);
+
+ if (list_empty(in-child_head))
+ return 0;
+
+ len = strlen(buf);
+ strncpy(local, buf, sizeof(local));
+ snprintf(local + len, 2, |);
+ if (len local[len - 1] == '`')
+ local[len - 1] = ' ';
+
+ list_for_each_entry_safe(pos, n, in-child_head, sibling_node) {
+ if (ip++)
+ display_succ(prev, local);
+ prev = pos;
+ }
+
+ snprintf(local + len, 2, `);
+ display_succ(prev, local);
+
+ return 0;
+}
+
+static int dm_dump(struct device *dev)
+{
+ if (!dev)
+ return -EINVAL;
+ return display_succ(dev, );
+}
+
+static int do_dm_dump_all(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ struct device *root;
+
+ root = dm_root();
+ printf(ROOT %08x\n, map_to_sysmem(root));
+ return dm_dump(root);
+}
+
+static int do_dm_dump_uclass(cmd_tbl_t *cmdtp, int flag, int argc,
+char * const argv[])
+{
+ struct uclass *uc;
+ int ret;
+ int id;
+
+ for (id = 0; id UCLASS_COUNT; id++) {
+ struct device *dev;
+
+ ret = uclass_get(id, uc);
+ if (ret)
+ continue;
+
+ printf(uclass %d: %s\n, id, uc-uc_drv-name);
+ for (ret = uclass_first_device(id, dev);
+dev;
+ret = uclass_next_device(dev)) {
+ printf( %s @ %08x:\n, dev-name,
+ map_to_sysmem(dev));
+ }
+ puts(\n);
+ }
+
+ return 0;
+}
+
+static int do_dm_test(cmd_tbl_t *cmdtp, int flag, int argc,
+ char * const argv[])
+{
+ return dm_test_main();
+}
+
+static cmd_tbl_t test_commands[] = {
+ U_BOOT_CMD_MKENT(tree, 0, 1, do_dm_dump_all, , ),
+ U_BOOT_CMD_MKENT(uclass, 1, 1, do_dm_dump_uclass, , ),
+ U_BOOT_CMD_MKENT(test, 1, 1, do_dm_test, , ),
+};
+
+static int do_dm(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+ cmd_tbl_t *test_cmd;
+ int ret;
+
+ if (argc != 2)
+ return CMD_RET_USAGE;
+ test_cmd = find_cmd_tbl(argv[1], test_commands,
+ ARRAY_SIZE(test_commands));
+ argc -= 2;
+ argv += 2;
+ if (!test_cmd || argc test_cmd-maxargs)
+ return CMD_RET_USAGE;
+
+ ret = test_cmd-cmd(test_cmd, flag, argc, argv);
+
+ return cmd_process_error(test_cmd, ret);
+}
+
+U_BOOT_CMD(
+ dm, 2, 1, do_dm,
+ Driver model low level access,
+ tree Dump driver model
[U-Boot] [PATCH v6 14/17] dm: Add GPIO support and tests
Add driver model support for GPIOs. Since existing GPIO drivers do not use
driver model, this feature must be enabled by CONFIG_DM_GPIO. After all
GPO drivers are converted over we can perhaps remove this config.
Tests are provided for the sandbox implementation, and are a sufficient
sanity check for basic operation.
The GPIO uclass understands the concept of named banks of GPIOs, with each
GPIO device providing a single bank. Within each bank the GPIOs are numbered
using an offset from 0 to n-1. For example a bank named 'b' with 20
offsets will provide GPIOs named b0 to b19.
Anonymous GPIO banks are also supported, and are just numbered without any
prefix.
Each time a GPIO driver is added to the uclass, the GPIOs are renumbered
accordinging, so there is always a global GPIO numbering order.
Signed-off-by: Simon Glass s...@chromium.org
Signed-off-by: Marek Vasut ma...@denx.de
Signed-off-by: Pavel Herrmann morpheus.i...@gmail.com
Signed-off-by: Viktor Křivák viktor.kri...@gmail.com
Signed-off-by: Tomas Hlavacek tmshl...@gmail.com
---
Changes in v6:
- Rename platform_data to platdata
Changes in v5:
- Change to new SPDX license headers
Changes in v4: None
Changes in v3:
- Tidy up comments/documentation in GPIO module
- Update GPIO support to use new struct member names
Changes in v2: None
drivers/gpio/Makefile | 2 +
drivers/gpio/gpio-uclass.c | 266 +
include/asm-generic/gpio.h | 104 ++
test/dm/gpio.c | 111 +++
4 files changed, 483 insertions(+)
create mode 100644 drivers/gpio/gpio-uclass.c
create mode 100644 test/dm/gpio.c
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 1165793..eb1b1e7 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -5,6 +5,8 @@
# SPDX-License-Identifier: GPL-2.0+
#
+obj-$(CONFIG_DM_GPIO) += gpio-uclass.o
+
obj-$(CONFIG_AT91_GPIO)+= at91_gpio.o
obj-$(CONFIG_INTEL_ICH6_GPIO) += intel_ich6_gpio.o
obj-$(CONFIG_KIRKWOOD_GPIO)+= kw_gpio.o
diff --git a/drivers/gpio/gpio-uclass.c b/drivers/gpio/gpio-uclass.c
new file mode 100644
index 000..56bfd11
--- /dev/null
+++ b/drivers/gpio/gpio-uclass.c
@@ -0,0 +1,266 @@
+/*
+ * Copyright (c) 2013 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include dm.h
+#include errno.h
+#include asm/gpio.h
+
+/**
+ * gpio_to_device() - Convert global GPIO number to device, number
+ * gpio: The numeric representation of the GPIO
+ *
+ * Convert the GPIO number to an entry in the list of GPIOs
+ * or GPIO blocks registered with the GPIO controller. Returns
+ * entry on success, NULL on error.
+ */
+static int gpio_to_device(unsigned int gpio, struct device **devp,
+ unsigned int *offset)
+{
+ struct gpio_dev_priv *uc_priv;
+ struct device *dev;
+ int ret;
+
+ for (ret = uclass_first_device(UCLASS_GPIO, dev);
+dev;
+ret = uclass_next_device(dev)) {
+ uc_priv = dev-uclass_priv;
+ if (gpio = uc_priv-gpio_base
+ gpio uc_priv-gpio_base + uc_priv-gpio_count) {
+ *devp = dev;
+ *offset = gpio - uc_priv-gpio_base;
+ return 0;
+ }
+ }
+
+ /* No such GPIO */
+ return ret ? ret : -EINVAL;
+}
+
+int gpio_lookup_name(const char *name, struct device **devp,
+unsigned int *offsetp, unsigned int *gpiop)
+{
+ struct gpio_dev_priv *uc_priv;
+ struct device *dev;
+ int ret;
+
+ if (devp)
+ *devp = NULL;
+ for (ret = uclass_first_device(UCLASS_GPIO, dev);
+dev;
+ret = uclass_next_device(dev)) {
+ ulong offset;
+ int len;
+
+ uc_priv = dev-uclass_priv;
+ len = uc_priv-bank_name ? strlen(uc_priv-bank_name) : 0;
+
+ if (!strncmp(name, uc_priv-bank_name, len)) {
+ if (strict_strtoul(name + len, 10, offset))
+ continue;
+ if (devp)
+ *devp = dev;
+ if (offsetp)
+ *offsetp = offset;
+ if (gpiop)
+ *gpiop = uc_priv-gpio_base + offset;
+ return 0;
+ }
+ }
+
+ return ret ? ret : -EINVAL;
+}
+
+/**
+ * gpio_request() - [COMPAT] Request GPIO
+ * gpio: GPIO number
+ * label: Name for the requested GPIO
+ *
+ * This function implements the API that's compatible with current
+ * GPIO API used in U-Boot. The request is forwarded to particular
+ * GPIO driver. Returns 0 on success, negative value on error.
+ */
+int gpio_request(unsigned gpio, const char *label)
+{
+ unsigned int offset;
+ struct device *dev;
+ int ret;
+
+ ret
[U-Boot] [PATCH v6 11/17] dm: Add basic tests
Add some tests of driver model functionality. Coverage includes:
- basic init
- binding of drivers to devices using platform_data
- automatic probing of devices when referenced
- availability of platform data to devices
- lifecycle from bind to probe to remove to unbind
- renumbering within a uclass when devices are probed/removed
- calling driver-defined operations
- deactivation of drivers when removed
- memory leak across creation and destruction of drivers/uclasses
- uclass init/destroy methods
- automatic probe/remove of children/parents when needed
This function is enabled for sandbox, using CONFIG_DM_TEST.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v6:
- Add a test script for driver model
- Convert Makefiles to new Kconfig format
- Rename platform_data to platdata
- Use ofdata_to_platdata feature
Changes in v5:
- Change to new SPDX license headers
- Fix style nit on for() loop
Changes in v4:
- Correct 'out.dtb' typo
Changes in v3:
- Add function/struct comments to tests
Changes in v2: None
Makefile | 1 +
include/configs/sandbox.h | 1 +
include/dm/test.h | 167 ++
include/dm/ut.h | 95
test/dm/.gitignore| 1 +
test/dm/Makefile | 17 ++
test/dm/core.c| 544 ++
test/dm/test-dm.sh| 7 +
test/dm/test-driver.c | 146 +
test/dm/test-fdt.c| 144
test/dm/test-main.c | 107 +
test/dm/test-uclass.c | 104 +
test/dm/test.dts | 59 +
test/dm/ut.c | 33 +++
14 files changed, 1426 insertions(+)
create mode 100644 include/dm/test.h
create mode 100644 include/dm/ut.h
create mode 100644 test/dm/.gitignore
create mode 100644 test/dm/Makefile
create mode 100644 test/dm/core.c
create mode 100755 test/dm/test-dm.sh
create mode 100644 test/dm/test-driver.c
create mode 100644 test/dm/test-fdt.c
create mode 100644 test/dm/test-main.c
create mode 100644 test/dm/test-uclass.c
create mode 100644 test/dm/test.dts
create mode 100644 test/dm/ut.c
diff --git a/Makefile b/Makefile
index 6e3eb8c..f4badca 100644
--- a/Makefile
+++ b/Makefile
@@ -300,6 +300,7 @@ LIBS-y += api/libapi.o
LIBS-y += post/libpost.o
LIBS-y += test/libtest.o
LIBS-$(CONFIG_DM) += drivers/core/libdm.o
+LIBS-y += test/dm/libtestdm.o
ifneq (,$(filter $(SOC), mx25 mx27 mx5 mx6 mx31 mx35 mxs vf610))
LIBS-y += arch/$(ARCH)/imx-common/libimx-common.o
diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index 6855e7d..a41f372 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -19,6 +19,7 @@
#define CONFIG_BOOTSTAGE
#define CONFIG_BOOTSTAGE_REPORT
#define CONFIG_DM
+#define CONFIG_DM_TEST
/* Number of bits in a C 'long' on this architecture */
#define CONFIG_SANDBOX_BITS_PER_LONG 64
diff --git a/include/dm/test.h b/include/dm/test.h
new file mode 100644
index 000..eeaa2eb
--- /dev/null
+++ b/include/dm/test.h
@@ -0,0 +1,167 @@
+/*
+ * Copyright (c) 2013 Google, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __DM_TEST_H
+#define __DM_TEST_H
+
+#include dm.h
+
+/**
+ * struct dm_test_cdata - configuration data for test instance
+ *
+ * @ping_add: Amonut to add each time we get a ping
+ * @base: Base address of this device
+ */
+struct dm_test_pdata {
+ int ping_add;
+ uint32_t base;
+};
+
+/**
+ * struct test_ops - Operations supported by the test device
+ *
+ * @ping: Ping operation
+ * @dev: Device to operate on
+ * @pingval: Value to ping the device with
+ * @pingret: Returns resulting value from driver
+ * @return 0 if OK, -ve on error
+ */
+struct test_ops {
+ int (*ping)(struct device *dev, int pingval, int *pingret);
+};
+
+/* Operations that our test driver supports */
+enum {
+ DM_TEST_OP_BIND = 0,
+ DM_TEST_OP_UNBIND,
+ DM_TEST_OP_PROBE,
+ DM_TEST_OP_REMOVE,
+
+ /* For uclass */
+ DM_TEST_OP_POST_BIND,
+ DM_TEST_OP_PRE_UNBIND,
+ DM_TEST_OP_POST_PROBE,
+ DM_TEST_OP_PRE_REMOVE,
+ DM_TEST_OP_INIT,
+ DM_TEST_OP_DESTROY,
+
+ DM_TEST_OP_COUNT,
+};
+
+/* Test driver types */
+enum {
+ DM_TEST_TYPE_FIRST = 0,
+ DM_TEST_TYPE_SECOND,
+};
+
+/* The number added to the ping total on each probe */
+#define DM_TEST_START_TOTAL5
+
+/**
+ * struct dm_test_priv - private data for the test devices
+ */
+struct dm_test_priv {
+ int ping_total;
+ int op_count[DM_TEST_OP_COUNT];
+};
+
+/**
+ * struct dm_test_perdev_class_priv - private per-device data for test uclass
+ */
+struct dm_test_uclass_perdev_priv {
+ int base_add;
+};
+
+/**
+ * struct dm_test_uclass_priv - private data for test uclass
+ */
+struct dm_test_uclass_priv {
+ int total_add;
+};
+
+/*
+ * Operation counts for the test driver, used to check that each method is
+ * called correctly
+ */
+extern int
[U-Boot] [PATCH v6 07/17] dm: Add README for driver model
This adds a README to help with understanding of this series. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v6: - Rename platform_data to platdata - Revise and update README Changes in v5: None Changes in v4: None Changes in v3: - Updated README.txt to cover changes since version 2 Changes in v2: - Add GPIO uclass and tests - Add U_BOOT_DEVICE to declare platform_data - Add a single include/dm.h to bring in driver model code - Add auto-probing feature for platform_data to avoid driver_bind() calls - Add automatic allocation of device-specific priv data for uclasses - Add automatic allocation of platform_data for FDT - Add automatic allocation of priv data for devices - Add device tree support in driver model - Add dm_warn() to warn about impending doom - Add integration tests for driver model - Add new header file for lists - Add new util file to hold utility functions - Add sandbox GPIO driver - Add script to run tests - Add simple unit test functions - Add test infrastructure for driver model - Add tests for core code - Allow a driver to bind to only one uclass - Allow driver_bind() to support a NULL parent - Put platform_data definitions in their own header file - Remove relocation functions - Remove unneeded arguments to uclass_bind(), uclass_unbind() - Removed pointer return values in favour of integer - Rename data structures to hopefully be clearer - Rename struct device's 'bus' to 'parent' - Standardise variable names (e.g. uclass instead of class) - Update gpio command to use driver model - Use driver_bind() in dm_init() instead of writing new code doc/driver-model/README.txt | 368 1 file changed, 368 insertions(+) create mode 100644 doc/driver-model/README.txt diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt new file mode 100644 index 000..22c1481 --- /dev/null +++ b/doc/driver-model/README.txt @@ -0,0 +1,368 @@ +Driver Model + + +This README contains high-level information about driver model, a unified +way of declaring and accessing drivers in U-Boot. The original work was done +by: + + Marek Vasut ma...@denx.de + Pavel Herrmann morpheus.i...@gmail.com + Viktor Křivák viktor.kri...@gmail.com + Tomas Hlavacek tmshl...@gmail.com + +This has been both simplified and extended into the current implementation +by: + + Simon Glass s...@chromium.org + + +Terminology +--- + +Uclass - a group of device which operate in the same way. A uclass provides + a way of accessing invidual devices within the group, but always + using the same interface. For example a GPIO uclass provides + operations for get/set value. An I2C uclass may have 10 I2C ports, + 4 with one driver, and 6 with another. + +Driver - some code which talks to a peripheral and presents a higher-level + interface to it. + +Device - an instance of a driver, tied to a particular port or peripheral. + + +How to try it +- + +Build U-Boot sandbox and run it: + + make sandbox_config + make + ./u-boot + + (type 'reset' to exit U-Boot) + + +There is a uclass called 'demo'. This uclass handles +saying hello, and reporting its status. There are two drivers in this +uclass: + + - simple: Just prints a message for hello, doesn't implement status + - shape: Prints shapes and reports number of characters printed as status + +The demo class is pretty simple, but not trivial. The intention is that it +can be used for testing, so it will implement all driver model features and +provide good code coverage of them. It does have multiple drivers, it +handles parameter data and platdata (data which tells the driver how +to operate on a particular platform) and it uses private driver data. + +To try it, see the example session below: + +=demo hello 1 +Hello '@' from 07981110: red 4 +=demo status 2 +Status: 0 +=demo hello 2 +g +r@ +e@@ +e@@@ +n +g@ +=demo status 2 +Status: 21 +=demo hello 4 ^ + y^^^ + e^ +l^^^ +l^^^ + o^ + w^^^ +=demo status 4 +Status: 36 += + + +Running the tests +- + +The intent with driver model is that the core portion has 100% test coverage +in sandbox, and every uclass has its own test. As a move towards this, tests +are provided in test/dm. To run them, try: + + ./test/dm/test-dm.sh + +You should see something like this: + +...U-Boot banner... +Running 12 driver model tests +Test: dm_test_autobind +Test: dm_test_autoprobe +Test: dm_test_children +Test: dm_test_fdt +Test: dm_test_gpio +sandbox_gpio: sb_gpio_get_value: error: offset 4 not reserved +Test: dm_test_leak +Warning: Please add '#define DEBUG' to the top of common/dlmalloc.c +Warning: Please add '#define DEBUG' to the top of common/dlmalloc.c +Test: dm_test_lifecycle +Test: dm_test_operations +Test: dm_test_ordering +Test: dm_test_platdata +Test: dm_test_remove +Test: dm_test_uclass +Failures: 0
[U-Boot] [PATCH v6 04/17] sandbox: config: Don't use 64-bit physical memory
Sandbox uses an emulated memory map which is quite small. We don't need the CONFIG_PHYS_64BIT option since we can address memory with a 32-bit offset into our ram_buf. Adjust the phys_addr_t and phys_size_t types accordingly. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v6: None Changes in v5: None Changes in v4: None Changes in v3: None Changes in v2: None arch/sandbox/include/asm/types.h | 4 ++-- include/configs/sandbox.h| 1 - 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/sandbox/include/asm/types.h b/arch/sandbox/include/asm/types.h index 88c84ba..6d3eb1f 100644 --- a/arch/sandbox/include/asm/types.h +++ b/arch/sandbox/include/asm/types.h @@ -48,8 +48,8 @@ typedef unsigned long long u64; #define BITS_PER_LONG CONFIG_SANDBOX_BITS_PER_LONG typedef unsigned long dma_addr_t; -typedef unsigned long phys_addr_t; -typedef unsigned long phys_size_t; +typedef u32 phys_addr_t; +typedef u32 phys_size_t; #endif /* __KERNEL__ */ diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h index 279abbc..bce889e 100644 --- a/include/configs/sandbox.h +++ b/include/configs/sandbox.h @@ -69,7 +69,6 @@ #define CONFIG_SYS_LOAD_ADDR 0x #define CONFIG_SYS_MEMTEST_START 0x0010 #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + 0x1000) -#define CONFIG_PHYS_64BIT #define CONFIG_SYS_FDT_LOAD_ADDR 0x100 /* Size of our emulated memory */ -- 1.8.4.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] am33xx: Stop modifying certain EMIF4D registers
Based on the definitive guide to EMIF configuration[1] certain registers
that we have been modifying (and are documented registers) should be
left in their reset values rather than modified. This has been tested
on AM335x GP EVM and Beaglebone White.
[1]: http://processors.wiki.ti.com/index.php/AM335x_EMIF_Configuration_tips
Cc: Enric Balletbo i Serra eballe...@iseebcn.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Cc: Heiko Schocher h...@denx.de
Cc: Matt Porter matt.por...@linaro.org
Cc: Lars Poeschel poesc...@lemonage.de
Signed-off-by: Tom Rini tr...@ti.com
---
arch/arm/cpu/armv7/am33xx/ddr.c |7 --
arch/arm/include/asm/arch-am33xx/ddr_defs.h | 31 ++-
board/isee/igep0033/board.c |4
board/phytec/pcm051/board.c |4
board/siemens/dxr2/board.c |4
board/siemens/pxm2/board.c |5 -
board/siemens/rut/board.c |5 -
board/ti/am335x/board.c | 17 ---
board/ti/ti814x/evm.c |5 -
board/ti/ti816x/evm.c | 17 ---
10 files changed, 6 insertions(+), 93 deletions(-)
diff --git a/arch/arm/cpu/armv7/am33xx/ddr.c b/arch/arm/cpu/armv7/am33xx/ddr.c
index fa697c7..5b0454c 100644
--- a/arch/arm/cpu/armv7/am33xx/ddr.c
+++ b/arch/arm/cpu/armv7/am33xx/ddr.c
@@ -89,15 +89,12 @@ void config_ddr_phy(const struct emif_regs *regs, int nr)
void config_cmd_ctrl(const struct cmd_control *cmd, int nr)
{
writel(cmd-cmd0csratio, ddr_cmd_reg[nr]-cm0csratio);
- writel(cmd-cmd0dldiff, ddr_cmd_reg[nr]-cm0dldiff);
writel(cmd-cmd0iclkout, ddr_cmd_reg[nr]-cm0iclkout);
writel(cmd-cmd1csratio, ddr_cmd_reg[nr]-cm1csratio);
- writel(cmd-cmd1dldiff, ddr_cmd_reg[nr]-cm1dldiff);
writel(cmd-cmd1iclkout, ddr_cmd_reg[nr]-cm1iclkout);
writel(cmd-cmd2csratio, ddr_cmd_reg[nr]-cm2csratio);
- writel(cmd-cmd2dldiff, ddr_cmd_reg[nr]-cm2dldiff);
writel(cmd-cmd2iclkout, ddr_cmd_reg[nr]-cm2iclkout);
}
@@ -121,10 +118,6 @@ void config_ddr_data(const struct ddr_data *data, int nr)
(ddr_data_reg[nr]+i)-dt0fwsratio0);
writel(data-datawrsratio0,
(ddr_data_reg[nr]+i)-dt0wrsratio0);
- writel(data-datauserank0delay,
- (ddr_data_reg[nr]+i)-dt0rdelays0);
- writel(data-datadldiff0,
- (ddr_data_reg[nr]+i)-dt0dldiff0);
}
}
diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
index fe48b5f..e5bda64 100644
--- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
+++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
@@ -18,7 +18,6 @@
#define VTP_CTRL_READY (0x1 5)
#define VTP_CTRL_ENABLE(0x1 6)
#define VTP_CTRL_START_EN (0x1)
-#define PHY_DLL_LOCK_DIFF 0x0
#define DDR_CKE_CTRL_NORMAL0x1
#define PHY_EN_DYN_PWRDN (0x1 20)
@@ -29,7 +28,6 @@
#define MT47H128M16RT25E_EMIF_TIM3 0x033F
#define MT47H128M16RT25E_EMIF_SDCFG0x41805332
#define MT47H128M16RT25E_EMIF_SDREF0x081a
-#define MT47H128M16RT25E_DLL_LOCK_DIFF 0x0
#define MT47H128M16RT25E_RATIO 0x80
#define MT47H128M16RT25E_INVERT_CLKOUT 0x00
#define MT47H128M16RT25E_RD_DQS0x12
@@ -38,7 +36,6 @@
#define MT47H128M16RT25E_PHY_GATELVL 0x00
#define MT47H128M16RT25E_PHY_WR_DATA 0x40
#define MT47H128M16RT25E_PHY_FIFO_WE 0x80
-#define MT47H128M16RT25E_PHY_RANK0_DELAY 0x1
#define MT47H128M16RT25E_IOCTRL_VALUE 0x18B
/* Micron MT41J128M16JT-125 */
@@ -49,7 +46,6 @@
#define MT41J128MJT125_EMIF_SDCFG 0x61C04AB2
#define MT41J128MJT125_EMIF_SDREF 0x093B
#define MT41J128MJT125_ZQ_CFG 0x50074BE4
-#define MT41J128MJT125_DLL_LOCK_DIFF 0x1
#define MT41J128MJT125_RATIO 0x40
#define MT41J128MJT125_INVERT_CLKOUT 0x1
#define MT41J128MJT125_RD_DQS 0x3B
@@ -66,7 +62,6 @@
#define MT41J256M8HX15E_EMIF_SDCFG 0x61C04B32
#define MT41J256M8HX15E_EMIF_SDREF 0x093B
#define MT41J256M8HX15E_ZQ_CFG 0x50074BE4
-#define MT41J256M8HX15E_DLL_LOCK_DIFF 0x1
#define MT41J256M8HX15E_RATIO 0x40
#define MT41J256M8HX15E_INVERT_CLKOUT 0x1
#define MT41J256M8HX15E_RD_DQS 0x3B
@@ -83,7 +78,6 @@
#define MT41K256M16HA125E_EMIF_SDCFG 0x61C05332
#define MT41K256M16HA125E_EMIF_SDREF 0xC30
#define MT41K256M16HA125E_ZQ_CFG 0x50074BE4
-#define MT41K256M16HA125E_DLL_LOCK_DIFF0x1
#define MT41K256M16HA125E_RATIO0x80
#define MT41K256M16HA125E_INVERT_CLKOUT
Re: [U-Boot] [PATCH] designware_i2c: disable i2c controller during target address setup
Hi Alexey, On Thu, 7 Nov 2013 17:52:18 +0400, Alexey Brodkin alexey.brod...@synopsys.com wrote: As it is stated in DesignWare I2C databook: writes to IC_TAR (0x4) register succeed only when IC_ENABLE[0] is set to 0. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Tom Rini tr...@ti.com cc: Armando Visconti armando.visco...@st.com Cc: Stefan Roese s...@denx.de Cc: Albert ARIBAUD albert.u.b...@aribaud.net Cc: Heiko Schocher h...@denx.de Cc: Vipin KUMAR vipin.ku...@st.com Cc: Tom Rix tom@windriver.com Cc: Mischa Jonker mjon...@synopsys.com --- /me wonders what made this patch Cc: me. Is it ARM-related in some way? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Dear Heiko, In message 527b8ba7.2070...@denx.de you wrote: Agreed too. I doubt if a mailing list makes sense to collect such data. It would probably be more efficient to provide a web based service for this. It just has to be easy to submit reports, and to query the status for boards. Ok, how would look like such a web based service? I have no idea. Not yet. Let's first define what we want to have, then think about how to implement it. I also think that should be done on release only. Why? To me it makes a lot of sense to also collect information on intermediate snapshots. Hmm.. I thought we get a test report (however this looks like in the end) based on a commit id in u-boot/master ... isn;t this enough? Yes, this is perfectly fine. I just want to allow this at _any_ time, not only once per release (near the end of the release cycle). especially for releases where bigger changes get merged it may be precious information to know when the code stopped working. I hesitate to automatically remove existing boards. Why would we want to do that? To reduce efforts, right? So I vote to keep boards as long as they are either maintained, or they at least do not hurt. Why the not hurt case? Is it really good to have a lot of boards, which compile clean, but we do not know, if the code really works? Well, one reason is efficiency. If the code builds fine, and does not cause efforts druing any of the ongoing work, it is more efficient to just keep it than to actively remove it, which would require active work. I. e. I want to reduce the work load on the maintainer(s) such that they only have to become active if such action saves even more effort. Actually it may even seem more efficient in some cases to perform minor fixing even of unmaintained boards than to remove them. I prefer to have in current mainline only boards, which really work or at least maintained... if a board maintainer did the work to bring it into mainline, it should be interested in stay in mainline. If this interest is lost and no other volunteers ... board is useless in mainline. But should we not also try to minimize efforts, especially on the custodians? If a board does not cause any trouble, we should not have to invent additional efforts for it. Ok, that is a way to go, if we have for all boards the information, in which maintainstate it is ... but think of for example the new i2c framework, how much boards use I2C? I have to check now all this boards, decide to delete it or convert it ... very time consuming frustrating work ... and maybe for a lot of do not hurt boards only waste of time ... :-( I don't really understand this argument. The I2C code is either hardware independent (say, the command line interface code), or it is platform specific (say, the driver code for the I2C controller on a specific SoC), or it is board dendent (say, some specific twiddeling with I2C devices to perform some magic operations on a board). In the first two cases the work wil have to be done in any case (except for the realy rare case that there are only old, unmaintained boards left using this SoC). An for the board specific code you can check if you need to adapt it by checking the board's test status. If the board is unmaintained, then we enter the it hurts branch, and drop the board. if we have a clean mainline state, where I know all boards are working the decision is clear, convert all ... and board maintainers will test it ... and we have always a clean compile state for mainline Again: you don't need any knowledge about boards that are not affected by your I2C changes. And if we have this test/delete cycle, I can be sure, that after a defined time all boards in mainline are working! Yes, but the cost is additional efforts, and being more aggressive than necessary. I dislike both. 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 Life would be so much easier if everyone read the manual. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Dear Heiko Schocher, In message 527b8c7f.6060...@denx.de you wrote: All you want to do here is feed a database with data. This is not what mailing lists were made for, so we should really use a more appropriate interface. Ok. But this status report can be in readable text format ;-) Yes, it can. So do you want to see 250 test passed messages for the BeagleBone or the Rasperry Pi for every few commits that get merged? I don't. In a database, we can automatically filter redundant information. You, you can use a mailing list for submitting such information, but I doubt that it would be efficient. And I definitely do not want to see this on the current U-Boot ML. 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 You ain't experienced... Well, nor are you. That's true. But the point is ... the point is ... the point is we've been not experienced for a lot longer than you. We've got a lot of experience of not having any experience. - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Dear Tom, In message 20131107133159.GR5925@bill-the-cat you wrote: I feel this is the hard part of the problem, and what we're glossing over. What has to be tested by the board maintainer? What are we going to leave to their discretion? Will am335x_evm not count if I don't dig up the NOR cape for it? Good question. Eventually this is something that develops over time. Intially, we might be satisfied with a very basic it works message, which may just mean that this specific version booted on the actual hardware. In the long run, we might provide a more detailed questionaire to the reported. I could for example imagine a tool that parses the board's config file and then provides some checkboxes - if there is NOR flash configured on the board, ask if NOR has been tested; similar for network, MMC, USB, ... other features. One day we might even have more developers using automatic test tools so we could generate information on a per-command base. I know that I'm just dreaming, but we should try to just be open for any such future extensions, even if we start really small now. I think we all agree that _any_ kind of test information will be better than none. 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 You see things; and you say ``Why?'' But I dream things that never were; and I say ``Why not?'' - George Bernard Shaw _Back to Methuselah_ (1921) pt. 1, act 1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
On Thu, Nov 07, 2013 at 08:26:57PM +0100, Wolfgang Denk wrote: Dear Tom, In message 20131107133159.GR5925@bill-the-cat you wrote: I feel this is the hard part of the problem, and what we're glossing over. What has to be tested by the board maintainer? What are we going to leave to their discretion? Will am335x_evm not count if I don't dig up the NOR cape for it? Good question. Eventually this is something that develops over time. Intially, we might be satisfied with a very basic it works message, which may just mean that this specific version booted on the actual hardware. In the long run, we might provide a more detailed questionaire to the reported. I could for example imagine a tool that parses the board's config file and then provides some checkboxes - if there is NOR flash configured on the board, ask if NOR has been tested; similar for network, MMC, USB, ... other features. One day we might even have more developers using automatic test tools so we could generate information on a per-command base. I know that I'm just dreaming, but we should try to just be open for any such future extensions, even if we start really small now. I think we all agree that _any_ kind of test information will be better than none. What we need to be careful of here is making sure whatever we grow is both useful and not overly complicated. What I honestly wonder about is automated testing for commands (crc32 pops to mind only because I just fixed things) but otherwise having things broken down into a front end where people select what they did Booted a ___ into ___ via ___, provide some output from a command (maybe add just a touch more info to 'version') and cover non-boot testing with copy/paste'able drop-downs. I know automated testing is The Thing, but given N frameworks, everyone of them has issues because frankly, every SoC family has its own quirks about how boot and load and what is and is not even feasible, especially for the bootloader. -- 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 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM
Hi Tom,
On Wed, Nov 6, 2013 at 4:37 PM, Tom Rini tr...@ti.com wrote:
+
+ if (header-magic != 0xEE3355AA) {
Why is the header the same as AM335x? Shouldn't it be something
like 0xEE3344AA or whatever?
No, the header is still same. It is 0xEE3355AA.
My question was why ;)
What's the point of adding the same magic value for a different SoC?
Unless there's a good reason for doing so i think this needs to be fixed
in the EEPROM programmer.
A magic value is sufficiently magical, I don't think we'll get anyone to
change it at this point.
With almost half a dozen of AM335x board variants floating around this
thing is bound to cause problems eventually. The EEPROM format
can simply be updated to fix this. If there's a big resistance in doing
this then we might as well live with it - but i would at least ask once ;)
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] livetime of boards
Dear Tom, In message 20131107205133.GT5925@bill-the-cat you wrote: What we need to be careful of here is making sure whatever we grow is both useful and not overly complicated. What I honestly wonder about is automated testing for commands (crc32 pops to mind only because I just fixed things) but otherwise having things broken down into a front end where people select what they did Booted a ___ into ___ via ___, provide some output from a command (maybe add just a touch more info to 'version') and cover non-boot testing with copy/paste'able drop-downs. I know automated testing is The Thing, but given N frameworks, everyone of them has issues because frankly, every SoC family has its own quirks about how boot and load and what is and is not even feasible, especially for the bootloader. Agreed. In the end, you will probably define a specific set of test cases that can be run automatically on a board. We will never have 100% coverage, nor any generic set of tests that fits all boards. OK, a pretty large sub-set of common functionality can be tested in the sandbox, which is a great achievement ... I still firmly belive that the approach we've taken a long time ago, i. e. to use a test framework (DUTS) in combination with a (today wiki based) documentation framework (DULG) is something that can meet a wide range of requirements. Unfortunately, we haven't been able yet to find a test framework that makes it easy for the average user to add new test cases. I'm not even talking here about the core of the framework, that has to deal with things like attaching to the console of a board, control power and/or reset state, detect if a JTAG debugger is attached and such things. In the current state, our code is expect based (and thus implemented in tcl), and it's really a PITA to add new test cases to it. BUt it would require significant efforts to rwrite this in a more modern context... 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 In C we had to code our own bugs, in C++ we can inherit them. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/2013 03:56 PM, Vaibhav Bedia wrote:
Hi Tom,
On Wed, Nov 6, 2013 at 4:37 PM, Tom Rini tr...@ti.com wrote:
+
+ if (header-magic != 0xEE3355AA) {
Why is the header the same as AM335x? Shouldn't it be something
like 0xEE3344AA or whatever?
No, the header is still same. It is 0xEE3355AA.
My question was why ;)
What's the point of adding the same magic value for a different SoC?
Unless there's a good reason for doing so i think this needs to be fixed
in the EEPROM programmer.
A magic value is sufficiently magical, I don't think we'll get anyone to
change it at this point.
With almost half a dozen of AM335x board variants floating around this
thing is bound to cause problems eventually. The EEPROM format
can simply be updated to fix this. If there's a big resistance in doing
this then we might as well live with it - but i would at least ask once ;)
The thing is, customers drop the EEPROM or come up with their own, see
the Siemens am335x boards :)
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSfADXAAoJENk4IS6UOR1WRa0P/1EMaiNOZsztbkdosA+Gja5y
/FDdvJl8fWrKKMY0gBUNIplFNev2cDdOyb0EdglD77oinYM8cpdYHkh1rhZEv7rA
kvx5rFZ0iOftuavbgtUEBcTs2/oLbFjKZV8ajCkwuFig6E1XY49yeT9obsB9UKxG
uBYIs75SYBPZg/8RzDlQbwpyBR/3cSwRQ9t61p21lQVnZvenIwNPhVxCg++jxtdT
i0IuzraMwcdUXKIBoBkE6Lu+vYgbi4yWcrPIrllxo5C3vRkw9ua6rRHB9qTG60xM
V02CSxm9UTfrg4yMlBZHMkPDAHcbAirV4+z70vMdqsffzMhGspL3/Lo8+bf6FD31
xnlws8IVJTLjNTLL/ZZ6POcPXI2rHsLkdfVQoXYWVBVmn5ZHvfrCEL2ahkYBG40Y
y2rzyw/QiFCZz8GXPHNV7NNDaVTaasw7ph7dJ03/a3yMBJJNIK7OV3EdR22dtgUe
a2734X2DWbPQtdovkH5YQMULXi5pYH6aCXMbcPGsGWVN8HZXuEOdmNdWkdFyoD4W
/l8vx63X5BdUCsrbahp6KI9Es4AZN/QbNGbn5oLSkf/qVDdJTxW3RrZ/wcgk+r3I
F7ufYYetQi0nOE+2ri0ayFgZNNqNCbUZKeZEuEMzUNXwPfY4CZDTov3fk2C4rnfk
PewbVnXTpc2lnUyjxD1v
=B5PZ
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/14] ARM: AM43xx: Select clk source for Timer2
Hi Lokesh, On Thu, Nov 7, 2013 at 8:43 AM, Lokesh Vutla lokeshvu...@ti.com wrote: Hi Vaibhav, On Wednesday 06 November 2013 06:10 PM, Vaibhav Bedia wrote: On Mon, Nov 4, 2013 at 11:20 PM, Lokesh Vutla lokeshvu...@ti.com wrote: Selecting the Master osc clk as Timer2 clock source. I obviously missed the first round of patches for AM43xx here. Why is timer2 being used here? Don't we use the synctimer and timer1 in the kernel? In u-boot there is already code present to handle timer2 in arch/arm/cpu/armv7/omap-common/timer.c(Registers offsets are different for timer1 and timer2) . Trying to reuse the same here. This is how it is done in am335x also. Correct me if I am wrong. On AM335x that timer is used in U-Boot in the delay loop and later gets used in the kernel as a system timer. On AM437x it might be a good idea to use synctimer since it has some stabilization period requirements and that's going to affect the kernel boot eventually. Regards, Vaibhav ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am33xx: Stop modifying certain EMIF4D registers
Hi Tom,
On Thu, Nov 7, 2013 at 11:42 AM, Tom Rini tr...@ti.com wrote:
Based on the definitive guide to EMIF configuration[1] certain registers
that we have been modifying (and are documented registers) should be
left in their reset values rather than modified. This has been tested
on AM335x GP EVM and Beaglebone White.
[...]
diff --git a/board/ti/ti814x/evm.c b/board/ti/ti814x/evm.c
index e406326..0b76a77 100644
--- a/board/ti/ti814x/evm.c
+++ b/board/ti/ti814x/evm.c
@@ -33,15 +33,12 @@ static struct ctrl_dev *cdev = (struct ctrl_dev
*)CTRL_DEVICE_BASE;
#ifdef CONFIG_SPL_BUILD
static const struct cmd_control evm_ddr2_cctrl_data = {
.cmd0csratio= 0x80,
- .cmd0dldiff = 0x04,
.cmd0iclkout= 0x00,
.cmd1csratio= 0x80,
- .cmd1dldiff = 0x04,
.cmd1iclkout= 0x00,
.cmd2csratio= 0x80,
- .cmd2dldiff = 0x04,
.cmd2iclkout= 0x00,
};
@@ -77,8 +74,6 @@ static const struct ddr_data evm_ddr2_data = {
.datagiratio0 = ((010) | (00)),
.datafwsratio0 = ((0x9010) | (0x900)),
.datawrsratio0 = ((0x5010) | (0x500)),
- .datauserank0delay = 1,
- .datadldiff0= 0x4,
};
void set_uart_mux_conf(void)
diff --git a/board/ti/ti816x/evm.c b/board/ti/ti816x/evm.c
index 74d35e9..a53859e 100644
--- a/board/ti/ti816x/evm.c
+++ b/board/ti/ti816x/evm.c
@@ -59,21 +59,16 @@ static struct ddr_data ddr2_data = {
.datagiratio0 = ((0x010) | (0x00)),
.datafwsratio0 = ((0x13A10) | (0x13A0)),
.datawrsratio0 = ((0x8A10) | (0x8A0)),
- .datauserank0delay = 0x1,
- .datadldiff0= 0x0, /* depend on cpu rev, set later */
};
static struct cmd_control ddr2_ctrl = {
.cmd0csratio= 0x80,
- .cmd0dldiff = 0x04, /* reset value is 0x4 */
.cmd0iclkout= 0x00,
.cmd1csratio= 0x80,
- .cmd1dldiff = 0x04, /* reset value is 0x4 */
.cmd1iclkout= 0x00,
.cmd2csratio= 0x80,
- .cmd2dldiff = 0x04, /* reset value is 0x4 */
.cmd2iclkout= 0x00,
};
@@ -150,21 +145,16 @@ static struct ddr_data ddr3_data = {
.datagiratio0 = ((0x2010) | 0x200),
.datafwsratio0 = ((RD_DQS_GATE10) | (RD_DQS_GATE0)),
.datawrsratio0 = (((WR_DQS+0x40)10) | ((WR_DQS+0x40)0)),
- .datauserank0delay = 0x1,
- .datadldiff0= 0x0, /* depend on cpu rev, set later */
};
static const struct cmd_control ddr3_ctrl = {
.cmd0csratio= 0x100,
- .cmd0dldiff = 0x004, /* reset value is 0x4 */
.cmd0iclkout= 0x001,
.cmd1csratio= 0x100,
- .cmd1dldiff = 0x004, /* reset value is 0x4 */
.cmd1iclkout= 0x001,
.cmd2csratio= 0x100,
- .cmd2dldiff = 0x004, /* reset value is 0x4 */
.cmd2iclkout= 0x001,
};
@@ -198,11 +188,6 @@ void sdram_init(void)
config_dmm(evm_lisa_map_regs);
#ifdef CONFIG_TI816X_EVM_DDR2
- ddr2_data.datadldiff0 = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
- ddr2_ctrl.cmd0dldiff = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
- ddr2_ctrl.cmd1dldiff = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
- ddr2_ctrl.cmd2dldiff = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
-
if (CONFIG_TI816X_USE_EMIF0) {
ddr2_emif0_regs.emif_ddr_phy_ctlr_1 =
(get_cpu_rev() == 0x1 ? 0x010B : 0x030B);
@@ -217,8 +202,6 @@ void sdram_init(void)
#endif
#ifdef CONFIG_TI816X_EVM_DDR3
- ddr3_data.datadldiff0 = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
-
From a quick glance it looks like at least earlier variants of TI81xx
used these registers to work around some bugs? This might end up
breaking those. Note that TI81xx DDR frequencies are much higher
compared to AM335x so issues related to this might not show up
right now.
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/14] ARM: AM43XX: board: add support for reading onboard EEPROM
On Thu, Nov 7, 2013 at 4:06 PM, Tom Rini tr...@ti.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/2013 03:56 PM, Vaibhav Bedia wrote:
Hi Tom,
On Wed, Nov 6, 2013 at 4:37 PM, Tom Rini tr...@ti.com wrote:
+
+ if (header-magic != 0xEE3355AA) {
Why is the header the same as AM335x? Shouldn't it be something
like 0xEE3344AA or whatever?
No, the header is still same. It is 0xEE3355AA.
My question was why ;)
What's the point of adding the same magic value for a different SoC?
Unless there's a good reason for doing so i think this needs to be fixed
in the EEPROM programmer.
A magic value is sufficiently magical, I don't think we'll get anyone to
change it at this point.
With almost half a dozen of AM335x board variants floating around this
thing is bound to cause problems eventually. The EEPROM format
can simply be updated to fix this. If there's a big resistance in doing
this then we might as well live with it - but i would at least ask once ;)
The thing is, customers drop the EEPROM or come up with their own, see
the Siemens am335x boards :)
Customers fix a design and get rid of whatever they can ;)
I always considered the EEPROM as one of the ways of maintaining some
sanity amongst the numerous board variants that go around internally :P
I'll leave this for the right folks to decide then :)
Regards,
Vaibhav
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am33xx: Stop modifying certain EMIF4D registers
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/2013 04:12 PM, Vaibhav Bedia wrote:
Hi Tom,
On Thu, Nov 7, 2013 at 11:42 AM, Tom Rini tr...@ti.com wrote:
Based on the definitive guide to EMIF configuration[1] certain registers
that we have been modifying (and are documented registers) should be
left in their reset values rather than modified. This has been tested
on AM335x GP EVM and Beaglebone White.
[...]
[snip]
@@ -198,11 +188,6 @@ void sdram_init(void)
config_dmm(evm_lisa_map_regs);
#ifdef CONFIG_TI816X_EVM_DDR2
- ddr2_data.datadldiff0 = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
- ddr2_ctrl.cmd0dldiff = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
- ddr2_ctrl.cmd1dldiff = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
- ddr2_ctrl.cmd2dldiff = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
-
if (CONFIG_TI816X_USE_EMIF0) {
ddr2_emif0_regs.emif_ddr_phy_ctlr_1 =
(get_cpu_rev() == 0x1 ? 0x010B : 0x030B);
@@ -217,8 +202,6 @@ void sdram_init(void)
#endif
#ifdef CONFIG_TI816X_EVM_DDR3
- ddr3_data.datadldiff0 = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
-
From a quick glance it looks like at least earlier variants of TI81xx
used these registers to work around some bugs? This might end up
breaking those. Note that TI81xx DDR frequencies are much higher
compared to AM335x so issues related to this might not show up
right now.
It's an open question on if TI81xx needs these set or was simply also
setting them for historical reasons (and in turn was inherited by am335x).
- --
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBAgAGBQJSfAM3AAoJENk4IS6UOR1WjYsP/2pTuP2Mufp7jRjgM4NVA56F
AL5H2e/mOmgn9qP67fkg4zk+LB+OvWAJOrilTNvx21hJUoSUwRTi8kTtT88o91FG
nPZlE0RMwZrVLR+paW96TfX8//9OVuCun9vqYvmCBpR4UYNQZHDr4KsxkLORqV+m
zNG6rTOSL8lGy9YsBWz0pcMvj6IxyrhXxkSJvD2h0xaApvC8Tdes3erqJlVXaJKs
sqcSv9cgE2mthQxzI7pemALxY4R9O3LcXCuB7Ad+vRgqlxR/SO5ON9zWRqLQNH7x
SM6ZtPO6yNT3eEqOxS6jyYGmanlgtsNBhrcz8fNtrnzbF9by6mCPvXMvPy36uTpR
gplwMOgxfsKQn6xosMdwj/5U8sQwadXTb1vvD2Dunmz4JEPE7IUsHbSLiXEz47QK
41x3zAb1yTk2Ku+zbhloD5osMtMlyekTqImAXviDP/v0vgXO5kRhbBEllAMtSBtP
yrXbNhH6r1ZyZmWdbvhp62DYflvEs37i9Miv/Zu6m2p8gI5IndzvmUxLc3h5jRAv
eIqpw+DYQlJx1s0P2s9IjmKDFlgTSyPYcjWL9jk5GKd2b2D+hLYoDfhsKMeNSqZm
Mym5cHlQCgYVqs+KE12GJ4pD3PA1gHXFd39I/z9ML4ZbDbXiirsZh2Ikpg2Tdk6j
YZzCdrrXxGBd2/Wi7mNd
=XIox
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] am33xx: Stop modifying certain EMIF4D registers
On Thu, Nov 07, 2013 at 04:16:40PM -0500, Tom Rini wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/2013 04:12 PM, Vaibhav Bedia wrote:
Hi Tom,
On Thu, Nov 7, 2013 at 11:42 AM, Tom Rini tr...@ti.com wrote:
Based on the definitive guide to EMIF configuration[1] certain registers
that we have been modifying (and are documented registers) should be
left in their reset values rather than modified. This has been tested
on AM335x GP EVM and Beaglebone White.
[...]
[snip]
@@ -198,11 +188,6 @@ void sdram_init(void)
config_dmm(evm_lisa_map_regs);
#ifdef CONFIG_TI816X_EVM_DDR2
- ddr2_data.datadldiff0 = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
- ddr2_ctrl.cmd0dldiff = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
- ddr2_ctrl.cmd1dldiff = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
- ddr2_ctrl.cmd2dldiff = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
-
if (CONFIG_TI816X_USE_EMIF0) {
ddr2_emif0_regs.emif_ddr_phy_ctlr_1 =
(get_cpu_rev() == 0x1 ? 0x010B : 0x030B);
@@ -217,8 +202,6 @@ void sdram_init(void)
#endif
#ifdef CONFIG_TI816X_EVM_DDR3
- ddr3_data.datadldiff0 = (get_cpu_rev() == 0x1 ? 0x0 : 0xF);
-
From a quick glance it looks like at least earlier variants of TI81xx
used these registers to work around some bugs? This might end up
breaking those. Note that TI81xx DDR frequencies are much higher
compared to AM335x so issues related to this might not show up
right now.
It's an open question on if TI81xx needs these set or was simply also
setting them for historical reasons (and in turn was inherited by am335x).
I will doublecheck on my early TI8148...out of time today but tomorrow.
-Matt
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] ARM: bcm2835: add missing mbox overscan response field
On 11/07/2013 06:29 AM, Albert ARIBAUD wrote: Hi Andre, On Wed, 23 Oct 2013 21:46:31 +0200, Andre Heider a.hei...@gmail.com wrote: On Wed, Oct 23, 2013 at 05:54:13PM +0100, Stephen Warren wrote: On 10/22/2013 09:27 PM, Andre Heider wrote: Add the missing right field to struct bcm2835_mbox_tag_overscan. This one patch, Acked-by: Stephen Warren swar...@wwwdotorg.org You need to send/cc this patch to Albert Aribauld, since he applies ARM patches. Or, perhaps just make sure the patch gets assigned to him in patchwork? Okay, I did the patchwork dance :) Thanks, Andre In fact, the series could be applied as a whole by the same custodian -- and actually, I'd prefer it to be applied as a whole, since patch 1/2 alone looks like dead/useless code, whereas it makes sense if applied along with 2/2. So, there are 2 patches and 2 custodians. One of you has to ack the patch for the other to merge them both through the other's subsystem, right? I guess you want Anatolij to take both of these through the video tree based on your comments. If so, can you ack this patch and re-assign them both in patchwork, so he knows that? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v14 07/10] arm64: core support
On 10/14/2013 08:34 PM, feng...@phytium.com.cn wrote: From: David Feng feng...@phytium.com.cn Relocation code based on a patch by Scott Wood, which is: Signed-off-by: Scott Wood scottw...@freescale.com Signed-off-by: David Feng feng...@phytium.com.cn --- arch/arm/config.mk |3 +- arch/arm/cpu/armv8/Makefile | 38 + arch/arm/cpu/armv8/cache.S | 130 + snip diff --git a/arch/arm/cpu/armv8/cache.S b/arch/arm/cpu/armv8/cache.S new file mode 100644 index 000..419f169 --- /dev/null +++ b/arch/arm/cpu/armv8/cache.S @@ -0,0 +1,130 @@ +/* + * (C) Copyright 2013 + * David Feng feng...@phytium.com.cn + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include asm-offsets.h +#include config.h +#include version.h +#include asm/macro.h +#include linux/linkage.h + +/* + * void __asm_flush_dcache_level(level) + * + * clean and invalidate one level cache. + * + * x0: cache level + * x1~x9: clobbered + */ +ENTRY(__asm_flush_dcache_level) + lsl x1, x0, #1 + msr csselr_el1, x1 /* select cache level */ + isb /* isb to sych the new cssr csidr */ + mrs x6, ccsidr_el1 /* read the new ccsidr */ + and x2, x6, #7 /* x2 - length of the cache lines */ + add x2, x2, #4 /* add 4 (line length offset) */ + mov x3, #0x3ff + and x3, x3, x6, lsr #3 /* x3 - maximum number of way size */ + clz w5, w3 /* bit position of way size */ + mov x4, #0x7fff + and x4, x4, x1, lsr #13 /* x4 - max number of the set size */ Shouldn't this x1 be x6? + /* x1 - cache level 1 */ + /* x2 - line length offset */ + /* x3 - number of cache ways */ + /* x4 - number of cache sets */ + /* x5 - bit position of way size */ + +loop_set: + mov x6, x3 /* create working copy of way size */ +loop_way: + lsl x7, x6, x5 + orr x9, x0, x7 /* map way and level to cisw value */ Shouldn't this x0 be x1? + lsl x7, x4, x2 + orr x9, x9, x7 /* map set number to cisw value */ + dc cisw, x9/* clean invalidate by set/way */ + subsx6, x6, #1 /* decrement the way */ + b.geloop_way + subsx4, x4, #1 /* decrement the set */ + b.geloop_set + + ret +ENDPROC(__asm_flush_dcache_level) + I haven't been able to verify this change. It simply takes too long to finish on emulator. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] gpio_led driver updates
This simple series enhances the gpio_led driver a bit by some documentation, checking the return value of gpio_request() call, and finally adding support for inverted polarity GPIOs. Igor Grinberg (3): README: document the CONFIG_GPIO_LED symbol gpio_led: check gpio_request() return value gpio_led: add support for inverted polarity README | 15 +++ drivers/misc/gpio_led.c | 33 ++--- 2 files changed, 45 insertions(+), 3 deletions(-) -- 1.8.1.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] README: document the CONFIG_GPIO_LED symbol
The CONFIG_GPIO_LED symbol does not have any documentation in the README file. Document the CONFIG_GPIO_LED symbol. Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- README | 8 1 file changed, 8 insertions(+) diff --git a/README b/README index 09662a4..55c71fa 100644 --- a/README +++ b/README @@ -1951,6 +1951,14 @@ CBFS (Coreboot Filesystem) support kernel). Defining CONFIG_STATUS_LED enables this feature in U-Boot. + Additional options: + + CONFIG_GPIO_LED + The status LED can be connected to a GPIO pin. + In such cases, the gpio_led driver can be used as a + status LED backend implementation. Define CONFIG_GPIO_LED + to include the gpio_led driver in the U-Boot binary. + - CAN Support: CONFIG_CAN_DRIVER Defining CONFIG_CAN_DRIVER enables CAN driver support -- 1.8.1.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] gpio_led: add support for inverted polarity
Some GPIO connected LEDs have inverted polarity.
Introduce new config option: CONFIG_GPIO_LED_INVERTED_TABLE for the
specifying the inverted GPIO LEDs list and add support for this in the
gpio_led driver.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
README | 7 +++
drivers/misc/gpio_led.c | 27 +--
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/README b/README
index 55c71fa..b8bad51 100644
--- a/README
+++ b/README
@@ -1959,6 +1959,13 @@ CBFS (Coreboot Filesystem) support
status LED backend implementation. Define CONFIG_GPIO_LED
to include the gpio_led driver in the U-Boot binary.
+ CONFIG_GPIO_LED_INVERTED_TABLE
+ Some GPIO connected LEDs may have inverted polarity in which
+ case the GPIO high value corresponds to LED off state and
+ GPIO low value corresponds to LED on state.
+ In such cases CONFIG_GPIO_LED_INVERTED_TABLE may be defined
+ with a list of GPIO LEDs that have inverted polarity.
+
- CAN Support: CONFIG_CAN_DRIVER
Defining CONFIG_CAN_DRIVER enables CAN driver support
diff --git a/drivers/misc/gpio_led.c b/drivers/misc/gpio_led.c
index de20419..3e95727 100644
--- a/drivers/misc/gpio_led.c
+++ b/drivers/misc/gpio_led.c
@@ -9,19 +9,42 @@
#include status_led.h
#include asm/gpio.h
+#ifndef CONFIG_GPIO_LED_INVERTED_TABLE
+#define CONFIG_GPIO_LED_INVERTED_TABLE {}
+#endif
+
+static led_id_t gpio_led_inv[] = CONFIG_GPIO_LED_INVERTED_TABLE;
+
+static int gpio_led_gpio_value(led_id_t mask, int state)
+{
+ int i, gpio_value = (state == STATUS_LED_ON);
+
+ for (i = 0; i ARRAY_SIZE(gpio_led_inv); i++) {
+ if (gpio_led_inv[i] == mask)
+ gpio_value = !gpio_value;
+ }
+
+ return gpio_value;
+}
+
void __led_init(led_id_t mask, int state)
{
+ int gpio_value;
+
if (gpio_request(mask, gpio_led) != 0) {
printf(%s: failed requesting GPIO%lu!\n, __func__, mask);
return;
}
- gpio_direction_output(mask, state == STATUS_LED_ON);
+ gpio_value = gpio_led_gpio_value(mask, state);
+ gpio_direction_output(mask, gpio_value);
}
void __led_set(led_id_t mask, int state)
{
- gpio_set_value(mask, state == STATUS_LED_ON);
+ int gpio_value = gpio_led_gpio_value(mask, state);
+
+ gpio_set_value(mask, gpio_value);
}
void __led_toggle(led_id_t mask)
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 2/2] video: bcm2835: respect the pitch value
On Thu, 24 Oct 2013 20:00:41 +0200
Andre Heider a.hei...@gmail.com wrote:
...
@@ -90,6 +94,7 @@ void lcd_ctrl_init(void *lcdbase)
w = msg_setup-physical_w_h.body.resp.width;
h = msg_setup-physical_w_h.body.resp.height;
+ bcm2835_pitch = msg_setup-pitch.body.resp.pitch;
debug(bcm2835: Final resolution is %d x %d\n, w, h);
@@ -102,4 +107,6 @@ void lcd_ctrl_init(void *lcdbase)
void lcd_enable(void)
{
+ if (bcm2835_pitch)
+ lcd_line_length = bcm2835_pitch;
}
setting lcd_line_length in lcd_enable() is wrong, it should
happen earlier, before lcd_clear() is called in the lcd.c
driver. I suggest making the lcd_get_size() in lcd.c a weak
function and then provide bcm2835 specific lcd_get_size()
which sets the pitch as needed:
diff --git a/common/lcd.c b/common/lcd.c
index 5dd7948..60faa62 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -386,8 +386,13 @@ static void test_pattern(void)
//
/* ** GENERIC Initialization Routines */
//
-
-int lcd_get_size(int *line_length)
+/*
+ * Implement a weak default function for getting the length/size
+ * from panel_info parameters. With some boards/drivers the
+ * length might need adjustments, so allow defining the driver
+ * specific lcd_get_size() function.
+ */
+__weak int lcd_get_size(int *line_length)
{
*line_length = (panel_info.vl_col * NBITS(panel_info.vl_bpix)) / 8;
return *line_length * panel_info.vl_row;
and
diff --git a/drivers/video/bcm2835.c b/drivers/video/bcm2835.c
index 58a6163..45b470a 100644
--- a/drivers/video/bcm2835.c
+++ b/drivers/video/bcm2835.c
@@ -103,3 +103,9 @@ void lcd_ctrl_init(void *lcdbase)
void lcd_enable(void)
{
}
+
+void lcd_get_size(int *line_length)
+{
+ *line_length = bcm2835_pitch;
+ return *line_length * panel_info.vl_row;
+}
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] gpio_led: check gpio_request() return value
Add a check for the gpio_request() function return value and do not try
to configure the GPIO if the gpio_request() call fails.
Also, print an error message indicating the gpio_request() has failed.
Signed-off-by: Igor Grinberg grinb...@compulab.co.il
---
drivers/misc/gpio_led.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/gpio_led.c b/drivers/misc/gpio_led.c
index 3fedddc..de20419 100644
--- a/drivers/misc/gpio_led.c
+++ b/drivers/misc/gpio_led.c
@@ -11,7 +11,11 @@
void __led_init(led_id_t mask, int state)
{
- gpio_request(mask, gpio_led);
+ if (gpio_request(mask, gpio_led) != 0) {
+ printf(%s: failed requesting GPIO%lu!\n, __func__, mask);
+ return;
+ }
+
gpio_direction_output(mask, state == STATUS_LED_ON);
}
--
1.8.1.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v14 07/10] arm64: core support
On Tue, 2013-10-15 at 11:34 +0800, feng...@phytium.com.cn wrote: +/* + * void __asm_flush_dcache_level(level) + * + * clean and invalidate one level cache. + * + * x0: cache level + * x1~x9: clobbered + */ +ENTRY(__asm_flush_dcache_level) + lsl x1, x0, #1 + msr csselr_el1, x1 /* select cache level */ + isb /* isb to sych the new cssr csidr */ + mrs x6, ccsidr_el1 /* read the new ccsidr */ + and x2, x6, #7 /* x2 - length of the cache lines */ + add x2, x2, #4 /* add 4 (line length offset) */ + mov x3, #0x3ff + and x3, x3, x6, lsr #3 /* x3 - maximum number of way size */ + clz w5, w3 /* bit position of way size */ You should round up (so add w3, w3, w3; sub w3, w3, #1 before clz), since the architecture allows non-power-of-2 values for #sets/#ways. Also s/way size/#ways/ and s/set size/#sets/ When I see set size I think of the number of ways times the size of a cache line, not the number of sets. BTW, I see some very similar comments, register usage, and code structure in the Linux code. Are you *sure* this code wasn't derived from it (or some other common source)? Do we need to start from scratch, if we can't trust that you're identifying all the code that you didn't write yourself? You were asked several times to do so. +loop_level: + lsl x1, x0, #1 + add x1, x1, x0 /* x0 - 3x cache level */ Comment says x0 gets 3x cache level, but the value is placed in x1. + sub x3, x2, #1 + bic x0, x0, x3 +1: dc civac, x0 /* clean invalidate D/unified line */ + add x0, x0, x2 Whitespace + /* load TTBR0 */ + el = curent_el(); + if (el == 1) + asm volatile(msr ttbr0_el1, %0 + : : r (gd-arch.tlb_addr) : memory); + else if (el == 2) + asm volatile(msr ttbr0_el2, %0 + : : r (gd-arch.tlb_addr) : memory); + else + panic(Not Supported Exception Level); Do we really need to support running in either el1 or el2 at runtime, throughout U-Boot? If Linux is started in el2, it enters el1 after setting up exception vectors to get control back if it needs to. Can't we do the same (and go back to el2 if available immediately before entering an OS)? Assuming we don't want to just set the expected exception level at compile time. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/7] mmc: Add some usefull macro definition
Dear Haijun,
On 11/05/2013 03:23 PM, Haijun Zhang wrote:
Add command class define.
Add mmc erase and secure erase define.
Add secure erase and trim support bit define.
Signed-off-by: Haijun Zhang haijun.zh...@freescale.com
---
include/mmc.h | 49 +
1 file changed, 49 insertions(+)
diff --git a/include/mmc.h b/include/mmc.h
index cb558da..26fab07 100644
--- a/include/mmc.h
+++ b/include/mmc.h
@@ -53,6 +53,7 @@
#define COMM_ERR -18 /* Communications Error */
#define TIMEOUT -19
#define IN_PROGRESS -20 /* operation is in progress */
+#define NOT_SUPPORT -21 /* Operation is not support */
#define MMC_CMD_GO_IDLE_STATE0
#define MMC_CMD_SEND_OP_COND 1
@@ -105,6 +106,39 @@
#define OCR_VOLTAGE_MASK 0x007FFF80
#define OCR_ACCESS_MODE 0x6000
+/*
+ * Card Command Classes (CCC)
+ *
+ * (0) Basic protocol functions (CMD0,1,2,3,4,7,9,10,12,13,15)
+ * (and for SPI, CMD58,59)
+ * (1) Stream read commands (CMD11)
+ * (2) Block read commands (CMD16,17,18)
+ * (3) Stream write commands (CMD20)
+ * (4) Block write commands (CMD16,24,25,26,27)
+ * (5) Ability to erase blocks (CMD32,33,34,35,36,37,38,39)
+ * (6) Able to write protect blocks (CMD28,29,30)
+ * (7) Able to lock down card (CMD16,CMD42)
+ * (8) Application specific (CMD55,56,57,ACMD*)
+ * (9) I/O mode (CMD5,39,40,52,53)
+ * (10) High speed switch (CMD6,34,35,36,37,50)
+ */
+#define CCC_BASIC(10)
+#define CCC_STREAM_READ (11)
+#define CCC_BLOCK_READ (12)
+#define CCC_STREAM_WRITE (13)
+#define CCC_BLOCK_WRITE (14)
+#define CCC_ERASE(15)
+#define CCC_WRITE_PROT (16)
+#define CCC_LOCK_CARD(17)
+#define CCC_APP_SPEC (18)
+#define CCC_IO_MODE (19)
+#define CCC_SWITCH (110)
+
+#define MMC_ERASE_ARG 0x
+#define MMC_SECURE_ERASE_ARG0x8000
+#define MMC_TRIM_ARG0x0001
+#define MMC_DISCARD_ARG 0x0003
+
#define SECURE_ERASE 0x8000
#define MMC_STATUS_MASK (~0x0206BF7F)
@@ -160,8 +194,12 @@
#define EXT_CSD_CARD_TYPE196 /* RO */
#define EXT_CSD_SEC_CNT 212 /* RO, 4 bytes */
#define EXT_CSD_HC_WP_GRP_SIZE 221 /* RO */
+#define EXT_CSD_REL_WR_SEC_C 222 /* RO */
+#define EXT_CSD_ERASE_TIMEOUT_MULT 223 /* RO */
#define EXT_CSD_HC_ERASE_GRP_SIZE224 /* RO */
#define EXT_CSD_BOOT_MULT226 /* RO */
+#define EXT_CSD_SEC_ERASE_MULT 230 /* RO */
+#define EXT_CSD_SEC_FEATURE_SUPPORT 231 /* RO */
/*
* EXT_CSD field definitions
@@ -178,6 +216,12 @@
#define EXT_CSD_BUS_WIDTH_4 1 /* Card is in 4 bit mode */
#define EXT_CSD_BUS_WIDTH_8 2 /* Card is in 8 bit mode */
+#define EXT_CSD_SEC_ER_EN(10)
Where is this bit defined?
+#define EXT_CSD_SEC_BD_BLK_EN(12)
+#define EXT_CSD_SEC_GB_CL_EN (14)
+#define EXT_CSD_SEC_SANITIZE (16) /* v4.5 only */
Which version do you refer?
SEC_SANITIZE is only supported v4.5? then v4.51 or v5.0?
I think that Comment need to modify.
/* Since v4.5 */
+
+
remove the empty line.
Best Regards,
Jaehoon Chung
#define EXT_CSD_BOOT_ACK_ENABLE (1 6)
#define EXT_CSD_BOOT_PARTITION_ENABLE(1 3)
#define EXT_CSD_PARTITION_ACCESS_ENABLE (1 0)
@@ -268,10 +312,15 @@ struct mmc {
ushort rca;
char part_config;
char part_num;
+ ushort cmdclass;
uint tran_speed;
uint read_bl_len;
uint write_bl_len;
uint erase_grp_size;
+ uint erase_timeout_mult;
+ char sec_feature_support;
+ uint sec_erase_mult;
+ uint sec_erase_timeout;
u64 capacity;
u64 capacity_user;
u64 capacity_boot;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
