Re: [U-Boot] [PATCH v4 07/27] Introduce generic global_data
Hi Graeme,
On Wed, Mar 14, 2012 at 8:41 PM, Simon Glass wrote:
> Hi Graeme,
>
> On Wed, Mar 14, 2012 at 8:02 PM, Graeme Russ wrote:
>> Hi Simon,
>>
>> On Thu, Mar 15, 2012 at 1:50 PM, Simon Glass wrote:
>>> Hi Graeme,
>>>
>>> On Wed, Mar 14, 2012 at 7:35 PM, Graeme Russ wrote:
Hi Simon,
>>
>> [snip]
>>
IMHO, global data should contain only globally common members and an arch-
specific struct and ditch (most of) the #ifdefs
>>>
>>> My thinking here was to try to bring everything into a single file. It
>>> then should be clearer when things are common between different
>>> architectures. Patches to the generic file can be made without also
>>> having to patch the non-generic files, etc.
>>>
>>> A fair number of the #ifdefs are not needed, or are there because some
>>> archs don't implement all the features of U-Boot.
>>>
>>> You have an example right there: cpu_clk_rate_hz is similar to cpu_clk
>>> and core_clk.
>>>
>>> That said it is a bit of a daunting task to amalgamate them.
>>>
>>> Also there is the purely practical consideration that if we continue
>>> to have an asm/global_data.h then we end up with two global datas. One
>>> is for CONFIG_SYS_GENERIC_BOARD and contains just the non-common
>>> fields. The other is for non-CONFIG_SYS_GENERIC_BOARD and contains all
>>> fields. Ick.
>>>
>>> So what do you think?
>>
>> Do you really need to unify global data to achieve what the title of the
>> patch series suggests (i.e. to unify the init processing loop)? Maybe you
>> could leave global data as is (or slightly tweak the odd arch) and leave
>> the resolution of just how bad global data is becoming for another day
>
> It's not that easy, because in board_f.c and board_r.c and other files
> there are certain fields required. It doesn't make a huge amount of
> sense to have generic code which accesses a different global structure
> depending on what architecture it is built for. Then there are fields
> are are only used when certain options are defined. Ick.
>
> If I am going to pull this off I need a bit of flexibility. I've
> looked into this quite a bit and mapped a path through this which I
> think will work. It requires doing things in stages, or it will never
> happen.
>
>>
>> I only say this because this is turning into "let's do a dirty hack now to
>> partially fix it and leave the rest for later (it'll get done, really,
>> honestly, I promise)" ;)
>
> It was always like that. Although I wouldn't characterise it as a
> dirty hack. If there was a requirement to do all of this in one big
> bang then I wouldn't have even started. It is just too hard :-(
>
>>
>> There will always be arch specific global data members - I see a few
>> options:
>>
>> - Move them into bd
>
> I recall talk of getting rid of this (Mike?)
>
>> - Move them into an arch_global_data struct inside gd
>
> This was Mike's idea. It is probably the easiest thing to do.
>
>> - Move them into an arch_global_data struct totally seperate from gd
>
> I sort-of like this except it would slow down access and maybe
> increase code size. Then again perhaps that's a good thing if it
> provides an incentive to reduce the number of arch-specific fields.
>
>> - Question how many are really required to be in gd (remember, gd is
>> only there to cart around writable global variable before .bss and
>> .data are available after relocation)
>
> Well yes, I feel there are far more at present than are needed. Having
> them all there in the open feels like a nice way to draw attention to
> the mess.
Any more comments on this thread? At this stage I am still not sure of
the best approach for this header...none of the options is
particularly attractive. I can imagine something horrible like:
struct global_data {
...
#include
};
which would be the smallest code change (essentially no accesses would
need to change). But it is too awful.
Of course I have a generic bd structure now, so moving things into
there doesn't fix the problem.
So if I rewind back to your first suggestion (just leave global-data
and bd as they are now), then I have the problem that I need to add
quite a bit of stuff to these structures for every architecture. This
is because at present most architectures don't support all the
features, and so don't need all the fields. As soon as I have generic
C code, I have references in that C code to global data members that
only exist for some architectures. Then someone enables CONFIG_SPI,
and breaks the board on the architecture that didn't previously have
SPI support. I wonder if that matters?
It sort-off seems attractive from the 'less work' point of view, and
is a stepping stone along the way, though.
Just to repeat your other ideas:
> - Move them into bd
> - Move them into an arch_global_data struct inside gd
> - Move them into an arch_global_data struct totally seperate from gd
> - Question how many are really required to be in gd (remember, gd is
> only there to cart around writable
Re: [U-Boot] A few things for the release?
Hi Albert, On Fri, Mar 9, 2012 at 6:32 AM, Simon Glass wrote: > Hi, > > I have a few more series that I hope will go in this time. Do you have any comments on 3 and 4 below please? Otherwise lds can perhaps go in as it in. For generic reloc I will issue a new series which tidies up SPL a bit if there are no further comments, but keeping the membasic.c approach for now. > > 3. For generic relocation, there is the issue of creating > lib/membasic.c (which is safe I think, but changes things for > everyone) versus using -ffunction-sections and possibly breaking some > boards. The latter solution is probably preferred in the long term, > but I'm not sure if Albert is keep on this happening now. See here for > details: > > http://patchwork.ozlabs.org/patch/142216/ > > Albert, can you please take a look? > > 4. I have created a bundle for the ARM link-script series as it is today: > > http://patchwork.ozlabs.org/bundle/sjg/lds/ > > Albert you had some comments, the latest of which I answered here: > > http://patchwork.ozlabs.org/patch/142254/ Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Loading kernel from usb
I am currently working on a project and I am trying to load the kernel from usb instead of an sd card. How do you configure u-boot to support usb commands? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4][v2] powerpc/85xx:Make debug exception vector accessible
On Friday 23 March 2012 11:44 PM, Scott Wood wrote: On 03/23/2012 06:44 AM, Prabhakar Kushwaha wrote: Hi Scott, On Friday 23 March 2012 01:13 AM, Scott Wood wrote: On 03/22/2012 12:52 AM, Prabhakar Kushwaha wrote: Hi Scott, Please find my reply in-lined On Thursday 22 March 2012 01:22 AM, Scott Wood wrote: On 03/20/2012 11:43 PM, Prabhakar Kushwaha wrote: Debugging of e500 and e500v1 processer requires debug exception vecter (IVPR + IVOR15) to have valid and fetchable OP code. While executing in translated space (AS=1), whenever a debug exception is generated, the MSR[DS/IS] gets cleared i.e. AS=0 and the processor tries to fetch an instruction from the debug exception vector (IVPR + IVOR15); since now we are in AS=0, the application needs to ensure the proper TLB configuration to have (IVOR + IVOR15) accessible from AS=0 also. Create a temporary TLB in AS0 to make sure debug exception verctor is accessible on debug exception. Signed-off-by: Radu Lazarescu Signed-off-by: Marius Grigoras Signed-off-by: Prabhakar Kushwaha Can you document the flow of exactly what TLB entries are present at various points of the boot flow, for all the various configurations (NOR boot, NAND SPL, RAMBOOT, IFC versus non-IFC, etc). Sure. May be separate patch will be send. Let's start with just an e-mail thoroughly describing your understanding of this. It will provide necessary context for review. We can clean it up for permanent documentation once it's clear to everyone what's going on. Sure. I will start this activity from now. But i will suggest not to combine both patches. let debugger patch to go ahead , if required i will send required patch later-on. My point is that I cannot fully follow what's going on here without spending a bunch of time looking at it, and I don't see anyone else stepping up to review this, so I'd like to see a write-up of what's going on so that I can properly review these patches. Means i have to make the doc first :( OK. Its my pleasure. In the ramboot case is this really supposed to be I+G? I am not sure. But same is done under label "create_init_ram_area" for TLB entry 15. what you suggest. I suggest as part of the request to document all of this, you figure out what should actually be mapped in each configuration. The existing code might be wrong for some of them, but we shouldn't proceed ahead blindly and make an even bigger mess. After internal discussion we can have following settings for non-RAMBOOT(NOR boot) ==> I + G for RAMBOOT ==> I, cache inhibited is required as L1 cache is used as stack. Why does using L1 for a stack mean that the mapping must be cache inhibited? Why do we even need to use L1 for a stack with ramboot? it is done at label "_start_cont". L1 is set for Stack address as "switch_as" label. am i wrong?? I=0 it means the memory range is cacheable, so an access to an address from that range could get the line in cache. If you are using the cache as a memory zone(L1 as stack), it may overwrite some data in cache and replace it with the last access. It will not do that -- when we use L1 (or part of it) for an early stack, we lock the cache lines. Agree.. Which path will NAND SPL go through (not the payload, but the SPL itself)? That will be only a 4K window mapped, and guarded doesn't stop speculative instruction fetches, so we don't want to map more than is backed up by something. NAND SPL go via !defined(CONFIG_SYS_RAMBOOT) path. i think NAND_SPL does not require temporary TLB as NAND SPL even does not have any interrupt vector. So there's no plan to support using breakpoints or single step during the SPL? That's fine with me, but should be documented, and we should make sure this code does not run in that case. Breakpoints will work as it is. No impact will be on debugging for NAND SPL. Generally any debugger use some initial configuration file. Only problem occurs when application modifies those configuration. Then why do we need to set MSR[DE] on entry, if the debugger can take care of it? Yes. You are right. It is required only for SD/SPI boot not for NAND_SPL/NOR boot. But to make MSR[DE] bit set general way (out of #define) throughout u-boot code. I did. +lis r10,0xffc0@h +ori r10,r10,0xffc0@l Don't waste instructions -- this could be in an SPL. That ori is a no-op. Please refer above response. May be this piece of code is not required for NAND SPL Still, I'd like to know why you're writing 0xffc0 to MAS7. Only the low 4 bits of MAS7 are valid on current e500. The reason for using 0xffc0 to support e6500 - since it supports 40-bit physical addresses, the last 8 bits of MAS7 are defined. Regardless, you're setting the wrong end of MAS7. It's the *lower* bits, not the upper bits, that are used. oh.. got your point. And we should not be doing anything special for e6500 here. e6500 does not need this, and e6500 platforms should not set CONFIG_SYS_PPC_E500_DEB
[U-Boot] [PATCH] cmd_nand: Fix possible uninited max_size variable
GCC 4.7 error:
cmd_nand.c: In function ‘arg_off_size’:
cmd_nand.c:216:5: warning: ‘maxsize’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
Signed-off-by: Marek Vasut
Cc: Scott Wood
---
common/cmd_nand.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 035a6f6..b015d11 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -191,7 +191,7 @@ static int arg_off_size(int argc, char *const argv[], int
*idx,
loff_t *off, loff_t *size)
{
int ret;
- loff_t maxsize;
+ loff_t maxsize = 0;
if (argc == 0) {
*off = 0;
--
1.7.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bootstage: Fix build error for standalone API example
Hi Anatolij,
On Fri, Mar 23, 2012 at 3:32 PM, Anatolij Gustschin wrote:
> Hi Simon,
>
> On Mon, 19 Mar 2012 22:49:30 -0700
> Simon Glass wrote:
>
>> This example doesn't have get_timer() defined, which causes build breakages.
>>
>> Add #ifdef guards to work around this.
>>
>> Signed-off-by: Simon Glass
>> ---
>> lib/time.c | 2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/lib/time.c b/lib/time.c
>> index 69edc3d..5f393c3 100644
>> --- a/lib/time.c
>> +++ b/lib/time.c
>> @@ -48,6 +48,7 @@ void mdelay(unsigned long msec)
>> udelay(1000);
>> }
>>
>> +#ifdef CONFIG_BOOTSTAGE
>> ulong __timer_get_boot_us(void)
>> {
>> static ulong base_time;
>> @@ -64,3 +65,4 @@ ulong __timer_get_boot_us(void)
>>
>> ulong timer_get_boot_us(void)
>> __attribute__((weak, alias("__timer_get_boot_us")));
>> +#endif
>
> Isn't it better to move timer_get_boot_us() to common/bootstage.c ?
> Or is there a plan to use this function not only in bootstage code?
Yes I sent through the smallest fix.
But as I said in the patch thread I am not sure which is best.
I'm happy to do it either way, so let me know and I can do a patch the
other way.
Regards,
Simon
>
> Thanks,
> Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] bootstage: Fix build error for standalone API example
Hi Simon,
On Mon, 19 Mar 2012 22:49:30 -0700
Simon Glass wrote:
> This example doesn't have get_timer() defined, which causes build breakages.
>
> Add #ifdef guards to work around this.
>
> Signed-off-by: Simon Glass
> ---
> lib/time.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/lib/time.c b/lib/time.c
> index 69edc3d..5f393c3 100644
> --- a/lib/time.c
> +++ b/lib/time.c
> @@ -48,6 +48,7 @@ void mdelay(unsigned long msec)
> udelay(1000);
> }
>
> +#ifdef CONFIG_BOOTSTAGE
> ulong __timer_get_boot_us(void)
> {
> static ulong base_time;
> @@ -64,3 +65,4 @@ ulong __timer_get_boot_us(void)
>
> ulong timer_get_boot_us(void)
> __attribute__((weak, alias("__timer_get_boot_us")));
> +#endif
Isn't it better to move timer_get_boot_us() to common/bootstage.c ?
Or is there a plan to use this function not only in bootstage code?
Thanks,
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-cfi-flash/master
Dear Stefan Roese, In message <201203211628.51225...@denx.de> you wrote: > > please pull the following fix: > > > The following changes since commit dbb87bbd8eff11cf974caa2b5cc397aea444bc5a: > > Armada100: gplugD: Add FAT & EXT2 command support (2012-03-19 00:08:26 > +0100) > > are available in the git repository at: > > git://www.denx.de/git/u-boot-cfi-flash.git master > > for you to fetch changes up to 85c344e5f98408c0bcf988a6c6fca68c1f3c2015: > > cfi: fix the incomplete erased status check in buffer write (2012-03-21 > 16:25:33 +0100) > > > Tao Hou (1): > cfi: fix the incomplete erased status check in buffer write > > drivers/mtd/cfi_flash.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Applied, 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 When a child is taught ... its programmed with simple instructions -- and at some point, if its mind develops properly, it exceeds the sum of what it was taught, thinks independently. -- Dr. Richard Daystrom, "The Ultimate Computer", stardate 4731.3. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request for u-boot-nds32
Dear Macpaul Lin, In message you wrote: > --e89a8ff1c62e4e8e0a04bb93f28d > Content-Type: text/plain; charset=ISO-8859-1 > > Dear Wolfgang, > > Please pull the following 2 fix patches into your master branch. > Thanks! > > The following changes since commit dbb87bbd8eff11cf974caa2b5cc397aea444bc5a: > > Armada100: gplugD: Add FAT & EXT2 command support (2012-03-19 00:08:26 > +0100) > > are available in the git repository at: > git://git.denx.de/u-boot-nds32.git master > > Macpaul Lin (2): > nds32: fix ptrace and interrupt register overflow > nds32/n1213: correct vector table in start.S > > arch/nds32/cpu/n1213/start.S| 22 +++--- > arch/nds32/include/asm/ptrace.h |2 ++ > arch/nds32/lib/interrupts.c |2 +- > 3 files changed, 22 insertions(+), 4 deletions(-) Applied, 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 If you think the problem is bad now, just wait until we've solved it. Epstein's Law ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/5] Revert "Add board_pre_console_putc to deal with early console output"
Dear Simon, In message <1332219558-9143-1-git-send-email-...@chromium.org> you wrote: > This reverts commit 295d3942b806552503243f5cfb36aec6f1b5a9bf. > > It turns that this really doesn't work very nicely. Instead we should > have a pre-console panic function so that we know that further execution > is impossible and we don't need to worry about trampling on UARTs, etc. > > Signed-off-by: Simon Glass > --- > > README | 17 - > common/console.c | 10 +- > include/common.h |7 --- > 3 files changed, 1 insertions(+), 33 deletions(-) Applied, 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 If all you have is a hammer, everything looks like a nail. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] net/tsec: convert the printf() to serial_printf()
In case we use netconsole for stdout and something goes wrong here and
we run into one of this printf() then there is no point of sending this
over network again since it is likely that will fail again.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/net/tsec.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 160bc05..78badfa 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -199,7 +199,7 @@ static void adjust_link(struct tsec_private *priv, struct
phy_device *phydev)
u32 ecntrl, maccfg2;
if (!phydev->link) {
- printf("%s: No link.\n", phydev->dev->name);
+ serial_printf("%s: No link.\n", phydev->dev->name);
return;
}
@@ -228,14 +228,14 @@ static void adjust_link(struct tsec_private *priv, struct
phy_device *phydev)
ecntrl |= ECNTRL_R100;
break;
default:
- printf("%s: Speed was bad\n", phydev->dev->name);
+ serial_printf("%s: Speed was bad\n", phydev->dev->name);
break;
}
out_be32(®s->ecntrl, ecntrl);
out_be32(®s->maccfg2, maccfg2);
- printf("Speed: %d, %s duplex%s\n", phydev->speed,
+ serial_printf("Speed: %d, %s duplex%s\n", phydev->speed,
(phydev->duplex) ? "full" : "half",
(phydev->port == PORT_FIBRE) ? ", fiber mode" : "");
}
@@ -287,7 +287,7 @@ void redundant_init(struct eth_device *dev)
/* Wait for buffer to be received */
for (t = 0; rtx.rxbd[rxIdx].status & RXBD_EMPTY; t++) {
if (t >= 10 * TOUT_LOOP) {
- printf("%s: tsec: rx error\n", dev->name);
+ serial_printf("%s: tsec: rx error\n",
dev->name);
break;
}
}
@@ -305,7 +305,7 @@ void redundant_init(struct eth_device *dev)
out_be32(®s->rstat, RSTAT_CLEAR_RHALT);
}
if (fail) {
- printf("loopback recv packet error!\n");
+ serial_printf("loopback recv packet error!\n");
clrbits_be32(®s->maccfg1, MACCFG1_RX_EN);
udelay(1000);
setbits_be32(®s->maccfg1, MACCFG1_RX_EN);
@@ -428,7 +428,7 @@ static int tsec_recv(struct eth_device *dev)
if (!(rtx.rxbd[rxIdx].status & RXBD_STATS)) {
NetReceive(NetRxPackets[rxIdx], length - 4);
} else {
- printf("Got error %x\n",
+ serial_printf("Got error %x\n",
(rtx.rxbd[rxIdx].status & RXBD_STATS));
}
--
1.7.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] net/tsec: Don't tell the link status if used with netconsole
Since we start/stop the network after each character we see that line
printed a lot.
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/net/tsec.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 78badfa..9af3c7e 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -235,9 +235,11 @@ static void adjust_link(struct tsec_private *priv, struct
phy_device *phydev)
out_be32(®s->ecntrl, ecntrl);
out_be32(®s->maccfg2, maccfg2);
- serial_printf("Speed: %d, %s duplex%s\n", phydev->speed,
- (phydev->duplex) ? "full" : "half",
- (phydev->port == PORT_FIBRE) ? ", fiber mode" : "");
+ if (strcmp(getenv("stdout"), "nc"))
+ serial_printf("Speed: %d, %s duplex%s\n", phydev->speed,
+ (phydev->duplex) ? "full" : "half",
+ (phydev->port == PORT_FIBRE) ? ", fiber mode"
+ : "");
}
#ifdef CONFIG_SYS_FSL_ERRATUM_NMG_ETSEC129
--
1.7.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] net/eth: set status to active before calling init
If we set the status after successful init call then we get in trouble
if stdout (or setderr) is set to netconsole. If we are going to use one
of those (lets say printf) during ->init() the following happens:
- network is of (state passive)
- we switch on netconsole
- nc_getc() gets called
- in NetLoop() we switch on ethernet via eth_init()
- we end up in tsec_init() (inc case we use the tsec driver). Here we
call a printf()
- That printf() ends up in nc_puts() because netconsole is our default
output.
- The state is not active yet, so we call eth_init() once again.
- and we are again in tsec_init(). Another printf() is waiting. However,
due to the recursion check nc_puts() returns early before doing
anything.
- we return from each function. Sine nc_puts() thinks that it was in
charge of enabling the ethernet, it disables it before leaving.
- We return now to the top-most eth_init() function. Since everything
went fine, it sets the status to active. In reality the network is
switched off.
- nc_getc() gets called over and over to receive new packets. Sadly the
nic is disabled and new network packets won't be noticed.
This patch sets the network status early so nc_puts() does not get
confused and disables the network interface in case of a printf() on its
way.
Signed-off-by: Sebastian Andrzej Siewior
---
net/eth.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/eth.c b/net/eth.c
index 4280d6d..bca405a 100644
--- a/net/eth.c
+++ b/net/eth.c
@@ -380,14 +380,17 @@ int eth_init(bd_t *bis)
old_current = eth_current;
do {
+ int old_state;
+
debug("Trying %s\n", eth_current->name);
- if (eth_current->init(eth_current,bis) >= 0) {
- eth_current->state = ETH_STATE_ACTIVE;
-
+ old_state = eth_current->state;
+ eth_current->state = ETH_STATE_ACTIVE;
+ if (eth_current->init(eth_current,bis) >= 0)
return 0;
- }
+
debug("FAIL\n");
+ eth_current->state = old_state;
eth_try_another(0);
} while (old_current != eth_current);
--
1.7.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NetConsole & TFTP
Dear Thomas, In message you wrote: > > Is it possible to use NetConsole and TFTP parallel at one Ethernet > interface? My fist thoughts were that this could be possible, because TFTP Yes, this is supposed to work. We've even seen running TFTP and Netconsole over Ethernet over USB... > and NetConsole use different ports. But out of the box the behavior is > different. In my tests TFTP tries to use another Ethernet interface > (eTSEC1) as the NetConsole (eTSEC0), but the final Hardware has only one Hm... you are not running mainline code, right? Because we always have a single network interface active at any time. > Therefore I need a possibility to communicate with a target (via > NetConsole) and transfer the flash images (via TFTP). Has anybody > experiences with this? Is this possible with U-Boot? Maybe I am doing > something wrong? I recommend you undo any modifications made to the network stack, and/or try plain mainline code instead. 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 Premature optimization is the root of all evil. -- D.E. Knuth ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] USB OTG host mode support in u-boot (Ethernet Over USB)
I am trying to get usb-ethernet dongle to work in u-boot but in order to get this to work I need to have the device in host mode. My current platform doesn't have USB host EHCI port but it has the micro OTG port and I have verified that keyboard/mouse/usb-ethernet all work on this port in Linux. But I have not been able to get ethernet over USB to work in u-boot (using Micro-A cable). Ethernet over USB is already supported in u-boot for the USB host but it seems that USB OTG support is missing from u-boot. Can someone advise or suggest a solution to get ethernet over USB to work in u-boot using USB OTG host? Thanks, Behnam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] NetConsole & TFTP
Hi all, I am trying to use the NetConsole to configure the U-Boot and to send command to it. Everything works fine, but I also need to transfer files via TFTP. It looks like that is a problem and I hope the members of this mailing list can give me some answers and maybe solutions. Is it possible to use NetConsole and TFTP parallel at one Ethernet interface? My fist thoughts were that this could be possible, because TFTP and NetConsole use different ports. But out of the box the behavior is different. In my tests TFTP tries to use another Ethernet interface (eTSEC1) as the NetConsole (eTSEC0), but the final Hardware has only one Ethernet and no serial interface. By the way, I tried the functionality with a second Ethernet interface and it also does not work. I see only less character at the NetConsole and it seems that the communication is going wrong and after a short time the communication is dead. Therefore I need a possibility to communicate with a target (via NetConsole) and transfer the flash images (via TFTP). Has anybody experiences with this? Is this possible with U-Boot? Maybe I am doing something wrong? Thank you for helping. Regards, Thomas SICK AG - Sitz: Waldkirch i. Br. - Handelsregister: Freiburg i. Br. HRB 280355 Vorstand: Dr. Robert Bauer (Vorsitzender) - Reinhard Bösl - Markus Paschmann - Markus Vatter Aufsichtsrat: Gisela Sick (Ehrenvorsitzende) - Klaus M. Bukenberger (Vorsitzender) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4][v2] powerpc/85xx:Make debug exception vector accessible
On 03/23/2012 06:44 AM, Prabhakar Kushwaha wrote: > Hi Scott, > > On Friday 23 March 2012 01:13 AM, Scott Wood wrote: >> On 03/22/2012 12:52 AM, Prabhakar Kushwaha wrote: >>> Hi Scott, >>> >>> Please find my reply in-lined >>> >>> On Thursday 22 March 2012 01:22 AM, Scott Wood wrote: On 03/20/2012 11:43 PM, Prabhakar Kushwaha wrote: > Debugging of e500 and e500v1 processer requires debug exception > vecter (IVPR + > IVOR15) to have valid and fetchable OP code. > > While executing in translated space (AS=1), whenever a debug > exception is > generated, the MSR[DS/IS] gets cleared i.e. AS=0 and the processor > tries to > fetch an instruction from the debug exception vector (IVPR + IVOR15); > since now > we are in AS=0, the application needs to ensure the proper TLB > configuration to > have (IVOR + IVOR15) accessible from AS=0 also. > > Create a temporary TLB in AS0 to make sure debug exception verctor is > accessible on debug exception. > > Signed-off-by: Radu Lazarescu > Signed-off-by: Marius Grigoras > Signed-off-by: Prabhakar Kushwaha Can you document the flow of exactly what TLB entries are present at various points of the boot flow, for all the various configurations (NOR boot, NAND SPL, RAMBOOT, IFC versus non-IFC, etc). >>> Sure. May be separate patch will be send. >> Let's start with just an e-mail thoroughly describing your understanding >> of this. It will provide necessary context for review. >> >> We can clean it up for permanent documentation once it's clear to >> everyone what's going on. > > Sure. I will start this activity from now. > But i will suggest not to combine both patches. let debugger patch to go > ahead , if required i will send required patch later-on. My point is that I cannot fully follow what's going on here without spending a bunch of time looking at it, and I don't see anyone else stepping up to review this, so I'd like to see a write-up of what's going on so that I can properly review these patches. In the ramboot case is this really supposed to be I+G? >>> I am not sure. But same is done under label "create_init_ram_area" for >>> TLB entry 15. >>> what you suggest. >> I suggest as part of the request to document all of this, you figure out >> what should actually be mapped in each configuration. The existing code >> might be wrong for some of them, but we shouldn't proceed ahead blindly >> and make an even bigger mess. >> > > After internal discussion we can have following settings > for non-RAMBOOT(NOR boot) ==> I + G > for RAMBOOT ==> I, cache inhibited is required as L1 cache is used as > stack. Why does using L1 for a stack mean that the mapping must be cache inhibited? Why do we even need to use L1 for a stack with ramboot? > I=0 it means the memory range is cacheable, so an access to an address > from that range could get the line in cache. If you are using the cache > as a memory zone(L1 as stack), it may overwrite some data in cache and > replace it with the last access. It will not do that -- when we use L1 (or part of it) for an early stack, we lock the cache lines. Which path will NAND SPL go through (not the payload, but the SPL itself)? That will be only a 4K window mapped, and guarded doesn't stop speculative instruction fetches, so we don't want to map more than is backed up by something. >>> NAND SPL go via !defined(CONFIG_SYS_RAMBOOT) path. >>> >>> i think NAND_SPL does not require temporary TLB as NAND SPL even does >>> not have any interrupt vector. >> So there's no plan to support using breakpoints or single step during >> the SPL? That's fine with me, but should be documented, and we should >> make sure this code does not run in that case. >> > > Breakpoints will work as it is. No impact will be on debugging for NAND > SPL. > > Generally any debugger use some initial configuration file. Only problem > occurs > when application modifies those configuration. Then why do we need to set MSR[DE] on entry, if the debugger can take care of it? > +lis r10,0xffc0@h > +ori r10,r10,0xffc0@l Don't waste instructions -- this could be in an SPL. That ori is a no-op. >>> Please refer above response. May be this piece of code is not required >>> for NAND SPL >> Still, I'd like to know why you're writing 0xffc0 to MAS7. Only the >> low 4 bits of MAS7 are valid on current e500. > > > The reason for using 0xffc0 to support e6500 - since it supports > 40-bit physical addresses, the last 8 bits of MAS7 are defined. Regardless, you're setting the wrong end of MAS7. It's the *lower* bits, not the upper bits, that are used. And we should not be doing anything special for e6500 here. e6500 does not need this, and e6500 platforms should not set CONFIG_SYS_PPC_E500_DEBUG_TLB. > But i am not sure whether e6500 will be part of mpc85xx or not. It will. > So, I will
Re: [U-Boot] [PATCH 1/1] MX53: DDR: Fix ZQHWCTRL field TZQ_CS
Hi Stefano, On Fri, Mar 23, 2012 at 6:34 AM, Stefano Babic wrote: > Is there someone who can answer to this question ? This patch fixes the > value according to the manual, without doubts. But if the manual is wrong... We are checking this internally at Freescale and will keep the list updated. Thanks, Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC v0 01/11] omap3+: Introduce
On Thu, Mar 22, 2012 at 09:48:27PM -0400, Jason Kridner wrote: > I'm reading/replying to these one-by-one for sanity/clarity with regards > to BeagleBoard... [snip] > >diff --git a/include/configs/omap3_beagle.h > >b/include/configs/omap3_beagle.h > >index 80b9a5a..21e4b01 100644 > >--- a/include/configs/omap3_beagle.h > >+++ b/include/configs/omap3_beagle.h > >@@ -29,16 +29,21 @@ > > #define __CONFIG_H > > > > /* > >- * High Level Configuration Options > >+ * Values that differ from platform defaults or are unspecified. > > */ > >-#define CONFIG_OMAP 1 /* in a TI OMAP core */ > >-#define CONFIG_OMAP34XX 1 /* which is a 34XX */ > >-#define CONFIG_OMAP3_BEAGLE 1 /* working with BEAGLE */ > >+#define CONFIG_SDRC /* The chip has SDRC controller */ > > > >-#define CONFIG_SDRC /* The chip has SDRC controller */ > > I can see it can make sense to have an OMAP/DM/AM3x target without SDRC > enabled. Er, right. That's why SDRC or EMIF is done per-board for us (omap4/5 are EMIF only and if we can honestly keep am335x at one config for all boards it'll just be opting in to later parts of these kind of series). -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] tegra: Specify debugging serial port at boot.
Hi Graeme,
On Thu, Mar 22, 2012 at 4:41 PM, Graeme Russ wrote:
> Hi Simon,
>
> On Fri, Mar 23, 2012 at 10:03 AM, Simon Glass wrote:
>
>> I am going to have a similar problem in the SPL soon - how to deal
>> with panic(). Advice gratefully accepted.
>
> Take a leaf out of the Linux x86 source
>
> arch/x86/boot/main.c - This is the start of the 16-bit 'real-mode' code
> which is entered by the boot loader (so it's like SPL - IPL being the
> BIOS/Bootloader combo)
>
> void main(void)
> {
> /* First, copy the boot header into the "zeropage" */
> copy_boot_params();
>
> /* Initialize the early-boot console */
> console_init();
> ...
>
>
> arch/x86/boot/early_serial_console.c
>
> void console_init(void)
> {
> parse_earlyprintk();
>
> if (!early_serial_base)
> parse_console_uart8250();
> }
>
> early_serial_base is a global defined in boot.h:
>
> extern int early_serial_base;
>
> You can do the same in SPL, but you are not going to have the luxury of
> having it configurable unless you can do so in some non-volatile memory
> or hardware configuration (dedicated GPIO pins etc)
>
> It's a chicken and egg scenario - If you want your default console port to
> be configurable, you need code to determine the configuration. But you
> cannot spew out debug messages for the code which determines the console
> configuration. Linux x86 has the same problem, there is no way to ouput
> debug messages in copy_boot_params() or console_init()
>
> In U-Boot we kind of 'cheat' - We define a board specific default console
> in the board config (hard coded in the U-Boot binary) which we use unitl
> environment variables are available. Linux x86 could do the same - have
> compile time options which allow the serial console to be enabled before
> copy_boot_params(), but the amount of code which is 'dark' is so small
> it's not worth it.
>
> U-Boot is different, the amount of code that is 'dark' before the
> environment variables are available is rather large. And pre console
> buffer covers the 'dark' code just prior to the hard-coded console being
> available (but of course pre console buffer does not help if there is a
> hang or crash before the hard-coded console is available)
Thanks very much for your comments.
Yes it is this dark period that bothers me. I think for now the
solution is to ignore it and hope that nothing goes wrong,
particularly with the revert of even the pre-console putc(). I think
for now I will provide an option to check the device tree later in the
boot, and later look at having some sort of fallback config for the
console.
>
> I should check - Is it possible to not have a default console, and
> therefor pre console buffer is used all the way up to the console defined
> in the environment being intialised?
I actually created a patch to delay console init until after
relocation, just to see how this might work. It works fine, and does
speed things up a little, but is of course not in keeping with the
U-Boot design.
Anyway all I am really concerned about is that we might not make it
through the dark period. For now I am going to forget about that
problem; there are plenty of others.
Regards,
Simon
>
> Regards,
>
> Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4][v2] powerpc/85xx:Make debug exception vector accessible
Hi Scott, On Friday 23 March 2012 01:13 AM, Scott Wood wrote: On 03/22/2012 12:52 AM, Prabhakar Kushwaha wrote: Hi Scott, Please find my reply in-lined On Thursday 22 March 2012 01:22 AM, Scott Wood wrote: On 03/20/2012 11:43 PM, Prabhakar Kushwaha wrote: Debugging of e500 and e500v1 processer requires debug exception vecter (IVPR + IVOR15) to have valid and fetchable OP code. While executing in translated space (AS=1), whenever a debug exception is generated, the MSR[DS/IS] gets cleared i.e. AS=0 and the processor tries to fetch an instruction from the debug exception vector (IVPR + IVOR15); since now we are in AS=0, the application needs to ensure the proper TLB configuration to have (IVOR + IVOR15) accessible from AS=0 also. Create a temporary TLB in AS0 to make sure debug exception verctor is accessible on debug exception. Signed-off-by: Radu Lazarescu Signed-off-by: Marius Grigoras Signed-off-by: Prabhakar Kushwaha Can you document the flow of exactly what TLB entries are present at various points of the boot flow, for all the various configurations (NOR boot, NAND SPL, RAMBOOT, IFC versus non-IFC, etc). Sure. May be separate patch will be send. Let's start with just an e-mail thoroughly describing your understanding of this. It will provide necessary context for review. We can clean it up for permanent documentation once it's clear to everyone what's going on. Sure. I will start this activity from now. But i will suggest not to combine both patches. let debugger patch to go ahead , if required i will send required patch later-on. In the ramboot case is this really supposed to be I+G? I am not sure. But same is done under label "create_init_ram_area" for TLB entry 15. what you suggest. I suggest as part of the request to document all of this, you figure out what should actually be mapped in each configuration. The existing code might be wrong for some of them, but we shouldn't proceed ahead blindly and make an even bigger mess. After internal discussion we can have following settings for non-RAMBOOT(NOR boot) ==> I + G for RAMBOOT ==> I, cache inhibited is required as L1 cache is used as stack. I=0 it means the memory range is cacheable, so an access to an address from that range could get the line in cache. If you are using the cache as a memory zone(L1 as stack), it may overwrite some data in cache and replace it with the last access. Which path will NAND SPL go through (not the payload, but the SPL itself)? That will be only a 4K window mapped, and guarded doesn't stop speculative instruction fetches, so we don't want to map more than is backed up by something. NAND SPL go via !defined(CONFIG_SYS_RAMBOOT) path. i think NAND_SPL does not require temporary TLB as NAND SPL even does not have any interrupt vector. So there's no plan to support using breakpoints or single step during the SPL? That's fine with me, but should be documented, and we should make sure this code does not run in that case. Breakpoints will work as it is. No impact will be on debugging for NAND SPL. Generally any debugger use some initial configuration file. Only problem occurs when application modifies those configuration. +lis r10,0xffc0@h +ori r10,r10,0xffc0@l Don't waste instructions -- this could be in an SPL. That ori is a no-op. Please refer above response. May be this piece of code is not required for NAND SPL Still, I'd like to know why you're writing 0xffc0 to MAS7. Only the low 4 bits of MAS7 are valid on current e500. The reason for using 0xffc0 to support e6500 - since it supports 40-bit physical addresses, the last 8 bits of MAS7 are defined. But i am not sure whether e6500 will be part of mpc85xx or not. So, I will use as #ifdef CONFIG_ENABLE_36BIT_PHYS lis r10,0x #endif +mtspr MAS0,r6 +mtspr MAS1,r7 +mtspr MAS2,r8 +mtspr MAS3,r9 +mtspr MAS7,r10 Why are you writing 0xffc0 into MAS7? Access to MAS7 needs to be conditional on CONFIG_ENABLE_36BIT_PHYS (misnamed, should be something like CONFIG_SYS_PPC_HAS_MAS7). i will put this code under #define CONFIG_ENABLE_36BIT_PHYS For your kind information : in start.S, label label "create_ccsr_new_tlb", "create_ccsr_old_tlb" uses MAS7 without CONFIG_ENABLE_36BIT_PHYS #define. It should be fixed ?? Yes, it should be fixed. That was a fairly recent change and perhaps e500v1 has not been tested since then -- Timur, could you look at this? i will use CONFIG_ENABLE_36BIT_PHYS defines. diff --git a/arch/powerpc/include/asm/config_mpc85xx.h b/arch/powerpc/include/asm/config_mpc85xx.h index 8654625..268c56e 100644 --- a/arch/powerpc/include/asm/config_mpc85xx.h +++ b/arch/powerpc/include/asm/config_mpc85xx.h @@ -1,5 +1,5 @@ /* - * Copyright 2011 Freescale Semiconductor, Inc. + * Copyright 2011-2012 Freescale Semiconductor, Inc. * * This program is free software; you can redistribute it and/or * modify it und
Re: [U-Boot] [PATCH] mx53ard: Initialize return code with error
On 20/03/2012 00:41, Fabio Estevam wrote: > The variable "rc" is the return of board_eth_init() function. Initialize > it with an error code, so that this function can return an error when > CONFIG_SMC911X is not set. > > Signed-off-by: Fabio Estevam > --- 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mx53: Make PLL2 to be the parent of UART clock
On 21/03/2012 16:42, Fabio Estevam wrote: > Change the parent UART clock to be PLL2, so that U-boot can also boot > a Freescale 2.6.35 kernel for mx53. > > FSL kernel and U-boot changed the UART parent from PLL3 to PLL2 to avoid > conflicts with IPU clocks, so that the video resolution can be changed > without affecting the UART clock. > > On a 2.6.35 kernel the serial console is messed up after IPU driver is loaded > and this patch fixes this problem. > > Tested on a mx53loco board booting a FSL kernel and also a mainline kernel. > > Reported-by: Otavio Salvador > Signed-off-by: Fabio Estevam > --- 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] MX53: DDR: Fix ZQHWCTRL field TZQ_CS
On 23/03/2012 04:25, Troy Kisky wrote: > On 3/22/2012 6:47 PM, Troy Kisky wrote: >> On 3/22/2012 3:00 PM, Troy Kisky wrote: >>> Currently, board files are setting this field to 0x01 >>> which the manual says is a reserved value. Change to >>> use the default of 0x04 - 128 cycles. >> Typo, should say default of 0x02 - 128 cycles >> > Possibly the manual is wrong, and the value of 0x01 corresponds > to 64 cycles? My testing was on a DDR2 device where this field > is not relevant. Is there someone who can answer to this question ? This patch fixes the value according to the manual, without doubts. But if the manual is wrong... 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] configs: imx: Use CONFIG_SF_DEFAULT_CS
On 23/03/2012 01:29, Fabio Estevam wrote: > CONFIG_SPI_FLASH_CS is not used anywhere. > > Use CONFIG_SF_DEFAULT_CS instead. > > Signed-off-by: Fabio Estevam > --- 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx28evk: Provide default values for SPI bus and chip select
On 23/03/2012 01:29, Fabio Estevam wrote: > From: Fabio Estevam > > Provide default values for SPI bus and chip select. > > This allows the command "sf probe" to work without passing SPI bus and chip > select numbers as arguments. > > Signed-off-by: Fabio Estevam > --- 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] configs: imx: Use CONFIG_SF_DEFAULT_CS
On 23/03/2012 10:18, Marek Vasut wrote: > > No, that's why I'm asking. And I see no use of CONFIG_SPI_FLASH_CS. All right > then: > > Acked-by: Marek Vasut Ok, then everything is clear. Acked-by: Stefano Babic 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] configs: imx: Use CONFIG_SF_DEFAULT_CS
Dear Stefano Babic, > On 23/03/2012 09:39, Marek Vasut wrote: > > Dear Fabio Estevam, > > > >> CONFIG_SPI_FLASH_CS is not used anywhere. > >> > >> Use CONFIG_SF_DEFAULT_CS instead. > >> > >> Signed-off-by: Fabio Estevam > >> --- > >> > >> include/configs/efikamx.h |2 +- > >> include/configs/m28evk.h |2 +- > >> include/configs/vision2.h |2 +- > >> 3 files changed, 3 insertions(+), 3 deletions(-) > >> > >> diff --git a/include/configs/efikamx.h b/include/configs/efikamx.h > >> index af542fa..120055f 100644 > >> --- a/include/configs/efikamx.h > >> +++ b/include/configs/efikamx.h > >> @@ -113,7 +113,7 @@ > >> > >> #define CONFIG_SPI_FLASH > >> #define CONFIG_SPI_FLASH_SST > >> > >> -#define CONFIG_SPI_FLASH_CS (1 | 121 << 8) > >> +#define CONFIG_SF_DEFAULT_CS (1 | 121 << 8) > >> > >> #define CONFIG_SF_DEFAULT_MODE(SPI_MODE_0) > >> #define CONFIG_SF_DEFAULT_SPEED 2500 > >> > >> diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h > >> index 4d59153..4b97c71 100644 > >> --- a/include/configs/m28evk.h > >> +++ b/include/configs/m28evk.h > >> @@ -252,7 +252,7 @@ > >> > >> #ifdefCONFIG_CMD_SF > >> #define CONFIG_SPI_FLASH > >> #define CONFIG_SPI_FLASH_STMICRO > >> > >> -#define CONFIG_SPI_FLASH_CS 2 > >> +#define CONFIG_SF_DEFAULT_CS2 > > > > are you sure about this? Are you sure this does the same thing? > > Are we sure that CONFIG_SPI_FLASH_CS has still a meaning ? It seems to > me that SPI flash uses now CONFIG_SF_DEFAULT_CS, and we should exchange > other boards exactly as Fabio does for mx28evk. Is there still code > using CONFIG_SPI_FLASH_CS ? No, that's why I'm asking. And I see no use of CONFIG_SPI_FLASH_CS. All right then: Acked-by: Marek Vasut > > Best regards, > Stefano Babic Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] configs: imx: Use CONFIG_SF_DEFAULT_CS
On 23/03/2012 09:39, Marek Vasut wrote: > Dear Fabio Estevam, > >> CONFIG_SPI_FLASH_CS is not used anywhere. >> >> Use CONFIG_SF_DEFAULT_CS instead. >> >> Signed-off-by: Fabio Estevam >> --- >> include/configs/efikamx.h |2 +- >> include/configs/m28evk.h |2 +- >> include/configs/vision2.h |2 +- >> 3 files changed, 3 insertions(+), 3 deletions(-) >> >> diff --git a/include/configs/efikamx.h b/include/configs/efikamx.h >> index af542fa..120055f 100644 >> --- a/include/configs/efikamx.h >> +++ b/include/configs/efikamx.h >> @@ -113,7 +113,7 @@ >> >> #define CONFIG_SPI_FLASH >> #define CONFIG_SPI_FLASH_SST >> -#define CONFIG_SPI_FLASH_CS (1 | 121 << 8) >> +#define CONFIG_SF_DEFAULT_CS(1 | 121 << 8) >> #define CONFIG_SF_DEFAULT_MODE (SPI_MODE_0) >> #define CONFIG_SF_DEFAULT_SPEED 2500 >> >> diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h >> index 4d59153..4b97c71 100644 >> --- a/include/configs/m28evk.h >> +++ b/include/configs/m28evk.h >> @@ -252,7 +252,7 @@ >> #ifdef CONFIG_CMD_SF >> #define CONFIG_SPI_FLASH >> #define CONFIG_SPI_FLASH_STMICRO >> -#define CONFIG_SPI_FLASH_CS 2 >> +#define CONFIG_SF_DEFAULT_CS2 > > are you sure about this? Are you sure this does the same thing? Are we sure that CONFIG_SPI_FLASH_CS has still a meaning ? It seems to me that SPI flash uses now CONFIG_SF_DEFAULT_CS, and we should exchange other boards exactly as Fabio does for mx28evk. Is there still code using CONFIG_SPI_FLASH_CS ? 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-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 05/14] cfb_console: Fix function console_scrollup
Hi, On Thu, 22 Mar 2012 01:58:02 -0700 (PDT) Pali Rohár wrote: ... > Do you think that mapped address of framebuffer is only problem? I wrote that it could be a problem. I do not know much about your system and U-Boot port and do not know exactly what you meant by "damaged screen output" and when exactly it happens, so I can only speculate. > Why > then framebuffer output on n900 screen working without problem if I > do NOT read framebuffer memory? Problem with garbaged display output > seems happends only for read operations (console_scrollup, negation > of pixels for cursor,...) but not for write-only operations (clear > console, clear line, set black/white cursror, render fonsts...). I > think if there is problem with address space, then garbaged screen > should be also for framebuffer write operations... This is another issue then. Can you test read/write access to the frame buffer area by available memory commands "cp", "md", "mm", "cmp"? Can you also verify that reading from frame buffer area by using these memory commands is not working? Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] configs: imx: Use CONFIG_SF_DEFAULT_CS
Dear Fabio Estevam, > CONFIG_SPI_FLASH_CS is not used anywhere. > > Use CONFIG_SF_DEFAULT_CS instead. > > Signed-off-by: Fabio Estevam > --- > include/configs/efikamx.h |2 +- > include/configs/m28evk.h |2 +- > include/configs/vision2.h |2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/include/configs/efikamx.h b/include/configs/efikamx.h > index af542fa..120055f 100644 > --- a/include/configs/efikamx.h > +++ b/include/configs/efikamx.h > @@ -113,7 +113,7 @@ > > #define CONFIG_SPI_FLASH > #define CONFIG_SPI_FLASH_SST > -#define CONFIG_SPI_FLASH_CS (1 | 121 << 8) > +#define CONFIG_SF_DEFAULT_CS (1 | 121 << 8) > #define CONFIG_SF_DEFAULT_MODE (SPI_MODE_0) > #define CONFIG_SF_DEFAULT_SPEED 2500 > > diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h > index 4d59153..4b97c71 100644 > --- a/include/configs/m28evk.h > +++ b/include/configs/m28evk.h > @@ -252,7 +252,7 @@ > #ifdef CONFIG_CMD_SF > #define CONFIG_SPI_FLASH > #define CONFIG_SPI_FLASH_STMICRO > -#define CONFIG_SPI_FLASH_CS 2 > +#define CONFIG_SF_DEFAULT_CS2 are you sure about this? Are you sure this does the same thing? > #define CONFIG_SF_DEFAULT_MODE SPI_MODE_0 > #define CONFIG_SF_DEFAULT_SPEED 2400 > > diff --git a/include/configs/vision2.h b/include/configs/vision2.h > index 35b71f7..f6904f3 100644 > --- a/include/configs/vision2.h > +++ b/include/configs/vision2.h > @@ -72,7 +72,7 @@ > * Use gpio 4 pin 25 as chip select for SPI flash > * This corresponds to gpio 121 > */ > -#define CONFIG_SPI_FLASH_CS (1 | (121 << 8)) > +#define CONFIG_SF_DEFAULT_CS (1 | (121 << 8)) > #define CONFIG_SF_DEFAULT_MODE SPI_MODE_0 > #define CONFIG_SF_DEFAULT_SPEED 2500 Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx28evk: Provide default values for SPI bus and chip select
Dear Fabio Estevam, > From: Fabio Estevam > > Provide default values for SPI bus and chip select. > > This allows the command "sf probe" to work without passing SPI bus and chip > select numbers as arguments. > > Signed-off-by: Fabio Estevam Acked-by: Marek Vasut > --- > include/configs/mx28evk.h |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/include/configs/mx28evk.h b/include/configs/mx28evk.h > index 04967d7..112fda4 100644 > --- a/include/configs/mx28evk.h > +++ b/include/configs/mx28evk.h > @@ -186,6 +186,8 @@ > /* SPI Flash */ > #ifdef CONFIG_CMD_SF > #define CONFIG_SPI_FLASH > +#define CONFIG_SF_DEFAULT_BUS2 > +#define CONFIG_SF_DEFAULT_CS 0 > /* this may vary and depends on the installed chip */ > #define CONFIG_SPI_FLASH_SST > #define CONFIG_SF_DEFAULT_MODE SPI_MODE_0 Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] BOOT: Add RAW ramdisk support to bootz
Dear Wolfgang Denk, > Dear Marek Vasut, > > In message <201203221745.16226.marek.va...@gmail.com> you wrote: > > > > Dear Wolfgang Denk, are we OK with applying this and bootz patch > > > > please? Can we get it into .04 release please? > > > > > > "this" - which patch version exactly are you referring to? > > > > Revision V6. > > Could you please be a bit more specific? Like posting a link to the > respective message on gmane, or in patchwork? http://patchwork.ozlabs.org/patch/146848/ http://patchwork.ozlabs.org/patch/147440/ > > The Subject: of this message is "BOOT: Add RAW ramdisk support to > bootz", but I have not seen any V6 for this patch. Ican only guess > that you might be referring to [PATCH V6] BOOT: Add "bootz" command to > boot Linux zImage on ARM - but I'd rather be sure. Yes, see above two links please. > > > I believe this patch is quite important to the linux-arm people and early > > adoption of this stuff would be very beneficial. Also, there are other > > patches that were applied after the MW was closed. Finally, this patch > > started long before .04 release cycle. > > Where/when? If you mean the patch, here: http://patchwork.ozlabs.org/patch/125318/ If you talk about accepting patches way past MW, almost all the time, at least in the ARM stuffs. And this works OK so far I believe, I see no breakage. Also, we didn't reach the RC phase yet either. Lastly, this change is not intrusive in any way. > > Best regards, > > Wolfgang Denk Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
