Re: isorecorder
[ 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. steve@einval.com
"I suspect most samba developers are already technically insane... Of
course, since many of them are Australians, you can't tell." -- Linus Torvalds
Reply to: