[U-Boot-Users] Latest git not working for MPC8349EMDS

[U-Boot-Users] Latest git not working for MPC8349EMDS

[Benedict, Michael]

Hello all,
	I am trying to update U-Boot on my MPC8349EA-MDS.  I tried both
the u-boot.git and u-boot-mpc83xx.git repositories.  After I reset, I
get nothing on the serial console.  I was hoping someone might have a
suggestion before I try to configure the BDI-2000 for this target and
begin debugging this.  BDI configs for the 8349EA-MDS would also be
appreciated.
	Thank you!
		Michael

[U-Boot-Users] Latest git not working for MPC8349EMDS

[David Hawkins]

Hi Michael,

> 	I am trying to update U-Boot on my MPC8349EA-MDS.  I tried both
> the u-boot.git and u-boot-mpc83xx.git repositories.  After I reset, I
> get nothing on the serial console.  I was hoping someone might have a
> suggestion before I try to configure the BDI-2000 for this target and
> begin debugging this.  BDI configs for the 8349EA-MDS would also be
> appreciated.

How old was the U-Boot version that you upgraded from?
Eg. did you update from the Freescale version shipped with the
board to a version from the Denx git repo, or was it a old Denx
repo version to new version upgrade that broke things?

The MPC9349E boot sequence was modified at one point, and
so to boot a new kernel you had to also change the HRCW.
I forget the details, but here's my notes ...

http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf

see the comments on p18.

I have an MPC8349EA board as well, but I haven't had time to
test it yet.

Hope that helps.
Dave

[U-Boot-Users] Latest git not working for MPC8349EMDS

[Benedict, Michael]

David Hawkins wrote:
>> 	I am trying to update U-Boot on my MPC8349EA-MDS.  
> 
> How old was the U-Boot version that you upgraded from?
> 
I am upgrading from 1.1.3, that shipped on the board.

> The MPC9349E boot sequence was modified at one point, and
> so to boot a new kernel you had to also change the HRCW.
> I forget the details, but here's my notes ...
> 
> http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf
> 
> see the comments on p18.
 
I am pretty confused by your notes as they relate to my image.  For me,
I am flashing at fff00000.  This is sufficient to brick the board :-D.
It seemed like your notes were reflecting a change in the boot address
between versions?  I tried to use the addresses you mention and 1)
fe000000 tells me it is not erased, even after I erase it (?) and 2)
fe700000 seems to have no effect. I thought those were the u-boot
locations for the mpc8349ITX (?).

Just to be clear, I am not even at the point of booting the kernel, just
trying to get to the u-boot prompt of a new u-boot.

I really appreciate the help!  Unfortunately, I am just more confused at
the moment.
	Thank you,
		Michael

[U-Boot-Users] Latest git not working for MPC8349EMDS

[Timur Tabi]

Benedict, Michael wrote:
> David Hawkins wrote:
>>> 	I am trying to update U-Boot on my MPC8349EA-MDS.  
>> How old was the U-Boot version that you upgraded from?
>>
> I am upgrading from 1.1.3, that shipped on the board.
> 
>> The MPC9349E boot sequence was modified at one point, and
>> so to boot a new kernel you had to also change the HRCW.
>> I forget the details, but here's my notes ...
>>
>> http://www.ovro.caltech.edu/~dwh/powerpc_mpc8349e.pdf
>>
>> see the comments on p18.
>  
> I am pretty confused by your notes as they relate to my image.  For me,
> I am flashing at fff00000.  This is sufficient to brick the board :-D.
> It seemed like your notes were reflecting a change in the boot address
> between versions?  I tried to use the addresses you mention and 1)
> fe000000 tells me it is not erased, even after I erase it (?) and 2)
> fe700000 seems to have no effect. I thought those were the u-boot
> locations for the mpc8349ITX (?).

The ITX can boot from FE000000 or FEF00000 if you're using the latest code from denx.de. 
FE700000 is the address of the "alternate" U-Boot location.  If you flip a jumper, 
addresses from FE000000-FE7F0000 are swapped with FE800000-FEFFFFFF.  This causes the 
U-Boot that used to be at FE700000 to appear at FEF00000.

