Re: [U-Boot] [PATCH] powerpc: do not fixup NULL ptrs

Andy,
Sure, but until freescale or someone else with eq. and motivation researches it, we are stuck. I am not sure anyone else has tried 83xx based boards yet. If someone has please report. Also include weather booted from NAND or NOR, CPU type(e300cX) and what reset vector is used.
I have a couple of Freescale reference boards here (8313ERDB and 8349-MITX-GP). I'm not a powerpc expert by any means but if there are some (simple) tests you would like me to run on them then I will see if I can find some time.
I can see this issues only on MPC837x, i.e. *not* on MPC834x.
Andy.
Regards, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Andre Schwarz andre.schwarz@matrix-vision.de wrote on 2010/11/04 13:14:37:
Andy,
Sure, but until freescale or someone else with eq. and motivation researches it, we are stuck. I am not sure anyone else has tried 83xx based boards yet. If someone has please report. Also include weather booted from NAND or NOR, CPU type(e300cX) and what reset vector is used.
I have a couple of Freescale reference boards here (8313ERDB and 8349-MITX-GP). I'm not a powerpc expert by any means but if there are some (simple) tests you would like me to run on them then I will see if I can find some time.
I can see this issues only on MPC837x, i.e. *not* on MPC834x.
-E_TOO_LITTLE_INFO

Andy,
Sure, but until freescale or someone else with eq. and motivation researches it, we are stuck. I am not sure anyone else has tried 83xx based boards yet. If someone has please report. Also include weather booted from NAND or NOR, CPU type(e300cX) and what reset vector is used.
I have a couple of Freescale reference boards here (8313ERDB and 8349-MITX-GP). I'm not a powerpc expert by any means but if there are some (simple) tests you would like me to run on them then I will see if I can find some time.
I can see this issues only on MPC837x, i.e. *not* on MPC834x.
-E_TOO_LITTLE_INFO
sorry.
I meant that e.g. mvblm7 board (=MPC8343) works like a charm from current mainline U-Boot.
My latest MPC8377 board does not even start without your suggested 4 nops. It does not start (i.e. serial line completely dead) with any USB functionality defined. I also have random hangs depending on activated code, e.g. CONFIG_CMD_something or SPI drivers etc.
To me it looks like an alignment problem *somewhere*.
As said before I'm still digging and try to get more useful information.
Do you think porting the board to an earlier (maybe 2009) version is worth a try ? I could start bisecting if we could get a stable version.
Regards, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Andre Schwarz andre.schwarz@matrix-vision.de wrote on 2010/11/04 13:28:27:
Andy,
Sure, but until freescale or someone else with eq. and motivation researches it, we are stuck. I am not sure anyone else has tried 83xx based boards yet. If someone has please report. Also include weather booted from NAND or NOR, CPU type(e300cX) and what reset vector is used.
I have a couple of Freescale reference boards here (8313ERDB and 8349-MITX-GP). I'm not a powerpc expert by any means but if there are some (simple) tests you would like me to run on them then I will see if I can find some time.
I can see this issues only on MPC837x, i.e. *not* on MPC834x.
-E_TOO_LITTLE_INFO
sorry.
I meant that e.g. mvblm7 board (=MPC8343) works like a charm from current mainline U-Boot.
still -E_TOO_LITTLE_INFO: "include weather booted from NAND or NOR, CPU type(e300cX) and what reset vector is used."
My latest MPC8377 board does not even start without your suggested 4 nops. It does not start (i.e. serial line completely dead) with any USB functionality defined.
Something else is broken here, no idea what.

