From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Tue, 03 Aug 2010 14:01:30 +0200 Subject: [U-Boot] [PATCH V5 4/4] edminiv2: add mvsata_ide and cmd_ide support In-Reply-To: <4C5661FE.506@free.fr> References: <1279022559-15772-1-git-send-email-albert.aribaud@free.fr> <1279022559-15772-2-git-send-email-albert.aribaud@free.fr> <1279022559-15772-3-git-send-email-albert.aribaud@free.fr> <1279022559-15772-4-git-send-email-albert.aribaud@free.fr> <4C49740D.3020003@free.fr> <4C55B043.3020604@free.fr> <4C5661FE.506@free.fr> Message-ID: <4C58051A.30606@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de (adding Tanmay who might be interested in the OpenOCD init sequence issue) Le 02/08/2010 08:13, Albert ARIBAUD a ?crit : > Hi, > > Le 02/08/2010 05:35, Prafulla Wadaskar a ?crit : > >> I tried tweaking MPP setup for SATA related stuff, it's multiplexed with UART and other I/Os (NAND), >> What I observed: if I boot kernel with sata support, kernel sata driver works properly and I can detect and use IDE devices. >> >> So I doubt MPP, I don't know kernel (latest stable) overrides MPP settings done by u-boot?? We can get some reference from there. > > I went the low level route and compared MPP / GPIO settings (content of > 0xf1010000, 0xf1010100, 0xf1010140) at original U-boot start and at > (patched) mainline u-boot start: three MPPs are set up differently, > namely MPP13 and 14 (original had UART 1 signals, mainline has SD > signals) and MPP29 (original had TS MP[9], mainline has GPIO). > > I have taken the OpenRD schematics from GlobalScale Technologies, and I > have found no indication that these signals have anything to do with SATA. > > Also, I have noticed that 'ide reset' may work on kirkwood dependending > on conditions yet imprecise, possibly related to whether an 'ide reset' > was already done from the original u-boot; also there are times when I > get garbled console output or no console at all. > > These random issues could come from the fact I use OpenOCD to reset the > Open-RD client, set up the RAM and upload and run the u-boot image, > rather than rely on the kwbimage process -- that's because I don't want > to flash to NAND until I am sure the boot loader works enough -- and > there may be initialization differences between the kwbimage wrapper and > the OpenOCD init script. I'll have a look at that too, just in case. I've had a look, and the OpenOCD config file for openrd has an incomplete init sequence, mostly concerning MPP settings. I've completed it and so far it seems to work better (I'll check/submit an update to the OpenOCD project for this). > As for the ATAPI issue as such, I'll try adding a delay between the > writes within the port initialization function, although I could find no > indication in the 88F6281 specs that such a delay is required or what > order of duration it should have. > > I'll post my results at end of day today. Actually two things were necessary to get ide reset to work reliably: 1) adding a delay between the writes to SControl. Experimentation showed this delay should be at least 41 us on my board. I have set it to 50 us to play safe on possible HW characteristics dispersions. 2) moving the call(s) to mvsata_ide_initialize_port() from board_init() function to function ide_preinit(), which is called just before an IDE reset if CONFIG_IDE_INIT is set -- accordingly, I added ide_preinit() to openrd_base.c and defined CONFIG_IDE_INIT in kirkwood.h. Prafulla, can you try the patch attached above yours? If this works, then I'll backport the above fixes to orion5x/edminiv2 and post a V7 patch. Amicalement, -- Albert. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mvsata_on_kw_aa.patch Url: http://lists.denx.de/pipermail/u-boot/attachments/20100803/fcb86341/attachment.asc