- 14 Jun, 2020 2 commits
-
-
Priit Laes authored
Signed-off-by: Priit Laes <plaes@plaes.org>
-
Karl Palsson authored
The watchdog register isn't in the same place, nor uses the same values to trigger a reset. Signed-off-by: Karl Palsson <karlp@tweak.net.au>
-
- 20 Apr, 2020 1 commit
-
-
Karl Palsson authored
The watchdog register isn't in the same place, nor uses the same values to trigger a reset. Signed-off-by: Karl Palsson <karlp@tweak.net.au>
-
- 09 Jul, 2018 1 commit
-
-
Icenowy Zheng authored
Allwinner H6 is a new SoC with its memory map changed. Add its SoC info, including SRAM addresses and SID address. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Signed-off-by: Andre Przywara <osp@andrep.de>
-
- 27 Feb, 2018 1 commit
-
-
Jack Mitchell authored
As per the wiki[1] set ttbr0 to 0x44000 to enable the MMU. Transfer speed is increased from 191KB/s to ~800KB/s which is handy when transferring larger kernels and root filesystems. Tested on a custom H8/A83T board. [1] https://linux-sunxi.org/FEL/USBBoot
-
- 28 Feb, 2017 1 commit
-
-
Siarhei Siamashka authored
Use a hardwired L.NOP instruction from the OpenRISC reset vector as a way to check if the workaround is necessary. Because these L.NOP instructions are guaranteed to be there and are read-only, this is the most reliable non-invasive test. Reading SID would be less reliable because it is one-time programmable and theoretically may be set to zero on some boards. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
-
- 28 Dec, 2016 3 commits
-
-
Icenowy Zheng authored
H3 SID controller has some bug, that makes the initial value at 0x01c14200 wrong. This commit workarounds this bug by reading them with register access first. Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz> Reviewed-by: Bernhard Nortmann <bernhard.nortmann@web.de>
-
Bernhard Nortmann authored
This is a preparatory step. Instead of using memory-based access, we might want to retrieve SID keys (e-fuses) via SID registers. For this, it's convenient if the plain base address is available. Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
-
Icenowy Zheng authored
The V3s SoC looks like A10/13/20 in SRAM mapping and SID address. Add support for it. Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
-
- 01 Dec, 2016 1 commit
-
-
Bernhard Nortmann authored
Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
-
- 29 Nov, 2016 3 commits
-
-
Bernhard Nortmann authored
open_fel_device() will automatically provide this member field, based on the SoC ID from FEL/BROM version data. The field will either receive a human-readable identifier, or the ID in 4-digit hexadecimal representation (for unknown SoCs). Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
-
Chen-Yu Tsai authored
The SID block in the A80 is at 0x01c0e000, with the e-fuses we care about at offset 0x200 within the block. Signed-off-by: Chen-Yu Tsai <wens@csie.org>
-
Chen-Yu Tsai authored
The R40 is marketed as the successor to the A20. The SRAM layout is the same as the A20, but there doesn't seem to be a secure SRAM block. The SID block is at a completely different address. The layout is the same as the newer SoCs, with the e-fuses at an offset of 0x200. Signed-off-by: Chen-Yu Tsai <wens@csie.org>
-
- 16 Nov, 2016 1 commit
-
-
Bernhard Nortmann authored
Besides having fewer lines of code, the #define macros should also prevent users from accidentally using these names without braces (i.e. as function pointers). Instead, this will cause compiler errors now. soc_info.c: add "A10s" label in comment for SoC ID 0x1625. Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
-
- 13 Nov, 2016 1 commit
-
-
Bernhard Nortmann authored
While at it, modify the former "sram_info" identifiers to carry a broader "soc_info" meaning. Signed-off-by: Bernhard Nortmann <bernhard.nortmann@web.de>
-