[U-Boot] crash in usb_stor_get_info using pre-relocation address for ss->transport

[Albert ARIBAUD]

Hi Chris,

On Thu, 13 Jun 2013 13:16:17 +1200, Chris Packham
<judge.packham at gmail.com> wrote:

> On Thu, Jun 13, 2013 at 12:02 PM, Chris Packham <judge.packham at gmail.com> wrote:
> > Hi,
> >
> > I've just found a crash in usb_stor_get_info (actually usb_inquiry
> > which gets auto-inlined). The cause seems to be that ss->transport is
> > set to the pre-relocation address of usb_stor_BBB_transport. Yet
> > ss->transport_reset is set to the correct relocated address of.
> >
> > The difference between the two is that usb_stor_BBB_reset is declared
> > static and usb_stor_BBB_transport is not. Changing
> > usb_stor_BBB_transport to a static makes things work but I notice that
> > none of the other transport functions are static either so I'm
> > thinking I haven't actually fixed the problem rather just masked it.
> 
> Actually I see commit 199adb60 (common/misc: sparse fixes) does change
> the transport functions to static. Which is the change I was looking
> at. I still don't know if it is fixing a problem or masking a
> different one but this is probably why no-one else is complaining that
> their usb mass storage devices are causing crashes. I'll cherry-pick
> this to fix my problem.
> 
> >
> > I did  some poking with a lauterbach and from the disassembly it looks
> > like there is a translation table being used when the function
> > pointers are setup by usb_storage_probe and when declared normally
> > usb_stor_BBB_transport ends up at the end. Everything else has the
> > correct relocated address so I wonder if there is an off-by-one error
> > in whatever creates that table.

Can you elaborate? The only relocation-related table that I know of is
the one used in relocate_code(), and no other relocation-fix table
exists or is used anywhere else.

> > Does this sound familiar to anyone.

Familiar, no, but it does set in my mind, if not a blaring alarm with
flashing beacons, at least a blinking red light with a beep, so let's
analyize this.

Amicalement,
-- 
Albert.