樹莓派 3B+ 筦窺︰ 【POE】 USB Boot ?☻

窮舉法』是一種通用方法。它以『問題』為『解』之『對錯』的『判準』,窮盡『所有可能』的『解』作『斷言』之求解法。或可同時參閱《 M♪o 之學習筆記本《寅》井井︰【䷝】試釋是事》文中所說之『蠻力法』以及例子︰

行 ︰雖說是蠻力法,實則乃用『窮舉』,數ㄕㄨˇ數ㄕㄨˋ數不盡,耗時難為功,怎曉 機 機心迅捷後,此法遂真可行耶!?實習所用機,登入採『學號』與『針碼』【※ Pin Code 四位數字碼】 。『學號』之制 ── 班碼-位碼 ──,班不過十,位少於百,故而極其數不足千。針碼有四位,總其量,只有萬。試而盡之,『千萬』已『窮舉』。問題當在『咸澤碼訊』有多快?『登錄』之法有 多嚴 ?破解程式幾人會?設使一應具足,那個『駭黑』之事,怕是恐難免!!……

此處特別指出計算機『速度提昇』使得『窮舉法』的實用性大增,對此法的了解也就更顯得重要了。

假使將『所有可能解』看成『解空間』,將『問題』當成『約束』條件,此時『問題』的『求解』,就轉換成『尋找』『解空間』中滿足『約束』條件的『解』。一般將之稱為『蠻力搜尋法』︰

Brute-force search

In computer science, brute-force search or exhaustive search, also known as generate and test, is a very general problem-solving technique that consists of systematically enumerating all possible candidates for the solution and checking whether each candidate satisfies the problem’s statement.

A brute-force algorithm to find the divisors of a natural number n would enumerate all integers from 1 to the square root of n, and check whether each of them divides n without remainder. A brute-force approach for the eight queens puzzle would examine all possible arrangements of 8 pieces on the 64-square chessboard, and, for each arrangement, check whether each (queen) piece can attack any other.

While a brute-force search is simple to implement, and will always find a solution if it exists, its cost is proportional to the number of candidate solutions – which in many practical problems tends to grow very quickly as the size of the problem increases. Therefore, brute-force search is typically used when the problem size is limited, or when there are problem-specific heuristics that can be used to reduce the set of candidate solutions to a manageable size. The method is also used when the simplicity of implementation is more important than speed.

This is the case, for example, in critical applications where any errors in the algorithm would have very serious consequences; or when using a computer to prove a mathematical theorem. Brute-force search is also useful as a baseline method when benchmarking other algorithms or metaheuristics. Indeed, brute-force search can be viewed as the simplest metaheuristic. Brute force search should not be confused with backtracking, where large sets of solutions can be discarded without being explicitly enumerated (as in the textbook computer solution to the eight queens problem above). The brute-force method for finding an item in a table — namely, check all entries of the latter, sequentially — is called linear search.

─── 《勇闖新世界︰ 《 PYDATALOG 》【專題】之約束編程‧三

 

心想碰到『古怪』之事!如何『決斷』咦?最好用『窮舉』法☺

電源甲乙丙︰

‧ A/C Adapter

‧ PoE Splitter

‧ Official PoE HAT

情況有三種︰

‧ SD boot

‧ USB Flash connected via Power HUB, then Boot

‧ USB Flash  connected directly to Raspberry Pi, then Boot

 

同時確認官網『啟動流程』文件︰

BOOT FLOW

The flow of boot begins with reading the OTP to decide on the valid boot modes enabled. By default, this is SD card boot followed by USB device boot. Subsequently, the boot ROM checks to see if the GPIO boot mode OTP bits have been programmed — one to enable GPIO boot mode and one to select the bank of GPIOs it uses to disable boot modes (low = GPIOs 22-26, high = GPIOs 39-43). This makes it possible to use a hardware switch to choose between different boot modes if there is more than one available.

The GPIO boot mode OTP bits can be programmed by adding program_gpio_bootmode=n to config.txt, where n is 1 to select the low bank (22-26) or 2 to select the high bank (39-43). Once added, boot the device, then power-cycle it (rebooting is not sufficient). You should expect it to no longer boot (all boot modes will be disabled by default). Apply a pull-up to the required pin to enable the required boot mode. After programming, the config.txt setting can be removed.

N.B.:

  1. It is important to remember that, once set, OTP bits can never be unset, so think carefully before enabling this facility because it effectively makes 5 GPIOs unusable for other purposes. Also note that the bit assignments make it possible to switch from the low bank (22-26) to the high bank (39-43), but not back again, and that selecting the high bank is likely to produce a non-bootable Pi, unless you’re using a Compute Module (any version).
  2. Do not use program_gpio_bootmode unless your firmware is dated 20 Oct 2017 or later (vcgencmd version). Doing so will make it impossible to select the low bank of boot mode GPIOs.

