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
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.
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
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
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...
Regards,
/Pete
Reply to: