Re: [U-Boot-Users] 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.
However, this once inside the phy mapped functions, printfs are illegal. And causing BAD trap errors, in this case it is causing an unhandled exception on Vector 400 on my system, which is a static storage handler error. Not entirely sure on WHY, but looking at the back trace and several pointers, I have noticed this.
Up till the call to any phy specific function, U-boot is happily running from the top of DDR Ram, but as soon as we traverse into phy specific handlers, it jumps BACK INTO FLASH! and starts executing! On my system this means the backtrace will contain a lot of calls around the 256MB boundary i.e. 0x0ffxxxxx and then suddently I will see return address being pushed at 0xE00xxxxx. My guess is that when printf or similar gets called, it tries to do a relative pop/push to the stack or something or tries to relatively access RAM and BOMBS.
My base system has the following setup DDR2 RAM: 0x00000000 - 0x1FFFFFFF (512MB) FLASH: 0xE0000000 - 0xEFFFFFFF (128MB physical, 128MB reserved for future) SOCL: 0xF0000000 - 0xF1000000 (IMMR SPACE)
When I get the error, I see the PC register is pointing at 0xFBFe7ee4????
This would make perfect sense, if the stack were placed at the top of ram, and I was executing 'accidently' from flash, i.e. it the PC was assumed to be at 0x0fxxxxxx and it somehow got shifted to the 0xE0xxxxxx block, and then tried to relatively add 256MB to get to the stack. It would end up at the 0xFxxxxxxx area???
Am I way off base here?? WHY is the UEC_Driver accessing flash after U-boot is running from RAM?
-Russ
-----Original Message----- From: Russell McGuire [mailto:rmcguire@videopresence.com] Sent: den 21 december 2007 11:46 To: u-boot-users@lists.sourceforge.net Cc: 'Kim Phillips'; joakim.tjernlund@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
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Joakim Tjernlund Sent: den 21 december 2007 13:35 To: rmcguire@videopresence.com; u-boot-users@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@videopresence.com] Sent: den 21 december 2007 11:46 To: u-boot-users@lists.sourceforge.net Cc: 'Kim Phillips'; joakim.tjernlund@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
Joakim Tjernlund wrote:
-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@lists.sourceforge.net] On Behalf Of Joakim Tjernlund Sent: den 21 december 2007 13:35 To: rmcguire@videopresence.com; u-boot-users@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@videopresence.com] Sent: den 21 december 2007 11:46 To: u-boot-users@lists.sourceforge.net Cc: 'Kim Phillips'; joakim.tjernlund@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
participants (3)
-
Ben Warren -
Joakim Tjernlund -
Russell McGuire