kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
* request_firmware in DMA region
@ 2020-03-18 14:29 Lucas Tanure
  2020-03-18 14:46 ` Greg KH
  0 siblings, 1 reply; 4+ messages in thread
From: Lucas Tanure @ 2020-03-18 14:29 UTC (permalink / raw)
  To: kernelnewbies

Hi,

I'm sending firmware to usb device with this code:
But it`s falling because the request firmware call didn't put my 
firmware in a DMA capable area. That's my guess.

So how to request firmware in DMA capable area?

Thanks
Lucas

[   30.330081] ------------[ cut here ]------------
[   30.334782] WARNING: CPU: 1 PID: 557 at 
/media/workspace/linux/drivers/usb/core/hcd.c:1586 
usb_hcd_map_urb_for_dma+0x4f4/0x634
[   30.346362] transfer buffer not dma capable
[   30.350623] Modules linked in: usb_bridge_boot(+) bnep hci_uart btbcm 
serdev bluetooth ecdh_generic 8021q garp stp llc bcm2835_codec(C) 
brcmfmac vc4 brcmutil v4l6
[   30.406130] CPU: 1 PID: 557 Comm: systemd-udevd Tainted: G         
C        4.19.108-v7l+ #1
[   30.414691] Hardware name: BCM2835
[   30.418148] [<c0212c6c>] (unwind_backtrace) from [<c020d490>] 
(show_stack+0x20/0x24)
[   30.426009] [<c020d490>] (show_stack) from [<c09c1ac0>] 
(dump_stack+0xd8/0x11c)
[   30.433428] [<c09c1ac0>] (dump_stack) from [<c0222138>] 
(__warn+0xf0/0x108)
[   30.440492] [<c0222138>] (__warn) from [<c02221a8>] 
(warn_slowpath_fmt+0x58/0x74)
[   30.448087] [<c02221a8>] (warn_slowpath_fmt) from [<c079df38>] 
(usb_hcd_map_urb_for_dma+0x4f4/0x634)
[   30.457357] [<c079df38>] (usb_hcd_map_urb_for_dma) from [<c079e518>] 
(usb_hcd_submit_urb+0x4a0/0x968)
[   30.466714] [<c079e518>] (usb_hcd_submit_urb) from [<c079fbfc>] 
(usb_submit_urb+0x354/0x504)
[   30.475277] [<c079fbfc>] (usb_submit_urb) from [<c07a0430>] 
(usb_start_wait_urb+0x6c/0xf0)
[   30.483663] [<c07a0430>] (usb_start_wait_urb) from [<c07a0588>] 
(usb_control_msg+0xd4/0x12c)
[   30.492232] [<c07a0588>] (usb_control_msg) from [<bf984270>] 
(clbrd_probe+0x240/0x43c [usb_bridge_boot])
[   30.502135] [<bf984270>] (clbrd_probe [usb_bridge_boot]) from 
[<c07a4f64>] (usb_probe_interface+0xec/0x278)
[   30.512287] [<c07a4f64>] (usb_probe_interface) from [<c071a4d8>] 
(really_probe+0x1e8/0x2d0)
[   30.520762] [<c071a4d8>] (really_probe) from [<c071a794>] 
(driver_probe_device+0x70/0x184)
[   30.529149] [<c071a794>] (driver_probe_device) from [<c071a998>] 
(__driver_attach+0xf0/0xf4)
[   30.537712] [<c071a998>] (__driver_attach) from [<c07183f4>] 
(bus_for_each_dev+0x84/0xc4)
[   30.546011] [<c07183f4>] (bus_for_each_dev) from [<c0719ddc>] 
(driver_attach+0x2c/0x30)
[   30.554133] [<c0719ddc>] (driver_attach) from [<c07197bc>] 
(bus_add_driver+0x19c/0x220)
[   30.562254] [<c07197bc>] (bus_add_driver) from [<c071b184>] 
(driver_register+0x84/0x118)
[   30.570464] [<c071b184>] (driver_register) from [<c07a3d84>] 
(usb_register_driver+0x80/0x144)
[   30.579117] [<c07a3d84>] (usb_register_driver) from [<bf989030>] 
(clbrd_driver_init+0x30/0x1000 [usb_bridge_boot])
[   30.589889] [<bf989030>] (clbrd_driver_init [usb_bridge_boot]) from 
[<c0203138>] (do_one_initcall+0x50/0x214)
[   30.600218] [<c0203138>] (do_one_initcall) from [<c02bdcb8>] 
(do_init_module+0x74/0x224)
[   30.608429] [<c02bdcb8>] (do_init_module) from [<c02bcce8>] 
(load_module+0x202c/0x25dc)
[   30.616552] [<c02bcce8>] (load_module) from [<c02bd4d8>] 
(sys_finit_module+0xbc/0xe8)
[   30.624497] [<c02bd4d8>] (sys_finit_module) from [<c02011a4>] 
(__sys_trace_return+0x0/0x1c)
[   30.632969] Exception stack(0xdafdffa8 to 0xdafdfff0)
[   30.638091] ffa0:                   fda1c800 01e30b08 00000006 
b6d8f8e0 00000000 b6d903f4
[   30.646388] ffc0: fda1c800 01e30b08 00000000 0000017b 01e5c418 
0057f1dc 01e5d0c8 00000000
[   30.654684] ffe0: bea80180 bea80170 b6d869d8 b6e76af0
[   30.659823] ---[ end trace fa96d8b137009b49 ]---

static int fx3_ram_write(struct usb_device *udev, u32 *buf, u32 
ramAddress, size_t len)
{
     size_t index = 0, size;
     int ret;

     while(len > 0) {
         size = (len > MAX_WRITE_SIZE) ? MAX_WRITE_SIZE : len;
         ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0), 0xA0, 0x40,
                       ramAddress & 0xFFFF, ramAddress >> 16,
                       &buf[index], size, VENDORCMD_TIMEOUT);
         if (ret != size) {
             ret = (ret < 0) ? ret : -EIO;
             dev_err(&udev->dev, "Error: Vendor write to FX3 RAM failed: 
%d\n", ret);
             return ret;
         }
         ramAddress += size;
         index      += size;
         len        -= size;
     }

     return 0;
}

static int clbrd_probe(struct usb_interface *intf,
                const struct usb_device_id *id)
{
     struct device *dev = &intf->dev;
     struct usb_device *udev = interface_to_usbdev(intf);
     const struct firmware *firmware;
     struct fx3_img *img;
     struct fx3_sector *sector;
     int ret;

     dev_info(&intf->dev, "%s\n", __func__);

     ret = request_firmware(&firmware, FW_NAME, dev);
     if (ret)
         dev_err(dev, "request_firmware failed '%s' = %d (check 
files)\n", FW_NAME, ret);

     img = (struct fx3_img*)firmware->data;

     print_img_header(dev, img);

     sector = (struct fx3_sector*)img->sectors;
     while ((u8*)sector < firmware->data + firmware->size) {

         dev_dbg(&intf->dev, "0x%.4x 0x%.4x\n", sector->dLength , 
sector->dAddress);

         if (sector->dLength == 0) {
             ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
                           0xA0, 0x40,
                           (sector->dAddress & 0xFFFF),
                           (sector->dAddress >> 16),
                           NULL, 0, VENDORCMD_TIMEOUT);
             if (ret < 0)
                 dev_err(dev, "Fail to write last sector: %d\n", ret);
             break;
         }

         ret = fx3_ram_write(udev, sector->dData, sector->dAddress, 
sector->dLength * 4);
         if (ret < 0)
             dev_err(dev, "Fail to write sector: %d\n", ret);

         sector +=  sizeof(sector->dLength) + sizeof(sector->dAddress) + 
(sector->dLength * 4);
     }

     release_firmware(firmware);
     return ret;
}



_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: request_firmware in DMA region
  2020-03-18 14:29 request_firmware in DMA region Lucas Tanure
@ 2020-03-18 14:46 ` Greg KH
  2020-03-18 16:55   ` Lucas Tanure
  0 siblings, 1 reply; 4+ messages in thread
