[U-Boot-Users] [PATCH] Sequoia has two UARTs in "4-pin" mode. Configure the GPIOs as per schematic.
The Sequoia board has two UARTs in "4-pin" mode. This patch modifies the GPIO
configuration to match the schematic, and also sets the sdr0_pfc1 register to
select the corresponding mode for the UARTs.
board/amcc/sequoia/sequoia.c |5 +
include/configs/sequoia.h| 12 ++--
2 files changed, 11 insertions(+), 6 deletions(-)
Signed-off-by: Steven A. Falco <[EMAIL PROTECTED]>
diff --git a/board/amcc/sequoia/sequoia.c b/board/amcc/sequoia/sequoia.c
index 6bcb3ab..6ee9c88 100644
--- a/board/amcc/sequoia/sequoia.c
+++ b/board/amcc/sequoia/sequoia.c
@@ -93,6 +93,11 @@ int board_early_init_f(void)
#ifdef CONFIG_I2C_MULTI_BUS
sdr0_pfc1 |= ((sdr0_pfc1 & ~SDR0_PFC1_SIS_MASK) |
SDR0_PFC1_SIS_IIC1_SEL);
#endif
+ /* Two UARTs, so we need 4-pin mode. Also, we want CTS/RTS mode. */
+ sdr0_pfc1 = (sdr0_pfc1 & ~SDR0_PFC1_U0IM_MASK) | SDR0_PFC1_U0IM_4PINS;
+ sdr0_pfc1 = (sdr0_pfc1 & ~SDR0_PFC1_U0ME_MASK) | SDR0_PFC1_U0ME_CTS_RTS;
+ sdr0_pfc1 = (sdr0_pfc1 & ~SDR0_PFC1_U1ME_MASK) | SDR0_PFC1_U1ME_CTS_RTS;
+
mfsdr(SDR0_PFC2, sdr0_pfc2);
sdr0_pfc2 = (sdr0_pfc2 & ~SDR0_PFC2_SELECT_MASK) |
SDR0_PFC2_SELECT_CONFIG_4;
diff --git a/include/configs/sequoia.h b/include/configs/sequoia.h
index 555316f..d129a58 100644
--- a/include/configs/sequoia.h
+++ b/include/configs/sequoia.h
@@ -544,12 +544,12 @@
/* GPIO Core 1 */
\
{GPIO1_BASE, GPIO_OUT, GPIO_ALT1, GPIO_OUT_1}, /* GPIO32 USB2D_OPMODE0
EBC_DATA(2) */ \
{GPIO1_BASE, GPIO_OUT, GPIO_ALT1, GPIO_OUT_1}, /* GPIO33 USB2D_OPMODE1
EBC_DATA(3) */ \
-{GPIO1_BASE, GPIO_OUT, GPIO_ALT3, GPIO_OUT_1}, /* GPIO34 UART0_DCD_N
UART1_DSR_CTS_N UART2_SOUT*/ \
-{GPIO1_BASE, GPIO_IN , GPIO_ALT3, GPIO_OUT_0}, /* GPIO35 UART0_8PIN_DSR_N
UART1_RTS_DTR_N UART2_SIN*/ \
-{GPIO1_BASE, GPIO_IN , GPIO_ALT3, GPIO_OUT_0}, /* GPIO36 UART0_8PIN_CTS_N
EBC_DATA(0) UART3_SIN*/ \
-{GPIO1_BASE, GPIO_BI , GPIO_ALT2, GPIO_OUT_0}, /* GPIO37 UART0_RTS_N
EBC_DATA(1) UART3_SOUT*/ \
-{GPIO1_BASE, GPIO_OUT, GPIO_ALT2, GPIO_OUT_1}, /* GPIO38 UART0_DTR_N
UART1_SOUT */ \
-{GPIO1_BASE, GPIO_IN , GPIO_ALT2, GPIO_OUT_0}, /* GPIO39 UART0_RI_N
UART1_SIN */ \
+{GPIO1_BASE, GPIO_IN , GPIO_ALT2, GPIO_OUT_0}, /* GPIO34 UART0_8PIN_DCD_N
UART1_DSR_CTS_N UART2_SOUT*/ \
+{GPIO1_BASE, GPIO_OUT, GPIO_ALT2, GPIO_OUT_1}, /* GPIO35 UART0_8PIN_DSR_N
UART1_RTS_DTR_N UART2_SIN*/ \
+{GPIO1_BASE, GPIO_IN , GPIO_ALT1, GPIO_OUT_0}, /* GPIO36 UART0_CTS_N
EBC_DATA(0) UART3_SIN*/ \
+{GPIO1_BASE, GPIO_OUT, GPIO_ALT1, GPIO_OUT_1}, /* GPIO37 UART0_RTS_N
EBC_DATA(1) UART3_SOUT*/ \
+{GPIO1_BASE, GPIO_OUT, GPIO_ALT2, GPIO_OUT_1}, /* GPIO38 UART0_8PIN_DTR_N
UART1_SOUT */ \
+{GPIO1_BASE, GPIO_IN , GPIO_ALT2, GPIO_OUT_0}, /* GPIO39 UART0_8PIN_RI_N
UART1_SIN */ \
{GPIO1_BASE, GPIO_IN , GPIO_ALT1, GPIO_OUT_0}, /* GPIO40 UIC_IRQ(0)
*/ \
{GPIO1_BASE, GPIO_IN , GPIO_ALT1, GPIO_OUT_0}, /* GPIO41 UIC_IRQ(1)
*/ \
{GPIO1_BASE, GPIO_IN , GPIO_ALT1, GPIO_OUT_0}, /* GPIO42 UIC_IRQ(2)
*/ \
--
1.5.5.1
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] sequoia uarts
Stefan Roese wrote: > On Friday 01 August 2008, Wolfgang Denk wrote: > >> In message <[EMAIL PROTECTED]> you wrote: >> >>> I have verified that the Sequoia (440EPx) does not have its UARTs >>> properly configured. The attached patch corrects this by setting three >>> bits in SDR0_PFC1 to enable 4-wire mode, and to select cts/rts >>> functionality for the UARTs. Also, I modified the GPIO settings for >>> >> We definitely do NOT want any hardware handshake on the serial >> console. Never. >> > > Ack, we don't want hardware handshake enabled in U-Boot. But if I understand > this correctly, then this patch from Steven configures the RTS/CTS lines > correctly (they are multiplexed with other signals), so that they *can* be > used by the OS if needed. It doesn't enable hardware handshake in U-Boot. > > Steven please correct me if I am wrong here. > You are correct. The patch simply configures the lines to match the schematic - it does not activate hardware handshake within U-Boot. Steve - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] sequoia uarts
Wolfgang Denk wrote: > In message <[EMAIL PROTECTED]> you wrote: > >> I have verified that the Sequoia (440EPx) does not have its UARTs >> properly configured. The attached patch corrects this by setting three >> bits in SDR0_PFC1 to enable 4-wire mode, and to select cts/rts >> functionality for the UARTs. Also, I modified the GPIO settings for >> > > We definitely do NOT want any hardware handshake on the serial > console. Never. > > Best regards, > > Wolfgang Denk > Perhaps my comments were not clear. Please let me try again: The schematic for the Sequoia shows two uarts. U-boot leaves the SDR0_PFC1[U0IM] bit cleared to 0, which means that the 440EPx will only have one uart, operating in 8-wire mode. So, U-boot does not set the CPU to the correct mode to enable two uarts. This is independent of whether you want RTS/CTS or not, and as far as I can see, it must be fixed if both uart ports are going to work. This also applies to the GPIOs. They are not set correctly to connect the uarts to the I/O pins - the wrong functions and polarities are selected. This too is dictated by the schematic. The wires go where they go, and the GPIOs should be configured to match the schematic (or the schematic should be changed to match the software, but we know that isn't going to happen). :-) The remaining point is the SDR0_PFC1[U0ME] and SDR0_PFC1[U1ME] bits, which determine whether the control signals are RTS/CTS or DCD/DSR. These signals are wired to the DB-9 jacks on pins 7 and 8. According to the RS232 standard, these pins are RTS/CTS, and there is nothing software can do to change their meaning. So, I believe my patch should be applied as written, so that the software and hardware agree as to function. That said, /what we choose to do with the lines is up to us/. If we don't want to enable RTS/CTS processing in the drivers, that is fine. We can leave the function disabled. But the hardware registers must be configured to at least match the schematic wiring. Anything else makes no sense. Steve - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [PATCH] sequoia uarts
I have verified that the Sequoia (440EPx) does not have its UARTs
properly configured. The attached patch corrects this by setting three
bits in SDR0_PFC1 to enable 4-wire mode, and to select cts/rts
functionality for the UARTs. Also, I modified the GPIO settings for
pins 34-37 to conform to the tables in section 31 of the 440EPx users
manual.
Here is a dump of the registers once the patch was made. I've verified
that these match the users manual. Also, my Sequoia board works. :-)
=> getidcr e.f 4101
000e.000f-4101 Read 034c100f
=> md.l ef600c00 1
ef600c00:
=> md.l ef600c04 1
ef600c04: d600
=> md.l ef600c08 1
ef600c08: 5218R...
=> md.l ef600c10 1
ef600c10:
=> md.l ef600c40 1
ef600c40:
=> md.l ef600c38 1
ef600c38: 0401
=> md.l ef600c30 1
ef600c30: 00405550[EMAIL PROTECTED]
Signed-off-by: Steven A. Falco <[EMAIL PROTECTED]>
diff --git a/board/amcc/sequoia/sequoia.c b/board/amcc/sequoia/sequoia.c
index 6bcb3ab..6ee9c88 100644
--- a/board/amcc/sequoia/sequoia.c
+++ b/board/amcc/sequoia/sequoia.c
@@ -93,6 +93,11 @@ int board_early_init_f(void)
#ifdef CONFIG_I2C_MULTI_BUS
sdr0_pfc1 |= ((sdr0_pfc1 & ~SDR0_PFC1_SIS_MASK) | SDR0_PFC1_SIS_IIC1_SEL);
#endif
+ /* Two UARTs, so we need 4-pin mode. Also, we want CTS/RTS mode. */
+ sdr0_pfc1 = (sdr0_pfc1 & ~SDR0_PFC1_U0IM_MASK) | SDR0_PFC1_U0IM_4PINS;
+ sdr0_pfc1 = (sdr0_pfc1 & ~SDR0_PFC1_U0ME_MASK) | SDR0_PFC1_U0ME_CTS_RTS;
+ sdr0_pfc1 = (sdr0_pfc1 & ~SDR0_PFC1_U1ME_MASK) | SDR0_PFC1_U1ME_CTS_RTS;
+
mfsdr(SDR0_PFC2, sdr0_pfc2);
sdr0_pfc2 = (sdr0_pfc2 & ~SDR0_PFC2_SELECT_MASK) |
SDR0_PFC2_SELECT_CONFIG_4;
diff --git a/include/configs/sequoia.h b/include/configs/sequoia.h
index 555316f..d129a58 100644
--- a/include/configs/sequoia.h
+++ b/include/configs/sequoia.h
@@ -544,12 +544,12 @@
/* GPIO Core 1 */ \
{GPIO1_BASE, GPIO_OUT, GPIO_ALT1, GPIO_OUT_1}, /* GPIO32 USB2D_OPMODE0 EBC_DATA(2) */ \
{GPIO1_BASE, GPIO_OUT, GPIO_ALT1, GPIO_OUT_1}, /* GPIO33 USB2D_OPMODE1 EBC_DATA(3) */ \
-{GPIO1_BASE, GPIO_OUT, GPIO_ALT3, GPIO_OUT_1}, /* GPIO34 UART0_DCD_N UART1_DSR_CTS_N UART2_SOUT*/ \
-{GPIO1_BASE, GPIO_IN , GPIO_ALT3, GPIO_OUT_0}, /* GPIO35 UART0_8PIN_DSR_N UART1_RTS_DTR_N UART2_SIN*/ \
-{GPIO1_BASE, GPIO_IN , GPIO_ALT3, GPIO_OUT_0}, /* GPIO36 UART0_8PIN_CTS_N EBC_DATA(0) UART3_SIN*/ \
-{GPIO1_BASE, GPIO_BI , GPIO_ALT2, GPIO_OUT_0}, /* GPIO37 UART0_RTS_N EBC_DATA(1) UART3_SOUT*/ \
-{GPIO1_BASE, GPIO_OUT, GPIO_ALT2, GPIO_OUT_1}, /* GPIO38 UART0_DTR_N UART1_SOUT */ \
-{GPIO1_BASE, GPIO_IN , GPIO_ALT2, GPIO_OUT_0}, /* GPIO39 UART0_RI_N UART1_SIN */ \
+{GPIO1_BASE, GPIO_IN , GPIO_ALT2, GPIO_OUT_0}, /* GPIO34 UART0_8PIN_DCD_N UART1_DSR_CTS_N UART2_SOUT*/ \
+{GPIO1_BASE, GPIO_OUT, GPIO_ALT2, GPIO_OUT_1}, /* GPIO35 UART0_8PIN_DSR_N UART1_RTS_DTR_N UART2_SIN*/ \
+{GPIO1_BASE, GPIO_IN , GPIO_ALT1, GPIO_OUT_0}, /* GPIO36 UART0_CTS_N EBC_DATA(0) UART3_SIN*/ \
+{GPIO1_BASE, GPIO_OUT, GPIO_ALT1, GPIO_OUT_1}, /* GPIO37 UART0_RTS_N EBC_DATA(1) UART3_SOUT*/ \
+{GPIO1_BASE, GPIO_OUT, GPIO_ALT2, GPIO_OUT_1}, /* GPIO38 UART0_8PIN_DTR_N UART1_SOUT */ \
+{GPIO1_BASE, GPIO_IN , GPIO_ALT2, GPIO_OUT_0}, /* GPIO39 UART0_8PIN_RI_N UART1_SIN */ \
{GPIO1_BASE, GPIO_IN , GPIO_ALT1, GPIO_OUT_0}, /* GPIO40 UIC_IRQ(0) */ \
{GPIO1_BASE, GPIO_IN , GPIO_ALT1, GPIO_OUT_0}, /* GPIO41 UIC_IRQ(1) */ \
{GPIO1_BASE, GPIO_IN , GPIO_ALT1, GPIO_OUT_0}, /* GPIO42 UIC_IRQ(2) */ \
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Sequoia uart support looks to be misconfigured
I am looking at U-Boot version "DENX-v1.3.3" for the AMCC Sequoia board
(PPC440EPx).
The uart gpio configuration doesn't appear to match the schematics.
sequoia.h has the following GPIO settings:
{GPIO1_BASE, GPIO_OUT, GPIO_ALT3, GPIO_OUT_1}, /* GPIO34 UART0_DCD_N
UART1_DSR_CTS_NUART2_SOUT*/ \
{GPIO1_BASE, GPIO_IN , GPIO_ALT3, GPIO_OUT_0}, /* GPIO35
UART0_8PIN_DSR_N UART1_RTS_DTR_N UART2_SIN*/ \
{GPIO1_BASE, GPIO_IN , GPIO_ALT3, GPIO_OUT_0}, /* GPIO36
UART0_8PIN_CTS_N EBC_DATA(0)UART3_SIN*/ \
{GPIO1_BASE, GPIO_BI , GPIO_ALT2, GPIO_OUT_0}, /* GPIO37 UART0_RTS_N
EBC_DATA(1)UART3_SOUT*/ \
These look wrong. For example, GPIO34 (ball C28) is wired as CTS
according to the Sequoia schematic. So, shouldn't it be GPIO_ALT2
rather than GPIO_ALT3? Similarly, GPIO35 (ball C29) should be RTS,
which is also GPIO_ALT2 rather than GPIO_ALT3.
GPIO36 (ball A29) is also a CTS signal, so I think this should be
GPIO_ALT1, not GPIO_ALT3. Finally, GPIO37 (ball B29) is another RTS
signal, so it should be GPIO_ALT1, not GPIO_ALT2.
One final comment. In order to use two uarts, SDR0_PFC1[U0IM] must be
set to 1. To select the RTS/CTS function for the first uart,
SDR0_PFC1[U0ME] must be set to 1. Yet, I have not found any place in
the sequoia initialization code where these bits are set. So, I think
the board is actually running with one uart in 8-pin mode rather than
two uarts each in 4-pin mode.
I'd appreciate it if someone else could take a look at this, and comment
on my concerns.
Steve
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Silent console enhancement patch
Wolfgang Denk wrote: > Why isn't "silent" defined as needed in your defualkt environment > that gets used when there is no valid environment? > > The easiest way is set up everything as needed, or example by > including the environment sector(s) with the U-Boot image (i. e. > chosing a configuration which uses ENV_IS_EMBEDDED). > Thank you! I believe ENV_IS_EMBEDDED will do what I need. I had based my bsp on sequoia, which did not have this set. Also, I had a misconception about ENV_IS_EMBEDDED - I had thought it meant that the environment was permanently part of the text segment, which would not be good for me. But after studying the code, I now understand that ENV_IS_EMBEDDED is only for the initial environment. I would like to withdraw my patch. I would still like to pursue my proposed "setenv.patch" - that one changes setenv() to return an integer rather than void. If you have any comments on it, please let me know. Thanks again, Steve - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] ppcenv_assert = ASSERT?
I downloaded u-boot-1.3.3.tar.bz2 and tried building sequoia_defconfig. I noticed a message in u-boot.map: 0x00044740ohci_dev 0x00044900ghcca 0x0001ppcenv_assert = ASSERT ((. < 0x8000), .bss section too big, overlaps .ppcenv section. Please update your confguration: CFG_MONITOR_BASE, CFG_MONITOR_LEN and TEXT_BASE may need to be modified.) 0x00044a00_end = . 0x00044a00PROVIDE (end, .) Address of section .text set to 0xfffa The build runs to completion and the resulting rom works fine. Does this message indicate an error or can it be ignored? Steve - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Patch to clean up syntax highlighting
Jerry Van Baren wrote: > > Jerry Van Baren wrote: >> Steven A. Falco wrote: >>> My text-editor (vim) has a bit of trouble syntax-highlighting the >>> cmd_nvedit.c >>> file, because it apparently does not parse C ifdef/else/endif. The >>> following >>> patch does not change the behavior of the code at all, but does >>> allow the >>> editor to properly syntax-highlight the file. >>> >>> Comments invited. >> >> OK, you invited comments so I'll be the designated curmudgeon >> tonight... I'm not wild about uglifying our code to accommodating vim >> syntax highlighting limitations. Perhaps you can fix the vim syntax >> highlighting instead? >> >>> Signed-off-by: Steve Falco <[EMAIL PROTECTED]> >>> >>> diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c >>> index 9c5d1fc..1ac91ea 100644 >>> --- a/common/cmd_nvedit.c >>> +++ b/common/cmd_nvedit.c >>> @@ -179,11 +179,12 @@ int _do_setenv (int flag, int argc, char *argv[]) >>> * Ethernet Address and serial# can be set only once, >>> * ver is readonly. >>> */ >>> +if ( >>> #ifdef CONFIG_HAS_UID >>> /* Allow serial# forced overwrite with 0xdeaf4add flag */ >>> -if ( ((strcmp (name, "serial#") == 0) && (flag != >>> 0xdeaf4add)) || >>> +((strcmp (name, "serial#") == 0) && (flag != >>> 0xdeaf4add)) || >>> #else >>> -if ( (strcmp (name, "serial#") == 0) || >>> +(strcmp (name, "serial#") == 0) || >>> #endif >>> ((strcmp (name, "ethaddr") == 0) >>> #if defined(CONFIG_OVERWRITE_ETHADDR_ONCE) && defined(CONFIG_ETHADDR) >> >> I probably should confess I don't use syntax highlighting so that >> probably factors in to my lack of sympathy. >> >> Best regards, >> gvb > > Hi Steven, > > I got a good night's sleep and a cup of coffee in me and so I'm a > little more mellow this morning. ;-) > > Looking at the source code, its pretty ugly already. Your change > doesn't make it any more ugly and it could be argued that it is > slightly less ugly (your patch removes the duplication of the "if( > (...)" statement). I also don't see any alternative that would make > the code beautiful. :-( > > Anyway, I formally withdraw my objection to this patch. > > Best regards, > gvb > Glad to hear it. :-) So this is probably my first actual contribution to u-boot. Is there something more I should do to have this patch merged into an official tree, or will the appropriate person pick it up when time permits? Steve - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Silent console enhancement patch
Wolfgang Denk wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>
>> The silent console as currently implemented is not silent if a board has been
>> newly manufactured. I.e., some messages are printed prior to being able to
>> set
>> the "silent" environment variable the first time.
>>
>> The following patch adds a new configuration option,
>> CONFIG_VERY_SILENT_CONSOLE, which modifies the behavior slightly. If this
>> option is selected, then the absence of the "silent" variable will result in
>> a default behavior of "silent". Also, if "silent" is set to "1", then the
>> behavior will be "silent". Only if a different value, say "0", is selected
>> will the behavior be "verbose".
>>
>> This patch doesn't change the behavior for any existing BSP's because they
>> will
>> not have selected the CONFIG_VERY_SILENT_CONSOLE option.
>>
>
> I consider this seriously confusing.
>
> Also I don't see what your problem is, assuming you provide a valid
> environment with your newly manufactured systems.
>
> I thend to reject this patch.
>
> Best regards,
>
> Wolfgang Denk
>
When we manufacture a new board, we will load the flash via jtag. All I
had planned to put in at that stage was the u-boot image itself. I did
not plan to put in an initial environment, because the environment can
easily be constructed by u-boot. The problem is that by the time the
initial environment is constructed, some messages that I want to
suppress will already have been printed, because "silent" is not defined
yet. The purpose of the patch is to suppress messages in this case.
I currently construct the environment in my BSP.c file, like so:
if(setenv("flash_self", "run flash_dhcp")) return 1;
if(setHex("kernel0_addr", CFG_KERNEL0_ADDR)) return 1;
I do this rather than using CONFIG_EXTRA_ENV_SETTINGS because some of
the values have to be computed. So, I guess I could write a host tool
to construct the environment by linking with my BSP.c file, and then
merge the constructed environment with the u-boot executable, so that
jtag could put everything in at once. But that is much more complicated.
How do other people construct the initial environment, so that it can be
loaded via jtag along with the u-boot executable?
Steve
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Silent console enhancement patch
The silent console as currently implemented is not silent if a board has been
newly manufactured. I.e., some messages are printed prior to being able to set
the "silent" environment variable the first time.
The following patch adds a new configuration option,
CONFIG_VERY_SILENT_CONSOLE, which modifies the behavior slightly. If this
option is selected, then the absence of the "silent" variable will result in
a default behavior of "silent". Also, if "silent" is set to "1", then the
behavior will be "silent". Only if a different value, say "0", is selected
will the behavior be "verbose".
This patch doesn't change the behavior for any existing BSP's because they will
not have selected the CONFIG_VERY_SILENT_CONSOLE option.
Signed-off-by: Steve Falco <[EMAIL PROTECTED]>
diff --git a/common/console.c b/common/console.c
index d8a0cb6..4c98eef 100644
--- a/common/console.c
+++ b/common/console.c
@@ -361,12 +361,22 @@ int console_assign (int file, char *devname)
/* Called before relocation - use serial functions */
int console_init_f (void)
{
+#ifdef CONFIG_VERY_SILENT_CONSOLE
+ char *pSilent;
+#endif
+
gd->have_console = 1;
#ifdef CONFIG_SILENT_CONSOLE
+#ifdef CONFIG_VERY_SILENT_CONSOLE
+ pSilent = getenv("silent");
+ if(!pSilent || *pSilent == '1')
+ gd->flags |= GD_FLG_SILENT;
+#else
if (getenv("silent") != NULL)
gd->flags |= GD_FLG_SILENT;
#endif
+#endif
return (0);
}
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Patch to clean up syntax highlighting
My text-editor (vim) has a bit of trouble syntax-highlighting the cmd_nvedit.c file, because it apparently does not parse C ifdef/else/endif. The following patch does not change the behavior of the code at all, but does allow the editor to properly syntax-highlight the file. Comments invited. Signed-off-by: Steve Falco <[EMAIL PROTECTED]> diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c index 9c5d1fc..1ac91ea 100644 --- a/common/cmd_nvedit.c +++ b/common/cmd_nvedit.c @@ -179,11 +179,12 @@ int _do_setenv (int flag, int argc, char *argv[]) * Ethernet Address and serial# can be set only once, * ver is readonly. */ + if ( #ifdef CONFIG_HAS_UID /* Allow serial# forced overwrite with 0xdeaf4add flag */ - if ( ((strcmp (name, "serial#") == 0) && (flag != 0xdeaf4add)) || + ((strcmp (name, "serial#") == 0) && (flag != 0xdeaf4add)) || #else - if ( (strcmp (name, "serial#") == 0) || + (strcmp (name, "serial#") == 0) || #endif ((strcmp (name, "ethaddr") == 0) #if defined(CONFIG_OVERWRITE_ETHADDR_ONCE) && defined(CONFIG_ETHADDR) - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Patch to setenv() to return status
Currently, the setenv function does not return an error code. I'd like to
propose the following patch, because I want to be able to test for errors in
a new BSP I'm writing.
Comments invited.
Signed-off-by: Steve Falco <[EMAIL PROTECTED]>
diff --git a/include/common.h b/include/common.h
index d0f5704..e2dfc83 100644
--- a/include/common.h
+++ b/include/common.h
@@ -232,9 +232,9 @@ char*getenv (char *);
intgetenv_r (char *name, char *buf, unsigned len);
intsaveenv (void);
#ifdef CONFIG_PPC /* ARM version to be fixed! */
-void inline setenv (char *, char *);
+int inline setenv (char *, char *);
#else
-void setenv (char *, char *);
+intsetenv (char *, char *);
#ifdef CONFIG_HAS_UID
void forceenv (char *, char *);
#endif
diff --git a/include/exports.h b/include/exports.h
index d6512cb..6377875 100644
--- a/include/exports.h
+++ b/include/exports.h
@@ -22,7 +22,7 @@ void vprintf(const char *, va_list);
void do_reset (void);
unsigned long simple_strtoul(const char *cp,char **endp,unsigned int base);
char *getenv (char *name);
-void setenv (char *varname, char *varvalue);
+int setenv (char *varname, char *varvalue);
long simple_strtol(const char *cp,char **endp,unsigned int base);
int strcmp(const char * cs,const char * ct);
#ifdef CONFIG_HAS_UID
diff --git a/include/asm-arm/u-boot-arm.h b/include/asm-arm/u-boot-arm.h
index 41e7a8f..4ee5a32 100644
--- a/include/asm-arm/u-boot-arm.h
+++ b/include/asm-arm/u-boot-arm.h
@@ -52,7 +52,7 @@ void setup_revision_tag (struct tag **params);
/* To be fixed!*/
/* */
/* common/cmd_nvedit.c */
-void setenv (char *, char *);
+intsetenv (char *, char *);
/* cpu/.../interrupt.c */
void reset_timer_masked (void);
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 9c5d1fc..1ac91ea 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -379,13 +380,13 @@ int _do_setenv (int flag, int argc, char *argv[])
return 0;
}
-void setenv (char *varname, char *varvalue)
+int setenv (char *varname, char *varvalue)
{
char *argv[4] = { "setenv", varname, varvalue, NULL };
if (varvalue == NULL)
- _do_setenv (0, 2, argv);
+ return _do_setenv (0, 2, argv);
else
- _do_setenv (0, 3, argv);
+ return _do_setenv (0, 3, argv);
}
#ifdef CONFIG_HAS_UID
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
