[U-Boot-Users] Latest git not working for MPC8349EMDS
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
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
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
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.
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
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 /.@....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
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 /.@....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
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.
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 /.@....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?
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
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.
u-boot-users-bounces@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 /.@....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
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 /.@....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
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 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 /.@....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
participants (3)
-
Benedict, Michael -
David Hawkins -
Timur Tabi