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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.