From: ich <contumax@gmx.at>
To: u-boot@lists.denx.de
Subject: [U-Boot] Boot uboot from another position in flash
Date: Wed, 10 Aug 2011 16:52:26 +0200 [thread overview]
Message-ID: <1312987946.10498.8.camel@debian> (raw)
In-Reply-To: <20110803192104.8830E11EEDB3@gemini.denx.de>
Am Mittwoch, den 03.08.2011, 21:21 +0200 schrieb Wolfgang Denk:
> Dear ich,
>
> In message <1312383540.4776.36.camel@debian> you wrote:
> >
> > I know that. But I am not able to port for sh platform to a newer
> > u-boot.
> >
> > > Please note that U-Boot v1.3.1 is about 4 years old and as such no
> > > longer supported here.
>
> Your quoting style is strange. Normally the reply _follows_.
>
> Well, if you cannot update, then we cannot help it either. It's yur
> problem, after all.
>
> [Well, of course there are companies that will happily send you a
> quotation for such an update, in case you are considering a commercial
> solution.]
>
> > > U-Boot is, in it's default configuration, designed to be run on a
> > > virgin CPU comingg fresh out of reset, so it naturally has to be
> > > installed at the reset vector of your processor. In addition to the
> > > start address, many parts of the initialization code expect to find a
> > > vorgin, uninitialized system. Such parts must be disabled when you
> > > want to change the conditions under which you want to run U-Boot.
> >
> > I read this several time in the net, but found no solution.
> > I know it is possible, because I saw it in a flash hex-file, but can't
> > reproduce it.
> > I thought changing CFG_MONITOR_BASE / CFG_RESET_ADDRESS would do it.
>
> As mentioned, this is NOT sufficient. See also the FAQ.
It is absolutly not necessary to change CFG_MONITOR_BASE /
CFG_RESET_ADDRESS !
>
> > Do you say it's not easily possible to boot u-boot from another flash
> > address even with a newer u-boot????
>
> It is possible, and it is not so difficult if you have sufficient
> experience with U-Boot.
>
> > Do I have to make big changes to the uboot-source (start.S,..)?
>
> This depends on your definition of "big". Judging from the questions
> you are asking, I tend to say: too big for you. No offence meant.
There is no need to change anything in u-Boot source for my platform.
Judging from the answers you give, I tend to say: Don't answer
questions, wich are too big for you.
> > I could put ~256 bytes of assembly code to the reset-vector at
> > 0x0A000000 and jmp in the u-boot; but if you say this is not enough, I
> > will not start to learn the assembly language for my processor.
>
> This has nothing to do with using assembly code.
It was only an assembly code problem.
I can now start U-Boot from every position in flash I want.
contumax
prev parent reply other threads:[~2011-08-10 14:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-03 12:49 [U-Boot] Boot uboot from another position in flash ich
2011-08-03 13:16 ` Wolfgang Denk
2011-08-03 14:59 ` ich
2011-08-03 19:21 ` Wolfgang Denk
2011-08-10 14:52 ` ich [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=1312987946.10498.8.camel@debian \
--to=contumax@gmx.at \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox