+65
−26
Loading
Gitlab 现已全面支持 git over ssh 与 git over https。通过 HTTPS 访问请配置带有 read_repository / write_repository 权限的 Personal access token。通过 SSH 端口访问请使用 22 端口或 13389 端口。如果使用CAS注册了账户但不知道密码,可以自行至设置中更改;如有其他问题,请发邮件至 service@cra.moe 寻求协助。
At present the driver relies on valid OPMENU0/OPMENU1 register values that are programmed by BIOS to function correctly. However in a real world it's absolutely legitimate for a bootloader to leave these two registers untouched. Intel FSP for Baytrail exactly does like this. When we are booting from any Intel FSP based bootloaders like U-Boot, the driver refuses to work. We can of course program various flash opcodes in the OPMENU0/OPMENU1 registers, and such workaround can be added in either the bootloader codes, or the kernel driver itself. But a graceful solution would be to update the kernel driver to remove such limitation of OPMENU0/1 register dependency. The SPI controller settings are not locked under such configuration. So we can first check the controller locking status, and if it is not locked that means the driver job can be fulfilled by using a chosen OPMENU index to set up the flash opcode every time. While we are here, the missing 'Atomic Cycle Sequence' handling in the SW sequencer codes is also added. Signed-off-by:Bin Meng <bmeng.cn@gmail.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Cyrille Pitchen <cyrille.pitchen@wedev4u.fr>
CRA Git | Maintained and supported by SUSTech CRA and CCSE