On 09/28/2018 11:30 AM, Patrick DELAUNAY wrote: > Hi, Hi,
>> From: Marek Vasut <ma...@denx.de> >> >> On 09/26/2018 01:04 PM, Patrick Delaunay wrote: >>> solve data abort for the command "ums 0 ubi 0" >>> because result of case blk_get_device_part_str() result is OK but with >>> block_dev = 0 when CONFIG_CMD_UBIFS is activate and ubi volume is >>> mounted >> >> I don't quite understand the commit message, can you reword it? > > Ok, I prepare a V3 Sending a V3 while discussion is ongoing is pointless. >> Also, when is this ever called with block_dev == NULL ? What's the condition >> to >> trigger this and why ? > > To reproduce the issue you need to have a ubifs already mounted, > for example with the command: > ubi part UBI > ubifsmount ubi0:boot > > I investigate the point, the call stack before the crash is caused by the > ubi support in > ./disk/part.c:425 = blk_get_device_part_str() > > Some part of code here are under CONFIG_CMD_UBIFS with the comment : > "ubi goes through a mtd, rathen then through a regular block device" > > So the the function return a pointer to disk_partition_t : > info->type = BOOT_PART_TYPE > info->name = "UBI" > but without block device information ! > *dev_desc = NULL Would it rather make sense to fix it here , so it has a valid dev_desc ? > So the issue occurs because, when the ubifs volume is mounted, > The code in cmd/usb_mass_storage.c [...] -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
