Re: [U-Boot-Users] Increasing U-Boot partition size
Arrr, my insanity. Wolfgang is correct, of course. Gee, and I was just going to ask why on earth you liked high-boot :) I've seen one novel use of high-boot that could make it useful if you're lazy and can't be bothered plugging in your debugger ;) Assuming your board has a toggle switch that sets the state of BMS in the RCW (as most Freescale boards do), you can put a 'good' version of U-Boot at say the high-boot location, and the test version at the low-boot. If the low-boot version doesn't boot, power-down, flip the BMS toggle switch, power-up and boot-high, reflash to the next low-boot test version, and continue. I personally haven't tried the trick, but it sounded like a nice idea. Low-boot is the only sane method for booting, since high-boot sticks the bootloader 8MB into your 32MB/64MB/etc Flash ... I mean who uses 8MB Flash these days ... :) Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Power.org open-firmware/device trees ePAPR reference
Hi, I just received an email from Power.org referencing this document: http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf The ePAPR is loosely related to the IEEE 1275 Open Firmware standard—IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices. It looks to have a nice description of device trees. I see lots of familiar U-Boot developer names in the acknowledgments, so I imagine U-Boot is probably compliant with this specification already. Looks like a useful document to reference somewhere on the Denx documentation area. Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Power.org open-firmware/device trees ePAPR reference
Hi Wolfgang, It's already there - see http://www.denx.de/wiki/view/DULG/MoreInformationFurtherReading#Section_12.2.4. Indeed it is :) Thanks, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Freescale MPC8349EMDS BCSR corruption
Hi Dave, I believe it is timing issue. The BCSR read(#LOE) has not enough setup time. You may try the two solutions: (a) slow down local bus clock If you are using default configuration, the local bus clock is 66MHz. change the LCRR from div 4 to div 8 to make the local bus clock as 33MHz. you can find it in the MPC8349EMDS.h (b) Tuning the #CS1 timing, such as change the OR1 from 0xE8F0 to 0xE9F7 Let us know the result. Sorry for not getting back to you sooner, I've been out of touch for the last week. Freescale support responded that they were able to reproduce the issue on their hardware. In case you are interested; the support person in question was Fedor, and the SR# is 1-458670791. (I don't expect you to work on this, I'm just providing the information in case you care to look at it). I haven't talked in detail with Ira regarding the additional tests he performed after I left last week, however, I believe he changed the clock rates as you mentioned and the error still occurred. Our work-around that just writes the correct reset value to BCSR[0] was sufficient to keep him working on productive code. Since you were not able to reproduce the problem on your hardware, I'm interested to learn how you determined that the LOE# signal does not have enough setup time. Did you look at the placed-and-routed BCSR project to determine actual timing? I have a copy of the Verilog code used in the BCSR, but not the Xilinx ISE project. I'll take a more detailed look at the code, but I won't be able to look at the timing, unless I ask SR for an ISE project. I'll let them get back to me with their solution before I go trying to get the project files. Hopefully the fix will be to update the BCSR, and I'll just have to build a Xilinx download cable, and use the free web version of ISE to update the CPLD. Thanks for helping look at this issue. Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Freescale MPC8349EMDS BCSR corruption
I have a copy of the Verilog code used in the BCSR I took a closer look at the Verilog code. Searching for the I/O port nBCSR_CS within the code shows that it is synchronized through a single register to the 33MHz clock (which comes from on-board oscillator, not the processor) to generate the signal nBCSRCSsyn. This code is incorrect, the signal nBCSR_CS is asynchronous relative to the 33MHz clock. As such, the signal should be registered through two registers to synchronize it to the 33MHz clock domain. This synchronization error would cause multiple transient issues. These issues will not show up in simulation, as the metastability of the register outputs is not simulated (by Modelsim anyway). These issues will also show up on the hardware, regardless of the PowerPC local clock setting, as the BCSR is accessed in PowerPC LBC GPCM mode, and the CPLD is using its own 33MHz clock to generate GPCM responses. Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] Freescale MPC8349EMDS BCSR corruption
Hi all, We're having a rough week with our Freescale MDS boards. I've just submitted a service request through Freescale's online system. However, I figured others (eg. Kim, and Timur) might be interested in the following problem: We have an MPC8349E-MDS-PB and an MPC8349EA-MDS-PB that we are using to develop PCI agent mode software. After debugging the I2C flash write issue, we found that the serial port would stop receiving shortly after boot (we could see the U-Boot boot messages). We traced the issue to the RS232 receiver enable bit in the BCSR register 0 being written to; disabling the serial port receiver tri-state outputs. The RS232 receiver enable bit is not being changed by a write to the BCSR, but by a write to the *flash*. Yikes!! We were adding print statements that showed the value of the BCSR code in U-Boot. We found the error occurred during the Flash CFI code. I don't think the problem is related to CFI code - thats just where the corruption is triggered. Starting with U-Boot head, we applied Timur's I2C patch, and then added the following code sequence to __flash_detect_cfi in U-boot: - write 0x2F (the reset value) to the BCSR[0] register at 0xE240 - read BCSR[0] (to confirm the write) - write 0xCC to Flash (0xFE00) - read BCSR[0] (to show the value changed) (If you would like to repeat this test, please ask and Ira can send a patch file). The board was operated in stand-alone host-mode on the bench. The following logic analyzer traces show: a) the case where this sequence did nothing, http://www.ovro.caltech.edu/~dwh/mpc8349e_bcsr_read_ok.pdf and (b) the case where the sequence changed the value read back from the BCSR base address to 0xCC. http://www.ovro.caltech.edu/~dwh/mpc8349e_bcsr_read_bad.pdf We were able to trigger the error on both the E and EA board, but it would not fail every single reset - it occurred about 1-in-3 tries - hence it seems like a timing issue. It could be that the BCSR CPLD code has a decoding bug, or a timing issue. Another possibility is that the CPLD code that monitors CS#[0] for RCW access on boot is screwy and is allowing a write to CS#[1] to occur. We have had several other weird issues with the ethernet interfaces failing too, and their enable registers are in BCSR[0], so this would explain that too. I figured that this may help others explain weird issues they may be seeing on their development boards. Cheers, Dave PS. The MDS board serial port is also driving the 3.3V processor with 5V logic levels (4V measured) which is bad-bad-bad, but thats not the cause of our current issue. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?
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 would protect against writes to the boot flash. This is not the way to go. Hushing up problems has never been a solution. Instead, let's find and fix the culprit. I figured I'd gauge if there was any interest in adding this feature before looking into it further. Frankly: I saee this as a non-issue. Let's rather fix the bug instead. Yep, fair enough. I figured that might be the consensus, hence I did not look into it too much. Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?
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 to flash occurs during the period before relocation, at least that way the introduction of an accidental flash write would be detected immediately. I could have a look at the 83xx MMU settings during that time and see if there was an alternative solution using that. Using the MMU that early is going to be some work and has risks of other mysterious lockups when done wrong. MMUs are different for different processors and, often, within different branches of the same family of processors. This will add to the complexity. MMU == complexity == risk. :-( Yep, I agree. The 440EP solution to generate an exception looked a bit nicer, but its not portable either. 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 handle the exception properly, simply enter a spin loop so that the processor stops in a known state with enough information to identify the root cause. Haven't seen that type of register on the MPC8349EA, it might exist, I just didn't look :) Pros: * Get an exception identifying a bad bug occurrence rather than silent pass (mostly) or failure (mysteriously). Cons: * More complexity == risk * Debug capabilities, like the MMU, are different for different processors and families. This could be complex and could turn into an ifdefhell. * It may be easier and better to use a debugger (e.g. BDI-3000) to control the hardware breakpoint registers. A debugger may get unhappy or may simply undo our doings if we directly control the hardware breakpoint registers. Yep, a repeatable bug can be traced using a debugger. The hard part is making the bug repeatable. It would be nice to have a technique to trap these pre-relocation bugs. They don't happen often, but they *do* happen and they are hard to find (until they bite you and then they are hard to identify). What are the capabilities of your debugger? Can you set a hardware breakpoint range on your flash and have it trigger on start up? If so, we should add it to our FAQ and add the technique to our toolbox. Its a BDI2000. I don't recall seeing a trap on range feature. This is a tricky one to put in the FAQ, as it really shouldn't happen :) We managed to get pretty far with the debugger; we eventually found the address at which things died, however, the debugger wasn't able to give us an explanation. It was the logic analyzer on the flash/local-bus that showed the reason. So perhaps thats something that can be added to the FAQ. Let me know if you want something coherent, and I can write a 'logic analyzer tricks and tips' section for the FAQ. Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?
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 actually written, since the write occurs to flash before relocation, so whatever the intent of the write was, needs to be fixed. Wolfgang did not like the idea of adding code to disable writes to flash at the processor-level before relocation. This has the unfortunate side-effect of masking errors such as the one your code added. Please don't feel bad about this discussion, bugs happen :) Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] RFQ: disable flash writes until after relocation?
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 headers on their boards. My custom boards have 5000+ BGA balls http://www.ovro.caltech.edu/~dwh/carma_board/ so I made sure to hang a few logic analyzer connectors on that too :) One interesting thing that came out of the board development is that the PowerPC processor was RoHS, while the FPGAs were not. The assembly company stripped the RoHS balls off the PowerPC, reballed them non-RoHS, and then assembled the boards. The boards were then X-rayed with what amounts to a CT scanner, and each ball shape was observed at the bottom, middle, and top to ensure that they all looked nice and pretty. Amazing stuff :) Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] fsl-i2c: fix writes to data segment before relocation
Hi Timur, - i2c_bus_speed[0] = set_i2c_bus_speed(dev, gd-i2c1_clk, speed); + temp = set_i2c_bus_speed(dev, gd-i2c1_clk, speed); + if (gd-flags GD_FLG_RELOC) + i2c_bus_speed[0] = temp; Does i2c_init() get called again after relocation? If the I2C code is only ever used during flash startup, then this is dead code. The I2C controller needs to get initialized to read the I2C SPD EEPROM, so that it can then setup DDR. I guess in some cases a board with fixed DDR would not need to initialize the I2C controller until after relocation. If you need I2C speed tracking code, why not just re-read the I2C controller registers, and determine the speed from there? That is independent of relocation. Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Freescale MPC8349EMDS hang on boot
Hi Timur, FE00_9B90 is in the drivers/i2c/fsl_i2c.c code, which explains why Ira would see the 'I2C: ' line before lockup. Someone reported this problem last week while I was on vacation. Did they post directly to you, or the list? I don't recall seeing anything ... but then again, we didn't know what we were looking for until yesterday. I'd be interested in seeing the post. Seems like the sourceforge pages are down at the moment though. The fix is to check if relocation has occurred, and only write the speed if it has. I guess I need to post a patch ASAP. Sounds good. Thanks! Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] RFQ: disable flash writes until after relocation?
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 flash return invalid data (as far as the processor is concerned). The write was coming from drivers code that we had not introduced, and depends on the address of the flash write which changes depending on the section sizes, so the cause of the bug was not initially obvious. The MPC8349 processor base register has the option; BRn[WP] = 1, that could be used to disable writes to the boot flash. This local bus controller register is likely the same on all 83xx series processors. To see if this type of feature was on any other PowerPC processors, I looked in the AMCC 440EP manual. The 440EP local bus peripheral bank configuration registers has a bank-usage bit that can be used to set the 440EP local bus read-only, EBC0_B0CR[BU] = 01b. Writes to boot Flash could be disabled early on in the boot sequence, and then enabled again after relocation. This would protect against writes to the boot flash. The downside of this change, would be that flash writes would not work if you stopped the processor between the time writes were disabled, and then enabled. So if you were debugging, stepped into code before relocation, and decided to stop the processor and erase the flash (using your favorite debugger), flash erase would fail. Hence, the consensus may be that we don't want this type of feature - it may generate too many messages; 'help I can't program Flash' However, the debugger initialization file could be written to enable the flash before attempting to erase or program it. 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. It would be nicer to generate an exception if a write to flash occurs during the period before relocation, at least that way the introduction of an accidental flash write would be detected immediately. I could have a look at the 83xx MMU settings during that time and see if there was an alternative solution using that. The 440EP manual indicates that a protect error would occur if a write is attempted to a read-only bank. I figured I'd gauge if there was any interest in adding this feature before looking into it further. Cheers, Dave - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Freescale MPC8349EMDS hang on boot
Hi guys, As noted in Ira's previous posts, he'd managed to get the MPC8349E and MPC8349EA boards to fail consistently. Starting with the U-Boot head, and applying Ira's minimal BCSR access plus linker 32-byte alignment patch, we used a BDI2000 to set break-points until we identified the flash address at which the board died. The BDI could break consistently at FE00_9B90, but stepping past that point would result in failure. FE00_9B90 is in the drivers/i2c/fsl_i2c.c code, which explains why Ira would see the 'I2C: ' line before lockup. I put a logic analyzer on the local bus and triggered at the access to FE00_9B90, and found something weird ... Right before the access to FE00_9B90 was a *write* to FE03_03C8. This location is in the .data section, but in *read-only* Flash. The data following that write is then *not* the same as the data shown in the ELF file (or binary file written to flash). My hypothesis is that this write-access to the flash triggers an undocumented Flash command code, that causes further reads from the Flash to return manufacturer data *not code*. Hence, following the write to Flash, the processor loads garbage instructions and goes off into nowhere land. Ira's alignment patch to the linker code causes the write-address to change, so I suspect that the address for the Flash write was critical in triggering the Flash code. The offending write shown in the logic analyzer trace was the value 0005_FE99 to address FE03_03C8, which results in 16-bits writes of 0005 then FE99 to address FE03_03C8 and FE03_03CA. On the MPC8349E board, which uses Micron Q-Flash, the Flash reads after this write return 0, while on the MPC8349EA board, which uses Spansion Flash, the reads return non-zero data, but still invalid data. We tried writing the offending command code to Flash and then reading from FE00_9B90 to see if we could reproduce what the logic analyzer shows. However, we could not reproduce the problem; the write waveforms would match, but the reads returned valid Flash data. So, its a pretty subtle Flash command code sequence! How's that for a 'trial by fire'?! The offending line that produces the write to Flash, involves the use of a static unsigned int i2c_bus_speed[2] on line 48 of drivers/i2c/fsl_i2c.c, which is written to in the function i2c_init(). This code is running from Flash still, so there should be no writes to .data section code. git log d8c82db4 shows Timur added this code. So, Timur, you owe Ira a beer for the stress this change caused :) We haven't looked into the intent of the I2C speed tracking variable, so can't provide a patch. However, I'm sure Timur will come up with a nice solution. Thanks for all the valuable feedback everyone supplied to Ira. Kudos to Ira for debugging this issue. Cheers, Dave Hawkins. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Using DDR1 in AMCC 460EX custom design
Hi Felix, I will soon have to port U-Boot to a custom board based on AMCC 460EX CPU. This board should be very close to Canyonlands evaluation board, but board designers decided to use DDR1 instead of DDR2 present on Canyonlands. Looking at U-Boot 1.3.3 code, I can see that DDR1 support for 460EX is available in cpu/ppc4xx/cp44x_spd_ddr2.c. My question is - was DDR1 support ever tested on 460EX. Another question is - are there DDR1 DIMMs that can be used on Canyonlands ? DDR1/DDR2 support is available on many processors, but the hardware layout is memory specific. I don't have a Canyonlands board, but if it was designed for DDR2, then it will be setup with a 1.8V DDR supply and 0.9V VTT supply, so you will *not* be able to use DDR1 DIMMs on that specific hardware implementation. A DDR1 board would be designed to use a 2.5V DDR supply, and 1.25V VTT termination voltage, along with lots of termination resistors. So if you have DDR1 on your board, you will need to work out the DDR1 settings. If the layout of your board is identical to the Canyonlands board, then likely you can copy all that boards general settings, and then apply the DDR1 specific settings. If you board layout is different, then you'll need to start from scratch - which isn't that hard. One thing that can really help in determining the DDR1 settings required, is a board-level post-layout simulation. Your hardware engineer should have performed a simulation during board layout to make sure the clock delays and voltage ringing on the transmission lines was all in spec. So there should be some useful information there for you. For example, I am using a Freescale MPC8349EA PowerQUICC II Pro. It has clock and data-strobe adjustment registers, which we use to align the clock and data correctly. We had to make sure there would be a valid setting that would work for us, based on the relative clock-and-data timing shown in the post-layout simulations. As far as customizing the DDR setup relative to a Freescale evaluation board, I pretty much copied the basic settings, and then adjusted the drive-strength and clock-alignment for my specific layout. You'll have to do something similar. Cheers, Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] 83xx SPD_EEPROM DDR2 Issues
Hi Russell, Reposting on previous issue that is becoming a lot more painful. Today, I went to my local PC store, and bought EVERY type of DDR2 SODIMM memory they had, Kingston, Crucial, PC4200, PC5300 four different kinds of memory, and NONE of them will boot with U-boot now. We apparently have hit a new version of RAM in production, that I imagine will affect EVERYONE using 83xx chips if they actually try and purchase any recent memory. Has anyone got patches out for updates SPD code? I will work on this today and until I get it fixed, since beta testing has come to a complete halt within our company due to this. Out of interest, have you determined what is incorrect in the SPD entries versus a working configuration for the board? Have you tried to get each DDR2 working independently of the SPD settings? For example, you could test each RAM module by plugging it into the MPC8349EA-MDS-PB, and powering it up in a PCI slot with CFG_RS[0:2] = 100h, and CFG_CLKIN = 0 for a 33MHz PCI bus, or CFG_RS[0:2] = 011h, and CFG_CLKIN = 0 for a 66MHz PCI bus (or CFG_CLKIN = 1 for 33MHz bus). See 4.3 in the EA reference manual. This will boot the board in agent mode with a hard-coded reset values for the RCWs. The DDR interface will be clocked at 133MHz, so 266MHz DDR. The core would run at 400MHz if it was enabled, but its not needed. From the x86 host, you can manually program the DDR registers and determine a configuration that works. The reason for booting the board in this way, is that during each test you need to disable the DDR controller, make changes to the settings, and then re-enable the controller. You can generate burst transactions to the DDR memory by DMAing data from the PCI host to the board, and back again. Even though the PCI clock is slower than the DDR, the I/O sequencer buffers the data, and generates burst transactions to the DDR. I used this to write a pattern to a page of memory on the host, DMA to our MPC8349EA board, DMA it back again, and check the pattern is valid. The adjust the clocks and retry. I'm pretty sure the only things that you'll want to adjust are the clock timings. There are two clock adjustment options in the DDR controller 1. CK/CK# to address/command timing DDR_SDRAM_CLK_CNTL[CLK_ADJUST] b clock launched aligned with address/command 0001b clock launched 1/8th clock after address/command 0010b clock launched 1/2th clock after address/command 0011b clock launched 3/8th clock after address/command 0100b clock launched 1/2th clock after address/command 0101b clock launched 5/8th clock after address/command 0110b clock launched 3/4th clock after address/command 0111b clock launched 7/8th clock after address/command 1000b clock launched 1 clock after address/command 1001b-b Reserved 2. write-data to DQS timing TIMING_CFG_2[WR_DATA_DELAY] 000b0 clock delay 001b 1/4 clock delay 010b 1/2 clock delay 011b 3/4 clock delay 100b1 clock delay 101b 5/4 clock delay 110b 3/2 clock delay 111b reserved Alternatively you can use the BDI2000 to initial the DDR registers, and DMA say from Flash to DDR to write patterns. Here's the configuration file I wrote for our EA board based on the settings from a running U-Boot (so the parameters were determined from working SPD decoded values): ftp://ftp.denx.de/pub/BDI2000/mpc8349ea_mds_pb.cfg You could see how different the SPD derived settings are relative to the settings in this configuration file. Hope that helps. Cheers, Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode
Hi Vivek, Sorry, I forgot to tell that we are using MPC8349E processor with a e300 core. And it is clearly mentioned in the e300 core datasheet that, it supports True little-endian mode for compatibility with other true little-endian devices. Data sheets need to be read in the wider context of knowing how the devices are 'typically used'. Just because a core can operate in little-endian, doesn't mean you should :) So, according to data sheet I have done following changes in U-Boot to configure it in true little endian mode The convention for this processor, and pretty much all other PowerPCs is to operate in big-endian mode. We want to configure MPC8349E in little endian as some other PCI devices(DSPs) are operating in little endian. Any help/suggestion will be appreciated. The PowerPC should be operated in big-endian mode, so that you have the wider support of the community. There is absolutely no reason to operate the processor in little-endian mode just because you want to talk to little-endian processors over the little-endian PCI bus. The overhead of any required byte-swapping functions is negligible. Regardless of what mode your PowerPC host operates versus your DSPs, you will have to use a communications protocol that enforces data alignment and format, eg. a C-structure on the DSP will more than likely not have the same layout as the same C-structure compiled on the PowerPC. There is the issue of endianness, but also the issue of alignment and packing. As such you would write an encode/serialization function to send data, and a decode/deserialization function to decode data. There are standardized machine independent binary formats already defined, eg. XDR as used by NFS, and CDR as used by CORBA. Application code written using this technique is transparent to the endianness of the underlying processor. I use little-endian x86 hosts to communicate with about 20 little-endian DSPs, or big-endian PowerPCs (MPC8349EAs). The devices communicate using CDR. I use the ACE C++ library and its CDR encode/decode functions on the x86 and PowerPCs, while on the DSPs, I use C-structures and pack/unpack them to match the equivalent CDR encoded functions. The overhead of data conversion is insignificant. I hope that given this insight you will understand why you are recommended to operate the processor in its 'standard' big-endian mode. Cheers, Dave - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode
Hi Vivek, Just to clarify these comments: It would be a lot easier if you modified the application to work on big-endian and little-endian. Just look through the code in places where the endian matters, and add cpu_to_be32() and be32_to_cpu() (or similar functions). When you are dealing with a driver, register accesses need to be in a specific format. The MPC8349EA has some of its registers in big-endian format, and others in little-endian format. Regardless of the mode you operate your processor, you will *have* to use the correct byte-swap functions. The only time this will be real problem is with DMA, since on 83xx you cannot modify the data during a DMA transfer. DMA would be used to move a block of data, not to manipulate a register. If encode/decode functions are used to move blocks of data, then the data is in byte-stream format, which does not change when the endian-order of the processor changes. Each byte occurs in the same order. You mention you are trying to re-use an existing code base. Keep in mind that just because the old code works, doesn't mean it is good code. If the code was not written to be endian-neutral, then it wasn't portable in the first place, so should be corrected. Cheers, Dave - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode
Hi Timur, When you are dealing with a driver, register accesses need to be in a specific format. The MPC8349EA has some of its registers in big-endian format, and others in little-endian format. Regardless of the mode you operate your processor, you will *have* to use the correct byte-swap functions. That's why we use cpu_to_be32() to write to big-endian registers. On a big-endian processor, this macro doesn't modify the parameter. So, *p = be32_to_cpu(12); will be compiled to *p = 12; On a little-endian process, the macro will do a byte-swap. This macro, and others like it, eliminates the need to have two different versions of the code. Sure. I wasn't pointing out the clarification to you, but to Vivek as it seemed like he had limited experience with endianness issues. DMA would be used to move a block of data, not to manipulate a register. I can see you've never written an audio driver before. The data itself has endianness, and the register may require the data to appear in one endian or another. If Note that I'm was not trying to be antagonistic here, so no offense was intended in any my response to your message. It seemed to me that Vivek was not very experienced with endianness issues so wanted to clarify your application examples - to Vivek. I haven't written an audio driver, so I'm interested in learning more. So are you saying you would DMA to a register with a specific endianness. The two situations I can think of with a DMA controller moving data that requires a specific endianness are; 1) DMA controller scatter-gather descriptor entries. These would normally consist of source, destination, length, and next pointers in a specific endianness format. 2) DMA from memory to a FIFO destination address that expects little-endian format 16-bit values. In either case, you would use the byte-conversion routines to serialize the descriptor entries in memory, or in the source buffer, into the correct endianness before performing enabling the DMA. So the discussion on serializing data into a source buffer applies to this case too. If Vivek's application correctly serializes any endian-specific data before using the MPC8349EA DMA controller, then he should have no issues. Does an audio driver differ in any respect to the above situations? Thanks for the feedback. Cheers, Dave - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode
Hi Timur, In either case, you would use the byte-conversion routines to serialize the descriptor entries in memory, or in the source buffer, into the correct endianness before performing enabling the DMA. Very true. However, this means that if the original data is in the wrong endian, you have to have a middle layer that modifies the data when copying from the source buffer to the DMA buffer. This adds overhead. This would be the key question for Vivek then. Does his highest volume data set have any endianness issues that need to be resolved? If Vivek's application correctly serializes any endian-specific data before using the MPC8349EA DMA controller, then he should have no issues. Yes, but it may take him weeks to find all the places in the where the endianness matters. Indeed. Conversely, it may take months to get a little-endian PowerPC port working! :) Cheers, Dave - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Configuring U-Boot for MPC8349E in little endian mode
Hi Vivek Now due to some reason we have to configure 8349E in little endian mode. Perhaps you could explain why you feel you need to use little-endian mode. Readers of the list could offer some constructive comments. Regards, Dave - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] pci memory booting on ppc460
Hi Stefan, There does not appear to be a 460EX User's Manual on the AMCC web site. Anyone know where to get it? I created an account just in case it was not visible to guests, but no change. It's still preliminary, so you probably need to contact your AMCC distributor/FAE to get access to it. It sounds like Ame has things under control, so I won't try getting the manual. Ame, good luck with your board bring-up. If your hardware guys are still working on the board, make sure they connect all the JTAG connections on those processors! Thanks, Dave - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] pci memory booting on ppc460
Hi Stefan, Here's a few ideas then. Sorry, all of the ideas were based on the MPC8349EA, which I am currently using. I did not look at the ppc460 documents, as I was just putting ideas 'out there'. When the MPC8349EA is booted, you can enable the peripherals while leaving the core in reset. The IMMRs are memory mapped to PCI via a 1MB BAR, and there are several other BARs setup to have 1MB windows. The IMMR registers can be accessed to setup the memory map of the target processor, and setup the inbound translation windows. I've been using this technique to check out all of my hardware, and DMA over PCI, DDR, and local buses. Given that you don't think any of my suggestions are possible, I'll have to go download the ppc460 reference manual and convince myself :) Ame, feel free to chime in if you think any of the ideas are possible. Cheers, Dave - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] pci memory booting on ppc460
Hi Ame, So maybe I need to clarify some more. The PPC460 data sheet is not too clear on this yet. However, here are my thoughts on this. Lets just take the simple case as an example. We have a plurality of 460s where a single one is the master. Between the master and all the slaves is a PCI bridge. The slaves are hardwired to boot from pci bus memory -- according to the datasheet that is at a fixed address. So there does not appear to be any need to do anything to the slave upon power up. Really? I didn't see a comment about the fixed address when I parsed the data sheet. Where is that comment in PP460EX_DS2063.pdf, rev 1.09 April 14, 2008? Now the master boots and then allocates a chunk of contiguous memory using a kernel driver or whatever is needed. The image is just whatever the flash image would normally contain (uboot + kernel + rootfs). Or you could just have a u-boot image, and then use u-boot to fetch the kernel and rootfs. The address of that chunk is then given to the pci bridge so that it can perform inbound translation from the address that the PPC slaves will use to the address where the image is physically located. Then the slaves are taken out of reset and begin reading flash across the pci bus which really goes through the bridge and is mapped to the DRAM on the master (or I guess it could be the flash on the master, but DRAM seemed easier since it is already running). Ok, so how many holes does this approach have? This seems reasonable to me. However, without the full users manual for the 460EX, and the users manual for the pci bridge, I can't really comment more. Cheers, Dave - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] pci memory booting on ppc460
Hi Ame, Yes, what is the main reason you want to do this? Ok, here is what I want to do. I have a board that has several PPC460s on it. Each has its own DDR2. One of them is the master and boots up normally today with uboot, launches linux, etc. What I want to do is have that master load the flash binary image into memory and then lock that memory down (via whatever kernel calls are required). Then I want to configure each slaves PCI bar registers to be able to read from this main memory and then tell them to go. So my thought was that it would appear to the slaves that they are just loading from a regular flash and this image would contain uboot, kernel, root filesystem. Basically everything a flash normally would have. It sounded reasonable at the time. The reason to avoid a flash on every one is so that we don't have to reflash that many CPUs every time and because it will take up more board space. Thanks Here's a few ideas then. 1) Use the main host to setup DDR on each of the targets, copy a U-Boot image to each target, and then enable the targets to boot from DDR. The target U-Boot versions would have to skip all DDR initialization, since they are running from DDR. I believe this code would come under ... http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM Which contains the warning: 'But it is difficult, unsupported, and fraught with peril.' Wolfgang and Stephan could probably comment more on this. 2) Configure an inbound translation window on the host to point a PCI window to its *flash*. Configure the outbound translation windows on the targets to point to the host inbound window. Each target would then boot from the same flash as the host. Assuming there was some I/O to distinguish the targets from the host, the code could determine what to do at runtime. This has the disadvantage that all boards are booting from potentially slower flash memory, but that may not matter. 3) Configure the host DDR memory such that the OS does not use all installed memory, eg. reserves enough memory for a U-Boot image. Setup the host inbound translation window to point to that linear DDR region, and have the host copy the image there. Setup the targets as in (2) and let them boot. The nice thing about (2) and (3) is that the target processors are effectively in the 'virgin' state that flash booting expects, so the modifications to U-Boot required to support the booting scheme would be minimal. 4) Another option would be to place SRAM on each of the other processors, and copy the U-Boot image there. That way flash on the targets is replaced with SRAM. However, this would require a hardware change, and is not much of an improvement. As for the root filesystem, there's more to think about there :) I will soon have a similar situation to yours. I'll have a master CPU (an x86 host CPU in a compact PCI crate), and 15 to 20 boards in peripheral slots (MPC8349EA processors). Each processor has a gigabit ethernet port, so during development, I'll just use an NFS mounted rootfs. However, once I deploy about 8 crates worth of this hardware, I don't want to have lots of Gbe cables and switches. At that point I plan to change to a scheme where I create a virtual network interface over PCI. If there is stuff that needs to be stored locally, then I'll setup a RAM disk and rsync the contents from an NFS mount at boot time. The only issue with this approach is whether a virtual network over PCI driver exists. The MPC8349EA development kit comes with a driver that sounds like it does some of this, so I'll start with that. The scheme I envisage is; the peripheral boards boot U-Boot, and that U-Boot port has a 'terminal over PCI' and 'ethernet over PCI' driver built in. Back on the host CPU, I can get to the terminals via /dev/ttyPCI# nodes, and get to each board via ethernet connections, where the slot numbers of the boards define unique MAC addresses. The U-Boots on each board can then tftp a kernel and boot. The kernel command line will use an NFS path that comes back through the x86 host CPU. None of this is implemented, but its only software ... right :) Cheers, Dave - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] pci memory booting on ppc460
Hi Ame, Hello, I saw a reference to PCI booting in the docs, but could not find enough detail. We would like to use PCI memory space booting on an upcoming design with the PPC460EX. Does Uboot currently support that mode of booting? Is it as easy as booting from a flash? We are developing our app with the canyonlands board, but we won't be able to try the PCI boot until we have our own board finished. U-Boot is a bootloader. What you are describing here circumvents needing a bootloader. I use an MPC8349EA Freescale processor, and it also has an option to boot over PCI. However, I plan to use U-Boot on Flash to boot the board. I'll tell you why ... for my hardware anyway, your reasons may end up being similar. If you want to boot your board over PCI, then the board will most likely be a peripheral board (a host would need to boot and setup bridges, so you would have a hard time booting a host through a bridge that is not configured). The host CPU would hold the image of the kernel that you were planning to boot onto the PCI peripheral board. However, your host would need to perform all of the tasks normally performed by the bootloader; setup the memory map, memory controllers, and peripherals that Linux expects to find configured. Then even trickier, is to setup the kernel boot command line arguments and device tree. My guess would be that you would have to hardwire that info into your kernel image, or add a small bootloader to the kernel image to setup the arguments to the kernel proper. There is also the issue that the host CPU is running an OS with its MMU enabled, so the kernel image that it can present to the board over the PCI bus is fragmented. The only way to make this image linear would be to preserve a chunk of memory on boot of the OS, and load the kernel image there for the PCI board to boot from. There's a lot of code in there that you would have to maintain on your lonesome. For the price of a flash device, I would recommend using U-Boot as the bootloader in Flash on your board. The PCI interface can be used to transfer a kernel image, and then that image can be booted by the bootloader. Note that this transfer can account for the fragmented image on the host by using scatter-gather DMA into the linear address space of the DDR memory on the board (since U-Boot is running with a flat memory map). Save yourself a lot of trouble, and no community support, by doing things the standard way (and a good sign is, that you're already asking questions). Note that if your processor has the option that when reset is deasserted, the core can remain in reset, make sure you implement that feature (on the MPC8349EA its controlled by the reset configuration words source pin strapping). This allows you to enable the chip, including the PCI interface, while the core is reset, and therefore does not try to boot. The MPC8349EA has default windows over PCI that then allow a host CPU to manipulate all the memory-mapped registers visible to the PowerPC core. I've been using this feature of the MPC8349EA processor to test my board over PCI from an x86 host. The DDR controller can be enabled/disabled, the clocks swept, and data patterns DMAed to/from PCI to confirm the memory controller configuration prior to attempting a U-Boot port. Hope this helps. Cheers, Dave - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] pci memory booting on ppc460
Hi Wolfgang, This is not necessarily true. There may be many reasons why you still want to run a boot loader (like U-Boot) on the PCI device's local processor. Fair enough. If you want to boot your board over PCI, then the board will most likely be a peripheral board (a host would need to boot and setup bridges, so you would have a hard time booting a host through a bridge that is not configured). The host CPU would hold the image of the kernel that you were planning to boot onto the PCI peripheral board. However, your host would need to perform all of the tasks normally performed by the bootloader; setup the memory map, memory controllers, and peripherals that Linux expects to find configured. Then even trickier, is to setup the kernel boot command line arguments and device tree. My guess would be that you would have to hardwire that info into your kernel image, or add a small bootloader to the kernel image to setup the arguments to the kernel proper. You see? There is plenty of good reasons to have a well-known, powerful boot loader available :-) Save yourself a lot of trouble, and no community support, Who says no community support? This is a perfectly legal way of using U-Boot, and we we can, we will help. The 'no community support' referred to maintaining out-of-tree host-side code that performed all the board-specific setup before loading the kernel, i.e., with no U-boot interaction at all. Sorry if that was misleading. Ok, so given this is a perfectly legal way of booting U-Boot, would you (Wolfgang) recommend it? Lets take the MPC8349EA as the example here. The processor reset configuration can be setup for PCI boot, however the processor will come out of reset with PCI outbound translation windows configured to fetch from PCI address 0 (I think). A boot-sequencer EEPROM on the PowerPC would not help (for setting up the outbound window), since it won't know the PCI address of the U-Boot image (lets assume its an x86 running Linux for example sake). So the x86 host would have to setup the PCI outbound translation window to point to the U-Boot image. But you have the issue, that the hosts MMU will be running, so the linear U-Boot image that the host loaded into memory, will in fact consist of 4K pages of physical addresses as viewed over the PCI bus, i.e., the U-Boot image will be fragmented. The PCI boot sequence from the perspective of the PowerPC expects a linear sequence of addresses, and for this particular example, that will not normally be the case. The host could arrange for a block of its DDR to be reserved (eg. using the mem= kernel argument on boot), and it could load the U-Boot image to that, and then point the PowerPC to boot from the PCI address that points to that window. So, its not impossible, but it does seem like more work than using Flash to boot the board. But of course there may be reasons to want to boot over PCI ... I guess once you do this, there isn't really much difference between the U-Boot image that would have been programmed to Flash versus the one fetched over PCI, since U-Boot can still perform its stack-in-cache trick, setup DDR etc. Interesting ... if there is work done on this, I can test any patches on the MPC8349EA. Cheers, Dave - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] [PATCH] Make MPC83xx one step closer to full relocation.
Hi Joakim, See for example cpu/mpc8xx/start.S - while at the moment we really start with .text, it would technically be more approrpriate to change the first 256 bytes (from monitor base to EXC_OFF_SYS_RESET) into .rodata or something like this. Ahh, now I see what you mean and it gave me an idea ... While you're chewing on ideas, here's a couple of points about mpc83xx/start.S The reset configuration words that start at the beginning of Flash are *optional*, and depend on the reset configurations words source pin strapping (CFG_RS[0:2]). If CFG_RS[0:2] = 000b, then the RCWs are read from the local bus chip-select 0. Nominally this means read from flash, but hardware can subvert the bus to the flash and supply the RCWs from an alternative source, eg. on the MPC8349EA-MDS-PB, the RCWs can be driven onto the local bus by an on-board CPLD (which in turn gets the RCWs from dip switches). On my custom MPC8349EA board, I can deliver the RCWs from the Flash, or if flash is blank, from the FPGA, or I can change the CFG_RS[0:2] source so that the processor uses hard-coded RCWs, or an I2C boot EEPROM. If the RCWs were placed in their own section, then that section could be made optional. In the case of it being used, and boot-low being used (RCWH[BMS] = 0), then the RCW+U-Boot magic+string section would need be 100h bytes in size, and be concatenated with the U-Boot image. Otherwise the RCW area could be left as a separate binary image, that the user has to burn to Flash. (Eg. for a user that for some bizarre reason wants to put RCWH[BMS] = 1 :) ). How about a 100-byte section called .rcw, or .rcwdata? I'm not sure if these comments will make life easier or worse ... Cheers, Dave - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] MPC83xx HRCW
Hi Andre, In cpu/mpc83xx/start.S there is a comment : /* * The Hard Reset Configuration Word (HRCW) table is in the first 64 * (0x40) bytes of flash. It has 8 bytes, but each byte is repeated 8 * times so the processor can fetch it out of flash whether the flash * is 8, 16, 32, or 64 bits wide (hardware trickery). */ This does _not_ hold true for all configurations. Flash is simply one of many options ... Maybe it's true for the Freescale boards. Other sources of the HRCW can be hard-coded strapping pins or an I2C EEPROM. Why is there a need to define the HRCW ? I think the main reasoning here is that the original board ports, eg. the Freescale development boards, used this method. For example, on the MPC8349E-MDS-PB and MPC8349EA-MDS-PB, the HRCW is defined in the port header file MPC8349EMDS.h, and the assembly code generated in the section in start.S is written to the Flash at the beginning of Flash - regardless of whether the processor will boot from high-memory (BMS = 1, old U-Boot code), or low-memory (BMS = 1, latest U-boot code). (The start code is in a different assembler section). But that being said, the MDS board doesn't have to use the Flash HRCW. If you change one of the toggle switches on the MDS board, the BCSR CPLD will drive the local bus read for the HRCW from a set of toggle switches, and basically over-ride the HRCW from Flash. Note that for the current U-Boot code, BMS = 0, so the reset vector occurs at 100h, and the HRCW is always read from 0h. Since both of these locations are withing the first sector of a typical Flash device, it would be 'difficult' to erase the Flash and write just the U-Boot start-up code without also writing the HRCW. Hence the reason for the code you see. In my design, I have an FPGA between the boot flash and the MPC8349EA processor. This allows my PORESET# code in the FPGA to read the flash, and if it is blank (reads 0x), it can place a hard-coded reset source, CFG_RS[0:2], onto the bus, otherwise if the Flash is not blank, CFG_RS[0:2] is driven with the HRCW from Flash. If I wanted to, I could have the HRCW in the FPGA too (I just love FPGAs :) ). Since the FPGA also reads the state of the cPCI M66EN signal (33MHz or 66MHz clock reference), it can drive CFG_CLKIN_DIV such that the processor always generates the same clock frequencies. I have also put an I2C EEPROM on the board, but haven't played with it yet. Let me know if you have any design questions, and I can share what I have worked on. Regards, Dave Here's the hardware design I'm working on: http://www.ovro.caltech.edu/~dwh/carma_board/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] MPC83xx HRCW
Hi André, I was just wondering why there's a need to define the HRCW inside a header. This _only_ makes sense for the HRCW from flash on local bus-section. Any hard coded reset word or the use of an I2C Prom does make this obsolete. Right. But there is also no harm in having it :) My fear was that the defined HRCW is actually used somewhere - which would be a bug. That is true. Code needing the values of the RCWs should be reading them from the IMMR registers 900h (RCWLR) and 904h (RCWHR). If you are concerned, you could have a look through the code to check that is true. I'm actually bringing up my latest design. It's a MPC8343B based board stereo-camera board with external Altera FPGA on PCI and a MiniPCI Slot for different expansion. Configuring the 512MByte Micron memory was a little bit time consuming ... but now everything works fine. Great! Since my board is a cPCI peripheral, I could cheat a little, and program all the DDR register over PCI from an x86 host. This allowed me to sweep the clocks (MCK and DQS), mess with ECC, etc, until I got things right. My HRCW resides in a write-protected EEPROM on I2C. It's very easy with pre-programmed EEPROMS during production ... no faults possible with erased/invalid flash memory. Hmm, good point ... perhaps I'll have to use that idea ... thanks :) Currently I'm bringing up the two Ethernet PHYs (Vitesse VSC8601) in RGMII mode. Communication is already established and both PHY report valid links ... but no data yet. Do you have experience with RGMII on MPC834x ? Any uncommon defines ? I've used a single PHY, but its the same as the Marvell PHYs on the MPC8349EA-MDS-PB. I've wired it up for GMII, but I'm pretty sure I can probably run it in DDRed RGMII mode too. I'm currently working on UPM programming (via PCI) and writing VHDL for the local bus UPM interface, so haven't checked out my PHY yet. If you need a second opinion on RGMII, I can try something out when I get to that point. Best of luck with the board bring-up, Cheers, Dave - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] DDR-II @ MPC8343A
Hi Andre, has anyone set up the DDR-II controller on a Freescale MPC8343A without ? As far as I can see there are only DDR-I boards from Freescale. Are there any patches not yet posted to handle this ? Chances are that the MPC8343 DDR controller is much the same as the MPC8349EA controller. Here's a couple of annotated BDI2000 configuration files for the MPC8349E-MDS-PB loaded with 2.5V DDR1, and the MPC8349EA-MDS-PB board loaded with 1.8V DDR2 ftp://www.denx.de/pub/BDI2000/mpc8349e_mds_pb.cfg ftp://www.denx.de/pub/BDI2000/mpc8349ea_mds_pb.cfg I'm not sure if it'll be of use, just wanted to mention it. The U-Boot code for the MPC8349 handles both board types transparently. I haven't delved into the code in too much detail, but I think the code is using the SPD EEPROM information to configure the controller appropriately for DDR1 or DDR2 operation. You can probably use that code as a reference to any changes required for your MPC8343 code. Regards, Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] [OT] Using MTD to manipulate CFI flash on PCI boards?
Hi, Sorry, for the slightly off-topic post, but I figured someone else might have faced a similar issue. I'm in the process of bringing up an MPC8349E PowerPC based board. The board is configured as a compact PCI peripheral board. The board will boot U-Boot off on-board Spansion S29GL-N Flash, and U-Boot will then boot Linux. The cPCI interface is used to communicate with an x86 host CPU board. The final system will have 15 boards per cPCI crate, and there will be 8 crates. I can use a BDI2000 to program the Flash on a board, but this doesn't scale so well when wanting to perform Flash updates on crates full of boards using the x86 host CPU. Basically I'll have a setup where an x86 host can see the Flash on the PowerPC boards via PCI memory regions. In the case of a new board with a blank flash, the PowerPC core will be held in reset, so without using JTAG/COP, only the x86 host CPU can program the flash. As far as flash manipulation from a PowerPC on a single board goes, I figured that once I have U-Boot and Linux working, I would just use the MTD subsystem. However, its less clear to me whether I can use MTD on the x86 Linux host CPU, to access the flash devices on multiple boards via the PCI bus. The documentation at: http://www.linux-mtd.infradead.org/ wasn't much help, so I'll go and look at the code. So while I go read some more, I figured I'd ask if anyone else has used the MTD system in a similar way for programming their flash. Recommendations anyone? Thanks! Regards, Dave. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] BDI .cfg for MPC8349E/EA-MDS-PB [1/2]
Hi all, I've written a couple of BDI2000 .cfg files, with register settings consistent with the latest U-Boot source. I've tested it on both the Freescale boards: MPC8349E-MDS-PB: - MPC8349E processor (v1.x silicon) - DDR1 SDRAM - Micron Q-Flash MPC8349EA-MDS-PB: - MPC8349EA processor (v3.x silicon) - DDR2 SDRAM - Spansion Flash Wolfgang/Stefan could you place these in the ftp://www.denx.de/pub/BDI2000, as they may be useful to others. I'll send the two files separately to avoid the newsgroup file size limits. [1/2] BDI .cfg for MPC8349E-MDS-PB Thanks! Dave ; bdiGDB configuration file for MPC8349E-MDS-PB board ;-- ; ; 3/03/2008 D. W. Hawkins ([EMAIL PROTECTED]) ; ; The Freescale MPC8349E/EA PowerQUICC II PowerPC processor ; has two evaluation boards; ; ; * MPC8349E-MDS-PB ;- MPC8349E processor (v1.x silicon) ;- DDR1 memory ;- Micron Q-Flash. ; ; * MPC8349EA-MDS-PB ;- MPC8349EA processor (v3.x silicon) ;- DDR2 memory ;- Spansion Mirror-bit (S29GL) Flash. ; ; The DDR memory controller requires a different configuration ; for the two boards, and the programming algorithms for the ; Flash is different. ; ;-- ; NOTES: ; -- ; ; 1. If the DDR memory is not known to be working (eg. on another ;MPC8349EA-based board), comment out the WORKSPACE used by ;the [FLASH] programming section below. ; ; 2. The memory map (local address window LAW) register settings ;in the [INIT] section were made identical to the ;U-Boot 1.3.1 settings (read from the board registers ;after U-Boot had started). ; ;0x_ - 0x0FFF_ 256MB DDR1 (single SODIMM) ;0xE000_ - 0xE00F_ 1MB IMMR ;0xE240_ - 0xE240_7FFF 32kB BCSR ;0xFE00_ - 0x_ 32MB Flash ; ;Note that the BCSRs are located at 0xF800_ in the ;Freescale MPC8349E-MDS-PB documentation. That documentation ;also defines PCI inbound/outbound windows. These windows ;are not configured by this configuration file, or by ;U-Boot 1.3.1. ; ; 3. U-Boot 1.3.1 uses low-memory boot, i.e., BMS = 0 in the ;reset configuration words. The DIP switch for FCFG ;(SW4.8) must be in the '1' position (closest to the ;power connector below it). This ensures that the RCWs ;are read from Flash. ; ;Once the Flash is programmed, the RCW entry in the ;[TARGET] section can be commented out. ; ; 4. U-Boot 1.3.1 initial messages: ; ;CPU: e300c1, MPC8349E, Rev: 11 at 528 MHz, CSB: 264 MHz ;Board: Freescale MPC8349EMDS ;I2C: ready ;DRAM: 256 MB (DDR1, 64-bit, ECC off) ;FLASH: 8 MB ;In:serial ;Out: serial ;Err: serial ;Net: TSEC0, TSEC1 ; ;So the CPU operates at 528MHz, the DDR operates ;at 132MHz clock rate (264MHz data rate), DDR ECC is off. ; ; 5. There are DDR registers defined in the MPC8349EA reference ;manual, that are not supposed to be programmed on the ;MPC8349E. AN3055 lists most of the register differences [5]. ; ;The following registers are programmed in the ;mpc8349ea_mds_pb.cfg file, but they are not used in the ;mpc8349e_mds_pb.cfg file (this file): ; ;Register offset relative to IMMR: ; - 0x0128 DDRCDR ; - 0x2100 TIMING_CFG_3 ; - 0x2104 TIMING_CFG_0 ; - 0x2114 DDR_SDRAM_CFG_2 ; - 0x211C DDR_SDRAM_MODE_2 ; ;-- ; REFERENCES: ; --- ; ; [1] MPC8349E PowerQUICC II Pro Integrated Host Processor ; Family Reference Manual, Rev. 1 8/2005, Freescale ; Semiconductor (MPC8349ERM.pdf). ; ; *** WARNING *** ; There was a revision 2 version of this manual released, ; however, that manual became the MPC8349EA manual, and ; the MPC8349E manual reverted to revision 1. ; ; [1b] Errata to the MPC8349E PowerQUICC II Pro Integrated Host ; Processor Family Reference Manual, Rev. 1, Rev 1.2, ; 08/2006 (MPC8349ERMAD.pdf). ; ; [2] MPC8349E MDS Processor Board User Manual, Rev. 1.6, ; 12/2005, Freescale Semiconductor. ; ; [3] MT46V64M4, MT46V32M8, MT46V16M16: 256Mb x4 x8 x16 DDR SDRAM ; Micron Technologies, 2000 (256MBDDRx4x8x16.pdf) ; ; [4] MT28F128J3, MT28F640J3, MT28F320J3: 128Mb, 64Mb, 32Mb ; Q-Flash memory, Micron Technologies, 2004 (MT28F640.pdf) ; ; [5] AN3055: Migration from MPC834x Revision 1.x to Revision ; 3.x, Freescale, Rev 4, 1/2008 ; ;-- ; ; = [INIT] ; init core register WREGMSR 0x1002 ;MSR : ME,RI ; Internal Memory Mapped Registers (IMMR) ; --- ; ; The base address of the 1MB of IMMR registers defaults ; to 0xFF40_ (see Ch. 2 and Ch. 5 [1]). ; ; Write to IMMRBAR to move the
[U-Boot-Users] BDI .cfg for MPC8349E/EA-MDS-PB [2/2]
Second .cfg file [2/2] BDI .cfg for MPC8349EA-MDS-PB ; bdiGDB configuration file for MPC8349EA-MDS-PB board ;-- ; ; 2/14/2008 D. W. Hawkins ([EMAIL PROTECTED]) ; ; The Freescale MPC8349E/EA PowerQUICC II PowerPC processor ; has two evaluation boards; ; ; * MPC8349E-MDS-PB ;- MPC8349E processor (v1.x silicon) ;- DDR1 memory ;- Micron Q-Flash. ; ; * MPC8349EA-MDS-PB ;- MPC8349EA processor (v3.x silicon) ;- DDR2 memory ;- Spansion Mirror-bit (S29GL) Flash. ; ; The DDR memory controller requires a different configuration ; for the two boards, and the programming algorithms for the ; Flash is different. ; ;-- ; NOTES: ; -- ; ; 1. If the DDR memory is not known to be working (eg. on another ;MPC8349EA-based board), comment out the WORKSPACE used by ;the [FLASH] programming section below. ; ; 2. The memory map (local address window LAW) register settings ;in the [INIT] section were made identical to the ;U-Boot 1.3.1 settings (read from the board registers ;after U-Boot had started). ; ;0x_ - 0x0FFF_ 256MB DDR2 (single SODIMM) ;0xE000_ - 0xE00F_ 1MB IMMR ;0xE240_ - 0xE240_7FFF 32kB BCSR ;0xFE00_ - 0x_ 32MB Flash ; ;Note that the BCSRs are located at 0xF800_ in the ;Freescale MPC8349EA-MDS-PB documentation. That documentation ;also defines PCI inbound/outbound windows. These windows ;are not configured by this configuration file, or by ;U-Boot 1.3.1. ; ; 3. U-Boot 1.3.1 uses low-memory boot, i.e., BMS = 0 in the ;reset configuration words. The DIP switch for FCFG ;(SW4.8) must be in the '1' position (closest to the ;power connector below it). This ensures that the RCWs ;are read from Flash. ; ;Once the Flash is programmed, the RCW entry in the ;[TARGET] section can be commented out. ; ; 4. In the MPC8349EA-MDS-PB schematic (Rev 2.0 Ver 0.2, 11/2006), ;the DDR DQS7 signal routes to DQS7 on U54.191 (the installed ;SODIMM), and DQS7# on U17.189 (the optional SODIMM). Given ;this error, its unlikely the second SODIMM is useable. ; ; 5. U-Boot 1.3.1 initial messages: ; ;CPU: e300c1, MPC8349E, Rev: 31 at 528 MHz, CSB: 264 MHz ;Board: Freescale MPC8349EMDS ;I2C: ready ;DRAM: 256 MB (DDR2, 64-bit, ECC on) ;FLASH: 32 MB ;In:serial ;Out: serial ;Err: serial ;Net: TSEC0, TSEC1 ; ;So the CPU operates at 528MHz, the DDR operates ;at 132MHz clock rate (264MHz data rate), DDR ECC is on. ; ;-- ; REFERENCES: ; --- ; ; [1] MPC8349EA PowerQUICC II Pro Integrated Host Processor ; Family Reference Manual, Rev. 1 08/2006, Freescale ; Semiconductor (MPC8349EARM.pdf). ; ; [2] MPC8349EA MDS Processor Board User Manual, Rev. 0.1, ; 12/2006, Freescale Semiconductor. ; ; [3] HYB18T256400/800/160AF(L) 256Mbit DDR2 SDRAM, Rev 1.41, ; 1/2007, Qimonda. ; ;-- ; ; = [INIT] ; init core register WREGMSR 0x1002 ;MSR ME,RI ; Internal Memory Mapped Registers (IMMR) ; --- ; ; The base address of the 1MB of IMMR registers defaults ; to 0xFF40_ (see Ch. 2 and Ch. 5 [1]). ; ; Write to IMMRBAR to move the IMMRs to 0xE000_. ; WM32 0xFF40 0xE000 ; Local Address Windows (LAWs) ; ; ; The processor has 9 LAWs (see Table 5-1 in Ch. 5 [1]). ; ; The MPC8349EA-MDS-PB uses; ; - a local-bus LAW for Flash ; - a local-bus LAW for BCSRs ; - a DDR LAW for DDR2 memory ; - and it can use a PCI LAW for PCI accesses ; ; Local-bus Flash ; --- ; LBC Local Access Window 0 Base Address Register (p5-7 [1]). ; LBLAWBAR0 ; [ 0:19] BASE_ADDR Base address MSBs (1MB aligned) ; [20:31]-Reserved ; ; LBC Local Access Window 0 Attributes Register (p5-8 [1]). ; LBLAWAR0 ; [0] ENEnabled (1) ; [26:31] SIZE Decode region is 2^(SIZE-1)-bytes ; WM320xE020 0xFE00 ;LBLAWBAR0 Flash WM320xE024 0x8018 ;LBLAWAR0 32MB ; Local-bus Board Control and Status Registers (BCSRs) ; ; LBC Local Access Window 1 Base Address Register (p5-7 [1]). ; LBLAWBAR1 ; [ 0:19] BASE_ADDR Base address MSBs (1MB aligned) ; [20:31]-Reserved ; ; LBC Local Access Window 1 Attributes Register (p5-8 [1]). ; LBLAWAR1 ; [0] ENEnabled (1) ; [26:31] SIZE Decode region is 2^(SIZE-1)-bytes ; WM320xE028 0xE240 ;LBLAWBAR1 BCSR WM320xE02C 0x800E ;LBLAWAR1 32kB ; DDR Memory ; -- ;
Re: [U-Boot-Users] MPC8349EMDS.h Why do the BAT entries use Memory coherency?
Hi all, Once I'd written the email on this subject to the U-Boot list, I figured it was starting to sound like a Freescale support request, so I submitted one too. Here's their response: Actually, snooping occurs inside MPC8349 device. Besides e300 core, other possible masters are: PCI1, PCI2, DMA, TSEC1, TSEC2, USB, Ecnryption engine. So, it does sound like there are devices internal to the MPC8349EA that are monitoring the e300 core gbl# signal, and hence the M-bit would need to be set in the 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. And this list pretty much makes sense. The exception would be the stack-in-dcache, since there is no external memory associated with the stack-in-dcache trick. Trying to understand the stack-in-dcache trick was what what started all this ... but, I guess in that case, having the M-Bit set in the BAT entry doesn't really matter, since nothing is (or should be) snooping that address anyway. Sorry for the 'noise' :) Cheers, Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Altera Stratix II
Hi Liberty, 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... If I understand your earlier posts, you are using a CFI flash, and then 'hiding' half or more of that Flash from the end user. You mention 'lifting pins', but I'm not sure if you were actually doing that, or effectively doing that using your FPGA on the Flash address lines. A few questions 1. Does it really matter if the user can read the data? If not, just use the write-protect feature of the Flash to protect it from users. Eg. have the local bus FPGA decode the flash chip select, and address, and keep write-protect asserted for the regions you want to protect. 2. Is there any way to have your FPGA do this hiding for you? For example, if the FPGA decoded the Flash chip select, it could allow the Flash to respond to low-addresses, and could itself drive zeros on the bus for accesses to the hidden region. 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? Cheers, Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
[U-Boot-Users] MPC8349EMDS.h Why do the BAT entries use Memory coherency?
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 SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] why eeprom vs flash
So, as the designer, its up to you. But keep in mind that you want to make it hard for a customer to screw up, so a separate EEPROM could be a good choice. In many cases it ain't. I've seen many board which lost their EEPROM contents, typically because of edge condition problems as documented in the file mentioned before - a poor power supply with too slow rise times of the voltages makes an excellent test case. I know of systems where it blows the EEPROM content in 2 out of 3 boot cycles :-( Interesting failure mode. In the case of say the MPC8349EA, it can use an I2C EEPROM as the boot sequencer. So if a board design really needed to use that mode, one would need to pay attention to the above issue - independently of whether this same EEPROM was used to store MAC addresses or serial numbers, etc. An example EEPROM for the boot sequencer would be the AT24C512B. Looking at its data sheet, there is a RESET MEMORY sequence that could be used by the processor every time it booted to ensure that the EEPROM was not left in a write-state. I doubt the boot sequencer does this, so that would only be a solution for storage of the environment in the EEPROM. A better solution, is that the part also has a write-protect pin, which can be controlled by a GPIO. If the GPIO is tri-stated on power-up (likely), then a pull-up on the pin can ensure that the part can not be written to in error. How slow is 'too slow' for a power-supply rise time? (doc/I2C_Edge_Conditions doesn't mention). To ensure correct power-supply sequencing, I use hot-swap controllers (on cPCI power supply inputs), dc-to-dc converters with programmable turn on times and slew-rates (for PPC/FPGA core voltages, and DDR voltages), and linear regulators with slew-rate controls. I've got most of them set to about 5-10ms. The PowerPC docs state it can handle about 20ms between all supplies, while the FPGAs want under 100ms, with monotonic ramps on them all. I doubt that I'll see this issue, but its an interesting problem to be aware of. Cheers, Dave PS. If anyone is interested, the power supply design notes, and board design is here: http://www.ovro.caltech.edu/~dwh/carma_board/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Re: [U-Boot-Users] Booting Standalone App?
onyxtape wrote: Hi there, So what are the steps to get u-boot to boot the hello_world example? I'm evaluating the PowerPC 440-based AMCC Yosemite board. Here are the notes I wrote for the Yosemite board, they include how to build the standard standalone example. Perhaps that will help you. http://www.ovro.caltech.edu/~dwh/powerpc_440ep.pdf Cheers, Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
