Что такое usb s3 wake up

USB S3 Wake-up что это в биосе? (Samsung)

Привет USB S3 Wake-up — опция BIOS, которая позволяет включать компьютер при помощи мышки или клавиатуры. Но если быть точнее, то не включать, а как бы выходить из спящего режима. Или из ждущего, здесь уже зависит от настроек материнской платы. Данные режимы также называются как энергосберегательные и имеют обозначения S1 (Power on Suspend), S2, S3 (Suspend to RAM или STR), S4 (Hibernation, Safe Sleep), S5 (Software Shutdown)

Как правило опция имеет два положения — Enable и Disable, что переводится как Вкл и Выкл.

Данная настройка осуществляется поддержкой ACPI (Advanced Configuration and Power Interface) — спецификация, определяющая механизмы взаимодействия операционной системы и аппаратного обеспечения для управления электропитанием. Настройка может присутствовать в разделе Power Management Setup (зависит от материнки).

Некоторые материнские платы поддерживают технологию пробуждения USB-устройствами ввода, если они подсоединены к определенным портам. Стоит уточнить в руководстве к материнской плате или на официальном сайте производителя.

Дополнительно

Учтите, что если вы будете часто переводить компьютер в ждущий или спящий режим, то это негативно сказывается на сроке службы жесткого диска. Впрочем это относится и к выключения компьютера. 1-2 раза за сутки считается нормой. Больше — лучше оставить компьютер в работе, чем выключать/переводить в спящий режим. Да, кажется что сомнительно все это, в интернете давно ведутся на эту тему, можете проверить, если не верите.

Ноутбук самсунг не стартует Windows с флешки. Помог только диск.

Сегодня мы рассмотрим интересный случай с ноутбуком Samsung NP 300 при переустановке Windows с флэшки.

Включаем ноутбук и заходим в BIOS, нажимая клавишу F2. В меню мы проверяем, чтобы все параметры были установлены верно.

Во вкладке «Advanced», для пункта «USB S3 Wake-up» установлен параметр «Disabled».

Во вкладке «Boot», для пункта «UEFI Boot Support» также установлен параметр «Disabled».

И в «Boot Device Priority» наша флэшка стоит на первом месте.

То есть, все настройки в порядке. Выходим с сохранением на вкладке «Exit» («Exit Saving Changes), и перезагружается ноутбук. По идее должна начаться загрузка с флэшки, но до того как была удалена Windows с диск С:, то ноутбук грузил ее.

Теперь он при загрузке зависает и выдает следующее окно:

В окне говорится, что компьютер не нашел никаких операционных систем на ноутбуке и предлагает установить диск с Windows.

Это значит, что ноутбук пытается загрузиться с жесткого диска, хотя флэшка подключена и видно, что она считывается и на нее поступает питание (горит лампочка на флэшке).

При попытке установки с диска, все проходит успешно.

Произведем сброс настроек до заводских. Для этого включаем ноутбук и жмем F2. Переходим во вкладку «Exit» и выбираем пункт «Load Setup Defaults», два раза Enter и выходим с сохранением изменений.

При перезагрузке ноутбук снова зависает. Выключаем и снова включаем, снова заходим в BIOS (клавиша F2) и если перейдем в «Boot Device Priority» на вкладке «Boot», то увидим, что ноутбук нашу флэшку не видит.

Перезагружаем, но ничего не изменилось. Поэтому переходим во вкладку «Advanced» и меняем значение «Fast BIOS Mode» на «Disabled». Выходим с сохранением.

Снова перезагружаемся, идем в «Boot Device Priority» и видим, что появилась наша флэшка. Клавишей F6 подымаем ее на первое место. Делаем выход с сохранением.

Снова черный экран с мигающим курсором в верхнем левом углу и через 5 сек ноутбук выключится.

Была попытка, загрузки Windows со специальной флэшки в UEFI режиме. И все прошло успешно, но после выбора пункта установка Windows все снова зависло.

Поэтому, приступили к установке с диска. Для этого в «Boot Device Priority» ставим наш DVD привод на первое место.

Выходим с сохранением, происходит перезагрузка и начинается успешная загрузка Windows с диска. Следуем инструкциям и устанавливаем операционную систему.

Проблема при загрузке с флэшки, скорее всего, кроется в неполадках BIOS. Возможно, его пере прошивка поможет.

Usb s3 wake up что это

USB S3 Wake-Up что это и для чего нужно

Если зайти в настройки BIOS на вкладку управления питанием (Power Managment), то там можно встретить параметр USB S3 Wake-Up. Причем после буквы S может стоять цифра от 1 до 5. Имеются два доступных значения – Enabled (Включена) и Disabled (Выключена). О том, что включает и выключает этот параметр мы и поговорим в данной статье.

Назначение

Те, кто знаком с английским языком наверняка обратил внимание на слово Wake-Up в названии. Переводится оно, как пробуждение. USB в данном контексте имеется ввиду как устройства подключенные к USB портам, а S3 – это класс режима энергосбережения (S1 – S5).

В таком виде чаще всего эта настройка встречается на ноутбуках Samsung, но стоит отметить, что в зависимости от версии BIOS и модели материнской платы возможны другие варианты названий, например:

Wake Up By USB device;
USB Wake Up From S3;
USB Resume From S3/S4;
USB Device Wakeup From S3/S4;
Resume by USB From S3.

Если USB S3 Wake-Up включена (Enabled), то это значит, что при переводе компьютера (ноутбука) в режим энергосбережения (спящий режим) вывести его оттуда (пробудить) можно нажатием клавиши на клавиатуре или мышке при условии что они подключены через USB.

вывод компьютера из ждущего режима мышкой или клавиатурой

Варианты значений для usb-s3-wake-up

Перевод данной настройки в состояние Disabled отключает возможность вывода компьютера из сна устройствами, подключенными через USB. В этом случае пробуждение возможно только нажатием на кнопку включения.

Вывод

Опция USB S3 Wake-Up в BIOS относится к классу настроек управления питанием. Отвечает она за возможность пробуждения компьютера, находящегося в спящем режиме, клавишами на устройствах ввода, которые подключены через разъем USB.

Включать ее или нет каждый решает сам для себя, но в любом случае вывести ПК из режима сна можно нажатием на кнопку включения.

ACPI wakeup

Здравствуйте! Я пытаюсь организовать пробуждение системы из состояния S3 от USB клавиатуры.

После загрузки ОС команда «cat /proc/acpi/wakeup» выдает:

Device S-state Status Sysfs node

PCI0 S5 disabled no-bus:pci0000:00

HDEF S4 disabled pci:0000:00:1b.0

RP01 S5 disabled pci:0000:00:1c.0

RP02 S5 disabled pci:0000:00:1c.1

RP03 S5 disabled pci:0000:00:1c.2

RP04 S5 disabled pci:0000:00:1c.3

RP05 S5 disabled pci:0000:00:1c.4

RP06 S5 disabled pci:0000:00:1c.5

USB1 S3 disabled pci:0000:00:1d.0

USB2 S3 disabled pci:0000:00:1d.1

USB3 S3 disabled pci:0000:00:1d.2

USB4 S3 disabled pci:0000:00:1d.3

EHC1 S3 disabled pci:0000:00:1d.7

MODM S4 disabled

COMA S3 disabled pnp:00:08

COMB S3 disabled pnp:00:09

Насколько я понимаю, представленные устройства в таблице это устройства из таблицы DSDT, для которых существует метод _PRW. Однако почему-то wakeup для них по умолчанию выключен.

Включить wakeup для клавиатуры (в данном случае для меня это USB1) можно с помощью команд:

echo PCI0 > /proc/acpi/wakeup

echo USB1 > /proc/acpi/wakeup

Судя по всему эти команды говорят ОС о том, что при входе в S3, нужно модифицировать соответcтвующие биты в регистре ACPI GPE0_EN (о том какие именно биты, можно видеть из соответствующего метода _PRW устройства)

Однако этим дело не заканчивается. ОС при входе в S3 отводит питание от USB. Чтобы это исправить находим из dmesg номер USB в системе

[ 2.724374] input: LITEON Technology USB Multimedia Keyboard as /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0/input/input6

и выполняем команду «echo enabled > /sys/bus/usb/devices/2-2/power/wakeup»

После этого wakeup от клавиатуры работает нормально.

А теперь вопрос, как нужно отредактировать DSDT, чтобы эти команды вбивать не пришлось? (вариант с вбиванием рассмотренных выше команд в автозагрузку не рассматривается)

USB 3.0 Power Management: Waking up from low-power states

This is summary of a few issues related to waking up from the U1, U2 or U3 low-power states on a SuperSpeed USB link, with emphasis on the details that need to be decided upon when implementing a USB device.

A similar discussion on invoking these low-power states can be found on this page. There is also a page with an broader view of power states.

Waking up from a low power state is essentially a simple procedure: The side requesting the wakeup (the “initiator”) starts transmitting a continuous LFPS signal, waits for the other side to acknowledge the wakeup request by transmitting an LFPS signal as well. When each side has detected the other side’s LFPS burst (subject to a minimal LFPS burst length), it turns on its Gigabit transceiver in Recovery state. Both sides reach Recovery, and move on to U0 just like after any transition to Recovery.