From: Greg KH @ 2020-03-18 14:46 UTC (permalink / raw)
  To: Lucas Tanure; +Cc: kernelnewbies

On Wed, Mar 18, 2020 at 02:29:24PM +0000, Lucas Tanure wrote:
> Hi,
> 
> I'm sending firmware to usb device with this code:
> But it`s falling because the request firmware call didn't put my firmware in
> a DMA capable area. That's my guess.
> 
> So how to request firmware in DMA capable area?

kmalloc your buffer used for USB transfers.

Do you have a pointer to your driver anywhere?  The code you show below
isn't in any kernel source that I can see.

thanks,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: request_firmware in DMA region
  2020-03-18 14:46 ` Greg KH
@ 2020-03-18 16:55   ` Lucas Tanure
  2020-03-18 17:09     ` Greg KH
  0 siblings, 1 reply; 4+ messages in thread
From: Lucas Tanure @ 2020-03-18 16:55 UTC (permalink / raw)
  To: Greg KH; +Cc: kernelnewbies

On 2020-03-18 14:46, Greg KH wrote:
> On Wed, Mar 18, 2020 at 02:29:24PM +0000, Lucas Tanure wrote:
>> Hi,
>>
>> I'm sending firmware to usb device with this code:
>> But it`s falling because the request firmware call didn't put my firmware in
>> a DMA capable area. That's my guess.
>>
>> So how to request firmware in DMA capable area?
> kmalloc your buffer used for USB transfers.
Thanks, worked.
>
> Do you have a pointer to your driver anywhere?  The code you show below
> isn't in any kernel source that I can see.

I`m working to get permission for that.

Quick question: Why my usb driver doesn't unload after I disconnected it ?

This driver is meant to load a new firmware into the board only. And 
after the bootloader finished the download the board with show it self 
with a different vendor and product id.

All the firmware download in done in probe, so there is no need for this 
driver after that. Can my driver unload it self ?

>
> thanks,
>
> greg k-h

Thanks!

Lucas



_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: request_firmware in DMA region
  2020-03-18 16:55   ` Lucas Tanure
@ 2020-03-18 17:09     ` Greg KH
  0 siblings, 0 replies; 4+ messages in thread
From: Greg KH @ 2020-03-18 17:09 UTC (permalink / raw)
  To: Lucas Tanure; +Cc: kernelnewbies

On Wed, Mar 18, 2020 at 04:55:47PM +0000, Lucas Tanure wrote:
> On 2020-03-18 14:46, Greg KH wrote:
> > On Wed, Mar 18, 2020 at 02:29:24PM +0000, Lucas Tanure wrote:
> > > Hi,
> > > 
> > > I'm sending firmware to usb device with this code:
> > > But it`s falling because the request firmware call didn't put my firmware in
> > > a DMA capable area. That's my guess.
> > > 
> > > So how to request firmware in DMA capable area?
> > kmalloc your buffer used for USB transfers.
> Thanks, worked.
> > 
> > Do you have a pointer to your driver anywhere?  The code you show below
> > isn't in any kernel source that I can see.
> 
> I`m working to get permission for that.

It will have to happen eventually, might as well do it now so that you
can get help with it :)

> Quick question: Why my usb driver doesn't unload after I disconnected it ?

Who knows, we can't see the code, odds are there is a bug somewhere.

> This driver is meant to load a new firmware into the board only. And after
> the bootloader finished the download the board with show it self with a
> different vendor and product id.
> 
> All the firmware download in done in probe, so there is no need for this
> driver after that. Can my driver unload it self ?

Why do you need a kernel driver at all, you can do all of that from
userspace using libusb today.

And no, a driver can not unload itself, but it does not have to bind to
a device if you don't want to, which should keep it from ever actually
sticking to a device after the probe call has returned.

thanks,

greg k-h

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-03-18 17:10 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-18 14:29 request_firmware in DMA region Lucas Tanure
2020-03-18 14:46 ` Greg KH
2020-03-18 16:55   ` Lucas Tanure
2020-03-18 17:09     ` Greg KH

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).