Michael, I think your problem is in the configuration.  For instance, you're building a 
U-Boot from the wrong config file, or you're flashing it to the wrong address, or there's 
some low-level config option that's set wrong, like a LAWAR or LAWBAR.

I would use a BDI.  You need to find out which instruction is causing the hang/panic.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Latest git not working for MPC8349EMDS

[David Hawkins]

Hi Michael,

> I am upgrading from 1.1.3, that shipped on the board.

Ok.

p14 of the notes comments that same version is shipped
on the MPC8349E boards.

> I am pretty confused by your notes as they relate to my image.
> For me, I am flashing at fff00000.  This is sufficient to brick
> the board :-D. It seemed like your notes were reflecting a change
> in the boot address between versions? 

see p8 comments:

   Table 1 and Figure 3 show the default Flash memory map (as shipped on
   the board), showing the location of the Linux Kernel, JFFS2/RAM disk
   filesystem, and U-Boot images [9]. This Flash memory map is used by
   the U-Boot 1.1.3 code (processor reset vector at 0xFFF00100), and the
   U-Boot 1.1.4 code, but is changed in the latest U-Boot code
   (processor reset vector at 0x00000100). Processor reset configuration
   is discussed in Section 6.

So on reset the processor reads in the HRCW and in U-Boot 1.1.3
boots from FFF00100, which happens to map to the end of Flash
(during boot). Whereas in the latest source, the Flash gets
mapped to 0 on boot and the processor executes code from 00000100.
However, once the processor is booted, the flash is mapped to
FE000000.

Confusing eh!?

> I tried to use the addresses you mention and 1) fe000000 tells me
> it is not erased, even after I erase it (?) and 2) fe700000 seems
> to have no effect.

Look at the p14, and follow along with that example, see if you
can see the right bytes in memory.

As for programming flash, look at the sequence of commands on p17.

 > I thought those were the u-boot locations for the mpc8349ITX (?).

Same processor, so same boot sequence :)

> Just to be clear, I am not even at the point of booting the kernel, just
> trying to get to the u-boot prompt of a new u-boot.

Yep. Understood.

> I really appreciate the help!  Unfortunately, I am just more confused at
> the moment.

Take the time to read the document I sent. Read the MPC8349 manual
with regards to resetting the processor. Eventually it'll make
sense. I found it confusing to start with. Hopefully this will
help you.

Cheers,
Dave

[U-Boot-Users] Latest git not working for MPC8349EMDS

[Benedict, Michael]

David Hawkins wrote:
> Confusing eh!?

Very!  Thank you for explaining it.

> Look at the p14, and follow along with that example, see if you
> can see the right bytes in memory.

Almost, but not quite.  For one, the flash was locked, and that was why
the flash erase/copy would not take before.  Secondly, the eleventh byte
is different, which I think just means I have a different rev than
yours, 0x43 vs. 0x7f (and I can verify that it is a read-only register):

=> md.b f8000000 20
f8000000: 2f 0c 40 08 86 af 07 33 ff ff 43 12 ff ff ff 02
/. at ....3..C.....
f8000010: 22 07 05 19 24 ff ff ff ff ff ff ff ff ff ff ff
"...$...........

> Take the time to read the document I sent. Read the MPC8349 manual
> with regards to resetting the processor. Eventually it'll make
> sense. I found it confusing to start with. Hopefully this will
> help you.
> 

Big help already, I was able to flash the new u-boot to fe000000, when I
could not before.  Unfortunately, I am still booting to the old u-boot
at fff00000(?)  I apologize if I am being dense, but I thought your
document indicates flashing fe000000 with a u-boot.bin would be all that
is required to boot from low memory.  See below:

=> md fe000000
fe000000: 04040404 04040404 04040404 04040404    ................
fe000010: 00000000 00000000 00000000 00000000    ................
fe000020: b0b0b0b0 b0b0b0b0 60606060 60606060    ........````````
fe000030: a0a0a0a0 a0a0a0a0 00000000 00000000    ................
fe000040: 27051956 552d426f 6f742031 2e322e30    '..VU-Boot 1.2.0
fe000050: 2d673134 64613566 37362028 4d617920    -g14da5f76 (May
fe000060: 20312032 30303720 2d203134 3a33333a     1 2007 - 14:33:
fe000070: 33342920 4d504338 33585800 00000000    34) MPC83XX.....
=> reset
Resetting the board.


U-Boot 1.1.3 (Dec 21 2006 - 11:05:55) MPC83XX

Clock configuration:
  Coherent System Bus:  264 MHz
  Core:                 528 MHz
  Local Bus Controller: 528 MHz
  Local Bus:            132 MHz
  DDR:                  264 MHz
  SEC:                   88 MHz
  I2C1:                 264 MHz
  I2C2:                 264 MHz
  TSEC1:                264 MHz
  TSEC2:                264 MHz
  USB MPH:               88 MHz
  USB DR:                88 MHz
CPU: MPC8349E, Rev: 31 at 528 MHz
Board: Freescale MPC8349MDS
I2C:   ready
DRAM:
   DDR DIMM: data bus width is 64 bit with ECC
   DDRC ECC mode: ON
   SDRAM on Local Bus is NOT available!
   DDR RAM: 256 MB
FLASH: 32 MB
In:    serial
Out:   serial
Err:   serial
Net:   Freescale TSEC0: PHY is Marvell 88E1111 (1410cc2)
Freescale TSEC1: PHY is Marvell 88E1111 (1410cc2)
Freescale TSEC0, Freescale TSEC1
Hit any key to stop autoboot:  0
=>


Thank you again for all your help!
	Michael

[U-Boot-Users] Latest git not working for MPC8349EMDS

[David Hawkins]

Hi Michael,

>> Confusing eh!?
> 
> Very!  Thank you for explaining it.

No problem!

>> Look at the p14, and follow along with that example, see if you
>> can see the right bytes in memory.
> 
> Almost, but not quite.  For one, the flash was locked, and that was why
> the flash erase/copy would not take before.  Secondly, the eleventh byte
> is different, which I think just means I have a different rev than
> yours, 0x43 vs. 0x7f (and I can verify that it is a read-only register):
> 
> => md.b f8000000 20
> f8000000: 2f 0c 40 08 86 af 07 33 ff ff 43 12 ff ff ff 02
> /. at ....3..C.....
> f8000010: 22 07 05 19 24 ff ff ff ff ff ff ff ff ff ff ff
> "...$...........

I don't have the PDF around just at the moment, but I
suspect that you are right.

>> Take the time to read the document I sent. Read the MPC8349 manual
>> with regards to resetting the processor. Eventually it'll make
>> sense. I found it confusing to start with. Hopefully this will
>> help you.
>>
> Big help already, I was able to flash the new u-boot to fe000000, when I
> could not before.  Unfortunately, I am still booting to the old u-boot
> at fff00000(?)  I apologize if I am being dense, but I thought your
> document indicates flashing fe000000 with a u-boot.bin would be all that
> is required to boot from low memory.

For the board to low-memory boot, the HRCW has to indicate low-boot.
I'm pretty sure all I did was write the new HRCW to the first
sector of Flash (or maybe it comes with the U-Boot image, I can't
recall). I think there may also be a jumper setting you need to
change to tell the hardware to read the HRCW from flash rather
than the headers.

A little more reading should get you booted. But if you can't figure
it out, let me know and I'll take a look later on.

Dave

[U-Boot-Users] Latest git not working for MPC8349EMDS

[Timur Tabi]

David Hawkins wrote:

> For the board to low-memory boot, the HRCW has to indicate low-boot.
> I'm pretty sure all I did was write the new HRCW to the first
> sector of Flash (or maybe it comes with the U-Boot image, I can't
> recall). 

It does.  The first 64 bytes of u-boot.bin are the HRCW.  If you flash u-boot.bin to 
FEF00000, those 64 bytes are ignored however.