Timeouts

The USB 3.0 spec defines two timeouts related to exiting a low-power state:

tNoLFPSResponseTimeout, for successfully completing the LFPS handshake: How long time the initiator may wait for the other side to transmit an LFPS signal in response. It’s 2 ms for U1 and U2, 10 ms for U3.
Ux_EXIT_TIMER, for reaching the U0 (link active state): The total time from initiation to a proper link is up in U0 state. It’s 6 ms for U1 and U2, and not applied for U3. Note that this includes the LFPS handshake and the Recovery state. Note that plain Recovery from U0 (due to some link error) has a 12 ms timeout.

The port shall move to SS.Inactive state when any of these timeouts expire when waking up from U1 or U2. Timed out attempts to wake up from U3 are repeated in 100 ms intervals. These repeated attempts are stopped only if the reason for wakeup is disabled, or due to a physical disconnection between the link partner, in which case the ports enter the SS.Disabled state.

In large, the LFPS handshake is defined as successful (in section 6.9.2 of the USB 3.0 spec, which defines the handshake and its timing in general) if the handshake’s initiator detects its link partner’s LFPS signal within tNoLFPSResponseTimeout. The transition to Recovery isn’t included in the timeout period.

Another timing restriction on both sides is that the time gap between the end of LFPS and the Gigabit stream is maximum 20 ns.

Timing parameters

When implementing the power management module for a device, there are in fact only three timing parameters that need to be decided upon, separately for U1, U2 and U3:

When initiating a wakeup, the minimal length of the transmitted LFPS burst (i.e. when to move on to turning on the Gigabit transceiver, if an LFPS burst is sensed).
When responding to a wakeup LFPS burst, the length of the transmitted burst to issue before switching to the Gigabit transceiver)
The minimal length of a detected LFPS burst to be considered a wakeup request. In other words, how fast the detector needs to be. This may have influence on the complexity of the detection mechanism, in particular for the short bursts possibly used to wake up from U1.

Section 6.9.2 defines a significant number of timing restrictions in Table 6-22 for each of the low-power modes. This table is the reference in the following analysis of the these three items.

Item #1: Minimal initiating burst

It may seem odd that a minimal time for the initiating burst is defined at all: If the link partner responds with an LFPS, why not jump into the Gigabit phase immediately?

The purpose of this limit is to cover the case when both sides initiate a wakeup LFPS burst at the same time: Even though sensing the other side’s LFPS burst, both sides must continue transmitting the bursts long enough so the other side is guaranteed to detect it.

This time period is given as t12-t10 in Table 6-22: At least 0.6 μs for U1, and at least 80 μs for U2 and U3. Table 6-21 in the spec details (among others) the minimal burst transmitter times for all types of LFPS bursts. For the low power exit bursts, the same numbers are given.

One may wonder why there is a difference between the power states. After all, if the link partner already transmits an LFPS, surely it’s ready to detect one. The answer is (see note 6 to Table 6-21) that a port isn’t required to maintain its common-mode voltage on the differential wires when in U2 and U3. As a result, a certain time segment at the beginning of the LFPS signal may not be properly transmitted when coming out of these states. These 80 μs ensure that at least the end of the burst can be properly detected.

Hence 0.6 μs is sufficient when the LFPS transmitter was in for U1, even if the receiver might be in U2 due to automatic transition (this is what Note 2 under Table 6-22 says).

However be sure to read the “Changes in USB 3.1″ part below for a longer U1 burst.

Item #2: Time of responding burst

In a given designed system, this is just the time that the LFPS burst is generated before moving on to transmitting the Gigabit stream. It should be no longer than the minimum required by spec, as this ensures its detection by the link partner, so this would unnecessarily slow down the resumption to U0. And of course it can’t be shorter.

This time period is given as t13-t11 in Table 6-22: At least 0.6 μs for U1, and at least 80 μs for U2 and U3. It’s the same figures as for item #1, for the exact same reasons.

Once again, be sure to read the “Changes in USB 3.1″ part below for a longer U1 burst.

Item #3: Minimal burst time for detection (part I)

A quick detection of the LFPS signal is important for not wasting time on the handshake procedure. On the other hand, every electrical engineer knows the connection between a fast detector and false alarms.

Table 6-22 seems to suggest 0.3 μs as the minimal LFPS that must be detected, as this is the given minimal t11-t10. This parameter can’t be interpreted as a restriction (both ports may start transmitting their LFPS bursts at the same time, for example), it can only be interpreted as an expectation from the detector.

