Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?

2008-07-21 Thread Jerry Van Baren
David Hawkins wrote: Hi all, We recently debugged a problem where a Flash write on MPC8349E and MPC8349EA processor boards was accidentally occurring during board initialization. Under the right conditions, the write appears to put the flash into a command-mode, rather than read-data

Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?

2008-07-21 Thread Timur Tabi
Wolfgang Denk wrote: Which exact driver are you referring to? If any driver has such a bug, it should be fixed. drivers/i2c/fsl_i2c.c The function is i2c_init(). I recently posted a patch that added this line of code: i2c_bus_speed[0] = set_i2c_bus_speed(dev, gd-i2c1_clk, speed);

Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?

2008-07-21 Thread David Hawkins
Hi Wolfgang, We recently debugged a problem where a Flash write on MPC8349E and MPC8349EA processor boards was accidentally occurring during board initialization. A write to flash should not matter at all. Thats what I thought, until I saw the logic analyzer trace show otherwise ... This

Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?

2008-07-21 Thread David Hawkins
Hi Jerry, The fix will also not expose the accidental introduction of flash writes in the future, it'll just stop those writes from having any effect. IOW, it simply hides the bug. :-( Yeah, I didn't like that as a solution either. It would be nicer to generate an exception if a write

Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?

2008-07-21 Thread David Hawkins
Hi Timur, I'm working on a patch that blocks i2c_init() from writing to global variables before relocation has occurred. But if you're saying that this patch should not be necessary, then that would be better. The I2C patch is necessary. Whatever was written to i2c_bus_speed[0] was never

Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?

2008-07-21 Thread Jerry Van Baren
David Hawkins wrote: Hi Jerry, [snip] Most processors available today have debug registers. If the processor used on a given target has a debug register set and the registers can be set to trigger on a write to a range, that would give you an exception. You would not necessarily have to

Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?

2008-07-21 Thread Wolfgang Denk
In message [EMAIL PROTECTED] you wrote: Which exact driver are you referring to? If any driver has such a bug, it should be fixed. drivers/i2c/fsl_i2c.c The function is i2c_init(). I recently posted a patch that added this line of code: i2c_bus_speed[0] =

Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?

2008-07-21 Thread Timur Tabi
David Hawkins wrote: Whatever was written to i2c_bus_speed[0] was never actually written, since the write occurs to flash before relocation, so whatever the intent of the write was, needs to be fixed. Prior to relocation, the value of i2c_bus_speed[] is irrelevant. All that matter is that

Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?

2008-07-21 Thread David Hawkins
Hi Jerry, One really good trick is how to hook a logic analyzer to those itty-bitty balls on the processor. Back when I was a boy, processors had 40 legs and no balls. :-D You must have a board with a logic analyzer connector. Thankfully the Freescale MDS boards do have logic analyzer

Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?

2008-07-20 Thread Wolfgang Denk
In message [EMAIL PROTECTED] you wrote: We recently debugged a problem where a Flash write on MPC8349E and MPC8349EA processor boards was accidentally occurring during board initialization. A write to flash should not matter at all. Under the right conditions, the write appears to put the

[U-Boot-Users] RFQ: disable flash writes until after relocation?

2008-07-19 Thread David Hawkins
Hi all, We recently debugged a problem where a Flash write on MPC8349E and MPC8349EA processor boards was accidentally occurring during board initialization. Under the right conditions, the write appears to put the flash into a command-mode, rather than read-data mode, and further reads from the