Wolfgang Denk w...@denx.de wrote:
Dear Haavard Skinnemoen,
In message 20090831155327.62b58...@hskinnemoen-d830 you wrote:
Possibly. But it means even more effort and even larger code, so I'm
not exactly happy about it.
Really? Sorry if I'm asking dumb questions - I don't know AVR32:
Becky Bruce becky.br...@freescale.com wrote:
Sorry, guys, I'm still not clear on what's going on. Haavard, did you
expect each call to flash_map to return a different VA each time (i.e.
you're trying to do some sort of dynamic mapping), or are you just
calling it to get the VA that
On Tuesday 01 September 2009 10:57:52 Haavard Skinnemoen wrote:
Well, usually we run with IC on and with DC off, usually because
quite a number of drivers and other code do not use proper I/O
accessors yet, and/or because it's easier and nobody really cares.
For example on
Dear Haavard Skinnemoen,
In message 20090901105752.5bb77...@hskinnemoen-d830 you wrote:
Really? Sorry if I'm asking dumb questions - I don't know AVR32: is
it true that stting up a non-1:1 mapping for the NOR flash (i. e.
what you are doing now) is easier (less code) than setting up
Becky Bruce becky.br...@freescale.com wrote:
Becky: the fact that Haavard's code is breaking is not considered an
indication of a deficiency in his code.
I'm not calling the code deficient, just a bit inconsistent, and it
wasn't clear to me why. When code uses the same value 1) by
Stefan Roese s...@denx.de wrote:
On Tuesday 01 September 2009 10:57:52 Haavard Skinnemoen wrote:
Well, usually we run with IC on and with DC off, usually because
quite a number of drivers and other code do not use proper I/O
accessors yet, and/or because it's easier and
Wolfgang Denk w...@denx.de wrote:
Dear Haavard Skinnemoen,
Like I explained in an earlier mail, the default setup includes a 1:1
mapping of the lowest addresses, but it's cacheable. The default setup
also includes an uncached mapping of the same memory at a higher
virtual address.
You
Dear Haavard Skinnemoen,
In message 20090901123829.55fcb...@hskinnemoen-d830 you wrote:
And that is EXACTLY why I'm trying to advocate: Keep the additional
complexity (which can be kept to a minimum) localized to a handful of
drivers, and don't change the command line interface or the board
Wolfgang Denk w...@denx.de wrote:
Dear Haavard Skinnemoen,
In message 20090901123829.55fcb...@hskinnemoen-d830 you wrote:
And that is EXACTLY why I'm trying to advocate: Keep the additional
complexity (which can be kept to a minimum) localized to a handful of
drivers, and don't change
Wolfgang Denk w...@denx.de wrote:
Dear Haavard Skinnemoen,
In message 20090901134257.59961...@hskinnemoen-d830 you wrote:
complexity (which can be kept to a minimum) localized to a handful of
drivers, and don't change the command line interface or the board
configuration
Dear Haavard Skinnemoen,
In message 20090901152305.68e8d...@hskinnemoen-d830 you wrote:
On a 32 bit system with 36 bit physical addresses you cannot use a
physical address when running the md command, for example.
Yes you can, if you teach the md command to map it at a virtual
address
Wolfgang Denk w...@denx.de wrote:
Well, that was the part of me saying before: as long as it doesn't
hurt others. We don't want to add that complexity to U-Boot as noone
needs it.
Right. I forgot that nobody actually needs this.
Fuck it, I'm out.
Haavard
Thiago A. Corrêa thiago.cor...@gmail.com wrote:
Hi,
I don't want to intrude too much into the discussion, but I would
like to offer a small bit of info
Oh, I wish more people would intrude ;-)
On Tue, Sep 1, 2009 at 10:23 AM, Haavard
Skinnemoenhaavard.skinnem...@atmel.com wrote:
It
Hi,
I don't want to intrude too much into the discussion, but I would
like to offer a small bit of info
On Tue, Sep 1, 2009 at 10:23 AM, Haavard
Skinnemoenhaavard.skinnem...@atmel.com wrote:
It would be a good idea to clean up this board support, remove the
proprietary flash driver and
Haavard Skinnemoen wrote:
snip
Right...I'm beginning to doubt that anyone is familiar enough with the
u-boot code, since everyone seems to have their own opinion about how
things are supposed to work.
To summarize, here are the possible ways to fix the problem as I see it:
- Use virtual
Dear Haavard Skinnemoen,
In message 20090830224218.10f14...@siona you wrote:
Well, VA==PA is the default setting for U-Boot that shall be used for
all systems, unless it is really impossible on a board to implement an
exception from that rule.
While not impossible, following that rule
Dear Haavard Skinnemoen,
In message 20090831155327.62b58...@hskinnemoen-d830 you wrote:
Possibly. But it means even more effort and even larger code, so I'm
not exactly happy about it.
Really? Sorry if I'm asking dumb questions - I don't know AVR32: is
it true that stting up a non-1:1
On Aug 30, 2009, at 1:11 PM, Wolfgang Denk wrote:
Dear Haavard Becky,
In message 20090830173640.2af9c...@siona you wrote:
The only way for that to work
is when VA=PA (or, depending on what you were doing with the
address,
Well, VA==PA is the default setting for U-Boot that shall be
On Aug 31, 2009, at 6:57 AM, Wolfgang Denk wrote:
Dear Haavard Skinnemoen,
In message 20090830224218.10f14...@siona you wrote:
Well, VA==PA is the default setting for U-Boot that shall be used
for
all systems, unless it is really impossible on a board to
implement an
exception from
On Fri, 28 Aug 2009 14:58:15 -0500
Becky Bruce becky.br...@freescale.com wrote:
FYI, before the patch, the CFI driver was sometimes doing the map,
but IIRC it was also abusing the physical address, treating it as
a virtual address without mapping it.
In that case, those places should have been
On Sat, 29 Aug 2009 13:39:02 +0200
Stefan Roese s...@denx.de wrote:
I think too, that revering the patch in question is not the right
solution for this problem in the current stage. But I have to admit
that I don't have enough insight into your platform to come up with
another good idea
Dear Haavard Becky,
In message 20090830173640.2af9c...@siona you wrote:
The only way for that to work
is when VA=PA (or, depending on what you were doing with the address,
Well, VA==PA is the default setting for U-Boot that shall be used for
all systems, unless it is really impossible on
On Sun, 30 Aug 2009 20:11:01 +0200
Wolfgang Denk w...@denx.de wrote:
Dear Haavard Becky,
In message 20090830173640.2af9c...@siona you wrote:
The only way for that to work
is when VA=PA (or, depending on what you were doing with the
address,
Well, VA==PA is the default setting
On Friday 28 August 2009 21:58:15 Becky Bruce wrote:
On Aug 28, 2009, at 8:49 AM, Haavard Skinnemoen wrote:
Kumar Gala ga...@kernel.crashing.org wrote:
Reverting 09ce9921a7d8b1ce764656b14b42217bbf4faa38 would bring
things
back to the way they were, and fix both the saveenv problem and the
Ever since the CFI driver was rewritten to use virtual addresses, thus
eliminating the whole point of the map_physmem() macro, ATNGW100 has
been broken like this:
U-Boot saveenv
Saving Environment to Flash...
Error: start and/or end address not on sector boundary
So let's take a different
Haavard Skinnemoen wrote:
Ever since the CFI driver was rewritten to use virtual addresses, thus
eliminating the whole point of the map_physmem() macro, ATNGW100 has
been broken like this:
How about other boards (like the MIMC200) ?
Aren't *all* AVR32 boards affected in this way ?
Mark
Mark Jackson mpfj-l...@mimc.co.uk wrote:
Haavard Skinnemoen wrote:
Ever since the CFI driver was rewritten to use virtual addresses, thus
eliminating the whole point of the map_physmem() macro, ATNGW100 has
been broken like this:
How about other boards (like the MIMC200) ?
Aren't
Mark Jackson mpfj-l...@mimc.co.uk wrote:
Haavard Skinnemoen wrote:
Possibly, but NGW100 is the only one which I've seen reports about.
STK1000 is safe since it doesn't use the CFI driver.
I did kinda report this in the thread JFFS2 scanning bug, and
the triple-revert patch you posted on
Haavard Skinnemoen wrote:
Mark Jackson mpfj-l...@mimc.co.uk wrote:
Haavard Skinnemoen wrote:
Possibly, but NGW100 is the only one which I've seen reports about.
STK1000 is safe since it doesn't use the CFI driver.
I did kinda report this in the thread JFFS2 scanning bug, and
the
Dear Haavard Skinnemoen,
In message 1251448970-15252-1-git-send-email-haavard.skinnem...@atmel.com you
wrote:
Ever since the CFI driver was rewritten to use virtual addresses, thus
eliminating the whole point of the map_physmem() macro, ATNGW100 has
been broken like this:
U-Boot saveenv
Dear Mark Jackson,
In message 4a97b2d4.6080...@mimc.co.uk you wrote:
Okay ... looks like there are 2 problems revolving round CFI.
(1) saveenv
(2) jffs2
The CONFIG_ENV_ADDR patch fixes (1) but *not* (2).
The triple-revert patch fixes both (1) and (2).
Not quite sure how to
Wolfgang Denk w...@denx.de wrote:
#define CONFIG_ENV_IS_IN_FLASH 1
#define CONFIG_ENV_SIZE65536
-#define CONFIG_ENV_ADDR(CONFIG_SYS_FLASH_BASE +
CONFIG_SYS_FLASH_SIZE - CONFIG_ENV_SIZE)
+#define CONFIG_ENV_ADDR
On Aug 28, 2009, at 7:14 AM, Haavard Skinnemoen wrote:
Wolfgang Denk w...@denx.de wrote:
#define CONFIG_ENV_IS_IN_FLASH 1
#define CONFIG_ENV_SIZE 65536
-#define CONFIG_ENV_ADDR(CONFIG_SYS_FLASH_BASE +
CONFIG_SYS_FLASH_SIZE -
Kumar Gala ga...@kernel.crashing.org wrote:
Reverting 09ce9921a7d8b1ce764656b14b42217bbf4faa38 would bring things
back to the way they were, and fix both the saveenv problem and the
jffs2 problem.
Such a revert would break other boards that now expect the new
behavior (like all the
On Aug 28, 2009, at 8:49 AM, Haavard Skinnemoen wrote:
Kumar Gala ga...@kernel.crashing.org wrote:
Reverting 09ce9921a7d8b1ce764656b14b42217bbf4faa38 would bring
things
back to the way they were, and fix both the saveenv problem and the
jffs2 problem.
Such a revert would break other
35 matches
Mail list logo