However in section 6.9.2’s discussion on both side starting their LFPS burst simultaneously, an LFPS burst of 0.6 μs is required to ensure the other side has detected it properly.

The difference is explained in note 7 of Table 6-21, stating that the receiver must detect a burst of 0.3 μs, but the transmission to must last 0.6 μs, with the extra 0.3 μs being a “guard band”. This is important in particular for a downstream facing port, which may need to distinguish between a U1 state’s Ping.LFPS signal of up to 200 ns, and a wakeup LFPS burst, possibly as short as 600 ns. There are plenty of hardware out there that doesn’t manage this correctly.

But what is the real minimum? Consider for example a USB device that never initiates any wakeup. Seemingly it only needs to detect initiating LFPS bursts from its link partner. And since the initiating LFPS burst continues until the handshake is completed, can’t the detection be slow enough just to keep the handshake below tNoLFPSResponseTimeout? That’s at least 2 ms, a completely different order of magnitude.

The answer is that a so-so designed USB device that only responds to wakeups can have a very slow LFPS detector indeed, but it may have practical reliability issues, because of insufficient handling of false wakeups. So before concluding the minimal burst time detection, a slight detour.

False wakeups

In a perfect world, the hardware’s LFPS detector works without producing any false alarms. Unfortunately, in some real-life Gigabit transceiver hardware, there are many possible sources for a false alarm:

The other side’s Gigabit transmission may cause spurious false LFPS signal detections. This is problematic in particular when receiving a Gigabit transmission a few microseconds after going into a low power state. Such false detection would cause an unnecessary wakeup immediately when entering the low power state.
The link partner’s shutdown of the Gigabit transceiver (and possibly the common-mode bias voltage) may generate spurious ringing on the wires that may be mistaken for an LFPS burst.
The link partner’s invocation of U2 or U3 states, which may involve turning off the common-mode voltage of the physical wires, can be detected as activity. In particular, an FPGA’s transceiver has been observed detecting the link partner’s U1 to U2 transition as an LFPS signal.
If the U1 to U2 transition is disabled, and the U1 state lasts longer than 200 ms, the LFPS.Ping keepalive signal from the the device may be misinterpreted as a wakeup LFPS burst, even though the former is 200 ns at most, and the minimal for a wakeup burst detection is 300 ns. Still, a fairly decent USB 3.0 hub (Genesys Logic 05e3:0626) has been observed to repeatedly wake up on 100 ns LFPS.Ping bursts.
Electromagnetic noise from the environment can cause momentary activity on the wires that can be mistaken for an LFPS signal. As a device may in a low power state for hours and days, this is a possibility to take into account even if the probability seems small.

If properly handled, a false wakeup is fairly harmless from the U1 or U2 states: The device starts its LFPS signal in response to the false signal, but the link partner considers this a wakeup request, and responds with a real LFPS signal. Eventually, both sides start their Gigabit transceivers, invoke Recovery and U0. A short while later, the link should go back to a low power state due to lack of activity but not all hardware does that (for example, Intel’s 8086:a12f USB controller does this, but Renesas’ 1912:0015 waits in U0 until there’s traffic, and only then acts on link inactivity). The worst case scenario is probably energy wasted on a link that is held in U0 for no reason.

False wakeups from U3 is a different story however: They can power up a computer from a suspended state. On the other hand, the timing requirements are much easier, so the detection of LFPS signals from U3 can be made very safely.

Item #3: Minimal burst time for detection (part II: Conclusion)

The false wakeup scenario boils down to a reversal of roles: The port that falsely detected the LFPS signal thinks it responds to a wakeup request, but it’s actually initiating one. The link partner indeed responds to a wakeup request. This reversal is pretty harmless from U1 and U2 states if both sides receive LFPS bursts that are long enough for their detection.

Recall from items #1 and #2 above, that the burst time for responding to wakeup request is the same as the minimal time for the initiating LFPS burst. Hence it’s guaranteed that the link partner detects the burst that is transmitted as a response, but is actually an initiation.

So back to minimal detection time. The relevant scenario is that the opposite port has falsely detected an LFPS bursts, and now responds with an LFPS bursts that it considers a response.

To cope with this, any port must be able to detect an LFPS burst that is transmitted as a response. The minimal length of which is given as t13-t11 in Table 6-22: 0.6 μs for U1, and at least 80 μs for U2 and U3. Note that these power state relate to the link partner, so if the U1-to-U2 inactivity timer is enabled, it’s the link partner’s power state that needs to be taken into consideration.

