New u-boot available, needs new MLO
Koen Kooi
There's a new u-boot available at http://www.angstrom-distribution.org/demo/beagleboard/u-boot.bin and it needs a matching MLO, available at http://www.angstrom-distribution.org/demo/beagleboard/MLO . Without the MLO it will have during ram/nand detection.
New stuff in MLO:
* version 1.44ss from Steve Sakomans tree
* falls back to serial boot if mmc and nand fail
* prints beagleboard revision on serial
New stuff in u-boot:
* version 2010.03-rc1 from Steve Sakomans tree
* beagleboard RevB, RevC[1234], xM[1] support
* autodetects all the boards in http://www.elinux.org/BeagleBoardPinMux#Vendor_and_Device_IDs and sets up mux according for zippy1 and zippy2
Stuff that's missing compared to previous u-boot:
* DSS initialization, so now logo or orange screen on boot
Patches to add back the orange screen would be greatly appreciated!
If you are designing an expansion board and want to be supported in uboot, please have a look at http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=946351081bd14e8bf5816fc38b82e004a0e6b4fe and send a patch to add your boards. If a patch is too mux work, at least add your vendor and board id into the wiki.
I don't know how well this approach scales, but this code is available *now* which beats all the pie-in-the-sky ideas out there.
regards,
Koen
[1] Some bugs need to get ironed out for the xM, but I'm able to boot into the angstrom GNOME desktop and use DSP, SGX, NEON, etc
h...@computer.org
this is all good news. But I have some suggestions to make life easier
for those who do not just want to install some binaries but compile
from scratch and/or do some non-public extensions.
BR,
Nikolaus
On 27 Mrz., 11:56, Koen Kooi <k...@beagleboard.org> wrote:
> Hi,
>
> There's a new u-boot available
++
> at http://www.angstrom-distribution.org/demo/beagleboard/u-boot.binand it needs a matching MLO, available athttp://www.angstrom-distribution.org/demo/beagleboard/MLO. Without the MLO it will have during ram/nand detection.
Where are the sources of your binary u-boot.bin?
>
> New stuff in MLO:
>
> * version 1.44ss from Steve Sakomans tree
> * falls back to serial boot if mmc and nand fail
++
> * prints beagleboard revision on serial
-- I don't think this is really a good idea. Each time there will be a
new version of a Beagleboard, now there will be a different version of
MLO - increasing confusion IMHO. And, the MLO is no tied exactly to
the BeagleBoard and its version detection logic. I usually suggest the
Divide&Conquer approach: keep modules independent and universal.
And, can you please post a link to the sources of the MLO?
> New stuff in u-boot:
>
> * version 2010.03-rc1 from Steve Sakomans tree
What does this change and/or improve?
> * beagleboard RevB, RevC[1234], xM[1] support
++
> * autodetects all the boards inhttp://www.elinux.org/BeagleBoardPinMux#Vendor_and_Device_IDsand sets up mux according for zippy1 and zippy2
++
> Stuff that's missing compared to previous u-boot:
> * DSS initialization, so now logo or orange screen on boot
--
> Patches to add back the orange screen would be greatly appreciated!
Hm. This makes this new version quite useless compared to the previous
for all those who don't have a XM board yet.
>
> If you are designing an expansion board and want to be supported in uboot, please have a look athttp://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h...and send a patch to add your boards. If a patch is too mux work, at least add your vendor and board id into the wiki.
Koen Kooi
Op 27 mrt 2010, om 13:00 heeft h...@computer.org het volgende geschreven:
> Hi Koen,
> this is all good news. But I have some suggestions to make life easier
> for those who do not just want to install some binaries but compile
> from scratch and/or do some non-public extensions.
Everything is available from OpenEmbedded if you want to build from source.
h...@computer.org
> Everything is available from OpenEmbedded if you want to build from source.
Although that is true, it needs a lot of reverse engineering of OE...
Not everyone can or wants to use OE (e.g. does not run natively on Mac
OS X). Relying an open source project only on one specific build
system could be considered a major project risk...
Therefore I would suggest that the latest (patched) sources for
creating a binary are just saved as a .tbz besides the pure binary.
And (essentially off-topic for this list): why not provide for OE some
web tool similar to http://www.angstrom-distribution.org/repo that
allows to browse and download recipies and the source codes linked by
the files list?
But I don't want to rant, just create some awareness of aspects to
consider for future releases (which I really appreciate!).
Nikolaus
Koen Kooi
Op 27 mrt 2010, om 18:27 heeft h...@computer.org het volgende geschreven:
>
>> Everything is available from OpenEmbedded if you want to build from source.
>
> Although that is true, it needs a lot of reverse engineering of OE...
> Not everyone can or wants to use OE (e.g. does not run natively on Mac
> OS X). Relying an open source project only on one specific build
> system could be considered a major project risk...
Yes, having u-boot rely on 'make' is a big risk indeed.
> Therefore I would suggest that the latest (patched) sources for
> creating a binary are just saved as a .tbz besides the pure binary.
Feel free to do so.
> And (essentially off-topic for this list): why not provide for OE some
> web tool similar to http://www.angstrom-distribution.org/repo that
> allows to browse and download recipies and the source codes linked by
> the files list?
Feel free to write such a tool.
h...@computer.org
> Op 27 mrt 2010, om 18:27 heeft h...@computer.org het volgende geschreven:
>
>
>
> >> Everything is available from OpenEmbedded if you want to build from source.
>
> > Although that is true, it needs a lot of reverse engineering of OE...
> > Not everyone can or wants to use OE (e.g. does not run natively on Mac
> > OS X). Relying an open source project only on one specific build
> > system could be considered a major project risk...
>
> Yes, having u-boot rely on 'make' is a big risk indeed.
make is POSIX and available on MacOS X (as well as gnumake through
MacPorts) while OE relies on bitbake and many other tools which
aren't. And the URLs of the sources and patches are hidden somewhere.
I just ask to make the sources available in the same easy way to
access as the binary.
Running make isn't a problem then.
>
> > Therefore I would suggest that the latest (patched) sources for
> > creating a binary are just saved as a .tbz besides the pure binary.
>
> Feel free to do so.
I can only do if you tell me where the sources of your specific binary
are.
BTW, there is already a directory at:
http://www.angstrom-distribution.org/demo/beagleboard/u-boot/
but it is not up-to-date with u-boot.bin
>
> > And (essentially off-topic for this list): why not provide for OE some
> > web tool similar tohttp://www.angstrom-distribution.org/repothat
> > allows to browse and download recipies and the source codes linked by
> > the files list?
>
> Feel free to write such a tool.
If you write such a tool you would no longer have to answer my
questions where the sources are :)
Please take my questions as an appreciation of your work - otherwise I
would not care about getting the sources...
Ben Gamari
> On 27 Mrz., 19:31, Koen Kooi <k...@beagleboard.org> wrote:
> I just ask to make the sources available in the same easy way to
> access as the binary.
>
> Running make isn't a problem then.
>
http://www.denx.de/wiki/U-Boot/SourceCode
> >
> > > Therefore I would suggest that the latest (patched) sources for
> > > creating a binary are just saved as a .tbz besides the pure binary.
> >
> > Feel free to do so.
>
> I can only do if you tell me where the sources of your specific binary
> are.
>
For this, you'll need to look at the recipe, which really isn't that tough to
find. In the openembedded tree, you want the /recipes/u-boot (IIRC) directory.
I suspect, however, that the recipe simply configures u-boot with the correct
machine type. Just a guess though.
> > Feel free to write such a tool.
>
> If you write such a tool you would no longer have to answer my
> questions where the sources are :)
>
> Please take my questions as an appreciation of your work - otherwise I
> would not care about getting the sources...
>
Good luck.
- Ben
Michael Zucchi
> On 27 Mrz., 19:31, Koen Kooi <k...@beagleboard.org> wrote:
>> Op 27 mrt 2010, om 18:27 heeft h...@computer.org het volgende geschreven:
>> > Therefore I would suggest that the latest (patched) sources for
>> > creating a binary are just saved as a .tbz besides the pure binary.
>>
>> Feel free to do so.
>
> I can only do if you tell me where the sources of your specific binary
> are.
Isn't das u-boot licensed under the GNU GPL version 2?
Somehow I don't think `* version 2010.03-rc1 from Steve Sakomans tree'
cuts it as far as the binary distribution requirements go. Nor does
`Everything is available from OpenEmbedded if you want to build from
source.'
Particularly for version 2, section 3 - either clause a) - include
complete corresponding source, or b) include a written offer valid for
3 years to get the source (by mail!), must apply when distributing
binaries you created. And somehow I don't think you wish to use
clause b) (and I see no written offer), so the easiest solution (and
only legal way remaining) is just to include the complete sources
along with the binary (and `in the same place', by the last paragraph
of section 3).
GNU GPL Version 3 section 6 relaxes and more clearly defines these
requirements a bit, including version controlled sources/different
servers, but even than you need to provide clear instructions on where
to get the complete source used to create that binary (and the above
still doesn't cut it). In any event none of that applies here unless
you're distributing it under gpl3 instead (I don't think it's all 'or
later version' though so i guess it can't be anyway).
Distributing source is one thing, but as soon as you distribute
binaries other clauses kick in.
Dr. H. Nikolaus Schaller
Am 28.03.2010 um 16:30 schrieb Ben Gamari:
> On Sun, 28 Mar 2010 00:24:25 -0700 (PDT), "h...@computer.org" <h...@computer.org
> > wrote:
>> On 27 Mrz., 19:31, Koen Kooi <k...@beagleboard.org> wrote:
>> I just ask to make the sources available in the same easy way to
>> access as the binary.
>>
>> Running make isn't a problem then.
>>
> Perhaps you are looking for this?
>
> http://www.denx.de/wiki/U-Boot/SourceCode
Thanks but unfortunately no. I am looking for the specific version and
patches that made up the new U-Boot and MLO binaries that have been
announced for download at the beginning of this thread.
For the version before this one I did have the right sources and after
some tweaking I could compile them myself to understand and make
modifications for my project.
But now there is a new binary version made from unknown sources (I
just got the hint: "it is all in OE") - and therefore I can't apply my
own patches and use an unknown binary. Or I have to continue without
the latest changes. Or I have to reverse engineer OE. Neither option
looks attractive to me, doesn't it?
>
>>>
>>>> Therefore I would suggest that the latest (patched) sources for
>>>> creating a binary are just saved as a .tbz besides the pure binary.
>>>
>>> Feel free to do so.
>>
>> I can only do if you tell me where the sources of your specific
>> binary
>> are.
>>
> For this, you'll need to look at the recipe, which really isn't that
> tough to
> find. In the openembedded tree, you want the /recipes/u-boot (IIRC)
> directory.
This requires to download the full OE tree just to find 2 files where
the information is located (I think there is a downloads list and a
patches list within each recipe). Maybe, someone who already has OE
installed can send me the (latest!) version of the recipies of U-Boot
and the new MLO.
> I suspect, however, that the recipe simply configures u-boot with
> the correct
> machine type. Just a guess though.
Most probably it is so for the real build phase. But that is not my
issue - it is getting the correct source package.
In my view and experience the complexity nowadays lies in the
multitude of different source repositories and how easy it became to
make new and only slightly differing versions. Tracking down the
correct sources has become more complex by that. OE tries to make life
easy by having a central list of this information. Which is a very
good idea. But it adds one level of complexity to all those who do not
just want to or can not use the OE magics.
Up to some years ago the task I am trying to do was simple: each
project did have a FTP server where the sources were happily sorted by
version number as a project-version-src.tar.gz.
>
>>> Feel free to write such a tool.
>>
>> If you write such a tool you would no longer have to answer my
>> questions where the sources are :)
>>
>> Please take my questions as an appreciation of your work -
>> otherwise I
>> would not care about getting the sources...
>>
>
> Good luck.
Thanks!
-- Nikolaus
Paul Menzel
[…]
> This requires to download the full OE tree just to find 2 files where
> the information is located (I think there is a downloads list and a
> patches list within each recipe). Maybe, someone who already has OE
> installed can send me the (latest!) version of the recipies of U-Boot
> and the new MLO.
If you do not want to clone the OE repository you can browse the
repository too [1].
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/u-boot
[…]
Thanks,
Paul
Koen Kooi
And the GPLv2 also mentions buildscripts, so pointing to OE is the only valid option for me. Both the OE tree and the tarballs snapshots from the git tree used to build them are on the angstrom server, which satisfies the GPL. There's no clause in the GPL that says one needs to cater to special wishes for people refusing to use various tools.
According to the opensource review board distributing sources + OE is enough to satisfy the GPL, and that's exactly the case here.
And GPL hairsplitting aside, how hard is it to google up the git tree? Using "sakomans u-boot tree" as query seems to do the trick for me.
regards,
Koen
Ben Gamari
> Am 28.03.2010 um 16:30 schrieb Ben Gamari:
> > Perhaps you are looking for this?
> >
> > http://www.denx.de/wiki/U-Boot/SourceCode
>
> Thanks but unfortunately no. I am looking for the specific version and
> patches that made up the new U-Boot and MLO binaries that have been
> announced for download at the beginning of this thread.
>
http://www.sakoman.com/cgi-bin/gitweb.cgi?p=x-loader.git;a=summary
> For the version before this one I did have the right sources and after
> some tweaking I could compile them myself to understand and make
> modifications for my project.
>
> But now there is a new binary version made from unknown sources (I
> just got the hint: "it is all in OE") - and therefore I can't apply my
> own patches and use an unknown binary. Or I have to continue without
> the latest changes. Or I have to reverse engineer OE. Neither option
> looks attractive to me, doesn't it?
The announcement tells you exactly where the sources came from (Steve Sakoman's
tree). If you are making modifications to u-boot, then you probably ought to
just be tracking Steve's tree directly anyways. It will make life substantially
easier when it comes time to rebase (i.e. now).
>
> > For this, you'll need to look at the recipe, which really isn't that
> > tough to
> > find. In the openembedded tree, you want the /recipes/u-boot (IIRC)
> > directory.
>
> This requires to download the full OE tree just to find 2 files where
> the information is located (I think there is a downloads list and a
> patches list within each recipe). Maybe, someone who already has OE
> installed can send me the (latest!) version of the recipies of U-Boot
> and the new MLO.
>
Nope, gitweb (err, cgit) is your friend,
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/u-boot
> > I suspect, however, that the recipe simply configures u-boot with
> > the correct
> > machine type. Just a guess though.
>
> Most probably it is so for the real build phase. But that is not my
> issue - it is getting the correct source package.
>
> In my view and experience the complexity nowadays lies in the
> multitude of different source repositories and how easy it became to
> make new and only slightly differing versions. Tracking down the
> correct sources has become more complex by that.
It really isn't that difficult. You simply need to read. The announcement told
you exactly where to look.
> OE tries to make life easy by having a central list of this information.
> Which is a very good idea. But it adds one level of complexity to all those
> who do not just want to or can not use the OE magics. Up to some years ago
> the task I am trying to do was simple: each project did have a FTP server
> where the sources were happily sorted by version number as a
> project-version-src.tar.gz.
>
And now it's even easier.
$ git clone <repo>
$ git checkout <branch/tag> (optional)
So to recap, it's not difficult, you simply need to know where to look. There
is absolutely nothing magical about OE, it's just a convenient way to compile
things. Granted, the few patches still held in OE should be upstreamed, but
there's probably good reason for waiting that I'm not aware of and none of them
appear to be all that crucial.
Cheers,
- Ben
Ben Gamari
> Isn't das u-boot licensed under the GNU GPL version 2?
>
> Somehow I don't think `* version 2010.03-rc1 from Steve Sakomans tree'
> cuts it as far as the binary distribution requirements go. Nor does
> `Everything is available from OpenEmbedded if you want to build from
> source.'
>
to need to build your own image, then you
a) Shouldn't be using this image
b) Should know how to use Google
c) Shouldn't mind spending 20 seconds using it
Sure, the announcement could have included a URL to Steve's git repo, but
really, this isn't rocket science.
- Ben
Dr. H. Nikolaus Schaller
Am 28.03.2010 um 18:08 schrieb Ben Gamari:
> On Sun, 28 Mar 2010 16:56:03 +0200, "Dr. H. Nikolaus Schaller" <h...@computer.org
> > wrote:
>> Am 28.03.2010 um 16:30 schrieb Ben Gamari:
>>> Perhaps you are looking for this?
>>>
>>> http://www.denx.de/wiki/U-Boot/SourceCode
>>
>> Thanks but unfortunately no. I am looking for the specific version
>> and
>> patches that made up the new U-Boot and MLO binaries that have been
>> announced for download at the beginning of this thread.
>>
> So you are looking for Steve Sakoman's git tree? Google can help you
> there.
> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=x-loader.git;a=summary
If that is now the official one? After going through the Wiki it said
me "Note: For experimental U-Boot patches not ready for mainline yet,
Steve's Beagle U-Boot git repository is used to test them."
So if the new Angstrom U-Boot is based on that (without patches), does
it
* include Khasims C4 patches?
* is stable enough to be the official U-Boot?
BTW: the old binary was simply overwritten and is no longer available
(but fortunately I have a copy).
>
>> For the version before this one I did have the right sources and
>> after
>> some tweaking I could compile them myself to understand and make
>> modifications for my project.
>>
>> But now there is a new binary version made from unknown sources (I
>> just got the hint: "it is all in OE") - and therefore I can't apply
>> my
>> own patches and use an unknown binary. Or I have to continue without
>> the latest changes. Or I have to reverse engineer OE. Neither option
>> looks attractive to me, doesn't it?
>
> The announcement tells you exactly where the sources came from
> (Steve Sakoman's
> tree). If you are making modifications to u-boot, then you probably
> ought to
> just be tracking Steve's tree directly anyways. It will make life
> substantially
> easier when it comes time to rebase (i.e. now).
Is this now the official tree? Just 3 weeks ago I tried to find out
that and was directed between:
http://elinux.org/BeagleBoard#Source: git clone git://git.denx.de/u-
boot.git u-boot-main
by recent discussion about the C4 patches: http://gitorious.org/beagleboard-default-u-boot/
>
>>
>>> For this, you'll need to look at the recipe, which really isn't that
>>> tough to
>>> find. In the openembedded tree, you want the /recipes/u-boot (IIRC)
>>> directory.
>>
>> This requires to download the full OE tree just to find 2 files where
>> the information is located (I think there is a downloads list and a
>> patches list within each recipe). Maybe, someone who already has OE
>> installed can send me the (latest!) version of the recipies of U-Boot
>> and the new MLO.
>>
>
> Nope, gitweb (err, cgit) is your friend,
>
> http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/u-boot
Oh, this is a really nice idea!
>
>
>>> I suspect, however, that the recipe simply configures u-boot with
>>> the correct
>>> machine type. Just a guess though.
>>
>> Most probably it is so for the real build phase. But that is not my
>> issue - it is getting the correct source package.
>>
>> In my view and experience the complexity nowadays lies in the
>> multitude of different source repositories and how easy it became to
>> make new and only slightly differing versions. Tracking down the
>> correct sources has become more complex by that.
>
> It really isn't that difficult. You simply need to read. The
> announcement told
> you exactly where to look.
Maybe, but I did not understand the message...
>
>> OE tries to make life easy by having a central list of this
>> information.
>> Which is a very good idea. But it adds one level of complexity to
>> all those
>> who do not just want to or can not use the OE magics. Up to some
>> years ago
>> the task I am trying to do was simple: each project did have a FTP
>> server
>> where the sources were happily sorted by version number as a
>> project-version-src.tar.gz.
>>
> And now it's even easier.
> $ git clone <repo>
> $ git checkout <branch/tag> (optional)
>
> So to recap, it's not difficult, you simply need to know where to
> look. There
Exactly, that is what I mean with "difficult" (situation). Knowing or
finding out where to look. Not difficult commands.
> is absolutely nothing magical about OE, it's just a convenient way
> to compile
> things. Granted, the few patches still held in OE should be
> upstreamed, but
So, please can anyone tell me what the official "upstream" is? That is
what I try to find out and the more I looks and ask around the more
repositories are there.
> there's probably good reason for waiting that I'm not aware of and
> none of them
> appear to be all that crucial.
Now I think I get what the real problem is: there are too many
outdated pointers around where sources are or could be.
> Cheers,
>
> - Ben
>
Tnx,
Nikolaus
Koen Kooi
To be fair, a pointer to a remote git repo isn't enough for the GPLv2, especially considering that 'git rebase' will loose history and one can't count on 3rd parties to stop their harddisk from crashing for the next 3 years.
But as you said, if you want to develop against those sources instead of merely exercising your GPL rights, google is extremely helpfull.
regards,
Koen
h...@computer.org
On 28 Mrz., 18:13, Ben Gamari <bgamari.f...@gmail.com> wrote:
> On Mon, 29 Mar 2010 01:04:45 +1030, Michael Zucchi <not...@gmail.com> wrote:
> > Isn't das u-boot licensed under the GNU GPL version 2?
>
> > Somehow I don't think `* version 2010.03-rc1 from Steve Sakomans tree'
> > cuts it as far as the binary distribution requirements go. Nor does
> > `Everything is available from OpenEmbedded if you want to build from
> > source.'
>
> Oh, please. Must we? These images are merely for convenience. If you know enough
For whose convenience? I would like to be included in this group :)
> to need to build your own image, then you
>
> a) Shouldn't be using this image
> b) Should know how to use Google
> c) Shouldn't mind spending 20 seconds using it
As usual: you can only find what you know you are looking for. And
googling for "source code of beagleboard u-boot" gives you around 4000
hits. Funnily enough the second one I see says: "Please don't use
below code and binaries any more, they are outdated! Outdated REV B
source for Beagle Board."
>
> Sure, the announcement could have included a URL to Steve's git repo, but
> really, this isn't rocket science.
No, isn't. But only if you understand:
a) there is a "Steve's git repo" (I have never heared or used that
before - now as I know I found the rare pointers)
b) the new u-boot and MLO are 100% taken from that. Quite honestly, I
thought that there are some patches by Steve and they have been
included in some other mystic repository I was trying to trace down.
Finally, I did understand what appeared very obvious to others...
Have a nice time,
Nikolaus
Michael Zucchi
> On Mon, 29 Mar 2010 01:04:45 +1030, Michael Zucchi <not...@gmail.com> wrote:
>> Isn't das u-boot licensed under the GNU GPL version 2?
>>
>> Somehow I don't think `* version 2010.03-rc1 from Steve Sakomans tree'
>> cuts it as far as the binary distribution requirements go. Nor does
>> `Everything is available from OpenEmbedded if you want to build from
>> source.'
>>
> Oh, please. Must we? These images are merely for convenience. If you know enough
> to need to build your own image, then you
Well sure you must - this is part of the LICENSE.
Of course you don't have to distribute binaries, but since that is
what was chose, there is no choice in the matter.
Tarter Giovanni
On 27 Mar, 12:56, Koen Kooi <k...@beagleboard.org> wrote:
> Hi,
>
> There's a new u-boot available athttp://www.angstrom-distribution.org/demo/beagleboard/u-boot.binand it needs a matching MLO, available athttp://www.angstrom-distribution.org/demo/beagleboard/MLO. Without the MLO it will have during ram/nand detection.
>
> New stuff in MLO:
>
> * version 1.44ss from Steve Sakomans tree
> * falls back to serial boot if mmc and nand fail
> * prints beagleboard revision on serial
>
> New stuff in u-boot:
>
> * version 2010.03-rc1 from Steve Sakomans tree
> * beagleboard RevB, RevC[1234], xM[1] support
> * autodetects all the boards inhttp://www.elinux.org/BeagleBoardPinMux#Vendor_and_Device_IDsand sets up mux according for zippy1 and zippy2
>
> Stuff that's missing compared to previous u-boot:
> * DSS initialization, so now logo or orange screen on boot
>
> Patches to add back the orange screen would be greatly appreciated!
>
> If you are designing an expansion board and want to be supported in uboot, please have a look athttp://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h...and send a patch to add your boards. If a patch is too mux work, at least add your vendor and board id into the wiki.
>
> I don't know how well this approach scales, but this code is available *now* which beats all the pie-in-the-sky ideas out there.
>
> regards,
>
> Koen
>
> [1] Some bugs need to get ironed out for the xM, but I'm able to boot into the angstrom GNOME desktop and use DSP, SGX, NEON, etc
Hi
I downloaded u-boot and MLO from the link above and i put them inside
the boot partition in my SD but I can't get them working.
Are there issues with Beaglebord Rev C2?
This is my log from the serial console:
Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
Reading boot sector
Loading u-boot.bin from mmc
U-Boot 2010.03-rc1 (Mar 30 2010 - 13:46:26)
OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max clock-600Mhz
OMAP3 Beagle board + LPDDR/NAND
I2C: ready
and then nothing more.
I suppose it's the same problem that happen with the wrong MLO but I
get the MLO from the link above.
Regards,
Giovanni
Nilly
I have used this u-boot.bin and MLO.I am using beagle board B7 but
still I am getting bogo mips 498.
M I missing something.
I have read that one can achieve bogo mips up to 5XX.
Regards,
Nilly
On Apr 6, 4:07 am, Tarter Giovanni <giml...@gmail.com> wrote:
> On 27 Mar, 12:56, Koen Kooi <k...@beagleboard.org> wrote:
>
>
>
>
>
> > Hi,
>
> > There's a new u-boot available athttp://www.angstrom-distribution.org/demo/beagleboard/u-boot.binandit needs a matching MLO, available athttp://www.angstrom-distribution.org/demo/beagleboard/MLO. Without the MLO it will have during ram/nand detection.
>
> > New stuff in MLO:
>
> > * version 1.44ss from Steve Sakomans tree
> > * falls back to serial boot if mmc and nand fail
> > * prints beagleboard revision on serial
>
> > New stuff in u-boot:
>
> > * version 2010.03-rc1 from Steve Sakomans tree
> > * beagleboard RevB, RevC[1234], xM[1] support
> > * autodetects all the boards inhttp://www.elinux.org/BeagleBoardPinMux#Vendor_and_Device_IDsandsets up mux according for zippy1 and zippy2
>
> > Stuff that's missing compared to previous u-boot:
> > * DSS initialization, so now logo or orange screen on boot
>
> > Patches to add back the orange screen would be greatly appreciated!
>
> > If you are designing an expansion board and want to be supported in uboot, please have a look athttp://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h...send a patch to add your boards. If a patch is too mux work, at least add your vendor and board id into the wiki.
>
> > I don't know how well this approach scales, but this code is available *now* which beats all the pie-in-the-sky ideas out there.
>
> > regards,
>
> > Koen
>
> > [1] Some bugs need to get ironed out for the xM, but I'm able to boot into the angstrom GNOME desktop and use DSP, SGX, NEON, etc
>
> Hi
>
> I downloaded u-boot and MLO from the link above and i put them inside
> the boot partition in my SD but I can't get them working.
> Are there issues with Beaglebord Rev C2?
>
> This is my log from the serial console:
>
> Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
> Reading boot sector
> Loading u-boot.bin from mmc
>
> U-Boot 2010.03-rc1 (Mar 30 2010 - 13:46:26)
>
> OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max clock-600Mhz
> OMAP3 Beagle board + LPDDR/NAND
> I2C: ready
>
> and then nothing more.
> I suppose it's the same problem that happen with the wrong MLO but I
> get the MLO from the link above.
>
> Regards,
> Giovanni- Hide quoted text -
>
> - Show quoted text -
Maxim Podbereznyy
I got that too, but I found the solution :)
You must hold the USER button pressed during a power-on. I think this is because of the MLO file which is booted from the NAND.
regards,
Max
--
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagl...@googlegroups.com.
To unsubscribe from this group, send email to beagleboard...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
Nilly
How much you are getting in bogo mips in
cat /proc/cpuinfo
Regards,
Niral
On Apr 6, 10:48 am, Maxim Podbereznyy <lisar...@gmail.com> wrote:
> Hi!
>
> I got that too, but I found the solution :)
> You must hold the USER button pressed during a power-on. I think this is
> because of the MLO file which is booted from the NAND.
>
> regards,
> Max
>
> 2010/4/6 Tarter Giovanni <giml...@gmail.com>
> > beagleboard...@googlegroups.com<beagleboard%2Bunsubscribe@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/beagleboard?hl=en.- Hide quoted text -
Koen Kooi
Op 6 apr 2010, om 01:07 heeft Tarter Giovanni het volgende geschreven:
> On 27 Mar, 12:56, Koen Kooi <k...@beagleboard.org> wrote:
>> New stuff in MLO:
>>
>> * version 1.44ss from Steve Sakomans tree
[..]
> This is my log from the serial console:
>
> Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
That's not the MLO you just downloaded, but another one.
regards,
Koen
Robert Nelson
> the boot partition in my SD but I can't get them working.
> Are there issues with Beaglebord Rev C2?
>
> This is my log from the serial console:
>
> Texas Instruments X-Loader 1.4.2 (Feb 19 2009 - 12:01:24)
> Reading boot sector
> Loading u-boot.bin from mmc
>
>
> U-Boot 2010.03-rc1 (Mar 30 2010 - 13:46:26)
>
> OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max clock-600Mhz
> OMAP3 Beagle board + LPDDR/NAND
> I2C: ready
>
> and then nothing more.
> I suppose it's the same problem that happen with the wrong MLO but I
> get the MLO from the link above.
>
Just ran into this too this morning... Hit and hold the user button
while pushing the reset button..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/