From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Warren Date: Fri, 21 Dec 2007 19:18:32 -0500 Subject: [U-Boot-Users] 83xx, FSL_UEC reducing boot latency, printf causing crash In-Reply-To: <006301c843cf$2e9f6b30$5267a8c0@Jocke> References: <001a01c83343$502979e0$6405a8c0@absolut><20071204160356.fb61dc05.kim.phillips@freescale.com><003701c836d0$7eed0860$02ac10ac@Jocke><20071205091232.22478a9b.kim.phillips@freescale.com><000301c841f3$71701b90$6405a8c0@absolut><1198051648.21876.77.camel@gentoo-jocke.transmode.se><000001c8435a$99d4b1f0$6405a8c0@absolut><1198194282.8129.45.camel@gentoo-jocke.transmode.se><001901c843be$ab735a10$6405a8c0@absolut> <006201c843cd$ef3c1cf0$5267a8c0@Jocke> <006301c843cf$2e9f6b30$5267a8c0@Jocke> Message-ID: <476C57D8.7000108@qstreams.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Joakim Tjernlund wrote: >> -----Original Message----- >> From: u-boot-users-bounces at lists.sourceforge.net >> [mailto:u-boot-users-bounces at lists.sourceforge.net] On Behalf >> Of Joakim Tjernlund >> Sent: den 21 december 2007 13:35 >> To: rmcguire at videopresence.com; u-boot-users at lists.sourceforge.net >> Cc: 'Kim Phillips' >> Subject: Re: [U-Boot-Users] 83xx, FSL_UEC reducing boot >> latency,printf causing crash >> >> >>> -----Original Message----- >>> From: Russell McGuire [mailto:rmcguire at videopresence.com] >>> Sent: den 21 december 2007 11:46 >>> To: u-boot-users at lists.sourceforge.net >>> Cc: 'Kim Phillips'; joakim.tjernlund at transmode.se >>> Subject: RE: 83xx, FSL_UEC reducing boot latency, printf >>> >> causing crash >> >>> All, >>> >>> Maybe somebody can help me understand what I am seeing >>> Dealing with the printf causing crashes problem. >>> >>> This only occurs if printfs are caleed from within the >>> uec_phy.c file, and >>> only them within functions that are mapped as part of a phy >>> specific call, >>> i.e. a function that was within a specific part, marvell, >>> national, etc... >>> >>> So when a read_status call is called, of course depending on your >>> configuration it might get redirected to call genmii_read_status or >>> equivlant. >>> >> Just to add, as I recall, it is the use of function pointers that >> is the probem. These doesn't get relocated with normal u-boot >> relocation. Full relocation adds stuff to __fixup_entries >> which will relocate function ptrs that normal relocation doesn't do. >> >> Jocke >> > > BTW, the marwell entry looks bad: > static struct phy_info phy_info_marvell = { > .phy_id = 0x01410c00, > .phy_id_mask = 0xffffff00, > .name = "Marvell 88E11x1", > .features = MII_GBIT_FEATURES, > .config_aneg = &marvell_config_aneg, > .read_status = &marvell_read_status, > .ack_interrupt = &marvell_ack_interrupt, > .config_intr = &marvell_config_intr, > }; > > Those & should not be there I think. > > Futhermore I think each specific PHY type should have its own CONFIG_ #define > to reduce code. > > Jocke > > In the much-talked-about-but-little-seen upcoming PHY library, each manufacturer has its own source file (and of course CONFIG_), just like Linux > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > U-Boot-Users mailing list > U-Boot-Users at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/u-boot-users > >