So all in all, it boils down to a detection of a 0.6 μs burst for U1 and U2, even if it’s never going to initiate any wakeup requests. But recall the requirement in note 7 of Table 6-21, requiring 0.3 μs, so the latter is the preferred value. If the link partner is known to be in U2 (e.g. due to a direct transition from U0 to U2), 80 μs is fine as well, but this may include a time segment for which the LFPS isn’t properly transmitted. So there’s no need to push as low as 0.3 μs, but surely not 80 μs either.

As for U3, maybe as much as 1 ms for detecting initiations. Waking up a computer from suspend because of a falsely detected LFPS is really bad, and if the computer made such false detection, it might as well ditch the port the port that caused this.

Response time

As the LFPS detector must detect the LFPS signal 80 μs after the beginning of its transmission in the worst case, one may wonder why the timeout for the handshake is 2 ms. This isn’t discussed in the spec, but presumably the reason is that the control of the LFPS and Gigabit transmitter may be in the hand of software, which may add latencies.

Table 6-22, and its footnotes in particular, address this issue in particular for the case of waking up from U1 when the U2 Inactivity Timer is disabled, referring to a set with “short timing requirement”. This means that both ports are known to be in U1 (the timeout mechanism for slipping down to U2 is disabled).

In this case, two extra restrictions are added:

The responding port must start its LFPS burst no later than 0.9 μs after the initiating port starter its burst (t11 — t10 < 0.9 μs).
Both ports are required to turn on their Gigabit transceivers no later than 0.9 μs after the responding LFPS burst begins (t12 — t11 < 0.9 μs and t13 — t11 < 0.9 μs).

Recall that the conclusion from the analysis for U1 was the detector should detect a burst after 0.3 μs, so extra delays aside, t11 — t10 = 0.3 μs.

Also, based on the conclusions above, the LFPS burst length on both sides will be 0.6 μs: The responding burst starts 0.3 μs after the initiator’s, and then it takes 0.3 μs for the initiator to detect the responding burst. So 0.6 μs after the initiator began transmitting its burst, it has detected the responding burst, and switches Gigabit transmission after the minimal time for the LFPS burst. So this gives t12 — t11 = 0.3 μs and t13 — t11 = 0.6 μs.

So if there are no extra delays, these 0.9 μs limits are met easily. In an FPGA / ASIC design, the delay from a detection to action is typically a few tens of nanoseconds, so there’s no problem there. If the control is implemented in software, it might be a problem. Even an interrupt handler can be delayed by several microseconds.

So what happens if the 0.9 μs timing requirements aren’t met? The spec doesn’t say, but the answer is most likely nothing, except for the added latency. So if a device’s power state is controlled by software, and these requirements aren’t met, it’s unlikely that any problems will arise, in particular as the device is aware of the latencies it imposes.

Apparently, these requirements are intended for hubs and the USB controllers in computers, so that devices that are attached to them can rely on a quick wakeup from U1 if needed. As these are always implemented as logic in a chip, these restrictions make perfect sense.

And a practical note: This “short time requirement” is relevant when U2 is disabled, and both sides remain in U1. This situation is quite rare in real-life hardware, because it requires the upstream port to send an LFPS.Ping burst every 200 ms, which is mistaken for a wakeup burst by some hardware out there. Consequently, this setting is generally avoided.

Changes in USB 3.1

In a late revision of USB 3.1, the minimal LFPS burst time for U1 was raised from 0.6 μs to 0.9 μs, with several timing parameters adjusted accordingly in Tables 6-30 (Table 6-21 in USB 3.0) and Table 6-31 (Table 6-22 in USB 3.0).

Among others, the “short timing requirement” set was adjusted to allow these longer bursts.

The later USB specs recognize that some ports may transmit LFPS bursts of 0.6 μs only. However for new designs, it’s advisable to transmit 0.9 μs for U1, even if it breaks the “short timing requirement” set.

To prevent an immediate wakeup from U1, an additional restriction is added: In the USB 3.1 spec section 7.2.4.2.7, a U1_MIN_RESIDENCY_TIMER is defined, requiring either port to wait 3 μs in U1 after sending or receiving an LPMA (or after timing out waiting for it), before generating an LFPS wakeup burst, if so desired.

Entry on S3 RTC Wake

Назначение параметра: Режим сна компьютера, при котором отключаются все его компоненты, кроме оперативной памяти.

Возможные варианты значений:
Disabled — Отключено.
Enabled — Включено.

КОММЕНТАРИИ к «Entry on S3 RTC Wake»