Hi,
If I mess up the u-boot in my efikamx smart book how can I install a new one? I tried booting with an SD-card image from http://www.powerdeveloper.org/asset/by-id/116. I guess this only works if I have a working u-boot in place.
I don't have the serial/JTAG connector. Is this what I need in order to recover?
Thanks, Per
On Tue, Jan 18, 2011, Per Förlin wrote:
If I mess up the u-boot in my efikamx smart book how can I install a new one? I tried booting with an SD-card image from http://www.powerdeveloper.org/asset/by-id/116. I guess this only works if I have a working u-boot in place.
I don't have the serial/JTAG connector. Is this what I need in order to recover?
There is a series of DIP switches in the back panel (where you plug the debug cable); depending on their positions, the board will boot from SD, micro-SD or from flash. You can create a "replace all my flash contents with a known-good u-boot" SD card with the bits provided by genesi.
Per,
The file you need is in the first partition of the SD card you downloaded - I believe I made an 8MB space at the front of the updater card to put U-Boot there for these kinds of rescues. You just need to
dd if=u-boot-2009.01-2.0.6-efikasb of=/dev/mmcblk0 skip=1 seek=1 bs=1024
The DIP switches depend on which SD card slot you use, for the side slot it should be all the switches set to "off" (they default to "on on on off" for NOR, "off off off on" should use the microsd slot). I may have that reversed but you'll notice when it doesn't do anything and realize you need to swap the last bit over. To get to the switches pop the keyboard - it should latch away if you use a small screwdriver or awl to push the latches at the top of the keyboard, there are 4, start from the right. There are small catches 3/4 of the way down the length, so when you try and lift it forward, be careful as too much pressure or tugging on the keyboard will bend it. A little jiggle will make this easier.
Once you've gotten to that point, without a serial board it gets a bit tricky: it won't run the autoupdate utility from the SD card because it will detect the running SD U-Boot as a current version. You will need to edit the boot.scr script provided (just edit it in a text editor, remove the garbage header, save it, mkimage it again) to set the u-boot date code to something around today's date to make sure it's going to flash.
IN THEORY, the system should flash it and then power off. You'll see the caps lock led blink 3 times then it'll shut down. At this point take the SD out... flip the DIPs back, et voila. However if the system is constantly rebooting and flashing, you have those 3 blinks to basically kill the system (yank AC with no battery) or it will be halfway through a flash update and NOR will be invalid again.
If we're at the point we're having more trouble at this point please give me a nudge and I'll create a solution for rescues that will suit your exact situation.
I am curious, how did you get to this state in the first place?
Hi Matt,
On 18 January 2011 15:03, Matt Sealey matt@genesi-usa.com wrote:
IN THEORY, the system should flash it and then power off. You'll see the caps lock led blink 3 times then it'll shut down. At this point take the SD out... flip the DIPs back, et voila. However if the system is constantly rebooting and flashing, you have those 3 blinks to basically kill the system (yank AC with no battery) or it will be halfway through a flash update and NOR will be invalid again.
I run the updater-sd-card successfully at one time and it proceeded as you described it, caps lock blink 3 times then shut down.
If we're at the point we're having more trouble at this point please give me a nudge and I'll create a solution for rescues that will suit your exact situation.
I am curious, how did you get to this state in the first place?
My inexperience with writing u-boot scripts but me in this situation. I wanted to write my own u-boot script. Now when I boot the caps lock is not blinking instead there is a steady bright light.
I haven't double checked what I did to make this happen yet. I used setenv with invalid bootargs but I didn't store them. This weekend I will make a new attempt bringing it back to life. I don't have a arm development board at home to test patches on so I thought I may use this one for it. I just need to get familiar with the boot/flash procedures first :)
Thanks for you detailed instructions.
-- Matt Sealey matt@genesi-usa.com Product Development Analyst, Genesi USA, Inc.
On Tue, Jan 18, 2011 at 4:02 AM, Loïc Minier loic.minier@linaro.org wrote:
On Tue, Jan 18, 2011, Per Förlin wrote:
If I mess up the u-boot in my efikamx smart book how can I install a new one? I tried booting with an SD-card image from http://www.powerdeveloper.org/asset/by-id/116. I guess this only works if I have a working u-boot in place.
I don't have the serial/JTAG connector. Is this what I need in order to recover?
There is a series of DIP switches in the back panel (where you plug the debug cable); depending on their positions, the board will boot from SD, micro-SD or from flash. You can create a "replace all my flash contents with a known-good u-boot" SD card with the bits provided by genesi.
-- Loïc Minier
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Okay we can make an SD card that will force a U-Boot update and power down easily..
On Wed, Jan 19, 2011, Matt Sealey wrote:
Okay we can make an SD card that will force a U-Boot update and power down easily..
This would be awesome!
Speaking for other Linaro needs, it would be nice if we could reproduce this build ourselves as to allow us to create special purpose u-boots. I realize it's not a process you're generally promoting to end-users, but we'd like to create special images loading a kernel from the network, or trying to add device tree to support to u-boot etc. and this needs us to build our own u-boots.
Thanks!
On 18 January 2011 15:03, Matt Sealey matt@genesi-usa.com wrote:
Per,
The file you need is in the first partition of the SD card you downloaded - I believe I made an 8MB space at the front of the updater card to put U-Boot there for these kinds of rescues. You just need to
dd if=u-boot-2009.01-2.0.6-efikasb of=/dev/mmcblk0 skip=1 seek=1 bs=1024
I took the same ubootsb.bin in efikamx-updater.img.xz instead of u-boot-2009.01-2.0.6-efikasb. I figure that would be the same or similar.
The DIP switches depend on which SD card slot you use, for the side slot it should be all the switches set to "off" (they default to "on on on off" for NOR, "off off off on" should use the microsd slot). I may have that reversed but you'll notice when it doesn't do anything and realize you need to swap the last bit over. To get to the switches pop the keyboard - it should latch away if you use a small screwdriver or awl to push the latches at the top of the keyboard, there are 4, start from the right. There are small catches 3/4 of the way down the length, so when you try and lift it forward, be careful as too much pressure or tugging on the keyboard will bend it. A little jiggle will make this easier.
Once you've gotten to that point, without a serial board it gets a bit tricky: it won't run the autoupdate utility from the SD card because it will detect the running SD U-Boot as a current version. You will need to edit the boot.scr script provided (just edit it in a text editor, remove the garbage header, save it, mkimage it again) to set the u-boot date code to something around today's date to make sure it's going to flash.
IN THEORY, the system should flash it and then power off. You'll see the caps lock led blink 3 times then it'll shut down. At this point take the SD out... flip the DIPs back, et voila. However if the system is constantly rebooting and flashing, you have those 3 blinks to basically kill the system (yank AC with no battery) or it will be halfway through a flash update and NOR will be invalid again.
I switched all 4 switches off. Updated the u-boot version to the date of today. I insert the sd-card and press the power button, it starts blinking. What does this indicate? The caps lock led is not active at all.
I seems like the u-boot on my sd-card is never executed or invalid. The caps lock led would indicate if u-boot is running, right? I used your line to copy u-boot onto the sd-card. dd if=ubootsb.bin of=/dev/mmcblk0 skip=1 seek=1 bs=1024
If we're at the point we're having more trouble at this point please give me a nudge and I'll create a solution for rescues that will suit your exact situation.
I think I have reached this point :)
Okay we can make an SD card that will force a U-Boot update and power down easily..
I would like to test with this pre-made image, if it exist.
Many thanks, Per
Hi Matt,
I made a new attempt bringing up my imx today, this time I reconnected the keyboard and then I could recover u-boot without any trouble. I disconnected the keyboard when changing the DIP switches.
BR Per
On 23 January 2011 03:05, Per Forlin per.forlin@linaro.org wrote:
On 18 January 2011 15:03, Matt Sealey matt@genesi-usa.com wrote:
Per,
The file you need is in the first partition of the SD card you downloaded - I believe I made an 8MB space at the front of the updater card to put U-Boot there for these kinds of rescues. You just need to
dd if=u-boot-2009.01-2.0.6-efikasb of=/dev/mmcblk0 skip=1 seek=1 bs=1024
I took the same ubootsb.bin in efikamx-updater.img.xz instead of u-boot-2009.01-2.0.6-efikasb. I figure that would be the same or similar.
The DIP switches depend on which SD card slot you use, for the side slot it should be all the switches set to "off" (they default to "on on on off" for NOR, "off off off on" should use the microsd slot). I may have that reversed but you'll notice when it doesn't do anything and realize you need to swap the last bit over. To get to the switches pop the keyboard - it should latch away if you use a small screwdriver or awl to push the latches at the top of the keyboard, there are 4, start from the right. There are small catches 3/4 of the way down the length, so when you try and lift it forward, be careful as too much pressure or tugging on the keyboard will bend it. A little jiggle will make this easier.
Once you've gotten to that point, without a serial board it gets a bit tricky: it won't run the autoupdate utility from the SD card because it will detect the running SD U-Boot as a current version. You will need to edit the boot.scr script provided (just edit it in a text editor, remove the garbage header, save it, mkimage it again) to set the u-boot date code to something around today's date to make sure it's going to flash.
IN THEORY, the system should flash it and then power off. You'll see the caps lock led blink 3 times then it'll shut down. At this point take the SD out... flip the DIPs back, et voila. However if the system is constantly rebooting and flashing, you have those 3 blinks to basically kill the system (yank AC with no battery) or it will be halfway through a flash update and NOR will be invalid again.
I switched all 4 switches off. Updated the u-boot version to the date of today. I insert the sd-card and press the power button, it starts blinking. What does this indicate? The caps lock led is not active at all.
I seems like the u-boot on my sd-card is never executed or invalid. The caps lock led would indicate if u-boot is running, right? I used your line to copy u-boot onto the sd-card. dd if=ubootsb.bin of=/dev/mmcblk0 skip=1 seek=1 bs=1024
If we're at the point we're having more trouble at this point please give me a nudge and I'll create a solution for rescues that will suit your exact situation.
I think I have reached this point :)
Okay we can make an SD card that will force a U-Boot update and power down easily..
I would like to test with this pre-made image, if it exist.
Many thanks, Per
On Wed, Feb 02, 2011, Per Förlin wrote:
I made a new attempt bringing up my imx today, this time I reconnected the keyboard and then I could recover u-boot without any trouble. I disconnected the keyboard when changing the DIP switches.
Per, upstream u-boot got support in git for efikamx some hours ago; I managed to boot it this very morning! make efikamx_config and make, then write u-boot.imx to SD at offset 0x400; boot with 4 DIP switches to off.
I think we will have this in .debs soon; mainline kernel lack some important stuff still though
Cheers
On Thu, Feb 3, 2011 at 6:44 AM, Loïc Minier loic.minier@linaro.org wrote:
On Wed, Feb 02, 2011, Per Förlin wrote:
I made a new attempt bringing up my imx today, this time I reconnected the keyboard and then I could recover u-boot without any trouble. I disconnected the keyboard when changing the DIP switches.
Per, upstream u-boot got support in git for efikamx some hours ago; I managed to boot it this very morning! make efikamx_config and make, then write u-boot.imx to SD at offset 0x400; boot with 4 DIP switches to off.
Hi All,
Sorry being late on this.
I guess we need some where to document all these tricks, which will be of great help to other developers. At least the below information from what I understand:
1. A bit explanation of the codenames, efikasb for smartbook and efikamx for smart top? As we may need to follow a consistent naming scheme.
2. The three possible boot up methods: a) Internal SPI NOR flash, b) the MicroSD card behind the battery and c) the normal SD card at the left side, not really sure about the situation on Efika MX (smart top) as I don't have one in my hands
3. The DIP switch states corresponding to each boot up method above
4. The boot sequence of the Internal SPI NOR flash, as it looks to me that it's trying to find boot.scr from either the MicroSD or SD card on the first partition? Also it would be helpful to document the envionment variables of this specific u-boot.
5. If Linaro is going to support u-boot for Efika MX/SB, it's better to follow what is in upstream. However, there could be some differences between the u-boot in the recovery/installing image downloadable from powerdeveloper.org and the one in upstream. We might need to figure out those differences and see how to handle them.
6. As Loic mentioned, would be of great help if the process of generating the recovery/installer images are documented. And linaro-media-create might get to be aware if there are any tricks.
Matt,
Maybe I missed the search, do you know if the information above is already documented somewhere? And if not, I'm not sure if a page on wiki.linaro.org will be fine?
Some other small problems I met with u-boot on Efika are:
1. upstream u-boot building error for efikamx:
efikamx.c: In function ‘board_init’: efikamx.c:624:27: error: ‘MACH_TYPE_MX51_LANGE51’ undeclared (first use in this function) efikamx.c:624:27: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [efikamx.o] Error 1 make[1]: Leaving directory `/home/ycmiao/linaro/uboot-imx/board/efikamx' make: *** [board/efikamx/libefikamx.o] Error 2
2. check-out of git://gitorious.org/efikamx/uboot-efikamx.git didn't seem to build for a 'make efikasb_config'?
Finally, it would be nice if a GUI support is possible as most users (even developers) don't have a serial cable. But that could be postponed to a later implementation.
- eric
I think we will have this in .debs soon; mainline kernel lack some important stuff still though
Cheers
Loïc Minier
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
hey
adding my bits where I can
On Tue, Feb 08, 2011, Eric Miao wrote:
- The three possible boot up methods: a) Internal SPI NOR flash, b) the MicroSD card behind the battery and c) the normal SD card at the left side, not really sure about the situation on Efika MX (smart top) as I don't have one in my hands
efikamx only has SD and internal flash; there might be other boot methods like serial or USB, but I don't think we need to care too much about these
- The boot sequence of the Internal SPI NOR flash, as it looks to me that it's trying to find boot.scr from either the MicroSD or SD card on the first partition? Also it would be helpful to document the envionment variables of this specific u-boot.
on my efikamx, this is the bootcmd it had when I received it and corresponding variables: bootcmd=run pata_boot pata_boot=run bootargs_base bootargs_pata bootargs_base=setenv bootargs noinitrd console=ttymxc0,115200 console=tty1 bootargs_pata=setenv bootargs ${bootargs} root=/dev/sda2 ${bootinfo};run boot_pata bootinfo=rw boot_pata=run base_cmds;ide reset;fatload ide 0:1 ${loadaddr} ${kernel}; bootm ${loadaddr} base_cmds=run base_cmd1;run base_cmd2;run base_cmd3;run base_cmd4;run base_cmd5;run base_cmd99 loadaddr=0x90007FC0 kernel=uImage base_cmd1=pmic 15 0x00400022;mw.l 0x73fa84b8 0xe7 1;mw.l 0x73fd4014 0x59239100 1 base_cmd2=mw.l 0x83fd9010 0xcaaaf6d0 1;mw.l 0x73f88000 0x01025200 1;mw.l 0x73f84000 0x20 1 base_cmd3=mw.l 0x83fd9004 0x333574aa 1;mw.l 0x83fd900c 0x333574aa 1; base_cmd4=mw.l 0x83fd9020 0x00f48b00 1;mw.l 0x83fd9024 0x00f49700 1;mw.l 0x83fd9028 0x00f48700 1 base_cmd5=mw.l 0x83fd902c 0x00f48400 1;mw.l 0x83fd9030 0x00f44e00 1;
- If Linaro is going to support u-boot for Efika MX/SB, it's better to follow what is in upstream. However, there could be some differences between the u-boot in the recovery/installing image downloadable from powerdeveloper.org and the one in upstream. We might need to figure out those differences and see how to handle them.
That was indeed the case; Marex, who developed the upstream u-boot bits, told me the same u-boot would work on SD and on flash; the one I've built from mainline uses the default imximage.cfg settings which is "BOOT_FROM spi", yet works fine from a SD card. So it seems the same u-boot can be used for both SD and flash -- just with different bootcmd.
Cheers,
Just to clear up on this front regarding how the i.MX boots: there is an internal boot ROM built into the mask of the SoC which contains some rudimentary boot code. It can perform the following tasks:
1) boot from any SPI-based ROM this actually includes any memory-based SD card as they are just 4-bit SPI buses as standard. Every SD card manufactured absolutely must be able to be accessed using 1-bit SPI access, per the SD Assoc. standard. Isn't that fun? 2) possibly boot from i2c-based EEPROMs 3) boot from the NAND flash controller (which we don't use) 4) boot from PATA or SATA (in MX53) 5) fall back to booting from a specially connected USB host connected to the OTG port (also we don't use) 6) fall back to booting from UART
It will pick the boot method from the BT_* pins on the board, which are usually hooked to DIPs or hardwired to ground or an appropriate pullup to enforce boot behavior. We support booting from SPI and SD card, and the 4th DIP switch on all the boards determines the "chipselect" (so, chipselect 0 for SPI is valid, but chipselect 1 for SPI would be the PMIC, which is a silly combination, and 0 or 1 for the 4th pin selects SD card slot, where on the Efika MX Smarttop 1.3 revision ("TO3") there is only one valid SD card slot).
There are various padding requirements for the ROM-based boot methods.
From SPI or SD card, it will load the i.MX DCD table from 1024 bytes
into the device. The same is true of PATA and SATA boot methods on MX53. This allows partitioning information to be skipped. From NAND flash I think it picks it up from 4096 bytes into the device (to correspond to a decent multiple of a NAND flash page, on top of the requirement to have a partition table or header in the first few bytes of flash).
Older U-Boots (like ours) padded u-boot.bin but newer U-Boots (mainline right now) do not, so the offset you flash to can either be 0 (ours, if you're dding to an SD card, seek=1 skip=1 bs=1024) or 1024 (skip=1 bs=1024 I think)
That's pretty much the down low of it..
The U-Boot on gitorious is more of a nostalgia piece, we actually abandoned the repo a long time ago.
I am recommending this, and hoping Linaro stick to it: Linaro, Ubuntu, Debian or any concerned distribution has absolutely NO business building or flashing U-Boot for the boards.
You do not need to know codenames for the boards as described in U-Boot.
You do not need to even HAVE the source.
It should not be a requirement for a board to have it's firmware built within the distribution it runs. This is, to my eyes, an absolutely braindead endeavor.
You do not have to flash it.
We can provide the source code to anyone who asks, but I do ask in return that you develop support for mainline, and Genesi will decide if we ship it on our hardware. We have to maintain a correctly operating consumer product here, it is not "usual" for any PC to actively be reflashing and recompiling, or even providing firmware binaries along with the operating system, whether they run Linux or not.
The only suggestion I see in this thread that makes any sense is documenting the bootcmd we have, and I will tell you it does the following very simple task (which we will freely admit, we stripped and modified from flash-kernel in Ubuntu, for Dove and OMAP3) in pseudocode:
for each (mmc0, mmc1, ide) if exists boot.scr load it if valid-image run it fi fi end
That's it. That's all it needs to do. What confused us was that flash-kernel actively modified the bootcmd variable for Dove/OMAP to insert this boot procedure. We decided it was silly, and this would be better to ship it by default, so that all a boot.script has to do is
load kernel to loadaddr load ramdisk to ramdiskaddr setenv bootargs foo bar bootm loadaddr ramdiskaddr
(there are two pertinent variables in U-boot that help us flash new versons, "model" and a build "version" which is constructed from the exact date and time it built, but you don't need to care about those. We ship a single kernel for both boards now, so knowing which model it is is ONLY relevant to U-Boot itself).
-
Eric Miao -
Loïc Minier -
Matt Sealey -
Per Forlin