Re: [U-Boot] [STATUS] v2011.06-rc3 released
Le 23/06/2011 03:19, Marek Vasut a écrit : On Thursday, June 23, 2011 12:51:23 AM Wolfgang Denk wrote: Dear Michael Schwingen, In message4e0267e9.2000...@discworld.dascon.de you wrote: Please help testing, and check if all your relevant patches have been included. I think the IXP42x patches are still missing. I don't think I have seen a pull request for these. Marek, could you please comment? [PULL] U-Boot-pxa pull request From: Marek Vasutxxx To: u-boot@xxx CC: Wolfgang Denkxxx Date: 05/27/11 04:56 PM I'm dead sure I sent a pull rq. Just checked my mail, deleted mail and spam folders, no sign of it, though it appears on gmane NNTP server so clearly it was lost somewhere inbetween. Marek, can you rebase on current u-boot[-arm]/master (there are conflicts in several mmc files) and resend the pull request? Apologies for the added work. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2011.06-rc3 released
Le 23/06/2011 08:15, Albert ARIBAUD a écrit : Le 23/06/2011 03:19, Marek Vasut a écrit : On Thursday, June 23, 2011 12:51:23 AM Wolfgang Denk wrote: Dear Michael Schwingen, In message4e0267e9.2000...@discworld.dascon.de you wrote: Please help testing, and check if all your relevant patches have been included. I think the IXP42x patches are still missing. I don't think I have seen a pull request for these. Marek, could you please comment? [PULL] U-Boot-pxa pull request From: Marek Vasutxxx To: u-boot@xxx CC: Wolfgang Denkxxx Date: 05/27/11 04:56 PM I'm dead sure I sent a pull rq. Just checked my mail, deleted mail and spam folders, no sign of it, though it appears on gmane NNTP server so clearly it was lost somewhere inbetween. Marek, can you rebase on current u-boot[-arm]/master (there are conflicts in several mmc files) and resend the pull request? Apologies for the added work. Scratch that, I'd tried pulling pxa/master, not pxa/ixp. pxa/ixp seems up to date. Pulling in now. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] U-Boot-pxa pull request
Le 27/05/2011 16:56, Marek Vasut a écrit : Hi, please pull my git://git.denx.de/u-boot-pxa ixp branch into your u- boot/master branch. Thanks These are mostly the IXP changes + I added the fix I promissed you half a year ago ... damn the time runs fast :-/ Cheers The following changes since commit 5d1ee00b1fe1180503f6dfc10e87a6c6e74778f3: .gitignore: update list of u-boot.* files and add *.bin (2011-05-22 23:46:26 +0200) are available in the git repository at: git://git.denx.de/u-boot-pxa.git ixp Marek Vasut (1): Move wepep250,delta,xsengine to scrapyard Michael Schwingen (17): add XScale sub architecture (IXP/PXA) to maintainer list add support for IXP42x Rev. B1 and newer trigger hardware watchdog in IXP42x serial driver Fix IXP code to work after relocation was added fix depend target in npe directory support CONFIG_SYS_LDSCRIPT on ARM use -ffunction-sections / --gc-sections on IXP42x update/fix AcTux1 board update/fix AcTux2 board update/fix AcTux3 board update/fix AcTux4 board IXP NPE: add support for fixed-speed MII ports add dvlhost (dLAN 200 AV Wireless G) board update/fix IXDP425 / IXDPG425 boards update/fix PDNB3 board IXP42x PCI rewrite run arm_pci_init after relocation MAINTAINERS | 49 ++-- arch/arm/config.mk|7 + arch/arm/cpu/ixp/config.mk|5 + arch/arm/cpu/ixp/cpu.c|5 - arch/arm/cpu/ixp/npe/Makefile |1 + arch/arm/cpu/ixp/npe/npe.c| 74 +++-- arch/arm/cpu/ixp/start.S | 59 +--- arch/arm/cpu/ixp/timer.c | 124 +++--- arch/arm/cpu/ixp/u-boot.lds |8 +- arch/arm/include/asm/arch-ixp/ixp425.h|5 +- arch/arm/include/asm/arch-ixp/ixp425pci.h | 130 +-- arch/arm/include/asm/global_data.h|3 + arch/arm/lib/board.c |6 +- board/actux1/actux1.c | 105 +++--- board/actux1/config.mk|4 - board/actux1/u-boot.lds | 41 ++- board/actux2/actux2.c | 93 +++--- board/actux2/config.mk|4 - board/actux2/u-boot.lds | 46 ++- board/actux3/actux3.c | 120 +++--- board/actux3/config.mk|4 - board/actux3/u-boot.lds | 52 ++- board/actux4/actux4.c | 103 +++-- board/actux4/config.mk|4 - board/dvlhost/Makefile| 50 +++ board/dvlhost/dvlhost.c | 130 ++ board/dvlhost/dvlhost_hw.h| 47 +++ board/dvlhost/u-boot.lds | 87 board/dvlhost/watchdog.c | 43 ++ board/ixdp425/config.mk |2 - board/ixdp425/flash.c | 427 board/ixdp425/ixdp425.c | 155 +++- board/prodrive/pdnb3/config.mk|2 - boards.cfg|8 +- doc/README.scrapyard |3 + drivers/pci/pci.c |4 - drivers/pci/pci_indirect.c| 13 +- drivers/pci/pci_ixp.c | 612 ++--- drivers/serial/serial_ixp.c |7 +- include/configs/actux1.h | 62 ++-- include/configs/actux2.h | 35 ++- include/configs/actux3.h | 37 ++- include/configs/actux4.h | 39 ++- include/configs/dvlhost.h | 248 include/configs/ixdp425.h | 196 +++--- include/configs/ixdpg425.h| 11 +- include/configs/pdnb3.h | 10 +- 47 files changed, 1692 insertions(+), 1588 deletions(-) delete mode 100644 board/actux1/config.mk delete mode 100644 board/actux2/config.mk delete mode 100644 board/actux3/config.mk delete mode 100644 board/actux4/config.mk create mode 100644 board/dvlhost/Makefile create mode 100644 board/dvlhost/dvlhost.c create mode 100644 board/dvlhost/dvlhost_hw.h create mode 100644 board/dvlhost/u-boot.lds create mode 100644 board/dvlhost/watchdog.c delete mode 100644 board/ixdp425/config.mk delete mode 100644 board/ixdp425/flash.c delete mode 100644 board/prodrive/pdnb3/config.mk create mode 100644 include/configs/dvlhost.h Applied (with a trivial merge on boards.cfg), thanks, and apologies for missing this! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM pull request
(forgot to Cc: the lits, sorry for the duplicate) Hi Wolfgang, The following changes since commit 79cfe422615c010a75ece41662a05cd432ada389: Prepare v2011.06-rc3 (2011-06-22 11:39:24 +0200) are available in the git repository at: git://git.denx.de/u-boot-arm.git master Michael Schwingen (17): add XScale sub architecture (IXP/PXA) to maintainer list add support for IXP42x Rev. B1 and newer trigger hardware watchdog in IXP42x serial driver Fix IXP code to work after relocation was added fix depend target in npe directory support CONFIG_SYS_LDSCRIPT on ARM use -ffunction-sections / --gc-sections on IXP42x update/fix AcTux1 board update/fix AcTux2 board update/fix AcTux3 board update/fix AcTux4 board IXP NPE: add support for fixed-speed MII ports add dvlhost (dLAN 200 AV Wireless G) board update/fix IXDP425 / IXDPG425 boards update/fix PDNB3 board IXP42x PCI rewrite run arm_pci_init after relocation MAINTAINERS | 45 ++- arch/arm/config.mk|7 + arch/arm/cpu/ixp/config.mk|5 + arch/arm/cpu/ixp/cpu.c|5 - arch/arm/cpu/ixp/npe/Makefile |1 + arch/arm/cpu/ixp/npe/npe.c| 74 +++-- arch/arm/cpu/ixp/start.S | 59 +--- arch/arm/cpu/ixp/timer.c | 124 +++--- arch/arm/cpu/ixp/u-boot.lds |8 +- arch/arm/include/asm/arch-ixp/ixp425.h|5 +- arch/arm/include/asm/arch-ixp/ixp425pci.h | 130 +-- arch/arm/include/asm/global_data.h|3 + arch/arm/lib/board.c |6 +- board/actux1/actux1.c | 105 +++--- board/actux1/config.mk|4 - board/actux1/u-boot.lds | 41 ++- board/actux2/actux2.c | 93 +++--- board/actux2/config.mk|4 - board/actux2/u-boot.lds | 46 ++- board/actux3/actux3.c | 120 +++--- board/actux3/config.mk|4 - board/actux3/u-boot.lds | 52 ++- board/actux4/actux4.c | 103 +++-- board/actux4/config.mk|4 - board/dvlhost/Makefile| 50 +++ board/dvlhost/dvlhost.c | 130 ++ board/dvlhost/dvlhost_hw.h| 47 +++ board/dvlhost/u-boot.lds | 87 board/dvlhost/watchdog.c | 43 ++ board/ixdp425/config.mk |2 - board/ixdp425/flash.c | 427 board/ixdp425/ixdp425.c | 155 +++- board/prodrive/pdnb3/config.mk|2 - boards.cfg|8 +- drivers/pci/pci.c |4 - drivers/pci/pci_indirect.c| 13 +- drivers/pci/pci_ixp.c | 612 ++--- drivers/serial/serial_ixp.c |7 +- include/configs/actux1.h | 62 ++-- include/configs/actux2.h | 35 ++- include/configs/actux3.h | 37 ++- include/configs/actux4.h | 39 ++- include/configs/dvlhost.h | 248 include/configs/ixdp425.h | 196 +++--- include/configs/ixdpg425.h| 11 +- include/configs/pdnb3.h | 10 +- 46 files changed, 1689 insertions(+), 1584 deletions(-) delete mode 100644 board/actux1/config.mk delete mode 100644 board/actux2/config.mk delete mode 100644 board/actux3/config.mk delete mode 100644 board/actux4/config.mk create mode 100644 board/dvlhost/Makefile create mode 100644 board/dvlhost/dvlhost.c create mode 100644 board/dvlhost/dvlhost_hw.h create mode 100644 board/dvlhost/u-boot.lds create mode 100644 board/dvlhost/watchdog.c delete mode 100644 board/ixdp425/config.mk delete mode 100644 board/ixdp425/flash.c delete mode 100644 board/prodrive/pdnb3/config.mk create mode 100644 include/configs/dvlhost.h uboot@lilith:~/src/u-boot-arm$ git fetch u-boot-arm From git://git.denx.de/u-boot-arm 79cfe42..1ed63c5 master - u-boot-arm/master + 17859fd...26137d3 next - u-boot-arm/next (forced update) uboot@lilith:~/src/u-boot-arm$ git request-pull u-boot/master git://git.denx.de/u-boot-arm.git master The following changes since commit 79cfe422615c010a75ece41662a05cd432ada389: Prepare v2011.06-rc3 (2011-06-22 11:39:24 +0200) are available in the git repository at: git://git.denx.de/u-boot-arm.git master Michael Schwingen (17): add XScale sub architecture (IXP/PXA) to maintainer list add support for IXP42x Rev. B1 and newer trigger hardware watchdog in IXP42x serial driver
Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board
Hi Sanjeev,
On 06/22/11 22:24, Sanjeev Premi wrote:
From: Sriramakrishnan s...@ti.com
The GPIO pin used for resetting the external LAN chip has
changed for Rev.G board.
Signed-off-by: Sriramakrishnan s...@ti.com
Signed-off-by: Sanjeev Premi pr...@ti.com
---
board/ti/evm/evm.c | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 8f9f141..57e5fa5 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -181,17 +181,26 @@ static void setup_net_chip(void)
*/
static void reset_net_chip(void)
{
- struct gpio *gpio3_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
-
- /* Make GPIO 64 as output pin */
- writel(readl(gpio3_base-oe) ~(GPIO0), gpio3_base-oe);
-
- /* Now send a pulse on the GPIO pin */
- writel(GPIO0, gpio3_base-setdataout);
+ struct gpio *gpio_base;
+ u32 pin;
+
+ if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1) {
+ gpio_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
+ pin = GPIO0;/* Output pin: GPIO Bank 3, pin 0 */
+ } else {
+ gpio_base = (struct gpio *)OMAP34XX_GPIO1_BASE;
+ pin = GPIO7;/* Output pin: GPIO Bank 0, pin 7 */
+ }
+
+ /* Configure the pin as output */
+ writel(readl(gpio_base-oe) ~(pin), gpio_base-oe);
+
+ /* Send a pulse on the GPIO pin */
+ writel(pin, gpio_base-setdataout);
udelay(1);
- writel(GPIO0, gpio3_base-cleardataout);
+ writel(pin, gpio_base-cleardataout);
udelay(1);
- writel(GPIO0, gpio3_base-setdataout);
+ writel(pin, gpio_base-setdataout);
Why keep messing with the gpio registers?
Why not use gpio framework?
Though it is omap specific, but it will be much cleaner then the above.
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board
-Original Message-
From: Igor Grinberg [mailto:grinb...@compulab.co.il]
Sent: Thursday, June 23, 2011 2:38 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de; Govindarajan, Sriramakrishnan
Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet
reset sequence for Rev.G board
Hi Sanjeev,
On 06/22/11 22:24, Sanjeev Premi wrote:
From: Sriramakrishnan s...@ti.com
The GPIO pin used for resetting the external LAN chip has
changed for Rev.G board.
Signed-off-by: Sriramakrishnan s...@ti.com
Signed-off-by: Sanjeev Premi pr...@ti.com
---
board/ti/evm/evm.c | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 8f9f141..57e5fa5 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -181,17 +181,26 @@ static void setup_net_chip(void)
*/
static void reset_net_chip(void)
{
- struct gpio *gpio3_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
-
- /* Make GPIO 64 as output pin */
- writel(readl(gpio3_base-oe) ~(GPIO0), gpio3_base-oe);
-
- /* Now send a pulse on the GPIO pin */
- writel(GPIO0, gpio3_base-setdataout);
+ struct gpio *gpio_base;
+ u32 pin;
+
+ if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1) {
+ gpio_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
+ pin = GPIO0;/* Output pin: GPIO Bank 3, pin 0 */
+ } else {
+ gpio_base = (struct gpio *)OMAP34XX_GPIO1_BASE;
+ pin = GPIO7;/* Output pin: GPIO Bank 0, pin 7 */
+ }
+
+ /* Configure the pin as output */
+ writel(readl(gpio_base-oe) ~(pin), gpio_base-oe);
+
+ /* Send a pulse on the GPIO pin */
+ writel(pin, gpio_base-setdataout);
udelay(1);
- writel(GPIO0, gpio3_base-cleardataout);
+ writel(pin, gpio_base-cleardataout);
udelay(1);
- writel(GPIO0, gpio3_base-setdataout);
+ writel(pin, gpio_base-setdataout);
Why keep messing with the gpio registers?
Why not use gpio framework?
Though it is omap specific, but it will be much cleaner then
the above.
[sp] I guess the intent was to keep code similar. But yes,
gpio framework can be used.
~sanjeev
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet reset sequence for Rev.G board
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev
Sent: Thursday, June 23, 2011 4:43 PM
To: Igor Grinberg
Cc: Govindarajan, Sriramakrishnan; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet
reset sequence for Rev.G board
-Original Message-
From: Igor Grinberg [mailto:grinb...@compulab.co.il]
Sent: Thursday, June 23, 2011 2:38 PM
To: Premi, Sanjeev
Cc: u-boot@lists.denx.de; Govindarajan, Sriramakrishnan
Subject: Re: [U-Boot] [PATCH 2/3] omap3evm: Update ethernet
reset sequence for Rev.G board
Hi Sanjeev,
On 06/22/11 22:24, Sanjeev Premi wrote:
From: Sriramakrishnan s...@ti.com
The GPIO pin used for resetting the external LAN chip has
changed for Rev.G board.
Signed-off-by: Sriramakrishnan s...@ti.com
Signed-off-by: Sanjeev Premi pr...@ti.com
---
board/ti/evm/evm.c | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/board/ti/evm/evm.c b/board/ti/evm/evm.c
index 8f9f141..57e5fa5 100644
--- a/board/ti/evm/evm.c
+++ b/board/ti/evm/evm.c
@@ -181,17 +181,26 @@ static void setup_net_chip(void)
*/
static void reset_net_chip(void)
{
- struct gpio *gpio3_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
-
- /* Make GPIO 64 as output pin */
- writel(readl(gpio3_base-oe) ~(GPIO0), gpio3_base-oe);
-
- /* Now send a pulse on the GPIO pin */
- writel(GPIO0, gpio3_base-setdataout);
+ struct gpio *gpio_base;
+ u32 pin;
+
+ if (get_omap3_evm_rev() == OMAP3EVM_BOARD_GEN_1) {
+ gpio_base = (struct gpio *)OMAP34XX_GPIO3_BASE;
+ pin = GPIO0;/* Output pin: GPIO Bank 3, pin 0 */
+ } else {
+ gpio_base = (struct gpio *)OMAP34XX_GPIO1_BASE;
+ pin = GPIO7;/* Output pin: GPIO Bank 0, pin 7 */
+ }
+
+ /* Configure the pin as output */
+ writel(readl(gpio_base-oe) ~(pin), gpio_base-oe);
+
+ /* Send a pulse on the GPIO pin */
+ writel(pin, gpio_base-setdataout);
udelay(1);
- writel(GPIO0, gpio3_base-cleardataout);
+ writel(pin, gpio_base-cleardataout);
udelay(1);
- writel(GPIO0, gpio3_base-setdataout);
+ writel(pin, gpio_base-setdataout);
Why keep messing with the gpio registers?
Why not use gpio framework?
Though it is omap specific, but it will be much cleaner then
the above.
[sp] I guess the intent was to keep code similar. But yes,
gpio framework can be used.
[sp] Sorry, mail went earlier than I wanted :(
The only issue is that I couln't see gpio framework for omap.
Let me dig further...
~sanjeev
--
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM pull request
Dear Albert ARIBAUD, In message 4e02de75.7030...@aribaud.net you wrote: (forgot to Cc: the lits, sorry for the duplicate) Hi Wolfgang, The following changes since commit 79cfe422615c010a75ece41662a05cd432ada389: Prepare v2011.06-rc3 (2011-06-22 11:39:24 +0200) are available in the git repository at: git://git.denx.de/u-boot-arm.git master Michael Schwingen (17): add XScale sub architecture (IXP/PXA) to maintainer list add support for IXP42x Rev. B1 and newer trigger hardware watchdog in IXP42x serial driver Fix IXP code to work after relocation was added fix depend target in npe directory support CONFIG_SYS_LDSCRIPT on ARM use -ffunction-sections / --gc-sections on IXP42x update/fix AcTux1 board update/fix AcTux2 board update/fix AcTux3 board update/fix AcTux4 board IXP NPE: add support for fixed-speed MII ports add dvlhost (dLAN 200 AV Wireless G) board update/fix IXDP425 / IXDPG425 boards update/fix PDNB3 board IXP42x PCI rewrite run arm_pci_init after relocation MAINTAINERS | 45 ++- arch/arm/config.mk|7 + arch/arm/cpu/ixp/config.mk|5 + arch/arm/cpu/ixp/cpu.c|5 - arch/arm/cpu/ixp/npe/Makefile |1 + arch/arm/cpu/ixp/npe/npe.c| 74 +++-- arch/arm/cpu/ixp/start.S | 59 +--- arch/arm/cpu/ixp/timer.c | 124 +++--- arch/arm/cpu/ixp/u-boot.lds |8 +- arch/arm/include/asm/arch-ixp/ixp425.h|5 +- arch/arm/include/asm/arch-ixp/ixp425pci.h | 130 +-- arch/arm/include/asm/global_data.h|3 + arch/arm/lib/board.c |6 +- board/actux1/actux1.c | 105 +++--- board/actux1/config.mk|4 - board/actux1/u-boot.lds | 41 ++- board/actux2/actux2.c | 93 +++--- board/actux2/config.mk|4 - board/actux2/u-boot.lds | 46 ++- board/actux3/actux3.c | 120 +++--- board/actux3/config.mk|4 - board/actux3/u-boot.lds | 52 ++- board/actux4/actux4.c | 103 +++-- board/actux4/config.mk|4 - board/dvlhost/Makefile| 50 +++ board/dvlhost/dvlhost.c | 130 ++ board/dvlhost/dvlhost_hw.h| 47 +++ board/dvlhost/u-boot.lds | 87 board/dvlhost/watchdog.c | 43 ++ board/ixdp425/config.mk |2 - board/ixdp425/flash.c | 427 board/ixdp425/ixdp425.c | 155 +++- board/prodrive/pdnb3/config.mk|2 - boards.cfg|8 +- drivers/pci/pci.c |4 - drivers/pci/pci_indirect.c| 13 +- drivers/pci/pci_ixp.c | 612 ++--- drivers/serial/serial_ixp.c |7 +- include/configs/actux1.h | 62 ++-- include/configs/actux2.h | 35 ++- include/configs/actux3.h | 37 ++- include/configs/actux4.h | 39 ++- include/configs/dvlhost.h | 248 include/configs/ixdp425.h | 196 +++--- include/configs/ixdpg425.h| 11 +- include/configs/pdnb3.h | 10 +- 46 files changed, 1689 insertions(+), 1584 deletions(-) delete mode 100644 board/actux1/config.mk delete mode 100644 board/actux2/config.mk delete mode 100644 board/actux3/config.mk delete mode 100644 board/actux4/config.mk create mode 100644 board/dvlhost/Makefile create mode 100644 board/dvlhost/dvlhost.c create mode 100644 board/dvlhost/dvlhost_hw.h create mode 100644 board/dvlhost/u-boot.lds create mode 100644 board/dvlhost/watchdog.c delete mode 100644 board/ixdp425/config.mk delete mode 100644 board/ixdp425/flash.c delete mode 100644 board/prodrive/pdnb3/config.mk create mode 100644 include/configs/dvlhost.h Applied, thanks. I had to fix a merge conflict in arch/arm/lib/board.c (due to the removal of the trab board inbetween), so please verify. 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 f u cn rd ths, itn tyg h myxbl cd. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reg. CFI flash_init and hardware write protected devices
On Wed, Jun 1, 2011 at 6:59 PM, Frank Svendsbøe
frank.svends...@gmail.com wrote:
On Wed, Jun 1, 2011 at 5:34 PM, Stefan Roese s...@denx.de wrote:
Hi Frank,
On Wednesday 01 June 2011 16:33:14 Frank Svendsbøe wrote:
Simply because disabling write-protection is not impossible after
installation. Our device will be located 3000m below sea level.
I see.
Hmm.. then you read my mind :) I meant to say is not possible and not is
not impossible :)
Yep. I read so fast, that I didn't catch the misspelled words. ;)
Thanks, this worked for me. Is it ok for you too?
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index 6039e1f..99360af 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -176,6 +176,7 @@ u64 flash_read64(void *addr)__attribute__((weak,
alias(__flash_read64)));
#define flash_read64 __flash_read64
#endif
+
Don't add this empty line.
Thanks for spotting this. I'll remove this of course.
/*---
*/
#if defined(CONFIG_ENV_IS_IN_FLASH) ||
defined(CONFIG_ENV_ADDR_REDUND) || (CONFIG_SYS_MONITOR_BASE =
CONFIG_SYS_FLASH_BASE)
@@ -2151,7 +2152,8 @@ void flash_protect_default(void)
#endif
}
-unsigned long flash_init (void)
+unsigned long flash_init(void) __attribute__((weak,
alias(__flash_init))); +unsigned long __flash_init (void)
{
unsigned long size = 0;
int i;
Looks good. I have no objections. Please go ahead and send this as a proper
patch.
Will do (as soon as I get back to work).
Best regards,
Frank.
Hi Stefan,
A few weeks ago, I applied this change and everything worked fine in
U-Boot. However, I didn't succeed doing the same hack in Linux. I've
done some hardcoding experiments in drivers/mtd/chips/cfi_probe.c, but
so far no success. After reading some CFI manuals, it seems CFI
will/should use bus write operations even during CFI read operations.
Can you confirm this? Then my next question is how come U-Boot read
operations works by just hardcoding the flash geometry. It seems
U-Boot utilize just plain localbus accesses to read flash data, ie.
not the CFI protocol. What did I miss here.. ?
Now I'm considering two options: 1) Either write a custom flash map
driver, and access the flash the same way U-Boot does, or 2) try to
convince the FPGA designers that our way of forcing write protection
is not according the the CFI specifications, and should be done
otherwise. What do you think is the best solution?
Is there anybody else out there supporting hardware write protection
on CFI devices?
Best regards,
Frank
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reg. CFI flash_init and hardware write protected devices
Dear Frank, In message banlktinfma7fn-bd7z2-zyat+-ubwn7...@mail.gmail.com you wrote: A few weeks ago, I applied this change and everything worked fine in U-Boot. However, I didn't succeed doing the same hack in Linux. I've done some hardcoding experiments in drivers/mtd/chips/cfi_probe.c, but so far no success. After reading some CFI manuals, it seems CFI will/should use bus write operations even during CFI read operations. What exactly do you mean by CFI read operations? Can you confirm this? Then my next question is how come U-Boot read operations works by just hardcoding the flash geometry. It seems U-Boot utilize just plain localbus accesses to read flash data, ie. not the CFI protocol. What did I miss here.. ? It seems you misunderstand the different modes. In command mode, you will use the specific command sequences defined in the CFI protocol to talk to the controller poart of the flash chip. In this mode, you can read for example query information, flash geometry data, status information, etc. Yes, any such command sequence includes write operations to the flash device, even when you actually want to read some specific data. In data mode, flash is working just as normal real-only memory. No specific protocol is used, you just use plain read accesses to read the user data programmed into the flash chip. Any kind of probing, auto-identification etc. of the flash chip will need to use CFI command sequences, and thus write access to the device. As long as you just want to read the data or execute code from the flash no write accesses are needed. Now I'm considering two options: 1) Either write a custom flash map driver, and access the flash the same way U-Boot does, or 2) try to convince the FPGA designers that our way of forcing write protection is not according the the CFI specifications, and should be done otherwise. What do you think is the best solution? Linux can also read from ROM memory. You just have to make sure that you do not try to run the normal CFI flash drivers on your flash devices - these will not work, because they will try to probe the flash chips. Is there anybody else out there supporting hardware write protection on CFI devices? CFI flash chips with the level of write protection you implemented have to be dealt with in the same way as other ROM memory. Normal CFI driver are not appropriate here. 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 And now remains That we find out the cause of this effect, Or rather say, the cause of this defect... -- Hamlet, Act II, Scene 2 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reg. CFI flash_init and hardware write protected devices
On Thu, Jun 23, 2011 at 5:21 PM, Wolfgang Denk w...@denx.de wrote: Dear Frank, In message banlktinfma7fn-bd7z2-zyat+-ubwn7...@mail.gmail.com you wrote: A few weeks ago, I applied this change and everything worked fine in U-Boot. However, I didn't succeed doing the same hack in Linux. I've done some hardcoding experiments in drivers/mtd/chips/cfi_probe.c, but so far no success. After reading some CFI manuals, it seems CFI will/should use bus write operations even during CFI read operations. What exactly do you mean by CFI read operations? Good question. When reading Intels CFI manual I was referring to something called read array which used bus write commands. I guess normal byte/word read access don't utilize this then. Can you confirm this? Then my next question is how come U-Boot read operations works by just hardcoding the flash geometry. It seems U-Boot utilize just plain localbus accesses to read flash data, ie. not the CFI protocol. What did I miss here.. ? It seems you misunderstand the different modes. In command mode, you will use the specific command sequences defined in the CFI protocol to talk to the controller poart of the flash chip. In this mode, you can read for example query information, flash geometry data, status information, etc. Yes, any such command sequence includes write operations to the flash device, even when you actually want to read some specific data. In data mode, flash is working just as normal real-only memory. No specific protocol is used, you just use plain read accesses to read the user data programmed into the flash chip. Right, and thanks for the explanation. What I've done to U-Boot is bypass the probing which uses the command mode and thus avoid getting problems with bus write accesses when flash protection is on. Any kind of probing, auto-identification etc. of the flash chip will need to use CFI command sequences, and thus write access to the device. As long as you just want to read the data or execute code from the flash no write accesses are needed. Now I'm considering two options: 1) Either write a custom flash map driver, and access the flash the same way U-Boot does, or 2) try to convince the FPGA designers that our way of forcing write protection is not according the the CFI specifications, and should be done otherwise. What do you think is the best solution? Linux can also read from ROM memory. You just have to make sure that you do not try to run the normal CFI flash drivers on your flash devices - these will not work, because they will try to probe the flash chips. Yes, well I tried to fool Linux's CFI driver too, but no luck so far. It was after this I started reading about CFI and came to the (wrong) conclusion that CFI uses bus write operations during read accesses too. Is there anybody else out there supporting hardware write protection on CFI devices? CFI flash chips with the level of write protection you implemented have to be dealt with in the same way as other ROM memory. Normal CFI driver are not appropriate here. Ok. So you recommend I stop hacking the CFI probing and instead write a custom flash map driver? Best regards, Frank ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/2] MMC: add erase function to both mmc and sd
Acked-by: Mike Frysinger vap...@gentoo.org -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/2] MMC: unify mmc read and write operation
Acked-by: Mike Frysinger vap...@gentoo.org -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM pull request
Hi Wolfgang, Le 23/06/2011 15:40, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4e02de75.7030...@aribaud.net you wrote: (forgot to Cc: the lits, sorry for the duplicate) Hi Wolfgang, The following changes since commit 79cfe422615c010a75ece41662a05cd432ada389: Prepare v2011.06-rc3 (2011-06-22 11:39:24 +0200) are available in the git repository at: git://git.denx.de/u-boot-arm.git master Michael Schwingen (17): add XScale sub architecture (IXP/PXA) to maintainer list add support for IXP42x Rev. B1 and newer trigger hardware watchdog in IXP42x serial driver Fix IXP code to work after relocation was added fix depend target in npe directory support CONFIG_SYS_LDSCRIPT on ARM use -ffunction-sections / --gc-sections on IXP42x update/fix AcTux1 board update/fix AcTux2 board update/fix AcTux3 board update/fix AcTux4 board IXP NPE: add support for fixed-speed MII ports add dvlhost (dLAN 200 AV Wireless G) board update/fix IXDP425 / IXDPG425 boards update/fix PDNB3 board IXP42x PCI rewrite run arm_pci_init after relocation MAINTAINERS | 45 ++- arch/arm/config.mk|7 + arch/arm/cpu/ixp/config.mk|5 + arch/arm/cpu/ixp/cpu.c|5 - arch/arm/cpu/ixp/npe/Makefile |1 + arch/arm/cpu/ixp/npe/npe.c| 74 +++-- arch/arm/cpu/ixp/start.S | 59 +--- arch/arm/cpu/ixp/timer.c | 124 +++--- arch/arm/cpu/ixp/u-boot.lds |8 +- arch/arm/include/asm/arch-ixp/ixp425.h|5 +- arch/arm/include/asm/arch-ixp/ixp425pci.h | 130 +-- arch/arm/include/asm/global_data.h|3 + arch/arm/lib/board.c |6 +- board/actux1/actux1.c | 105 +++--- board/actux1/config.mk|4 - board/actux1/u-boot.lds | 41 ++- board/actux2/actux2.c | 93 +++--- board/actux2/config.mk|4 - board/actux2/u-boot.lds | 46 ++- board/actux3/actux3.c | 120 +++--- board/actux3/config.mk|4 - board/actux3/u-boot.lds | 52 ++- board/actux4/actux4.c | 103 +++-- board/actux4/config.mk|4 - board/dvlhost/Makefile| 50 +++ board/dvlhost/dvlhost.c | 130 ++ board/dvlhost/dvlhost_hw.h| 47 +++ board/dvlhost/u-boot.lds | 87 board/dvlhost/watchdog.c | 43 ++ board/ixdp425/config.mk |2 - board/ixdp425/flash.c | 427 board/ixdp425/ixdp425.c | 155 +++- board/prodrive/pdnb3/config.mk|2 - boards.cfg|8 +- drivers/pci/pci.c |4 - drivers/pci/pci_indirect.c| 13 +- drivers/pci/pci_ixp.c | 612 ++--- drivers/serial/serial_ixp.c |7 +- include/configs/actux1.h | 62 ++-- include/configs/actux2.h | 35 ++- include/configs/actux3.h | 37 ++- include/configs/actux4.h | 39 ++- include/configs/dvlhost.h | 248 include/configs/ixdp425.h | 196 +++--- include/configs/ixdpg425.h| 11 +- include/configs/pdnb3.h | 10 +- 46 files changed, 1689 insertions(+), 1584 deletions(-) delete mode 100644 board/actux1/config.mk delete mode 100644 board/actux2/config.mk delete mode 100644 board/actux3/config.mk delete mode 100644 board/actux4/config.mk create mode 100644 board/dvlhost/Makefile create mode 100644 board/dvlhost/dvlhost.c create mode 100644 board/dvlhost/dvlhost_hw.h create mode 100644 board/dvlhost/u-boot.lds create mode 100644 board/dvlhost/watchdog.c delete mode 100644 board/ixdp425/config.mk delete mode 100644 board/ixdp425/flash.c delete mode 100644 board/prodrive/pdnb3/config.mk create mode 100644 include/configs/dvlhost.h Applied, thanks. I had to fix a merge conflict in arch/arm/lib/board.c (due to the removal of the trab board inbetween), so please verify. Seems ok to me, thanks. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reg. CFI flash_init and hardware write protected devices
Dear Frank, In message BANLkTi=p9gdogoetwojrqkmrxxm7do_...@mail.gmail.com you wrote: CFI flash chips with the level of write protection you implemented have to be dealt with in the same way as other ROM memory. =A0Normal CFI driver are not appropriate here. Ok. So you recommend I stop hacking the CFI probing and instead write a custom flash map driver? No. Never write new drivers when you can use existing ones :-) Describe the flash memory as mtd-ram (instead of cfi-flash) in the device tree and select the physmap driver in your kernel config. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The only way to get rid of a temptation is to yield to it. - Oscar Wilde ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 4/6] Add generic, reusable menu code
This will be used first by the pxecfg code, but is intended to be
generic and reusable for other jobs in U-boot.
Signed-off-by: Jason Hobbs jason.ho...@calxeda.com
---
changes in v2:
- new in v2
common/Makefile |1 +
common/menu.c | 338 +++
include/menu.h | 40 +++
3 files changed, 379 insertions(+), 0 deletions(-)
create mode 100644 common/menu.c
create mode 100644 include/menu.h
diff --git a/common/Makefile b/common/Makefile
index f81cff9..9b413cd 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -171,6 +171,7 @@ COBJS-$(CONFIG_CMD_KGDB) += kgdb.o kgdb_stubs.o
COBJS-$(CONFIG_KALLSYMS) += kallsyms.o
COBJS-$(CONFIG_LCD) += lcd.o
COBJS-$(CONFIG_LYNXKDI) += lynxkdi.o
+COBJS-$(CONFIG_MENU) += menu.o
COBJS-$(CONFIG_MODEM_SUPPORT) += modem.o
COBJS-$(CONFIG_UPDATE_TFTP) += update.o
COBJS-$(CONFIG_USB_KEYBOARD) += usb_kbd.o
diff --git a/common/menu.c b/common/menu.c
new file mode 100644
index 000..e92d302
--- /dev/null
+++ b/common/menu.c
@@ -0,0 +1,338 @@
+/*
+ * Copyright 2010-2011 Calxeda, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include common.h
+#include malloc.h
+#include errno.h
+#include linux/list.h
+
+#include menu.h
+
+struct menu_item {
+ char *key;
+ void *data;
+ struct list_head list;
+};
+
+struct menu {
+ struct menu_item *default_item;
+ int timeout;
+ char *title;
+ int prompt;
+ void (*item_data_print)(void *);
+ void (*item_data_destroy)(void *);
+ struct list_head items;
+};
+
+struct callback_with_data {
+ void *(*callback)(void *, void *);
+ void *data;
+};
+
+static inline void *menu_items_iter(struct menu *m,
+ void *(*callback)(struct menu *, struct menu_item *, void *),
+ void *extra)
+{
+ struct list_head *pos, *n;
+ struct menu_item *item;
+ void *ret;
+
+ list_for_each_safe(pos, n, m-items) {
+ item = list_entry(pos, struct menu_item, list);
+
+ ret = callback(m, item, extra);
+
+ if (ret)
+ return ret;
+ }
+
+ return NULL;
+}
+
+static inline void *menu_item_print(struct menu *m,
+ struct menu_item *item,
+ void *extra)
+{
+ if (!m-item_data_print)
+ printf(%s:\n, item-key);
+ else
+ m-item_data_print(item-data);
+
+ return NULL;
+}
+
+static inline void *menu_item_destroy(struct menu *m,
+ struct menu_item *item,
+ void *extra)
+{
+ if (m-item_data_destroy)
+ m-item_data_destroy(item-data);
+
+ if (item-key)
+ free(item-key);
+
+ free(item);
+
+ return NULL;
+}
+
+static inline void menu_display(struct menu *m)
+{
+ if (m-title)
+ printf(%s\n, m-title);
+
+ menu_items_iter(m, menu_item_print, NULL);
+}
+
+static inline void *menu_item_key_match(struct menu *m,
+ struct menu_item *item,
+ void *key)
+{
+ if (!key || !item-key) {
+ if (key == item)
+ return item;
+
+ return NULL;
+ }
+
+ if (strcmp(item-key, key) == 0)
+ return item;
+
+ return NULL;
+}
+
+static inline struct menu_item *menu_item_by_key(struct menu *m, char *key)
+{
+ return menu_items_iter(m, menu_item_key_match, key);
+}
+
+static inline void *menu_item_data_cb(struct menu *m,
+ struct menu_item *item,
+ void *extra)
+{
+
+ struct callback_with_data *cb_data = extra;
+
+ return cb_data-callback(item-data, cb_data-data);
+}
+
+static inline int delay_for_input(int timeout)
+{
+ if (!timeout)
+ return 0;
+
+ if (abortboot(timeout/10)) {
+ printf(autoboot aborted!\n);
+ return 1;
+ }
+
+ return 0;
+}
+
+void *menu_items_data_iter(struct menu *m,
+ void *(*callback)(void *, void *),
+ void *extra)
+{
+ struct callback_with_data cb_data;
+
+ if (!m || !callback)
+ return NULL;
+
+ cb_data.callback = callback;
+
[U-Boot] [PATCH v2 0/6] Add support for pxecfg commands
The pxecfg commands provide a near subset of the functionality provided by the PXELINUX boot loader. This allows U-boot based systems to be controlled remotely using the same PXE based techniques that many non U-boot based servers use. To avoid identity confusion with PXELINUX, and because not all behavior is identical, we call this feature 'pxecfg'. As an example, support for the pxecfg commands is enabled for the ca9x4_ct_vxp config. Additional details are available in the README file added as part of this patch series. v2 of this patch series separates the menu code from the pxecfg code, giving a reusable menu implementation. It also contains various smaller changes documented in the comment section of the patches. Jason Hobbs (6): cosmetic, main: correct indentation/spacing issues common: add run_command2 for running simple or hush commands common: make abortboot available for menu use Add generic, reusable menu code Add pxecfg command arm: ca9x4_ct_vxp: enable pxecfg support common/Makefile|2 + common/cmd_pxecfg.c| 924 common/hush.c |2 +- common/main.c | 60 ++-- common/menu.c | 338 +++ doc/README.pxecfg | 238 +++ include/common.h |7 + include/configs/ca9x4_ct_vxp.h |5 + include/hush.h |2 +- include/menu.h | 40 ++ 10 files changed, 1584 insertions(+), 34 deletions(-) create mode 100644 common/cmd_pxecfg.c create mode 100644 common/menu.c create mode 100644 doc/README.pxecfg create mode 100644 include/menu.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/6] common: add run_command2 for running simple or hush commands
Signed-off-by: Jason Hobbs jason.ho...@calxeda.com
---
changes in v2:
- whitespace correction
common/hush.c|2 +-
common/main.c| 46 +++---
include/common.h |1 +
include/hush.h |2 +-
4 files changed, 22 insertions(+), 29 deletions(-)
diff --git a/common/hush.c b/common/hush.c
index 85a6030..940889b 100644
--- a/common/hush.c
+++ b/common/hush.c
@@ -3217,7 +3217,7 @@ int parse_stream_outer(struct in_str *inp, int flag)
#ifndef __U_BOOT__
static int parse_string_outer(const char *s, int flag)
#else
-int parse_string_outer(char *s, int flag)
+int parse_string_outer(const char *s, int flag)
#endif /* __U_BOOT__ */
{
struct in_str input;
diff --git a/common/main.c b/common/main.c
index f05ee53..1f64523 100644
--- a/common/main.c
+++ b/common/main.c
@@ -342,12 +342,7 @@ void main_loop (void)
int prev = disable_ctrlc(1);/* disable Control C checking */
# endif
-# ifndef CONFIG_SYS_HUSH_PARSER
- run_command (p, 0);
-# else
- parse_string_outer(p, FLAG_PARSE_SEMICOLON |
- FLAG_EXIT_FROM_LOOP);
-# endif
+ run_command2(p, 0);
# ifdef CONFIG_AUTOBOOT_KEYED
disable_ctrlc(prev);/* restore Control C checking */
@@ -392,12 +387,7 @@ void main_loop (void)
int prev = disable_ctrlc(1);/* disable Control C checking */
# endif
-# ifndef CONFIG_SYS_HUSH_PARSER
- run_command (s, 0);
-# else
- parse_string_outer(s, FLAG_PARSE_SEMICOLON |
- FLAG_EXIT_FROM_LOOP);
-# endif
+ run_command2(s, 0);
# ifdef CONFIG_AUTOBOOT_KEYED
disable_ctrlc(prev);/* restore Control C checking */
@@ -407,14 +397,8 @@ void main_loop (void)
# ifdef CONFIG_MENUKEY
if (menukey == CONFIG_MENUKEY) {
s = getenv(menucmd);
- if (s) {
-# ifndef CONFIG_SYS_HUSH_PARSER
- run_command(s, 0);
-# else
- parse_string_outer(s, FLAG_PARSE_SEMICOLON |
- FLAG_EXIT_FROM_LOOP);
-# endif
- }
+ if (s)
+ run_command2(s, 0);
}
#endif /* CONFIG_MENUKEY */
#endif /* CONFIG_BOOTDELAY */
@@ -1396,6 +1380,19 @@ int run_command (const char *cmd, int flag)
return rc ? rc : repeatable;
}
+int run_command2(const char *cmd, int flag)
+{
+#ifndef CONFIG_SYS_HUSH_PARSER
+ if (run_command(cmd, flag) == -1)
+ return 1;
+#else
+ if (parse_string_outer(cmd,
+ FLAG_PARSE_SEMICOLON | FLAG_EXIT_FROM_LOOP) != 0)
+ return 1;
+#endif
+ return 0;
+}
+
//
#if defined(CONFIG_CMD_RUN)
@@ -1413,14 +1410,9 @@ int do_run (cmd_tbl_t * cmdtp, int flag, int argc, char
* const argv[])
printf (## Error: \%s\ not defined\n, argv[i]);
return 1;
}
-#ifndef CONFIG_SYS_HUSH_PARSER
- if (run_command (arg, flag) == -1)
- return 1;
-#else
- if (parse_string_outer(arg,
- FLAG_PARSE_SEMICOLON | FLAG_EXIT_FROM_LOOP) != 0)
+
+ if (run_command2(arg, flag) != 0)
return 1;
-#endif
}
return 0;
}
diff --git a/include/common.h b/include/common.h
index 1e4a6a5..e659630 100644
--- a/include/common.h
+++ b/include/common.h
@@ -228,6 +228,7 @@ int print_buffer (ulong addr, void* data, uint width, uint
count, uint linelen);
/* common/main.c */
void main_loop (void);
intrun_command (const char *cmd, int flag);
+intrun_command2(const char *cmd, int flag);
intreadline(const char *const prompt);
intreadline_into_buffer(const char *const prompt, char * buffer);
intparse_line (char *, char *[]);
diff --git a/include/hush.h b/include/hush.h
index 5c566cc..ecf9222 100644
--- a/include/hush.h
+++ b/include/hush.h
@@ -29,7 +29,7 @@
#define FLAG_REPARSING (1 2)/* =2nd pass */
extern int u_boot_hush_start(void);
-extern int parse_string_outer(char *, int);
+extern int parse_string_outer(const char *, int);
extern int parse_file_outer(void);
int set_local_var(const char *s, int flg_export);
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 5/6] Add pxecfg command
Add pxecfg command, which is intended to mimic PXELINUX functionality.
'pxecfg get' uses tftp to retrieve a file based on UUID, MAC address or
IP address. 'pxecfg boot' interprets the contents of PXELINUX config
like file to boot using a specific initrd, kernel and kernel command
line.
This patch also adds a README.pxecfg file - see it for more details on
the pxecfg command.
Signed-off-by: Jason Hobbs jason.ho...@calxeda.com
---
changes in v2:
- call abortboot directly instead of via a wrapper
- change the license to GPLv2+
- cleanup brace usage in multiline statements, conditionals
- allow bootfile to not exist, or to be a standalone filename
- try to clarify what's going on with get_relfile
- try cfg paths one by one instead of building an array
- refactor getenv/printfs to a new from_env function
- use the new generic menu code instead of that being integrated
- drop the ifdef from do_tftp in common.h
- use a clearer comment wrt to localcmd dup
- default to no timeout
common/Makefile |1 +
common/cmd_pxecfg.c | 924 +++
doc/README.pxecfg | 238 +
include/common.h|3 +
4 files changed, 1166 insertions(+), 0 deletions(-)
create mode 100644 common/cmd_pxecfg.c
create mode 100644 doc/README.pxecfg
diff --git a/common/Makefile b/common/Makefile
index 9b413cd..8885c6d 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -136,6 +136,7 @@ COBJS-$(CONFIG_CMD_PCI) += cmd_pci.o
endif
COBJS-y += cmd_pcmcia.o
COBJS-$(CONFIG_CMD_PORTIO) += cmd_portio.o
+COBJS-$(CONFIG_CMD_PXECFG) += cmd_pxecfg.o
COBJS-$(CONFIG_CMD_REGINFO) += cmd_reginfo.o
COBJS-$(CONFIG_CMD_REISER) += cmd_reiser.o
COBJS-$(CONFIG_CMD_SATA) += cmd_sata.o
diff --git a/common/cmd_pxecfg.c b/common/cmd_pxecfg.c
new file mode 100644
index 000..b44db8c
--- /dev/null
+++ b/common/cmd_pxecfg.c
@@ -0,0 +1,924 @@
+/*
+ * Copyright 2010-2011 Calxeda, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+#include common.h
+#include command.h
+#include malloc.h
+#include linux/string.h
+#include linux/ctype.h
+#include errno.h
+
+#include menu.h
+
+#define MAX_TFTP_PATH_LEN 127
+
+static char *from_env(char *envvar)
+{
+ char *ret;
+
+ ret = getenv(envvar);
+
+ if (!ret)
+ printf(missing environment variable: %s\n, envvar);
+
+ return ret;
+}
+
+/*
+ * Returns the ethaddr environment variable formated with -'s instead of :'s
+ */
+static void format_mac_pxecfg(char **outbuf)
+{
+ char *p, *ethaddr;
+
+ *outbuf = NULL;
+
+ ethaddr = from_env(ethaddr);
+
+ if (!ethaddr)
+ return;
+
+ *outbuf = strdup(ethaddr);
+
+ if (*outbuf == NULL)
+ return;
+
+ for (p = *outbuf; *p; p++) {
+ if (*p == ':')
+ *p = '-';
+ }
+}
+
+/*
+ * Returns the directory the file specified in the bootfile env variable is
+ * in.
+ */
+static char *get_bootfile_path(void)
+{
+ char *bootfile, *bootfile_path, *last_slash;
+ size_t path_len;
+
+ bootfile = from_env(bootfile);
+
+ if (!bootfile)
+ return NULL;
+
+ last_slash = strrchr(bootfile, '/');
+
+ if (last_slash == NULL)
+ return NULL;
+
+ path_len = (last_slash - bootfile) + 1;
+
+ bootfile_path = malloc(path_len + 1);
+
+ if (bootfile_path == NULL) {
+ printf(out of memory\n);
+ return NULL;
+ }
+
+ strncpy(bootfile_path, bootfile, path_len);
+
+ bootfile_path[path_len] = '\0';
+
+ return bootfile_path;
+}
+
+/*
+ * As in pxelinux, paths to files in pxecfg files are relative to the location
+ * of bootfile. get_relfile takes a path from a pxecfg file and joins it with
+ * the bootfile path to get the full path to the target file.
+ */
+static int get_relfile(char *file_path, void *file_addr)
+{
+ char *bootfile_path;
+ size_t path_len;
+ char relfile[MAX_TFTP_PATH_LEN+1];
+ char addr_buf[10];
+ char *tftp_argv[] = {tftp, NULL, NULL, NULL};
+
+ bootfile_path = get_bootfile_path();
+
+ path_len = strlen(file_path);
+
+ if (bootfile_path)
+ path_len += strlen(bootfile_path);
+
+ if (path_len MAX_TFTP_PATH_LEN) {
+ printf(Base path too long (%s%s)\n,
+
[U-Boot] [PATCH v2 1/6] cosmetic, main: correct indentation/spacing issues
Signed-off-by: Jason Hobbs jason.ho...@calxeda.com
---
changes in v2:
- new in v2
common/main.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/common/main.c b/common/main.c
index dcbacc9..f05ee53 100644
--- a/common/main.c
+++ b/common/main.c
@@ -406,15 +406,15 @@ void main_loop (void)
# ifdef CONFIG_MENUKEY
if (menukey == CONFIG_MENUKEY) {
- s = getenv(menucmd);
- if (s) {
+ s = getenv(menucmd);
+ if (s) {
# ifndef CONFIG_SYS_HUSH_PARSER
- run_command (s, 0);
+ run_command(s, 0);
# else
- parse_string_outer(s, FLAG_PARSE_SEMICOLON |
- FLAG_EXIT_FROM_LOOP);
+ parse_string_outer(s, FLAG_PARSE_SEMICOLON |
+ FLAG_EXIT_FROM_LOOP);
# endif
- }
+ }
}
#endif /* CONFIG_MENUKEY */
#endif /* CONFIG_BOOTDELAY */
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/6] common: make abortboot available for menu use
Signed-off-by: Jason Hobbs jason.ho...@calxeda.com
---
changes in v2:
- expose abortboot externally instead of using a wrapper
- expose abortboot externally when CONFIG_MENU is set
common/main.c| 12
include/common.h |3 +++
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/common/main.c b/common/main.c
index 1f64523..a031a33 100644
--- a/common/main.c
+++ b/common/main.c
@@ -56,10 +56,6 @@ void update_tftp (void);
#define MAX_DELAY_STOP_STR 32
-#if defined(CONFIG_BOOTDELAY) (CONFIG_BOOTDELAY = 0)
-static int abortboot(int);
-#endif
-
#undef DEBUG_PARSER
charconsole_buffer[CONFIG_SYS_CBSIZE + 1]; /* console I/O buffer
*/
@@ -91,7 +87,11 @@ extern void mdm_init(void); /* defined in board.c */
*/
#if defined(CONFIG_BOOTDELAY) (CONFIG_BOOTDELAY = 0)
# if defined(CONFIG_AUTOBOOT_KEYED)
+#ifdef CONFIG_MENU
+int abortboot(int bootdelay)
+#else
static __inline__ int abortboot(int bootdelay)
+#endif
{
int abort = 0;
uint64_t etime = endtick(bootdelay);
@@ -205,7 +205,11 @@ static __inline__ int abortboot(int bootdelay)
static int menukey = 0;
#endif
+#ifdef CONFIG_MENU
+int abortboot(int bootdelay)
+#else
static __inline__ int abortboot(int bootdelay)
+#endif
{
int abort = 0;
diff --git a/include/common.h b/include/common.h
index e659630..d8b8a79 100644
--- a/include/common.h
+++ b/include/common.h
@@ -234,6 +234,9 @@ int readline_into_buffer(const char *const prompt, char
* buffer);
intparse_line (char *, char *[]);
void init_cmd_timeout(void);
void reset_cmd_timeout(void);
+#ifdef CONFIG_MENU
+intabortboot(int bootdelay);
+#endif
/* arch/$(ARCH)/lib/board.c */
void board_init_f (ulong) __attribute__ ((noreturn));
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 6/6] arm: ca9x4_ct_vxp: enable pxecfg support
Signed-off-by: Jason Hobbs jason.ho...@calxeda.com --- changes in v2: - use CONFIG_MENU to enable building the menu for pxecfg use include/configs/ca9x4_ct_vxp.h |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/include/configs/ca9x4_ct_vxp.h b/include/configs/ca9x4_ct_vxp.h index 7f83249..f3d0e3f 100644 --- a/include/configs/ca9x4_ct_vxp.h +++ b/include/configs/ca9x4_ct_vxp.h @@ -73,6 +73,8 @@ /* Command line configuration */ #define CONFIG_CMD_BDI #define CONFIG_CMD_DHCP +#define CONFIG_CMD_PXECFG +#define CONFIG_MENU #define CONFIG_CMD_ELF #define CONFIG_CMD_ENV #define CONFIG_CMD_FLASH @@ -136,6 +138,9 @@ kerneladdr=0x4410\0 \ initrdaddr=0x4480\0 \ maxinitrd=0x180\0 \ + pxecfg_ram=0x8800\0 \ + initrd_ram=0x6100\0 \ + kernel_ram=0x80008000\0 \ console=ttyAMA0,38400n8\0 \ dram=1024M\0 \ root=/dev/sda1 rw\0 \ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reg. CFI flash_init and hardware write protected devices
On Thu, Jun 23, 2011 at 7:55 PM, Wolfgang Denk w...@denx.de wrote: Dear Frank, In message BANLkTi=p9gdogoetwojrqkmrxxm7do_...@mail.gmail.com you wrote: CFI flash chips with the level of write protection you implemented have to be dealt with in the same way as other ROM memory. =A0Normal CFI driver are not appropriate here. Ok. So you recommend I stop hacking the CFI probing and instead write a custom flash map driver? No. Never write new drivers when you can use existing ones :-) Describe the flash memory as mtd-ram (instead of cfi-flash) in the device tree and select the physmap driver in your kernel config. Oh. I will try that. Thanks a lot for this tip :) .. and sorry for asking about Linux related topics on the U-Boot ML. Best regards, Frank ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] TI: TNETV107X Fix Build Error
This patch provides SDRAM base address and initial stack address to fix build errors. Signed-off-by: Chan-Taek Park c-p...@ti.com --- include/configs/tnetv107x_evm.h |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/configs/tnetv107x_evm.h b/include/configs/tnetv107x_evm.h index 3627ce7..4bced0c 100644 --- a/include/configs/tnetv107x_evm.h +++ b/include/configs/tnetv107x_evm.h @@ -57,6 +57,12 @@ #define CONFIG_NR_DRAM_BANKS 1 #define CONFIG_STACKSIZE (256*1024) +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_RAM_SIZE 0x1000 +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + \ +CONFIG_SYS_INIT_RAM_SIZE - \ +GENERATED_GBL_DATA_SIZE) + /* Serial Driver Info */ #define CONFIG_SYS_NS16550 #define CONFIG_SYS_NS16550_SERIAL -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 0/9] armv7: cache maintenance operations
Hi All, Le 17/06/2011 11:30, Aneesh V a écrit : With D-cache and MMU enabled for ARM in u-boot it becomes imperative to support a minimal set of cache maintenance operations and necessary initializations before enabling MMU. This series of patches attempt to do the following for armv7: * Necessary initialization sequence before enabling MMU that includes invalidation of TLB, data caches, branch predictor array etc. * Framework for supporting SOC specific outer caches in a generic manner (using a structure of function pointers - inspired by the Linux implementation) * Generic armv7 cache maintenance operations for caches known to the CPU * Support for ARM PL310 L2 cache controller used in OMAP4 * Cleanup of the cleanup_before_linux() function * Adapting all armv7 SOCs to use the new framework and removing duplicated code Sandeep, Minkyu: is the patch series OK with you? If so I'll pull it all in ARM and issue a last pull request. Amicalement, -- Albert. I am fine with it. Acked-by: Sandeep Paulraj s-paul...@ti.com --Sandeep ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/6] Add generic, reusable menu code
Dear Jason Hobbs, In message 1308853655-12407-5-git-send-email-jason.ho...@calxeda.com you wrote: This will be used first by the pxecfg code, but is intended to be generic and reusable for other jobs in U-boot. Signed-off-by: Jason Hobbs jason.ho...@calxeda.com --- changes in v2: - new in v2 common/Makefile |1 + common/menu.c | 338 +++ include/menu.h | 40 +++ 3 files changed, 379 insertions(+), 0 deletions(-) create mode 100644 common/menu.c create mode 100644 include/menu.h Is this all new code, or was it copied from some other project? If so, reference would be needed. Then, we need documentation how this is going to be used. Please add a README with documentation of the interfaces and usage examples. Also, I would like to know why you didn't adapt for example the menu code from barebox - which specific advantages do you see in the code you have chosen? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I think it's a new feature. Don't tell anyone it was an accident. :-) -- Larry Wall on s/foo/bar/eieio in 10...@jpl-devvax.jpl.nasa.gov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] NAND: Add 16bit NAND support for the NDFC
On Thu, Jun 16, 2011 at 04:06:22PM -0400, Alex Waterman wrote: From 99efc91f7a3d55bcf0e839ae30c286fd08166010 Mon Sep 17 00:00:00 2001 From: Alex Waterman awater...@dawning.com Date: Thu, 19 May 2011 15:08:36 -0400 Subject: [PATCH] NAND: Add 16bit NAND support for the NDFC This patch adds support for 16 bit NAND devices attached to the NDFC on ppc4xx processors. Two config entries were added: CONFIG_SYS_NDFC_16- Setting this tells the NDFC that a 16 bit device is attached. CONFIG_SYS_NDFC_EBC0_CFG - This is for the External Bus Controller configuration register. Also, a new ndfc_read_byte() function was added which does not first convert the data to little endian. The NAND SPL was also modified to do 16bit bad block testing when a 16 bit chip is being used. Signed-off-by: Alex Waterman awater...@dawning.com --- Applied to u-boot-nand-flash next -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add assert() for debug assertions
On Wed, Jun 22, 2011 at 3:08 PM, Mike Frysinger vap...@gentoo.org wrote: On Wednesday, June 22, 2011 17:56:49 Wolfgang Denk wrote: Mike Frysinger wrote: the trouble with ifdef magic like this is that errors/warnings can be=20 introduced when DEBUG isnt defined, and then only noticed when DEBUG is=20 defined. so how about: #ifdef DEBUG # define _DEBUG 1 #else # define _DEBUG 2 1 and 2? You don't happen to mean 1 and 0 ? err, of course. i had something semi-related on my mind as i banged that out. Hi Mike Wolfgang, That sounds better thanks, I will send a new patch. It would be good to have it compile the same code in and out of DEBUG mode. Regards, Simon -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add assert() for debug assertions
On Wed, Jun 22, 2011 at 10:49 PM, V, Aneesh ane...@ti.com wrote:
On Thu, Jun 23, 2011 at 2:53 AM, Mike Frysinger vap...@gentoo.org wrote:
On Wednesday, June 22, 2011 17:04:49 Simon Glass wrote:
+/*
+ * An assertion is run-time check done in debug mode only. If DEBUG is not
+ * defined then it is skipped. It does not BUG or halt U-Boot, but tries
to + * continue execution in any case. It is hoped that all failing
assertions + * are found before release, and after release it is hoped
that they don't + * matter. But in any case these failing assertions
cannot be fixed with a + * BUG-type reset (which may just do the same
assertion again).
+ */
+#define assert(x) \
+ ({ if (!(x)) printf(Assertion failure '%s' %s line %d\n, \
+ #x, __FILE__, __LINE__); })
#else
#define debug(fmt,args...)
#define debugX(level,fmt,args...)
+#define assert(x)
#endif /* DEBUG */
the trouble with ifdef magic like this is that errors/warnings can be
introduced when DEBUG isnt defined, and then only noticed when DEBUG is
defined. so how about:
Hi Aneesh,
Symbian OS, that had an array of defensive programming features, had two
ASSERT macros:
Something like ASSERT_DEBUG(x) and ASSERT_ALWAYS(x).
Symbian OS can live on in U-Boot!
ASSERT_DEBUG(x) could be used more liberally because it is compiled out in
production image and ASSERT_ALWAYS(x) could be used in more critical run-time
errors.
My rule of thumb for using these two was this:
1. ASSERT_DEBUG(x) was used for invariant checking, that's for catching errors
that could arise out of programming errors. This was used more liberally in
the
code.
2. ASSERT_ALWAYS(x) was used to catch erros due to invalid run-time parameters
that one may not be able to catch during testing.
With this patch we have:
- assert: compiled out for production code, used for debug, like your
ASSERT_DEBUG I think
- BUG_ON: halt/reset even in production code, used for production code
and critical faults where continued execution is certainly pointless
or counterproductive. Like your ASSERT_ALWAYS I think.
Regards,
Simon
best regards,
Aneesh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] THANK YOU
I am Dr Jacob Clark, Human Resource Manager for Agricultural and Mineral Research Institute. A new job opening in your area, It's a work from home/office position and you are not required to pay any registration fee or pay for any application form before you getemployed. kindly reply immediately. This space is opened ti ll the 9th of JULY 2011. Please email me back full name.. Your full home address.. city .state Regards, Dr Jacob Clark ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add assert() for debug assertions
On Thursday, June 23, 2011 17:39:12 Simon Glass wrote: - BUG_ON: halt/reset even in production code, used for production code and critical faults where continued execution is certainly pointless or counterproductive. Like your ASSERT_ALWAYS I think. if we're going to go this route, then we should just take the API linux already has. that means WARN/WARN_ON/BUG/BUG_ON. we've got more in common with linux than we'll ever have with symbian. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/6] common: make abortboot available for menu use
On Thursday, June 23, 2011 14:27:32 Jason Hobbs wrote:
+#ifdef CONFIG_MENU
+int abortboot(int bootdelay)
+#else
static __inline__ int abortboot(int bootdelay)
+#endif
more ifdef trickery here than necessary:
#ifndef CONFIG_MENU
static inline
#endif
int abortboot(int bootdelay)
{
-mike
signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Add assert() for debug assertions
assert() is like BUG_ON() but compiles to nothing unless DEBUG is defined.
This is useful when a condition is an error but a board reset is unlikely
to fix it, so it is better to soldier on in hope. Assertion failures should
be caught during development/test.
It turns out that assert() is defined separately in a few places in U-Boot
with various meanings. This patch cleans up some of these.
Build errors exposed by this change (and defining DEBUG) are also fixed in
this patch.
Signed-off-by: Simon Glass s...@chromium.org
---
V2:
* Changed macros so that all code is compiled even if DEBUG is disabled
---
common/dlmalloc.c |7 ---
include/common.h | 19 +++
include/malloc.h |8
lib/qsort.c |5 -
4 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index e9bab09..f2080c6 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -286,13 +286,6 @@ extern C {
*/
-#ifdef DEBUG
-#include assert.h
-#else
-#define assert(x) ((void)0)
-#endif
-
-
/*
INTERNAL_SIZE_T is the word-size used for internal bookkeeping
of chunk sizes. On a 64-bit machine, you can reduce malloc
diff --git a/include/common.h b/include/common.h
index 1e21b7a..6181e07 100644
--- a/include/common.h
+++ b/include/common.h
@@ -124,6 +124,25 @@ typedef volatile unsigned char vu_char;
#define debugX(level,fmt,args...)
#endif /* DEBUG */
+#ifdef DEBUG
+# define _DEBUG 1
+#else
+# define _DEBUG 0
+#endif
+
+/*
+ * An assertion is run-time check done in debug mode only. If DEBUG is not
+ * defined then it is skipped. It does not BUG or halt U-Boot, but tries to
+ * continue execution in any case. It is hoped that all failing assertions
+ * are found before release, and after release it is hoped that they don't
+ * matter. But in any case these failing assertions cannot be fixed with a
+ * BUG-type reset (which may just do the same assertion again).
+ */
+#define assert(x) \
+ ({ if (!(x) _DEBUG) \
+ printf(Assertion failure '%s' %s line %d\n, \
+ #x, __FILE__, __LINE__); })
+
#define error(fmt, args...) do { \
printf(ERROR: fmt \nat %s:%d/%s()\n, \
##args, __FILE__, __LINE__, __func__); \
diff --git a/include/malloc.h b/include/malloc.h
index 3e145ad..ecf3c67 100644
--- a/include/malloc.h
+++ b/include/malloc.h
@@ -285,14 +285,6 @@ extern C {
*/
-#ifdef DEBUG
-/* #include assert.h */
-#define assert(x) ((void)0)
-#else
-#define assert(x) ((void)0)
-#endif
-
-
/*
INTERNAL_SIZE_T is the word-size used for internal bookkeeping
of chunk sizes. On a 64-bit machine, you can reduce malloc
diff --git a/lib/qsort.c b/lib/qsort.c
index 1cc0d31..86c392c 100644
--- a/lib/qsort.c
+++ b/lib/qsort.c
@@ -17,11 +17,6 @@
#include linux/types.h
#include exports.h
-#if 0
-#include assert.h
-#else
-#define assert(arg)
-#endif
void qsort(void *base,
size_t nel,
--
1.7.3.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Add assert() for debug assertions
Acked-by: Mike Frysinger vap...@gentoo.org -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] USB: Ethernet: asix.c: Added support for AX88178 based devices
Hi David,
Thanks for the patch - I have tried this and things still work, but I
don't think I have a Belkin F5D5055 Gig USB to test with. No matter.
Please see below form comments.
On Tue, May 31, 2011 at 5:58 AM, David Jander da...@protonic.nl wrote:
Completed command definitions copied from linux driver source.
Implemented support for AX88178 by copying and rewriting bits and pieces
from the linux asix driver.
Signed-off-by: David Jander da...@protonic.nl
---
drivers/usb/eth/asix.c | 236
+---
include/usb_ether.h | 1 +
2 files changed, 224 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/eth/asix.c b/drivers/usb/eth/asix.c
index 9b012e4..cecbc76 100644
--- a/drivers/usb/eth/asix.c
+++ b/drivers/usb/eth/asix.c
@@ -310,7 +331,7 @@ static int mii_nway_restart(struct ueth_data *dev)
/*
* Asix callbacks
*/
-static int asix_init(struct eth_device *eth, bd_t *bd)
+static int asix_init_ax88772(struct eth_device *eth, bd_t *bd)
{
int embd_phy;
unsigned char buf[ETH_ALEN];
@@ -419,6 +440,190 @@ out_err:
return -1;
}
+/**
+ * mii_check_media - check the MII interface for a duplex change
+ * @mii: the MII interface
+ * @ok_to_print: OK to print link up/down messages
+ * @init_media: OK to save duplex mode in @mii
+ *
+ * Returns 1 if the duplex mode changed, 0 if not.
+ * If the media type is forced, always returns 0.
+ */
+unsigned int mii_check_media (struct eth_device *eth,
Please remove space before (
+ unsigned int ok_to_print,
+ unsigned int init_media)
+{
+ int advertise, lpa, media, duplex;
+ int lpa2 = 0;
+ struct ueth_data *dev = (struct ueth_data *)eth-priv;
+
+ /* get MII advertise and LPA values */
+ advertise = asix_mdio_read(dev, dev-phy_id, MII_ADVERTISE);
+ lpa = asix_mdio_read(dev, dev-phy_id, MII_LPA);
+ lpa2 = asix_mdio_read(dev, dev-phy_id, MII_STAT1000);
+
+ /* figure out media and duplex from advertise and LPA values */
+ media = mii_nway_result(lpa advertise);
+ duplex = (media ADVERTISE_FULL) ? 1 : 0;
+ if (lpa2 LPA_1000FULL)
+ duplex = 1;
+
+ printf(link up, %uMbps, %s-duplex, lpa 0x%04X\n,
+ lpa2 (LPA_1000FULL | LPA_1000HALF) ? 1000 :
+ media (ADVERTISE_100FULL | ADVERTISE_100HALF) ?
+ 100 : 10,
+ duplex ? full : half,
+ lpa);
+
+ return 0; /* duplex did not change */
+}
+
+static int ax88178_link_reset(struct eth_device *eth)
+{
+ u16 mode;
+ struct ueth_data *dev = (struct ueth_data *)eth-priv;
+
+ debug(ax88178_link_reset()\n);
+
+ mii_check_media(eth, 1, 1);
+ mode = AX88178_MEDIUM_DEFAULT;
+
+ /* All supported ax88178 dongles have GMII */
+ mode |= AX_MEDIUM_GM;
+ mode |= AX_MEDIUM_ENCK;
+ mode |= AX_MEDIUM_FD;
+
+ asix_write_medium_mode(dev, mode);
+
+ return 0;
+}
+
+static int asix_init_ax88178(struct eth_device *eth, bd_t *bd)
+{
+ unsigned char buf[ETH_ALEN];
+ int phymode, ledmode;
+ int gpio0 = 0;
+ u8 status;
+ __le16 eeprom;
+ struct ueth_data *dev = (struct ueth_data *)eth-priv;
+ int timeout = 0;
+#define TIMEOUT_RESOLUTION 50 /* ms */
+ int link_detected;
+
+ debug(** %s()\n, __func__);
+
+ asix_read_cmd(dev, AX_CMD_READ_GPIOS, 0, 0, 1, status);
+ debug(GPIO Status: 0x%04x\n, status);
+
+ asix_write_cmd(dev, AX_CMD_WRITE_ENABLE, 0, 0, 0, NULL);
+ asix_read_cmd(dev, AX_CMD_READ_EEPROM, 0x0017, 0, 2, eeprom);
+ asix_write_cmd(dev, AX_CMD_WRITE_DISABLE, 0, 0, 0, NULL);
+
+ debug(EEPROM index 0x17 is 0x%04x\n, eeprom);
+ if (eeprom == cpu_to_le16(0x)) {
+ printf(Error: Marvell phy not supported\n);
+ return -1;
+ } else {
+ phymode = le16_to_cpu(eeprom) 7;
+ ledmode = le16_to_cpu(eeprom) 8;
+ gpio0 = (le16_to_cpu(eeprom) 0x80) ? 0 : 1;
+ }
+ debug(GPIO0: %d, PhyMode: %d\n, gpio0, phymode);
+
+ asix_write_gpio(dev, AX_GPIO_RSE | AX_GPIO_GPO_1 | AX_GPIO_GPO1EN,
40);
+ if ((le16_to_cpu(eeprom) 8) != 1) {
+ asix_write_gpio(dev, 0x003c, 30);
+ asix_write_gpio(dev, 0x001c, 300);
+ asix_write_gpio(dev, 0x003c, 30);
+ } else {
+ debug(gpio phymode == 1 path\n);
+ asix_write_gpio(dev, AX_GPIO_GPO1EN, 30);
+ asix_write_gpio(dev, AX_GPIO_GPO1EN | AX_GPIO_GPO_1, 30);
+ }
+
+ asix_sw_reset(dev, 0);
+ udelay(15);
+
+ asix_sw_reset(dev, AX_SWRESET_PRL | AX_SWRESET_IPPD);
+
Re: [U-Boot] [PATCH v2 3/6] common: make abortboot available for menu use
Dear Jason Hobbs, In message 1308853655-12407-4-git-send-email-jason.ho...@calxeda.com you wrote: Signed-off-by: Jason Hobbs jason.ho...@calxeda.com --- changes in v2: - expose abortboot externally instead of using a wrapper - expose abortboot externally when CONFIG_MENU is set common/main.c| 12 include/common.h |3 +++ 2 files changed, 11 insertions(+), 4 deletions(-) ... +#ifdef CONFIG_MENU This being a new CONFIG_ variable, it must be documented in the README. But as is this makes little sense, so I suggest you change the order of your patches and add the abortboot support to the menu system in a second step, after adding (and documenting) the menu stuff. 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 have the capacity to learn from mistakes. You'll learn a lot today. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] Add assert() for debug assertions
Dear Simon Glass,
In message 1308870873-32540-1-git-send-email-...@chromium.org you wrote:
assert() is like BUG_ON() but compiles to nothing unless DEBUG is defined.
This is useful when a condition is an error but a board reset is unlikely
to fix it, so it is better to soldier on in hope. Assertion failures should
be caught during development/test.
It turns out that assert() is defined separately in a few places in U-Boot
with various meanings. This patch cleans up some of these.
Build errors exposed by this change (and defining DEBUG) are also fixed in
this patch.
Signed-off-by: Simon Glass s...@chromium.org
---
V2:
* Changed macros so that all code is compiled even if DEBUG is disabled
...
+#define assert(x)\
+ ({ if (!(x) _DEBUG) \
+ printf(Assertion failure '%s' %s line %d\n, \
+ #x, __FILE__, __LINE__); })
Can we please use the same message format as used by assert(3) ?
Afaict they use %s%s%s:%u: %s%sAssertion `%s' failed..
Also, to save on memory footprint (frequent repetition of the common
string Assertion failed) we should probably provide a separate
function for this (cf. /usr/include/assert.h).
Finally, should the assert() not result in some termination or hang of
U-Boot, like assert(3) is doing?
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
What the scientists have in their briefcases is terrifying.
- Nikita Khrushchev
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
