Right
Sorry
On Nov 15, 2007 5:38 PM, Corey Osgood <[EMAIL PROTECTED]> wrote:
> Fridel Fainshtein wrote:
> > I compared to etherboot and it works there.
> > In Etherboot there are 2 set of bswap functions:
> > 1) little
> > 2) big
> >
> > In FILO there is only one bswap set
> >
> > Which one to choose?
> >
>
> no idea. but please cc the list with stuff like this so someone else can
> help.
>
> -corey
>
>
> > On Nov 15, 2007 8:41 AM, Corey Osgood <[EMAIL PROTECTED]> wrote:
> >
> >> Fridel Fainshtein wrote:
> >>
> >>> Hello all,
> >>>
> >>> It seams that the USB code was taken from the previous version of FILO
> >>> but never have been tested.
> >>>
> >>>
> >> Since noone else piped up, here's what I've figured out:
> >> Older versions of FILO (<0.5) don't have any USB support. The original
> >> author(s) of FILO's USB stack were from LinuxLabs. I don't know what the
> >> story is, but it was probably written under contract for someone (in a
> >> case where it did work), and they simply don't have the time to provide
> >> support for it. I've heard that it was originally merged from Etherboot,
> >> where it may have worked, but I can't confirm that. In any case, it
> >> doesn't seem to have been really touched since the initial import to the
> >> svn repository, according to the svn logs.
> >>
> >>
> >>> Some symptoms are
> >>> 1)
> >>> malloc_diag: alloc: 4208 bytes (8 blocks), free: 61320 bytes (1 blocks)
> >>> malloc_check: sizes mismatch: 0xa1 vs 0x0 at 00132670
> >>> 2)
> >>> dma_to_td: can not find td
> >>>
> >>>
> >> Is this using an OHCI controller? I've tried several times with UHCI and
> >> seen a different error:
> >>
> >> malloc_diag: alloc: xxxx bytes ([x] blocks), free: xxxx bytes (2 blocks)
> >> init_framelist: frame_list is at 13[n]000
> >> dump_link: frame_list_link: addr: 001233[n+1]0
> >> dump_link: frame_list_link: raw addr: 1bfd40[n*2]0
> >> dump_link: frame_list_link: terminate: 0
> >> dump_link: frame_list_link: queue: 1
> >> dump_link: frame_list_link: depth: 0
> >> (repeated half a dozen or so times)
> >> Out of heap space
> >>
> >>
> >>> Trying to debug it, I discovered the following piece of code:
> >>>
> >>> void *allot2(size_t size, unsigned int alignment)
> >>> {
> >>> void *addr;
> >>> unsigned long addrval;
> >>> addr=malloc(2*size);
> >>>
> >>> addrval=(unsigned long)addr;
> >>> addrval+=alignment+1; // 0x12345600 + 0xff + 1
> >>> addrval&=~alignment; // 0x12345700
> >>> *(void * *)(addrval-sizeof(unsigned long))=addr;
> >>> return (void *)addrval;
> >>> }
> >>>
> >>> void forget2(void *mem)
> >>> {
> >>> unsigned long addr=(unsigned long)mem;
> >>>
> >>> addr-=sizeof(unsigned long);
> >>> free((void *)(*(unsigned long *)addr));
> >>> }
> >>>
> >>> I have 2 questions:
> >>> if size = 8 and alignment=256, it writes outside malloc allocation, isn't
> >>> it?
> >>> What was the meaning of the code?
> >>>
> >>> Thanks
> >>>
> >> No idea. This does sound like something worth taking a look at, you
> >> might want to investigate how Etherboot does malloc/allot and also see
> >> if USB really does work there.
> >>
> >> Good luck!
> >> Corey
> >>
> >>
> >
> >
>
>
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
