From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Mon, 27 Jun 2005 08:04:03 -0400 Subject: [U-Boot-Users] Strange : Same 8248 image needs to be reprogrammed In-Reply-To: <20050627070724.30431.qmail@web15906.mail.cnb.yahoo.com> References: <20050627070724.30431.qmail@web15906.mail.cnb.yahoo.com> Message-ID: <42BFEB33.208@smiths-aerospace.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Confusion issues: RSTCONF* is active low so either a) you are pulling it down, not up b) you have an inverter buffering it c) are wrong (since you can program flash, this is unlikely) Do you intend to boot high or low normally? I'm assuming boot-high (and would recommend you switch to boot-low). Note: you probably cannot avoid setting the BR0 and OR0 registers as part of your BDI initialization because the default HRCW is all zeros which is probably _not_ right for your hardware (BPS => 64 bit port size, BMS => 0xFE00_000). You should verify that your WireTAP configuration has the necessary and sufficient initialization and (preferably) no more. Sam Song wrote: > Jerry Van Baren wrote: > >>>>Pull up RSTCONF -> Connect WireTAP with No-head >>>>config file -> Program the image on 0xff000000 >>>>-> Disconnect WireTAP -> Pull down RSTCONF >>>>-> Power-on -> No serial output -> Power-down >>>>-> Connect WireTAP with head config file >>>>-> Reprogram the same image at 0xff000000 >>>>-> Disconnect WireTAP -> Power-on -> Work! > > [snip] > >>The reason your first approach didn't work is >>because the HRCW gets read from the >>_first_32_bytes_ of flash (four reads at offsets 0, > > In my first programming, RSTCONF pull up, HRCW is the > default vaule 0x00000000. It doesn't need to read it > from FLASH at all. When you programmed at 0xff000000, you put the HRCW in the right place but u-boot in the wrong place for boot-high. Both are in the right place for boot-low. I cannot explain why programming a second time at 0xff000000 "fixed" it, I would speculate that you really programmed at 0xfff00000 which would put u-boot in the right place for boot-high. >>8, 16, 24 with CS0 asserted). It isn't read from >>any true "address" - BR0/OR0 are configured by the >>HRCW and thus cannot be used for reading the HRCW. > > > Yeah, I do agree. In > > >>When you programmed u-boot at 0xFFF00000, u-boot was >>programmed into the proper location but the HRCW > > > I didn't program u-boot on 0xFFF00000 in this case. > 0xFF000000 instead. As noted above, this doesn't make sense. >>This is another reason for doing "low-boot" rather >>than "high-boot": in >>"low-boot" mode, both u-boot and the HRCW get placed >>in the proper memory locations inherently. > > Yeah, thanks to the perfect adjustment on 8260, all > we can do is to program one image at the first sector > of FLASH to finish HRCW and boot the target at the > same time. Low boot is much better than high boot > on this point. > >>Answering your second question, my experience is >>that RSTCONF is necessary and _barely_ sufficient > > So you mean RSTCONF MUST pull up when programming a > blank FLASH on a 8260 target with BDI? It must be _active_ (the physical pin must be pulled low, your hardware may be inverting it). A blank flash will be 0xffffffff which is not a valid HRCW and you will _not_ be able to program flash (CDIS core disable probably causes this). >>to program the HRCW in the first 32 >>bytes of flash. I never try to do more than that. > > So for every brand-new target, we need to pullup > RSTCONF once for programming the HRCW. Right? > > Could we program the low-boot image at this time > once for all on BDI? Yes (RSTCONF* active) and yes. The two big advantages of boot-low are 1a) No awkward flash size-dependent gap between the HRCW and u-boot 1b) You cannot use any of the other bytes in the first sector of flash for write purposes (which includes env variables) without risking screwing up your HRCW and turning the unit into a brick at your customer's site (big points off). This means you either waste most of the sector or you find something that doesn't ever change to put in the first sector. 2) One program operation with no offsets programs everything necessary to boot (u-boot + HRCW). There is one minor advantage of boot-low: you can replace u-boot without erasing and re-programming the HRCW. With boot-high, if you mess up reprogramming u-boot (and, inherently, the HRCW), you need to put the RSTCONF* jumper on, recover the HRCW, pull the RSTCONF* jumper off. With boot-low, you would only mess up u-boot, not the HRCW, so recovery doesn't include messing with the RSTCONF* jumpper. Like I said, basically no advantage. >>Once you have a valid HRCW programmed, deassert >>RSTCONF, cycle power (IMPORTANT since >>the HRCW is only read on a full reset) and proceed >>normally. > > Uh, Does "proceed normally" here mean we can use BDI > to program the low-boot image at the first sector of > FLASH? If so, BDI also needs to reprogram the low-boot > image at the first sector of FLASH. > > Or "proceed normally" means the programmed target > can boot directly with the image which was done by > pull-up case? Low boot: one program of the u-boot image takes care of both the HRCW and u-boot. Assert RSTCONF*, program u-boot, deassert RSTCONF*, cycle power. Simple. High boot: With RSTCONF* asserted, you can program any of flash anywhere, so you could theoretically program the HRCW and u-boot in the same programming session (two programming operations). Since the default HRCW when RSTCONF* is asserted sets the ISB to 0x0000_0000, if you link u-boot to reside at 0xFFF00000, you will have to use the proper offset on your BDI command to put the u-boot image in the top 1MB of flash (flash size dependent). I find it is much easier to program the HRCW so that my memory map is what it should be, deassert RSTCONF*, and cycle power to pick up the HRCW. At this point, you memory map will be what you normally run with and things will be a lot less confusing. > Thanks a lot for your notes, > > Sam