Dear Tom, dear Jean-Christophe,
Tom wrote:
> Dirk Behme wrote:
>> Hi Tom,
>>
>> Tom wrote:
>>> Here is the changes to Zoom2 to rebase onto the arm/next branch
>>
>> I'm not sure and and didn't test it, but it seems to me that we might
>> get some conflicts with patches in arm/master branch and th
Dear Wolfgang,
Wolfgang Denk wrote:
> Dear Dirk Behme,
>
> In message <49f9f000.2060...@googlemail.com> you wrote:
>> Short status update after recent ARM pull request
>
> Thanks for keeping the summary up to date. This is really helpful in
> this complicated situation.
>
>
1. OMAP3: Beag
Shinya Kuribayashi wrote:
> As for my hardware, however, this still doesn't work. My processor
> (MIPS 4KEc) of couse supports byte read/write, on the other hand,
> the address decoder at UART module can not handle byte addresses
> properly; all byte read/write accesses with +1/+2/+3 offset, will
>
Hi Jerry-san,
Jerry Van Baren wrote:
>>> I might be unclear. I used to use REG_SIZE = -16, as 16550 registers
>>> are located at 0, +0x10, +0x20, ..., .
>
> 16 byte stride. That is seriously odd.
Well, 8 or 16 byte stride is not so odd, IMHO.
>>> I don't know much about precise hardware logics
Hi,
Detlev Zundel wrote:
>>> I see. Actually I was looking a lot at the Linux driver but was hoping
>>> that we could away without introducing serial_{in,out}...
>> In my horrible opinion, the combinations of base addres + reg_shift
>> + iotype (char, long, or whatever), are simpler, more configu
On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> cpu.c will be better
Here's a followup patch that applies on top of this one,
and creates the cpu.c you wanted.
=== CUT HERE
From: David Brownell
Move the clock-rate dumping code into the cpu/.../davinci area
where it should
On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> too long please split
Update below.
=== CUT HERE
From: David Brownell
This updates the optional (non-default!) NAND support for the
DaVinci DM6446 EVM:
- include MTD partitioning, defaulting to what Linux uses
- use a fla
Hi,
Detlev Zundel wrote:
> Thinking about it some more, I wonder about the following. You said,
> this would work for you:
>
> struct NS16550 {
>unsigned long rbr;
>unsigned long postpad_rbr[3];
>
>
> while
>
> struct NS16550 {
>unsigned char rbr;
>unsigned
Derek Ou wrote:
> Hi, Ben,
>
> Ben Warren wrote:
>> Do you have CONFIG_RESET_PHY_R defined? It forces a call to
>> eth_init(), which most likely causes the delay you're seeing. Try
>> commenting it out in your config file.
> Yes, CONFIG_RESET_PHY_R is defined by default. And I can see it
> li
On Fri, May 01, 2009 at 12:31:54AM +0200, Wolfgang Denk wrote:
> Dear Anton,
>
> In message <20090429215000.ga1...@oksana.dev.rtsoft.ru> you wrote:
> > This patch implements simple hwconfig infrastructure: an
> > interface for software knobs to control a hardware.
>
> Thanks a lot.
>
> > 3. We s
Hi, Ben,
Ben Warren wrote:
> Do you have CONFIG_RESET_PHY_R defined? It forces a call to eth_init(),
> which most likely causes the delay you're seeing. Try commenting it out
> in your config file.
Yes, CONFIG_RESET_PHY_R is defined by default. And I can see it linking to
the eth_init and the
Dear Kyungmin,
currently the "apollon" board does not build any more, because there
is no definition of CONFIG_SYS_MONITOR_LEN in th eboard config file.
I was tempted just to add one, and define it as 128 kB according to
the mtdparts configuration at the bottom of the board config file, but
the r
Dear Anton,
In message <20090429215000.ga1...@oksana.dev.rtsoft.ru> you wrote:
> This patch implements simple hwconfig infrastructure: an
> interface for software knobs to control a hardware.
Thanks a lot.
> 3. We support hwconfig options with arguments. For example,
>
>set hwconfig dr_usb,
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
---
cpu/arm720t/Makefile |4 +-
cpu/arm720t/s3c4510b/Makefile |1 +
cpu/arm720t/s3c4510b/interrupts.c | 85 +
cpu/arm720t/{interrupts.c => timer.c} | 74 ---
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
---
cpu/arm720t/lpc2292/Makefile | 15 +
cpu/arm720t/lpc2292/interrupts.c | 41 ++
cpu/arm720t/timer.c | 12 ---
3 files changed, 51 insertions(+), 17 deletions(-)
creat
all arm init the IRQ stack the same way
so unify it in lib_arm/interrupts.c and then call arch specific interrupt init
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
---
cpu/arm1136/cpu.c| 11 ---
cpu/arm720t/cpu.c|7 ---
cpu/arm720t/interrupts.c |
move s3c44b0 to arch_cpu_init and as noone use cpu_init remove it
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD
---
cpu/arm1136/cpu.c |5 -
cpu/arm1176/cpu.c |5 -
cpu/arm720t/cpu.c |5 -
cpu/arm920t/cpu.c |5 -
cpu/arm925t/cpu.c |5
Dear Dirk Behme,
In message <49f9f000.2060...@googlemail.com> you wrote:
>
> Short status update after recent ARM pull request
Thanks for keeping the summary up to date. This is really helpful in
this complicated situation.
> >> 1. OMAP3: Beagle: Set pinmux conditionally for Rev C boards
> >>
Dear Dirk Behme,
In message <1240327745-8917-1-git-send-email-dirk.be...@googlemail.com> you
wrote:
> From: Manikandan Pillai
> Signed-off-by: Dirk Behme
> Signed-off-by: Manikandan Pillai
> ---
> Changes in v3 which replaces previous version [3]:
>
> * Fix udelay(), too
> * Fix and use TIMER
On Thu, Apr 30, 2009 at 3:36 PM, Matthew L. Creech wrote:
>
> The problem I'm currently running into is step 2, which throws an
> error in ubi_io_write() (see below). Googling around turned up a few
> hits that suggested turning off sub-page writes, so I tried adding
> NAND_NO_SUBPAGE_WRITE to NA
Dear Derek Ou,
In message <49fa1279.5080...@siconix.com> you wrote:
>
> When we have the Network support compiled, it takes a few second to do
> the auto-negotiation
That should be part of the network init sequence, which should only be
run when you run a network command.
> even though MAC chip
Derek Ou wrote:
> Wolfgang Denk wrote:
>
>> Dear Derek Ou,
>>
>> In message <49fa1279.5080...@siconix.com> you wrote:
>>
>>
>>> When we have the Network support compiled, it takes a few second to do
>>> the auto-negotiation
>>>
>>>
>> That should be part of the network init
Wolfgang Denk wrote:
> Dear Derek Ou,
>
> In message <49fa1279.5080...@siconix.com> you wrote:
>
>> When we have the Network support compiled, it takes a few second to do
>> the auto-negotiation
>>
> That should be part of the network init sequence, which should only be
> run when you run
Derek Ou wrote:
> Wolfgang Denk wrote:
>
>> Why would compiled in Network support slow down the boot process?
>>
>> The network interface will only be initialized as soon as you use it.
>> If you don't have one, then you probably will not try using it - then
>> why would it delay your boot?
>>
Dear Jean-Christophe PLAGNIOL-VILLARD,
In message <20090430071035.ge31...@game.jcrosoft.org> you wrote:
>
> Please pull
> The following changes since commit 4277f4de065b4daea4dc27420fc1bc131701291d:
> Wolfgang Denk (1):
> Merge branch 'master' of git://git.denx.de/u-boot-net
>
> are a
Wolfgang Denk wrote:
> Why would compiled in Network support slow down the boot process?
>
> The network interface will only be initialized as soon as you use it.
> If you don't have one, then you probably will not try using it - then
> why would it delay your boot?
>
When we have the Network su
Dear Stefan Roese,
In message <200904291109.32226...@denx.de> you wrote:
>
> please pull one patch which I missed pushing:
>
> The following changes since commit 4d9eab89b3b2c2ed432b14d355a56f274d8aac75:
> Wolfgang Denk (1):
> cmd_ext2.c: fix compile warnings
>
> are available in the
Dear Anatolij Gustschin,
In message <49f6c68d.9040...@denx.de> you wrote:
> Dear Wolfgang,
>
> The following changes since commit 28afe0160f87ff74574150d703055a965f91422a:
> Heiko Schocher (1):
> ids8247: Remove legacy NAND defines
>
> are available in the git repository at:
>
> git
Dear Derek Ou,
In message <49fa0922.2000...@siconix.com> you wrote:
>
> Other than recompiling, is it possible to disable Ethernet through
> environment settings? At our
No.
> work, we often need Ethernet only during development, manufacturing and
> troubleshooting. So
> we put the Ethernet
Hi,
> Is existing a way to globally disable some features such as ethernet
> or Nand support, instead of doing it for a specific board?
>
Other than recompiling, is it possible to disable Ethernet through
environment settings? At our
work, we often need Ethernet only during development, manufa
Hi
2009/4/30 alfred steele :
> Hi
>> That's fine.
>> Which linker script gets actually used for the layout in in case of
>> nand_spl. Is it u-boot-nand.lds or u-boot.lds.?
>
> I am going back to the original intent of this thread, booting off the
> linux kernel using TFTP. Here's is a dump of my
Dirk Behme wrote:
> Hi Tom,
>
> Tom wrote:
>> Here is the changes to Zoom2 to rebase onto the arm/next branch
>
> I'm not sure and and didn't test it, but it seems to me that we might
> get some conflicts with patches in arm/master branch and these against
> arm/next.
>
> With Premi's patch that
On Thu, Apr 30, 2009 at 03:00:50PM -0500, Kim Phillips wrote:
> On Thu, 30 Apr 2009 01:50:00 +0400
> Anton Vorontsov wrote:
>
> > This patch implements simple hwconfig infrastructure: an
> > interface for software knobs to control a hardware.
> >
> > This is very simple implementation, i.e. it i
On Thu, Apr 30, 2009 at 02:59:37PM -0500, Kim Phillips wrote:
> On Thu, 30 Apr 2009 23:35:34 +0400
> Anton Vorontsov wrote:
>
> > What if there is some errata in 8377 chip (with 1.0 revision), and
> > not in 8378 chip (also 1.0 revision)?
>
> I believe they are in fact the same chip, just with d
Hi
> That's fine.
> Which linker script gets actually used for the layout in in case of
> nand_spl. Is it u-boot-nand.lds or u-boot.lds.?
I am going back to the original intent of this thread, booting off the
linux kernel using TFTP. Here's is a dump of my U-boot env. Does
it look good enough
On Thu, 30 Apr 2009 01:50:00 +0400
Anton Vorontsov wrote:
> This patch implements simple hwconfig infrastructure: an
> interface for software knobs to control a hardware.
>
> This is very simple implementation, i.e. it is implemented
> via `hwconfig' environment variable. Later we could write
>
On Thu, 30 Apr 2009 23:39:11 +0400
Anton Vorontsov wrote:
> On Thu, Apr 30, 2009 at 11:35:34PM +0400, Anton Vorontsov wrote:
> > On Thu, Apr 30, 2009 at 02:28:52PM -0500, Kim Phillips wrote:
> > > On Thu, 30 Apr 2009 22:59:59 +0400
> > > Anton Vorontsov wrote:
> > >
> > > > On Thu, Apr 30, 2009
On Thu, 30 Apr 2009 23:35:34 +0400
Anton Vorontsov wrote:
> What if there is some errata in 8377 chip (with 1.0 revision), and
> not in 8378 chip (also 1.0 revision)?
I believe they are in fact the same chip, just with different fuses
blown.
> IMO prefix is more specific than a block revision.
Hi Magnus,
> I need more time to post the patches since I'm taking care of some
> comments that were posted to Maxim's patches (which I'm using as a
> base).
That's fine.
Which linker script gets actually used for the layout in in case of
nand_spl. Is it u-boot-nand.lds or u-boot.lds.?
Thanks.
_
On Thu, Apr 30, 2009 at 11:35:34PM +0400, Anton Vorontsov wrote:
> On Thu, Apr 30, 2009 at 02:28:52PM -0500, Kim Phillips wrote:
> > On Thu, 30 Apr 2009 22:59:59 +0400
> > Anton Vorontsov wrote:
> >
> > > On Thu, Apr 30, 2009 at 12:57:52PM -0500, Scott Wood wrote:
> > > > On Thu, Apr 30, 2009 at
Hi, I'm using the latest U-Boot GIT snapshot (4/28), and trying to get
UBI/UBIFS working. I'm wondering what the current status of UBI
support in U-Boot is, and whether what I'm doing will work.
The goal is to get a single R/W filesystem on a large NAND partition.
If I understand correctly, I sho
On Thu, Apr 30, 2009 at 02:28:52PM -0500, Kim Phillips wrote:
> On Thu, 30 Apr 2009 22:59:59 +0400
> Anton Vorontsov wrote:
>
> > On Thu, Apr 30, 2009 at 12:57:52PM -0500, Scott Wood wrote:
> > > On Thu, Apr 30, 2009 at 01:20:11AM +0400, Anton Vorontsov wrote:
> > > > > Isn't there a more global
On Thu, 30 Apr 2009 22:59:59 +0400
Anton Vorontsov wrote:
> On Thu, Apr 30, 2009 at 12:57:52PM -0500, Scott Wood wrote:
> > On Thu, Apr 30, 2009 at 01:20:11AM +0400, Anton Vorontsov wrote:
> > > > Isn't there a more global means of doing this? I don't like having
> > > > the 8536/8379 in the dri
On Thu, Apr 30, 2009 at 12:57:52PM -0500, Scott Wood wrote:
> On Thu, Apr 30, 2009 at 01:20:11AM +0400, Anton Vorontsov wrote:
> > > Isn't there a more global means of doing this? I don't like having
> > > the 8536/8379 in the driver, itself.
> >
> > But that's how we prefer bindings nowadays.
>
Hi Tom,
Tom wrote:
> Here is the changes to Zoom2 to rebase onto the arm/next branch
I'm not sure and and didn't test it, but it seems to me that we might
get some conflicts with patches in arm/master branch and these against
arm/next.
With Premi's patch that removes unused board-types
http:/
Dirk Behme wrote:
> Sanjeev Premi wrote:
>> This series contains 3 specific updates:
>> - Use common API to print cpu and board
>>related information.
>> - Remove unused board type definitions.
>> - Print correct silicon revision in the
>>board information.
>>
>> This series fixes the co
Short status update after recent ARM pull request
http://lists.denx.de/pipermail/u-boot/2009-April/051803.html
Dirk Behme wrote:
>> To avoid loosing the overview, here my list of pending OMAP3 patches
>> ready to be applied. From my point of view there are no open comments
>> on these which wi
On Thu, Apr 30, 2009 at 01:20:11AM +0400, Anton Vorontsov wrote:
> > Isn't there a more global means of doing this? I don't like having
> > the 8536/8379 in the driver, itself.
>
> But that's how we prefer bindings nowadays.
Block version numbers are better, if available.
> > Actually, there is
Detlev Zundel wrote:
> Hi Jerry,
>
>> Detlev Zundel wrote:
>>> Hello Shinya,
>>>
Detlev Zundel wrote:
> As I said, I understand now why there were different data-types involved
> although this was kind of non-obvious. So I take it, you had a working
> configuration with REG_SIZE
Dear Marc Leeman,
In message <1f729c480904300627r5661774ej7d2cf5a19bee1...@mail.gmail.com> you
wrote:
>
> IIRC, I tried to stick as close to the fw_Xenv code structure as possible;
> as such, this basically copies the fw_setenv block and modifies it without
> interfering or breaking in the upstr
> Have you got a chance to post the patches to the mainline yet?
No, but as I stated earlier the only merge problem I got was in the
top Makefile and that was easy to fix.
I need more time to post the patches since I'm taking care of some
comments that were posted to Maxim's patches (which I'm us
Hi Magnus,
> If U-boot had full NAND support for i.MX31, NAND would be detected
> somewhere between steps 7 and 8.
Thanks for the elaborate explanation. I did not find any detailed
documentation for the same in the u-boot readme's.
> See my explanation above. CONFIG_SKIP* is defined when compili
> Hi Matthias,
>
> Matthias Fuchs wrote:
> > Hi Ben, Hi Stefan,
> >
> > I will prepare a patch for these boards on thursday:
> >
> >> AR405.h
> >> CPCIISER4.h
> >> HUB405.h
> >> OCRTC.h
> >> ORSG.h
> >> WUH405.h
> >>
> >
> > I have a cleanup patch ready for DP405 by today :-)
> >
> >> D
My name is Mr. Hamilton, I am a foreign Investor and I am writting to seek your
assistance in starting a business investment in your country and execute a
business investment under your management. If you can assist me in receiving my
money and investing it in your country e-mail me with your te
Hi
2009/4/30 alfred steele :
> Hi Magnus,
>
>
>> The mainline u-boot + my patches from early April does not contain any
>> driver for the i.MX31 NAND flash controller so that can't autodetect
>> any flash part at all.
> How does it boot out of NAND then? I am getting confused. By
> detection, i me
On Thursday 30 April 2009 10:00:41 Detlev Zundel wrote:
> >> I wasn't even thinking about language comments but simply names
> >> especially in git-commit messages.
> >
> > i have no problem with localized names. i do have a problem with
> > localized comments and source code.
>
> Ok, so we're mor
Hi Jerry,
>> 16 byte stride. That is seriously odd.
>
> Isn't this "natural" for a 64-bitter?
No, of course not. That would be still another generation of course.
Makes this look all the more weird.
Cheers
Detlev
--
Each language has its purpose, however humble. Each language expresses
the
Grant,
Thanks for the reply.
I am certain that it is a hardware failure that is causing the machine check
because I can use the exact same binary on another (identical) board and have
it boot just fine. That tells me that all the EBC and SDRAM settings are
correct; and that I am using the rig
Detlev Zundel writes:
> So what about using +16 for your board and lower the base address by 2?
Ugh. Increasing by 2 would be more in line with my reasongin...
> Does that work? What is your base address? Is that 64-bit aligned?
>
> This is somewhat hypothetical and outright ugly, but I still
Hi Jerry,
> Detlev Zundel wrote:
>> Hello Shinya,
>>
>>> Detlev Zundel wrote:
As I said, I understand now why there were different data-types involved
although this was kind of non-obvious. So I take it, you had a working
configuration with REG_SIZE = 4, correct?
>>> I might be unc
Hi Mike,
>> I wasn't even thinking about language comments but simply names
>> especially in git-commit messages.
>
> i have no problem with localized names. i do have a problem with localized
> comments and source code.
Ok, so we're more or less in accord - remembering that names also show
up
> Hm... this seems a lot of code to deal with a trivial issue. I think
> implementing my idea (reading the input line by line from a text
> file) would be much easier to implement and easier to use as well.
Yeah, probably.
IIRC, I tried to stick as close to the fw_Xenv code structure as pos
Hello Shinya,
> I might be unclear. I used to use REG_SIZE = -16, as 16550 registers
> are located at 0, +0x10, +0x20, ..., .
Actually, come to think of it, I have never seen what you used to use,
as the REG_SIZE = -16 case was never in the official U-Boot sources.
Theoretically extending the "-4
Dear joe seb,
In message <4f9abdc70904300510m4397302cw61ea972990dcd...@mail.gmail.com> you
wrote:
>
> Can I know U-boot has support for MIPS32 24K based platforms?
> If there is one, I would like to refer that port for our MIPS 24K based
> platform.
"grep vct_ Makefile" will show you a list of b
Dear Marc,
In message <20090430113741.gd10...@crichton.homelinux.org> you wrote:
>
> If I didn't in the past, I did now; this is what we are using to write
> from the firmware to do bulk changes in the u-boot config space.
>
> The patch is against 1.3.3
Thanks a lot.
Hm... this seems a lot of
On 14/03/09 00:59, Ilya Yanok wrote:
> Hi Mark,
>
>
> I'll prepare the patch and will post it in some days. (We can just drop
> the above two lines and it should work but the most clean way would be
> to calculate sector_size after flash_init() and then just use that value
> but that means a lot
Detlev Zundel wrote:
> Hello Shinya,
>
>> Detlev Zundel wrote:
>>> As I said, I understand now why there were different data-types involved
>>> although this was kind of non-obvious. So I take it, you had a working
>>> configuration with REG_SIZE = 4, correct?
>> I might be unclear. I used to use
Hello Shinya,
> Detlev Zundel wrote:
>> As I said, I understand now why there were different data-types involved
>> although this was kind of non-obvious. So I take it, you had a working
>> configuration with REG_SIZE = 4, correct?
>
> I might be unclear. I used to use REG_SIZE = -16, as 16550 re
Hi Friends,
Can I know U-boot has support for MIPS32 24K based platforms?
If there is one, I would like to refer that port for our MIPS 24K based
platform.
Thanks,
Joe
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-
> This patch makes fw_setenv write multiple variables on a single command
> line. That is "fw_setenv var1 value1 var2 value2" will write all
> variables and values without the need to erase multiple times the
> environment.
IIRC fw_setenv uses the first word as key and all the rest as the value.
J
If I didn't in the past, I did now; this is what we are using to write
from the firmware to do bulk changes in the u-boot config space.
The patch is against 1.3.3
--
greetz, marc
(1) Never draw what you can copy.
(2) Never copy what you can trace.
(3) Never trace what you can cut out and paste
Dear Nikos Mavrogiannopoulos,
In message <49f9738d.9060...@gennetsa.com> you wrote:
>
> This patch makes fw_setenv write multiple variables on a single command
> line. That is "fw_setenv var1 value1 var2 value2" will write all
> variables and values without the need to erase multiple times the
>
On 23:30 Wed 29 Apr , David Brownell wrote:
> On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > as all other recent board patch
> > please unify the lds and please be aware of ben patch
>
> Erm, could you elaborate? Which "ben patch"
> would that be, and what do you mean
This patch makes fw_setenv write multiple variables on a single command
line. That is "fw_setenv var1 value1 var2 value2" will write all
variables and values without the need to erase multiple times the
environment.
regards,
Nikos
>From a105d76fada85542837870e1050f12875c668634 Mon Sep 17 00:00:00
On Thursday 30 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 23:35 Wed 29 Apr , David Brownell wrote:
> > On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > my idea is more this
> > > the lowlovel will init the pll (lowlevel_init.S or other stage bootloader)
>
On 23:35 Wed 29 Apr , David Brownell wrote:
> On Wednesday 29 April 2009, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > my idea is more this
> > the lowlovel will init the pll (lowlevel_init.S or other stage bootloader)
>
> Right ...
>
>
> > so instead of hardcoding the PPLDIV read it in the r
Hi Wolfgang,
Please pull
The following changes since commit 4277f4de065b4daea4dc27420fc1bc131701291d:
Wolfgang Denk (1):
Merge branch 'master' of git://git.denx.de/u-boot-net
are available in the git repository at:
git://git.denx.de/u-boot-arm.git master
Daniel Gorsulowski (1):
77 matches
Mail list logo
