First of all, I still have my patches and am working (for reasons which are connected with the flat device tree & initrd) to make them patch cleanly against latest RC. If any want wants them for him self or any interested in making the effort to apply them... I will gladly send him/her everything i have.

Second: If you follow the mailing list you can see I have tried real hard to follow the general conformance and be a nice contributing dude. At the time my patches where applied cleanly against whatever git version i was told to... at some point i had enough of those games.

Third: This is no Ego games/wars and i certainly don't need my name carved in u-boot code for eternity (though i think it already is somewhere) . If anyone wants to have my patches I will gladly give them (just don't tell me you don't like the indention or whatever) right now i have a patch that will burn Altera Statrix II in Fast Passive Serial, Fast Passive Parallel and Fast Passive Parallel encrypted. Both parallel have been a bit neglected since in the end we chose to go with the Passive serial (which can do encrypted no extra charge) . But they are there.

Yours, Liberty

On Tue, Feb 26, 2008 at 9:23 AM, Jean-Christophe PLAGNIOL-VILLARD plagnioj@jcrosoft.com wrote:

On 08:19 Tue 26 Feb , Markus Brunner wrote:

...

Hi,

I've seen some patches for stratix II support on the Mailinglist, but none ended up in the git repository. e.g.: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/28559

Where are the problems and what has to be done to bring them into u-boot?

First, the patch is broken Second, there some coding style Third, the patch won't applied on the current tree

Feel free to send a rebase and fixed patch

Best Regards, J.

As part of my current ongoing effort to get up to date with rc2 I will produce a patch that will apply cleanly against that in a few a days. Hopefully it will be adopted in one go. If not I will grant others the honor to make it there.

And on another topic (since I am already here):

Flash memory size. On all the versions till now I have cheated U-boot to believe I have a 16M flash though the real flash was of sizes 32,64,128,256, and 512. This suited my goals very nicely because i could have a generic binary u-boot image for all my products. As cfi_flash.c grew up it started reading the eeprom embedded in the FLASH and learn for itself the real size of the FLASH, but till now I was able to restrict it to desired size from the config file, or cheat it by returning a constant in get_flash_size() function. Currently I am adopting RC2 and is having trouble making u-boot do What I want (and not the other way around). Trying to give a lower then expected MAX_SECT in the config file will both give an error (which is better then crash) and will config the wrong side of the flash (the first sectors). Cheating it by hard coded does not seem to work as well.

Any pointers on the subject will be appreciated.

And since this turned out to be a long one... I believe there is a bug in the fdt manipulation function when regarding the initrd and reserved maps. I do not fully understand this code so I suggest someone who knows his way around there will take a look. It seems that after manipulating the FDT by enlarging it by 64bit*2 and pushing the desired initrd content... the local ctx pointers are updated but no one update the original pointer in the FDT itself. dumping the tree right after that operation will reveal a broken tree. I have implemented an update fdt which takes the local pointer and write them back into the FDT and it seems to solve it, but my initrd is not working yet so i am not sure this is the right thing to do.

That's all.

Have fun, Liberty

On Fri, Feb 29, 2008 at 7:45 PM, Detlev Zundel dzu@denx.de wrote:

Hi Eran and Markus,

...

I still have my patches and am working (for reasons which are connected with the flat device tree & initrd) to make them patch cleanly against latest RC. If any want wants them for him self or any interested in making the effort to apply them... I will gladly send him/her everything i have.

Good, thanks.

...

Second: If you follow the mailing list you can see I have tried real hard to follow the general conformance and be a nice contributing dude. At the time my patches where applied cleanly against whatever git version i was told to... at some point i had enough of those games.

Do you really think that rules that *everyone* contributing to a project has to follow to achieve goals like maintainability, readability and changeability is "playing games"?

I admit that the rules are checked pretty strictly in U-Boot, but the rules as such are in my opinion pretty comparable to other projects....

...

Third: This is no Ego games/wars and i certainly don't need my name carved in u-boot code for eternity (though i think it already is somewhere) . If anyone wants to have my patches I will gladly give them (just don't tell me you don't like the indention or whatever)

I would really like to see Eran to get the patches into acceptable state (should be not much work from what I can tell), but if this does not happen, Markus can you pick up the patches and massage them into acceptance? In this way you'd get what you want and contribute to U-Boot? This would be very much appreciated...

Cheers Detlev

-- The mathematician's patterns, like the painter's or the poet's, must be beautiful; the ideas, like the colours or the words, must fit together in a harmonious way. Beauty is the first test: there is no permanent place in the world for ugly mathematics. -- G. H. Hardy -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu@denx.de

On Fri, Feb 29, 2008 at 11:18 PM, Wolfgang Denk wd@denx.de wrote:

In message ffc2b1d40802291156o65bd167el8586288c5c07df3b@mail.gmail.com you wrote:

...

As part of my current ongoing effort to get up to date with rc2 I will produce a patch that will apply cleanly against that in a few a days.

In a few days we will have at least -rc3, if not 1.3.2.

...

Flash memory size. On all the versions till now I have cheated U-boot to believe I have a 16M flash though the real flash was of sizes 32,64,128,256, and 512. This suited my goals very nicely because i could have a generic binary u-boot image for all my products. As cfi_flash.c grew up it started

I cannot understand why this should be necessary. we've always been using the same U-Boot image no matter what the flash or RAM size was. Actually this is a major design philosophy of U-Boot *not* to hardcode memory sizes butto automatically deal with te sizes it actually finds on the board.

...

Currently I am adopting RC2 and is having trouble making u-boot do What I want (and not the other way around).

I think what you're trying to do is fundamentally broken. Why don't you use the real sizes present on the hardware? Why do you want to lie to yourself and to your users?

I have more then one way to answer this question some are more philosophical then others, But I will choose the bare hardware approach... we "hide" some backup information on the flash. We make sure the user can not access this hiden info by physically lifting the flash legs (there is a programmable part between the flash and the cpu on the bus). So though there may be a 64Mb flash the user really have a 32Mb. It is, in fact, the flash eeprom which lies to the u-boot / linux. Any attempt to access these non existing address will lead to bus fault exactly as if the flash was a 32Mb (which in many sense it is). So, again, it is important for me to tell u-boot "go ahaed and use CFI, but dont listen to the eeporm cuz he doesn't know what he is talking about".

Liberty

Best regards,

Wolfgang Denk

-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de ...though his invention worked superbly -- his theory was a crock of sewage from beginning to end. - Vernor Vinge, "The Peace War"

Brent Cook wrote:

On Friday 29 February 2008 15:36:59 eran liberty wrote:

...

Any attempt to access these non existing address will lead to bus fault exactly as if the flash was a 32Mb (which in many sense it is). So, again, it is important for me to tell u-boot "go ahaed and use CFI, but dont listen to the eeporm cuz he doesn't know what he is talking about".

Have you tried reprogramming the flash eeprom to say something else? I know I've accidentally reprogrammed DRAM SPD eeproms with different/incorrect data.

I am quite sure you can't write to the CFI data structures in flash.

cu Michael

Both of you (Wolfgang and Brent) Provided me with some new angle to think of...

I believe I will prefare crippling the CFI over Crippling the flash eeprom as I believe it will be easier on our production team... But I will have to play with it some more...

In the past I had my own flag I called CONFIG_FORCE_FLASH SIZE. Suppose I will come with a way to cripple the CFI to work as it should in the latest version, would you like such a feature integrated in the u-boot for all?

Liberty

On Sat, Mar 1, 2008 at 1:55 AM, Wolfgang Denk wd@denx.de wrote:

In message ffc2b1d40802291336s78a050b7i780fe48b9f2671ce@mail.gmail.com you wrote:

...

...

I think what you're trying to do is fundamentally broken. Why don't you use the real sizes present on the hardware? Why do you want to lie to yourself and to your users?

I have more then one way to answer this question some are more philosophical then others, But I will choose the bare hardware approach... we "hide" some backup information on the flash. We make sure the user can not access this hiden info by physically lifting the flash legs (there is a programmable part between the flash and the cpu on the bus). So though there may be a 64Mb flash the user really have a 32Mb. It is, in fact, the flash eeprom which lies to the u-boot / linux.

I see.

...

