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