[U-Boot-Users] 83xx, FSL_UEC reducing boot latency, printf causing crash

[Ben Warren]

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
>
>