[ Dropping CC to Lou as we've wandered, but re-adding Thomas for the GPT question. ]
On Wed, Jan 13, 2021 at 08:16:39PM +0000, Pete Batard wrote: >On 2021.01.13 18:49, Steve McIntyre wrote: >> I've never seen a UAS device here yet, let alone tested with one. :-) > >They've existed for quite a few years. > >I think currently have about 4 of those in my arsenal, with the first one >purchased more than 6 or 7 years ago. ACK. >> So it's not quite such a surprise that there might be problems there. >> >> > I'm still planning to look more closely into this when I get a chance, and >> > create a new bug (unless someone beats me to it), but if you have a UAS >> > device lying around, you should be able to replicate the issue with the >> > current Bullseye installation ISOs, including amd64 ones, as I confirmed >> > that >> > the problem was (still) present in the latest netinst testing amd64 ISOs. >> > >> > FYI, the USB subsystem should tell you if a device is UAS with something >> > like >> > this (from dmesg): >> > >> > [549114.637578] usb 8-1: new SuperSpeed Gen 1 USB device number 19 using >> > xhci-hcd >> > [549114.658815] usb 8-1: New USB device found, idVendor=174c, >> > idProduct=55aa, >> > bcdDevice= 1.00 >> > [549114.658837] usb 8-1: New USB device strings: Mfr=2, Product=3, >> > SerialNumber=1 >> > [549114.658852] usb 8-1: Product: Ventura Ultra >> > [549114.658867] usb 8-1: Manufacturer: Mushkin >> > [549114.658881] usb 8-1: SerialNumber: 000000000025 >> > [549114.666050] scsi host0: uas >> > [549114.668168] scsi 0:0:0:0: Direct-Access Mushkin Ventura Ultra 0 >> > PQ: 0 ANSI: 6 >> >> ACK. I'm just looking for one to buy right now so I can test with >> it. I can't see anybody selling the Mushkin drive you show here, which >> is not helpful. > >Yeah, that Mushkin device is definitely something I've had for more than 5 >years, and that I don't expect to be sold any longer. And most regular flash >drives would not be UAS. Yes, that's what I've found. >> Silly question - do you have any suggestions for a >> make/model to look for at all please? Google searches are basucally >> useless here for finding that level of detail on USB flash drives. :-( > >OK. One thing you may want to check first, if you have any lying around, are >USB <-> SATA or USB <-> NVMe adapters, because these frequently turn to be >UAS. > >For instance, the following USB <-> SATA "enclosure", that I purchased more >than 5 years ago, is UAS: >https://archive.plugable.com/products/usb3-sata-uasp1/ (it even says so in >the link). > >I don't think they are sold brand new any more, but you might be able to find >one of those off e-bay. > >Or, for something more recent and perhaps more convenient to get, the >following USB <-> NVMe enclosure is also UAS (at least for the "NVME - >10Gbps" version, which is what I have): > >https://www.aliexpress.com/item/1005001742426847.html Right. I've found and ordered a Startech USB3S2SAT3CB which looks useful. I've got a couple of small spare SSDs that I can use that with. I was hoping to find a source for reasonably-priced USB-UAS flash drives but the only one I can see off-hand is the "Corsair Voyager GTX", e.g. at https://www.scan.co.uk/products/128gb-corsair-flash-voyager-gtx-usb-31-gen-1-type-a-pendrive-black-460mb-s-read-460mb-s-write-33k-40 >Obviously, these last two devices require an additional NVMe or SATA disk to >be usable. But I'd say USB <-> NVMe adapters are likely to become more and >more widespread especially as can solve the problems of using something a bit >more reliable and faster (as well as much better with random I/O) than >regular flash drives, even more so on platforms that have USB 3.x but no >NVMe. > >Plus I can certainly see people wanting to use the "extract all the Debian >installation files into an ESP" procedure on regular x86 UEFI PCs, using a >USB SSD (especially now that USB speeds are starting to catch up with NVMe), >in which case there's a good chance their installation media will be UAS... Right. Now I know it's a problem, I can have a look. <pi 4> >> Sigh, OK. Firmware that doesn't deal flexibly with partitioning, >> i.e. by reading/parsing the partition table properly. I thought we'd >> be past that by now. :-( > >Three words: cheapest platform possible. > >That's what the Pi Foundation are pursuing, and thus, by transitive property, >Broadcom, since that's who the Foundation chose as their supplier. As a >result you're being met with tons of limitations or quirks (such as a >poor/buggy PCIe DMA implementation of the SoC, limited mask ROM space that's >likely to result in major trade-offs, and, recently in order to save another >few more cents on the platform, the complete removal of the xHCI controller >EEPROM that existed in the initial Pi 4 models, which means that, if you >happen to reset xHCI, you must now take care of loading its firmware data >back in RAM). > >My understanding is that SoC mask ROM is designed to look only at the first >FAT partition to load its boot files, and that we can actually count >ourselves lucky that the Pi 4 SoC can handle GPT as well as ESPs, as the mask >ROM from the SoC on Pi 3 and earlier models could only handle MBR and >partition types of 0xc/0xe (and not 0xef)... > >But of course, the counterpoint of that is that the price point of the Pi >continues to make it one of the most popular platforms out there. Nod, cheap always wins. :-( >> Is the firmware assuming a specific offset for the beginning of the >> ESP? > >Not that I can tell. I've tested with different offsets and I'm also not >aware of a specific value at which the first partition is expected to start. > >> Or will it deal with GPT, > >It deals with a GPT, but it'll look no further than the first partition. > >I'm pretty sure the current code (which should mostly be part of the mask >EEPROM of the SoC) does something like this: > >1. Find the offset of the first partition, be it either MBR or GPT. >2. *Always assume* that it's FAT16/FAT32 and see if trying to load the >platform files works. > >But, of course, all of this is closed source and coming from a chip >manufacturer that seems very tight lipped about anything that pertains to >their hardware. So it's hard to tell for sure... Oh, sure. You clearly have *some* experience here, hence the question. :-) @Thomas: This may seem like a silly question, I know, but... For the sake of this kind of use-case, is it sensible when driving xorriso to tweak the created partition table to list the ESP as partition 1? At the moment we're just using "-append_partition 2 0xef /path/to/ESP.img", would just changing that to be partition 1 instead work? As we're already starting to add more things (e.g. DTBs) into the media ESP, we could also add support for including (evil!! non-free!!) boot firmware etc. there too for platforms that need it. -- Steve McIntyre, Cambridge, UK. [email protected] "I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell." -- Linus Torvalds
