Re: [U-Boot] [PATCH] Move the SC520 specific pci.h header into an sc520 directory.
Gabe, I have already submitted a patch for this: http://patchwork.ozlabs.org/patch/120011/ Also, you patch does a delete then create rather than a file rename - When you use git-format-patch, use the --find-renames option Regards, Graeme On 29/10/11 09:34, Gabe Black wrote: > The arch/i386/include/asm/ic/pci.h header file include definitions which were > not generic to i386 and where specifically for SC520. This change moves that > header into a directory which more accurately reflects that. > > Signed-off-by: Gabe Black > --- > arch/x86/include/asm/ic/pci.h | 79 > --- > arch/x86/include/asm/ic/sc520/pci.h | 79 > +++ > 2 files changed, 79 insertions(+), 79 deletions(-) > delete mode 100644 arch/x86/include/asm/ic/pci.h > create mode 100644 arch/x86/include/asm/ic/sc520/pci.h > > diff --git a/arch/x86/include/asm/ic/pci.h b/arch/x86/include/asm/ic/pci.h > deleted file mode 100644 > index 12ba656..000 > --- a/arch/x86/include/asm/ic/pci.h > +++ /dev/null > @@ -1,79 +0,0 @@ > -/* > - * (C) Copyright 2002 > - * Daniel Engström, Omicron Ceti AB . > - * > - * See file CREDITS for list of people who contributed to this > - * project. > - * > - * This program is free software; you can redistribute it and/or > - * modify it under the terms of the GNU General Public License as > - * published by the Free Software Foundation; either version 2 of > - * the License, or (at your option) any later version. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > - * > - * You should have received a copy of the GNU General Public License > - * along with this program; if not, write to the Free Software > - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > - * MA 02111-1307 USA > - */ > - > -#ifndef _ASM_IC_SC520_PCI_H_ > -#define _ASM_IC_SC520_PCI_H_ 1 > - > -/* bus mapping constants (used for PCI core initialization) */ > > > > > /* bus mapping > constants */ > -#define SC520_REG_ADDR 0x0cf8 > -#define SC520_REG_DATA 0x0cfc > - > -#define SC520_ISA_MEM_PHYS 0x > -#define SC520_ISA_MEM_BUS0x > -#define SC520_ISA_MEM_SIZE 0x0100 > - > -#define SC520_ISA_IO_PHYS0x > -#define SC520_ISA_IO_BUS 0x > -#define SC520_ISA_IO_SIZE0x1000 > - > -/* PCI I/O space from 0x1000 to 0xdfff > - * (make 0xe000-0xfdff available for stuff like PCCard boot) */ > -#define SC520_PCI_IO_PHYS0x1000 > -#define SC520_PCI_IO_BUS 0x1000 > -#define SC520_PCI_IO_SIZE0xd000 > - > -/* system memory from 0x to 0x0fff */ > -#define SC520_PCI_MEMORY_PHYS 0x > -#define SC520_PCI_MEMORY_BUS0x > -#define SC520_PCI_MEMORY_SIZE0x1000 > - > -/* PCI bus memory from 0x1000 to 0x26ff > - * (make 0x2700 - 0x27ff available for stuff like PCCard boot) */ > -#define SC520_PCI_MEM_PHYS 0x1000 > -#define SC520_PCI_MEM_BUS0x1000 > -#define SC520_PCI_MEM_SIZE 0x1700 > - > -/* pin number used for PCI interrupt mappings */ > -#define SC520_PCI_INTA 0 > -#define SC520_PCI_INTB 1 > -#define SC520_PCI_INTC 2 > -#define SC520_PCI_INTD 3 > -#define SC520_PCI_GPIRQ0 4 > -#define SC520_PCI_GPIRQ1 5 > -#define SC520_PCI_GPIRQ2 6 > -#define SC520_PCI_GPIRQ3 7 > -#define SC520_PCI_GPIRQ4 8 > -#define SC520_PCI_GPIRQ5 9 > -#define SC520_PCI_GPIRQ6 10 > -#define SC520_PCI_GPIRQ7 11 > -#define SC520_PCI_GPIRQ8 12 > -#define SC520_PCI_GPIRQ9 13 > -#define SC520_PCI_GPIRQ10 14 > - > -extern int sc520_pci_ints[]; > - > -void pci_sc520_init(struct pci_controller *hose); > -int pci_set_regions(struct pci_controller *hose); > -int pci_sc520_set_irq(int pci_pin, int irq); > - > -#endif > diff --git a/arch/x86/include/asm/ic/sc520/pci.h > b/arch/x86/include/asm/ic/sc520/pci.h > new file mode 100644 > index 000..12ba656 > --- /dev/null > +++ b/arch/x86/include/asm/ic/sc520/pci.h > @@ -0,0 +1,79 @@ > +/* > + * (C) Copyright 2002 > + * Daniel Engström, Omicron Ceti AB . > + * > + * See file CREDITS for list of people who contributed to this > + * project. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option)
Re: [U-Boot] [RFC PATCH 3/3] sandbox: WIP: add basic command line parsing
Hi Mike, On Fri, Oct 28, 2011 at 6:05 PM, Mike Frysinger wrote: > On Sat, Oct 29, 2011 at 02:57, Simon Glass wrote: >> On Fri, Oct 28, 2011 at 5:50 PM, Mike Frysinger wrote: >>> On Sat, Oct 29, 2011 at 02:43, Simon Glass wrote: I am not going to get back to sandbox for a few weeks now - my next task is to get it booting from simulated SPI/MMC and see what tests can be written against that. It will become clearer then I think. >>> >>> this is a bit ambiguous ... you want to test booting from SPI flash >>> and from a card in a MMC slot ? or you want to test booting from a >>> card in a MMC slot connected via SPI ? >> >> I mean boot by loading some data, etc. from SPI-attached SPI flash and >> then loading a kernel from an SDMMC-attached MMC card and jumping to >> it. > > does the spi flash patch you posted satisfy your first part here ? > after all, the back end shouldn't matter so long as "sf" is able to > read data out of a file into memory. > otherwise, i'll try and update the spi flash patch i posted sooner > rather than later. Yes it does satisfy that - ATM I can boot through to where it wants to load from MMC. > > as for sd/mmc, i think you might be on your own there. i only have a > passing familiarity with the spec and would have to do quite a bit of > reading/learning first. which i'm not terribly interested in doing at > this time i'm sorry to say. the patents/licensing the sd peeps have > in place make that storage medium decidedly less interesting to me, > although i might suck it up (much further down the line) considering > it seems to (sadly) be the foreseeable future of storage in embedded. > -mike > Well that's OK. I had in mind a bit of a cheat (as I did with SPI) anyway - i.e. this would be pretty trivial. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/3] sandbox: WIP: add basic command line parsing
On Sat, Oct 29, 2011 at 02:57, Simon Glass wrote: > On Fri, Oct 28, 2011 at 5:50 PM, Mike Frysinger wrote: >> On Sat, Oct 29, 2011 at 02:43, Simon Glass wrote: >>> I am not going to get back to sandbox for a few weeks now - my next >>> task is to get it booting from simulated SPI/MMC and see what tests >>> can be written against that. It will become clearer then I think. >> >> this is a bit ambiguous ... you want to test booting from SPI flash >> and from a card in a MMC slot ? or you want to test booting from a >> card in a MMC slot connected via SPI ? > > I mean boot by loading some data, etc. from SPI-attached SPI flash and > then loading a kernel from an SDMMC-attached MMC card and jumping to > it. does the spi flash patch you posted satisfy your first part here ? after all, the back end shouldn't matter so long as "sf" is able to read data out of a file into memory. otherwise, i'll try and update the spi flash patch i posted sooner rather than later. as for sd/mmc, i think you might be on your own there. i only have a passing familiarity with the spec and would have to do quite a bit of reading/learning first. which i'm not terribly interested in doing at this time i'm sorry to say. the patents/licensing the sd peeps have in place make that storage medium decidedly less interesting to me, although i might suck it up (much further down the line) considering it seems to (sadly) be the foreseeable future of storage in embedded. -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [WIP] sandbox: spi/sf emulation
Hi Mike,
On Fri, Oct 28, 2011 at 5:56 PM, Mike Frysinger wrote:
> On Sat, Oct 29, 2011 at 02:47, Simon Glass wrote:
>> On Wed, Oct 26, 2011 at 1:37 PM, Mike Frysinger wrote:
>>> On Wed, Oct 26, 2011 at 12:26, Simon Glass wrote:
On Wed, Oct 26, 2011 at 3:30 AM, Mike Frysinger wrote:
> --- a/arch/sandbox/cpu/os.c
> +++ b/arch/sandbox/cpu/os.c
>
> +off_t os_lseek(int fd, off_t offset, int whence)
> +{
> + return lseek(fd, offset, whence);
> +}
How are we going to deal with calls to something like this where
'whence' is defined in an OS-specific header file? I believe we need
to add definitions to os.h to provide this feature, and make them
match Posix. Is there a better way? open has a similar problem.
>>>
>>> yeah, i noticed this, but was ignoring it for the time being. the
>>> only portable way i think is to have our local os.h provide arbitrary
>>> defines which the rest of u-boot will utilize, and then in the os_xxx
>>> func, we translate into the host defines. a bit ugly, but it's the
>>> only way to really work since there is no guarantee that something
>>> like O_RDONLY will always be defined to 0.
>>
>> I care less about portability to non-POSIX, others may though. Perhaps
>> just defining the types and #defines with a suitable prefix in the
>> header file, and then a compile-time assert in the C would be good
>> enough.
>
> funny story: POSIX doesn't mandate the values behind the defines, only
> that the defines exist and are suitable for CPP usage. notice i said
> "portable" and not "POSIX" ... that was not an accident :). the
> defines may differ across Linux architectures, as well as ABIs (e.g.
> x86 vs x86_64 vs x32), as well as C libraries, as well as operating
> systems. in practice, i vaguely recall the few defines we probably
> would use (ro/wo/rw/create) are the same across all Linux
> arches/ABIs/C libraries, but that's an icky situation to paint
> yourself into.
That's not very funny, but in any case it is manageable with a
sufficient amount of code bloat.
>
> a quick grep would probably clarify if the #if/#error assert logic
> would be sufficient to pass compile/run, but not necessarily pass the
> wd ;).
>
> --- a/arch/sandbox/cpu/start.c
> +++ b/arch/sandbox/cpu/start.c
>
> + if (os_getopt("-h", 0) || os_getopt("--help", 0)) {
> + serial_puts(usage);
> + return 0;
> + }
I did actually create something to parse args and put them into a
'state' structure. But it uses getopt_long(). Any reason we can't?
>>>
>>> on reason i didn't was so i wouldn't have to worry about translating
>>> defines/structs used in u-boot and defines/structs used by the host
>>> system. i.e. the same issue we face with bits for os_{open,lseek}.
>>
>> Well I don't think we should be passing any getopt structures outside
>> os.c or parse.c. That is the intent of my state.c - a place where the
>> test state / arguments is stored and can be accessed when needed
>> without reference to os-dependent code / structures.
>
> hrm, i'm not seeing what you mean, but i'll take a closer look at the code.
> -mike
>
There isn't much to look at yet, sorry.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/3] sandbox: WIP: add basic command line parsing
Hi Mike, On Fri, Oct 28, 2011 at 5:50 PM, Mike Frysinger wrote: > On Sat, Oct 29, 2011 at 02:43, Simon Glass wrote: >> On Wed, Oct 26, 2011 at 11:16 PM, Mike Frysinger wrote: >>> On Wed, Oct 26, 2011 at 18:54, Simon Glass wrote: This adds simple command-line parssing to sandbox. The idea is that it sets up the state with options provided, and this state can then be queried as needed later. >>> >>> i'm not seeing the usefulness of the "state" code >> >> Not yet - for now it just holds the command line flags and anything >> parsed from the command line. Ultimately it will hold test state, but >> it is early days on that yet. > > i think we should split command line parsing from state. the former > is clearly desirable $now. > + "\t-c \tExecute U-Boot command\n" >>> >>> i don't think this is necessary. i simply do: >>> ./u-boot <<<$'bdinfo\nreset\n' >> >> Well it's not possible ATM anyway since board_init_f() never returns. > > right. i was speaking in general. > >> Does your method use an expect script to check that the right result >> is obtained? > > yes & no. i wrote up a tiny test quite that does `./u-boot ... >& > test.out`, and then compares test.out to a test.in file to make sure > things worked. it could be made to use expect instead. > > however, Marek (or maybe Jean) pointed out DUTS to me, so i stopped > working on that and switched to trying to learn that framework so we > could use what already existed rather than writing something from > scratch which i imagine Wolfgang (rightly so) would barf all over. Yes, looking forward to finding out more about that. Whatever we do for test harness needs to avoid the re-invention of wheels. > >> I am not going to get back to sandbox for a few weeks now - my next >> task is to get it booting from simulated SPI/MMC and see what tests >> can be written against that. It will become clearer then I think. > > this is a bit ambiguous ... you want to test booting from SPI flash > and from a card in a MMC slot ? or you want to test booting from a > card in a MMC slot connected via SPI ? > -mike > I mean boot by loading some data, etc. from SPI-attached SPI flash and then loading a kernel from an SDMMC-attached MMC card and jumping to it. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [WIP] sandbox: spi/sf emulation
On Sat, Oct 29, 2011 at 02:47, Simon Glass wrote:
> On Wed, Oct 26, 2011 at 1:37 PM, Mike Frysinger wrote:
>> On Wed, Oct 26, 2011 at 12:26, Simon Glass wrote:
>>> On Wed, Oct 26, 2011 at 3:30 AM, Mike Frysinger wrote:
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
+off_t os_lseek(int fd, off_t offset, int whence)
+{
+ return lseek(fd, offset, whence);
+}
>>>
>>> How are we going to deal with calls to something like this where
>>> 'whence' is defined in an OS-specific header file? I believe we need
>>> to add definitions to os.h to provide this feature, and make them
>>> match Posix. Is there a better way? open has a similar problem.
>>
>> yeah, i noticed this, but was ignoring it for the time being. the
>> only portable way i think is to have our local os.h provide arbitrary
>> defines which the rest of u-boot will utilize, and then in the os_xxx
>> func, we translate into the host defines. a bit ugly, but it's the
>> only way to really work since there is no guarantee that something
>> like O_RDONLY will always be defined to 0.
>
> I care less about portability to non-POSIX, others may though. Perhaps
> just defining the types and #defines with a suitable prefix in the
> header file, and then a compile-time assert in the C would be good
> enough.
funny story: POSIX doesn't mandate the values behind the defines, only
that the defines exist and are suitable for CPP usage. notice i said
"portable" and not "POSIX" ... that was not an accident :). the
defines may differ across Linux architectures, as well as ABIs (e.g.
x86 vs x86_64 vs x32), as well as C libraries, as well as operating
systems. in practice, i vaguely recall the few defines we probably
would use (ro/wo/rw/create) are the same across all Linux
arches/ABIs/C libraries, but that's an icky situation to paint
yourself into.
a quick grep would probably clarify if the #if/#error assert logic
would be sufficient to pass compile/run, but not necessarily pass the
wd ;).
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
+ if (os_getopt("-h", 0) || os_getopt("--help", 0)) {
+ serial_puts(usage);
+ return 0;
+ }
>>>
>>> I did actually create something to parse args and put them into a
>>> 'state' structure. But it uses getopt_long(). Any reason we can't?
>>
>> on reason i didn't was so i wouldn't have to worry about translating
>> defines/structs used in u-boot and defines/structs used by the host
>> system. i.e. the same issue we face with bits for os_{open,lseek}.
>
> Well I don't think we should be passing any getopt structures outside
> os.c or parse.c. That is the intent of my state.c - a place where the
> test state / arguments is stored and can be accessed when needed
> without reference to os-dependent code / structures.
hrm, i'm not seeing what you mean, but i'll take a closer look at the code.
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] sandbox: gpio: WIP add basic driver for simulating GPIOs
Hi Mike, On Fri, Oct 28, 2011 at 5:42 PM, Mike Frysinger wrote: > ignoring the upgrade issues, i think this is useful. only thing > "missing" is having the pin update state externally, but maybe i'm > crazy in thinking we need that. it certainly could be done in a > follow up patch once your v2 of this patch gets updated, and once we > actually have a proposed interface that someone was able to make work > (vs us dreaming up something crazy like sockets/files/pipes/etc...). > -mike > Yes. It depends on your definition of 'externally'. I am mostly interested in self-contained tests, where we compile U-Boot against its test code and run it very fast. However there is enormous scope for going beyond that as has been discussed before - things like making U-Boot talk on the host's Ethernet/ serial / USB ports, etc. The tricky thing to get right here is the placement of the state. I think we want to avoid test state in drivers where possible - on the other hand we need drivers to be able to pretend to be broken, etc. If we provide some sort of generic input/output config/log files for test state, then I suppose converting to sockets/pipes is not a big step. This is wrapped up in what the test harness looks like also. Are we getting ahead of ourselves yet? ;-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/3] sandbox: WIP: add basic command line parsing
On Sat, Oct 29, 2011 at 02:43, Simon Glass wrote: > On Wed, Oct 26, 2011 at 11:16 PM, Mike Frysinger wrote: >> On Wed, Oct 26, 2011 at 18:54, Simon Glass wrote: >>> This adds simple command-line parssing to sandbox. The idea is that it >>> sets up the state with options provided, and this state can then be >>> queried as needed later. >> >> i'm not seeing the usefulness of the "state" code > > Not yet - for now it just holds the command line flags and anything > parsed from the command line. Ultimately it will hold test state, but > it is early days on that yet. i think we should split command line parsing from state. the former is clearly desirable $now. >>> + "\t-c \tExecute U-Boot command\n" >> >> i don't think this is necessary. i simply do: >> ./u-boot <<<$'bdinfo\nreset\n' > > Well it's not possible ATM anyway since board_init_f() never returns. right. i was speaking in general. > Does your method use an expect script to check that the right result > is obtained? yes & no. i wrote up a tiny test quite that does `./u-boot ... >& test.out`, and then compares test.out to a test.in file to make sure things worked. it could be made to use expect instead. however, Marek (or maybe Jean) pointed out DUTS to me, so i stopped working on that and switched to trying to learn that framework so we could use what already existed rather than writing something from scratch which i imagine Wolfgang (rightly so) would barf all over. > I am not going to get back to sandbox for a few weeks now - my next > task is to get it booting from simulated SPI/MMC and see what tests > can be written against that. It will become clearer then I think. this is a bit ambiguous ... you want to test booting from SPI flash and from a card in a MMC slot ? or you want to test booting from a card in a MMC slot connected via SPI ? -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [WIP] sandbox: spi/sf emulation
Hi Mike,
On Wed, Oct 26, 2011 at 1:37 PM, Mike Frysinger wrote:
> On Wed, Oct 26, 2011 at 12:26, Simon Glass wrote:
>> On Wed, Oct 26, 2011 at 3:30 AM, Mike Frysinger wrote:
>>> --- a/arch/sandbox/cpu/os.c
>>> +++ b/arch/sandbox/cpu/os.c
>>>
>>> +off_t os_lseek(int fd, off_t offset, int whence)
>>> +{
>>> + return lseek(fd, offset, whence);
>>> +}
>>
>> How are we going to deal with calls to something like this where
>> 'whence' is defined in an OS-specific header file? I believe we need
>> to add definitions to os.h to provide this feature, and make them
>> match Posix. Is there a better way? open has a similar problem.
>
> yeah, i noticed this, but was ignoring it for the time being. the
> only portable way i think is to have our local os.h provide arbitrary
> defines which the rest of u-boot will utilize, and then in the os_xxx
> func, we translate into the host defines. a bit ugly, but it's the
> only way to really work since there is no guarantee that something
> like O_RDONLY will always be defined to 0.
I care less about portability to non-POSIX, others may though. Perhaps
just defining the types and #defines with a suitable prefix in the
header file, and then a compile-time assert in the C would be good
enough.
>
>>> +const char *os_getenv(const char *name)
>>> +{
>>> + /* We can't use getenv() as u-boot provides it own */
>>
>> Ick, but I can't see an easy alternative.
>
> i ended up not needing this interface so far, so i think i'll drop it
> now that it's been archived on the mailing list.
OK
>
>>> --- a/arch/sandbox/cpu/start.c
>>> +++ b/arch/sandbox/cpu/start.c
>>>
>>> + if (os_getopt("-h", 0) || os_getopt("--help", 0)) {
>>> + serial_puts(usage);
>>> + return 0;
>>> + }
>>
>> I did actually create something to parse args and put them into a
>> 'state' structure. But it uses getopt_long(). Any reason we can't?
>
> on reason i didn't was so i wouldn't have to worry about translating
> defines/structs used in u-boot and defines/structs used by the host
> system. i.e. the same issue we face with bits for os_{open,lseek}.
Well I don't think we should be passing any getopt structures outside
os.c or parse.c. That is the intent of my state.c - a place where the
test state / arguments is stored and can be accessed when needed
without reference to os-dependent code / structures.
>
>>> --- a/include/os.h
>>> +++ b/include/os.h
>>>
>>> +const char *os_getenv(const char *name);
>>
>> I would really like to have full comments on all header functions
>> (with @param and @return).
>
> right, that's why this is a brain dump :). i didn't want to document
> funcs i would ultimately throw away.
Fair enough, just being picky as I like comments :-)
>
> also, this os.h header needs #ifdef protection against multiple inclusion ...
> -mike
>
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/3] sandbox: WIP: add basic command line parsing
Hi Mike, On Wed, Oct 26, 2011 at 11:16 PM, Mike Frysinger wrote: > On Wed, Oct 26, 2011 at 18:54, Simon Glass wrote: >> This adds simple command-line parssing to sandbox. The idea is that it >> sets up the state with options provided, and this state can then be >> queried as needed later. > > i'm not seeing the usefulness of the "state" code Not yet - for now it just holds the command line flags and anything parsed from the command line. Ultimately it will hold test state, but it is early days on that yet. > >> + "\t-c \tExecute U-Boot command\n" > > i don't think this is necessary. i simply do: > ./u-boot <<<$'bdinfo\nreset\n' > -mike > Well it's not possible ATM anyway since board_init_f() never returns. Does your method use an expect script to check that the right result is obtained? I am not going to get back to sandbox for a few weeks now - my next task is to get it booting from simulated SPI/MMC and see what tests can be written against that. It will become clearer then I think. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] sandbox: gpio: WIP add basic driver for simulating GPIOs
ignoring the upgrade issues, i think this is useful. only thing "missing" is having the pin update state externally, but maybe i'm crazy in thinking we need that. it certainly could be done in a follow up patch once your v2 of this patch gets updated, and once we actually have a proposed interface that someone was able to make work (vs us dreaming up something crazy like sockets/files/pipes/etc...). -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/3] sandbox: gpio: WIP add basic driver for simulating GPIOs
Hi Mike, On Wed, Oct 26, 2011 at 11:14 PM, Mike Frysinger wrote: > On Wed, Oct 26, 2011 at 18:54, Simon Glass wrote: >> --- /dev/null >> +++ b/drivers/gpio/sandbox.c >> >> +#include >> +#include > > not used > >> +#include > > should be asm/gpio.h > >> +/* These functions make up what could be a public interface within U-Boot */ > > these are the public interface in u-boot. i wonder why you need the > sandbox_* names at all rather than just the public asm/gpio.h > interfaces. > >> +U_BOOT_CMD( >> + gpio, 5, 1, do_gpio, > > if you implemented the asm/gpio.h interface only, you should be able > to re-use the existing cmd_gpio.c file rather than implementing your > own from scratch. > -mike > Yes I'm afraid this patch is against a slightly older tree. I rebased it but did not update it, but I will do so before sending it up for real. Thanks for the comments. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] arm: Move CP15 init out of cpu_init_crit()
Hi Albert, On Thu, Oct 27, 2011 at 10:09 PM, Albert ARIBAUD wrote: > Le 28/10/2011 03:43, Simon Glass a écrit : > >> The test was >> >> mrc p15, 0, r0, c0, c0, 0 @ get ID register >> and r0, r0, #0xf @ get architecture >> cmp r0, #0xf @ check for> ARMv6 >> movne pc, lr @ else skip cache init >> >> Unfortunately I think it is a plain ARM7TDMI with no CP15. > > What about other fields in r0 right after mrc? I don't really understand that sentence, sorry. The ARM7TDMI does not have a CP15 and aborts if I try to access it. Just in case there is something odd going on I checked with DSTREAM / RVdebug and it definitely doesn't have a CP15. [as Ford Prefect would say, I counted them twice] The simplest thing I have been able to think of that does not involve exceptions, differing instruction behaviour, doing the init later or putting in some Tegra-specific code is to check for the existence of the Q bit in the CPSR (actually APSR on ARMv7). This does seem to work and I have verified both in my old 1996 ARM ARM DDI 0100B and the ARMv7-A one (DDI 0406B) that from an architecture point of view this should work. The Q bit is RAZ on ARMv4T. I believe this will cope with the Cortex-A7 / A-15 combinations and possibly even Cortex-R4 / A-15 although I have not tested this. I suppose we can deal with this when it becomes an issue. So I have redone this one patch with that in mind, and adjusted the series slightly to fit with this. I will resend it when it completes MAKEALL. I hope that this resolves the matter, but if not(!), I would very much appreciate it if you could send through some actual pseudo code showing what you are looking for, to avoid any confusion. Thanks, Simon > >> Regards, >> Simon > > Amicalement, > -- > Albert. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib/string: memmove: use memcpy if it is safe to do so
On Fri, Oct 28, 2011 at 22:25, Wolfgang Denk wrote: > Peter Korsgaard wrote: >> memmove is used in a number of performance critical places, like copying the >> linux kernel from nor flash to ram, so optimizing it can be interesting. >> >> Unfortunately, an arch specific version of memmove often isn't used, and >> not supported at all on a number of archs (arm/mips/nds32/nios2/x86) - >> But memcpy typically is. > > So you are adding code, making the system even less efficient? This > sounds to be acounter-productive approach. > > Can you not instead arrange for arch specific, optimized versions > memmove() to be used? i think this is kind of a loose-loose situation. in common code, we have to use memmove() if the two regions could *possibly* overlap. so in practice, we end up calling memmove() in more cases than strictly necessary. but the only real choice is to update all the call sites with region overlap checks. at least with Peter's patch, we centralize all these checks in one place producing smaller code. in some cases, we probably add a little bit of runtime overhead when the new if() statement returns false, but it seems to be that one successful call quickly outweighs multiple unsuccessful if() checks. i also think this falls into the same category as the previous commit b038db852b5b7120f1ff825d8e2a5c2cd14c2f0f: memcpy/memmove: Do not copy to same address so the ideal probably would be to have an optimized memmove in place, but for the (many) arches which don't have this, we seem to get a "win" overall ? -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pullrequest: u-boot-arm/master
Hi Albert, On Thu, Oct 27, 2011 at 10:13 PM, Albert ARIBAUD wrote: > Hi Simon, > > Le 28/10/2011 03:53, Simon Glass a écrit : >> >> Hi Albert, > >> You have Tom's MMC patch here but not the series from Stephen. Please >> can you see my email below about this: >> >> On Thu, Oct 20, 2011 at 3:57 PM, Simon Glass wrote: >>> >>> Hi Albert, Wolfgang, >>> >>> I believe this is the current status on Tegra2 in u-boot-arm.git: >>> >>> - Stephen Warren has a patch series ending here: >>> http://patchwork.ozlabs.org/patch/119325/ >>> - Stephen Warren has a single GPIO patch here: >>> http://patchwork.ozlabs.org/patch/118184/ >>> - I have a boot refactor patch series ending here: >>> http://patchwork.ozlabs.org/patch/119941/ >>> >>> I think all of these have passed review, so I hope they can be >>> applied. They need to be applied in above order though. If there are >>> any problems I am on-hand to rebase, etc. >> >> The boot patch is actually still in review but I believe Stephen's >> patches are ready. > > Thanks Simon. I know I haven't gotten everything in, and I am working > through the backlog. Thank you - yes I can see there is an awful lot to get through. > > I'll get these in as soon as I can. OK thanks. Wolfgang has picked up the FDT series, so we don't need to worry about that here. I am going to see if I can tidy up the SPI series so we can at least get the driver in. Regards, Simon > Amicalement, > -- > Albert. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: part_efi: fix regression due to incorrect buffer usage
On Fri, Oct 28, 2011 at 3:47 PM, Anton Staaf wrote:
> Thanks Stephen, sorry Doug. :)
>
> -Anton
>
> On Fri, Oct 28, 2011 at 12:43 PM, Doug Anderson wrote:
>> Acked-by: Doug Anderson
Tested-by: Simon Glass
>>
>> ...to be fair though, the regression appears to be caused by a mid-air
>> collision of Anton's change (f75dd584cdfe29dfdcfd424bb237b9238cfb8fe4) with
>> my change. His patch was committed on Oct 25th (though authored earlier).
>> When I submitted my patch on the Oct 19th against denx/master, I'm pretty
>> sure it was correct.
>>
>> Thank you for finding / fixing! :)
>>
>> -Doug
>>
>> ---
>>
>> On Fri, Oct 28, 2011 at 12:21 PM, Stephen Warren wrote:
>>
>>> Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix
>>> **pgpt_pte == NULL" modified the code to pass "&gpt_head" to
>>> is_gpt_valid() rather than the previous "gpt_head". However, gpt_head
>>> is a pointer to the buffer, not the actual buffer, since it was allocated
>>> using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the
>>> disk block onto the stack rather than into the buffer, causing the
>>> code to fail.
>>>
>>> This change reverts that portion of the commit mentioned above.
>>>
>>> Signed-off-by: Stephen Warren
>>> ---
>>> disk/part_efi.c | 4 ++--
>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/disk/part_efi.c b/disk/part_efi.c
>>> index e7f2714..ddf80a7 100644
>>> --- a/disk/part_efi.c
>>> +++ b/disk/part_efi.c
>>> @@ -130,7 +130,7 @@ void print_part_efi(block_dev_desc_t * dev_desc)
>>> }
>>> /* This function validates AND fills in the GPT header and PTE */
>>> if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
>>> - &(gpt_head), &gpt_pte) != 1) {
>>> + gpt_head, &gpt_pte) != 1) {
>>> printf("%s: *** ERROR: Invalid GPT ***\n", __func__);
>>> return;
>>> }
>>> @@ -169,7 +169,7 @@ int get_partition_info_efi(block_dev_desc_t * dev_desc,
>>> int part,
>>>
>>> /* This function validates AND fills in the GPT header and PTE */
>>> if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
>>> - &(gpt_head), &gpt_pte) != 1) {
>>> + gpt_head, &gpt_pte) != 1) {
>>> printf("%s: *** ERROR: Invalid GPT ***\n", __func__);
>>> return -1;
>>> }
>>> --
>>> 1.7.0.4
>>>
>>>
>>
>> ___
>> 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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 1/5] tegra2: Use cmd_link_o_target in board Makefiles
Hi, On Thu, Oct 27, 2011 at 11:25 PM, Mike Frysinger wrote: > On Fri, Oct 28, 2011 at 07:35, Albert ARIBAUD wrote: >> Going up my backlog... for 2/4 and 4/5, as their are touching MMC driver >> code, I'd like Andy to ack them as the the MMC custodian, then I can apply >> the whole set (pending the MAINTAINER addition). > > i don't think this particular patch needs that much acknowledgement. > but at any rate, this patch is obsolete now as a newer one has already > been merged by Wolfgang. > -mike > Yes this single patch can be dropped now, meaning that Stephen's series is now: tegra2: Move MMC clock initialization into MMC driver tegra2: Move board_mmc_init into board files tegra2: Modify MMC driver to handle power and cd GPIOs tegra2: Add support for Ventana Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [BREAKAGE] gplugd board / armada100_fec
Dear Ajay Bhargav, I compiled the "gplugd" board and I got the following warnings, please fix. Configuring for gplugd board... armada100_fec.c: In function 'armdfec_init': armada100_fec.c:483:2: warning: dereferencing type-punned pointer will break strict-aliasing rules armada100_fec.c:484:2: warning: dereferencing type-punned pointer will break strict-aliasing rules armada100_fec.c: In function 'armdfec_recv': armada100_fec.c:670:2: warning: dereferencing type-punned pointer will break strict-aliasing rules gplugd.c: In function 'board_init': gplugd.c:95:27: error: 'MACH_TYPE_SHEEVAD' undeclared (first use in this function) gplugd.c:95:27: note: each undeclared identifier is reported only once for each function it appears in Cheers ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] e1000: fix bugs from recent commits
On Fri, Oct 28, 2011 at 22:19, Wolfgang Denk wrote:
> Mike Frysinger wrote:
>> On Fri, Oct 28, 2011 at 07:49, Wolfgang Denk wrote:
>> > --- a/drivers/net/e1000.h
>> > +++ b/drivers/net/e1000.h
>> >
>> > #define E1000_WRITE_FLUSH(a) \
>> > - do { uint32_t x = E1000_READ_REG(a, STATUS); } while (0)
>> > + E1000_READ_REG(a, STATUS)
>>
>> i think we want the do{}while as this is a write command and we don't
>> want people accidentally trying to check the return value
>
> I don't see that this is a write command. I'm seeing only reading of
> the status register here.
yes, the actual implementation is a read. however, the API implied by
the naming (xxx_WRITE_xxx) is a write command. sometimes that means a
read of the status register (if they're R1C bits), or a write (if
they're W1C bits), but the forward facing API is still a write.
> And I don't understand the "accidentally trying to check the return
> value" argument either. Why would one do that - and if one does
> (probably after checking the implementation), what would be wrong
> about it?
imo, using do{}while is simply "good programming". it falls under the
same argument of why we respect type warnings with gcc. this is
supposed to be a write operation with void return, so we should make
sure the implementation enforces that to keep the user from
accidentally trying to do things otherwise.
-mike
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib/string: memmove: use memcpy if it is safe to do so
> "Wolfgang" == Wolfgang Denk writes: Hi, >> memmove is used in a number of performance critical places, like copying the >> linux kernel from nor flash to ram, so optimizing it can be interesting. >> >> Unfortunately, an arch specific version of memmove often isn't used, and >> not supported at all on a number of archs (arm/mips/nds32/nios2/x86) - >> But memcpy typically is. Wolfgang> So you are adding code, making the system even less efficient? This Wolfgang> sounds to be acounter-productive approach. Well, slightly less efficient for the (uncommon) situation where src/dest overlaps in return for significantly more efficiency for the situation where they don't. Wolfgang> Can you not instead arrange for arch specific, optimized versions Wolfgang> memmove() to be used? That's another option, but more work for implementers - So I would prefer this trivial patch instead. But I'll drop it if you disagree. -- Bye, Peter Korsgaard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] The type expected by %zd is ssize_t, but it was being passed a size_t.
generally the subject/changelog should be more of the form: cmd_nvedit: fix printf warning gcc warns when using %zd with size_t types since the correct format is %zu: otherwise, the change (in theory) makes perfect sense to me ... i would ack if not for the commit summary/log ;) -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot maintainers: some boards are broken by recent mach-type update
Hi Albert, > Hello all, > > Recently the ARM mach-types.h file has been brought in sync with its > Linux original, leasing to a number of boards not being listed any more, > as the new list only contains boards which have actual Linux support or > were declared less than one year ago. > > The symptom is a build failure with a message of the form "error: > 'MACH_TYPE_XX' undeclared (first use in this function)". > > U-Boot maintainers of such boards (in Cc: of this mail) should provide a > patch to re-introduce the MACH_TYPE_XX definition in their boards' > config header file in include/configs/. > > Note that three boards do not have a maintainer and will be removed if > nobody steps forward to take over their maintainership. They have been > listed below as ORPHAN, and since they are all PXA boards, I have CC:ed > Marek just in case. > > Here is the list of broken boards (BTW: how about putting maintainer > identity in boards.cfg, or at least turning MAINTAINERS into a format > more easily parseable?) > > - > > Ajay Bhargav > > gplugd ARM926EJS (ARMADA100 88AP168 SoC) Ajay, you have warnings in your damn ethernet code !!! Have you ever tested it ?! > > Luca Ceresoli > > dig297 ARM ARMV7 (OMAP3530 SoC) > > Po-Yu Chuang > > a320evb FA526 (ARM920T-like) (a320 SoC) > > Daniel Gorsulowski > > meesc ARM926EJS (AT91SAM9263 SoC) > otc570 ARM926EJS (AT91SAM9263 SoC) > > Ilko Iliev > > PM9261 AT91SAM9261 > PM9263 AT91SAM9263 > PM9G45 ARM926EJS (AT91SAM9G45 SoC) > > Prakash Kumar > > cerf250 xscale/pxa Drop unless I get fixes from maintainer in a week or request for longer time to fix. > > Valentin Longchamp > > km_kirkwood ARM926EJS (Kirkwood SoC) > portl2 ARM926EJS (Kirkwood SoC) > > David Müller > > VCMA9 ARM920T > > Jens Scharsig > > eb_cpux9k2 ARM920T (AT91RM9200 SoC) > > Heiko Schocher > > mgcoge3un ARM926EJS (Kirkwood SoC) > > Robert Schwebel > > csb226 xscale/pxa > innokom xscale/pxa Drop unless I get fixes from maintainer in a week or request for longer time to fix. (here I have some feeling it's not gonna be fixed) > > Albin Tonnerre > > sbc35_a9g20 ARM926EJS (AT91SAM9G20 SoC) > tny_a9260 ARM926EJS (AT91SAM9260 SoC) > tny_a9g20 ARM926EJS (AT91SAM9G20 SoC) > > Matthias Weisser > > jadecpu ARM926EJS (MB86R01 SoC) > > ORPHAN: > > cradle xscale/pxa > pleb2 xscale/pxa > xm250 xscale/pxa Drop, sorry. Cheers ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot maintainers: some boards are broken by recent mach-type update
Hi Marek, On Fri, Oct 28, 2011 at 11:10:08PM +0200, Marek Vasut wrote: > > Robert Schwebel > > > > csb226 xscale/pxa > > innokom xscale/pxa > > Drop unless I get fixes from maintainer in a week or request for > longer time to fix. (here I have some feeling it's not gonna be fixed) They won't. Both boards are not in my hands any more and long obsolete. So from my side, dropping them is just fine. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: part_efi: fix regression due to incorrect buffer usage
Thanks Stephen, sorry Doug. :)
-Anton
On Fri, Oct 28, 2011 at 12:43 PM, Doug Anderson wrote:
> Acked-by: Doug Anderson
>
> ...to be fair though, the regression appears to be caused by a mid-air
> collision of Anton's change (f75dd584cdfe29dfdcfd424bb237b9238cfb8fe4) with
> my change. His patch was committed on Oct 25th (though authored earlier).
> When I submitted my patch on the Oct 19th against denx/master, I'm pretty
> sure it was correct.
>
> Thank you for finding / fixing! :)
>
> -Doug
>
> ---
>
> On Fri, Oct 28, 2011 at 12:21 PM, Stephen Warren wrote:
>
>> Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix
>> **pgpt_pte == NULL" modified the code to pass "&gpt_head" to
>> is_gpt_valid() rather than the previous "gpt_head". However, gpt_head
>> is a pointer to the buffer, not the actual buffer, since it was allocated
>> using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the
>> disk block onto the stack rather than into the buffer, causing the
>> code to fail.
>>
>> This change reverts that portion of the commit mentioned above.
>>
>> Signed-off-by: Stephen Warren
>> ---
>> disk/part_efi.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/disk/part_efi.c b/disk/part_efi.c
>> index e7f2714..ddf80a7 100644
>> --- a/disk/part_efi.c
>> +++ b/disk/part_efi.c
>> @@ -130,7 +130,7 @@ void print_part_efi(block_dev_desc_t * dev_desc)
>> }
>> /* This function validates AND fills in the GPT header and PTE */
>> if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
>> - &(gpt_head), &gpt_pte) != 1) {
>> + gpt_head, &gpt_pte) != 1) {
>> printf("%s: *** ERROR: Invalid GPT ***\n", __func__);
>> return;
>> }
>> @@ -169,7 +169,7 @@ int get_partition_info_efi(block_dev_desc_t * dev_desc,
>> int part,
>>
>> /* This function validates AND fills in the GPT header and PTE */
>> if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
>> - &(gpt_head), &gpt_pte) != 1) {
>> + gpt_head, &gpt_pte) != 1) {
>> printf("%s: *** ERROR: Invalid GPT ***\n", __func__);
>> return -1;
>> }
>> --
>> 1.7.0.4
>>
>>
>
> ___
> 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] [PATCH] [x86] Remove the prototype for the unused function board_init
From: Gabe Black Signed-off-by: Gabe Black --- arch/x86/include/asm/u-boot-x86.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/x86/include/asm/u-boot-x86.h b/arch/x86/include/asm/u-boot-x86.h index accc8fa..d3e2f4c 100644 --- a/arch/x86/include/asm/u-boot-x86.h +++ b/arch/x86/include/asm/u-boot-x86.h @@ -42,7 +42,6 @@ int dram_init_f(void); int cpu_init_interrupts(void); /* board/.../... */ -int board_init(void); int dram_init(void); void setup_pcat_compatibility(void); -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Move the SC520 specific pci.h header into an sc520 directory.
The arch/i386/include/asm/ic/pci.h header file include definitions which were not generic to i386 and where specifically for SC520. This change moves that header into a directory which more accurately reflects that. Signed-off-by: Gabe Black --- arch/x86/include/asm/ic/pci.h | 79 --- arch/x86/include/asm/ic/sc520/pci.h | 79 +++ 2 files changed, 79 insertions(+), 79 deletions(-) delete mode 100644 arch/x86/include/asm/ic/pci.h create mode 100644 arch/x86/include/asm/ic/sc520/pci.h diff --git a/arch/x86/include/asm/ic/pci.h b/arch/x86/include/asm/ic/pci.h deleted file mode 100644 index 12ba656..000 --- a/arch/x86/include/asm/ic/pci.h +++ /dev/null @@ -1,79 +0,0 @@ -/* - * (C) Copyright 2002 - * Daniel Engström, Omicron Ceti AB . - * - * See file CREDITS for list of people who contributed to this - * project. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation; either version 2 of - * the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, - * MA 02111-1307 USA - */ - -#ifndef _ASM_IC_SC520_PCI_H_ -#define _ASM_IC_SC520_PCI_H_ 1 - -/* bus mapping constants (used for PCI core initialization) */ /* bus mapping constants */ -#define SC520_REG_ADDR 0x0cf8 -#define SC520_REG_DATA 0x0cfc - -#define SC520_ISA_MEM_PHYS 0x -#define SC520_ISA_MEM_BUS 0x -#define SC520_ISA_MEM_SIZE 0x0100 - -#define SC520_ISA_IO_PHYS 0x -#define SC520_ISA_IO_BUS 0x -#define SC520_ISA_IO_SIZE 0x1000 - -/* PCI I/O space from 0x1000 to 0xdfff - * (make 0xe000-0xfdff available for stuff like PCCard boot) */ -#define SC520_PCI_IO_PHYS 0x1000 -#define SC520_PCI_IO_BUS 0x1000 -#define SC520_PCI_IO_SIZE 0xd000 - -/* system memory from 0x to 0x0fff */ -#defineSC520_PCI_MEMORY_PHYS 0x -#defineSC520_PCI_MEMORY_BUS0x -#define SC520_PCI_MEMORY_SIZE 0x1000 - -/* PCI bus memory from 0x1000 to 0x26ff - * (make 0x2700 - 0x27ff available for stuff like PCCard boot) */ -#define SC520_PCI_MEM_PHYS 0x1000 -#define SC520_PCI_MEM_BUS 0x1000 -#define SC520_PCI_MEM_SIZE 0x1700 - -/* pin number used for PCI interrupt mappings */ -#define SC520_PCI_INTA 0 -#define SC520_PCI_INTB 1 -#define SC520_PCI_INTC 2 -#define SC520_PCI_INTD 3 -#define SC520_PCI_GPIRQ0 4 -#define SC520_PCI_GPIRQ1 5 -#define SC520_PCI_GPIRQ2 6 -#define SC520_PCI_GPIRQ3 7 -#define SC520_PCI_GPIRQ4 8 -#define SC520_PCI_GPIRQ5 9 -#define SC520_PCI_GPIRQ6 10 -#define SC520_PCI_GPIRQ7 11 -#define SC520_PCI_GPIRQ8 12 -#define SC520_PCI_GPIRQ9 13 -#define SC520_PCI_GPIRQ10 14 - -extern int sc520_pci_ints[]; - -void pci_sc520_init(struct pci_controller *hose); -int pci_set_regions(struct pci_controller *hose); -int pci_sc520_set_irq(int pci_pin, int irq); - -#endif diff --git a/arch/x86/include/asm/ic/sc520/pci.h b/arch/x86/include/asm/ic/sc520/pci.h new file mode 100644 index 000..12ba656 --- /dev/null +++ b/arch/x86/include/asm/ic/sc520/pci.h @@ -0,0 +1,79 @@ +/* + * (C) Copyright 2002 + * Daniel Engström, Omicron Ceti AB . + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#ifndef _ASM_IC_SC520_PCI_H
Re: [U-Boot] [PATCH v2 5/8] nand: Merge new implementation of 1-bit ECC from Linux nand driver
On 10/12/2011 02:32 AM, Christian Hitz wrote: > [backport from linux commit 02f8c6aee8df3cdc935e9bdd4f2d020306035dbe] > > This patch synchronizes the nand driver with the Linux 3.0 state. > > Signed-off-by: Christian Hitz > Cc: Scott Wood > --- > > Adds 1416 bytes to the image size. What does this version of the code do that warrants the code size increase? This could break some SPLs. If it's just a speed issue, we probably want to stick with the current code. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] The type expected by %zd is ssize_t, but it was being passed a size_t.
Signed-off-by: Gabe Black
---
common/cmd_nvedit.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 396a171..d9dc3f2 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -862,7 +862,7 @@ static int do_env_import(cmd_tbl_t *cmdtp, int flag, int
argc, char * const argv
" - truncated\n", MAX_ENV_SIZE);
}
++size;
- printf("## Info: input data size = %zd = 0x%zX\n", size, size);
+ printf("## Info: input data size = %zu = 0x%zX\n", size, size);
}
if (chk) {
--
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] e1000: fix bugs from recent commits
> Commit 114d7fc0 "e1000: Rewrite EEPROM checksum error to give more > information" failed to initialize the checksum variable which should > result in random results. Fix that. > [I wonder if that code has _ever_ been tested!!] > > Commit 2326a94d caused a ton of "unused variable 'x'" warnings. > Fix these. While we are at it, remove some bogus parens. > > Signed-off-by: Wolfgang Denk > Cc: Kyle Moffett > --- > > Kyle, > > I wonder if you have ever actually build and run this code??? > With the "checksum" variable being random (due to not being > initialized) you should have seen serious checksum problems. > How did this escape your testing? > > And all these build warnings - have you ever actully compiled that > code? What's going on here??? - wd > > Marek: Could you please be so kind and have a look at the debug code? > I think this needs a major cleanup, too. Thanks in advance. - wd I might take a sneak peek ... -mv ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] nand: Add common functions to linux/mtd/nand.h
On 10/16/2011 05:50 AM, Simon Schwarz wrote: > Functions often used in SPL are now part of linux/mtd/nand.h. > > Signed-off-by: Simon Schwarz > Cc: scottw...@freescale.com > Cc: s-paul...@ti.com > Cc: albert.u.b...@aribaud.net > --- > Changes V2: > CHG moved function definiton from nand.h to linux/mtd/nand.h because of: > http://article.gmane.org/gmane.comp.boot-loaders.u-boot/110219 > --- > include/linux/mtd/nand.h |7 +++ > include/nand.h |3 --- > 2 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h > index 987a2ec..2419c6c 100644 > --- a/include/linux/mtd/nand.h > +++ b/include/linux/mtd/nand.h > @@ -624,3 +624,10 @@ struct platform_nand_chip *get_platform_nandchip(struct > mtd_info *mtd) > } > > #endif /* __LINUX_MTD_NAND_H */ > + > +/* Standard NAND functions from nand_base.c */ > +void nand_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len); > +void nand_write_buf16(struct mtd_info *mtd, const uint8_t *buf, int len); > +void nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len); > +void nand_read_buf16(struct mtd_info *mtd, uint8_t *buf, int len); > +uint8_t nand_read_byte(struct mtd_info *mtd); These need to go before the #endif. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] nand: Remove static modifier from common functions
On 10/16/2011 05:50 AM, Simon Schwarz wrote: > Removed static modifiers from functions that were often duplicated in > SPL implementations. > > Signed-off-by: Simon Schwarz > Cc: scottw...@freescale.com > Cc: s-paul...@ti.com > Cc: albert.u.b...@aribaud.net > --- > Changes V2: > nothing > --- > drivers/mtd/nand/nand_base.c |6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) Ideally the prototypes would be added in the same patch, but it's not worth respinning over, especially since U-Boot doesn't appear to enable -Wmissing-prototypes. Acked-by: Scott Wood Will this be taken via an ARM tree due to patch 3/3? -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] e1000: fix bugs from recent commits
Dear "Moffett, Kyle D",
In message you wrote:
>
> The correct E1000_WRITE_FLUSH macro should be:
> #define E1000_WRITE_FLUSH(a) \
> do { uint32_t x =3D E1000_READ_REG(a, STATUS); (void)x; } while(0=
> )
>
> It shouldn't return a value, it's just ensuring that writes are properly
> posted to the PCI bus.
Really? Should that not be guaranteed by the memory barriers inside
the E1000_READ_REG() code?
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
"Here's a fish hangs in the net like a poor man's right in the law.
'Twill hardly come out." - Shakespeare, Pericles, Act II, Scene 1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v8 2/3] MIPS: Jz4740: Add NAND driver
On 10/12/2011 09:26 AM, Shinya Kuribayashi wrote: > From: Xiangfu Liu > Date: Wed, 12 Oct 2011 12:24:06 +0800 > > Jz4740 NAND flash controller can support: > * MLC NAND as well as SLC NAND > * all 8-bit/16-bit NAND flash devices > * HAMMING and RS hardware ECC > * automatic boot up from NAND flash devices > > nand_ecclayout is set up for 2GiB NAND chip mounted in Qi LB60. > We'll bring up boot-from-NAND support in nand_spl/ in the future. > > Signed-off-by: Xiangfu Liu > Acked-by: Daniel > Signed-off-by: Shinya Kuribayashi Acked-by: Scott Wood -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Patchwork question
Dear Anton Staaf, In message you wrote: > > That makes sense to me, the reason I asked is that all of my patches are still > sitting in the new state, even though most of them have been applied already > (or rejected) for a while... Patchwork bugs... If you see such cases, please correct the state. It really helps me. Thanks! 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 "...all the good computer designs are bootlegged; the formally planned products, if they are built at all, are dogs!" - David E. Lundstrom, "A Few Good Men From Univac", MIT Press, 1987 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Patchwork question
Dear Albert ARIBAUD, In message <4eaae366.7050...@aribaud.net> you wrote: > > State changing should be done by the person who causes the change -- > > change requester or custodian -- as this is the only person that really > > knows for sure what the state change should be. Well, Patchwork often guesses wrong, and manual cleanup is needed. If a patch submitter sees his patch has been committed, and it is still marked as "new" in PW then such cleanup would help us maintainers. > Wolfgang uses tools to automate transitions to "Applied" when he applies > a patch or pull request -- I am looking into using these too. ...but this suferes from the known PW issues. > > Also, should I delegate patches to custodians that I believe should be > > looking at them? Or should custodians delegate patches to themselves? > > Le the custodians delegate as they see fit. Fact is that many don;t do this, or not regularly at least. I'd rather see all patches assigned to someone, even if incorrectly. The custodian will recognize soon enough that it's not for him, and reassign. If a patch is assigned, it's on somebody's todo list, asking for action. If it's left unassigned, it's in nowhere land where nobody feels responsible. 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 don't care if you *ARE* on a bondage-and-discipline post-technical system pawned off by the nation's largest oughta-be-illegal monopoly who cannot escape the sins of their forefathers -- namely, using the wrong slash for directories when the C language and its brethren use it for something else that's very important. -- Tom Christiansen in <55oabg$1j1$1...@csnews.cs.colorado.edu> ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Patchwork question
Dear Anton Staaf, In message you wrote: > > Who should change the state of patches there? Should I mark patches > that have been applied as Accepted? Or should the tree maintainer do > that? Both :-) > Also, should I delegate patches to custodians that I believe should be > looking at them? Or should custodians delegate patches to themselves? Both :-) The thing is, Patchwork has a number of shortcomings, and a number of bugs. Some patches get mis-identified, so earlier submissions (already marked as superseded) will set to "accepted", while the latest versions remain in state "new". Manual cleanup is needed then. Every help with this is more than welcome. Ditto for assigning patches to custoians (and don;t be afraid to guess wrong - if one custodian feels a patch is not for his plate, he can easily re-assign it). Better a wrong assignment than none [um... unless you assign them incorrectly to myself ;-) ] 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 human race has one really effective weapon, and that is laughter. - Mark Twain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] lib/string: memmove: use memcpy if it is safe to do so
Dear Peter Korsgaard, In message <1319789046-17715-1-git-send-email-jac...@sunsite.dk> you wrote: > memmove is used in a number of performance critical places, like copying the > linux kernel from nor flash to ram, so optimizing it can be interesting. > > Unfortunately, an arch specific version of memmove often isn't used, and > not supported at all on a number of archs (arm/mips/nds32/nios2/x86) - > But memcpy typically is. So you are adding code, making the system even less efficient? This sounds to be acounter-productive approach. Can you not instead arrange for arch specific, optimized versions memmove() to be used? 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 Uncertain fortune is thoroughly mastered by the equity of the calcu- lation. - Blaise Pascal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] e1000: fix bugs from recent commits
Dear Mike Frysinger,
In message
you wrote:
> On Fri, Oct 28, 2011 at 07:49, Wolfgang Denk wrote:
> > --- a/drivers/net/e1000.h
> > +++ b/drivers/net/e1000.h
> >
> > #define E1000_WRITE_FLUSH(a) \
> > - do { uint32_t x = E1000_READ_REG(a, STATUS); } while (0)
> > + E1000_READ_REG(a, STATUS)
>
> i think we want the do{}while as this is a write command and we don't
> want people accidentally trying to check the return value
I don't see that this is a write command. I'm seeing only reading of
the status register here.
And I don't understand the "accidentally trying to check the return
value" argument either. Why would one do that - and if one does
(probably after checking the implementation), what would be wrong
about 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
My play was a complete success. The audience was a failure.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] gpio: Add PCA9698 40-bit I2C I/O port
Dear Stefan Roese, In message <201110280825.08189...@denx.de> you wrote: > > Wolfgang, what would you prefer? Should Dirk just send an incremental patch? Yes, please. 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 It is more rational to sacrifice one life than six. -- Spock, "The Galileo Seven", stardate 2822.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot maintainers: some boards are broken by recent mach-type update
Hello all, Recently the ARM mach-types.h file has been brought in sync with its Linux original, leasing to a number of boards not being listed any more, as the new list only contains boards which have actual Linux support or were declared less than one year ago. The symptom is a build failure with a message of the form "error: 'MACH_TYPE_XX' undeclared (first use in this function)". U-Boot maintainers of such boards (in Cc: of this mail) should provide a patch to re-introduce the MACH_TYPE_XX definition in their boards' config header file in include/configs/. Note that three boards do not have a maintainer and will be removed if nobody steps forward to take over their maintainership. They have been listed below as ORPHAN, and since they are all PXA boards, I have CC:ed Marek just in case. Here is the list of broken boards (BTW: how about putting maintainer identity in boards.cfg, or at least turning MAINTAINERS into a format more easily parseable?) - Ajay Bhargav gplugd ARM926EJS (ARMADA100 88AP168 SoC) Luca Ceresoli dig297 ARM ARMV7 (OMAP3530 SoC) Po-Yu Chuang a320evb FA526 (ARM920T-like) (a320 SoC) Daniel Gorsulowski meesc ARM926EJS (AT91SAM9263 SoC) otc570 ARM926EJS (AT91SAM9263 SoC) Ilko Iliev PM9261 AT91SAM9261 PM9263 AT91SAM9263 PM9G45 ARM926EJS (AT91SAM9G45 SoC) Prakash Kumar cerf250 xscale/pxa Valentin Longchamp km_kirkwood ARM926EJS (Kirkwood SoC) portl2 ARM926EJS (Kirkwood SoC) David Müller VCMA9 ARM920T Jens Scharsig eb_cpux9k2 ARM920T (AT91RM9200 SoC) Heiko Schocher mgcoge3un ARM926EJS (Kirkwood SoC) Robert Schwebel csb226 xscale/pxa innokom xscale/pxa Albin Tonnerre sbc35_a9g20 ARM926EJS (AT91SAM9G20 SoC) tny_a9260 ARM926EJS (AT91SAM9260 SoC) tny_a9g20 ARM926EJS (AT91SAM9G20 SoC) Matthias Weisser jadecpu ARM926EJS (MB86R01 SoC) ORPHAN: cradle xscale/pxa pleb2 xscale/pxa xm250 xscale/pxa Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] disk: part_efi: fix regression due to incorrect buffer usage
Acked-by: Doug Anderson
...to be fair though, the regression appears to be caused by a mid-air
collision of Anton's change (f75dd584cdfe29dfdcfd424bb237b9238cfb8fe4) with
my change. His patch was committed on Oct 25th (though authored earlier).
When I submitted my patch on the Oct 19th against denx/master, I'm pretty
sure it was correct.
Thank you for finding / fixing! :)
-Doug
---
On Fri, Oct 28, 2011 at 12:21 PM, Stephen Warren wrote:
> Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix
> **pgpt_pte == NULL" modified the code to pass "&gpt_head" to
> is_gpt_valid() rather than the previous "gpt_head". However, gpt_head
> is a pointer to the buffer, not the actual buffer, since it was allocated
> using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the
> disk block onto the stack rather than into the buffer, causing the
> code to fail.
>
> This change reverts that portion of the commit mentioned above.
>
> Signed-off-by: Stephen Warren
> ---
> disk/part_efi.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/disk/part_efi.c b/disk/part_efi.c
> index e7f2714..ddf80a7 100644
> --- a/disk/part_efi.c
> +++ b/disk/part_efi.c
> @@ -130,7 +130,7 @@ void print_part_efi(block_dev_desc_t * dev_desc)
>}
>/* This function validates AND fills in the GPT header and PTE */
>if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
> -&(gpt_head), &gpt_pte) != 1) {
> +gpt_head, &gpt_pte) != 1) {
>printf("%s: *** ERROR: Invalid GPT ***\n", __func__);
>return;
>}
> @@ -169,7 +169,7 @@ int get_partition_info_efi(block_dev_desc_t * dev_desc,
> int part,
>
>/* This function validates AND fills in the GPT header and PTE */
>if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
> - &(gpt_head), &gpt_pte) != 1) {
> + gpt_head, &gpt_pte) != 1) {
>printf("%s: *** ERROR: Invalid GPT ***\n", __func__);
>return -1;
>}
> --
> 1.7.0.4
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] disk: part_efi: fix regression due to incorrect buffer usage
Commit deb5ca80275e8cfa74d5680b41204e08a095eca5 "disk: part_efi: fix
**pgpt_pte == NULL" modified the code to pass "&gpt_head" to
is_gpt_valid() rather than the previous "gpt_head". However, gpt_head
is a pointer to the buffer, not the actual buffer, since it was allocated
using ALLOC_CACHE_ALIGN_BUFFER. This caused is_gpt_valid() to read the
disk block onto the stack rather than into the buffer, causing the
code to fail.
This change reverts that portion of the commit mentioned above.
Signed-off-by: Stephen Warren
---
disk/part_efi.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/disk/part_efi.c b/disk/part_efi.c
index e7f2714..ddf80a7 100644
--- a/disk/part_efi.c
+++ b/disk/part_efi.c
@@ -130,7 +130,7 @@ void print_part_efi(block_dev_desc_t * dev_desc)
}
/* This function validates AND fills in the GPT header and PTE */
if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
-&(gpt_head), &gpt_pte) != 1) {
+gpt_head, &gpt_pte) != 1) {
printf("%s: *** ERROR: Invalid GPT ***\n", __func__);
return;
}
@@ -169,7 +169,7 @@ int get_partition_info_efi(block_dev_desc_t * dev_desc, int
part,
/* This function validates AND fills in the GPT header and PTE */
if (is_gpt_valid(dev_desc, GPT_PRIMARY_PARTITION_TABLE_LBA,
- &(gpt_head), &gpt_pte) != 1) {
+ gpt_head, &gpt_pte) != 1) {
printf("%s: *** ERROR: Invalid GPT ***\n", __func__);
return -1;
}
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Regression caused by "disk: part_efi: fix **pgpt_pte == NULL"
The commit below causes the command "mmc part" to fail on both Seaboard and Ventana (and I assume any Tegra platform, and possibly just any platform). Reverting it solves the problem. (this is observed in git://git.denx.de/u-boot.git master) commit deb5ca80275e8cfa74d5680b41204e08a095eca5 Author: Doug Anderson Date: Wed Oct 19 09:47:31 2011 + disk: part_efi: fix **pgpt_pte == NULL Code was setting **pgpt_pte == NULL, which meant that the pointer to the gpt_pte would be stored at RAM address . This 'worked' on T20 (SDRAM starts @ 0x), but hung gpt/EFI access on T30 (SDRAM starts @ 0x8000). Signed-off-by: Tom Warren Signed-off-by: Doug Anderson Test steps: mmc dev 1 # Works mmcinfo # Works mmc part # Hangs, or starts spewing messages such as: Aos DebugSemiHosting Initialized Assert on hardware/tegra/core/drivers/nvrm/nvrmkernel/core/ap15/ap15rm_power.c:486 Assert on hardware/tegra/core/drivers/nvrm/nvrmkernel/core/common/nvrm_power_dfs.c:2276 (perhaps it's executing some random address, and I happen to have some copy of fastboot in RAM from when I was flashing the updated U-Boot? -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] README: Fix supported i.MX SoC list for CONFIG_MXC_SPI
CONFIG_MXC_SPI currently works on MX31/35/51 boards, so update the README file. Signed-off-by: Fabio Estevam --- README |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/README b/README index 46f062f..de0b2db 100644 --- a/README +++ b/README @@ -1904,7 +1904,7 @@ The following options need to be configured: CONFIG_MXC_SPI Enables the driver for the SPI controllers on i.MX and MXC - SoCs. Currently only i.MX31 is supported. + SoCs. Currently i.MX31/35/51 are supported. - FPGA Support: CONFIG_FPGA -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] pm9261: add mach-type localy for the board
Hi Asen, You should copy Ilko as the maintainer, unless you are taking over maintainership of this board (and pm9263 and pm9g45), in which case please modify MAINTAINERS file as well. Le 28/10/2011 18:10, Asen Chavdarov Dimov a écrit : > Signed-off-by: Asen Chavdarov Dimov > --- > board/ronetix/pm9261/mach-type.h | 31 +++ NAK. Do not copy-paste mach-type.h, just add the MACH_TYPE_PM9261 define in include/configs/pm9261.h. > board/ronetix/pm9261/pm9261.c|1 + > 2 files changed, 32 insertions(+), 0 deletions(-) > create mode 100644 board/ronetix/pm9261/mach-type.h > > diff --git a/board/ronetix/pm9261/mach-type.h > b/board/ronetix/pm9261/mach-type.h > new file mode 100644 > index 000..ca07c18 > --- /dev/null > +++ b/board/ronetix/pm9261/mach-type.h > @@ -0,0 +1,31 @@ > +/* > + * This was manually generated from arch/arm/include/asm/mach-types.h > + * and add this machine ID removed with commit > + * 47af6f61bcd9fdd5dcf389cff0a7406eba756c6. > + * Do fix this. > + */ > + > +#ifndef __ASM_ARM_MACH_TYPE_PM9261_H > +#define __ASM_ARM_MACH_TYPE_PM9261_H > + > +#ifndef __ASSEMBLY__ > +/* The type of machine we're running on */ > +extern unsigned int __machine_arch_type; > +#endif > + > +/* see arch/arm/kernel/arch.c for a description of these */ > +#define MACH_TYPE_PM9261 1187 > + > +#ifdef CONFIG_MACH_PM9261 > +# ifdef machine_arch_type > +# undef machine_arch_type > +# define machine_arch_type __machine_arch_type > +# else > +# define machine_arch_type MACH_TYPE_PM9261 > +# endif > +# define machine_is_pm9261() (machine_arch_type == MACH_TYPE_PM9261) > +#else > +# define machine_is_pm9261() (0) > +#endif > + > +#endif > diff --git a/board/ronetix/pm9261/pm9261.c b/board/ronetix/pm9261/pm9261.c > index 871b94a..e394a93 100644 > --- a/board/ronetix/pm9261/pm9261.c > +++ b/board/ronetix/pm9261/pm9261.c > @@ -25,6 +25,7 @@ >*/ > > #include > +#include "mach-type.h" NAK -- you don't need this if you add MACH_TYPE_PM9261. > #include > #include > #include Same applies to the other two boards -- you can actually submit a single patch for all three of them. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] A bit about board.c, board.c
Hi Simon, Le 22/10/2011 18:40, Simon Glass a écrit : > Hi Albert, > > On Sat, Oct 22, 2011 at 12:17 AM, Albert ARIBAUD > wrote: >> Le 22/10/2011 07:11, Simon Glass a écrit : >>> >>> Hi, >>> >>> Each architecture has its own board.c but they are mostly quite similar. >>> >>> New features such as fdt, boot timing, trace, profiling, etc. must be >>> done separately for each arch, even if there are no >>> architecture-specific bits. >>> >>> What would you say to adding something like lib/board.c which is a >>> simplified cleaned-up copy of one of the existing board.c files, and a >>> CONFIG_ARCH_GENERIC_BOARD option to select that in preference to the >>> architecture-specific one. Then perhaps people could try it out and we >>> could slowly move to it over time... >> >> I'd say anything that factorizes ARM code is a good thing. :) >> >> However I'm not in favor of a CONFIG option that would force the board code >> to provide some functions just in odrer to override one, not if weak > > My suggestion was: > > CONFIG_ARCH_GENERIC_BOARD - you get lib/board.c > not CONFIG_ARCH_GENERIC_BOARD - you get arch/xxx/lib/board.c > >> definitions can do a finer job. I am looking into that already for cache >> management function specialization, and it seems like there is the same kind >> of possibility here, with lib functions defined weak and the board code >> overriding the ones it deems necessary to. > > ok. Just one little point. Weak symbols are the punishment our C++ > overlords gave us for not having to understand what code is executed > when we instantiate a C++ subclass. It is nice to know what code is > being linked in and avoid having to disassemble to find out. I think > using weak symbols to avoid a OBJS-$(CONFIG_ARCH_GENERIC_BOARD) in a > couple of Makefiles risks going too far. The problem I see with a config option is that it is all-or-nothing: either all cache functions are defined at the lib level, or none is. I want a finer-grain, function-by-function, approach. For the moment I think weak symbols are a nice solution, although I do recognize that it will be less visible than configuration options. > Regards, > Simon Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/5] mmc: Tegra2: Factor out mmc_wait_inhibit functionality
On Thu, Oct 13, 2011 at 2:57 PM, Anton Staaf wrote:
> This is a well encapsulated section of mmc_send_cmd, by moving
> it to it's own function it increases the readability of mmc_send_cmd.
>
> Signed-off-by: Anton Staaf
> Cc: Tom Warren
> Cc: Stephen Warren
Adding Albert to CC.
-Anton
> ---
> drivers/mmc/tegra2_mmc.c | 41 ++---
> 1 files changed, 26 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/mmc/tegra2_mmc.c b/drivers/mmc/tegra2_mmc.c
> index 27564b0..141429e 100644
> --- a/drivers/mmc/tegra2_mmc.c
> +++ b/drivers/mmc/tegra2_mmc.c
> @@ -102,18 +102,12 @@ static void mmc_set_transfer_mode(struct mmc_host
> *host, struct mmc_data *data)
> writew(mode, &host->reg->trnmod);
> }
>
> -static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
> - struct mmc_data *data)
> +static int mmc_wait_inhibit(struct mmc_host *host,
> + struct mmc_cmd *cmd,
> + struct mmc_data *data,
> + unsigned int timeout)
> {
> - struct mmc_host *host = (struct mmc_host *)mmc->priv;
> - int flags, i;
> - unsigned int timeout;
> - unsigned int mask;
> - unsigned int retry = 0x10;
> - debug(" mmc_send_cmd called\n");
> -
> - /* Wait max 10 ms */
> - timeout = 10;
> + unsigned int mask = 0;
>
> /*
> * PRNSTS
> @@ -121,15 +115,13 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
> *cmd,
> * CMDINHCMD[0] : Command Inhibit (CMD)
> */
> mask = (1 << 0);
> - if ((data != NULL) || (cmd->resp_type & MMC_RSP_BUSY))
> - mask |= (1 << 1);
>
> /*
> * We shouldn't wait for data inhibit for stop commands, even
> * though they might use busy signaling
> */
> - if (data)
> - mask &= ~(1 << 1);
> + if ((data == NULL) && (cmd->resp_type & MMC_RSP_BUSY))
> + mask |= (1 << 1);
>
> while (readl(&host->reg->prnsts) & mask) {
> if (timeout == 0) {
> @@ -140,6 +132,25 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
> *cmd,
> udelay(1000);
> }
>
> + return 0;
> +}
> +
> +static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
> + struct mmc_data *data)
> +{
> + struct mmc_host *host = (struct mmc_host *)mmc->priv;
> + int flags, i;
> + int result;
> + unsigned int timeout;
> + unsigned int mask;
> + unsigned int retry = 0x10;
> + debug(" mmc_send_cmd called\n");
> +
> + result = mmc_wait_inhibit(host, cmd, data, 10 /* ms */);
> +
> + if (result < 0)
> + return result;
> +
> if (data)
> mmc_prepare_data(host, data);
>
> --
> 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 1/5] mmc: Tegra2: Support DMA restarts at buffer boundaries
On Thu, Oct 13, 2011 at 2:57 PM, Anton Staaf wrote:
> Currently if a DMA buffer straddles a buffer alignment boundary
> (512KiB) then the DMA engine will pause and generate a DMA
> interrupt. Since the DMA interrupt is not enabled it will hang
> the MMC driver.
>
> This patch adds support for restarting the DMA transfer. The
> SYSTEM_ADDRESS register contains the next address that would have
> been read/written when a boundary is hit. So we can read that
> and write it back. The write triggers the resumption of the
> transfer.
>
> Signed-off-by: Anton Staaf
> Cc: Tom Warren
> Cc: Stephen Warren
Adding Albert to CC.
-Anton
> ---
> drivers/mmc/tegra2_mmc.c | 15 +++
> 1 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mmc/tegra2_mmc.c b/drivers/mmc/tegra2_mmc.c
> index 8b6f829..195f89d 100644
> --- a/drivers/mmc/tegra2_mmc.c
> +++ b/drivers/mmc/tegra2_mmc.c
> @@ -256,9 +256,15 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
> *cmd,
> __func__, mask);
> return -1;
> } else if (mask & (1 << 3)) {
> - /* DMA Interrupt */
> + /*
> + * DMA Interrupt, restart the transfer where
> + * it was interrupted.
> + */
> + unsigned int address =
> readl(&host->reg->sysad);
> +
> debug("DMA end\n");
> - break;
> + writel((1 << 3), &host->reg->norintsts);
> + writel(address, &host->reg->sysad);
> } else if (mask & (1 << 1)) {
> /* Transfer Complete */
> debug("r/w is done\n");
> @@ -442,12 +448,13 @@ static int mmc_core_init(struct mmc *mmc)
> * NORMAL Interrupt Status Enable Register init
> * [5] ENSTABUFRDRDY : Buffer Read Ready Status Enable
> * [4] ENSTABUFWTRDY : Buffer write Ready Status Enable
> + * [3] ENSTADMAINT : DMA Interrupt Status Enable
> * [1] ENSTASTANSCMPLT : Transfre Complete Status Enable
> * [0] ENSTACMDCMPLT : Command Complete Status Enable
> - */
> + */
> mask = readl(&host->reg->norintstsen);
> mask &= ~(0x);
> - mask |= (1 << 5) | (1 << 4) | (1 << 1) | (1 << 0);
> + mask |= (1 << 5) | (1 << 4) | (1 << 3) | (1 << 1) | (1 << 0);
> writel(mask, &host->reg->norintstsen);
>
> /*
> --
> 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 2/5] mmc: Tegra2: Add data transfer completion timeout
On Thu, Oct 13, 2011 at 2:57 PM, Anton Staaf wrote:
> Currently when no expected completion condition occures in the
> mmc_send_cmd while loop that is waiting for a data transfer to
> complete the MMC driver just hangs.
>
> This patch adds an arbitrary 2 second timeout. If nothing we
> recognize occures within 2 seconds some diagnostic information
> is printed and we fail out.
>
> Signed-off-by: Anton Staaf
> Cc: Tom Warren
> Cc: Stephen Warren
Adding Albert to CC.
-Anton
> ---
> drivers/mmc/tegra2_mmc.c | 14 ++
> 1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mmc/tegra2_mmc.c b/drivers/mmc/tegra2_mmc.c
> index 195f89d..27564b0 100644
> --- a/drivers/mmc/tegra2_mmc.c
> +++ b/drivers/mmc/tegra2_mmc.c
> @@ -246,6 +246,8 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
> *cmd,
> }
>
> if (data) {
> + unsigned long start = get_timer(0);
> +
> while (1) {
> mask = readl(&host->reg->norintsts);
>
> @@ -269,6 +271,18 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
> *cmd,
> /* Transfer Complete */
> debug("r/w is done\n");
> break;
> + } else if (get_timer(start) > 2000UL) {
> + writel(mask, &host->reg->norintsts);
> + printf("%s: MMC Timeout\n"
> + " Interrupt status 0x%08x\n"
> + " Interrupt status enable 0x%08x\n"
> + " Interrupt signal enable 0x%08x\n"
> + " Present status 0x%08x\n",
> + __func__, mask,
> + readl(&host->reg->norintstsen),
> + readl(&host->reg->norintsigen),
> + readl(&host->reg->prnsts));
> + return -1;
> }
> }
> writel(mask, &host->reg->norintsts);
> --
> 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 v6 4/5] tegra2: Modify MMC driver to handle power and cd GPIOs
Stephen Warren wrote at Wednesday, October 12, 2011 4:53 PM:
> Pass the GPIO numbers for power and card detect to tegra2_mmc_init(), and
> modify that function to perform all required GPIO initialization. This
> removes the need for board files to perform these operations.
>
> Move board_mmc_getcd() into tegra2_mmc.c now that the driver knows which
> GPIOs to use.
Andy,
This patch touches an MMC driver. If you consider it OK, could you please
Ack it so that Albert can apply the series to the ARM branch.
Thanks very much.
> Update affected call-sites in seaboard.c and harmony.c. Note that this
> change should make all SD ports work on Harmony, since the required GPIO
> setup is now being performed.
>
> v4: Fix prototype of tegra2_mmc_init() in board.h to match driver change.
> Remove prototype of gpio_config_mmc() from board.h
> Signed-off-by: Stephen Warren
> Tested-by: Simon Glass
> Acked-by: Simon Glass
> ---
> board/nvidia/common/board.h |3 +-
> board/nvidia/harmony/harmony.c | 27 ++-
> board/nvidia/seaboard/seaboard.c | 33 +
> drivers/mmc/tegra2_mmc.c | 42 -
> drivers/mmc/tegra2_mmc.h |4 ++-
> 5 files changed, 45 insertions(+), 64 deletions(-)
>
> diff --git a/board/nvidia/common/board.h b/board/nvidia/common/board.h
> index 344e702..35acbca 100644
> --- a/board/nvidia/common/board.h
> +++ b/board/nvidia/common/board.h
> @@ -26,7 +26,6 @@
>
> void tegra2_start(void);
> void gpio_config_uart(void);
> -void gpio_config_mmc(void);
> -int tegra2_mmc_init(int dev_index, int bus_width);
> +int tegra2_mmc_init(int dev_index, int bus_width, int pwr_gpio, int cd_gpio);
>
> #endif /* BOARD_H */
> diff --git a/board/nvidia/harmony/harmony.c b/board/nvidia/harmony/harmony.c
> index f2c3867..3cbe820 100644
> --- a/board/nvidia/harmony/harmony.c
> +++ b/board/nvidia/harmony/harmony.c
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #ifdef CONFIG_TEGRA2_MMC
> #include
> #endif
> @@ -72,15 +73,6 @@ static void pin_mux_mmc(void)
> pinmux_tristate_disable(PINGRP_ATC);
> }
>
> -/*
> - * Routine: gpio_config_mmc
> - * Description: Set GPIOs for SD card
> - */
> -void gpio_config_mmc(void)
> -{
> - /* Not implemented for now */
> -}
> -
> /* this is a weak define that we are overriding */
> int board_mmc_init(bd_t *bd)
> {
> @@ -88,29 +80,16 @@ int board_mmc_init(bd_t *bd)
>
> /* Enable muxes, etc. for SDMMC controllers */
> pin_mux_mmc();
> - gpio_config_mmc();
>
> debug("board_mmc_init: init SD slot J26\n");
> /* init dev 0, SD slot J26, with 4-bit bus */
> /* The board has an 8-bit bus, but 8-bit doesn't work yet */
> - tegra2_mmc_init(0, 4);
> + tegra2_mmc_init(0, 4, GPIO_PI6, GPIO_PH2);
>
> debug("board_mmc_init: init SD slot J5\n");
> /* init dev 2, SD slot J5, with 4-bit bus */
> - tegra2_mmc_init(2, 4);
> + tegra2_mmc_init(2, 4, GPIO_PT3, GPIO_PI5);
>
> return 0;
> }
> -
> -/* this is a weak define that we are overriding */
> -int board_mmc_getcd(u8 *cd, struct mmc *mmc)
> -{
> - debug("board_mmc_getcd called\n");
> - /*
> - * Hard-code CD presence for now. Need to add GPIO inputs
> - * for Harmony
> - */
> - *cd = 1;
> - return 0;
> -}
> #endif
> diff --git a/board/nvidia/seaboard/seaboard.c
> b/board/nvidia/seaboard/seaboard.c
> index 22a0e69..356d616 100644
> --- a/board/nvidia/seaboard/seaboard.c
> +++ b/board/nvidia/seaboard/seaboard.c
> @@ -87,19 +87,6 @@ static void pin_mux_mmc(void)
> pinmux_tristate_disable(PINGRP_ATC);
> }
>
> -/*
> - * Routine: gpio_config_mmc
> - * Description: Set GPIOs for SDMMC3 SDIO slot.
> - */
> -void gpio_config_mmc(void)
> -{
> - /* Set EN_VDDIO_SD (GPIO I6) */
> - gpio_direction_output(GPIO_PI6, 1);
> -
> - /* Config pin as GPI for Card Detect (GPIO I5) */
> - gpio_direction_input(GPIO_PI5);
> -}
> -
> /* this is a weak define that we are overriding */
> int board_mmc_init(bd_t *bd)
> {
> @@ -107,31 +94,15 @@ int board_mmc_init(bd_t *bd)
>
> /* Enable muxes, etc. for SDMMC controllers */
> pin_mux_mmc();
> - gpio_config_mmc();
>
> debug("board_mmc_init: init eMMC\n");
> /* init dev 0, eMMC chip, with 4-bit bus */
> /* The board has an 8-bit bus, but 8-bit doesn't work yet */
> - tegra2_mmc_init(0, 4);
> + tegra2_mmc_init(0, 4, -1, -1);
>
> debug("board_mmc_init: init SD slot\n");
> /* init dev 1, SD slot, with 4-bit bus */
> - tegra2_mmc_init(1, 4);
> -
> - return 0;
> -}
> -
> -/* this is a weak define that we are overriding */
> -int board_mmc_getcd(u8 *cd, struct mmc *mmc)
> -{
> - debug("board_mmc_getcd called\n");
> - *cd = 1;/* Assume card is inserted, or eMMC */
> -
> - if (IS_SD(mmc)) {
> - /* Seaboard SDMMC3 = SDIO3_CD = GPIO_PI5 */
> -
Re: [U-Boot] [PATCH 0/2] am335x: Minor fixes
Hi Tom, Le 22/10/2011 00:23, Tom Rini a écrit : > Hey all, > > As part of bringing over SPL support (which I'll post as soon > as I can figure out why this code doesn't run for me), I ran into > the following two fixes being needed. Patch set applied to u-boot-arm/master as a bugfix to the MACH_TYPE issue, thanks! Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/5] tegra2: Move MMC clock initialization into MMC driver
Stephen Warren wrote at Wednesday, October 12, 2011 4:53 PM:
> This centralizes knowledge of MMC clocking into the MMC driver. This also
> removes clock setup from the board files, which will simplify later changes
> that modify the Harmony board to support the correct set of MMC controllers.
Andy,
This patch touches an MMC driver. If you consider it OK, could you please
Ack it so that Albert can apply the series to the ARM branch.
Thanks very much.
> Signed-off-by: Stephen Warren
> Acked-by: Simon Glass
> Tested-by: Simon Glass
> ---
> board/nvidia/common/board.c | 13 +
> drivers/mmc/tegra2_mmc.c| 12 +---
> 2 files changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
> index d13537d..370a259 100644
> --- a/board/nvidia/common/board.c
> +++ b/board/nvidia/common/board.c
> @@ -102,16 +102,6 @@ static void pin_mux_uart(void)
>
> #ifdef CONFIG_TEGRA2_MMC
> /*
> - * Routine: clock_init_mmc
> - * Description: init the PLL and clocks for the SDMMC controllers
> - */
> -static void clock_init_mmc(void)
> -{
> - clock_start_periph_pll(PERIPH_ID_SDMMC4, CLOCK_ID_PERIPH, 2000);
> - clock_start_periph_pll(PERIPH_ID_SDMMC3, CLOCK_ID_PERIPH, 2000);
> -}
> -
> -/*
> * Routine: pin_mux_mmc
> * Description: setup the pin muxes/tristate values for the SDMMC(s)
> */
> @@ -157,8 +147,7 @@ int board_init(void)
> int board_mmc_init(bd_t *bd)
> {
> debug("board_mmc_init called\n");
> - /* Enable clocks, muxes, etc. for SDMMC controllers */
> - clock_init_mmc();
> + /* Enable muxes, etc. for SDMMC controllers */
> pin_mux_mmc();
> gpio_config_mmc();
>
> diff --git a/drivers/mmc/tegra2_mmc.c b/drivers/mmc/tegra2_mmc.c
> index 9e741f2..78b1190 100644
> --- a/drivers/mmc/tegra2_mmc.c
> +++ b/drivers/mmc/tegra2_mmc.c
> @@ -435,14 +435,22 @@ static int mmc_core_init(struct mmc *mmc)
>
> static int tegra2_mmc_initialize(int dev_index, int bus_width)
> {
> + struct mmc_host *host;
> struct mmc *mmc;
>
> debug(" mmc_initialize called\n");
>
> + host = &mmc_host[dev_index];
> +
> + host->clock = 0;
> + tegra2_get_setup(host, dev_index);
> +
> + clock_start_periph_pll(host->mmc_id, CLOCK_ID_PERIPH, 2000);
> +
> mmc = &mmc_dev[dev_index];
>
> sprintf(mmc->name, "Tegra2 SD/MMC");
> - mmc->priv = &mmc_host[dev_index];
> + mmc->priv = host;
> mmc->send_cmd = mmc_send_cmd;
> mmc->set_ios = mmc_set_ios;
> mmc->init = mmc_core_init;
> @@ -465,8 +473,6 @@ static int tegra2_mmc_initialize(int dev_index, int
> bus_width)
> mmc->f_min = 375000;
> mmc->f_max = 4800;
>
> - mmc_host[dev_index].clock = 0;
> - tegra2_get_setup(&mmc_host[dev_index], dev_index);
> mmc_register(mmc);
>
> return 0;
> --
> 1.7.0.4
--
nvpublic
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] e1000: fix bugs from recent commits
On Oct 28, 2011, at 01:49, Wolfgang Denk wrote:
> Commit 114d7fc0 "e1000: Rewrite EEPROM checksum error to give more
> information" failed to initialize the checksum variable which should
> result in random results. Fix that.
> [I wonder if that code has _ever_ been tested!!]
>
> I wonder if you have ever actually build and run this code???
> With the "checksum" variable being random (due to not being
> initialized) you should have seen serious checksum problems.
> How did this escape your testing?
Yes, sorry, that is the correct fix.
I'm running my old GIT checkout unmodified on my hardware right now
with no problems; I must have just gotten lucky with the compiler's
register allocation, perhaps?
*pokes through disassembly*
Yeah, it looks like I just got lucky and that stack slot is always
overwritten with zero by an earlier function call.
> Commit 2326a94d caused a ton of "unused variable 'x'" warnings.
> Fix these. While we are at it, remove some bogus parens.
>
> And all these build warnings - have you ever actully compiled that
> code? What's going on here??? - wd
>
> #define E1000_WRITE_FLUSH(a) \
> - do { uint32_t x = E1000_READ_REG(a, STATUS); } while (0)
> + E1000_READ_REG(a, STATUS)
The correct E1000_WRITE_FLUSH macro should be:
#define E1000_WRITE_FLUSH(a) \
do { uint32_t x = E1000_READ_REG(a, STATUS); (void)x; } while(0)
It shouldn't return a value, it's just ensuring that writes are properly
posted to the PCI bus.
I booted them and ran some standard load-and-performance tests on our
boards. Unfortunately I was not paying enough attention to the build
log after splitting the e1000 patches to put the SPI code in a separate
file; that was when I removed the apparently-unnecessary "(void)x;".
Is there a good way to turn on "-Werror" for U-Boot builds by default?
I'll make sure to do that in the future to catch these problems first.
Ohh, actually, for some reason "-Wno-unused" was getting propagated in
to CFLAGS from my system environment variables, that's why I didn't see
the error originally.
My apologies for the bugs.
Cheers,
Kyle Moffett
--
Curious about my work on the Debian powerpcspe port?
I'm keeping a blog here: http://pureperl.blogspot.com/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Patchwork question
On Fri, Oct 28, 2011 at 10:16 AM, Albert ARIBAUD wrote: > Hi Anton, > > Le 28/10/2011 18:52, Anton Staaf a écrit : >> >> I'm new to patchwork, and am wondering. >> >> Who should change the state of patches there? Should I mark patches >> that have been applied as Accepted? Or should the tree maintainer do >> that? > > State changing should be done by the person who causes the change -- change > requester or custodian -- as this is the only person that really knows for > sure what the state change should be. > > Wolfgang uses tools to automate transitions to "Applied" when he applies a > patch or pull request -- I am looking into using these too. That makes sense to me, the reason I asked is that all of my patches are still sitting in the new state, even though most of them have been applied already (or rejected) for a while... >> Also, should I delegate patches to custodians that I believe should be >> looking at them? Or should custodians delegate patches to themselves? > > Le the custodians delegate as they see fit. Will do. Thanks, Anton >> Thanks, >> Anton > > Amicalement, > -- > Albert. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] ARM: Update mach-types
Hi Tom, Le 28/10/2011 18:32, Tom Rini a écrit : > On Fri, Oct 28, 2011 at 8:22 AM, Albert ARIBAUD > wrote: >> Hi all, >> >> Le 28/10/2011 11:57, Stefano Babic a écrit : >>> On 10/28/2011 11:03 AM, Mike Frysinger wrote: On Wed, Oct 19, 2011 at 08:31, Albert ARIBAUD wrote: > Le 12/09/2011 05:54, Marek Vasut a écrit : >>This commit updates the mach-types based on the latest in Linus's > head > > Applied to u-boot-arm/master, thanks. so it's up to the respective board maintainers to fix all their boards that are now build broken ? >>> >>> Yes, I think so. I have already fixed a couple of i.MX boards. >>> >>> Stefano >> >> I have just pulled in the samsung and imx pull requests and launched a >> MAKEALL arm to collect all boards with MACH_TYPE issues and notify their >> maintainers. Expect the notifications yo be sent tonight. > > Can you exclude am335x_evm from that list? I sent a patch to add the > define temporarily a while back. Thanks :) Will do -- and I'll take your patch set in as a bugfix even though it came in after oct 15th. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Patchwork question
Hi Anton, Le 28/10/2011 18:52, Anton Staaf a écrit : > I'm new to patchwork, and am wondering. > > Who should change the state of patches there? Should I mark patches > that have been applied as Accepted? Or should the tree maintainer do > that? State changing should be done by the person who causes the change -- change requester or custodian -- as this is the only person that really knows for sure what the state change should be. Wolfgang uses tools to automate transitions to "Applied" when he applies a patch or pull request -- I am looking into using these too. > Also, should I delegate patches to custodians that I believe should be > looking at them? Or should custodians delegate patches to themselves? Le the custodians delegate as they see fit. > Thanks, > Anton Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] OMAP3: Add SPL support to Beagleboard
On 10/28/2011 09:42 AM, Scott Wood wrote:
> On 10/28/2011 11:29 AM, Tom Rini wrote:
>> On 10/28/2011 09:00 AM, Scott Wood wrote:
>>> On 10/27/2011 06:33 PM, Tom Rini wrote:
On 10/27/2011 04:22 PM, Scott Wood wrote:
> On 10/27/2011 06:13 PM, Tom Rini wrote:
>> OK, so, Scott, where would you suggest we put a very trivial set of nand
>> infrastructure we need outside of the scope of loading u-boot itself
>> from NAND ?
>
> Can the SPL code be used (not an actual SPL build, just the NAND code
> associated with it)?
As-is, no, it'll fail to compile unless you fill in a number of blanks
about ECC and so forth.
>>>
>>> "...with appropriate refactoring" was implied. :-)
>>>
If we split nand_spl_simple.c in two, we might
be able to re-use nand_command there (maybe with some re-thinking of the
#if logic for big or small pages). Give me filenames and I'll do the
work :)
>>>
>>> Pick whatever name you think makes sense given what's going to be in it.
>>
>> nand_spl_{cmd,read}.c ? _cmd gets the two nand_command() funcs, _read
>> gets everything else. Work for you?
>
> Could you stick a "simple" in there somewhere?
>
> Maybe nand_spl_simple.c and nand_cmd_simple.c (or nand_spl_simple_cmd.c
> if you want to keep the reference to spl as its primary purpose)?
nand_spl_simple.c + nand_spl_simple_cmd.c it is then, thanks. Putting
this on my v2012.03 TODO list (which is when I figure I should have this
all done and a merge window be available).
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] pm9263: add mach-type localy for the board
Signed-off-by: Asen Chavdarov Dimov --- board/ronetix/pm9263/mach-type.h | 31 +++ board/ronetix/pm9263/pm9263.c|1 + 2 files changed, 32 insertions(+), 0 deletions(-) create mode 100644 board/ronetix/pm9263/mach-type.h diff --git a/board/ronetix/pm9263/mach-type.h b/board/ronetix/pm9263/mach-type.h new file mode 100644 index 000..afa02df --- /dev/null +++ b/board/ronetix/pm9263/mach-type.h @@ -0,0 +1,31 @@ +/* + * This was manually generated from arch/arm/include/asm/mach-types.h + * and add this machine ID removed with commit + * 47af6f61bcd9fdd5dcf389cff0a7406eba756c6. + * Do fix this. + */ + +#ifndef __ASM_ARM_MACH_TYPE_PM9263_H +#define __ASM_ARM_MACH_TYPE_PM9263_H + +#ifndef __ASSEMBLY__ +/* The type of machine we're running on */ +extern unsigned int __machine_arch_type; +#endif + +/* see arch/arm/kernel/arch.c for a description of these */ +#define MACH_TYPE_PM9263 1475 + +#ifdef CONFIG_MACH_PM9263 +# ifdef machine_arch_type +# undef machine_arch_type +# define machine_arch_type__machine_arch_type +# else +# define machine_arch_typeMACH_TYPE_PM9263 +# endif +# define machine_is_pm9263() (machine_arch_type == MACH_TYPE_PM9263) +#else +# define machine_is_pm9263() (0) +#endif + +#endif diff --git a/board/ronetix/pm9263/pm9263.c b/board/ronetix/pm9263/pm9263.c index cfc9847..86a84b0 100644 --- a/board/ronetix/pm9263/pm9263.c +++ b/board/ronetix/pm9263/pm9263.c @@ -25,6 +25,7 @@ */ #include +#include "mach-type.h" #include #include #include -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] pm9261: add mach-type localy for the board
Signed-off-by: Asen Chavdarov Dimov --- board/ronetix/pm9261/mach-type.h | 31 +++ board/ronetix/pm9261/pm9261.c|1 + 2 files changed, 32 insertions(+), 0 deletions(-) create mode 100644 board/ronetix/pm9261/mach-type.h diff --git a/board/ronetix/pm9261/mach-type.h b/board/ronetix/pm9261/mach-type.h new file mode 100644 index 000..ca07c18 --- /dev/null +++ b/board/ronetix/pm9261/mach-type.h @@ -0,0 +1,31 @@ +/* + * This was manually generated from arch/arm/include/asm/mach-types.h + * and add this machine ID removed with commit + * 47af6f61bcd9fdd5dcf389cff0a7406eba756c6. + * Do fix this. + */ + +#ifndef __ASM_ARM_MACH_TYPE_PM9261_H +#define __ASM_ARM_MACH_TYPE_PM9261_H + +#ifndef __ASSEMBLY__ +/* The type of machine we're running on */ +extern unsigned int __machine_arch_type; +#endif + +/* see arch/arm/kernel/arch.c for a description of these */ +#define MACH_TYPE_PM9261 1187 + +#ifdef CONFIG_MACH_PM9261 +# ifdef machine_arch_type +# undef machine_arch_type +# define machine_arch_type__machine_arch_type +# else +# define machine_arch_typeMACH_TYPE_PM9261 +# endif +# define machine_is_pm9261() (machine_arch_type == MACH_TYPE_PM9261) +#else +# define machine_is_pm9261() (0) +#endif + +#endif diff --git a/board/ronetix/pm9261/pm9261.c b/board/ronetix/pm9261/pm9261.c index 871b94a..e394a93 100644 --- a/board/ronetix/pm9261/pm9261.c +++ b/board/ronetix/pm9261/pm9261.c @@ -25,6 +25,7 @@ */ #include +#include "mach-type.h" #include #include #include -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] pm9g45: add mach-type localy for the board
Signed-off-by: Asen Chavdarov Dimov --- board/ronetix/pm9g45/mach-type.h | 31 +++ board/ronetix/pm9g45/pm9g45.c|1 + 2 files changed, 32 insertions(+), 0 deletions(-) create mode 100644 board/ronetix/pm9g45/mach-type.h diff --git a/board/ronetix/pm9g45/mach-type.h b/board/ronetix/pm9g45/mach-type.h new file mode 100644 index 000..3f8902f --- /dev/null +++ b/board/ronetix/pm9g45/mach-type.h @@ -0,0 +1,31 @@ +/* + * This was manually generated from arch/arm/include/asm/mach-types.h + * and add this machine ID removed with commit + * 47af6f61bcd9fdd5dcf389cff0a7406eba756c6. + * Do fix this. + */ + +#ifndef __ASM_ARM_MACH_TYPE_PM9G45_H +#define __ASM_ARM_MACH_TYPE_PM9G45_H + +#ifndef __ASSEMBLY__ +/* The type of machine we're running on */ +extern unsigned int __machine_arch_type; +#endif + +/* see arch/arm/kernel/arch.c for a description of these */ +#define MACH_TYPE_PM9G45 2672 + +#ifdef CONFIG_MACH_PM9G45 +# ifdef machine_arch_type +# undef machine_arch_type +# define machine_arch_type__machine_arch_type +# else +# define machine_arch_typeMACH_TYPE_PM9G45 +# endif +# define machine_is_pm9g45() (machine_arch_type == MACH_TYPE_PM9G45) +#else +# define machine_is_pm9g45() (0) +#endif + +#endif diff --git a/board/ronetix/pm9g45/pm9g45.c b/board/ronetix/pm9g45/pm9g45.c index f3374a4..9aff01a 100644 --- a/board/ronetix/pm9g45/pm9g45.c +++ b/board/ronetix/pm9g45/pm9g45.c @@ -28,6 +28,7 @@ */ #include +#include "mach-type.h" #include #include #include -- 1.7.4.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Patchwork question
I'm new to patchwork, and am wondering. Who should change the state of patches there? Should I mark patches that have been applied as Accepted? Or should the tree maintainer do that? Also, should I delegate patches to custodians that I believe should be looking at them? Or should custodians delegate patches to themselves? Thanks, Anton ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] OMAP3: Add SPL support to Beagleboard
On 10/28/2011 11:29 AM, Tom Rini wrote:
> On 10/28/2011 09:00 AM, Scott Wood wrote:
>> On 10/27/2011 06:33 PM, Tom Rini wrote:
>>> On 10/27/2011 04:22 PM, Scott Wood wrote:
On 10/27/2011 06:13 PM, Tom Rini wrote:
> OK, so, Scott, where would you suggest we put a very trivial set of nand
> infrastructure we need outside of the scope of loading u-boot itself
> from NAND ?
Can the SPL code be used (not an actual SPL build, just the NAND code
associated with it)?
>>>
>>> As-is, no, it'll fail to compile unless you fill in a number of blanks
>>> about ECC and so forth.
>>
>> "...with appropriate refactoring" was implied. :-)
>>
>>> If we split nand_spl_simple.c in two, we might
>>> be able to re-use nand_command there (maybe with some re-thinking of the
>>> #if logic for big or small pages). Give me filenames and I'll do the
>>> work :)
>>
>> Pick whatever name you think makes sense given what's going to be in it.
>
> nand_spl_{cmd,read}.c ? _cmd gets the two nand_command() funcs, _read
> gets everything else. Work for you?
Could you stick a "simple" in there somewhere?
Maybe nand_spl_simple.c and nand_cmd_simple.c (or nand_spl_simple_cmd.c
if you want to keep the reference to spl as its primary purpose)?
-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help starting u-boot on an at91sam9260ek
On Fri, 2011-10-28 at 14:45 +0200, Stefano Babic wrote: > On 10/28/2011 11:21 AM, Fabio Porcedda wrote: > > Hi all, > > i'm trying to use the u-boot on an at91sam9260ek board, > > i cannot start successfull the u-boot binary. > > > > Hi Fabio, > Hi Stefano, > > Hit any key to stop autoboot: 0 > > U-Boot> loadb > > ## Ready for binary (kermit) download to 0x2200 at 115200 bps... > > > > Well, it is not clear to me why you want to run u-boot as single > application, instead of replacing the version you have now on target. > And why are you loading u-boot at 0x2200, because if I see in the > include/configs/at91sam9260ek.h CONFIG_SYS_TEXT_BASE is set to 0x21f0... Loading u-boot at 0x21f0 solved the issue! Thank you very much! I'm loading as single application, because if make some mistake it's faster to change the binary, and it's easy to change the load address too. > Apart of that, you should also check the bootstrap code (not part of > u-boot), and maybe you have to fix it if the addresses do not correspond > or a smaller image from NAND flash as u-boot is copied. Now i check the bootstrap code for the correct load address. > Best regards, > Stefano Babic > Thank you very much Fabio Porcedda ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] ARM: Update mach-types
On Fri, Oct 28, 2011 at 8:22 AM, Albert ARIBAUD wrote: > Hi all, > > Le 28/10/2011 11:57, Stefano Babic a écrit : >> On 10/28/2011 11:03 AM, Mike Frysinger wrote: >>> On Wed, Oct 19, 2011 at 08:31, Albert ARIBAUD wrote: Le 12/09/2011 05:54, Marek Vasut a écrit : > This commit updates the mach-types based on the latest in Linus's head Applied to u-boot-arm/master, thanks. >>> >>> so it's up to the respective board maintainers to fix all their boards >>> that are now build broken ? >> >> Yes, I think so. I have already fixed a couple of i.MX boards. >> >> Stefano > > I have just pulled in the samsung and imx pull requests and launched a > MAKEALL arm to collect all boards with MACH_TYPE issues and notify their > maintainers. Expect the notifications yo be sent tonight. Can you exclude am335x_evm from that list? I sent a patch to add the define temporarily a while back. Thanks :) -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] OMAP3: Add SPL support to Beagleboard
On 10/28/2011 09:00 AM, Scott Wood wrote:
> On 10/27/2011 06:33 PM, Tom Rini wrote:
>> On 10/27/2011 04:22 PM, Scott Wood wrote:
>>> On 10/27/2011 06:13 PM, Tom Rini wrote:
OK, so, Scott, where would you suggest we put a very trivial set of nand
infrastructure we need outside of the scope of loading u-boot itself
from NAND ?
>>>
>>> Can the SPL code be used (not an actual SPL build, just the NAND code
>>> associated with it)?
>>
>> As-is, no, it'll fail to compile unless you fill in a number of blanks
>> about ECC and so forth.
>
> "...with appropriate refactoring" was implied. :-)
>
>> If we split nand_spl_simple.c in two, we might
>> be able to re-use nand_command there (maybe with some re-thinking of the
>> #if logic for big or small pages). Give me filenames and I'll do the
>> work :)
>
> Pick whatever name you think makes sense given what's going to be in it.
nand_spl_{cmd,read}.c ? _cmd gets the two nand_command() funcs, _read
gets everything else. Work for you?
--
Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] OMAP3 NAND ECC bug report
On 10/28/2011 01:10 AM, Arno Steffen wrote: > I have been used u-boot supportet (or better say not suppported) by TI > in their latest PSP/SDK (Juli 2011). > Base is 2010.06. But this issue was also inside older versions. It's not older versions I'm concerned about, but newer ones. This bug has been fixed in mainline U-Boot, about a year ago. We don't have a time machine to put the bug fix in older versions. :-) -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/10 v3] spl, nand: add 4bit HW ecc oob first nand_read_page function
On 10/28/2011 01:05 AM, Heiko Schocher wrote: > Hello Scott, > > Scott Wood wrote: >> On 10/27/2011 12:23 AM, Heiko Schocher wrote: > In drivers/mtd/nand/davinci_nand.c CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST > is used, and there are 4bit specific functions, so this define is > also valid, just we need in drivers/mtd/nand/nand_spl_simple.c a more > common name, right? Right. Ideally, though, that would either be CONFIG_SYS_DAVINCI_... or #if defined(CONFIG_SYS_NAND_HW_ECC_OOBFIRST) && \ defined(CONFIG_SYS_NAND_HW_ECC_4BIT) >>> Hmm.. I thought you meant, this is not davinci nor 4bit specific? >>> Or do you mean to rename the CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST >>> define in drivers/mtd/nand/davinci_nand.c? >> >> I just mean that "4bit" and "oobfirst" are independent things, so I'd >> rather not have something that combines the two as part of the >> configuration of the general NAND interface in the absence of a >> requirement to enumerate all possibilities. OTOH, the structure of >> driver's private config can be whatever makes the most sense for that >> driver, but should be named in a way that it's obviously driver-specific. > > So my v4 version of this patch is ok? see: > http://patchwork.ozlabs.org/patch/121295/ Yes, the patch looks good -- ACK sent. > Maybe we should rename the CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST > in drivers/mtd/nand/davinci_nand.c to CONFIG_SYS_DAVINCI_NAND_HW_4BIT > in a seperate patch? Sure, that'd be good. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 06/11] spl, nand: add 4bit HW ecc oob first nand_read_page function
On 10/24/2011 02:38 AM, Heiko Schocher wrote: > similiar to commit dc7cd8e59ba077f3b4c1a4557c9cd86a31b9ab1f, only > adapted for the new spl framework. > > Signed-off-by: Heiko Schocher > Acked-by: Tom Rini > Cc: Scott Wood > Cc: Albert ARIBAUD > Cc: Sandeep Paulraj > > --- > changes for v2: > - add comment from Scott Wood: > as BSS is cleared, no need for intializing vars with 0 > remove this. > > changes for v3: > - add comment from Scoot Wood and Tom Rini > - rename CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST to > CONFIG_SYS_NAND_HW_ECC_OOBFIRST > - add dokumentation in README > > changes for v4: > - added Acked-by: Tom Rini > > README |5 > drivers/mtd/nand/nand_spl_simple.c | 43 > +++- > 2 files changed, 47 insertions(+), 1 deletions(-) Acked-by: Scott Wood -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] OMAP3: Add SPL support to Beagleboard
On 10/27/2011 06:33 PM, Tom Rini wrote: > On 10/27/2011 04:22 PM, Scott Wood wrote: >> On 10/27/2011 06:13 PM, Tom Rini wrote: >>> OK, so, Scott, where would you suggest we put a very trivial set of nand >>> infrastructure we need outside of the scope of loading u-boot itself >>> from NAND ? >> >> Can the SPL code be used (not an actual SPL build, just the NAND code >> associated with it)? > > As-is, no, it'll fail to compile unless you fill in a number of blanks > about ECC and so forth. "...with appropriate refactoring" was implied. :-) > If we split nand_spl_simple.c in two, we might > be able to re-use nand_command there (maybe with some re-thinking of the > #if logic for big or small pages). Give me filenames and I'll do the > work :) Pick whatever name you think makes sense given what's going to be in it. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] kirkwood: drop empty asm-offsets.s file
Mike, On Fri, Oct 28, 2011 at 02:23:56AM -0400, Mike Frysinger wrote: > This generated file does not belong in the tree -> punt. > > Signed-off-by: Mike Frysinger Acked-by: Jason Cooper > --- > 0 files changed, 0 insertions(+), 0 deletions(-) > delete mode 100644 arch/arm/cpu/arm926ejs/kirkwood/asm-offsets.s > > diff --git a/arch/arm/cpu/arm926ejs/kirkwood/asm-offsets.s > b/arch/arm/cpu/arm926ejs/kirkwood/asm-offsets.s > deleted file mode 100644 > index e69de29..000 > -- > 1.7.6.1 > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] ARM: Update mach-types
Hi all, Le 28/10/2011 11:57, Stefano Babic a écrit : > On 10/28/2011 11:03 AM, Mike Frysinger wrote: >> On Wed, Oct 19, 2011 at 08:31, Albert ARIBAUD wrote: >>> Le 12/09/2011 05:54, Marek Vasut a écrit : >>> > This commit updates the mach-types based on the latest in Linus's head >>> >>> Applied to u-boot-arm/master, thanks. >> >> so it's up to the respective board maintainers to fix all their boards >> that are now build broken ? > > Yes, I think so. I have already fixed a couple of i.MX boards. > > Stefano I have just pulled in the samsung and imx pull requests and launched a MAKEALL arm to collect all boards with MACH_TYPE issues and notify their maintainers. Expect the notifications yo be sent tonight. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi Stefano,
Le 28/10/2011 14:37, Stefano Babic a écrit :
> Hi Albert,
>
> please pull from u-boot-imx.
>
> The following changes since commit ce5207e191c59b3135303fd03b98dd2ac3701ba2:
>
>e1000: Allow direct access to the E1000 SPI EEPROM device (2011-10-28
> 00:37:01 +0200)
>
> are available in the git repository at:
>git://www.denx.de/git/u-boot-imx.git master
>
> Fabio Estevam (12):
>qong: remove unneeded "1" from qong.h
>mx31pdk: Add MC13783 PMIC support
>mx31: Introduce mx31_set_gpr function
>qong: Use mx31_set_gpr to setup USBH2 pins
>qong: remove unneeded IOMUX settings
>rtc: Make mc13783-rtc driver generic
>mx51evk: Add RTC support
>mx51evk: Use GPIO API for configuring the IOMUX
>mx35pdk: Add RTC support
>mx51evk: Remove unneeded '1' from mx51evk.h
>mx51evk: Remove unused get_board_rev function
>vision2: Remove unused header file
>
> Helmut Raiger (4):
>misc: pmic: fix regression in pmic_fsl.c (SPI)
>mx31: define pins and init for UART2 and CSPI3
>mx31: add ESD control registers
>mx31: Add board support for HALE TT-01
>
> Marek Vasut (1):
>I2C: Fix mxc_i2c.c problem on imx31_phycore
>
> Stefano Babic (9):
>MX35: added ESDC structure to imx-regs
>MX35: add pins definition for UART3
>MX35: add reset cause as provided by other i.MX
>MX35: factorize common assembly code
>I2C: added I2C-2 and I2C-3 to MX35
>MX35: Drop unnecessary prototypes from imx-regs.h
>MX51: vision2: add MACH_TYPE in config file
>MX35: add support for flea3 board
>MX25: tx25: Fix building due to missing MACH_TYPE
>
> Wolfgang Grandegger (1):
>mx5 configs: CONFIG_PRIME should really be CONFIG_ETHPRIME
>
> MAINTAINERS |5 +
> README |2 +-
> arch/arm/cpu/arm1136/mx31/devices.c | 15 ++
> arch/arm/cpu/arm1136/mx31/generic.c | 15 ++
> arch/arm/cpu/arm1136/mx35/generic.c | 31 +++-
> arch/arm/include/asm/arch-mx31/clock.h |2 +
> arch/arm/include/asm/arch-mx31/imx-regs.h | 67 ++
> arch/arm/include/asm/arch-mx35/imx-regs.h | 34 +++-
> arch/arm/include/asm/arch-mx35/lowlevel_macro.S | 140 +++
> arch/arm/include/asm/arch-mx35/mx35_pins.h |3 +
> board/CarMediaLab/flea3/Makefile| 49
> board/CarMediaLab/flea3/flea3.c | 289
> +++
> board/CarMediaLab/flea3/lowlevel_init.S | 79 ++
> board/davedenx/qong/qong.c |8 +-
> board/freescale/mx31pdk/mx31pdk.c | 12 +
> board/freescale/mx35pdk/mx35pdk.h | 18 --
> board/freescale/mx51evk/mx51evk.c | 17 +-
> board/hale/tt01/Makefile| 51
> board/hale/tt01/lowlevel_init.S | 32 +++
> board/hale/tt01/tt01.c | 200
> board/karo/tx25/tx25.c |1 -
> board/ttcontrol/vision2/vision2.c |1 -
> boards.cfg |2 +
> drivers/i2c/mxc_i2c.c | 41 +++-
> drivers/misc/pmic_fsl.c |5 +-
> drivers/misc/pmic_spi.c |3 +-
> drivers/rtc/Makefile|2 +-
> drivers/rtc/{mc13783-rtc.c => mc13xxx-rtc.c}|0
> include/configs/efikamx.h |2 +-
> include/configs/flea3.h | 286
> ++
> include/configs/imx31_litekit.h |2 +-
> include/configs/mx31ads.h |2 +-
> include/configs/mx31pdk.h |2 +-
> include/configs/mx35pdk.h |2 +
> include/configs/mx51evk.h | 14 +-
> include/configs/mx53ard.h |2 +-
> include/configs/mx53evk.h |2 +-
> include/configs/mx53loco.h |2 +-
> include/configs/mx53smd.h |2 +-
> include/configs/qong.h | 36 ++--
> include/configs/tt01.h | 254
> include/configs/tx25.h |6 +
> include/configs/vision2.h |5 +-
> 43 files changed, 1644 insertions(+), 99 deletions(-)
> create mode 100644 arch/arm/include/asm/arch-mx35/lowlevel_macro.S
> create mode 100644 board/CarMediaLab/flea3/Makefile
> create mode 100644 board/CarMediaLab/flea3/flea3.c
> create mode 100644 board/CarMediaLab/flea3/lowlevel_init.S
> create mode 100644 board/hale/tt01/Makefile
> create mode 100644 board/hale/tt01/lowlevel_init.S
>
Re: [U-Boot] please pull u-boot-samsung/master
Hi Minkyu,
Le 28/10/2011 10:19, Minkyu Kang a écrit :
> Dear Albert,
>
> The following changes since commit 37fc0ed268dc5acacd3a83adafa26eb1a84e90af:
>
>ARM: Add Calxeda Highbank platform (2011-10-27 21:56:37 +0200)
>
> are available in the git repository at:
>git://git.denx.de/u-boot-samsung master
>
> Angus Ainslie (2):
>ORIGEN : enable device tree support
>ORIGEN : use absolute paths and fix tool naming
>
> Chander Kashyap (4):
>SMDKV310: Initialize board id using CONFIG_MACH_TYPE
>SMDKV310: use get_ram_size() to validate dram size
>smdkv310: use spl framework for mmc spl
>smdkv310: use macro for mmc data read function address
>
> Łukasz Majewski (3):
>dcache:s5p CONFIG_SYS_CACHELINE_SIZE added for s5p GONI target
>dcache:s5p CONFIG_SYS_CACHELINE_SIZE added for s5p UNIVERSAL C210
> target
>misc:pmic:samsung Enable PMIC driver at C210 Universal target
>
> board/samsung/origen/Makefile |6 +-
> board/samsung/smdkv310/Makefile| 19 -
> .../board => board}/samsung/smdkv310/mmc_boot.c| 15 ++--
> board/samsung/smdkv310/smdkv310.c | 13 ++-
> .../samsung/smdkv310/tools/mkv310_image.c |0
> board/samsung/universal_c210/universal.c |5 +
> include/configs/origen.h |3 +
> include/configs/s5p_goni.h |2 +
> include/configs/s5pc210_universal.h| 19
> include/configs/smdkv310.h |8 ++-
> mmc_spl/board/samsung/smdkv310/Makefile| 106
>
> mmc_spl/board/samsung/smdkv310/u-boot.lds | 88
> spl/Makefile |2 +-
> 13 files changed, 74 insertions(+), 212 deletions(-)
> rename {mmc_spl/board => board}/samsung/smdkv310/mmc_boot.c (83%)
> rename {mmc_spl/board => board}/samsung/smdkv310/tools/mkv310_image.c
> (100%)
> delete mode 100644 mmc_spl/board/samsung/smdkv310/Makefile
> delete mode 100644 mmc_spl/board/samsung/smdkv310/u-boot.lds
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] [PATCH 1/5] arm/km: adapt bootcounter evaluation
Hi Prafulla, On 09/14/2011 10:41 AM, Holger Brunck wrote: > The bootcounter (stored in the RAM) is not enough protected with the 4 Bytes > BOOTCOUNT_MAGIC against bit errors due to short power loss or holding a system > in RESET. It has been seen, that the bootcounter value has been changed due to > a bit flip on a system holding in RESET, but the BOOTCOUNT_MAGIC was still > valid. > > A bit pattern with 4000 bytes (after BOOTCOUNT_MAGIC) has been implemented, > which should be enough to detect a bit error. > > Signed-off-by: Holger Brunck > Signed-off-by: Valentin Longchamp > cc: Prafulla Wadaskar > --- > board/keymile/km_arm/km_arm.c | 32 +++- > 1 files changed, 27 insertions(+), 5 deletions(-) > ...ping... Or should this serie not go through your tree? If so then please let me know. Same question for these two patches: http://lists.denx.de/pipermail/u-boot/2011-September/102534.html http://lists.denx.de/pipermail/u-boot/2011-September/102535.html Best regards Holger ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Help starting u-boot on an at91sam9260ek
On 10/28/2011 11:21 AM, Fabio Porcedda wrote: > Hi all, > i'm trying to use the u-boot on an at91sam9260ek board, > i cannot start successfull the u-boot binary. > Hi Fabio, > Hit any key to stop autoboot: 0 > U-Boot> loadb > ## Ready for binary (kermit) download to 0x2200 at 115200 bps... > Well, it is not clear to me why you want to run u-boot as single application, instead of replacing the version you have now on target. And why are you loading u-boot at 0x2200, because if I see in the include/configs/at91sam9260ek.h CONFIG_SYS_TEXT_BASE is set to 0x21f0... Apart of that, you should also check the bootstrap code (not part of u-boot), and maybe you have to fix it if the addresses do not correspond or a smaller image from NAND flash as u-boot is copied. 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-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [GIT PULL] Pull request: u-boot-imx
Hi Albert,
please pull from u-boot-imx.
The following changes since commit ce5207e191c59b3135303fd03b98dd2ac3701ba2:
e1000: Allow direct access to the E1000 SPI EEPROM device (2011-10-28
00:37:01 +0200)
are available in the git repository at:
git://www.denx.de/git/u-boot-imx.git master
Fabio Estevam (12):
qong: remove unneeded "1" from qong.h
mx31pdk: Add MC13783 PMIC support
mx31: Introduce mx31_set_gpr function
qong: Use mx31_set_gpr to setup USBH2 pins
qong: remove unneeded IOMUX settings
rtc: Make mc13783-rtc driver generic
mx51evk: Add RTC support
mx51evk: Use GPIO API for configuring the IOMUX
mx35pdk: Add RTC support
mx51evk: Remove unneeded '1' from mx51evk.h
mx51evk: Remove unused get_board_rev function
vision2: Remove unused header file
Helmut Raiger (4):
misc: pmic: fix regression in pmic_fsl.c (SPI)
mx31: define pins and init for UART2 and CSPI3
mx31: add ESD control registers
mx31: Add board support for HALE TT-01
Marek Vasut (1):
I2C: Fix mxc_i2c.c problem on imx31_phycore
Stefano Babic (9):
MX35: added ESDC structure to imx-regs
MX35: add pins definition for UART3
MX35: add reset cause as provided by other i.MX
MX35: factorize common assembly code
I2C: added I2C-2 and I2C-3 to MX35
MX35: Drop unnecessary prototypes from imx-regs.h
MX51: vision2: add MACH_TYPE in config file
MX35: add support for flea3 board
MX25: tx25: Fix building due to missing MACH_TYPE
Wolfgang Grandegger (1):
mx5 configs: CONFIG_PRIME should really be CONFIG_ETHPRIME
MAINTAINERS |5 +
README |2 +-
arch/arm/cpu/arm1136/mx31/devices.c | 15 ++
arch/arm/cpu/arm1136/mx31/generic.c | 15 ++
arch/arm/cpu/arm1136/mx35/generic.c | 31 +++-
arch/arm/include/asm/arch-mx31/clock.h |2 +
arch/arm/include/asm/arch-mx31/imx-regs.h | 67 ++
arch/arm/include/asm/arch-mx35/imx-regs.h | 34 +++-
arch/arm/include/asm/arch-mx35/lowlevel_macro.S | 140 +++
arch/arm/include/asm/arch-mx35/mx35_pins.h |3 +
board/CarMediaLab/flea3/Makefile| 49
board/CarMediaLab/flea3/flea3.c | 289
+++
board/CarMediaLab/flea3/lowlevel_init.S | 79 ++
board/davedenx/qong/qong.c |8 +-
board/freescale/mx31pdk/mx31pdk.c | 12 +
board/freescale/mx35pdk/mx35pdk.h | 18 --
board/freescale/mx51evk/mx51evk.c | 17 +-
board/hale/tt01/Makefile| 51
board/hale/tt01/lowlevel_init.S | 32 +++
board/hale/tt01/tt01.c | 200
board/karo/tx25/tx25.c |1 -
board/ttcontrol/vision2/vision2.c |1 -
boards.cfg |2 +
drivers/i2c/mxc_i2c.c | 41 +++-
drivers/misc/pmic_fsl.c |5 +-
drivers/misc/pmic_spi.c |3 +-
drivers/rtc/Makefile|2 +-
drivers/rtc/{mc13783-rtc.c => mc13xxx-rtc.c}|0
include/configs/efikamx.h |2 +-
include/configs/flea3.h | 286
++
include/configs/imx31_litekit.h |2 +-
include/configs/mx31ads.h |2 +-
include/configs/mx31pdk.h |2 +-
include/configs/mx35pdk.h |2 +
include/configs/mx51evk.h | 14 +-
include/configs/mx53ard.h |2 +-
include/configs/mx53evk.h |2 +-
include/configs/mx53loco.h |2 +-
include/configs/mx53smd.h |2 +-
include/configs/qong.h | 36 ++--
include/configs/tt01.h | 254
include/configs/tx25.h |6 +
include/configs/vision2.h |5 +-
43 files changed, 1644 insertions(+), 99 deletions(-)
create mode 100644 arch/arm/include/asm/arch-mx35/lowlevel_macro.S
create mode 100644 board/CarMediaLab/flea3/Makefile
create mode 100644 board/CarMediaLab/flea3/flea3.c
create mode 100644 board/CarMediaLab/flea3/lowlevel_init.S
create mode 100644 board/hale/tt01/Makefile
create mode 100644 board/hale/tt01/lowlevel_init.S
create mode 100644 board/hale/tt01/tt01.c
rename drivers/rtc/{mc13783-rtc.c => mc13xxx-rtc.c} (100%)
create mode 100644 include/configs/flea3.h
create mode 100644 include/configs/tt01.h
Thanks,
Stefano
--
=
DENX Software Engineering GmbH, MD: Wolfgang D
Re: [U-Boot] Help starting u-boot on an at91sam9260ek
Hi Fabio, I believe the at91 U-Boot that Atmel publish has some patches applied. I don't know offhand what they were but it would be worth checking that these have made it into the current builds. http://www.at91.com/project-community/article/2-Projects/218-at91-u-boot -bootloader.html refers. Out of interest, have you had any problems with 2010q1 compiler? Atmel told me a while back they only advise the use of 2007q1. I found that later compilers gave problems, though I can't remember what they were now. Cheers John > -Original Message- > From: u-boot-boun...@lists.denx.de [mailto:u-boot- > boun...@lists.denx.de] On Behalf Of Fabio Porcedda > Sent: 28 October 2011 10:22 > To: u-boot@lists.denx.de > Subject: [U-Boot] Help starting u-boot on an at91sam9260ek > > Hi all, > i'm trying to use the u-boot on an at91sam9260ek board, > i cannot start successfull the u-boot binary. > > build u-boot 2011.09: > export CROSS_COMPILE=/opt/arm-2010q1/bin/arm-none-linux-gnueabi- > /MAKEALL at91sam9260ek_nandflash > > load & start: > RomBOOT > > > > U-Boot 1.3.4 (Mar 9 2010 - 19:29:50) > > DRAM: 64 MB > NAND: 256 MiB > DataFlash:AT45DB642 > Nb pages: 8192 > Page Size: 1056 > Size= 8650752 bytes > Logical address: 0xD000 > Area 0: D000 to D00041FF (RO) Bootstrap > Area 1: D0004200 to D00083FF Environment > Area 2: D0008400 to D0041FFF (RO) U-Boot > Area 3: D0042000 to D0251FFF Kernel > Area 4: D0252000 to D083 FS > In:serial > Out: serial > Err: serial > Net: macb0 > macb0: Starting autonegotiation... > macb0: Autonegotiation timed out (status=0x7849) > macb0: link down (status: 0x7849) > Hit any key to stop autoboot: 0 > U-Boot> loadb > ## Ready for binary (kermit) download to 0x2200 at 115200 bps... > > (Back at ld2036) > > > > > (/home/fabiopo/) C-Kermit>send u-boot.bin > (/home/fabiopo/) C-Kermit>connect > Connecting to /dev/ttyS0, speed 115200 > Escape character: Ctrl-\ (ASCII 28, FS): enabled > Type the escape character followed by C to get back, > or followed by ? to see other options. > > ## Total Size = 0x00029d68 = 171368 Bytes > ## Start Addr = 0x2200 > U-Boot> go 0x2200 > ## Starting application at 0x2200 ... > > > I don't have problems running the linux4sam u-boot binary, > using the same commands. > ftp://www.at91.com/pub/uboot/u-boot-1.3.4-exp.4/u-boot-1.3.4-exp.4- > at91sam9260ek-nandflash.bin > > I'm making something wrong? > Someone can help me? > > Thanks in advance for any help > Fabio Porcedda > > ___ > 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] RE
VIEW ATTACHMENT FOR DETAILS! INTERNATIONAL MONETARY FUND.docx Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] ARM: Update mach-types
On 10/28/2011 11:03 AM, Mike Frysinger wrote: > On Wed, Oct 19, 2011 at 08:31, Albert ARIBAUD wrote: >> Le 12/09/2011 05:54, Marek Vasut a écrit : >> > This commit updates the mach-types based on the latest in Linus's head >> >> Applied to u-boot-arm/master, thanks. > > so it's up to the respective board maintainers to fix all their boards > that are now build broken ? Yes, I think so. I have already fixed a couple of i.MX boards. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Help starting u-boot on an at91sam9260ek
Hi all, i'm trying to use the u-boot on an at91sam9260ek board, i cannot start successfull the u-boot binary. build u-boot 2011.09: export CROSS_COMPILE=/opt/arm-2010q1/bin/arm-none-linux-gnueabi- /MAKEALL at91sam9260ek_nandflash load & start: RomBOOT > U-Boot 1.3.4 (Mar 9 2010 - 19:29:50) DRAM: 64 MB NAND: 256 MiB DataFlash:AT45DB642 Nb pages: 8192 Page Size: 1056 Size= 8650752 bytes Logical address: 0xD000 Area 0: D000 to D00041FF (RO) Bootstrap Area 1: D0004200 to D00083FF Environment Area 2: D0008400 to D0041FFF (RO) U-Boot Area 3: D0042000 to D0251FFF Kernel Area 4: D0252000 to D083 FS In:serial Out: serial Err: serial Net: macb0 macb0: Starting autonegotiation... macb0: Autonegotiation timed out (status=0x7849) macb0: link down (status: 0x7849) Hit any key to stop autoboot: 0 U-Boot> loadb ## Ready for binary (kermit) download to 0x2200 at 115200 bps... (Back at ld2036) (/home/fabiopo/) C-Kermit>send u-boot.bin (/home/fabiopo/) C-Kermit>connect Connecting to /dev/ttyS0, speed 115200 Escape character: Ctrl-\ (ASCII 28, FS): enabled Type the escape character followed by C to get back, or followed by ? to see other options. ## Total Size = 0x00029d68 = 171368 Bytes ## Start Addr = 0x2200 U-Boot> go 0x2200 ## Starting application at 0x2200 ... I don't have problems running the linux4sam u-boot binary, using the same commands. ftp://www.at91.com/pub/uboot/u-boot-1.3.4-exp.4/u-boot-1.3.4-exp.4-at91sam9260ek-nandflash.bin I'm making something wrong? Someone can help me? Thanks in advance for any help Fabio Porcedda ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] ARM: Update mach-types
> On Wed, Oct 19, 2011 at 08:31, Albert ARIBAUD wrote: > > Le 12/09/2011 05:54, Marek Vasut a écrit : > > > This commit updates the mach-types based on the latest in Linus's head > > > > Applied to u-boot-arm/master, thanks. > > so it's up to the respective board maintainers to fix all their boards > that are now build broken ? there seems to be quite a few from > `./MAKEALL arm` ... > -mike Hi Mike, yes, fix or be removed. Cheers ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] ARM: Update mach-types
On Wed, Oct 19, 2011 at 08:31, Albert ARIBAUD wrote: > Le 12/09/2011 05:54, Marek Vasut a écrit : > > This commit updates the mach-types based on the latest in Linus's head > > Applied to u-boot-arm/master, thanks. so it's up to the respective board maintainers to fix all their boards that are now build broken ? there seems to be quite a few from `./MAKEALL arm` ... -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: bootp: fix warning when CONFIG_BOOTP_SERVERIP is set
Signed-off-by: Stefano Babic
CC: Wolfgang Denk
---
net/bootp.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/bootp.c b/net/bootp.c
index b789eec..b446521 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -105,7 +105,9 @@ static int BootpCheckPkt(uchar *pkt, unsigned dest,
unsigned src, unsigned len)
*/
static void BootpCopyNetParams(Bootp_t *bp)
{
+#if !defined(CONFIG_BOOTP_SERVERIP)
IPaddr_t tmp_ip;
+#endif
NetCopyIP(&NetOurIP, &bp->bp_yiaddr);
#if !defined(CONFIG_BOOTP_SERVERIP)
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 2/3] mx31: add ESD control registers
On 10/27/2011 01:31 PM, Helmut Raiger wrote: > This allows to initialize DDR memory in C code. > Currently all mx31 boards use assembler code (lowlevel_init.S) > > Signed-off-by: Helmut Raiger > --- > V2: new in V2 > V3: no changes > > arch/arm/include/asm/arch-mx31/imx-regs.h | 13 + > 1 files changed, 13 insertions(+), 0 deletions(-) > Applied to u-boot-imx, 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-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V3 1/3] mx31: define pins and init for UART2 and CSPI3
On 10/27/2011 01:31 PM, Helmut Raiger wrote: > Signed-off-by: Helmut Raiger > --- > V2: no changes since V1 > V3: fixed multiline comment, rebased to u-boot-imx > > arch/arm/cpu/arm1136/mx31/devices.c | 15 +++ > arch/arm/include/asm/arch-mx31/clock.h|1 + > arch/arm/include/asm/arch-mx31/imx-regs.h | 16 > 3 files changed, 32 insertions(+), 0 deletions(-) > > diff --git a/arch/arm/cpu/arm1136/mx31/devices.c > b/arch/arm/cpu/arm1136/mx31/devices.c > index 1e7d48f..b42dac3 100644 > --- a/arch/arm/cpu/arm1136/mx31/devices.c > +++ b/arch/arm/cpu/arm1136/mx31/devices.c > @@ -38,7 +38,22 @@ void mx31_uart1_hw_init(void) > } > #endif Applied to u-boot-imx, 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-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MX25: tx25: Fix building due to missing MACH_TYPE
Added MACH_TYPE for the tx25 to the configuration file. The MACH_TYPE is dropped from mach-types.h after last sync with kernel. Signed-off-by: Stefano Babic --- board/karo/tx25/tx25.c |1 - include/configs/tx25.h |6 ++ 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/board/karo/tx25/tx25.c b/board/karo/tx25/tx25.c index d3d8ea5..2a29943 100644 --- a/board/karo/tx25/tx25.c +++ b/board/karo/tx25/tx25.c @@ -140,7 +140,6 @@ int board_init() mx25_uart1_init_pins(); #endif /* board id for linux */ - gd->bd->bi_arch_number = MACH_TYPE_TX25; gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100; return 0; } diff --git a/include/configs/tx25.h b/include/configs/tx25.h index 8cb57ff..f77c546 100644 --- a/include/configs/tx25.h +++ b/include/configs/tx25.h @@ -34,6 +34,12 @@ /* NAND BOOT is the only boot method */ #define CONFIG_NAND_U_BOOT +#ifndef MACH_TYPE_TX25 +#define MACH_TYPE_TX25 2177 +#endif + +#define CONFIG_MACH_TYPE MACH_TYPE_TX25 + #ifdef CONFIG_NAND_SPL /* Start copying real U-boot from the second page */ #define CONFIG_SYS_NAND_U_BOOT_OFFS0x800 -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] please pull u-boot-samsung/master
Dear Albert,
The following changes since commit 37fc0ed268dc5acacd3a83adafa26eb1a84e90af:
ARM: Add Calxeda Highbank platform (2011-10-27 21:56:37 +0200)
are available in the git repository at:
git://git.denx.de/u-boot-samsung master
Angus Ainslie (2):
ORIGEN : enable device tree support
ORIGEN : use absolute paths and fix tool naming
Chander Kashyap (4):
SMDKV310: Initialize board id using CONFIG_MACH_TYPE
SMDKV310: use get_ram_size() to validate dram size
smdkv310: use spl framework for mmc spl
smdkv310: use macro for mmc data read function address
Łukasz Majewski (3):
dcache:s5p CONFIG_SYS_CACHELINE_SIZE added for s5p GONI target
dcache:s5p CONFIG_SYS_CACHELINE_SIZE added for s5p UNIVERSAL C210 target
misc:pmic:samsung Enable PMIC driver at C210 Universal target
board/samsung/origen/Makefile |6 +-
board/samsung/smdkv310/Makefile| 19 -
.../board => board}/samsung/smdkv310/mmc_boot.c| 15 ++--
board/samsung/smdkv310/smdkv310.c | 13 ++-
.../samsung/smdkv310/tools/mkv310_image.c |0
board/samsung/universal_c210/universal.c |5 +
include/configs/origen.h |3 +
include/configs/s5p_goni.h |2 +
include/configs/s5pc210_universal.h| 19
include/configs/smdkv310.h |8 ++-
mmc_spl/board/samsung/smdkv310/Makefile| 106
mmc_spl/board/samsung/smdkv310/u-boot.lds | 88
spl/Makefile |2 +-
13 files changed, 74 insertions(+), 212 deletions(-)
rename {mmc_spl/board => board}/samsung/smdkv310/mmc_boot.c (83%)
rename {mmc_spl/board => board}/samsung/smdkv310/tools/mkv310_image.c (100%)
delete mode 100644 mmc_spl/board/samsung/smdkv310/Makefile
delete mode 100644 mmc_spl/board/samsung/smdkv310/u-boot.lds
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] misc:pmic:samsung Enable PMIC driver at C210 Universal target
Dear Lukasz Majewski, On 10/27/2011 05:33 PM, Lukasz Majewski wrote: > Enable support for PMIC driver at C210 Universal reference target. > > Signed-off-by: Lukasz Majewski > Signed-off-by: Kyungmin Park > Cc: Minkyu Kang > --- > Depend on: "New generic PMIC framework" > > http://patchwork.ozlabs.org/patch/118071/ > http://patchwork.ozlabs.org/patch/117565/ > http://patchwork.ozlabs.org/patch/117563/ > > ./tools/checkpatch.pl - > total: 0 errors, 0 warnings, 38 lines checked > --- > board/samsung/universal_c210/universal.c |5 + > include/configs/s5pc210_universal.h | 17 + > 2 files changed, 22 insertions(+), 0 deletions(-) > applied to u-boot-samsung. Thanks. Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] lib/string: memmove: use memcpy if it is safe to do so
memmove is used in a number of performance critical places, like copying the
linux kernel from nor flash to ram, so optimizing it can be interesting.
Unfortunately, an arch specific version of memmove often isn't used, and
not supported at all on a number of archs (arm/mips/nds32/nios2/x86) -
But memcpy typically is.
Often memmove is called for copies where src/dest don't overlap, so we
could use the more efficient memcpy instead. Detect these situations and
forward those request to memcpy instead.
Adds 40 bytes to memmove and speeds up boot with ~300ms on a 400MHz arm9.
Signed-off-by: Peter Korsgaard
---
lib/string.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/lib/string.c b/lib/string.c
index 2c4f0ec..239cc11 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -504,12 +504,16 @@ void * memmove(void * dest,const void *src,size_t count)
return dest;
if (dest <= src) {
+ if (dest + count <= src)
+ return memcpy(dest, src, count);
tmp = (char *) dest;
s = (char *) src;
while (count--)
*tmp++ = *s++;
}
else {
+ if (src + count <= dest)
+ return memcpy(dest, src, count);
tmp = (char *) dest + count;
s = (char *) src + count;
while (count--)
--
1.7.6.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm:exynos4:samsung Support for NURI target
Dear Lukasz Majewski,
On 10/20/2011 05:07 PM, Lukasz Majewski wrote:
> This patch adds support for Samsung's Exynos4 (C210) Nuri reference
> board.
>
> New exynos4_nuri board has been added to boards.cfg
>
> Signed-off-by: Lukasz Majewski
> Signed-off-by: Kyungmin Park
> Cc: Minkyu Kang
> ---
> Checkpatch output:
> total: 0 errors, 0 warnings, 891 lines checked
> ---
> board/samsung/nuri/Makefile| 45
> board/samsung/nuri/lowlevel_init.S | 395
>
> board/samsung/nuri/nuri.c | 237 +
> boards.cfg |1 +
> include/configs/exynos4_nuri.h | 207 +++
> 5 files changed, 885 insertions(+), 0 deletions(-)
> create mode 100644 board/samsung/nuri/Makefile
> create mode 100644 board/samsung/nuri/lowlevel_init.S
> create mode 100644 board/samsung/nuri/nuri.c
> create mode 100644 include/configs/exynos4_nuri.h
You missing MAINTAINER entry.
>
> diff --git a/board/samsung/nuri/nuri.c b/board/samsung/nuri/nuri.c
> new file mode 100644
> index 000..6cf126b
> --- /dev/null
> +++ b/board/samsung/nuri/nuri.c
> @@ -0,0 +1,237 @@
> +/*
> + * Copyright (C) 2011 Samsung Electronics
> + * Minkyu Kang
> + * Kyungmin Park
> + * Łukasz Majewski
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +DECLARE_GLOBAL_DATA_PTR;
> +
> +struct s5pc210_gpio_part1 *gpio1;
> +struct s5pc210_gpio_part2 *gpio2;
> +unsigned int board_rev;
> +
> +u32 get_board_rev(void)
> +{
> + return board_rev;
> +}
> +
> +static void check_hw_revision(void);
> +
> +int board_init(void)
> +{
> + gpio1 = (struct s5pc210_gpio_part1 *) S5PC210_GPIO_PART1_BASE;
> + gpio2 = (struct s5pc210_gpio_part2 *) S5PC210_GPIO_PART2_BASE;
> +
> + gd->bd->bi_arch_number = MACH_TYPE_UNIVERSAL_C210;
no need.
please define CONFIG_MACH_TYPE on exynos4_nuri.h.
> + gd->bd->bi_boot_params = PHYS_SDRAM_1 + 0x100;
> +
> + check_hw_revision();
> + printf("HW Revision:\t0x%x\n", board_rev);
> +
> + return 0;
> +}
> +
> +int dram_init(void)
> +{
> + gd->ram_size = \
> + get_ram_size((long *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE) +
> + get_ram_size((long *)PHYS_SDRAM_2, PHYS_SDRAM_2_SIZE) +
> + get_ram_size((long *)PHYS_SDRAM_3, PHYS_SDRAM_3_SIZE) +
> + get_ram_size((long *)PHYS_SDRAM_4, PHYS_SDRAM_4_SIZE);
> +
> + return 0;
> +}
> +
> +void dram_init_banksize(void)
> +{
> + gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
> + gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
> + gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
> + gd->bd->bi_dram[1].size = PHYS_SDRAM_2_SIZE;
> + gd->bd->bi_dram[2].start = PHYS_SDRAM_3;
> + gd->bd->bi_dram[2].size = PHYS_SDRAM_3_SIZE;
> + gd->bd->bi_dram[3].start = PHYS_SDRAM_4;
> + gd->bd->bi_dram[3].size = PHYS_SDRAM_4_SIZE;
> +}
> +
> +static unsigned short get_adc_value(int channel)
> +{
> + struct s5p_adc *adc = (struct s5p_adc *)samsung_get_base_adc();
> + unsigned short ret = 0;
> + unsigned int reg;
> + unsigned int loop = 0;
> +
> + writel(channel & 0xF, &adc->adcmux);
> + writel((1 << 14) | (49 << 6), &adc->adccon);
> + writel(1000 & 0x, &adc->adcdly);
> + writel(readl(&adc->adccon) | (1 << 16), &adc->adccon); /* 12 bit */
> + udelay(10);
> + writel(readl(&adc->adccon) | (1 << 0), &adc->adccon); /* Enable */
> + udelay(10);
We don't allow magic values.
Please fix it.
> +
> + do {
> + udelay(1);
> + reg = readl(&adc->adccon);
> + } while (!(reg & (1 << 15)) && (loop++ < 1000));
ditto.
> +
> + ret = readl(&adc->adcdat0) & 0xFFF;
> +
> + return ret;
> +}
> +
> +static unsigned int get_hw_revision(void)
> +{
> + int hwrev, mode0, mode1;
> +
> + mode0 = get_adc_value(1); /* HWREV_MODE0 */
> + mode1 = get_adc_value(2); /* HWREV_MODE1 */
> +
> + /*
> + * XXX Always set the default hwrev as the latest board
> + * ADC = (voltage) / 3.3 * 4096
> + */
> + hwrev = 3;
> +
> +#define IS_RANGE(x, m
Re: [U-Boot] [PATCH 2/2] Powerpc/i2c: Force i2c to become bus master out of reset
Thanks and Best Regards Jerry Huang > -Original Message- > From: Heiko Schocher [mailto:h...@denx.de] > Sent: Friday, October 28, 2011 2:34 PM > To: Huang Changming-R66093 > Cc: Joakim Tjernlund; u-boot@lists.denx.de > Subject: Re: [U-Boot] [PATCH 2/2] Powerpc/i2c: Force i2c to become bus > master out of reset > > Hello Huang Changming-R66093, > > Huang Changming-R66093 wrote: > >>> These tow part codes are doing the different thing due to the > >> different reason: > >>> 1. Kernel's code: > >>> because Sometimes 9th clock pulse isn't generated, that code is to > >> generate the 9th clock pulse. > >> > >> What code are you looking at? Are you just reading the comment? > >> Look at http://git.kernel.org/?p=linux/kernel/git/next/linux- > >> next.git;a=commit;h=0c2daaafcdec726e89cbccca61d576de8429c537 > >> to get a clue. > >> > >> Your code isn't complete, you cannot trust the manual to be the > whole > >> truth. > >> > > I am very confused, why do you always say my code isn't complete? > > Because it is not complete? I don't think it is not complete, because this patch resolves my issue. > > I have described I want to do detailed in comment. > > "when a system reset does not cause all I2C devices to be reset", > > You wrote: > "So, the kernel's patch and my patch is to resolve the different > issue." > > Yes! There are more "problems" on i2c bus, as also Joakim described! > And if we try to fix them in the common driver (as you did), we should > fix all known problems -> so your patch is incomplete. Yes, we should fix all known problems, but we should not hope one patch includes everything. it make sense for one patch to resolve one thing, instead of all. > > My codes will force the I2c module to become bus master and drive SCL, > > which force this i2c module to generate SCL so that the device > driving SDA can finish its transaction. > > These codes have been used on Emerson's P1022 board and resolved his > > issue (board will hang when u-boot booting, with my codes, this issue > > is resolved and board can boot well) > > Then you maybe define CONFIG_SYS_I2C_BOARD_LATE_INIT for this board and > do this in board code. I have pointed out, this is one feature of FSL I2C module and almost cover all 85xx platform, we provides one solution to resolve the i2c bus "reset" issue. So I think it is not necessary to define one macro for one special board. > > This is one feature of FSL I2C almost cover all 85xx platform, and > the code according to the RM has been verified, don't you think the > manual can be trust? > > See (for example on a mpc83xx based board) > board/keymile/common/common.c functions i2c_write_start_seq() and > i2c_make_abort() which solve also a deblocked i2c bus ... and they > started with the procedure noted in the RM, but this didn't solved all > issues for them. > > > Below is the description from your link: > > This patch improves the recovery of the MPC's I2C bus from errors > like > > bus hangs resulting in timeouts: > > 1. make the bus timeout configurable, as it depends on the bus clock > and > > the attached slave chip(s); default is still 1 second; 2. detect > > any of the cases indicated by the CF, BB and RXAK MSR flags if a > > timeout occurs, and add a missing (required) MAL reset; 3. use a > > more reliable method to fixup the bus if a hang has been detected. > > The sequence is sent 9 times which seems to be necessary if a > slave > > "misses" more than one clock cycle. For 400 kHz bus speed, the > fixup is > > also ~70us (81us vs. 150us) faster. > > > > This patch is created because a slave miss more than one clock cycle > and can resolve this issue. > > > > So, the kernel's patch and my patch is to resolve the different issue. > > Yes, and if editing a common driver, we should find a solution which > fit for all ... did you tried the linux driver code for your board? > Maybe it solves your problem too? So we can adapt it to u-boot code? > I can't try the Linux driver on my boards, because all boards on my hand has not these two i2c issue. These codes is generated according to FSL Reference Manual, if you check the RM of FSL, you will find out all 85xx chips(now I know) support this feature. And these code can be work on Emerson's p1022 board, if the code according to the RM can work, I don't think I have any reason to ask customer to use the other codes. And the solution RM provide can resolve the issue, why don't we trust the RM? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net, davinci_emac: fix compiler error
Heiko,
Thank you very much for identifying it and sending across a patch.
I was about to send the patch :)
Regards
--Manju
On Fri, Oct 28, 2011 at 11:29:03, Heiko Schocher wrote:
> This patch fixes following compile error for the davinice_emac driver:
>
> $ make -s cam_enc_4xx
> Configuring for cam_enc_4xx board...
> Generating include/generated/asm-offsets.h
> davinci_emac.c: In function 'davinci_emac_initialize':
> davinci_emac.c:817:3: error: request for member 'name' in something not a
> structure or union
> make[2]: *** [davinci_emac.o] Fehler 1
> make[1]: *** [drivers/net/libnet.o] Fehler 2
> make: *** [cam_enc_4xx] Fehler 2
> [hs@pollux u-boot]$
>
> introduced through commit:
> 062fe7d332c28ede25626f448681e43d76bb312e
>
> Signed-off-by: Heiko Schocher
> Cc: Manjunath Hadli
> Cc: Albert ARIBAUD
> Cc: Sandeep Paulraj
> Cc: Ben Warren
> ---
> drivers/net/davinci_emac.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c index
> e864a41..fa31159 100644
> --- a/drivers/net/davinci_emac.c
> +++ b/drivers/net/davinci_emac.c
> @@ -814,7 +814,7 @@ int davinci_emac_initialize(void)
> phy[i].auto_negotiate = gen_auto_negotiate;
> }
>
> - debug("Ethernet PHY: %s\n", phy.name);
> + debug("Ethernet PHY: %s\n", phy[i].name);
>
> miiphy_register(phy[i].name, davinci_mii_phy_read,
> davinci_mii_phy_write);
> --
> 1.7.6.4
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Nios] New Nios Custodian
On 10/28/2011 12:56 PM, 馬克泡 wrote: > Hi Scott and Thomas, > > 2011/10/28 Scott McNutt: >> Dear u-boot Nios Developers, >> >> Please welcome Thomas Chou as our new Nios custodian. >> >> Over the past several months, my personal work load has >> increased significantly. While this is great for me >> both professionally and personally, it interferes with >> my open source activity. In the best interest of the project, >> I am very pleased to place the Nios custodian responsibilities >> in Thomas' capable hands. He is an excellent Nios developer >> and he continues to make significant contributions. >> >> Best Regards, >> --Scott >> > > Nice to meed Thomas, I guess you also live in Taiwan. > Its good to see another contributor here in u-boot project. > Thanks for the contributions from Scott and Thomas. > Best thanks for McNutt's constant contribution to Nios community. And nice to meet macpaul. I live in Taipei, Taiwan. Best regards, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v2] board/nios2-generic: Use altera_pio driver and remove board specific driver
On 10/21/2011 09:48 PM, Joachim Foerster wrote: > Signed-off-by: Joachim Foerster > --- > board/altera/nios2-generic/Makefile |1 - > board/altera/nios2-generic/gpio.c | 71 > --- > include/configs/nios2-generic.h |4 ++ > 3 files changed, 4 insertions(+), 72 deletions(-) > delete mode 100644 board/altera/nios2-generic/gpio.c Hi Joachim, Applied. Thanks. Best regards, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v2] gpio: Add driver for Altera's PIO core
On 10/21/2011 09:48 PM, Joachim Foerster wrote: > This driver may handle multiple PIO cores and thus needs to be > setup by calling the altera_pio_init() function within the early > board setup routine. > > The driver comes with some extras, see below the copyleft header. > > Signed-off-by: Joachim Foerster > Tested-by: Thomas Chou > --- > arch/nios2/include/asm/gpio.h | 13 +- > board/altera/nios2-generic/custom_fpga.h |1 + > board/altera/nios2-generic/nios2-generic.c |8 + > drivers/gpio/Makefile |1 + > drivers/gpio/altera_pio.c | 299 > > 5 files changed, 320 insertions(+), 2 deletions(-) > create mode 100644 drivers/gpio/altera_pio.c Hi Joachim, Applied. Thanks. Best regards, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] nios2: Pseudo implement dcache_status/enable/disable()
On 10/20/2011 04:28 PM, Joachim Foerster wrote: > AFAIK the NIOS2 architecture does not have any possibility to > dynamically switch off the data cache. So _status() always reports 1 and > _enable/_disable() just issue a flush of everything. > > For example, common/cmd_elf.c depends on these symbols. > > Signed-off-by: Joachim Foerster > --- > Changes for v3: > - #include proper header file for flush_dcache() > Changes for v2: > - Remove return; from added void functions > > arch/nios2/cpu/cpu.c | 16 > 1 files changed, 16 insertions(+), 0 deletions(-) > Hi Joachim, Applied. Thanks. Best regards, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
