Hello,
Month ago, during 11.05 release testing, we had a case when Pandaboard didn't boot with one particular build and one particular card, while worked well with with other combinations.
During this test cycle, I hit similar conditions, which I however was able to trace to the following: if at the moment of reset/boot, there's a cable connected from Panda USB OTG (small) connector to host, it won't boot from SD. The D2 LED will light for about a second, then both will be off. Nothing is output on serial. As soon as you unplug cable from the host, all boots again.
I'm not sure if this is a known condition, but guessed I'd share it.
On 06/29/2011 07:58 PM, Somebody in the thread at some point said:
Hi -
Month ago, during 11.05 release testing, we had a case when Pandaboard didn't boot with one particular build and one particular card, while worked well with with other combinations.
During this test cycle, I hit similar conditions, which I however was able to trace to the following: if at the moment of reset/boot, there's a cable connected from Panda USB OTG (small) connector to host, it won't boot from SD. The D2 LED will light for about a second, then both will be off. Nothing is output on serial. As soon as you unplug cable from the host, all boots again.
I'm not sure if this is a known condition, but guessed I'd share it.
How old's your x-loader / MLO?
I wrote a patch 97bb3ce0ca014aff9ad9f35f2b78f3976bf276f6 to solve this back in February, it's in Gitorious x-loader repo
http://gitorious.org/x-loader/x-loader/commit/97bb3ce0ca014aff9ad9f35f2b78f3...
If you try an updated x-loader with that in, if the mUSB port is powered it'll just pause 2sec on start then start as normal from SD card.
-Andy
On Wed, 29 Jun 2011 21:33:18 +0100 Andy Green andy.green@linaro.org wrote:
On 06/29/2011 07:58 PM, Somebody in the thread at some point said:
Hi -
Month ago, during 11.05 release testing, we had a case when Pandaboard didn't boot with one particular build and one particular card, while worked well with with other combinations.
During this test cycle, I hit similar conditions, which I however was able to trace to the following: if at the moment of reset/boot, there's a cable connected from Panda USB OTG (small) connector to host, it won't boot from SD. The D2 LED will light for about a second, then both will be off. Nothing is output on serial. As soon as you unplug cable from the host, all boots again.
I'm not sure if this is a known condition, but guessed I'd share it.
How old's your x-loader / MLO?
I'm testing Linaro Android 11.06 releases: http://releases.linaro.org/platform/linaro-n/android/11.06/
I get:
Texas Instruments X-Loader 1.4.4ss (Mar 18 2011 - 14:14:59)
Btw I don't yet fully understand Panda boot architecture. This X-Loader appear to come from SD card. But what boots it then? How that piece is called, where it comes from, how it should be upgraded, and is that ever needed? I found this: https://gforge.ti.com/gf/project/omapzoom/wiki/?pagename=BootingAndFlashing but it's still a bit confusing (like, doesn't name that first loader, and from OS perspective, it appears to be 3-stage boot).
I wrote a patch 97bb3ce0ca014aff9ad9f35f2b78f3976bf276f6 to solve this back in February, it's in Gitorious x-loader repo
http://gitorious.org/x-loader/x-loader/commit/97bb3ce0ca014aff9ad9f35f2b78f3...
If you try an updated x-loader with that in, if the mUSB port is powered it'll just pause 2sec on start then start as normal from SD card.
Android builds use:
<project name="x-loader" path="device/linaro/x-loader" remote="omapzoom" revision="eb8b047c29a2027fbdd841cd1289fa27ddb22d72"/>
which is HEAD of master, and master is oldest branch, not updated in 10months (hmm, that doesn't explain why it says Mar 18 2011).
So, it would be nice if you could suggest Android team which repo/branch/tag/revision can be safely used to produce releases.
-Andy
Thanks, Paul
Paul,
On Thu, Jun 30, 2011 at 12:06 AM, Paul Sokolovsky < paul.sokolovsky@linaro.org> wrote:
Btw I don't yet fully understand Panda boot architecture. This X-Loader appear to come from SD card. But what boots it then? How that piece is called, where it comes from, how it should be upgraded, and is that ever needed? I found this: https://gforge.ti.com/gf/project/omapzoom/wiki/?pagename=BootingAndFlashing but it's still a bit confusing (like, doesn't name that first loader, and from OS perspective, it appears to be 3-stage boot).
on panda, you have an OMAP4430 processor. on power up, the very first s/w which is executed is the OMAP ROM code. this piece of code sits in the OMAP4 ROM. it cannot be changed by definition. the device initialization is described at lenght in the OMAP4 TRM that you can find here: http://pandaboard.org/node/224/#manual, chapter "Device init by ROM Code"
The TI ROM code offers support for multiple boot options. One can boot from SD which is the most common case with panda, but you can boot from USB, eMMC, serial, ... the boot sequence order is defined through the SYSBOOT pins. if i remember correctly, the default boot sequence on panda, is USB then SD. This can be changed with resistors as explained here: http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBUQFjAA&...
the ROM code is unable to access DDR since it doesn't know anything about the DDR settings. the main goal of the ROM code is to locate the 'first stage' bootloader which it will copy into internal memory, in our case this is x-loader (aka MLO). The sole purpose of xloader (in theory) is to initialize the DDR, locate the 2nd stage bootloader (uboot in our case) , copy uboot into DDR and start it. we need xloader because uboot is too big to fit into internal RAM, unfortunately.
lately there has been some community effort around a tool that would let you boot your panda over USB from your desktop (without the SD), see https://github.com/swetland/omap4boot or http://groups.google.com/group/pandaboard/browse_thread/thread/f73e5e6c7127b...
hope this clarifies.
On 06/29/2011 11:06 PM, Somebody in the thread at some point said:
Hi -
Btw I don't yet fully understand Panda boot architecture. This X-Loader appear to come from SD card. But what boots it then? How that piece is called, where it comes from, how it should be upgraded, and is that ever needed? I found this: https://gforge.ti.com/gf/project/omapzoom/wiki/?pagename=BootingAndFlashing but it's still a bit confusing (like, doesn't name that first loader, and from OS perspective, it appears to be 3-stage boot).
Nicolas already gave a rundown but the short answer is the ROM can drive the MMC hardware of the OMAP4, talk SD-HC protocol, parse your partition table and FAT filesystem on your SD Card, and will load and execute a file of the magic name "MLO" on partition 1.
That is "x-loader", which sets stuff up and loads and executes a magic file "u-boot.bin" off partition 1. And "u-boot" does its usual thing from then on.
ROM being ROM, it can't be upgraded, however, unlike in OMAP3 the ROM in OMAP4 stuff seems pretty much perfect for SD Card boot case, it doesn't care about any arcane stuff like geometry for example. It only needs to success to pull MLO reliably and anything further can be done there in an upgradeable way.
Of course, it'll pull anything called MLO. I believe folks are working on adding stuff to be able to call U-Boot "MLO" directly eliminating x-loader and Matt Hsu and I already did that for Qi.
So, it would be nice if you could suggest Android team which repo/branch/tag/revision can be safely used to produce releases.
Yeah confusing ain't it. There are two camps in x-loader development one on omapzoom and one on gitorious. TI engineers like omapzoom but the official repo is gitorious.
The magic branch I (and I believe Ubuntu) use is:
git://gitorious.org/x-loader/x-loader.git master
... and BTW, 3.0 android kernel from us requires MLO update from what you supply at the moment to this in order for 3D unit to start up. So this is a good idea anyway.
-Andy
Andy Green wrote:
ROM being ROM, it can't be upgraded, however, unlike in OMAP3 the ROM in OMAP4 stuff seems pretty much perfect for SD Card boot case, it doesn't care about any arcane stuff like geometry for example. It only needs to success to pull MLO reliably and anything further can be done there in an upgradeable way.
neither does the OMAP3 ROM code. All the cargo cult around geometry stems from the fact that initially x-loader aka MLO hardcoded sector 63 for the start of the boot partition and this is fixed since long. Unfortunately, there is a large number of ancient unfixed MLO files out there...
On 06/30/2011 08:00 AM, Somebody in the thread at some point said:
Andy Green wrote:
ROM being ROM, it can't be upgraded, however, unlike in OMAP3 the ROM in OMAP4 stuff seems pretty much perfect for SD Card boot case, it doesn't care about any arcane stuff like geometry for example. It only needs to success to pull MLO reliably and anything further can be done there in an upgradeable way.
neither does the OMAP3 ROM code. All the cargo cult around geometry stems from the fact that initially x-loader aka MLO hardcoded sector 63 for the start of the boot partition and this is fixed since long. Unfortunately, there is a large number of ancient unfixed MLO files out there...
I think we can count that as arcarna... but I think we're talking about different problems, and that the ROM fragility to partitioning on OMAP3 is real enough.
On an IGEP0020 I was unable to create a bootable image -- one that would boot x-loader so it would talk on the serial console -- even after a couple of days struggling. It was only 'solved' in the end when Loic imaged the start of his magic working card and I dd'd it on to mine. Then it was happy even when I put my MLO on there.
-Andy
Andy Green wrote:
I think we can count that as arcarna... but I think we're talking about different problems, and that the ROM fragility to partitioning on OMAP3 is real enough.
On an IGEP0020 I was unable to create a bootable image -- one that would boot x-loader so it would talk on the serial console -- even after a couple of days struggling. It was only 'solved' in the end when Loic imaged the start of his magic working card and I dd'd it on to mine. Then it was happy even when I put my MLO on there.
It would have been interesting to compare the 2 cards. In fact I did that once for a friend that had similar issues and in the end came up with:
http://groups.google.com/group/beagleboard/browse_thread/thread/ae8e64e6be02...
the fact that partition size in MBR and FAT have to match came as a little surprise :)
andy, paul,
On Thu, Jun 30, 2011 at 6:26 AM, Andy Green andy.green@linaro.org wrote:
Nicolas already gave a rundown but the short answer is the ROM can drive the MMC hardware of the OMAP4, talk SD-HC protocol, parse your partition table and FAT filesystem on your SD Card, and will load and execute a file of the magic name "MLO" on partition 1.
That is "x-loader", which sets stuff up and loads and executes a magic file "u-boot.bin" off partition 1. And "u-boot" does its usual thing from then on.
unlike MLO filename which is hardcoded in the ROM code (hence cannot change) the 'u-boot.bin' is coded in x-loader and is manageable. as it turns out ROM code needs to be able to read FAT/SD, x-loader needs that too (to load u-boot), and u-boot as well ;-) how funny...
ROM being ROM, it can't be upgraded, however, unlike in OMAP3 the ROM in OMAP4 stuff seems pretty much perfect for SD Card boot case, it doesn't care about any arcane stuff like geometry for example. It only needs to success to pull MLO reliably and anything further can be done there in an upgradeable way.
yes, some OMAP3 problems were fixed in the OMAP4 ROM code based on the feedback from linux/SD card users.
Of course, it'll pull anything called MLO. I believe folks are working on adding stuff to be able to call U-Boot "MLO" directly eliminating x-loader and Matt Hsu and I already did that for Qi.
one clarification: the u-boot MLO project is just about the capabilities of rebuilding MLO from u-boot sources. in fact MLO is a 'tiny uboot'. so instead of duplicating the source tree for x-loader as it stands today, the idea is to have a mlo config in uboot and rebuild this tiny uboot from uboot sources so that there is no need to maintain 2 MMC driver for example. you will still get a 2-stage bootloader.
So, it would be nice if you could suggest Android team which
repo/branch/tag/revision can be safely used to produce releases.
Yeah confusing ain't it. There are two camps in x-loader development one on omapzoom and one on gitorious. TI engineers like omapzoom but the official repo is gitorious.
i don't think it's a TI vs others issue. TI has been pushing for a mailing xloader because there is a lot of confusion on this topic. the clean mainline tree started after the android xloader and is still lacking behind. if community/TI is able to bring mainline x-loader to the same level of features has the omapzoom one, I am pretty sure that the migration can happen.
The magic branch I (and I believe Ubuntu) use is:
git://gitorious.org/x-loader/**x-loader.githttp://gitorious.org/x-loader/x-loader.gitmaster
... and BTW, 3.0 android kernel from us requires MLO update from what you supply at the moment to this in order for 3D unit to start up. So this is a good idea anyway.
Dechesne, Nicolas wrote:
ROM being ROM, it can't be upgraded, however, unlike in OMAP3 the ROM in OMAP4 stuff seems pretty much perfect for SD Card boot case, it doesn't care about any arcane stuff like geometry for example. It only needs to success to pull MLO reliably and anything further can be done there in an upgradeable way.yes, some OMAP3 problems were fixed in the OMAP4 ROM code based on the feedback from linux/SD card users.
would you be able to come up with a short list of "fixes" that have been done?
On Thu, Jun 30, 2011 at 9:24 AM, Vladimir Pantelic vladoman@gmail.comwrote:
would you be able to come up with a short list of "fixes" that have been done?
the notable problem fixed in OMAP4 vs OMAP3 boot code is related to how the ROM code will read the FAT table. in OMAP3 if you keep replacing the MLO/uboot/uimage (whether you cp or mv to it) after a while (~10 iterations, iirc) the ROM code will not be able to locate MLO anymore, and you need to reformat the card. this problem is fixed on OMAP4. there might be other things, but this one was really the biggest issue i think.
also, note that the SD can be used as RAW instead of FAT, in which case you aren't going through the embedded FAT implementation and avoid such issues.
Dechesne, Nicolas wrote:
On Thu, Jun 30, 2011 at 9:24 AM, Vladimir Pantelic <vladoman@gmail.com mailto:vladoman@gmail.com> wrote:
would you be able to come up with a short list of "fixes" that have been done?the notable problem fixed in OMAP4 vs OMAP3 boot code is related to how the ROM code will read the FAT table. in OMAP3 if you keep replacing the MLO/uboot/uimage (whether you cp or mv to it) after a while (~10 iterations, iirc) the ROM code will not be able to locate MLO anymore, and you need to reformat the card. this problem is fixed on OMAP4. there might be other things, but this one was really the biggest issue i think.
thanks!
also, note that the SD can be used as RAW instead of FAT, in which case you aren't going through the embedded FAT implementation and avoid such issues.
sure, that's how we boot from emmc :)
On 06/30/2011 08:11 AM, Somebody in the thread at some point said:
Hi -
yes, some OMAP3 problems were fixed in the OMAP4 ROM code based on the feedback from linux/SD card users.
I think it pretty much reached perfection on OMAP4 for SD boot case anyway. In fact a VFAT and partition parser in ROM was more than I expected to see, it's very good.
Of course, it'll pull anything called MLO. I believe folks are working on adding stuff to be able to call U-Boot "MLO" directly eliminating x-loader and Matt Hsu and I already did that for Qi.one clarification: the u-boot MLO project is just about the capabilities of rebuilding MLO from u-boot sources. in fact MLO is a 'tiny uboot'. so instead of duplicating the source tree for x-loader as it stands today, the idea is to have a mlo config in uboot and rebuild this tiny uboot from uboot sources so that there is no need to maintain 2 MMC driver for example. you will still get a 2-stage bootloader.
FWIW panda-dev branch of Qi does it in one stage, and it's not that much bigger than x-loader alone. It just loads and boots linux plus or minus initrd though so it's not the same as U-Boot.
Yeah confusing ain't it. There are two camps in x-loader development one on omapzoom and one on gitorious. TI engineers like omapzoom but the official repo is gitorious.i don't think it's a TI vs others issue. TI has been pushing for a
Right, I meant, as you can see from the two commit logs, that TI engineers "like" to push to omapzoom repo and the official one less so.
mailing xloader because there is a lot of confusion on this topic. the clean mainline tree started after the android xloader and is still lacking behind. if community/TI is able to bring mainline x-loader to the same level of features has the omapzoom one, I am pretty sure that the migration can happen.
I did create a unification branch a while ago which merged all omapzoom content on to the gitorious one. The result worked fine on Panda, but I didn't test it on anything else.
http://gitorious.org/x-loader/x-loader/commits/unified
-Andy
On Thu, Jun 30, 2011 at 12:06 AM, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
On Wed, 29 Jun 2011 21:33:18 +0100 Andy Green andy.green@linaro.org wrote:
On 06/29/2011 07:58 PM, Somebody in the thread at some point said:
Hi -
Month ago, during 11.05 release testing, we had a case when Pandaboard didn't boot with one particular build and one particular card, while worked well with with other combinations.
During this test cycle, I hit similar conditions, which I however was able to trace to the following: if at the moment of reset/boot, there's a cable connected from Panda USB OTG (small) connector to host, it won't boot from SD. The D2 LED will light for about a second, then both will be off. Nothing is output on serial. As soon as you unplug cable from the host, all boots again.
I'm not sure if this is a known condition, but guessed I'd share it.
How old's your x-loader / MLO?
I'm testing Linaro Android 11.06 releases: http://releases.linaro.org/platform/linaro-n/android/11.06/
I get:
Texas Instruments X-Loader 1.4.4ss (Mar 18 2011 - 14:14:59)
Btw I don't yet fully understand Panda boot architecture. This X-Loader appear to come from SD card. But what boots it then? How that piece is called, where it comes from, how it should be upgraded, and is that ever needed? I found this: https://gforge.ti.com/gf/project/omapzoom/wiki/?pagename=BootingAndFlashing but it's still a bit confusing (like, doesn't name that first loader, and from OS perspective, it appears to be 3-stage boot).
I wrote a patch 97bb3ce0ca014aff9ad9f35f2b78f3976bf276f6 to solve this back in February, it's in Gitorious x-loader repo
http://gitorious.org/x-loader/x-loader/commit/97bb3ce0ca014aff9ad9f35f2b78f3...
If you try an updated x-loader with that in, if the mUSB port is powered it'll just pause 2sec on start then start as normal from SD card.
Android builds use:
<project name="x-loader" path="device/linaro/x-loader" remote="omapzoom" revision="eb8b047c29a2027fbdd841cd1289fa27ddb22d72"/>
due to build system issues we don't build xloader from source atm.
Patrik added a blueprint "build MLO from source" to the backlog before he left to vacation: - https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-mlo-fro...
With some luck we might tackle it for this cycle (or august since patrik is on summar vacation this month).
-
Alexander Sack -
Andy Green -
Dechesne, Nicolas -
Paul Sokolovsky -
Vladimir Pantelic