+105
−19
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
Its possible that the Module may fail to download the next stage firmware, or to jump into it and boot into the new personality. We have already seen examples of both of these cases on EVT 1.5. This patch implements timeouts in the bootrom bundle driver, which now expects the next request from the Module to be received at the AP within 1 second of the previous request/response. The time interval can be increased later if required. The timeouts are added between: - AP_READY and FIRMWARE_SIZE operations - FIRMWARE_SIZE and GET_FIRMWARE operations - Two GET_FIRMWARE operations - GET_FIRMWARE and READY_TO_BOOT operations - READY_TO_BOOT operation and the call to the ->disconnect() event of the bootrom bundle (once the new hotplug request is received). The timeout for the last case is kept at 5 seconds right now (random value), as it may take a bit longer. Because 'bootrom->fw' can be accessed simultaneously (from timeout handler and incoming requests) and one of them can potentially free the '->fw' structure, a mutex is also added to take care of such races while accessing 'bootrom->fw' structure. Also note that the '!bootrom->fw' check is moved to free_firmware() routine. Tested on EVT 1.5, by faking errors on certain requests, so that the bootrom doesn't send any more requests. Normal case is working just fine for audio and GP modules. Signed-off-by:Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@google.com>
CRA Git | Maintained and supported by SUSTech CRA and CCSE