[LinuxBIOS] FILO with the USB

[Corey Osgood]

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 <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
>>> 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
>>
>>     
>
>