I personally recommend that you put U-Boot at FE000000 instead of FEF00000 which the BSP 
does.  That way, the HRCW and U-Boot are on the same flash bank.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Latest git not working for MPC8349EMDS

[Timur Tabi]

Benedict, Michael wrote:
> David Hawkins wrote:
>> Confusing eh!?
> 
> Very!  Thank you for explaining it.
> 
>> Look at the p14, and follow along with that example, see if you
>> can see the right bytes in memory.
> 
> Almost, but not quite.  For one, the flash was locked, and that was why
> the flash erase/copy would not take before.  Secondly, the eleventh byte
> is different, which I think just means I have a different rev than
> yours, 0x43 vs. 0x7f (and I can verify that it is a read-only register):
> 
> => md.b f8000000 20
> f8000000: 2f 0c 40 08 86 af 07 33 ff ff 43 12 ff ff ff 02
> /. at ....3..C.....
> f8000010: 22 07 05 19 24 ff ff ff ff ff ff ff ff ff ff ff
> "...$...........
> 
>> Take the time to read the document I sent. Read the MPC8349 manual
>> with regards to resetting the processor. Eventually it'll make
>> sense. I found it confusing to start with. Hopefully this will
>> help you.
>>
> 
> Big help already, I was able to flash the new u-boot to fe000000, when I
> could not before.  Unfortunately, I am still booting to the old u-boot
> at fff00000(?)  I apologize if I am being dense, but I thought your
> document indicates flashing fe000000 with a u-boot.bin would be all that
> is required to boot from low memory.  See below:

Not quite.  The HRCW at fe000000 must indicate that you want to boot from fe000000 
(actually, fe000100).  To do that, configure U-Boot with "make MPC8349ITX_LOWBOOT_config" 
and flash that u-boot.bin at fe000000.

> => md fe000000
> fe000000: 04040404 04040404 04040404 04040404    ................
> fe000010: 00000000 00000000 00000000 00000000    ................
> fe000020: b0b0b0b0 b0b0b0b0 60606060 60606060    ........````````
> fe000030: a0a0a0a0 a0a0a0a0 00000000 00000000    ................

Your HRCW is 04040000 b060a000, which means lowboot.  You must have something overriding 
your HRCW.  How is J22 jumpered?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Latest git not working for MPC8349EMDS

[David Hawkins]

> Not quite.  The HRCW at fe000000 must indicate that you want to boot 
> from fe000000 (actually, fe000100).  To do that, configure U-Boot with 
> "make MPC8349ITX_LOWBOOT_config" and flash that u-boot.bin at fe000000.
> 
>> => md fe000000
>> fe000000: 04040404 04040404 04040404 04040404    ................
>> fe000010: 00000000 00000000 00000000 00000000    ................
>> fe000020: b0b0b0b0 b0b0b0b0 60606060 60606060    ........````````
>> fe000030: a0a0a0a0 a0a0a0a0 00000000 00000000    ................
> 
> Your HRCW is 04040000 b060a000, which means lowboot.  You must have 
> something overriding your HRCW.  How is J22 jumpered?
> 

Thanks Timur,

So yeah, as I didn't recall, for low-boot, the HRCW is part of the
U-Boot image. So I think you need to check your jumpers.

Timur mentioned; make MPC8349ITX_LOWBOOT_config

But I'm not sure that would be correct for an MPC8349EMDS board.
So his comment in J22 may refer to the ITX board, not the MDS.
Check the MDS manual, and you'll figure it out.

Dave

[U-Boot-Users] Latest git not working for MPC8349EMDS

[Timur Tabi]

David Hawkins wrote:

> But I'm not sure that would be correct for an MPC8349EMDS board.
> So his comment in J22 may refer to the ITX board, not the MDS.
> Check the MDS manual, and you'll figure it out.

Oh sorry.  I don't know why I was thinking you had an ITX.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Latest git not working for MPC8349EMDS

[Benedict, Michael]

