Dear Timur Tabi,
In message <4bfd837d.2040...@freescale.com> you wrote:
> Wolfgang Denk wrote:
> > It appears you really haven't bothered checking. We have been using
> > it on PowerPC since day 1 - for well over 10 years by now. On many,
> > many systems. Get a clue!
>
> I've looked at get_ram_s
Dear Kumar Gala,
In message <1274433478-31849-2-git-send-email-ga...@kernel.crashing.org> you
wrote:
> The new is_serdes_configured covers a broader range of devices than the
> PCI specific code. Use it instead as we convert away from the
> is_fsl_pci_cfg() code.
>
> Additionally move to settin
On May 27, 2010, at 2:08 AM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message <1274433478-31849-2-git-send-email-ga...@kernel.crashing.org> you
> wrote:
>> The new is_serdes_configured covers a broader range of devices than the
>> PCI specific code. Use it instead as we convert away from
Dear Wolfgang Denk,
Yes, it is true.
Currently only for ARMs and i386.
Best Regards,
Alan
On 5/27/10, Wolfgang Denk wrote:
> Dear Alan Carvalho de Assis,
>
> In message
> you wrote:
>> Hi Mark,
>>
>> On 5/27/10, Mark Fanara wrote:
>> ...
>> >
>> > 2) I am using a bdi3000. Is there no way to
Hi All,
Can I expect a reply from seniors who might have faced this kind of issue?
If anyone have faced this kind of issue earlier. Please reply.
Thanks in advance.
Regards,
Prakash
On Tue, May 25, 2010 at 12:45 PM, prakash bedge wrote:
> Hi,
>
>
>
> I am using u-boot as Bootloader for my PP
Dear Kumar Gala,
In message <5f58de0b-6ef8-4ed6-a1a8-c0e37c853...@kernel.crashing.org> you wrote:
>
> This is my fault. However not sure what to do about it since we'd break
> compatibility with kernel .dts to clean this up.
>
> 99% of the u-boot code should match the HW docs. In this one plac
As my target board is PowerPC based (and therefore skipping relocation
is not possible), I need help with my previously enumerated questions.
1) In section 10.4, Tips and Tricks, it says "To prevent GDB from
jumping around in the code when trying to single step, i. e. when it
seems as if the code
On May 27, 2010, at 6:20 AM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message <5f58de0b-6ef8-4ed6-a1a8-c0e37c853...@kernel.crashing.org> you
> wrote:
>>
>> This is my fault. However not sure what to do about it since we'd break
>> compatibility with kernel .dts to clean this up.
>>
>>
Dear Mark Fanara,
In message you
wrote:
> As my target board is PowerPC based (and therefore skipping relocation
> is not possible), I need help with my previously enumerated questions.
>
> 1) In section 10.4, Tips and Tricks, it says "To prevent GDB from
> jumping around in the code when tryin
Dear Kumar Gala,
In message <7d2ba6a1-2eef-4bf5-8b76-07ad55537...@kernel.crashing.org> you wrote:
>
> > i. e. the highest number is at the lowest address??
>
> Correct, that is matching FSL HW docs numbering/naming.
>
> in the .dts the alias:
> * "pci0" is @ 0x8000 - FSL HW calls it PCIE3
> * "p
Hi all,
I would like to automate the kernel and filesystem loading using the u-boot
instructions.
Basically, I would start the loading process from a remote system such as a
pc computer for example, and then take some actions depending of the log
this pc would receive from the target.
Is there a w
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Pet Harp
> Sent: Thursday, May 27, 2010 7:12 PM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] Bootoloader remote automation
>
> Hi all,
>
> I would like to automate the kern
Wolfgang Denk wrote:
>> I've looked at get_ram_size(), and I don't think I can use it.
>
> Then fix it, please.
Let me guess, you won't accept my patch until I fix get_ram_size() first and
use it, right?
>> We use phys_addr_t to represent DDR sizes, which is a 64-bit integer on the
>> P1022DS.
On May 27, 2010, at 8:20 AM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message <7d2ba6a1-2eef-4bf5-8b76-07ad55537...@kernel.crashing.org> you
> wrote:
>>
>>> i. e. the highest number is at the lowest address??
>>
>> Correct, that is matching FSL HW docs numbering/naming.
>>
>> in the .d
Dear Pet Harp,
In message you
wrote:
>
> I would like to automate the kernel and filesystem loading using the u-boot
> instructions.
No problem. This has been done many, many times before, including
completely automatic production systems.
> Basically, I would start the loading process from a
get_ram_size() used to use "long" data types for addresses and data,
which in limited it to systems with less than 4 GiB memory. As more
and more systems are coming up with bigger memory resources, we adapt
the code to use phys_addr_t / phys_size_t data types instead.
Signed-off-by: Wolfgang Denk
Dear Timur Tabi,
In message <4bfe823a.1080...@freescale.com> you wrote:
>
> >> I've looked at get_ram_size(), and I don't think I can use it.
> >
> > Then fix it, please.
>
> Let me guess, you won't accept my patch until I fix get_ram_size() first and
> use it, right?
Do you think this is an u
get_ram_size() used to use "long" data types for addresses and data,
which limited it to systems with less than 4 GiB memory. As more and
more systems are coming up with bigger memory resources, we adapt the
code to use phys_addr_t / phys_size_t data types instead.
Signed-off-by: Wolfgang Denk
Cc
On Thu, May 27, 2010 at 1:11 PM, Wolfgang Denk wrote:
> get_ram_size() used to use "long" data types for addresses and data,
> which in limited it to systems with less than 4 GiB memory. As more
> and more systems are coming up with bigger memory resources, we adapt
> the code to use phys_addr_t /
Wolfgang Denk wrote:
> Do you think this is an unreasonable request? A quick fix takes me
> less than it takes to write this email (see following patch).
Fixing get_ram_size() is not a quick fix. We would need to implement a
temporary TLB mechanism for accessing memory above 2GB, and a machine
Dear Wolfgang Denk,
as the systems I was working on always had far less memory, I can
not comment much on the extension you propose here, but as Timur
Tabi's comments seem to go in a direction which could lead to a
bigger overhaul/discussion, I would like to add 2C from my point
of view on coldfir
On Thu, May 27, 2010 at 01:25:38PM -0500, Timur Tabi wrote:
> Wolfgang Denk wrote:
>
> > Do you think this is an unreasonable request? A quick fix takes me
> > less than it takes to write this email (see following patch).
>
> Fixing get_ram_size() is not a quick fix. We would need to implement
Hi,
2010/5/26 Sergei Shtylyov :
> create_pipe() can give wrong result if an expression is passed as the
> 'endpoint'
> argument -- due to missing parentheses.
>
> Thanks to Martin Mueller for finding the bug and providing the patch.
>
> Signed-off-by: Sergei Shtylyov
>
> ---
> include/usb.h |
Scott Wood wrote:
> Passing the actual, known size of RAM (why guess when we know?) as "maxsize"
> should eliminate the machine check problem[1] -- you'd just be using it as a
> not particularly exhaustive memory tester. I don't see why it should be
> mandatory.
The purpose of get_ram_size() is
The following changes since commit 01f03bda5b22e5aeae5f02fd537da97a41485c73:
Wolfgang Denk (1):
Prepare v2010.06-rc1
are available in the git repository at:
git://git.denx.de/u-boot-usb.git master
Sergei Shtylyov (1):
USB: fix create_pipe()
include/usb.h |2 +-
1 files ch
On 05/27/2010 02:07 PM, Timur Tabi wrote:
> Scott Wood wrote:
>
>> Passing the actual, known size of RAM (why guess when we know?) as "maxsize"
>> should eliminate the machine check problem[1] -- you'd just be using it as a
>> not particularly exhaustive memory tester. I don't see why it should be
On Thu, May 27, 2010 at 07:45:16AM -0500, Kumar Gala wrote:
>
> On May 27, 2010, at 6:20 AM, Wolfgang Denk wrote:
>
> > Dear Kumar Gala,
> >
> > In message <5f58de0b-6ef8-4ed6-a1a8-c0e37c853...@kernel.crashing.org> you
> > wrote:
> >>
> >> This is my fault. However not sure what to do about i
Dear Timur Tabi,
In message you
wrote:
> On Thu, May 27, 2010 at 1:11 PM, Wolfgang Denk wrote:
> > get_ram_size() used to use "long" data types for addresses and data,
> > which in limited it to systems with less than 4 GiB memory. As more
> > and more systems are coming up with bigger memory r
Dear Timur Tabi,
In message <4bfeb922.9040...@freescale.com> you wrote:
>
> > Do you think this is an unreasonable request? A quick fix takes me
> > less than it takes to write this email (see following patch).
>
> Fixing get_ram_size() is not a quick fix. We would need to implement a
> tempor
On Thu, May 27, 2010 at 08:16:28PM +0200, Wolfgang Denk wrote:
> get_ram_size() used to use "long" data types for addresses and data,
> which limited it to systems with less than 4 GiB memory. As more and
> more systems are coming up with bigger memory resources, we adapt the
> code to use phys_add
Dear Wolfgang Wegner,
In message <20100527185909.gg31...@leila.ping.de> you wrote:
>
> as the systems I was working on always had far less memory, I can
> not comment much on the extension you propose here, but as Timur
> Tabi's comments seem to go in a direction which could lead to a
> bigger ov
Dear Scott Wood,
In message <20100527190340.ga5...@schlenkerla.am.freescale.net> you wrote:
>
> Passing the actual, known size of RAM (why guess when we know?) as "maxsize"
> should eliminate the machine check problem[1] -- you'd just be using it as a
> not particularly exhaustive memory tester.
Dear Timur Tabi,
In message <4bfec2fd.5050...@freescale.com> you wrote:
>
> > It also doesn't handle non-power-of-two sized memory -- don't rely on the
> > value it returns.
>
> Ah, that's a serious limitation.
No, it is not. Testing is done per bank.
Best regards,
Wolfgang Denk
--
DENX Sof
Wolfgang Denk wrote:
> We don't have machine check handlers on the other PPC systems either.
> We kust make sure that the mapping is big enough for the maximal RAM
> size we are going to test.
What if the mapping is too big? Isn't the whole point of get_ram_size()
that there is less RAM than we
Dear Scott Wood,
In message <4bfec39e.7040...@freescale.com> you wrote:
>
> Attempting to experimentally determine whether you have more than you
> claim is dangerous.
It's not. Actually it allows to detect certain classes of errors.
Best regards,
Wolfgang Denk
--
DENX Software Engineering
Dear Scott Wood,
In message <20100527194618.gc5...@schlenkerla.am.freescale.net> you wrote:
> On Thu, May 27, 2010 at 08:16:28PM +0200, Wolfgang Denk wrote:
> > get_ram_size() used to use "long" data types for addresses and data,
> > which limited it to systems with less than 4 GiB memory. As more
On 05/27/2010 02:57 PM, Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message<20100527194618.gc5...@schlenkerla.am.freescale.net> you wrote:
>> On Thu, May 27, 2010 at 08:16:28PM +0200, Wolfgang Denk wrote:
>>> get_ram_size() used to use "long" data types for addresses and data,
>>> which limited
Dear Timur Tabi,
In message <4bfecdf7.4070...@freescale.com> you wrote:
>
> What if the mapping is too big? Isn't the whole point of get_ram_size()
> that there is less RAM than we say there is? That is, if there's only 1GB
> of RAM, and we do this:
get_ram_size() will also detect a number of h
Wolfgang Denk wrote:
>> The problem is that on all of our PowerPC boards, the TLBs only map
>> the lower 2GB of memory, regardless as to how much is present. So we
>> still can't use get_ram_size() to determine how much memory is in the
>> system, because any attempt to access memory higher than
Wolfgang Denk wrote:
>> It also doesn't handle non-power-of-two sized memory -- don't rely on the
>> value it returns.
>
> Such configurations are usually set up of from several differently
> sized banks of memory, and get_ram_size() is always run per bank. So
> as long as chip manufacturers cont
On 05/27/2010 02:53 PM, Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message<20100527190340.ga5...@schlenkerla.am.freescale.net> you wrote:
>>
>> Passing the actual, known size of RAM (why guess when we know?) as "maxsize"
>> should eliminate the machine check problem[1] -- you'd just be using i
On 05/27/2010 02:44 PM, Wolfgang Denk wrote:
> Dear Timur Tabi,
>
> In message you
> wrote:
>> On Thu, May 27, 2010 at 1:11 PM, Wolfgang Denk wrote:
>>> get_ram_size() used to use "long" data types for addresses and data,
>>> which in limited it to systems with less than 4 GiB memory. As more
>>
On 05/27/2010 03:00 PM, Wolfgang Denk wrote:
> Dear Timur Tabi,
>
> In message<4bfecdf7.4070...@freescale.com> you wrote:
>>
>> What if the mapping is too big? Isn't the whole point of get_ram_size()
>> that there is less RAM than we say there is? That is, if there's only 1GB
>> of RAM, and we d
Wolfgang Denk wrote:
>> Ah, that's a serious limitation.
>
> No, it is not. Testing is done per bank.
Ok, I get it now. I'm supposed to call get_ram_size() on each DIMM I
locate. That's going to be complicated because we don't have any TLBs set
up when we do that.
And what if we have a 4GB DI
Dear Scott Wood,
In message <4bfecf43.40...@freescale.com> you wrote:
>
> > Isn't phys_addr_t assumed to be the right data type to hold a
> > physical address?
>
> Yes. But you can't dereference a physical address directly.
Ah, right. OK, so this needs more work...
Best regards,
Wolfgang Den
Dear Timur Tabi,
In message <4bfecf82.60...@freescale.com> you wrote:
>
> Scott pointed out that writing/reading memory to determine how much memory
> actually exists is dangerous. I'm not convinced that I should be using
> get_ram_size(). I still believe that I shouldn't.
And I point out that
Dear Timur Tabi,
In message <4bfed01f.1040...@freescale.com> you wrote:
>
> > Such configurations are usually set up of from several differently
> > sized banks of memory, and get_ram_size() is always run per bank. So
> > as long as chip manufacturers continue to make RAM chips with
> > power-of-
Dear Scott Wood,
In message <4bfed090.1040...@freescale.com> you wrote:
>
> If you set maxsize beyond what you expect to find, how are you going to
> constrain it to operating on one bank?
Maybe it helps if you read section "System Initialization" in teh
README; this explains the original design
Wolfgang Denk wrote:
> The systems I know are the opposite - initially they map more memory
> than they support, then they determine the real size, then they
> adjust the mapping to the real size.
But we don't ever do that, at least not on systems that use SPD. We query
the DIMMs directly via SPD
Dear Scott Wood,
In message <4bfed0cd.5010...@freescale.com> you wrote:
>
> Not using get_ram_size(), which is of minimal utility when you know the
> actual size (and is an unsafe approach to the problem when you don't,
> unless you know a lot about where I/O is mapped and how the system
> resp
On May 27, 2010, at 3:57 PM, Wolfgang Denk wrote:
> Dear Timur Tabi,
>
> In message <4bfecf82.60...@freescale.com> you wrote:
>>
>> Scott pointed out that writing/reading memory to determine how much memory
>> actually exists is dangerous. I'm not convinced that I should be using
>> get_ram_si
Dear Timur Tabi,
In message <4bfed1ea.5060...@freescale.com> you wrote:
>
> So I have a question: are you still going to require me to use
> get_ram_size() in my P1022DS board patch?
I never *reqired* this.
All I wrote was:
| > + puts("DDR: ");
| > + return dram_size;
|
| How about usi
Dear Timur Tabi,
In message <4bfede90.6070...@freescale.com> you wrote:
> Wolfgang Denk wrote:
> > The systems I know are the opposite - initially they map more memory
> > than they support, then they determine the real size, then they
> > adjust the mapping to the real size.
>
> But we don't eve
Dear Kumar Gala,
In message <48a9b08d-9237-4837-91ca-0d23ce1e5...@kernel.crashing.org> you wrote:
>
> > The systems I know are the opposite - initially they map more memory
> > than they support, then they determine the real size, then they
> > adjust the mapping to the real size.
>
> Is the poi
The top level Makefile is growing and growing. Once, when we
supported only a few tens of boards, it was possible to implement
board configuration logic in the Makefile, but it quickly turned out
that this doesn't scale. Also, it is not really needed (at least not
any more) - we now have mechanisnm
Instead of adding explicit build rules for each and every board to the
top level Makefile (which makes it grow and grow), we now provide a
simple default rule and extend the "mkconfig" script to read board
configurations from a plain text file (table), "boards.cfg".
For simple boards it is now suf
On May 27, 2010, at 2:38 PM, Scott Wood wrote:
> On Thu, May 27, 2010 at 07:45:16AM -0500, Kumar Gala wrote:
>>
>> On May 27, 2010, at 6:20 AM, Wolfgang Denk wrote:
>>
>>> Dear Kumar Gala,
>>>
>>> In message <5f58de0b-6ef8-4ed6-a1a8-c0e37c853...@kernel.crashing.org> you
>>> wrote:
Kumar Gala wrote:
> We can do something like:
>
> for (hose = hose_head; hose; hose = hose->next) {
> off = fdt_node_offset_by_compatible(blob, -1, pci_compat);
> while (off != -FDT_ERR_NOTFOUND) {
> const int reg * = fdt_getprop(blob, off
On Fri, May 21, 2010 at 4:17 AM, Kumar Gala wrote:
> if (pcie_configured && !(devdisr & MPC85xx_DEVDISR_PCIE2)) {
> + set_next_law(CONFIG_SYS_PCIE2_MEM_PHYS, LAW_SIZE_512M,
> + LAW_TRGT_IF_PCIE_2);
> + set_next_law(CONFIG_SYS_PCIE2_
Thomas,
> The old nios arch is obsolete and the build has been broken for a long
> time. Shall we remove it from u-boot?
I'm in favor of removing the nios-32 code. It's been a very long
time since I had a customer using nios-32 -- never mind nios-32 u-boot.
If nobody objects, let's get rid of i
Scott McNutt wrote:
> Thomas,
>
>> The old nios arch is obsolete and the build has been broken for a long
>> time. Shall we remove it from u-boot?
>
> I'm in favor of removing the nios-32 code. It's been a very long
> time since I had a customer using nios-32 -- never mind nios-32 u-boot.
>
> I
Wolfgang Denk wrote:
> The top level Makefile is growing and growing. Once, when we
> supported only a few tens of boards, it was possible to implement
> board configuration logic in the Makefile, but it quickly turned out
> that this doesn't scale. Also, it is not really needed (at least not
> any
The nios-32 arch is obsolete and broken. So it is removed.
Signed-off-by: Thomas Chou
---
Deleted files are snipped.
The following changes since commit 01f03bda5b22e5aeae5f02fd537da97a41485c73:
Wolfgang Denk (1):
Prepare v2010.06-rc1
are available in the git repository at:
git://sopc
When set to PULL_NONE, gpio_set_pull function is returned without write the
register.
This patch fixed it.
Signed-off-by: Minkyu Kang
---
drivers/gpio/s5p_gpio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpio/s5p_gpio.c b/drivers/gpio/s5p_gpio.c
index 0439
Follow the discussion of Charles Manning and Mike Frysinger.
Using gc_sections helps reduce image size.
Configuring for nios2-generic board...
Before,
textdata bss dec hex filename
1239793724 22892 150595 24c43 /tmp/u-boot/u-boot
After,
textdata bss dec
Dear Tom,
Could you please update ARM machine types?
I will post the new board that is named goni,
but mach-types is not updated.
Thanks.
Minkyu Kang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi Wolfgang,
> Note:
> I had to disable the simple and very convenient rule
> %: %_config
> $(MAKE)
> in the top level Makefile, because it caused each invocation
> of "make" to fail with an error message:
>
> make: *** No rule
On Fri, 2010-05-28 at 00:13 -0500, Peter Tyser wrote:
> Hi Wolfgang,
>
>
>
> > Note:
> > I had to disable the simple and very convenient rule
> > %: %_config
> > $(MAKE)
> > in the top level Makefile, because it caused each invocation
> > of "make" to
Scott McNutt wrote:
> I tested on the 1c20 this evening as well ... works fine. I will test on
> the 2c35 board tomorrow. I'd like to get a positive confirmation WRT the
> 1S10 and 1S40 before applying this patch.
Hi Scott,
Please follow up this patch.
Best regards,
Thomas
__
69 matches
Mail list logo
