Introduce board_start_saveenv() and board_finish_saveenv(), two "weak"
functions that are called before and after saving the environment. This
allows for board-specific functions that "prepare" the board for saving
the environment. This is useful if, for some reason, the non-volatile
storage is n
On Friday 04 May 2012 18:21:31 Timur Tabi wrote:
> Introduce board_start_saveenv() and board_finish_saveenv(), two "weak"
> functions that are called before and after saving the environment. This
> allows for board-specific functions that "prepare" the board for saving
> the environment. This is
Mike Frysinger wrote:
> On Friday 04 May 2012 18:21:31 Timur Tabi wrote:
>> Introduce board_start_saveenv() and board_finish_saveenv(), two "weak"
>> functions that are called before and after saving the environment. This
>> allows for board-specific functions that "prepare" the board for saving
>
On Monday 14 May 2012 12:10:48 Timur Tabi wrote:
> Mike Frysinger wrote:
> > this is less bloat:
> > int board_start_saveenv(void) __attribute__((weak, alias("saveenv")));
> >
> > int do_env_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> > argv[]) {
> >
> > printf("Saving Environme
Mike Frysinger wrote:
> this is less bloat:
> int board_saveenv(void) __attribute__((weak, alias("saveenv")));
>
> int do_env_save(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> {
> printf("Saving Environment to %s...\n", env_name_spec);
> return board_saveenv() ? 1 : 0;
Dear Timur Tabi,
In message <4fb12e88.1050...@freescale.com> you wrote:
>
> > all these board hooks are paper-cutting us to death with unused bloat
>
> I know, and I don't like it either. I hate how our hardware designers are
> always breaking the "rules", forcing us software developers to hack
Wolfgang Denk wrote:
> I think whoever told you this was right. Let it break.
Come on, Wolfgang. That's not acceptable.
> We cannot add pre- and post-hooks all ever the place for brain-dead
> designs that need to do this and that before and after doing perfectly
> things.
Well, I already have
On 05/17/2012 05:18 PM, Wolfgang Denk wrote:
> Dear Timur Tabi,
>
> In message <4fb12e88.1050...@freescale.com> you wrote:
>>
>>> all these board hooks are paper-cutting us to death with unused bloat
>>
>> I know, and I don't like it either. I hate how our hardware designers are
>> always breakin
Scott Wood wrote:
> NAND doesn't need it because NAND goes through an API rather than direct
> memory-mapped access, and has more coarse-grained operations. NAND
> should be able to take care of this entirely in the driver using the
> select_chip() callback.
Fair enough. How do I enable that fea
On 05/17/2012 05:53 PM, Timur Tabi wrote:
> Scott Wood wrote:
>> NAND doesn't need it because NAND goes through an API rather than direct
>> memory-mapped access, and has more coarse-grained operations. NAND
>> should be able to take care of this entirely in the driver using the
>> select_chip() c
On 05/17/2012 09:21 PM, Tabi Timur-B04825 wrote:
> Scott Wood wrote:
Well, as with most of our boards, NOR is the default configuration. Also,
there's no NAND support upstream yet.
>> What isn't upstream, besides the muxing hack? Does it need the 4K page
>> hack?
>
> There's no NAND
Scott Wood wrote:
>> > Well, as with most of our boards, NOR is the default configuration. Also,
>> > there's no NAND support upstream yet.
> What isn't upstream, besides the muxing hack? Does it need the 4K page
> hack?
There's no NAND support at all. However, I just tried the two SDK patche
On Thursday 17 May 2012 18:35:25 Timur Tabi wrote:
> Well, I already have code in U-boot that does this. If you look at
> board/freescale/p1022ds/diu.c, you'll see that I override each of the NOR
> flash accessors. This is horribly inefficient, but it works.
> Unfortunately, it only covers NOR fl
Dear Timur,
In message <4fb57d2d.3090...@freescale.com> you wrote:
>
> > I think whoever told you this was right. Let it break.
>
> Come on, Wolfgang. That's not acceptable.
Why not? But adding arbitrary complexity and ugliness into U-Boot
mainline is acceptable? Why?
> > We cannot add pr
Wolfgang Denk wrote:
> This is already streching the code to the limits, and the only reason
> you ever got this thrugh is that it's FSL specific code, you you have
> to deal yourself with this ugliness. I don;t think you will find good
> arguments to convince me adding such stuff into common cod
Scott Wood wrote:
>> There's no NAND support at all.
> Of course there's NAND support. I was asking what, besides the mux,
> makes that existing support not work on this board.
No, there is no NAND support for the P1022DS upstream.
[b04825@efes u-boot.0]$ grep -i nand include/configs/P1022DS.h
[
On 05/18/2012 05:58 PM, Timur Tabi wrote:
Is there a way to switch the console
setenv stdout serial
works for me..
Regards,
Jeroen
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
On 05/18/2012 11:00 AM, Timur Tabi wrote:
> Scott Wood wrote:
>>> There's no NAND support at all.
>> Of course there's NAND support. I was asking what, besides the mux,
>> makes that existing support not work on this board.
>
> No, there is no NAND support for the P1022DS upstream.
>
> [b04825@e
Scott Wood wrote:
> That's the equivalent of saying Linux doesn't support something because
> nobody bothered to enable it in a certain defconfig.
Well, that's exactly what I meant. When you boot an upstream U-boot on a
P1022DS, there is no support for NAND chips. The 'nand' command does not
ex
On 05/18/2012 11:17 AM, Timur Tabi wrote:
> Scott Wood wrote:
>
>> That's the equivalent of saying Linux doesn't support something because
>> nobody bothered to enable it in a certain defconfig.
>
> Well, that's exactly what I meant. When you boot an upstream U-boot on a
> P1022DS, there is no s
Scott Wood wrote:
> It was over a year ago that I made that request internally. And still
> the answer is "I need this now now now!".
Who's going to do that work, if not you?
> NACK any non-SPD NAND boot for a board that otherwise uses SPD,
> particularly if it has socketed RAM. It's not as if
On 05/18/2012 12:08 PM, Timur Tabi wrote:
> Scott Wood wrote:
>> It was over a year ago that I made that request internally. And still
>> the answer is "I need this now now now!".
>
> Who's going to do that work, if not you?
Matthew had something working a while ago, I thought.
>> NACK any non-
On Fri, May 18, 2012 at 12:21 PM, Scott Wood wrote:
> On 05/18/2012 12:08 PM, Timur Tabi wrote:
>> Scott Wood wrote:
>>> It was over a year ago that I made that request internally. And still
>>> the answer is "I need this now now now!".
>>
>> Who's going to do that work, if not you?
>
> Matthew h
Dear Timur,
In message <4fb67191.4030...@freescale.com> you wrote:
>
> > For example, what happens when I just use "md" or "itest *addr" or
> > similar trying to read NOR flash while the display is on?
>
> The reason I make a big deal about saveenv is because I use an environment
> variable ("vi
Dear Jeroen Hofstee,
In message <4fb672b0.8010...@myspectrum.nl> you wrote:
> On 05/18/2012 05:58 PM, Timur Tabi wrote:
> > Is there a way to switch the console
> setenv stdout serial
>
> works for me..
Hey. Don't share insider information like that ;-)
Best regards,
Wolfgang Denk
--
DENX S
Dear Scott,
In message <4fb678cf.4030...@freescale.com> you wrote:
>
> Wolfgang will also probably object to adding another board to the old
> nand_spl infrastrucutre.
True. This gives a NAK reliably.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detl
On Fri, May 18, 2012 at 12:58 PM, Timur Tabi wrote:
> The reason I make a big deal about saveenv is because I use an environment
> variable ("video-mode") to enable video support. Once the console is
> switched to the video display, the only way to switch it back to the
> serial port is to delet
27 matches
Mail list logo