u-boot-users-bounces at lists.sourceforge.net wrote:
> Oh sorry.  I don't know why I was thinking you had an ITX.

Because I confused everybody by posting about an ITX for about a month
or so and then switching to an MDS ;).

Thank all for your help with both platforms.  I found the value to boot!

=>  md.b f8000000 20
f8000000: 2f 0c 40 08 82 af 07 33 ff ff 43 12 ff ff ff 02
/. at ....3..C.....
f8000010: 22 07 05 19 24 ff ff ff ff ff ff ff ff ff ff ff
"...$...........

The BMS was high before, so BCSR4 was 86, but for low boot it needs to
be 82.

Oddly, changing the SW4.5 did not seem to change this(?)  I was able to
write it from u-boot

=> mw.b f8000004 82

And that did the trick!

Thank you all.  Any ideas why the switch is not working?  Currently I
have to turn the board on, issue the above instruction to set low boot
mode, then reset.  I should be able to power off/on and boot into low
memory.  Any guesses what I am missing?
	Thank you,	
		Michael

[U-Boot-Users] Latest git not working for MPC8349EMDS

[David Hawkins]

> Thank all for your help with both platforms.  I found the value to boot!

Great!

> =>  md.b f8000000 20
> f8000000: 2f 0c 40 08 82 af 07 33 ff ff 43 12 ff ff ff 02
> /. at ....3..C.....
> f8000010: 22 07 05 19 24 ff ff ff ff ff ff ff ff ff ff ff
> "...$...........
> 
> The BMS was high before, so BCSR4 was 86, but for low boot it needs to
> be 82.
> 
> Oddly, changing the SW4.5 did not seem to change this(?)  I was able to
> write it from u-boot
> 
> => mw.b f8000004 82
> 
> And that did the trick!
> 
> Thank you all.  Any ideas why the switch is not working?  Currently I
> have to turn the board on, issue the above instruction to set low boot
> mode, then reset.  I should be able to power off/on and boot into low
> memory.  Any guesses what I am missing?

Sorry, no idea. Perhaps its a change between the E and the EA board.

Let us know if you figure it out :)

Dave

[U-Boot-Users] Latest git not working for MPC8349EMDS

[Timur Tabi]

Benedict, Michael wrote:

> Thank you all.  Any ideas why the switch is not working? 

I don't think they work on the ITX either.  Some of them depend on I2C, which doesn't make 
sense because I2C isn't initialized at power-on.

> Currently I
> have to turn the board on, issue the above instruction to set low boot
> mode, then reset.  I should be able to power off/on and boot into low
> memory.  Any guesses what I am missing?

Well, the board should be reading the HRCW from FE000000, and that value should contain 
the right boot location.  If that HRCW isn't being used, then something on your board is 
configured to ignore it.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

[U-Boot-Users] Latest git not working for MPC8349EMDS

[Benedict, Michael]

Timur Tabi wrote:
> Benedict, Michael wrote:
>> Any ideas why the switch is not working?
> 
> I don't think they work on the ITX either.  Some of them
> depend on I2C, which doesn't make
> sense because I2C isn't initialized at power-on.

Okay, this all makes more sense now.  If I switch SW4:8 FCFG to '1',
then the config is read from the flash (so it must not depend on I2C).
The BMS was a red herring.  This means that the final RCW settings
should be:

=> md.b e2400000 20
e2400000: 2f 0c 40 08 86 af 07 33 ff ff 47 12 ff ff ff 02
/. at ....3..G.....
e2400010: 22 07 05 19 24 ff ff ff ff ff ff ff ff ff ff ff
"...$...........


(note at e2400000 now because I am running on new u-boot source).  

I was off-by-one... e240000 is BSCSR10 not BCSR11, so other people
should have the same value for this register.

Thanks again to everyone!
	Michael

[U-Boot-Users] Latest git not working for MPC8349EMDS

[David Hawkins]

Hi Michael,

> Okay, this all makes more sense now.

Then you owe me a beer ;)

Glad to hear it all worked out.
Dave