Re: Re: Re: Re: i.MX233 Hand-Held Multimedia Board
Casainho
assembling tomorrow, however I don't know already from where to start.
I have solder iron, variable power supply and oscilloscope.
I think I will try to first supply power using the variable power supply.
First, I think I should assembly the imx233 + supply components + LED.
Then I hope to be able to run/debug Blink LED code. Does anyone think
that there is a better path?
--
You received this message because you are subscribed to the Google Groups "rockboxplayer" group.
To post to this group, send email to rockbo...@googlegroups.com.
To unsubscribe from this group, send email to rockboxplaye...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rockboxplayer?hl=en.
Casainho
I put 3.7V at battery input and I even can see that voltage on both
sides of D2 schottky diode, meaning that no voltage drop happens on
D2.
The is 0V on VDDIO_3V3, that's why the power LED do not light. I can't
see any voltage at L1 either.
What could be wrong? Can someone give an idea?
--
Cumprimentos,
Jorge Pinto
Casainho
need to press "POWER switch", as datahseet says:
"DC-DC power from a battery is the default configuration when a device
is powered on by pressing the PSWITCH and a battery is present.
The DC-DC converter starts when battery power is detected and the
PSWITCH button is pressed."
After about 20 secounds, the VDDIO_3V3 goes low, but high if I press
the button again. I guess it is a timeout, for we in firmware chose
correct config for the regulatos/DC DC.
The other board quickly flash the power LED when I press the button, just that.
I tried to connect the JTAG to the board that works correctly, using
the OpenOCD imx25 config file, and I got this:
Open On-Chip Debugger 0.4.0 (2010-05-13-20:02)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Warn : imx25.whatchacallit: nonstandard IR value
Warn : imx25.whatchacallit: nonstandard IR mask
Info : clock speed 6000 kHz
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Error: JTAG scan chain interrogation failed: all ones
Error: Check JTAG interface, timings, target power, etc.
Command handler execution failed
Warn : jtag initialization failed; try 'jtag init' again.
Well, it is not working, however I don' know what would happen...
Bob
From the datasheet it appears the serial JTAG is the default mode, and
also parallel JTAG pins need to be enabled in the MUX to get the JTAG
function. This implies the chip must boot code from somewhere which
sets up parallel JTAG before this mode can be used, which is a bit of
a Catch 22.
To set the OTP bits requires bitburner, so that would require the USB
target components to be working I think.
I have not seen a spec for serial JTAG, I wonder if it could be done
with a AT90USB device.
Casainho
> Hi Cas
>
> From the datasheet it appears the serial JTAG is the default mode, and
> also parallel JTAG pins need to be enabled in the MUX to get the JTAG
> function. This implies the chip must boot code from somewhere which
> sets up parallel JTAG before this mode can be used, which is a bit of
> a Catch 22.
:-( -- If I had a serial JTAG... anyone knows were I can buy one? or make one?
Then, I think I will try to use Chumby bootloader code to at least
turn on the LED, then I will know that I can run code. I will try to
boot from the uSDCard.
> To set the OTP bits requires bitburner, so that would require the USB
> target components to be working I think.
Matt told me something about the USB IC on board have wrong
connections, so, I will wait for Matt clarify this situation. Right
now I just assembled the components on sheet IMX233 and Power_boot.
> I have not seen a spec for serial JTAG, I wonder if it could be done
> with a AT90USB device.
Let's look for it :-)
Casainho
> On Thu, May 27, 2010 at 9:05 AM, Bob <bobcou...@googlemail.com> wrote:
>> Hi Cas
>>
>> From the datasheet it appears the serial JTAG is the default mode, and
>> also parallel JTAG pins need to be enabled in the MUX to get the JTAG
>> function. This implies the chip must boot code from somewhere which
>> sets up parallel JTAG before this mode can be used, which is a bit of
>> a Catch 22.
I posted a forum message on FreeScale:
http://forums.freescale.com/t5/i-MX-Microprocessors/help-on-i-MX233-OpenOCD-JTAG-serial-AND-sharing-our-Open/td-p/56148
I also commited to Lyre Sourceforge SVN, the initial code for blink
LED - but this time is just a copy of Chumby bootloader.
Here the link fr access to Sourceforge SVN:
https://sourceforge.net/scm/?type=svn&group_id=256528
Matt and John, can I add you both to Sourceforge Lyre? as commiters?
Bob, could you help me here? we need to be able to build a very simple
code, having a working Makefile.
Finally, we need to know how to use elftosb2.
john cooper
> On Thu, May 27, 2010 at 9:05 AM, Bob <bobcou...@googlemail.com> wrote:
>> Hi Cas
>>
>> From the datasheet it appears the serial JTAG is the default mode, and
>> also parallel JTAG pins need to be enabled in the MUX to get the JTAG
>> function. This implies the chip must boot code from somewhere which
>> sets up parallel JTAG before this mode can be used, which is a bit of
>> a Catch 22.
>
> :-( -- If I had a serial JTAG... anyone knows were I can buy one? or make one?
Probably only from FSL. I brought out the DEBUG pin initially
on my board assuming in ignorance it was more usage friendly.
But after a brief look at the logic required to work the protocol,
abandoned the idea.
>> I have not seen a spec for serial JTAG, I wonder if it could be done
>> with a AT90USB device.
>
> Let's look for it :-)
It isn't going to happen with a AVR device as whatever is
used needs to synchronize with the imx233's 24Mhz clock
and have enough usable resolution beyond that rate to speak
the protocol. FSL's example uses a 8x (192Mhz) clocked
FPGA/CLPD. See chapter #34 in the reference manual.
It would be useful for board bringup if the bootrom gave
some well known sign of life such as burping out a character
or string on the dedicated debug uart. No such behavior is
documented AFAICT yet a "DUART" is called out in the
reference manual. I'm suspicious whether one of the
reserved boot modes may enable some type of communication
on the DUART port. Might be worth bouncing the question
off of FSL.
-john
Casainho
john cooper
> On Thu, May 27, 2010 at 9:52 AM, Casainho <casa...@gmail.com> wrote:
>> On Thu, May 27, 2010 at 9:05 AM, Bob <bobcou...@googlemail.com> wrote:
>>> Hi Cas
>>>
>>> From the datasheet it appears the serial JTAG is the default mode, and
>>> also parallel JTAG pins need to be enabled in the MUX to get the JTAG
>>> function. This implies the chip must boot code from somewhere which
>>> sets up parallel JTAG before this mode can be used, which is a bit of
>>> a Catch 22.
>
> I posted a forum message on FreeScale:
> http://forums.freescale.com/t5/i-MX-Microprocessors/help-on-i-MX233-OpenOCD-JTAG-serial-AND-sharing-our-Open/td-p/56148
Well that confirms the origin of the elftosb2 utility
and associated stumbling blocks.
> I also commited to Lyre Sourceforge SVN, the initial code for blink
> LED - but this time is just a copy of Chumby bootloader.
> Here the link fr access to Sourceforge SVN:
> https://sourceforge.net/scm/?type=svn&group_id=256528
> Matt and John, can I add you both to Sourceforge Lyre? as commiters?
Ok.
> Bob, could you help me here? we need to be able to build a very simple
> code, having a working Makefile.
>
> Finally, we need to know how to use elftosb2.
Can you try to trivially boot Chumby's image, or an
led-blinking-modified version of it? AFAICT their
board is booting from SSP1 via SD. Also check the
source for whatever image they're booting on SD. The
DUART connector is brought out on their board and I
wouldn't be surprised to see some progress chatter
appear on that async port.
-john
Casainho
<john....@third-harmonic.com> wrote:
>> I also commited to Lyre Sourceforge SVN, the initial code for blink
>> LED - but this time is just a copy of Chumby bootloader.
>> Here the link fr access to Sourceforge SVN:
>> https://sourceforge.net/scm/?type=svn&group_id=256528
>> Matt and John, can I add you both to Sourceforge Lyre? as commiters?
>
> Ok.
I guess I need your Sourceforge user ID do add you as commiter. What is your ID?
>> Bob, could you help me here? we need to be able to build a very simple
>> code, having a working Makefile.
>>
>> Finally, we need to know how to use elftosb2.
>
> Can you try to trivially boot Chumby's image, or an
> led-blinking-modified version of it?
They even have some commented code for LED blink... however I would
prefer to delete all the code not needed and just leave there the one
for LED. That also for the Makefile. I will take many hours to do
that... if you can make it more quickly, please go ahead and send to
here the files or commit to SVN.
Maybe next task, would be to build a code to change the OTP bits, to
enable parallel JTAG. There is good information on datasheet for how
to do that. So, first we must be able to boot and turn on that LED.
john cooper
> On Thu, May 27, 2010 at 2:38 PM, john cooper
>> Can you try to trivially boot Chumby's image, or an
>> led-blinking-modified version of it?
>
> They even have some commented code for LED blink... however I would
> prefer to delete all the code not needed and just leave there the one
> for LED.
See my prior mail. IIUC Chumby is enabling MBR recognized
booting by programming the SD_MBR_BOOT eFuse. So with a
factory default imx233 you'll need to try booting via writing
out a valid BCB to the last block of SD media.
AFAICT there isn't any drawback to BCB vs. MBR booting
going forward. Just for bringup the Chumby SD image build
won't work unmodified.
> Maybe next task, would be to build a code to change the OTP bits, to
> enable parallel JTAG. There is good information on datasheet for how
> to do that. So, first we must be able to boot and turn on that LED.
Agreed. I think BCB boot is the only solution at this point
unless you want to use the FSL windoze tools to modify the
OTP/fuse bits.
-john
Casainho
> booting by programming the SD_MBR_BOOT eFuse. So with a
> factory default imx233 you'll need to try booting via writing
> out a valid BCB to the last block of SD media.
>
> AFAICT there isn't any drawback to BCB vs. MBR booting
> going forward. Just for bringup the Chumby SD image build
> won't work unmodified.
I am not having time to understand all this information, but I hope to learn.
>> Maybe next task, would be to build a code to change the OTP bits, to
>> enable parallel JTAG. There is good information on datasheet for how
>> to do that. So, first we must be able to boot and turn on that LED.
>
> Agreed. I think BCB boot is the only solution at this point
> unless you want to use the FSL windoze tools to modify the
> OTP/fuse bits.
I don't know what is BCB. Assuming I have a elf file for the blink
LED, what should I do to put that sb file(after elf'ing'tosb)?
Is there any code to format the uSDCard and make it "BCB way"? (on Linux host)
Devs on FreeScale just answered to my questions.
- About elftosb:
http://forums.freescale.com/t5/i-MX-Microprocessors/how-to-use-elftosb2-software-on-imx233/m-p/56173#M801
- About OpenOCD script to imx233:
http://forums.freescale.com/t5/i-MX-Microprocessors/help-on-i-MX233-OpenOCD-JTAG-serial-AND-sharing-our-Open/m-p/56175#M803
Bob
is the link again: http://forum.chumby.com/viewtopic.php?id=5056 I
guess they are not using encryption because I don't see any keys
there.
Of course, to get unencrypted boot we need to set OTP bits...
The BCB/MBR modes are described in the imx233 ref manual, section
35.7. MBR is Master Boot Record, which is a normal part of the FAT
partitioning system. I think there is a special partition for the
imx233 boot loader. As John says, Chumny use the MBR method, I think
they have some scripts for setting up SD cards. There are some posts
on the Chumby forum about this, possibly http://forum.chumby.com/viewtopic.php?id=4338
BCB is Boot Control Block, which AFAIK is non-standard usage specific
to imx233. I guess the SD is partitioned so that a "gap" is left at
the end of the storage space and the boot stuff written there.
At this point it appears essential that we can get bitburner working,
as we need to program several OTP bits to do anything. I guess we also
need to reprogram as needed until we can get to a good config.
I also think I saw some reference to messages on the debug UART, I'll
see if I can find those.
john cooper
>> See my prior mail. IIUC Chumby is enabling MBR recognized
>> booting by programming the SD_MBR_BOOT eFuse. So with a
>> factory default imx233 you'll need to try booting via writing
>> out a valid BCB to the last block of SD media.
>>
>> AFAICT there isn't any drawback to BCB vs. MBR booting
>> going forward. Just for bringup the Chumby SD image build
>> won't work unmodified.
>
> I am not having time to understand all this information, but I hope to learn.
Check out section 35.7.1 and 35.7.2 in the imx233 reference manual.
>>> Maybe next task, would be to build a code to change the OTP bits, to
Per Bunnie's mail the imx233's bootrom can program OTP bits
without a windowZe umbilical. Merry Christmas. However I don't
know where this is documented but hopefully it isn't limited to
release under NDA as this is the first I've heard of such a facility.
Understanding this is definitely task #1 as most/all of the awkward
default config options for us can be reverted.
>>> enable parallel JTAG. There is good information on datasheet for how
>>> to do that. So, first we must be able to boot and turn on that LED.
>> Agreed. I think BCB boot is the only solution at this point
>> unless you want to use the FSL windoze tools to modify the
>> OTP/fuse bits.
>
> I don't know what is BCB. Assuming I have a elf file for the blink
> LED, what should I do to put that sb file(after elf'ing'tosb)?
> Is there any code to format the uSDCard and make it "BCB way"? (on Linux host)
Before we take that path, lets try to replicate Chumby's boot
image workflow as we know that works. Note I haven't yet dug
into their code so I could be missing issues with my assumptions
here.
-john
Bob
> Before we take that path, lets try to replicate Chumby's boot
> image workflow as we know that works. Note I haven't yet dug
> into their code so I could be missing issues with my assumptions
> here.
It looks like the source for the Chumby OTP prorammer is the
"chumby_factory" target in the bootstream code. I think we are missing
the elftosb2 config file for that target, file "../config/
falconwing_factory_sb.db" is not in the tarball.
Casainho
> is the link again: http://forum.chumby.com/viewtopic.php?id=5056 I
> guess they are not using encryption because I don't see any keys
> there.
Nice!
Answer to my questions on FreeScale forum:
"A .bd file is a command script that instructs the ROM on how to
behave (which ELF file(s) to load, call, and jump to). There are
examples of .bd files and their contents in the Linux BSP.
You can think of an .sb file as a "fancy" ELF file that is made to run
on i.MX233. It can be encrypted, and can consist of multiple ELF
files. For example, one ELF could initialize the power system, then
the ROM would load/call the next ELF file, which may initialize the
SDRAM, then the ROM may finally jump to some application ELF file.
That behavior is defined in the .bd file and the .sb file is the end
result binary, which can be run on i.MX233."
And they told me also to look at Linux sources, because are there a
few .bd files which we can take as examples.
> Of course, to get unencrypted boot we need to set OTP bits...
No! I read on forum that by default that bit is disable! I know that
on datasheet they say the other way, but no, we need to provide the
keys and enable that bit to have the encryption work. Since we do not
want it, I think we just need to turn off the fuse for JTAG.
And maybe the bit that makes SDCard wait something, for compatibility?
no? that patch for ROM can be avoided if we change that bi, no?
> The BCB/MBR modes are described in the imx233 ref manual, section
> 35.7. MBR is Master Boot Record, which is a normal part of the FAT
> partitioning system. I think there is a special partition for the
> imx233 boot loader. As John says, Chumny use the MBR method, I think
> they have some scripts for setting up SD cards. There are some posts
> on the Chumby forum about this, possibly http://forum.chumby.com/viewtopic.php?id=4338
>
> BCB is Boot Control Block, which AFAIK is non-standard usage specific
> to imx233. I guess the SD is partitioned so that a "gap" is left at
> the end of the storage space and the boot stuff written there.
So, BCB would permit that we have a card with a normal FAT file system
with user data and the boot code at end of the card? Maybe could be
useful.
Casainho
"The EVK board has a built in CPLD to convert parallel JTAG signal to
the proprietary SJTAG signal used by the MX23.
If you were planning on debugging your own board that only had
parallel JTAG, then buring the OTP is one way to do that. The other
way would for you to have your first binary that runs (such as the
bootlet code) to clear the HW_DIGCTL_CTRL USE_SERIAL_JTAG bit. When
you burn the OTP fuse, this just causes ROM to do the same thing
(clear that bit)."
Bob
> > Of course, to get unencrypted boot we need to set OTP bits...
>
> No! I read on forum that by default that bit is disable! I know that
> on datasheet they say the other way, but no, we need to provide the
> keys and enable that bit to have the encryption work.
What the Freescale guy says is logical, but the datasheet says
differently. It be nice if Freescale could get this straight. In the
meantime, I guess we have to try it and find out. We should ask Chumby
for the config file for "chumby_factory", and try building that. It
might need to be relocated to internal RAM.
> So, BCB would permit that we have a card with a normal FAT file system
> with user data and the boot code at end of the card? Maybe could be
> useful.
The same is true of the MBR format, I think they both require special
partitioning of the SD card, possibly BCB is simpler.
john cooper
>> Of course, to get unencrypted boot we need to set OTP bits...
>
> No! I read on forum that by default that bit is disable! I know that
> on datasheet they say the other way, but no, we need to provide the
> keys and enable that bit to have the encryption work. Since we do not
> want it, I think we just need to turn off the fuse for JTAG.
AFAIK no one from FSL had definitively stated encryption is off
by default nor yet declared the manual is wrong concerning the
default mode for encryption.
I believe encryption is enabled by default. Chumby seems to
confirm this.
> And maybe the bit that makes SDCard wait something, for compatibility?
> no? that patch for ROM can be avoided if we change that bi, no?
Possibly. Or maybe FSL will fix the rom bug, but not yet
apparently.
> So, BCB would permit that we have a card with a normal FAT file system
> with user data and the boot code at end of the card? Maybe could be
> useful.
Depending on how I interpret Bunnie's response, there may be
a facility in the imx233 bootrom to program OTP bits, or it may
be in Chumby supplied code. If the latter then it appears that
code would need to load in BCB format.
-john
Casainho
the power LED working, the VDDIO_3V3 is correct and is generated by
the imx233, from the internal DC-DC.
The board that is not working, flash the power LED when I press the
power switch. Looks like imx233 quickly turns on the DC-DC and off.
Why? I verified with ohmmeter and I do not have a short circuit on
VDDIO_3V3...
I am sending oscilloscope images of VDDIO_3V3 and on both pins of L1,
the one connected to imx233 DC-DC pins.
Bob
chip will shutdown if crystal is not running, so I would check that
too.
> 197KViewDownload
>
> propendous-imx233-OK-L1_imx233_pin_DCDC_LP-20100528.bmp
> 197KViewDownload
>
> propendous-imx233-OK-L1_pins-20100528.bmp
> 197KViewDownload
>
> propendous-imx233-WRONG-VDDIO_3V3-20100528.bmp
> 197KViewDownload
>
> propendous-imx233-WRONG-L1_pins-20100528.bmp
> 197KViewDownload
>
> propendous-imx233-OK-L1_imx233_pin_DCDC_LN1-20100528.bmp
> 197KViewDownload
john cooper
> The DCDC will shut down if there is a short in VDDD or VDDA. Also the
> chip will shutdown if crystal is not running, so I would check that
> too.
There is also a power-off shutdown if boot fails under certain
conditions although I can't locate the reference ATM.
But judging from the time response of the shutdown and the
bulk cap discharge curve this seems to be a hardware issue
yet AFAICT not a current overload -- at least not on the scoped
power rail. Did you check the voltage of the 1.2/1.8/2.5 rails
as well? Could also be over/undervoltage shutdown, the former
potentially due to missing/defective bypass cap on some DC/DC
converter output rail.
-john
> On 28 May, 11:43, Casainho <casai...@gmail.com> wrote:
>> So, I have 1 board working and other not working. The one working have
>> the power LED working, the VDDIO_3V3 is correct and is generated by
>> the imx233, from the internal DC-DC.
>>
>> The board that is not working, flash the power LED when I press the
>> power switch. Looks like imx233 quickly turns on the DC-DC and off.
>> Why? I verified with ohmmeter and I do not have a short circuit on
>> VDDIO_3V3...
>>
>> I am sending oscilloscope images of VDDIO_3V3 and on both pins of L1,
>> the one connected to imx233 DC-DC pins.
>>
>> propendous-imx233-OK-VDDIO_3V3-20100528.bmp
>> 197KViewDownload
>>
>> propendous-imx233-OK-L1_imx233_pin_DCDC_LP-20100528.bmp
>> 197KViewDownload
>>
>> propendous-imx233-OK-L1_pins-20100528.bmp
>> 197KViewDownload
>>
>> propendous-imx233-WRONG-VDDIO_3V3-20100528.bmp
>> 197KViewDownload
>>
>> propendous-imx233-WRONG-L1_pins-20100528.bmp
>> 197KViewDownload
>>
>> propendous-imx233-OK-L1_imx233_pin_DCDC_LN1-20100528.bmp
>> 197KViewDownload
>
Casainho
> The DCDC will shut down if there is a short in VDDD or VDDA.
I see no short on both.
Also the
> chip will shutdown if crystal is not running, so I would check that
> too.
I saw on oscilloscope, it runs on 24MHz, during a few time (since
start until DC-DC shuts down). I am comparing both boards.
On datasheet, it says:
Power-down is also controlled by the DC-DC converters. When the DC-DC
converter detects a
power-down event, it returns the player to the off state described
above. The power-down sequence is
started when one of these events occurs:
• HW_POWER_RESET_PWD bit set while the register is unlocked. --
NOT VERIFIED, BUT SHOULD BE OK BY DEFAULT.
• Error condition occurs, as described in Section 32.2.1.1,
“Brownout/Error Detection.” -- MORE LATER.
• The watchdog timer expires while enabled. -- NOT VERIFIED, BUT
SHOULD BE OK BY DEFAULT.
• Fast falling edge (<10 ns) on PSWITCH pin. -- VERIFIED AND
TIME IS ABOUT 10MS, THERE IS A CAPACITOR ON THAT PIN.
Brownout/Error Detection
The power subsystem has several mechanisms active by default that
safely return the device to the off
state if any one of the following errors or brownouts occur:
• The crystal oscillator frequency is detected below a certain
threshold—This threshold is process-
and voltage-sensitive, but will always be between 100 kHz and
2 MHz. This feature can be disabled
in the DISABLE_XTALOK field in the HW_RTC_PERSISTENT0
register. -- VERIFIED, ITS RUNNING AT 24MHZ.
• The battery voltage falls below the battery brownout level
(field BRWNOUT_LVL in
HW_POWER_BATTMONITOR)—This feature is disabled by clearing
PWDN_BATTBRNOUT
in the same register. -- VERIFIED, ITS OK, I AM RUNNIG FROM A
POWER SUPPLY WITH ENOUGH CURRENT.
• 5 V is detected, then removed—This feature is disabled by clearing
HW_POWER_5VCTRL_PWDN_5VBRNOUT. -- I AM NOT SUPPLYING 5V TO BOARD.
On Fri, May 28, 2010 at 3:24 PM, john cooper
<john....@third-harmonic.com> wrote:
> There is also a power-off shutdown if boot fails under certain
> conditions although I can't locate the reference ATM.
I am comparing both boards, if one works the other should work also -
the same conditions for boot.
> But judging from the time response of the shutdown and the
> bulk cap discharge curve this seems to be a hardware issue
> yet AFAICT not a current overload -- at least not on the scoped
> power rail.
Ok, good to know your opinion. Looks to me that also is not short.
Did you check the voltage of the 1.2/1.8/2.5 rails
> as well?
Not the 2.5V, where is it? what name have on scheme?
Could also be over/undervoltage shutdown, the former
> potentially due to missing/defective bypass cap on some DC/DC
> converter output rail.
Maybe! There is one 33uF cap that I didn't have, but both boards don't have it.
I am sending more oscilloscope images. Please see the differences over
the start of the VDDIO_3V3 signal. Looks like there are 2 different
values, 2.8V and 3.16V (no 3.3V, maybe because of my oscilloscope GND
reference be a bit far). Looks like the WRONG board just goes to 2.8V,
while the OK one goes to 2.8V and right after go to 3.16V!! -- maybe
this means something, no?
Casainho
john cooper
Bob
> Bob wrote:
> > The Chumby config file for elftosb2 was posted on Chumby forum, here
> > is the link again:http://forum.chumby.com/viewtopic.php?id=5056I
> > guess they are not using encryption because I don't see any keys
> > there.
>
> > Of course, to get unencrypted boot we need to set OTP bits...
>
> > The BCB/MBR modes are described in the imx233 ref manual, section
> > 35.7. MBR is Master Boot Record, which is a normal part of the FAT
> > partitioning system. I think there is a special partition for the
> > imx233 boot loader. As John says, Chumny use the MBR method, I think
> > they have some scripts for setting up SD cards. There are some posts
> > BCB is Boot Control Block, which AFAIK is non-standard usage specific
> > to imx233. I guess the SD is partitioned so that a "gap" is left at
> > the end of the storage space and the boot stuff written there.
>
> > At this point it appears essential that we can get bitburner working,
> > as we need to program several OTP bits to do anything. I guess we also
> > need to reprogram as needed until we can get to a good config.
>
> > I also think I saw some reference to messages on the debug UART, I'll
> > see if I can find those.
>
> Bob,
> What Chumby code drop/version are you referencing here?
from page http://files.chumby.com/source/
I think my comments in that post are now superseded by info from
Chumby, the key now seems to be chumby_factory which reprograms the
OTP bits. Chumby must have a script somewhere which creates a SD card
image, if we can find that we are nearly there.
john cooper
>> Bob,
>> What Chumby code drop/version are you referencing here?
>
> The code I am looking at is http://files.chumby.com/source/falconwing/build2370/bootstream-1.0.tgz
> from page http://files.chumby.com/source/
>
> I think my comments in that post are now superseded by info from
> Chumby, the key now seems to be chumby_factory which reprograms the
> OTP bits. Chumby must have a script somewhere which creates a SD card
> image, if we can find that we are nearly there.
Ok, I'll take a look in just a bit.
On a logistical note, I'm thinking we might want to
keep our collective inquiries to Chumby minimal and
as focused as possible. These folks impress as an
invaluable resource and I wouldn't want to wear out
their goodwill to us. They also aren't subscribed to
the google group, and mail they've sent is bouncing
back to them. So let's make it easy on them.
I'll offer to collect our questions and relay such
to/from them just to minimize their effort. Let me
know if this is workable for you guys.
Thanks,
-john
Casainho
> to/from them just to minimize their effort. Let me
> know if this is workable for you guys.
They should have busy times, so, we should not send them to much e-mails.
I am also taking advantage of FreeScale forum (and yes, I saw that
John also, under nick "uhmgawa").
john cooper
To be honest, the impression I received from Chumby is they
likely know more about this aspect of the imx233 than
the FSL representatives in that forum. Understandable as
Chumby arguably needed to solve these issues to keep the
payroll going.
-john
Casainho
writing a forum message on FSL asking for help on the current problem.
I will use the same pictures I sent to here before.
--
Cumprimentos,
Jorge Pinto
Bob
it looks like the wires go to pins 1 and 3, but I think it should be 1
and 2. Pin 3 is the thermistor.
Casainho
> Are sure you have the battery connection right? I could be wrong but
> it looks like the wires go to pins 1 and 3, but I think it should be 1
> and 2. Pin 3 is the thermistor.
Yeah, battery is ok.
I just forget for now the no working board and try to focus to boot
and blink the LED on the working one.
---
BOOTING
I were trying to boot using the uSDCard and the files Bob worked.
Board didn't boot and I were looking at clock signal for uSDCard,
there was none :-)
Ok, jumpers were wrong :-) -- Matt configured it in a way that there
is no need of any jumper in place, which is perfect, no need to use
any jumper.
propendous-imx233-OK-usdcard_boot-01-20100530: Channel 2 VDDIO_3V3 and
Channel 1 uSDCard clock. There are at least 20ms from boot to first
clock on uSDCard.
propendous-imx233-OK-usdcard_boot-02-20100530: Clock frequency is
250KHz, if I remember correctly, is the maximum frequency for setup
the uSDCard, after it, it can go up to 25MHz.
Casainho
How it was? -- first Bob sent me an image and I did:
sudo dd if=bootstream-factory.img of=/dev/sdb
Then I did:
sudo ./bootstream_make_bootable.pl /dev/sdb
And the board just turned on and rebooted after about 300ms. Then Bob
sent me another image where "power" and "clocks" images are not used.
And then this image just blinks the LED, slow, but it blinks :-)
Many thanks goes for all of us and Chumby hackers :-) -- the code Bob
worked is on Lyre sourceforge SVN and is heavily based on Chumby
sources: http://lyre.svn.sourceforge.net/viewvc/lyre/
---
Not working board:
I just dissoldered the L1, and one pin on imx233 keeps that square
wave (PFM ?) while the other get nothing, as it was expected.
L1 have 0.4ohms out of circuit... unfortunately I just have 2 L1, one
for each board -- I can't change for a new one.
Bob told that looking for oscilloscope images, looks like if L1 is in
short, and looks the same to me.
I guess I will try to change the L1 over boards and at same time see
if I can get new ones from Farnell, which should take 4 days and 10€
for shipping :-(
Casainho
One pin ("the out pin"?) from L1 were not connected to imx233, that's
why looked like there was no capacitors, or like if L1 was in short.
It were a bad solder that I did.
NEXT TASKS:
Matt Opendous told me on e-mail that he finished almost his videos and
will put them online soon. He also told:
"the USB switch has an incorrect footprint but you can simply
> join all the USB traces. Look over the PCB in PCBnew to determine
> which traces to join. Top rightmost three and bottom inner three
> traces."
So, I don't know what I will assembly next. Bob, since I will send a
board to you, what do you think is best, SDRAM or USB? -- I guess USB
is good as the board can be powered by it, so no need for you use
right now the battery.
I would like to have LCD, it could help for debug messages. But, maybe
first we should see if SDRAM works, because if it do not work as we
need, then, no need to spend money on buying an LCD for this board.
Bob
> So, I don't know what I will assembly next. Bob, since I will send a
> board to you, what do you think is best, SDRAM or USB? -- I guess USB
> is good as the board can be powered by it, so no need for you use
> right now the battery.
checked out. I won't have much time for at least a week, so there is
no rush from my viewpoint. I also want to build a little proto board
for lcd, keys etc.
If the design is OK, I can solder up any remaining components. If
there are some mods required to the board it may be easier without
components in place. In the (unlikely?) we need to re-spin the board,
then we can save the components for the next revision.
Casainho
Ok.
But, what are really next task after the OTP firmware for fuses? --
because I can going ahead and solder... or should I put my energies
also on the OTP firmware?
Bob
> But, what are really next task after the OTP firmware for fuses? --
> because I can going ahead and solder... or should I put my energies
> also on the OTP firmware?
a bit for Matt to check the SDRAM.
In the meantime I think we can work on the blink_led project, and add
code to chumby_factory to enable the JTAG bit. I would be happy to
work with you on this, I have some time tomorrow but otherwise I am
busy next week.
I would also like to start adding in code to enable the clocks and
power sections, but I would need to check with Matt exactly what is
needed. There are various bits that need turning off (e.g. inrush
limiter), and other stuff needs to be set before enabling PLL (e.g.
VDDD voltage).
I have found some init code in the Linux BSP in the imx_bootlets
package, in the boot_prep target which we can probably use as a
template.
I think there are quite a few things to keep us busy, it's mainly a
question of detailed config now we have the basics working.
Casainho
> a bit for Matt to check the SDRAM.
I will be ready to help him and test with my board.
> In the meantime I think we can work on the blink_led project, and add
> code to chumby_factory to enable the JTAG bit. I would be happy to
> work with you on this, I have some time tomorrow but otherwise I am
> busy next week.
Ok.
> I would also like to start adding in code to enable the clocks and
> power sections, but I would need to check with Matt exactly what is
> needed. There are various bits that need turning off (e.g. inrush
> limiter), and other stuff needs to be set before enabling PLL (e.g.
> VDDD voltage).
Right, I forgot that. We need to have a blink LED using interrupt,
with clock configured by us. This is something we must do and
understand/know.
> I have found some init code in the Linux BSP in the imx_bootlets
> package, in the boot_prep target which we can probably use as a
> template.
Yeah, we need to re-use Open Source, take advantage of it. I will
start reading the datasheet of imx233 and look at imx_bootlets.
> I think there are quite a few things to keep us busy, it's mainly a
> question of detailed config now we have the basics working.
I will also try to assembly the USB part, but just to have the board
sourced with energy from USB port, since for now I will have mine
board always near the PC, so, no need to use a battery.
john cooper
> On 30 May, 18:28, Casainho <casai...@gmail.com> wrote:
>
>> But, what are really next task after the OTP firmware for fuses? --
>> because I can going ahead and solder... or should I put my energies
>> also on the OTP firmware?
>
> I know you are eager to get on with assembly, but I would really wait
> a bit for Matt to check the SDRAM.
That seems reasonable as it is the greatest variable
relative to a given board layout for this SoC.
> In the meantime I think we can work on the blink_led project, and add
> code to chumby_factory to enable the JTAG bit. I would be happy to
> work with you on this, I have some time tomorrow but otherwise I am
> busy next week.
Do you have the chumby shell building? That seems like a
useful intermediate stepping stone. Also should be convenient
to locate prospective ddr test routines. Unsure how much
of the 32KB sram remains though.
Incidentally you mentioned using a 4.3.2 toolchain per
Chumby's recommendation. Is a binary build available or
did you just roll one? If the latter what versions of
binutils and glibc are you using?
-john
john cooper
> Incidentally you mentioned using a 4.3.2 toolchain per
> Chumby's recommendation..
nm, just found it here:
http://wiki.chumby.com/mediawiki/index.php/GNU_Toolchain
-john
john cooper
> Do you have the chumby shell building? That seems like a
> useful intermediate stepping stone. Also should be convenient
> to locate prospective ddr test routines. Unsure how much
> of the 32KB sram remains though.
Looks like there are two versions of this monitor (aka
shell). The "chumby_factory" is rather small primarily
to fit inside of the 32K on-chip ram. But it does some
simple OTP programming and has a basic DDR test which
is probably fine to get started.
"chumby_boot" has more functionality and I expected to
see bss steered to ddr but the elf section header vma
looks like it is hitting a sram alias in the image I've
built. Unsure why ATM.
Both can boot an image from SD but are calling into the
FSL bootrom for SD io. Doesn't appear to be via a
structured interface but I'd like to be wrong. Wonder
if that at all factors into the rom bug fix stagnation..
-john
Bob
> Do you have the chumby shell building? That seems like a
> useful intermediate stepping stone. Also should be convenient
> to locate prospective ddr test routines. Unsure how much
> of the 32KB sram remains though.
builds chumby_factory, chumby_stub and chumby_boot. The only changes I
made to the source are in chumby_factory/src/shell.c to flash the LED
instead of programming OTP bits.
16K of the OCRAM is available for bootlets, since the boot ROM uses
the other 16K. chumby_factory comes in around 4K, but there is an 8K
offset in the link map which I am puzzled by. So we either have 8K or
12K free, I'm not sure... I'm assuming there are no mallocs!
chumby_stub also runs in OCRAM and is about 4KB. chumby_boot is over
100K and therefore loaded into SDRAM.
Btw, Chumby use a non-SB 2nd stage bootloader in a scheme similar to
your suggestion. They have some sort of mini filing system for it.
To recap:
====
Chumby boot code, in order of execution.
- chumby_factory aka bootstream-factory (BCB bootcode)
SB format, encrypted zero key.
Reprograms OTP bits if necessary, and reboots (to chumby_stub).
I have modified to flash LED.
Runs OK w/o clocks_prep, power_prep, sdram_prep bootlets.
- chumby_stub aka bootstream-chumby ("MBR" bootcode)
SB format, unencrypted. Normal boot, loads chumby_boot into SDRAM.
- chumby_boot
non-SB format. load and run linux kernel
=====
I believe everything is in our SVN repository, so once you have the
toolchain installed it should build. Creating the SD image is a manual
process still.
make clean is a bit unreliable.
Casainho
asked him to join us, sending this info to the group.
A quick question: what can we get if we have USB? any kind of USB
bootloader? I mean, for Rockbox port, I think we do not need USB since
Rockbox do not have USB working (I think).
> I posted some pictures to the PROpendous SVN. I needed to do a bit
> of additional board rework today. I too had some loose resistors and
> needed several attempts to get USB to work. Make sure to check the
> resistances on all the PSWITCH connections and jumper connections.
> Don't just check the resistors, check pins and neighbouring components
> to make sure your solder connections are proper. Also, check voltages
> when running.
>
> Is JTAG working for you yet? I have managed to enable parallel JTAG
> with 12mA drive strength and unencrypted boot but JTAG boot fails for
> me right now with OpenOCD. I will try different adaptors and testing
> of the pins tomorrow.
>
> I suggest you do not mount the DDR SDRAM until we can solve basic
> things like JTAG. Note from my pictures that I did not populate the
> capacitors closest to the SDRAM to make it easier to mount it later.
> Also, DigiKey has just obsoleted the DDR we are using. Only the
> expensive Micron RAM looks like it will be available into the future.
> I suggest we test with the current RAM and move on to Micron RAM as
> soon as we validate basic functionality.
>
> Later,
> Matt,
> Opendous Inc.
>
>
> P.S. Here is some output from USB mode. To get to it mount jumpers 1 and 3.
>
> [ 4263.963930] usbcore: registered new interface driver hiddev
> [ 4263.965192] generic-usb: probe of 0003:066F:3780.0001 failed with error -22
> [ 4263.965211] usbcore: registered new interface driver usbhid
> [ 4263.965213] usbhid: v2.6:USB HID core driver
> ubuntu@ubuntu:~$ sudo lsusb -vvv
> Bus 001 Device 005: ID 066f:3780 SigmaTel, Inc.
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> idVendor 0x066f SigmaTel, Inc.
> idProduct 0x3780
> bcdDevice 0.01
> iManufacturer 1 Sigmatel, Inc.
> iProduct 2 ROM Recovery
> iSerial 0
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 34
> bNumInterfaces 1
> bConfigurationValue 1
> iConfiguration 3 Recovery Configuration
> bmAttributes 0x80
> (Bus Powered)
> MaxPower 100mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 1
> bInterfaceClass 3 Human Interface Device
> bInterfaceSubClass 0 No Subclass
> bInterfaceProtocol 0 None
> iInterface 4 Recovery Interface
> ** UNRECOGNIZED: 09 21 10 01 00 01 22 90 00
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81 EP 1 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 1
> Device Qualifier (for other device speed):
> bLength 10
> bDescriptorType 6
> bcdUSB 2.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> bNumConfigurations 1
> Device Status: 0x0000
> (Bus Powered)
>
>
> On Sun, May 30, 2010 at 1:39 PM, Casainho <casa...@gmail.com> wrote:
>>> By the, the USB switch has an incorrect footprint but you can simply
>>> join all the USB traces. Look over the PCB in PCBnew to determine
>>> which traces to join. Top rightmost three and bottom inner three
>>> traces.
>>
>> Oh, it's working right now! one pin ("the out pin"?) from L1 were not
>> connected to imx233, that's why looked like there was no capacitors,
>> or like if L1 was in short. I was a bad solder I did.
>>
>> About USB, I will wait for your report when you post it for everyone.
>> Next I will solder SDRAM.
>>
>> Please join us and use the same code we are using. Right now you can
>> boot from uSDCard and put the LED blinking :-) -- code is on Lyre
>> sourceforge SVN.
>>
>> :-)
--
Cumprimentos,
Jorge Pinto
Bob
> Just to share the info Matt sent to me. As you can read, I already
> asked him to join us, sending this info to the group.
>
> A quick question: what can we get if we have USB? any kind of USB
> bootloader? I mean, for Rockbox port, I think we do not need USB since
> Rockbox do not have USB working (I think).
- battery charging (all in hardware?)
- access to HID Recovery mode (Bitburner?)
- there are no Rockbox USB drivers for this SoC until we write/port
them
- if we can get the Linux going, then I guess there is USB support in
the BSP, haven't really looked.
I was hoping for Rockbox to have USB charging working first, and long
term USB mass storage.
In the meantime I hoped we can dual boot Rockbox/Linux, and use Linux
drivers to provide mass storage device. This is similar to how some
Rockbox ports work already.
I don't think we get any kind of USB bootloader unless we write one, I
was expecting the microSD/SD to replace any need for bootloaders,
flash programmers etc.
As for USB host, I would regard that as pretty much a Linux thing.
Casainho
Ok :-)
> As for USB host, I would regard that as pretty much a Linux thing.
Ok, and actual board will not work as USB host since the USB mux IC
will not work, some problems on PCB routing. Actual USB signals must
bypass that USB mux IC.
Casainho
We are using right now the perl script 'write_bootstream.pl'! :-) Thanks :-)
> *) The "power" and "clocks" images set up power management and the CPU clocks. Technically they're not required, but it's still a good idea to have them. I believe the prep binaries are now open-source, and you can get them as part of the Freescale BSP.
We tried the "power" and "clocks" images and the blink LED code we
have didn't work, however it worked without them. With that image
files, the imx233 was shutting down himself just after booting (power
from battery).
Our blink LED code was pasted on Chumby 'shell.c' :-)
Casainho
> http://code.google.com/p/propendous/source/browse/#svn/trunk/Pictures
Ok, I also did that now - using the father in law computer with
Windows. I tried before with Wine, the program works but do not "see"
the imx233 on USB... maybe something about USB on Wine...
> I will post tutorials to the PROpendous.org website as soon as I
> have procedures in place for the various tasks.
>
>>And why aren't you sharing this information with others?
>
> All my work so far is in the PROpendous SVN but I want to wait to
> make sure things work before posting instructions or warnings for
> others. I don't yet know if what I am doing is correct.
>
> Enabling all clocks and power in firmware right now may be
> problematic. For example, do not enable VDDM (DDR Memory Power) until
> an actual chip is populated.
>
> I will spend the next while working on JTAG and debugging and then
> figure out the correct boot process for this board.
We will prefer to make a firmware that will enable/disable the fuses
that we need. Basically, Chumby sources do that and we want to
replicate. For now, I booted from uSDCard and blinked the LED, on a
virgin imx233 :-) -- code is here:
http://lyre.svn.sourceforge.net/viewvc/lyre/propendous-imx233_board/
Bob
> > *) If you're not planning on blowing OTP fuses, you can actually store the bootstream image at the very end of the car. The perl script write_bootstream.pl will take the whole chunk of data and write it there, and set up the BCB bits as well. The whole MBR thing applies only if you've blown the MBR OTP fuse bit.
>
> We are using right now the perl script 'write_bootstream.pl'! :-) Thanks :-)
BCB format is quite usable, but I think it's a lot neater to allocate
boot partitions at the start of a disk and allocate the rest to file
system. The boot SD is captive so perhaps it doesn't matter.
> > *) The "power" and "clocks" images set up power management and the CPU clocks. Technically they're not required, but it's still a good idea to have them. I believe the prep binaries are now open-source, and you can get them as part of the Freescale BSP.
"L2.6.31_10.04.00_ER_SOURCE Linux 2.6.31 Source Code Files 2010.04
Engineering Release" and it has revised and improved code in imx-
bootlets. This code has workarounds for the expanding list of errata,
so it should be useful. It also reveals an unannounced chip, iMX28?
Casainho
enable the JTAG parallel and 12mA. But JTAG seems not working :-(
By the way, in one board I changed the boot mode for SDCard to MBR,
and booth boards can boot the same image of blink LED -- I mean, using
'write_bootstream.pl' writes the image on SDCard that will boot
always.
In first image, I used the 'imx233.cfg' file and on second one, the
'imx25.cfg'. Looks to me that at least it get some correct values and
identify imx233... but after give that errors and so parallel JTAG is
not working :-(
And about USB, Matt made a mistake on USB mux IC, no way to use that
IC but board can work as USB device at least - like it is for me now.
john cooper
> On 31 May, 15:00, Casainho <casai...@gmail.com> wrote:
>>> *) If you're not planning on blowing OTP fuses, you can actually store the bootstream image at the very end of the car. The perl script write_bootstream.pl will take the whole chunk of data and write it there, and set up the BCB bits as well. The whole MBR thing applies only if you've blown the MBR OTP fuse bit.
>> We are using right now the perl script 'write_bootstream.pl'! :-) Thanks :-)
>
> We are using bootstream_make_bootable but it's a similar idea. I guess
> BCB format is quite usable, but I think it's a lot neater to allocate
> boot partitions at the start of a disk and allocate the rest to file
> system. The boot SD is captive so perhaps it doesn't matter.
>
>>> *) The "power" and "clocks" images set up power management and the CPU clocks. Technically they're not required, but it's still a good idea to have them. I believe the prep binaries are now open-source, and you can get them as part of the Freescale BSP.
>
> I have downloaded what I think is the latest Linux BSP described as
> "L2.6.31_10.04.00_ER_SOURCE Linux 2.6.31 Source Code Files 2010.04
> Engineering Release"
Have a pointer to that version? The release 1.6 / 2.6.28
is all I see on FSL's site.
-john
Casainho
> is all I see on FSL's site.
I am downloading from here:
The file name is: L2.6.31_10.04.01_ER_source.tar.gz
Casainho
Right now we have booting from uSDCard working and JTAG debugging. And
there is no big point now for burning eFuses, however that can be done
quickly as Chumby code have that already implemented and tested.
As for clocks and power, we have the latest FreeScale code with that.
I think that now we need to test the SDRAM!! And for it we will need
for sure the FreeScale code for clocks and power. And sure, we need
SDRAM soldered on the board, so, should I solder your SDRAM and send
the board to you?
If SDRAM goes ok, then we need to work on the LCD and buttons, and
finally on audio/Rockbox port.
Casainho
> Bob, should I send to you your board?
Bob, I used arm-none-eabi toolchain to build the enable parallel JTAG
and blink LED code. Don't you want to use it also at least because it
is easy for me (and you or others)? -- when we will port Rockbox, we
will need to use the other version ARM toolchain Rockbox uses.
Bob
not sure the version matters too much, but I guess it makes sense to
use the latest.
The Chumby recommended version is 4.3.2 (from CodeSourcery),
CodeSourcery latest is 4.4.1.
Rockbox have or seem about to move to EABI version, but I haven't
tried building the latest Rockbox with an EABI compiler. Hopefully we
can use the same compiler for Rockbox as everything else.
The Rockbox/app project has started under the Google sponsorship. It
looks like the initial target will be Android, but hopefully it will
be easily portable to any Linux with SDL.
And lastly, what has happened to lyre.sourceforge.net?
On 4 June, 14:38, Casainho <casai...@gmail.com> wrote:
Casainho
> Which toolchain are you referring to, the one from CodeSourcery?
That one, yes.
I'm
> not sure the version matters too much, but I guess it makes sense to
> use the latest.
Right.
> The Chumby recommended version is 4.3.2 (from CodeSourcery),
> CodeSourcery latest is 4.4.1.
>
> Rockbox have or seem about to move to EABI version, but I haven't
> tried building the latest Rockbox with an EABI compiler. Hopefully we
> can use the same compiler for Rockbox as everything else.
Yes.
> The Rockbox/app project has started under the Google sponsorship. It
> looks like the initial target will be Android, but hopefully it will
> be easily portable to any Linux with SDL.
This board will be able to run Android? I hope so, at least use it to
learn and discover Linux and Android.
I think we need a OS were Rockbox runs, which give us the USB,
Ethernet, wireless, and runs apps like trackers, PureData, etc, and
use small power.
> And lastly, what has happened to lyre.sourceforge.net?
It's working for me.
Bob
> This board will be able to run Android? I hope so, at least use it to
> learn and discover Linux and Android.
there.
It does for me now as well!
Casainho
Can you say what should we do now? How will we make SDRAM working?
FreeScale "imx-bootlets-src" sources seems to have code to initialize
the imx233, from the clocks to a few different SDRAMs. Also they test
100 sequential places in memory.
I never used/learned about external SDRAM...
Bob
based on code that is now part of the BSP. So I am looking at
L2.6.31_10.04.01_ER_source\pkgs\imx-bootlets-src-10.04.01\imx-bootlets-
src-10.04.01\boot_prep\init-mx23.c
This contains functions like this
void init_mddr_mt46h32m16lf_96Mhz(int ce)
{
HW_DRAM_CTL00_WR(0x01010001);
HW_DRAM_CTL01_WR(0x00010100);
HW_DRAM_CTL02_WR(0x01000101);
HW_DRAM_CTL03_WR(0x00000001);
HW_DRAM_CTL04_WR(0x00000101);
HW_DRAM_CTL05_WR(0x00000001);
HW_DRAM_CTL06_WR(0x00010000);
HW_DRAM_CTL07_WR(0x01000001);
HW_DRAM_CTL09_WR(0x00000001);
HW_DRAM_CTL10_WR(0x07000200);
HW_DRAM_CTL11_WR(0x00070203);
HW_DRAM_CTL12_WR(0x02020002);
HW_DRAM_CTL13_WR(0x06070a02);
HW_DRAM_CTL14_WR(0x00000200|ce);
HW_DRAM_CTL15_WR(0x03050000);
HW_DRAM_CTL16_WR(0x02000000);
HW_DRAM_CTL17_WR(0x2d000808);
HW_DRAM_CTL18_WR(0x1f1f0000);
HW_DRAM_CTL19_WR(0x020c1010);
HW_DRAM_CTL20_WR(0x0305101c);
HW_DRAM_CTL21_WR(0x00000007);
HW_DRAM_CTL22_WR(0x00080008);
HW_DRAM_CTL23_WR(0x00200020);
HW_DRAM_CTL24_WR(0x00200020);
HW_DRAM_CTL25_WR(0x00200020);
HW_DRAM_CTL26_WR(0x000002e6);
HW_DRAM_CTL29_WR(0x00000000);
HW_DRAM_CTL30_WR(0x00000020);
HW_DRAM_CTL31_WR(0x00000000);
HW_DRAM_CTL32_WR(0x000c1a3b);
HW_DRAM_CTL33_WR(0x0000000c);
HW_DRAM_CTL34_WR(0x00004b0d);
HW_DRAM_CTL36_WR(0x00000101);
HW_DRAM_CTL37_WR(0x00040001);
HW_DRAM_CTL38_WR(0x00400000);
HW_DRAM_CTL39_WR(0x00400040);
HW_DRAM_CTL40_WR(0x00030000);
HW_DRAM_CTL08_WR(0x01010000);
}
which set up DRAM regs (among other stuff). I haven't even tried
looking what all that does. I think it only makes sense to a hardware
guy ;)
I am hoping Matt will come up with the required runes! I don't think
there is much point in duplicating what Matt is doing, unless you are
interested of course.
I was thinking of getting a serial connection going, and maybe a
simple LCD driver for a nokia 3310. That should keep me busy until we
have SDRAM setup.
Casainho
> I assume that whatever Chumby use for clocks and sdram init etc is
> based on code that is now part of the BSP. So I am looking at
> L2.6.31_10.04.01_ER_source\pkgs\imx-bootlets-src-10.04.01\imx-bootlets-
> src-10.04.01\boot_prep\init-mx23.c
Yes, I am being looking at that code also.
> which set up DRAM regs (among other stuff). I haven't even tried
> looking what all that does. I think it only makes sense to a hardware
> guy ;)
>
> I am hoping Matt will come up with the required runes! I don't think
> there is much point in duplicating what Matt is doing, unless you are
> interested of course.
Matt do not communicates! :-( -- you know, we have getting much work
done by cooperating here.
If Matt is working on SDRAM, I could help him, because it's what I
want to do now, what I think is need to do now.
> I was thinking of getting a serial connection going, and maybe a
> simple LCD driver for a nokia 3310. That should keep me busy until we
> have SDRAM setup.
I am not really interest on serial port. I prefer instead the LCD and
I would like to compare the prices/advantages from the ones Matt did
choose to that Nokia LCD.
Casainho
>> simple LCD driver for a nokia 3310. That should keep me busy until we
>> have SDRAM setup.
>
> I am not really interest on serial port. I prefer instead the LCD and
> I would like to compare the prices/advantages from the ones Matt did
> choose to that Nokia LCD.
Ok, Matt give 3 options:
- €16.09, 128X160, with touchscreen:
- €24.75, 240X320, without touchscreen:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=NHD-2.4-240320SF-CTXI%23-ND
- €27.3, 240X320, with touchscreen:
I don't know if there is any connector to use with the LCD, does anyone knows?
Using touchscreen means that we need to use the TSC2003IPWR ic that costs 5.16€.
If we use touchscreen, we may not need to use buttons. I can' solder
the accelerometer, so, no possible to use it as "buttons".
Bob
One of the unknowns is the power consumption. Strangely, although this
is a key performance characteristic people are often unwilling to talk
numbers. IME this means it gets overlooked and battery life ends up
being terrible. Often it leads to late development efforts to
implement power saving when it could and should have been designed in
from the start.
If we have around 700mAH at 3.7V, for a life of 20 hours that's
something like 50ma average consumption at 3.3V. That is not a big
budget to play with. So my thinking is to start with something cheap
and very low power, and see where we are from there.
On the connector front, I thought Matt had a source in mind but I
don't remember where.
On 5 June, 00:45, Casainho <casai...@gmail.com> wrote:
> >> I was thinking of getting a serial connection going, and maybe a
> >> simple LCD driver for a nokia 3310. That should keep me busy until we
> >> have SDRAM setup.
>
> > I am not really interest on serial port. I prefer instead the LCD and
> > I would like to compare the prices/advantages from the ones Matt did
> > choose to that Nokia LCD.
>
> Ok, Matt give 3 options:
>
> - €16.09, 128X160, with touchscreen:
>
> - €24.75, 240X320, without touchscreen:
>
> - €27.3, 240X320, with touchscreen:
>
Bob
> If Matt is working on SDRAM, I could help him, because it's what I
> want to do now, what I think is need to do now.
following docs may be of general interest
http://cache.freescale.com/files/dsp/doc/app_note/AN3992.pdf?fpsp=1
https://www.ibm.com/developerworks/power/library/pa-tuncpc/
Casainho
> I thought you were keen on a cheap display with serial IO?
Cheap, yes. But the cheaper Nokia clone LCD costs $35
(http://www.sparkfun.com/commerce/product_info.php?products_id=8600)!
And I used it on AT91SAM9260 Lyre prototype. It's a bad quality LCD.
That LCD needs a "carrier" board, and the LCD have a very fine pitch
connector. It's difficult to solder and find the connector.
{
That Nokia clone LCD + carrier board consumes 324mA @ 3.3V, values
from Sparkfun page.
The 2.4" with touchscreen NHD-2.4-240320SF-CTXI#-T-ND LCD, consumes
7mA @ Vcc 2.8V and the backlight 20mA @ Vcc 3.2V!!
The 1.8'' LCD consumes about twice the 2.4''. So, I think the 2.4'' is
the best option we have.
}
Bob, if you think serial IO LCD is cheaper, can you give links to a
complete solution and details on to assembly it to the actual board?
> One of the unknowns is the power consumption. Strangely, although this
> is a key performance characteristic people are often unwilling to talk
> numbers. IME this means it gets overlooked and battery life ends up
> being terrible. Often it leads to late development efforts to
> implement power saving when it could and should have been designed in
> from the start.
>
> If we have around 700mAH at 3.7V, for a life of 20 hours that's
> something like 50ma average consumption at 3.3V. That is not a big
> budget to play with. So my thinking is to start with something cheap
> and very low power, and see where we are from there.
Remember that we can still use one 18650 size battery 3.7V 2000mAh.
> On the connector front, I thought Matt had a source in mind but I
> don't remember where.
The PROpendous-BillOfMaterials.txt do not list any connector:
~~~ Optional LCD Components ~~~
1, NHD-2.4-240320SF-CTXI#-T ,33.00 - U1 - LCD DISP TFT 2.4" 240X320 B/L
1, TSC2003IPWR , 6.75 - IC3 - IC TOUCH SCREEN 12BIT 16TSSOP
1, 2N7002TA , 0.26 - Q1 - MOSFET N-CH 60V 115MA SOT23-3
2, GRM188R71C104KA01D , 0.01 - C28 C35 - CAP CER .1UF
16V 10% X7R 0603
1, GRM188R61A105KA61D, , 0.04 - C29 - CAP CER 1.0UF 10V
10% X5R 0603
1, C2012X5R0J106K , 0.23 - C30 - CAP CER 10UF 6.3V
X5R 10% 0805
1, TCA0J336M8R , 0.33 - C78 - CAP TANT 33UF 6.3V
20% SMD 3-Ohm-ESR 1206
4, RMCF 1/16 10 1% R , 0.04 - R15 R12 R13 R14 - RES 10
OHM 1/10W 1% 0603 SMD
2, RMCF 1/16 1.2K 1% R , 0.04 - R17 R18 - RES 1.2K OHM
1/10W 1% 0603 SMD
3, RMCF 1/16 47K 5% R , 0.02 - R11 R16 R19 - RES 47K OHM
1/10W 5% 0603 SMD
~~~~~~~~~~~~~~~~~~~~~~~~~~~Sub-Total=40.92
- U1, the 2.4" LCD can be substituted with NHD-1.8-128160ZF-CTXL#, a
1.8" LCD or
the NHD-2.4-240320SF-CTXI# which has no touch screen
Casainho
Thanks! I started reading an Atmel Application Note for setup SDRAM on
their AT91SAM, to learn a bit more about SDRAM.
Casainho
For a portable audio player/recorder, I would prefer a smaller one,
the 1.8'', but just if we had a smaller board.
The schematics seems to have different voltages than the ones
indicated on LCD datasheet... will it work????
john cooper
> I thought you were keen on a cheap display with serial IO?
I'd been torturing over this design issue.
> One of the unknowns is the power consumption. Strangely, although this
> is a key performance characteristic people are often unwilling to talk
> numbers. IME this means it gets overlooked and battery life ends up
> being terrible. Often it leads to late development efforts to
> implement power saving when it could and should have been designed in
> from the start.
Power consumption was my primary concern as the "display viewing
duty-cycle" for an audio decoder should typically be low unless you're
tied to it for all input. All else being equal I'd love to toss a color
TFT display + touchscreen in the design however there are two draw backs.
The greater is the fact all color TFTs are transmissive meaning
the backlight is on or you don't see it. Some monochrome displays are
as well, but the majority are transreflective such that they are
illuminated via backlight and/or ambient light. Reflective LCDs (eg:
calculator displays) rely exclusively on ambient light. I thought to
punt on a backlight altogether as transreflective displays are
somewhat of a compromise but that seems overly restrictive.
Touchscreen would be nice from certain perspectives and it would
simplify the case mechanicals considerably. But I'm not sure I
want to give up tactile feedback and be tied to navigating exclusively
on a touchscreen. I'm proceeding with the monochrome transreflective
display but can't completely dismiss the possibility of TFT.
Ironically in prototype/experimentation quantities price-wise TFTs
and monochrome displays seem to be about the same cost if not finding
TFT's occasionally cheaper.
> If we have around 700mAH at 3.7V, for a life of 20 hours that's
> something like 50ma average consumption at 3.3V. That is not a big
> budget to play with. So my thinking is to start with something cheap
> and very low power, and see where we are from there.
You can probably fit a considerably higher capacity Li-ion cell
in your enclosure. I'm maxed out volume wise at about 810-850maH
with the more common choices in aftermarket cell phone batteries.
I've looked at FSL's power consumption spreadsheet for the imx233
but it still seems like there were enough loose ends and assumptions
in those numbers that I'd couldn't derive a believable steady state
power consumption figure for an audio decode application. Although I
think 20 hours is a good target goal.
>> Using touchscreen means that we need to use the TSC2003IPWR ic that costs 5.16�.
I believe you could do much better than that price although
in general they seem rather pricey for an A/D converter.
Actually the tsc2007 is a more sophisticated device which performs
multiple sampling and digital filtering without host intervention.
Oddly it is even cheaper and is AFAICT a drop-in replacement for the
tsc2003. The more basic tsc2003 has fundamental limitations given
the communication speed of the I2C bus (400KHz is max on the imx233)
such that you may not be able to sample the controller at a rate
sufficient for the desired user interaction. There is a paper on TI's
site which gives details.
If I ever traverse this path I'd have a look at using a cheap $2
AVR with a built-in A/D converter. One could likely squeeze other
features out of it as well.
-john
Bob
> You can probably fit a considerably higher capacity Li-ion cell
> in your enclosure. I'm maxed out volume wise at about 810-850maH
> with the more common choices in aftermarket cell phone batteries.
in parallel?
With the original case/design I envisaged splitting the space
horizontally, as this fits the stock battery compartment arrangement,
but there is not a lot of options in that space.
The common li-ion form seems to be the wide flat shape, but we don't
have much usable space in the vertical direction in our chosen case
style, but only by a few mm. I think 2 layers in the sandwich allows
plenty of fitting room, but 3 layers really needs custom design to
achieve more efficient use of the volume.
It would be interesting to have Casainho print some custom boxes and
see what we can do. With Matts board, we could probably pack the Z
direction without increasing the overall thickness and reduce the
length by chopping off the battery compartment.
john cooper
> On 5 June, 16:05, john cooper <john.coo...@third-harmonic.com> wrote:
>> You can probably fit a considerably higher capacity Li-ion cell
>> in your enclosure. I'm maxed out volume wise at about 810-850maH
>> with the more common choices in aftermarket cell phone batteries.
>
> This might be a daft question, but can we use two AA size li-ion cells
> in parallel?
Never have tried to do so myself but I think it is
reasonable assuming the cells are closely matched.
If I were looking at some experimentation here I'd
start with two from the same manufacturing run.
That said Li batteries can have spectacular failure
modes. But then again so do automobiles.
> With the original case/design I envisaged splitting the space
> horizontally, as this fits the stock battery compartment arrangement,
> but there is not a lot of options in that space.
>
> The common li-ion form seems to be the wide flat shape, but we don't
> have much usable space in the vertical direction in our chosen case
> style, but only by a few mm. I think 2 layers in the sandwich allows
> plenty of fitting room, but 3 layers really needs custom design to
> achieve more efficient use of the volume.
I've only looked at Motorola cell phone batteries (cells)
but there is somewhat of a selection in capacities and
physical footprints. Most are in around 5mm thick and
just under 1AH. Have you given the dealextreme.com cells
a look?
> It would be interesting to have Casainho print some custom boxes and
> see what we can do. With Matts board, we could probably pack the Z
> direction without increasing the overall thickness and reduce the
> length by chopping off the battery compartment.
I spent a fair amount of time with my board set trying to
compress the Z sprawl and found 5mm board-board standoff
was about as far as I could go via just arranging components
on both boards so as not to interfere. Going under 5mm
connector profiles are hard obstacles, followed by the inductor
soon after that. Incidentally once you get to this degree of
scrutiny the 1.6mm board laminate (here x2) starts to get
objectionable. 0.5~0.8mm laminate seems to be a reasonable
compromise between minimizing volume and acceptable rigidity.
-john
Casainho
> On 5 June, 16:05, john cooper <john.coo...@third-harmonic.com> wrote:
>> You can probably fit a considerably higher capacity Li-ion cell
>> in your enclosure. I'm maxed out volume wise at about 810-850maH
>> with the more common choices in aftermarket cell phone batteries.
>
> This might be a daft question, but can we use two AA size li-ion cells
> in parallel?
I think yes, however I never saw that. Maybe using small resistor in
series with each battery. Or simply forget that resistors as they have
they own internal resistance.
Some batteries on DealExtreme have internal protection circuit against
over/under voltage and over current. I had opened one of that
batteries to see the small circuit board (about 2 or 3mm, placed at
back of the original battery). I would place 2 of that batteries in
parallel and trust on it. See the attached image. Actual Hammond
enclosure have space for 2 * AA size batteries -- we would ended up
with 3.7 1400mAh (2 * 700mAh, real values although battery is rated
outside as 900mAh).
> It would be interesting to have Casainho print some custom boxes and
> see what we can do. With Matts board, we could probably pack the Z
> direction without increasing the overall thickness and reduce the
> length by chopping off the battery compartment.
If SDRAM works nicely, I think we should do another board revision,
this time in getting it smaller, maybe think in Z expansion boards. We
could even make a design for it, I mean, first design in 3D the
enclosure - or simple do a board small as possible and in the end
shape an enclosure for it, including the holes for USB device and host
connectors, audio connectors, buttons and LCD hole.
Having the option to quickly change and produce the enclosure, will
mean that users can quickly change the number/shape of batteries,
stack new boards on Z axis, add USB devices like HDD, Ethernet, Wifi,
etc.
People on RepRap community can be hired to print enclosures! They are
many and everyone will be happy to win some money - and I strong
believe that a printed enclosure is at least 4 times more cheap that
the Hammond enclosures!
Well, we may have here the Arduino V3!!!!!!!! A device capable of run
Linux and Android, DIY, and with many possibilities! Am I dreaming?
yes, I am, but I know we are every time more close to that reality!
And most important, I think market need such kind of
device/technology!
I need to work more on SDRAM and chat less ;-)
john cooper
> Some batteries on DealExtreme have internal protection circuit against
> over/under voltage and over current. I had opened one of that
> batteries to see the small circuit board (about 2 or 3mm, placed at
> back of the original battery).
Are you certain that is an active current limit device
or just a simple fuse? The Motorola Li-ion cells have
(AFAICT) some type of one-wire EEPROM within the battery
case. It could conceivably also contain an A/D but in
that event I wouldn't expect to find the analog
thermistor/diode temp sensor brought out to the connector.
That's what I can puzzle from the actual phone schematics
as I'm still waiting for the DealExtreme boat to arrive.
> If SDRAM works nicely, I think we should do another board revision,
> this time in getting it smaller, maybe think in Z expansion boards. We
> could even make a design for it, I mean, first design in 3D the
> enclosure - or simple do a board small as possible and in the end
> shape an enclosure for it, including the holes for USB device and host
> connectors, audio connectors, buttons and LCD hole.
I seem to have heard this somewhere before. ;)
> Having the option to quickly change and produce the enclosure, will
> mean that users can quickly change the number/shape of batteries,
> stack new boards on Z axis, add USB devices like HDD, Ethernet, Wifi,
You'll want to create a USB hub similar to the Chumby design
as USB is the only high bandwidth route out of that silicon.
I provided for an SPI ethernet in my design but that was just
a concession for debugging such that a kernel can boot on an
NFS root vs. having to re-write the flash as part of the
workflow.
-john
Casainho
>> over/under voltage and over current. I had opened one of that
>> batteries to see the small circuit board (about 2 or 3mm, placed at
>> back of the original battery).
>
> Are you certain that is an active current limit device
> or just a simple fuse? The Motorola Li-ion cells have
> (AFAICT) some type of one-wire EEPROM within the battery
> case. It could conceivably also contain an A/D but in
> that event I wouldn't expect to find the analog
> thermistor/diode temp sensor brought out to the connector.
> That's what I can puzzle from the actual phone schematics
> as I'm still waiting for the DealExtreme boat to arrive.
This ones: http://www.dealextreme.com/details.dx/sku.26112
And what you bought from DX? a battery for this project?
john cooper
Ah, I see. The imx233 will do equivalent cell
management except it doesn't act as a series
current limit switch.
> And what you bought from DX? a battery for this project?
There are several similar Motorola Li-ion cells available
with slightly different capacities, footprints, and
connector locations. Considering the flood of Motorola
cell phones on the planet it took far more effort than
I anticipated to find a domestic source of the direct-to-pcb
mating connector. Anyway this cell seems the best
compromise for my board as it is just about the same size
size and depth is only 5mm:
http://www.dealextreme.com/details.dx/sku.23708
I'm just waiting for this to show up as I haven't been
able to find definitive mechanical data on the
housing, exact connector location in particular.
-john
john cooper
> On 5 June, 00:11, Casainho <casai...@gmail.com> wrote:
>
>> If Matt is working on SDRAM, I could help him, because it's what I
>> want to do now, what I think is need to do now.
>
> I don't have anything specifically on our components, but the
> following docs may be of general interest
What exact DDR components are you using?
> http://cache.freescale.com/files/dsp/doc/app_note/AN3992.pdf?fpsp=1
>
> https://www.ibm.com/developerworks/power/library/pa-tuncpc/
>
Bob
> What exact DDR components are you using?
but is now obsolete.
The Freescale EVK uses Micron parts, and I think Chumby use Hynix.
Casainho
> On 7 June, 08:28, john cooper <john.coo...@third-harmonic.com> wrote:
>> What exact DDR components are you using?
>
> I believe it is this one http://search.digikey.com/scripts/DkSearch/dksus.dll?vendor=0&keywords=W9425G6EH-5,
> but is now obsolete.
Yes, is that one.
Since I understand, the problem is not to configure on memory
controller the collums, rows, banks, CAS latency of the memory,
because that is on memory datasheet. The difficult will be the delays
for signals to match the board.