[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: isorecorder

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.

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
[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,
[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.

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):


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...

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.

Is the firmware assuming a specific offset for the beginning of the

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...



Reply to: