Re: [U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

> > Hi, All > > > > Each time JFFS2 initialized, uboot need to scan the whole flash. This is > fairly time consuming. > > > > So EBS(erase block summary) is used to JFFS2 to reduce mounting time. And I > believe this can also be used to UBOOT to reduce booting time. > > > > Does UBOOT suppor

[U-Boot] Does uboot EBS(erase block summary) to reduce JFFS2 scaning time?

Hi, All Each time JFFS2 initialized, uboot need to scan the whole flash. This is fairly time consuming. So EBS(erase block summary) is used to JFFS2 to reduce mounting time. And I believe this can also be used to UBOOT to reduce booting time. Does UBOOT support this feature? or

Re: [U-Boot] [PATCH 04/10] ARM Add New Board GEC2410

Dear Wolfgang, 2009/11/1 Wolfgang Denk : > Dear "Hui.Tang", > > In message > <6c7a9a5dcafb1f535ed33cb29d579db993846325.1256898456.git.zetal...@gmail.com> > you wrote: >> Add gec2410_config option for GEC2410 >> >> Signed-off-by: Hui.Tang >> --- >>  Makefile |    7 +++ >>  1 files changed, 7

[U-Boot] jffs2 FS flash occupation

Hi, all If I wish to support uImage in jffs2 FS in NAND flash, how many size will be used for JFFS2 FS itself, such as wearing level, GC, JFFS2 INODE header? For example, NAND fash size is 32M and uImage is 8M including application and kernel. Thanks Leon

Re: [U-Boot] Net driver questions

On Monday 02 November 2009 18:38:59 Krzysztof Halasa wrote: > Mike Frysinger writes: > >> Let's look... The code does NetSetHandler(TftpHandler). > >> I think NetReceive() calls (*packetHandler)() = TftpHandler and this one > >> may call NetStartAgain(). > > > > but this doesnt call recv(), and Net

Re: [U-Boot] Net driver questions

Mike Frysinger writes: >> Let's look... The code does NetSetHandler(TftpHandler). >> I think NetReceive() calls (*packetHandler)() = TftpHandler and this one >> may call NetStartAgain(). > > but this doesnt call recv(), and NetStartAgain() changes the handler, so i > still dont see recursion wit

Re: [U-Boot] Net driver questions

On Monday 02 November 2009 10:08:00 Krzysztof Halasa wrote: > Mike Frysinger writes: > > it's on purpose because it makes the code simpler -- no need to maintain > > state. drivers have to be able to handle halt() irregardless of init(). > > i dont see this being a problem for anyone. > > Ok. S

Re: [U-Boot] [RFC 3/5] CAN device driver for the SJA1000

Matthias Fuchs wrote: > Hi Wolfgang, > > of course I can think of situations where some simple CAN mechanism > might be helpful (e.g. simple hardware testing). > > But do we really need this inside a bootloader? Surely not > for a production build. But please keep on hacking! > > On Monday 02 N

[U-Boot] [PATCH v2] OMAP2/3: I2C: Add support for second and third bus

Add support to use second and third I2C bus, too. Bus 0 is still the default, but by calling i2c_set_bus_num(1/2) before doing I2C accesses, code can switch to bus 1 and 2, too. Don't forget to switch back afterwards, then. Signed-off-by: Dirk Behme --- Changes in v2: - Don't initialize stati

Re: [U-Boot] [PATCH] Add I2C multibus support for OMAP2/3 boards

Hi Heiko, Heiko Schocher wrote: > Dirk Behme wrote: >> I would remove the following three functions as they are not needed at >> the moment (i.e. without command line interface). > > Hmm... really? If someone uses multibus support, > this functions are needed, or? Well, most probably yes. But I

[U-Boot] [PATCH 3/4] Use LINK_OFF in enviroment too

This is the most complex change. Keep this one as a separate commit for now. --- common/env_flash.c | 65 +++ 1 files changed, 39 insertions(+), 26 deletions(-) diff --git a/common/env_flash.c b/common/env_flash.c index b860c48..64882d2 100644 ---

[U-Boot] [PATCH 1/4] ppc: Add const void *link_off(const void *addr)

Calculates the offset between global data link address and where the data is actually loaded. Add this offset to 'addr' arg and return the result. Useful for true PIC and when relocating code to RAM. --- include/common.h |7 +++ lib_ppc/reloc.S | 21 + 2 files change

[U-Boot] [PATCH 4/4] ppc: Make mpc83xx start.S relative.

To use a different link address than load address, start.S must not make any absolute accesses. This makes it so. Use link_off(), if defined, to calculate the difference in load and link address. --- cpu/mpc83xx/start.S | 35 --- 1 files changed, 28 insertions(+),

[U-Boot] [PATCH 2/4] Use LINK_OFF to access global data

Accessing global data before relocation needs special handling if link address != load address. Use LINK_OFF to calculate the difference. --- common/cmd_nvedit.c |2 ++ common/console.c | 12 +--- common/env_common.c |2 +- cpu/mpc83xx/cpu.c

[U-Boot] [PATCH 0/4] Make u-boot true PIC for ppc

This series adds link_off(), a function to calculate the difference between load address and link address. Using this function it is possible to make u-boot 100% PIC by wrapping global data accesses LINK_OFF() calls. Plenty of examples in the code to show how to use it. All start.S needs to be up

Re: [U-Boot] [PATCH 0/3] No GOT in IRQ and use r12 as GOT ptr

Joakim Tjernlund wrote on 02/11/2009 17:43:59: > > This series removes the needs to access the GOT in > IRQ handlers, then switches GOT PTR in start.S asm to > use r12 instead of r14. This leads up to the removal of > -ffixed-r14 gcc option for ppc > > Joakim Tjernlund (3): > ppc: Loose GOT acce

[U-Boot] [PATCH 3/3] ppc: remove -ffixed-r14 gcc option.

This is no loger needed, free up r14 for general usage. --- cpu/74xx_7xx/config.mk |2 +- cpu/mpc512x/config.mk |2 +- cpu/mpc5xx/config.mk |2 +- cpu/mpc5xxx/config.mk |2 +- cpu/mpc8220/config.mk |2 +- cpu/mpc824x/config.mk |2 +- cpu/mpc8260/config.mk |2 +-

[U-Boot] [PATCH 1/3] ppc: Loose GOT access in IRQ

Using the GOT in IRQ handlers requires r14 to be -ffixed-r14. Avoid this by relocatate transfer_to_handler too. This will allow to free up r14 later on. --- cpu/74xx_7xx/start.S | 36 +++- cpu/mpc512x/start.S | 35 +++ cpu/mpc5xx

[U-Boot] [PATCH 0/3] No GOT in IRQ and use r12 as GOT ptr

This series removes the needs to access the GOT in IRQ handlers, then switches GOT PTR in start.S asm to use r12 instead of r14. This leads up to the removal of -ffixed-r14 gcc option for ppc Joakim Tjernlund (3): ppc: Loose GOT access in IRQ ppc: Use r12 instead of r14 as GOT pointer. ppc:

[U-Boot] [PATCH 2/3] ppc: Use r12 instead of r14 as GOT pointer.

r14 is not supposed to be clobbered by functions. Switch to r12 and call GET_GOT when needed. This will allow u-boot to loose the -ffixed-r14 gcc option. --- cpu/74xx_7xx/start.S | 11 ++- cpu/mpc512x/start.S | 11 ++- cpu/mpc5xx/start.S | 11 ++- cpu/mpc5xxx/start

Re: [U-Boot] [RFC PATCH] Implementation of non-blocking flash write/erase/status check functions.

Dear Wolfgang Denk, On Fri, Oct 30, 2009 at 07:22:17PM +0100, Wolfgang Denk wrote: [...] > > 2 files changed, 365 insertions(+), 78 deletions(-) > > This summary alone is a pretty clear message to me. This is indeed a > lot of added, and even worse, duplicated code. I tried to address this by r

[U-Boot] [PATCH] non-blocking flash write/erase/status check functions

More tightly integrated non-blocking variants of some CFI flash access functions. Enable with CONFIG_SYS_FLASH_CFI_NONBLOCK These can be useful to erase flash or write complete sectors of flash during a serial data transfer for software updates. This re-worked patch addresses the code duplication,

Re: [U-Boot] [PATCH] OMAP2/3: I2C: Add support for second and third bus

Dirk Behme wrote: > Add support to use second and third I2C bus, too. > > Bus 0 is still the default, but by calling i2c_set_bus_num(1/2) before doing > I2C accesses, code can switch to bus 1 and 2, too. Don't forget to switch > back afterwards, then. > > Signed-off-by: Dirk Behme > --- > > Ba

[U-Boot] [PATCH v2] mkconfig: deny messed up ARCH definition

Refuse to setup a platform if the command line ARCH= is not the same as the one required for the board. This prevents any user with prehistoric aliases from messing up their builds. Reported in thread: http://old.nabble.com/-U-Boot--Build-breaks-on-some-OMAP3-configs-to26132721.html Inputs from:

Re: [U-Boot] [PATCH] mkconfig: deny messed up ARCH definition

> From: Wolfgang Denk [mailto:w...@denx.de] > Sent: Sunday, November 01, 2009 8:58 AM > > Dear Mike Frysinger, > > In message <200911010838.08938.vap...@gentoo.org> you wrote: > > > > > > > +if [ ! -z "$ARCH" -a "$ARCH" != "$2" ]; then > > > > > > > > is the !-z really needed ? > > > > > > We do

Re: [U-Boot] Net driver questions

Mike Frysinger writes: > it's on purpose because it makes the code simpler -- no need to maintain > state. drivers have to be able to handle halt() irregardless of init(). i > dont see this being a problem for anyone. Ok. Sure, that's not a problem for me, I just noted the README doesn't tal

[U-Boot] [PATCH] fsl_pci_init_port end-point initialization is broken

commit 70ed869e broke fsl pcie end-point initialization. Returning 0 is not correct. The function must return the first free bus number for the next controller. fsl_pci_init() must still be called and a bus allocated even if the controller is an end-point. Signed-off-by: Ed Swarthout --- This

Re: [U-Boot] Best way of making some drivers common across kirkwood and orion5x SoCs?

Prafulla Wadaskar a écrit : > >> Still, the drivers would be full of 'KWxxx" and "kwxxx" symbols of >> which many are not kirkwood-specific actually. > > Any way, those are not even orion specific nor Marvell specific. Those are related to the functionality supported by SOCs that may be > cu

Re: [U-Boot] [RFC 3/5] CAN device driver for the SJA1000

Hi Wolfgang, of course I can think of situations where some simple CAN mechanism might be helpful (e.g. simple hardware testing). But do we really need this inside a bootloader? Surely not for a production build. But please keep on hacking! On Monday 02 November 2009 13:50, Wolfgang Grandegger

Re: [U-Boot] [PATCH] Enable port-mapped access to 16550 UART

Hi Graeme, >> we at least start using the Linux convention and turn all the register >> accesses into "serial_{in,out}" and define these for X86 and !X86 like >> you did. >> >> This way should be somewhat clearer than defining a "writeb" not to be a >> writeb after all, which I find confusing. >>

Re: [U-Boot] [PATCH-ARM 1/3] Add support for the s3c2440 cpu excluding nand driver

Tom wrote: > kevin.morf...@fearnside-systems.co.uk wrote: >> This patch adds support for the s3c2440 cpu, excluding the nand driver. >> >> Tested on an Embest SBC2440-II Board with local u-boot patches as I don't >> have >> any s3c2400 or s3c2410 boards but need this patch applying before I can

Re: [U-Boot] [RFC 3/5] CAN device driver for the SJA1000

Matthias Fuchs wrote: > Hi Wolfgang, > > this patch conflicts with my simple SJA header posted some days ago > > http://lists.denx.de/pipermail/u-boot/2009-October/063097.html > > together with a fix for two of our boards - which has not much > to do with CAN. WD asked me to use a C struct to ac

Re: [U-Boot] [RFC 3/5] CAN device driver for the SJA1000

Hi Wolfgang, this patch conflicts with my simple SJA header posted some days ago http://lists.denx.de/pipermail/u-boot/2009-October/063097.html together with a fix for two of our boards - which has not much to do with CAN. WD asked me to use a C struct to access the SJA1000. http://lists.denx.

Re: [U-Boot] Best way of making some drivers common across kirkwood and orion5x SoCs?

> -Original Message- > From: Albert ARIBAUD [mailto:albert.arib...@free.fr] > Sent: Monday, November 02, 2009 3:34 PM > To: Prafulla Wadaskar > Cc: u-boot@lists.denx.de; Tom > Subject: Re: [U-Boot] Best way of making some drivers common > across kirkwood and orion5x SoCs? > > Prafulla

[U-Boot] [PATCH V2] Davinci: add a pin multiplexer configuration API

Davinci: add a pin multiplexer configuration API. Creates a method allowing pin settings to be logically grouped into data structure arrays and provids an API to configure the PINMUX settings to enable the relevant pin functions. Signed-off-by: Nick Thompson --- Applies to: u-boot-ti The PINMUX

[U-Boot] Arbeit zu Hause - Deutschland

Guten Tag, ELS, amerikanisches Unternehmen im Bereich luxurioser Guter, sucht AdministrationsassistentInnen/VerkauferInnen in Deutschland, der/die von zuhause aus arbeiten, unser Verkaufsteam verstarken und unsere Dienstleistungen aufwerten, welche fur Privatpersonen, Unternehmen und Organisati

Re: [U-Boot] Best way of making some drivers common across kirkwood and orion5x SoCs?

Prafulla Wadaskar a écrit : > Dear Albert > > I propose the following strategy for this- For orion- let's follow > the standard development strategy used for ARM architectures > including Kirkwood. Since orion and kirkwood has lot of similarities > but when both these will evolve for there entire

Re: [U-Boot] Best way of making some drivers common across kirkwood and orion5x SoCs?

Dear Albert > -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert ARIBAUD > Sent: Sunday, November 01, 2009 6:30 AM > To: u-boot@lists.denx.de > Subject: Re: [U-Boot] Best way of making some drivers common > across kirkwood

Re: [U-Boot] Best way of making some drivers common across kirkwood and orion5x SoCs?

Hi Albert > -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert ARIBAUD > Sent: Saturday, October 31, 2009 8:42 PM > To: u-boot@lists.denx.de > Subject: Re: [U-Boot] Best way of making some drivers common > across kirkwood

Re: [U-Boot] [u-boot] [PATCH][1/2] mx27: Add necessary defines and helper functions to support I2C in i.MX27.

Hello javier, javier Martin wrote: > 2009/11/2 Heiko Schocher : >> Hello Javier, >> >> Javier Martin wrote: >>> Add proper register definitions, macros and clock functions required >>> for I2C driver to be developed. >>> >>> >>> >>> Signed-off-by: Javier Martin >>> -- >>> diff --git a/cpu/arm926e

[U-Boot] strex/ldrex compilation error while using atomic_inc u-boot

Hi all, I am getting the following error while building using ARMV7 toolchain. {standard input}:599: Error: selected processor does not support `ldrex r1,[r2]' {standard input}:601: Error: selected processor does not support `strex r3,r1,[r2]' For example the following code uses strex and ldrex

Re: [U-Boot] [PATCH] Add I2C multibus support for OMAP2/3 boards

Hello Dirk, Dirk Behme wrote: > Tom Rix wrote: >> From: Syed Mohammed Khasim >> >> This was cherry-picked from >> >> repo: http://www.beagleboard.org/u-boot-arm.git >> commit: 52eddcd07c2e7ad61d15bab2cf2d0d21466eaca2 >> >> In addition to adding multibus support, this patch >> also cleans up the r

Re: [U-Boot] [u-boot] [PATCH][1/2] mx27: Add necessary defines and helper functions to support I2C in i.MX27.

2009/11/2 Heiko Schocher : > Hello Javier, > > Javier Martin wrote: >> Add proper register definitions, macros and clock functions required >> for I2C driver to be developed. >> >> >> >> Signed-off-by: Javier Martin >> -- >> diff --git a/cpu/arm926ejs/mx27/generic.c b/cpu/arm926ejs/mx27/generic.c

Re: [U-Boot] Please pull u-boot-i2c.git next

Hello Wolfgang, Wolfgang Denk wrote: > Dear Heiko Schocher, > > In message <4aeaf4eb.3050...@denx.de> you wrote: >> Hello Wolfgang, >> >> The following changes since commit f2b4bc04d6aed6be712d236dab48ac4c4da22cbf: >> Wolfgang Denk (1): >> Merge branch 'master' of git://git.denx.de/u-bo

Re: [U-Boot] [u-boot] [PATCH][1/2] mx27: Add necessary defines and helper functions to support I2C in i.MX27.

Hello Javier, Javier Martin wrote: > Add proper register definitions, macros and clock functions required > for I2C driver to be developed. > > > > Signed-off-by: Javier Martin > -- > diff --git a/cpu/arm926ejs/mx27/generic.c b/cpu/arm926ejs/mx27/generic.c > index 808371f..540ef0c 100644 [...]