Jocke,
[snip]
still -E_TOO_LITTLE_INFO:
sorry - thought it was clear already.
"include weather booted from NAND or NOR, CPU type(e300cX) and what reset vector is used."
CPU: e300c4, MPC8379, Rev: 2.1 at 600 MHz, CSB: 400 MHz
- Boot from NOR Flash - HRCW from I2C EEPROM - Reset Vector 0x100, i.e. low boot.
Initial RAM ...
#define CONFIG_SYS_INIT_RAM_LOCK 1 #define CONFIG_SYS_INIT_RAM_ADDR 0xE6000000 #define CONFIG_SYS_INIT_RAM_SIZE 0x1000 #define CONFIG_SYS_GBL_DATA_SIZE 0x100 #define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_SIZE - CONFIG_SYS_GBL_DATA_SIZE)
... mapped by BAT5
#define CONFIG_SYS_IBAT5L (CONFIG_SYS_INIT_RAM_ADDR | BATL_PP_10) #define CONFIG_SYS_IBAT5U (CONFIG_SYS_INIT_RAM_ADDR | BATU_BL_128K | BATU_VS | BATU_VP) #define CONFIG_SYS_DBAT5L CONFIG_SYS_IBAT5L #define CONFIG_SYS_DBAT5U CONFIG_SYS_IBAT5U
Of course ELDK-4.2 toolchain.
My latest MPC8377 board does not even start without your suggested 4 nops. It does not start (i.e. serial line completely dead) with any USB functionality defined.
Something else is broken here, no idea what.
If it's an alignment or linking problem it could have the same root cause. Just want to give as much information as I can.
Cheers, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Andre Schwarz andre.schwarz@matrix-vision.de wrote on 2010/11/04 14:32:15:
Jocke,
[snip]
still -E_TOO_LITTLE_INFO:
sorry - thought it was clear already.
"include weather booted from NAND or NOR, CPU type(e300cX) and what reset vector is used."
CPU: e300c4, MPC8379, Rev: 2.1 at 600 MHz, CSB: 400 MHz
- Boot from NOR Flash
- HRCW from I2C EEPROM
- Reset Vector 0x100, i.e. low boot.
OK, almost the same as me, but I got a: CPU: e300c2, MPC8321, Rev: 1.1 at 266.664 MHz, CSB: 133.332 MHz
However, I think I just found the problem. My tree is a bit messy now so no patch but it will be:
Stick an isync (or sync) in map_flash_by_law1 .... stw r4, LBLAWAR1(r3) /* LBLAWAR1 <= 8MB Flash Size */ isync //HERE !! HERE !! HERE blr
I am guessing it takes a while for the stw r4, LBLAWAR1(r3) to hit the HW so one must wait for it, not sure what is best though, sync or isync?
There is nothing wrong with my reset vector

Jocke,
CPU: e300c4, MPC8379, Rev: 2.1 at 600 MHz, CSB: 400 MHz
- Boot from NOR Flash
- HRCW from I2C EEPROM
- Reset Vector 0x100, i.e. low boot.
OK, almost the same as me, but I got a: CPU: e300c2, MPC8321, Rev: 1.1 at 266.664 MHz, CSB: 133.332 MHz
However, I think I just found the problem.
excellent !
My tree is a bit messy now so no patch but it will be:
Stick an isync (or sync) in map_flash_by_law1 .... stw r4, LBLAWAR1(r3) /* LBLAWAR1<= 8MB Flash Size */ isync //HERE !! HERE !! HERE blr
ok - works for me, i.e. no quad-nop needed anymore.
I am guessing it takes a while for the stw r4, LBLAWAR1(r3) to hit the HW so one must wait for it, not sure what is best though, sync or isync?
If it is a timing issue why should have the nops influenced this ? I still wonder if this is the real problem and whether we might need more (i)syncs elsewhere ...
There is nothing wrong with my reset vector
ok.
Cheers, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

Andre Schwarz andre.schwarz@matrix-vision.de wrote on 2010/11/04 15:49:06:
Jocke,
CPU: e300c4, MPC8379, Rev: 2.1 at 600 MHz, CSB: 400 MHz
- Boot from NOR Flash
- HRCW from I2C EEPROM
- Reset Vector 0x100, i.e. low boot.
OK, almost the same as me, but I got a: CPU: e300c2, MPC8321, Rev: 1.1 at 266.664 MHz, CSB: 133.332 MHz
However, I think I just found the problem.
excellent !
My tree is a bit messy now so no patch but it will be:
Stick an isync (or sync) in map_flash_by_law1 .... stw r4, LBLAWAR1(r3) /* LBLAWAR1<= 8MB Flash Size */ isync //HERE !! HERE !! HERE blr
ok - works for me, i.e. no quad-nop needed anymore.
Does both your boards work now?
I am guessing it takes a while for the stw r4, LBLAWAR1(r3) to hit the HW so one must wait for it, not sure what is best though, sync or isync?
If it is a timing issue why should have the nops influenced this ? I still wonder if this is the real problem and whether we might need more (i)syncs elsewhere ...
You can try replacing the isync with 4 nops. That works for me. moving the 4 nops after the blr doesn't work.
I think it worked earlier by chance but the removal of the flags changed timing, probably a cache line crossing at the wrong place.
Jocke

Jocke,
ok - works for me, i.e. no quad-nop needed anymore.
Does both your boards work now?
MPC8343 @ 400MHz never had any issues - it's still working with your patch applied.
MPC8377 works fine up to 533MHz ... 600MHz+ still hangs.
Looks like there are more sync missing.
I am guessing it takes a while for the stw r4, LBLAWAR1(r3) to hit the HW so one must wait for it, not sure what is best though, sync or isync?
If it is a timing issue why should have the nops influenced this ? I still wonder if this is the real problem and whether we might need more (i)syncs elsewhere ...
You can try replacing the isync with 4 nops. That works for me. moving the 4 nops after the blr doesn't work.
I think it worked earlier by chance but the removal of the flags changed timing, probably a cache line crossing at the wrong place.
"works by chance" is probably not what we want.
Anyway - good catch. Thanks again.
Cheers, André
MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner
participants (2)
-
Andre Schwarz
-
Joakim Tjernlund