Travis, On the Phytec base board there are two switches (BTN1 and BTN2) If memory serves me, BTN1 if engaged will cause the S1L to use the default settings instead of the ones in the EEPROM. Check to see if it is stuck or JP25 is missing.
From: [email protected] [mailto:[email protected]] On Behalf Of Travis Imken Sent: Saturday, July 16, 2011 7:05 PM To: [email protected] Subject: [Ltib] Curious phytec LPC3250 S1L problem Hello there, I realize that this email is a little out of place on the LTIB mail list, but I am hoping someone may have the knowledge to help me; otherwise, I am sorry to bother you with this email (and feel free to point me in a different direction). I am a student working with a Phytec LPC3250 board for a school project. I am running into an issue with the S1L as I try to migrate our SOM from the development board to a custom interface board. Every time we power the LPC3250 on our interface board, the S1L seems to remember no settings (prompt name, image location, etc.) Below is the message we get: Using default system configuration Phytec LPC3250 board Build date: Dec 4 2008 09:45:09 PHY3250>info Prompt bootup timeout (secs) = 50000 FLASH device : detected Number of FLASH blocks : 4096 FLASH pages per block : 32 FLASH bytes per page : 512 Total FLASH size (Mbytes): 64 Stage 1 loader number of blocks used: 25 File loaded in memory: None No image stored in FLASH Autoboot source : Disabled SDRAM type/size: Low power SDRAM 64MB MMU : Enabled ARM system clock (Hz) = 208000000 HCLK (Hz) = 104000000 Peripheral clock (Hz) = 13000000 Ethernet MAC address: 50:ed:f4:01:fd:ec NAND FLASH vendor : 0x20 NAND FLASH device ID : 0x36 >From here, we are able to load u-boot from the SD card, mount it into the >flash, and then boot from it (like setting up the SOM for the first time). >U-Boot does use all of the boot variables stored in the flash from the SOM's >time on the development board. It will then boot into Linux with no issues. >However, if power is cycled, we again get the same message of "Using default >system configuration" and nothing will happen; it remembers none of the >settings. This includes something as basic as changing the prompt name. The curiosity of the problem comes when we place the SOM back onto the Phytec development board. Upon powering the LPC3250 on the dev board, it boots complete fine; no settings have to be changed or altered. I get the feeling that I am missing something basic but we have stared at this problem for hours with no victory. Why can the S1L not find the information it needs to boot on our board but is completely fine on the development board? Where is this information located? What could cause it to not be found, be saved, and then be completely fine on the dev board? I realize that without knowledge of our board it's hard for y'all to help trouble shoot this problem, but right now we are just fishing for leads to investigate. For reference, here is the 'info' from the S1L for the same SOM when it is on the phytec dev board: Phytec LPC3250 board Build date: Dec 4 2008 09:45:09 Autoboot in progress, press any key to stop.. phy3250-linux>info Prompt bootup timeout (secs) = 2 FLASH device : detected Number of FLASH blocks : 4096 FLASH pages per block : 32 FLASH bytes per page : 512 Total FLASH size (Mbytes): 64 Stage 1 loader number of blocks used: 25 File loaded in memory: None FLASH image first block used : 25 FLASH image blocks used : 10 FLASH image sectors used : 298 FLASH image size in bytes : 152220 FLASH image load address : 0x83fc0000 FLASH image execution address : 0x83fc0000 Autoboot source : FLASH Autoboot image type : RAW SDRAM type/size: Low power SDRAM 64MB MMU : Enabled ARM system clock (Hz) = 208000000 HCLK (Hz) = 104000000 Peripheral clock (Hz) = 13000000 Ethernet MAC address: 50:ed:f4:01:fd:ec NAND FLASH vendor : 0x20 NAND FLASH device ID : 0x36 phy3250-linux> I want to add a couple of points to highlight what we've been trying so far: 1) Having the watchdog enabled or disabled (via electrical connection) did not affect the problem. 2) We have confirmed that the /SERVICE pin is connected to ground as it is on the Development board. We have also tried removing a 0-ohm resistor from this line on our board to pull it high as well, but it made no difference. We came across this idea from a paragraph in chapter 8.1 of the LPC3250 hardware manual. Thanks for your time. Travis
_______________________________________________ LTIB home page: http://ltib.org Ltib mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/ltib