Next the boot ROM checks each of the boot sources for a file called bootcode.bin; if it is successful it will load the code into the local 128K cache and jump to it. The overall boot mode process is as follows:

  • 2837 boots
  • Reads boot ROM enabled boot modes from OTP
  • Uses program_gpio_bootmode to disable some modes by reading GPIOs 22-26 or 39-43 to see if the default values do not equal the default pull to ‘0’. If it is low, it will disable that boot mode for each of SD1, SD2, NAND, SPI, USB. If the value read is a ‘1’, then that boot mode is enabled (note this cannot enable boot modes that have not already been enabled in the OTP). The default pull resistance is around 50K ohm, so a smaller pull up of 5K should suffice to enable the boot mode but still allow the GPIO to be operational without consuming too much power.
  • If enabled: check primary SD for bootcode.bin on GPIO 48-53
    • Success – Boot
    • Fail – timeout (five seconds)
  • If enabled: check secondary SD
    • Success – Boot
    • Fail – timeout (five seconds)
  • If enabled: check NAND
  • If enabled: check SPI
  • If enabled: check USB
    • If OTG pin == 0
    • Enable USB, wait for valid USB 2.0 devices (two seconds)
      • Device found:
      • If device type == hub
        • Recurse for each port
      • If device type == (mass storage or LAN951x)
        • Store in list of devices
    • Recurse through each MSD
      • If bootcode.bin found boot
    • Recurse through each LAN951x
      • DHCP / TFTP boot
    • else (Device mode boot)
    • Enable device mode and wait for host PC to enumerate
    • We reply to PC with VID: 0a5c PID: 0x2763 (Pi 1 or Pi 2) or 0x2764 (Pi 3)

NOTES:

  • If there is no SD card inserted, the SD boot mode takes five seconds to fail. To reduce this and fall back to USB more quickly, you can either insert an SD card with nothing on it or use the GPIO bootmode OTP setting described above to only enable USB.
  • The default pull for the GPIOs is defined on page 102 of the ARM Peripherals datasheet. If the value at boot time does not equal the default pull, then that boot mode is enabled.
  • USB enumeration is a means of enabling power to the downstream devices on a hub, then waiting for the device to pull the D+ and D- lines to indicate if it is either USB 1 or USB 2. This can take time: on some devices it can take up to three seconds for a hard disk drive to spin up and start the enumeration process. Because this is the only way of detecting that the hardware is attached, we have to wait for a minimum amount of time (two seconds). If the device fails to respond after this maximum timeout, it is possible to increase the timeout to five seconds using program_usb_boot_timeout=1 in config.txt.
  • MSD takes precedence over Ethernet boot.
  • It is no longer necessary for the first partition to be the FAT partition, as the MSD boot will continue to search for a FAT partition beyond the first one.
  • The boot ROM also now supports GUID partitioning and has been tested with hard drives partitioned using Mac, Windows, and Linux.
  • The LAN951x is detected using the Vendor ID 0x0424 and Product ID 0xec00, this is different to the standalone LAN9500 device which has a product ID of 0x9500 or 0x9e00. To use the standalone LAN9500 an I2C EEPROM would need to be added to change these ID’s to match the LAN9514

The primary SD card boot mode is, as standard, set to be GPIOs 49-53. It is possible to boot from the secondary SD card on a second set of pins, i.e. to add a secondary SD card to the GPIO pins. However, we have not yet enabled this ability.

NAND boot and SPI boot modes do work, although they do not yet have full GPU support.

The USB device boot mode is enabled by default at the time of manufacture, but the USB host boot mode is only enabled with program_usb_boot_mode=1. Once enabled, the processor will use the value of the OTGID pin on the processor to decide between the two modes. On a Raspberry Pi Model B, the OTGID pin is driven to ‘0’ and therefore will only boot via host mode once enabled (it is not possible to boot through device mode because the LAN9515 device is in the way).

The USB will boot as a USB device on the Pi Zero or Compute Module if the OTGID pin is left floating (when plugged into a PC for example), so you can ‘squirt’ the bootcode.bin into the device. The code for doing this is usbboot.

 

為何一切行禮如儀,十之八九如其所言,可是唯獨

Official PoE HAT + USB Flash  connected directly to Raspberry Pi, then Boot

這個組合卻不行呢?☻

 

 

 

 

 

 

 

 

樹莓派 3B+ 筦窺︰ 【POE】號外

難得寫作文章之際,發現如此『號外』事件︰

Re: PoE HAT – USB Ports not working – over-current

jamesh

Tue Sep 11, 2018 2:22 pm

OK all, as some will have seen on the Register (www.theregister.co.uk) we think we have got to the bottom of this. Here is a letter from Eben sent to the Register, who had asked what was up after some of their readers got in touch.

We’ve been looking at this over the last week, and have a good handle on the underlying mechanism: it’s an interaction between the fairly low-frequency switching regulator on the HAT, and one of the two brands of USB current limiting switch that we use on the main board. Because the regulator operates at a fairly low frequency, each time it switches it moves quite a large chunk of energy into the three USB reservoir caps via the current limiting switch: this large instantaneous current is fooling the switch into thinking that a genuine over-current event is occurring. We missed it in product testing because (dumb luck) our heavy-load testing was done on boards with the other brand of switch, and most of our field testers were only using the board to power mice and keyboards, which works fine on all the HAT/Pi pairs we’ve tested.

There will be a blog post of gory details, probably tomorrow, but for now the summary is:

– A significant proportion of HAT/Pi pairs are limited to delivering <200mA of downstream current to USB. This is generally enough for mice and keyboards, but not for e.g. hard drives.
– We will fix this issue in a subsequent spin of the PoE HAT.
– In the meantime we’ll be adding a note where the HAT is sold, documenting this limitation.
– We will provide a couple of hand-mod options for adventurous users. These are likely to be:
– Removing reservoir caps from the main board (an easy, clean mod if you can use a soldering iron, but limits USB hotpluggability).
– Inserting a small amount of series impedance in the current path from the HAT (this one will be a bit fiddly to implement).
– Users who have bought a HAT and are inconvenienced by this issue should return it for a refund.

The moral of the story: do more testing, particularly where we have multiple vendors for key bits of silicon.

I hope that covers all the questions that have been asked above.

 

心想這個【POE】文本系列,主旨是談『測試‧除錯』過程 ,十分樂見 Eben 先生的快速全面回應呦。

所以依舊照表操課也。