Re: about your code/work on Chumby bootloader, imx233
Casainho
> Hi!
>
> No, we never used the JTAG. We debug with an oscilloscope and a serial port
> here. I'm afraid we are primitive like that, but they are commonly available
> tools.
>
> I don't know of any other open source projects using the i.MX233 at the
> moment. There is a pretty good corpus of information on the Freescale
> website with respect to the bootloader.
>
> As for using the chumby bootloader code, it should be all there -- we have a
> very tiny shell we wrote to bootstrap the device instead of using u-boot.
> Modifying that would be a good starting point for your LED blinking
> exercise. There is some complication with respect to where the MBR/CBR is
> located and the blow state of the fuses. Chumby blows an OTP so that we boot
> from an MBR record, but without the fuse blown it goes to some location near
> the top of Flash to load a CBR instead. That, and the optional boot
> encryption process, are the most frustrating parts of the bootloader, but we
> pretty much crib all of that directly from Freescale's tools.
>
> thanks,
Thanks! I am not sure I did understand all that you said, but I am
forwarding this message to our group, the others more experienced will
for sure be glad with this info.
Thanks :-)
> -b.
>
> At 03:15 AM 5/27/2010, Casainho wrote:
>>
>> Hello :-)
>>
>> I had reading in past your blog messages, which are great. It's good
>> the Chumby story, being Open Source, I appreciate, even If I do not
>> own one.
>>
>> Just a quick question, did you use JTAG debug with imx233? I am
>> working on a Open Source project, I have a board with me and I am
>> trying to connect to imx233 with JTAG and OpenOCD - did you used such
>> tools? If so, do you have any OpenOCD script for imx233?
>>
>> I am looking at Chumby bootloader code, I hope to use it to blink a
>> LED, and boot that code from uSDCard.
>>
>> Are there any other documents, sources, Open Source projects using
>> imx233 that you can recommend? - right now, Chumby is the only
>> reference to us ;-) -- we will be using the source files you share ;-)
>> Thanks!
>>
>> Info and files for our project:
>> http://lyre.sourceforge.net/?q=content/imx233-pcbs-arrived
>>
>> --
>> Cumprimentos,
>> Jorge Pinto
>
> ^`'~*-,._.^`'~*-,._.^`'~*-,._.^`'~*-,._.^`'~*-,._.^`'~*-,._.^`'~*-,._.^`'
>
john cooper
>> As for using the chumby bootloader code, it should be all there -- we have a
>> very tiny shell we wrote to bootstrap the device instead of using u-boot.
>> Modifying that would be a good starting point for your LED blinking
>> exercise. There is some complication with respect to where the MBR/CBR is
>> located and the blow state of the fuses. Chumby blows an OTP so that we boot
>> from an MBR record, but without the fuse blown it goes to some location near
>> the top of Flash to load a CBR instead.
Ah, ok. Forget the suggestion to try Chumby's boot image
as the factory config of the imx233 is going to look for
a BCB in the highest SD block -- presumably it gets this
last block location from the SD's CSD/C_SIZE.
Anyway you can get the BCB structure from the imx233
ref manual.
>> That, and the optional boot
>> encryption process, are the most frustrating parts of the bootloader,
Ugh, as feared.
>> but we
>> pretty much crib all of that directly from Freescale's tools.
Bunnie, given the above I assume you were using FSL's windows
tools to program the OTP bits as needed on factory vanilla parts?
Thanks,
-john
john cooper
> Looping in Sean Cross -- he knows the bootloader much better than I do.
>
> Our bootloader system creates two versions of the boot block, one at
> high and one at low. The code is identical, we just place them at
> different spots.
This is an MBR/FAT-style boot block or a BCB header located in the
high media block you're referring to above?
> We get our devices virgin, and the bootloader has a routine that unlocks
> the fuses and blows them -- natively, in-device, without the windows
> utility.
Ah, that's what I would expect. For some reason FSL's documentation
doesn't appear to describe this -- or I haven't been looking in the
right place.
> We use this also to blow our AES fuses, for example, to set the
> per-device key. But more importantly, the routine blows the fuse that
> gets us out of the annoying CBR structure.
So I'm reading here there is some interaction with the on-board
bootrom to program OTP/fuse bits perhaps via the DUART port?
Just curious what mask version FSL is shipping you folks? TA4 seems
to be the latest documented mask rev however they just shipped me a
lot of TA1s.
Thanks,
-john
> To burn the fuses, we have a bootloader that
> ^`'~*-,._.^`'~*-,._.^`'~*-,._.^`'~*-,._.^`'~*-,._.^`'~*-,._.^`'~*-,._.^`'
Casainho
when imx233 comes from factory? does the encryption fuse is ON when
imx233 comes from factory or we need to turn it ON if we want to use
encrypted boot images?
Because we are trying to avoid using Windows tools, and just use
Linux. For now we hope just to need use the 'elftosb' software that
exist also for Linux.
(Me, John and Bob, we both are on rockbo...@googlegroups.com list)
Casainho
> Yes, it does need to be encrypted. The "zero" key is sufficient, and is what we use. Our invocation to create the factory bootstream image is:
>
> elftosb2/elftosb2 -z -c ../config/falconwing_factory_sb.db \
> -o $(INSTALL_DIR)/bootstream-factory.bin
>
> I believe the "-z" command will cause the image to be encrypted with a key of all Zeros, which is what the fuses are set to by default.
>
> On our system, the factory image blows the "encryption not required" fuse, which lets our standard bootloader be unencrypted. So from the factory the image needs to be encrypted, but chumby removes this requirement.
Thanks! ;-)
john cooper
According to FSL in the same forum, encryption is on by default as
feared and as advertised in the imx233 ref manual:
http://forums.freescale.com/t5/i-MX-Microprocessors/sb-loader-amp-Linux/m-p/53813#M430
However from what Bunnie indicated I think reuse of
Chumby's BCB boot code/kernel is by far the path
of least resistance. And beyond that a windoZe-free
method to program the OTP/fuze bits. This is my
understanding from discussion -- just looking at the
code now.
-john
Casainho
> Chumby's BCB boot code/kernel is by far the path
> of least resistance. And beyond that a windoZe-free
> method to program the OTP/fuze bits. This is my
> understanding from discussion -- just looking at the
> code now.
Good John!
Could you maybe first do the blink (or simple turn ON) LED code? -- I
could quickly try on the board. And please use the Sourceforge Lyre
SVN :-)
Bob
The bootloader code you have put in sourceforge is the bootloader for
the Chumby Classic, not the Chumby One. The Classic is iMX21 not
iMX233.... The code we want is the "Falconwing" project.
john cooper
Encryption is on by default but customers can use the implicit
dummy zero key on a factory virgin part. So once you've crawled
inside with a program to modify the corresponding OTP bits to
turn-off encryption, this "bootstrap" step is complete. And
thankfully Chumby provides the OTP programmer bootable image
(which IIUC is actually a kernel image).
Bob,
Do any missing pieces still exist given this info?
-john
Sean Cross wrote:
>> Yes, it does need to be encrypted. The "zero" key is sufficient, and is what we use. Our invocation to create the factory bootstream image is:
>>
>> elftosb2/elftosb2 -z -c ../config/falconwing_factory_sb.db \
>> -o $(INSTALL_DIR)/bootstream-factory.bin
>>
>> I believe the "-z" command will cause the image to be encrypted with a key of all Zeros, which is what the fuses are set to by default.
>>
>> On our system, the factory image blows the "encryption not required" fuse, which lets our standard bootloader be unencrypted. So from the factory the image needs to be encrypted, but chumby removes this requirement.
Casainho
> Cas, you crazy guy!
>
> The bootloader code you have put in sourceforge is the bootloader for
> the Chumby Classic, not the Chumby One. The Classic is iMX21 not
> iMX233.... The code we want is the "Falconwing" project.
Oh... can you o delete it? or maybe the one that will make next commit.
Bob
> Bob,
> Do any missing pieces still exist given this info?
in the bootstream tarball from Chumby. We maybe just need to ask
Chumby for these, they seem to be very helpful.
I guess that the Chumby boot programs will use SDRAM, which I don't
think we have running yet. It may be a simple mod to run the OTP
bootstrap from internal RAM.
Casainho
Here the .sd file for u-boot:
// STMP378x ROM command script to load and run U-Boot
sources {
sdram_prep="./boot_prep/boot_prep";
image="/home/b20596/ltib/rootfs/boot/u-boot";
}
section (0) {
//----------------------------------------------------------
// SDRAM initialization
//----------------------------------------------------------
load sdram_prep;
call sdram_prep;
//----------------------------------------------------------
// Load and call u_boot - ELF ARM image
//----------------------------------------------------------
load image;
call image;
}
'boot_prep' and 'u-boot' are ELF files. In our case, we will just have
one, the 'blink_LED', maybe something like this:
sources
{
blink_LED_elf="./blink_LED";
}
section (0)
{
load blink_LED_elf;
call blink_LED_elf;
}
The 'imx-bootlets-src-4.5.1.tar.gz' on Linux BSP for imx233 have that
files and more. I am attaching that gz file (it gives an error when
unflating, but should be not problem).
Does anyone have a blink LED code? maybe even in assembly from the C
startup file?