Any attempt to access these non existing address will lead to bus fault exactly as if the flash was a 32Mb (which in many sense it is). So, again, it is important for me to tell u-boot "go ahaed and use CFI, but dont listen to the eeporm cuz he doesn't know what he is talking about".

I understand what you are trying to do, but I think your conclusion is wrong. The CFI driver was implemented to read the geometry and size information from the flash chips; if the chips cannot provide the correct information (as in your case), they are simply not CFI conformant, and you cannot use the CFI driver.

It may be possible to modify (or cripple) the CFI driver to ignore the information provided by the flash chips, or to overwrite parts of this information (you would have to overwrite at least size and number of sectors [and eventually the start address and first sector offset if you map the flash at a fixed end address]) - but I don't think that makes sense.

Best regards,

Wolfgang Denk

-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Writing a book is like washing an elephant: there's no good place to begin or end, and it's hard to keep track of what you've already covered.

Hi all,

I'm just reading through the MPC8349EA-MDS-PB board start-up code to understand it, eg. the initial SRAM in data-cache trick.

In the BAT setups in include/configs/MPC8349EMDS.h, some of the CFG_IBAT settings include the bit setting BATL_MEMCOHERENCE, indicating that those BAT entries are setting the M bit in the WIMG field, where M = memory coherence.

I'm trying to understand why that bit is set. Here's what the documents I've looked at say:

According to the Programming Environments Manual, and Freescale AN1809 (minimal boot sequence app note), if the M bit is set, accesses cause the processor to 'indicate' the access via a hardware signal. No doubt this indication is so that another processor can maintain coherence.

The e300 core reference manual indicates that in real addressing mode, WIMG defaults to 0011b (p4-6), and the on p4-7 it says

'When the M attribute is set, and the access is performed, the global signal is asserted to indicate that the access is global.'

Then on p8-2 it shows that there is an e300 core gbl# signal that reflects the state of the M bit. Ok, so I can see what the hardware signal is that asserts based on the M setting.

But in an MPC8349E/EA is there anything monitoring the gbl# signal?

Chapter 7 of the MPC8349EA reference manual has an overview of the core, but it doesn't comment on the gbl# signal. There is a comment on p7-27 that

'the instruction cache is not snooped, and cache coherency must be maintained by software'

which I would interpret as meaning there ain't nobody listening on gbl# for instruction accesses. Then for the data caching, there is the comment on p7-29 that

'cache coherency is enforced by on-chip bus snooping logic'

But coherency with what? What other masters are there that the core has to be coherent with?

I can see that the coherent system bus (CSB) is a multi-master bus, and that the core is just another master on that bus. But I don't think any of these devices have a cache that they need to invalidate in response to the processor asserting its gbl# signal (p6-11 just shows request/grant, repeat, and priority signals to the arbiter).

So does anyone have an idea why the M bit would need to be set for the MPC8349EA BAT entries?

FYI: - The M-bit is set for the BAT entries for: DDR, PCI memory, SDRAM, stack-in-dcache, and Flash) - The M-bit is not set for: PCI I/O, IMMRs, and BCSRs these are cache inhibited and guarded.

Cheers, Dave

PS. This is the first time I've looked at the startup code of a processor with an MMU, or BATs, so if I've missed the obvious ... be kind :)

This is starting to be me talking about my implementation, and though I love being in the spotlight, I think its best for the rest of u-boot mailing list that I will answer more question off line.

After I have solved it one way or the other I will simply present my solution and will let you decide if you wish to adopt it or not.

On Sat, Mar 1, 2008 at 11:51 PM, David Hawkins dwh@ovro.caltech.edu wrote:

1. Does it really matter if the user can read the data?

Yes! this is our last line of defence, Super idiot proof, reserved only for our technician coming to the site to save the day. If the user can write to it, its no longer Super idiot proof

2. Is there any way to have your FPGA do this hiding for you?

This is a valid solution, but for this FPGA needs bus logic, timing, address parsing, etc. Till today we preferred a simple bus shortcut.

3. Even if you lift the pins on the Flash, what is to stop the user doing a full chip erase, and deleting your unseen settings?

FPGA logic is encrypted! if user can read / create or write the FPGA. Then flash is the least of my problems. (while IP will certainly be higher and my job position even more :) )

Liberty.