From: Ben Warren <bwarren@qstreams.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] 83xx, FSL_UEC reducing boot latency, printf causing crash
Date: Fri, 21 Dec 2007 19:18:32 -0500 [thread overview]
Message-ID: <476C57D8.7000108@qstreams.com> (raw)
In-Reply-To: <006301c843cf$2e9f6b30$5267a8c0@Jocke>
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
>
>
next prev parent reply other threads:[~2007-12-22 0:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.185590.1187040981.7786.u-boot-users@lists.sourceforge.net>
2007-11-30 11:22 ` [U-Boot-Users] CONFIG_MII, 83xx, no MII device? Russell McGuire
2007-12-04 22:03 ` Kim Phillips
2007-12-04 23:50 ` Joakim Tjernlund
2007-12-05 15:12 ` Kim Phillips
2007-12-19 3:58 ` [U-Boot-Users] 83xx, FSL_UEC reducing boot latency, printf causing crash Russell McGuire
2007-12-19 7:54 ` Joakim Tjernlund
2007-12-19 8:07 ` Joakim Tjernlund
2007-12-19 23:36 ` Russell McGuire
2007-12-20 1:13 ` Kim Phillips
[not found] ` <000001c8435a$99d4b1f0$6405a8c0@absolut>
[not found] ` <1198194282.8129.45.camel@gentoo-jocke.transmode.se>
2007-12-21 10:45 ` Russell McGuire
2007-12-21 12:35 ` Joakim Tjernlund
2007-12-21 12:44 ` Joakim Tjernlund
2007-12-22 0:18 ` Ben Warren [this message]
2007-12-21 11:02 ` Russell McGuire
2007-12-21 12:12 ` Joakim Tjernlund
2007-12-20 1:29 Russell McGuire
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=476C57D8.7000108@qstreams.com \
--to=bwarren@qstreams.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox