On Mon, Dec 21, 2015 at 06:44:18PM +, edward wandasiewicz wrote:
> With 47-g977a7d4, we get
>
> 1. YES - we get no duplicate of the Philips, and get just one of each
> appear in the boot list, Mushkin & Philips
>
> 2. NO - we sometimes get just the Mushkin only - no Philips detected -
> with
With 47-g977a7d4, we get
1. YES - we get no duplicate of the Philips, and get just one of each
appear in the boot list, Mushkin & Philips
2. NO - we sometimes get just the Mushkin only - no Philips detected -
with both devices plugged in, about 1 in 10 cold boot starts - both
plugged in USB 3
FYI, the current testing branch (commit 977a7d4) has issues booting
Windows 10 via USB / Windows installer media on a Haswell ChromeBox
(XHCI only), locks up on the Windows logo. Tag 1.9.0 (commit 01a84be)
has no such issues. Will re-test with upstream master and report back
On 12/21/2015
On 12/21/2015 5:02 PM, Kevin O'Connor wrote:
On Mon, Dec 21, 2015 at 04:53:24PM -0600, Matt DeVillier wrote:
FYI, the current testing branch (commit 977a7d4) has issues booting Windows
10 via USB / Windows installer media on a Haswell ChromeBox (XHCI only),
locks up on the Windows logo. Tag
On Sun, Dec 20, 2015 at 08:23:40PM +, John Lewis wrote:
> >
> >Thanks, but the "badboot" log doesn't seem to show the failure.
> >
>
> Apologies, not thinking again. How about that one?
Okay - looks like you don't have the high/super confusion, but do need
the wait for port enable. I
On 2015-12-20 21:03, Kevin O'Connor wrote:
On Sun, Dec 20, 2015 at 08:23:40PM +, John Lewis wrote:
>
>Thanks, but the "badboot" log doesn't seem to show the failure.
>
Apologies, not thinking again. How about that one?
Okay - looks like you don't have the high/super confusion, but do
As requested, for rel-1.9.0-46-g636cbb4.
Is it worth testing the double scenario, or maybe put it down to a
"manufacturer's flaw" going forward?
Edward.
On Sun, Dec 20, 2015 at 9:03 PM, Kevin O'Connor wrote:
> On Sun, Dec 20, 2015 at 08:23:40PM +, John Lewis wrote:
>> >
On Sat, Dec 19, 2015 at 05:20:08PM +, John Lewis wrote:
> How quickly do you think you'll upstream these changes, Kevin? - they make a
> USB 3.0 M2 SSD enclosure I've just bought, work, on the USB 3.0 port,
> whereas it will only work with the USB 2.0 on upstream.
Which version works,
On 2015-12-20 07:59, Kevin O'Connor wrote:
On Sat, Dec 19, 2015 at 05:20:08PM +, John Lewis wrote:
How quickly do you think you'll upstream these changes, Kevin? - they
make a
USB 3.0 M2 SSD enclosure I've just bought, work, on the USB 3.0 port,
whereas it will only work with the USB 2.0
On Sun, Dec 20, 2015 at 07:43:19PM +, John Lewis wrote:
> On 2015-12-20 07:59, Kevin O'Connor wrote:
> >On Sat, Dec 19, 2015 at 05:20:08PM +, John Lewis wrote:
> >>How quickly do you think you'll upstream these changes, Kevin? - they
> >>make a
> >>USB 3.0 M2 SSD enclosure I've just
Thanks, but the "badboot" log doesn't seem to show the failure.
Apologies, not thinking again. How about that one?
Also, I note the enclosure gets lower boot priority than the onboard
SSD
when on the USB 3.0 port, but not when on the USB 2.0 port. Do I need
to do
something to the
On Sat, Dec 19, 2015 at 2:12 AM, Kevin O'Connor wrote:
> On Sat, Dec 19, 2015 at 01:49:04AM +, edward wandasiewicz wrote:
>> Is it a technically a manufacturer messing up the USB spec definitions it
>> should be following?
>
> That's a great question, and I don't know the
How quickly do you think you'll upstream these changes, Kevin? - they
make a USB 3.0 M2 SSD enclosure I've just bought, work, on the USB 3.0
port, whereas it will only work with the USB 2.0 on upstream.
John.
On 2015-12-18 22:54, Kevin O'Connor wrote:
On Fri, Dec 18, 2015 at 11:51:16AM
I managed to replicate a scenario 2 but with Type-C instead of USB 3,
with both 42-g9c58583 and 43-g55de21d
2(b) NO - Type C & Type C - once each (Philips & Muskin) - but double
Philips showing
cbmem.yes.both.TypeC.TypeC.DoublePhilips.42-g9c58583
On Fri, Dec 18, 2015 at 11:51:16AM +, edward wandasiewicz wrote:
> I managed to replicate a scenario 2 but with Type-C instead of USB 3,
> with both 42-g9c58583 and 43-g55de21d
>
> 2(b) NO - Type C & Type C - once each (Philips & Muskin) - but double
> Philips showing
>
>
Wrong file. Correct file attached. I checked for rel-1.9.0-45-gec65068
Edward.
On Fri, Dec 18, 2015 at 6:40 PM, edward wandasiewicz <0.w3...@gmail.com> wrote:
> Done.
>
> On Fri, Dec 18, 2015 at 6:25 PM, Kevin O'Connor wrote:
>> On Fri, Dec 18, 2015 at 06:11:56PM +,
-- Forwarded message --
From: "edward wandasiewicz" <0.w3...@gmail.com>
Date: 18 Dec 2015 6:11 p.m.
Subject: Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
To: "Kevin O'Connor" <ke...@koconnor.net>
Cc:
As requested.
Edward.
On Fri, Dec 18, 2015 at 06:11:56PM +, edward wandasiewicz wrote:
> As requested.
Thanks, but I had an off-by-one error in the patch - can you do the
same thing with 45-gec65068?
-Kevin
___
SeaBIOS mailing list
SeaBIOS@seabios.org
As requested.
Edward.
On Fri, Dec 18, 2015 at 8:02 PM, Kevin O'Connor wrote:
> On Fri, Dec 18, 2015 at 07:08:24PM +, edward wandasiewicz wrote:
>> Wrong file. Correct file attached. I checked for rel-1.9.0-45-gec65068
>
> Thanks, can you retry with 46-g0cc3233 ?
>
>
On Fri, Dec 18, 2015 at 07:08:24PM +, edward wandasiewicz wrote:
> Wrong file. Correct file attached. I checked for rel-1.9.0-45-gec65068
Thanks, can you retry with 46-g0cc3233 ?
-Kevin
___
SeaBIOS mailing list
SeaBIOS@seabios.org
On Sat, Dec 19, 2015 at 12:52:15AM +0100, Peter Stuge wrote:
> Kevin O'Connor wrote:
> > > Would checking the connection status for each device after all
> > > devices have been registered be able to filter the USB2 device out?
> >
> > Yes, but there isn't a way to "unregister" the drive once
Kevin O'Connor wrote:
> > Doesn't it effectively take the same amount of wall clock time?
..
> If you're asking if current state vs unregistering/delaying would take
> the same wall time - thinking about that now, it might be true.
Right - that's what I meant. I think it will, because ..
> I
-- Forwarded message --
From: "edward wandasiewicz" <0.w3...@gmail.com>
Date: 19 Dec 2015 1:44 a.m.
Subject: Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
To: "Kevin O'Connor" <ke...@koconnor.net>
Cc:
Is it a technically a manu
On Sat, Dec 19, 2015 at 01:51:15AM +0100, Peter Stuge wrote:
> Kevin O'Connor wrote:
> > > Doesn't it effectively take the same amount of wall clock time?
> ..
> > If you're asking if current state vs unregistering/delaying would take
> > the same wall time - thinking about that now, it might be
-- Forwarded message --
From: "edward wandasiewicz" <0.w3...@gmail.com>
Date: 19 Dec 2015 1:44 a.m.
Subject: Re: [SeaBIOS] SeaBIOS recognising USB 3.0 on boot works - partly
To: "Kevin O'Connor" <ke...@koconnor.net>
Cc:
Is it a technically a manu
Kevin O'Connor wrote:
> Once the device is recognized as USB3, the controller disconnects
> it from USB2, but by that point SeaBIOS has already fully registered
> it and isn't even checking the connection status. The device is
> then fully detected as a USB3 device, which is why the duplicate
>
On Sat, Dec 19, 2015 at 12:11:59AM +0100, Peter Stuge wrote:
> Kevin O'Connor wrote:
> > Once the device is recognized as USB3, the controller disconnects
> > it from USB2, but by that point SeaBIOS has already fully registered
> > it and isn't even checking the connection status. The device is
>
Kevin O'Connor wrote:
> > Would checking the connection status for each device after all
> > devices have been registered be able to filter the USB2 device out?
>
> Yes, but there isn't a way to "unregister" the drive once it's been
> registered.
Oh - why not?
If this has to do with e.g. BBS
On Sat, Dec 19, 2015 at 01:11:34AM +0100, Peter Stuge wrote:
> Kevin O'Connor wrote:
> > > > > Would checking the connection status for each device after all
> > > > > devices have been registered be able to filter the USB2 device out?
> > > >
> > > > Yes, but there isn't a way to "unregister"
On Fri, Dec 18, 2015 at 08:12:22PM +, edward wandasiewicz wrote:
> As requested.
Thanks. It appears this particular device is being fully detected as
a USB2 device (connection is detected, address is assigned, drive
configuration is downloaded, and the drive is registered internally)
before
On Fri, Dec 18, 2015 at 11:51:16AM +, edward wandasiewicz wrote:
> I thought, lets try swapping over the devices, but keeping the same
> Type-C cables on the left and right hand side and see what happens.
>
> I get scenario 5.
>
> 5. NO - Type C & Type C - one Philiips & no Mushkin
>
>
On Sat, Dec 19, 2015 at 01:49:04AM +, edward wandasiewicz wrote:
> Is it a technically a manufacturer messing up the USB spec definitions it
> should be following?
That's a great question, and I don't know the answer to it. It would
be great if there was some guidance in the USB3 spec to
On Mon, Dec 14, 2015 at 07:02:14PM -0500, Kevin O'Connor wrote:
> The double detection looks like the controller doing something weird.
> I need to look closer at the spec, but I don't think I'll be able to
> do that until later in the week.
After reviewing the spec I have a guess to what is
On Sun, Dec 13, 2015 at 09:16:02PM +, edward wandasiewicz wrote:
> On Sun, Dec 13, 2015 at 9:05 PM, edward wandasiewicz <0.w3...@gmail.com>
> wrote:
> > Hooray, it works... minus 2 scenarios :(
> >
> > With both Philips USB and Mushkin USB attached, and I perform a cold boot
> >
> > 1. YES -
On 12/14/2015 6:02 PM, Kevin O'Connor wrote:
On Sun, Dec 13, 2015 at 09:16:02PM +, edward wandasiewicz wrote:
On Sun, Dec 13, 2015 at 9:05 PM, edward wandasiewicz <0.w3...@gmail.com> wrote:
When I do, I will post output.
When attempting a cold boot - shutdown - cold boot - shutdown -
On Sun, Dec 13, 2015 at 10:49:30AM +, edward wandasiewicz wrote:
> With both the Philips USB and Mushkin USB plugged in on boot, I'm
> still getting 4 different scenarios appearing.
>
> 1. Philips Only
> 2. Mushkin Only
> 3. Both recognised - listed once and once only
> 4. Both recognised -
Hooray, it works... minus 2 scenarios :(
With both Philips USB and Mushkin USB attached, and I perform a cold boot
1. YES - USB 3 & USB 3 - once each (Philips & Mushkin)
cbmem.yes.both.USB3.USB3.gz
2. NO - USB 3 & USB 3 - once each (Philips & Muskin) - but double
Philips showing
On Fri, Dec 04, 2015 at 09:04:35PM +, edward wandasiewicz wrote:
> Here's what happens with x1 Philips USB attached and x1 Mushkin
> attached, and we cold boot with Kevin's patched SeaBIOS
>
> FIXED - when Philips drive is detected, it appears only once and once
> only in the list of bootable
@ John
Is the work on SeaVGABIOS for CBFS work under construction for the
Broadwell based Pixel 2015?
Looking at Kevin's chromeimage.sh - showing relevant parts only
CBFSTOOL=cbfstool
PAYLOAD=out/bios.bin.elf
PAYLOADVGA=out/vgabios.bin
#
# Build new seabios CBFS image.
#
CBFSFILE=seabios.cbfs
On Fri, Dec 04, 2015 at 05:50:29PM +, edward wandasiewicz wrote:
> Looking at the output from Googles ChromeOS shell-ball, I do:
>
> Write the hardware ID to get future ChromeOS updates
>
> $ ./gbb_utility --set --hwid="SAMUS XXX-YYY-ZZZ" bios.bin bios.hwid.bin
>
> # dd out 2 megs of the
On 4 Dec 2015 7:04 p.m., "Kevin O'Connor" wrote:
>
> On Fri, Dec 04, 2015 at 06:36:18PM +, edward wandasiewicz wrote:
> > @ John
> >
> > Is the work on SeaVGABIOS for CBFS work under construction for the
> > Broadwell based Pixel 2015?
> >
> > Looking at Kevin's
On Fri, Dec 04, 2015 at 07:08:50PM +, edward wandasiewicz wrote:
> On 4 Dec 2015 7:04 p.m., "Kevin O'Connor" wrote:
> >
> > On Fri, Dec 04, 2015 at 06:36:18PM +, edward wandasiewicz wrote:
> > > @ John
> > >
> > > Is the work on SeaVGABIOS for CBFS work under
On Fri, Dec 04, 2015 at 06:36:18PM +, edward wandasiewicz wrote:
> @ John
>
> Is the work on SeaVGABIOS for CBFS work under construction for the
> Broadwell based Pixel 2015?
>
> Looking at Kevin's chromeimage.sh - showing relevant parts only
>
> CBFSTOOL=cbfstool
> PAYLOAD=out/bios.bin.elf
On Mon, Nov 30, 2015 at 07:04:55PM +, edward wandasiewicz wrote:
> On 30 Nov 2015 5:35 p.m., "Kevin O'Connor" wrote:
> > Looks like two separate issues are occurring - the Philips drive is
> > being detected as both a high speed device and as a super speed
> > device. I
Booting with 1 x Phillips USB and 1 x Ventura Ultra attached to the Pixel 2015
I've attached the cbmem -c from Pixel Samus, after a cold boot into
Arch Linux and also following a reboot immediately after.
After a reboot, following a boot, the Philips USB now only appears
just the once, and not
On Mon, Nov 30, 2015 at 03:22:38PM +, edward wandasiewicz wrote:
> Booting with 1 x Phillips USB and 1 x Ventura Ultra attached to the Pixel 2015
>
> I've attached the cbmem -c from Pixel Samus, after a cold boot into
> Arch Linux and also following a reboot immediately after.
>
> After a
On 30 Nov 2015 5:35 p.m., "Kevin O'Connor" wrote:
>
> On Mon, Nov 30, 2015 at 04:47:29PM +, edward wandasiewicz wrote:
> > I started over, as I forgot which device was in which port.
> >
> > It seem's like a race condition, as I managed to get a USB device
> > detected
On Mon, Nov 30, 2015 at 04:47:29PM +, edward wandasiewicz wrote:
> I started over, as I forgot which device was in which port.
>
> It seem's like a race condition, as I managed to get a USB device
> detected twice with JohnLewis RW_LEGACY as well now, although it
> doesn't happen very
Running SeaBIOS on a Chromebook Pixel 2015, by default, does not
recognise a plugged in USB 3.0 device attached to a USB 3.0 port or
Type C port.
As of 28 Nov, I ran ./flash_chromebook_rom.sh
from
https://johnlewis.ie/custom-chromebook-firmware/rom-download/
to get Johns most current SeaBIOS
49 matches
Mail list logo