libertas sdio on bf548 w/ uclinux
Nick Moszer
nick.moszer at packetdigital.com
Mon Apr 21 20:09:53 EDT 2008
The scripts seem to solve that problem. Thanks!
I was wondering if you guys know what is typical for block sizes when
loading the firmware.
I am able to load the helper firmware just fine, once I get to the main
firmware a little debug shows:
(a whole mess of alternating 1, 16 block numbers like below)
sdh_setup_data enter flags:0x100 numblocks:1
blksize:32
sdh_setup_data enter flags:0x100 numblocks:16
blksize:32
sdh_setup_data enter flags:0x100 numblocks:1
blksize:32
sdh_setup_data enter flags:0x100 numblocks:16
blksize:32
sdh_setup_data enter flags:0x100 numblocks:1
blksize:32
sdh_setup_data enter flags:0x100 numblocks:3
blksize:32
sdh_setup_data enter flags:0x100 numblocks:1
blksize:32
sdh_setup_data enter flags:0x100 numblocks:1 blksize:52
Then the oddball at the end. It was 50 until I added the "round to a
multiple of 4" code in if_sdio.c.
My host controller driver does not like anything that isn't a power of 2.
Meaning they wrote the driver on this blackfin so that anything not a
power of 2 will call BUG_ON and cause a panic.
Is this normal behavior for the block size to change when loading like
that?
Thanks!
Dan Williams wrote:
> On Mon, 2008-04-14 at 22:17 +0200, Julien Boibessot wrote:
>
>> Dan Williams a écrit :
>>
>>> That's all handled by udev these days on most systems, unfortunately I'm
>>> not so up-to-date on the details of udev. Might be best to ask around
>>> the udev lists. Do you have any other drivers in your kernel that use
>>> request_firmware(), and do they work?
>>>
>>>
>> On my ARM9 system, with a Buildroot made Rootfs (without udev),
>> following script is working to load helper firmware (save it as
>> /sbin/hotplug):
>>
>> #!/bin/sh
>> if [ "$FIRMWARE" != "" ]; then
>> HOTPLUG_FW_DIR=/lib/firmware/
>> echo 1 > /sys/$DEVPATH/loading
>> cat $HOTPLUG_FW_DIR/$FIRMWARE > /sys/$DEVPATH/data
>> echo 0 > /sys/$DEVPATH/loading
>> fi
>>
>>
>> If it can help...
>>
>
> Most likely yes, since there are cases where you don't want the
> complexity that udev drags along :)
>
> Thanks,
> Dan
>
>
>
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev
>
More information about the libertas-dev
mailing list