All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Baumgartner <josef.baumgartner@telex.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] tftpboot of BIG file fails !
Date: Tue, 27 Jan 2004 15:38:37 +0100	[thread overview]
Message-ID: <200401271538.38025.josef.baumgartner@telex.de> (raw)
In-Reply-To: <20040127065737.CB062C108D@atlas.denx.de>

On Tuesday 27 January 2004 07:57, Wolfgang Denk wrote:
> In message <01a401c3e2a9$c29a0510$6706a8c0@Rupesh> you wrote:
> > I find a typical problem downloading a BIG ( 4MB) linux image to the
> > SDRAM
>
> I don't think this is a typical problem. On contrary, it  is  a  very
> UNtypical  problem  since  this has always been working fine on many,
> many boards.
>
> > using u-boot's  _tftpboot_ command.
> > The Linux image is Linked at 0x20000.
>
> Then your Linux image is broken. You must  not  change  the  kernel's
> link  address  unless you know exactly what you are doing. This means
> that for example on PowerPC the kernel will be linked  for  (virtual)
> address 0xC0000000 and started at (physical) address 0x00000000.

Seems to be uClinux for Motorola Coldfire. Therefore it's ok.

>
> > My u-boot is liked at 0x3e0000 (I understaood this from the following two
> > macros)
> > TEXT_BASE = 0x3E0000
> > CFG_MONITOR_BASE = 0x3E0000
>
> Then your port of U-Boot is seriously broken.
>
> I would like to point out that NONE  of  the  configurations  in  the
> public source tree uses such a broken definition.

In the current Coldfire 5272 port u-boot will be loaded to 0x3e0000 by colilo
and started there.

>
> > So I reconfigured the macros to link the u-boot on _top_ of the SDRAM
> > (SDRAM map is 0x00000000 to 0x01000000)
>
> A correctly configured U-Boot will automatically copy itself  at  the
> end of the RAM (at least on PPC).

Yes, in my new 5272 port u-boot relocates itself to the end of RAM.

>
> > But still I face the problem of not able to download the BIG image.
>
> You probably have other problems in your port.
>
> > Dows the tftp boot itself restrict the size of the file to be downloaded
> > ?
>
> Yes. The current implementation puts a limit at 16 MB.
>
> Best regards,
>
> Wolfgang Denk


Best regards,

Josef Baumgartner

      reply	other threads:[~2004-01-27 14:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-24 18:42 [U-Boot-Users] tftpboot of BIG file fails ! Rupesh S
2004-01-27  6:57 ` Wolfgang Denk
2004-01-27 14:38   ` Josef Baumgartner [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200401271538.38025.josef.baumgartner@telex.de \
    --to=josef.baumgartner@telex.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.