[LinuxBIOS] FILO with the USB
corey.osgood at gmail.com
Thu Nov 15 16:38:29 CET 2007
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
> On Nov 15, 2007 8:41 AM, Corey Osgood <corey.osgood at gmail.com> 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
>>> malloc_diag: alloc: 4208 bytes (8 blocks), free: 61320 bytes (1 blocks)
>>> malloc_check: sizes mismatch: 0xa1 vs 0x0 at 00132670
>>> 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;
>>> 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?
>> 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!
More information about the coreboot