Re: request_firmware in DMA region
On Wed, Mar 18, 2020 at 04:55:47PM +, Lucas Tanure wrote: > On 2020-03-18 14:46, Greg KH wrote: > > On Wed, Mar 18, 2020 at 02:29:24PM +, 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
Re: request_firmware in DMA region
On 2020-03-18 14:46, Greg KH wrote: On Wed, Mar 18, 2020 at 02:29:24PM +, 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
Re: request_firmware in DMA region
On Wed, Mar 18, 2020 at 02:29:24PM +, 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
request_firmware in DMA region
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] [] (unwind_backtrace) from []
(show_stack+0x20/0x24)
[ 30.426009] [] (show_stack) from []
(dump_stack+0xd8/0x11c)
[ 30.433428] [] (dump_stack) from []
(__warn+0xf0/0x108)
[ 30.440492] [] (__warn) from []
(warn_slowpath_fmt+0x58/0x74)
[ 30.448087] [] (warn_slowpath_fmt) from []
(usb_hcd_map_urb_for_dma+0x4f4/0x634)
[ 30.457357] [] (usb_hcd_map_urb_for_dma) from []
(usb_hcd_submit_urb+0x4a0/0x968)
[ 30.466714] [] (usb_hcd_submit_urb) from []
(usb_submit_urb+0x354/0x504)
[ 30.475277] [] (usb_submit_urb) from []
(usb_start_wait_urb+0x6c/0xf0)
[ 30.483663] [] (usb_start_wait_urb) from []
(usb_control_msg+0xd4/0x12c)
[ 30.492232] [] (usb_control_msg) from []
(clbrd_probe+0x240/0x43c [usb_bridge_boot])
[ 30.502135] [] (clbrd_probe [usb_bridge_boot]) from
[] (usb_probe_interface+0xec/0x278)
[ 30.512287] [] (usb_probe_interface) from []
(really_probe+0x1e8/0x2d0)
[ 30.520762] [] (really_probe) from []
(driver_probe_device+0x70/0x184)
[ 30.529149] [] (driver_probe_device) from []
(__driver_attach+0xf0/0xf4)
[ 30.537712] [] (__driver_attach) from []
(bus_for_each_dev+0x84/0xc4)
[ 30.546011] [] (bus_for_each_dev) from []
(driver_attach+0x2c/0x30)
[ 30.554133] [] (driver_attach) from []
(bus_add_driver+0x19c/0x220)
[ 30.562254] [] (bus_add_driver) from []
(driver_register+0x84/0x118)
[ 30.570464] [] (driver_register) from []
(usb_register_driver+0x80/0x144)
[ 30.579117] [] (usb_register_driver) from []
(clbrd_driver_init+0x30/0x1000 [usb_bridge_boot])
[ 30.589889] [] (clbrd_driver_init [usb_bridge_boot]) from
[] (do_one_initcall+0x50/0x214)
[ 30.600218] [] (do_one_initcall) from []
(do_init_module+0x74/0x224)
[ 30.608429] [] (do_init_module) from []
(load_module+0x202c/0x25dc)
[ 30.616552] [] (load_module) from []
(sys_finit_module+0xbc/0xe8)
[ 30.624497] [] (sys_finit_module) from []
(__sys_trace_return+0x0/0x1c)
[ 30.632969] Exception stack(0xdafdffa8 to 0xdafdfff0)
[ 30.638091] ffa0: fda1c800 01e30b08 0006
b6d8f8e0 b6d903f4
[ 30.646388] ffc0: fda1c800 01e30b08 017b 01e5c418
0057f1dc 01e5d0c8
[ 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 & 0x, ramAddress >> 16,
[index], size, VENDORCMD_TIMEOUT);
if (ret != size) {
ret = (ret < 0) ? ret : -EIO;
dev_err(>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 = >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(>dev, "%s\n", __func__);
ret = request_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(>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 & 0x),
(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,
Re: which "make" target simply builds the scripts/dtc/dtc executable?
On Sat, 14 Mar 2020, Stefan Wahren wrote: > Hi, > > Am 13.03.20 um 19:13 schrieb rpj...@crashcourse.ca: > > colleague has a kernel-compile infrastructure which builds the > > kernel just fine, but croaks trying to compile .dts files, complaining > > that there is no "./scripts/dtc/dtc" file. > > > > ok, so that sounds like whatever it is that compiles dtc.c (and > > friends) into dtc is being omitted. i just want to test whatever > > make target would normally compile that, but i'm having trouble > > figuring which make processing does that. > > > > is there a top-level target that wanders into scripts/dtc, and > > compiles that? > > for a ARM target you could try to (PowerPC or MIPS should work too) > > export ARCH=arm > make mxs_defconfig # random arm defconfig > make dtbs > > this should build the devicetree compiler and the devicetree sources, > but AFAIK newer kernel versions uses the dtc from the Host system. So > it's possible that the dtc is omitted. ah, i had completely missed that newer kernels use the host dtc. rday___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
