Compiling U-Boot with ubsan/asan libraries and running it in sandbox
may lead to below backtrace:

 => avb init 0
 => avb verify
 ## Android Verified Boot 2.0 version 1.1.0
read_is_device_unlocked not supported yet
common/avb_verify.c:407:31: runtime error: division by zero
AddressSanitizer:DEADLYSIGNAL
Reviewed-by: Igor Opaniuk <[email protected]>

=================================================================
==9388==ERROR: AddressSanitizer: FPE on unknown address 0x0000004b467f \
    (pc 0x0000004b467f bp 0x000000000000 sp 0x7ffd899fe150 T0)
    #0 0x4b467e in mmc_byte_io common/avb_verify.c:407
    #1 0x4b4c47 in mmc_byte_io common/avb_verify.c:532
    #2 0x4b4c47 in read_from_partition common/avb_verify.c:533
    #3 0x69dc0d in load_and_verify_vbmeta lib/libavb/avb_slot_verify.c:560
    #4 0x6a1ee6 in avb_slot_verify lib/libavb/avb_slot_verify.c:1139
    #5 0x45dabd in do_avb_verify_part cmd/avb.c:245
    #6 0x4af77c in cmd_call common/command.c:499
    #7 0x4af77c in cmd_process common/command.c:538
    #8 0x46bafc in run_pipe_real common/cli_hush.c:1677
    #9 0x46bafc in run_list_real common/cli_hush.c:1875
    #10 0x46c780 in run_list common/cli_hush.c:2024
    #11 0x46c780 in parse_stream_outer common/cli_hush.c:3216
    #12 0x46d34b in parse_file_outer common/cli_hush.c:3299
    #13 0x4ad609 in cli_loop common/cli.c:217
    #14 0x4625ae in main_loop common/main.c:65
    #15 0x46f2d1 in run_main_loop common/board_r.c:648
    #16 0x640253 in initcall_run_list lib/initcall.c:30
    #17 0x46f9d0 in board_init_r common/board_r.c:879
    #18 0x40539b in main arch/sandbox/cpu/start.c:321
    #19 0x7fa94925f82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #20 0x408908 in _start (/srv/R/u-boot-master/u-boot+0x408908)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE common/avb_verify.c:407 in mmc_byte_io
==9388==ABORTING

Signed-off-by: Eugeniu Rosca <[email protected]>

This patch fixes the following:
1. KR/SFI on lane u-boot#4 mux selector is 0x2 and not 0x1
2. Comment typo

Change-Id: I1e628576dc483697e454408463a34dac13ba277c
Signed-off-by: Rabeeh Khoury <[email protected]>
Signed-off-by: Stefan Roese <[email protected]>
Signed-off-by: Igal Liberman <[email protected]>
Reviewed-on: http://vgitil04.il.marvell.com:8080/38769
Tested-by: iSoC Platform CI <[email protected]>
Reviewed-by: Kostya Porotchkin <[email protected]>

v2019.04-rc3 sandbox U-Boot fails to boot when compiled with
 -fsanitize=address and linked against -lasan, reporting [1].

Git bisecting shows that the issue is contributed by v2019.01 commit
1678754 ("core: ofnode: Fix ofnode_get_addr_index function").

The root cause seems to be the mismatch between sizeof(u64) and
sizeof(fdt_size_t) on sandbox. Luckily, thanks to the fact that the
size argument of both of_get_address() and fdtdec_get_addr_size_fixed()
is optional, we can pass NULL in its place, avoiding the problem.

[1] Backtrace reported by ASAN (gcc 8.1.0):

$> ./u-boot -d arch/sandbox/dts/sandbox.dtb
[..]
Reviewed-by: Simon Glass <[email protected]>

=================================================================
==10998==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcc2331140 at pc 0x0000004eeeb0 bp 0x7ffcc2330f80 sp 0x7ffcc2330f70
WRITE of size 8 at 0x7ffcc2331140 thread T0
    #0 0x4eeeaf in of_get_address drivers/core/of_addr.c:154
    #1 0x4f7441 in ofnode_get_addr_index drivers/core/ofnode.c:263
    #2 0x5b2a78 in sb_eth_ofdata_to_platdata drivers/net/sandbox.c:422
    #3 0x4dccd8 in device_probe drivers/core/device.c:407
    #4 0x753170 in eth_initialize net/eth-uclass.c:428
    #5 0x47d9bf in initr_net common/board_r.c:557
    #6 0x6bcfa7 in initcall_run_list lib/initcall.c:30
    #7 0x47e1fe in board_init_r common/board_r.c:859
    #8 0x4060e5 in main arch/sandbox/cpu/start.c:356
    #9 0x7fb8d135482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #10 0x40a3a8 in _start (/path/to/u-boot/u-boot+0x40a3a8)

Address 0x7ffcc2331140 is located in stack of thread T0 at offset 32 in frame
    #0 0x4f72b8 in ofnode_get_addr_index drivers/core/ofnode.c:255

  This frame has 3 object(s):
    [32, 36) 'size' <== Memory access at offset 32 partially overflows this variable
    [96, 100) 'flags'
    [160, 168) 'node'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
      (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow drivers/core/of_addr.c:154 in of_get_address
Shadow bytes around the buggy address:
  0x10001845e1d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001845e1e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001845e1f0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
  0x10001845e200: 04 f2 f2 f2 f2 f2 f2 f2 04 f2 f2 f2 f2 f2 f2 f2
  0x10001845e210: 04 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00
=>0x10001845e220: 00 00 00 00 f1 f1 f1 f1[04]f2 f2 f2 f2 f2 f2 f2
  0x10001845e230: 04 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f3 f3 f3 f3
  0x10001845e240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10001845e250: 00 00 00 00 f1 f1 f1 f1 00 00 f2 f2 f3 f3 f3 f3
  0x10001845e260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
  0x10001845e270: f1 f1 00 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==10998==ABORTING

'To' list:
 git log --since=1year drivers/core/ofnode.c | grep "\-by: .*@" | \
     sed 's/.*-by: //' | sort | uniq -c | sort -rn
     10 Simon Glass <[email protected]>
      3 Mario Six <[email protected]>
      2 Martin Fuzzey <[email protected]>
      2 Marek Vasut <[email protected]>
      1 Tom Rini <[email protected]>
      1 Masahiro Yamada <[email protected]>
      1 Keerthy <[email protected]>
      1 Jens Wiklander <[email protected]>
      1 Bin Meng <[email protected]>

Fixes: 1678754 ("core: ofnode: Fix ofnode_get_addr_index function")
Signed-off-by: Eugeniu Rosca <[email protected]>

Compiling U-Boot with ubsan/asan libraries and running it in sandbox
may lead to below backtrace:

 => avb init 0
 => avb verify
 ## Android Verified Boot 2.0 version 1.1.0
read_is_device_unlocked not supported yet
common/avb_verify.c:407:31: runtime error: division by zero
AddressSanitizer:DEADLYSIGNAL
Reviewed-by: Igor Opaniuk <[email protected]>

=================================================================
==9388==ERROR: AddressSanitizer: FPE on unknown address 0x0000004b467f \
    (pc 0x0000004b467f bp 0x000000000000 sp 0x7ffd899fe150 T0)
    #0 0x4b467e in mmc_byte_io common/avb_verify.c:407
    #1 0x4b4c47 in mmc_byte_io common/avb_verify.c:532
    #2 0x4b4c47 in read_from_partition common/avb_verify.c:533
    #3 0x69dc0d in load_and_verify_vbmeta lib/libavb/avb_slot_verify.c:560
    #4 0x6a1ee6 in avb_slot_verify lib/libavb/avb_slot_verify.c:1139
    #5 0x45dabd in do_avb_verify_part cmd/avb.c:245
    #6 0x4af77c in cmd_call common/command.c:499
    u-boot#7 0x4af77c in cmd_process common/command.c:538
    u-boot#8 0x46bafc in run_pipe_real common/cli_hush.c:1677
    u-boot#9 0x46bafc in run_list_real common/cli_hush.c:1875
    u-boot#10 0x46c780 in run_list common/cli_hush.c:2024
    u-boot#11 0x46c780 in parse_stream_outer common/cli_hush.c:3216
    u-boot#12 0x46d34b in parse_file_outer common/cli_hush.c:3299
    u-boot#13 0x4ad609 in cli_loop common/cli.c:217
    u-boot#14 0x4625ae in main_loop common/main.c:65
    u-boot#15 0x46f2d1 in run_main_loop common/board_r.c:648
    u-boot#16 0x640253 in initcall_run_list lib/initcall.c:30
    u-boot#17 0x46f9d0 in board_init_r common/board_r.c:879
    u-boot#18 0x40539b in main arch/sandbox/cpu/start.c:321
    u-boot#19 0x7fa94925f82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    u-boot#20 0x408908 in _start (/srv/R/u-boot-master/u-boot+0x408908)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE common/avb_verify.c:407 in mmc_byte_io
==9388==ABORTING

Signed-off-by: Eugeniu Rosca <[email protected]>

…x018-develop

* commit 'e73caed9c8a33436395f6d3d0f91b72f9f3e7588':
  Renamed target config 1888tx018_defconf -> mb115-01_defconf
  /drivers/nmc/rcm_* files fixed: functions & variables names was renamed from rcm_1888tx018_ to rcm_
  Some errors was fixed. U-Boot is compiling without errors now.
  Updating device tree files using the identifier 1888TX018 to designate a microchip and RCM as a vendor prefix

pcl063_ull: Add ccon-mender compatibility / disable eMMC

Approved-by: Fredrik Flornes Ellertsen

Add detailed SMBIOS information as following:
1. Missing fields in Type u-boot#3 and u-boot#4
2. Type u-boot#7

Add support to dynamic length of contained object handles and
elements.

As SMBIOS is a fundamental feature which is enabled for all
boards, in order to avoid increasing rom size, all detailed SMBIOS
information is under kconfig GENERATE_SMBIOS_TABLE_VERBOSE.
Board maintainers can determine whether to select this feature.

Signed-off-by: Raymond Mao <[email protected]>

Add detailed SMBIOS information as following:
1. Missing fields in Type u-boot#3 and u-boot#4
2. Type u-boot#7

Add support to dynamic length of contained object handles and
elements.

As SMBIOS is a fundamental feature which is enabled for all
boards, in order to avoid increasing rom size, all detailed SMBIOS
information is under kconfig GENERATE_SMBIOS_TABLE_VERBOSE.
Board maintainers can determine whether to select this feature.

Signed-off-by: Raymond Mao <[email protected]>

Add detailed SMBIOS information as following:
1. Missing fields in Type u-boot#3 and u-boot#4
2. Type u-boot#7

Add support to dynamic length of contained object handles and
elements.

As SMBIOS is a fundamental feature which is enabled for all
boards, in order to avoid increasing rom size, all detailed SMBIOS
information is under kconfig GENERATE_SMBIOS_TABLE_VERBOSE.
Board maintainers can determine whether to select this feature.

Signed-off-by: Raymond Mao <[email protected]>

Add detailed SMBIOS information as following:
1. Missing fields in Type u-boot#3 and u-boot#4
2. Type u-boot#7

Add support to dynamic length of contained object handles and
elements.

As SMBIOS is a fundamental feature which is enabled for all
boards, in order to avoid increasing rom size, all detailed SMBIOS
information is under kconfig GENERATE_SMBIOS_TABLE_VERBOSE.
Board maintainers can determine whether to select this feature.

Signed-off-by: Raymond Mao <[email protected]>

Raymond Mao <[email protected]> says:

Motivations for changes:
Current SMBIOS library and command-line tool is not fully matching with
the requirements:
1. Missing support for other mandatory types (u-boot#7, u-boot#9, u-boot#16, u-boot#17, u-boot#19).
2. Only a few platforms support SMBIOS node from the device tree.
3. Values of some fields are hardcoded in the library other than fetching
   from the device hardware.
4. Embedded data with dynamic length is not supported (E.g. Contained
   Object Handles in Type u-boot#2 and Contained Elements in Type u-boot#3)

Changes:
1. Refactor the SMBIOS library and command-line tool to better align with
   the SMBIOS spec.
2. Create an arch-specific driver for all aarch64-based platforms to fetch
   SMBIOS private data from the device hardware (processor and cache).
3. Create a sysinfo driver to poppulate platform SMBIOS private data.
4. Add generic SMBIOS DTS file for arm64 platforms for those common strings
   and values which cannot be retrieved from the system registers.
   Vendors can create their own SMBIOS node using this as an example.
   For those boards without SMBIOS nodes, this DTS file can be included to
   have a generic SMBIOS information of the system.
5. Add support for Type u-boot#7 (Cache Information) and link its handles to
   Type u-boot#4.
6. To minimize size-growth for those platforms which have not sufficient
   ROM spaces or the platforms which don't need detailed SMBIOS
   information, new added fields are only being built when kconfig
   GENERATE_SMBIOS_TABLE_VERBOSE is selected.

Once this patch is acceptted, subsequent patch sets will add other missing
types (u-boot#9, u-boot#16, u-boot#17, u-boot#19).

Tests:
To test this with QEMU arm64, please follow the guide on dt_qemu.rst to
get a merged DT to run with.
```
qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb
cat  <(dtc -I dtb qemu.dtb) <(dtc -I dtb ./dts/dt.dtb | grep -v /dts-v1/) \
  | dtc - -o merged.dtb
qemu-system-aarch64 -machine virt -nographic -bios u-boot.bin \
  -dtb merged.dtb
```

Link: https://lore.kernel.org/r/[email protected]

Add detailed SMBIOS information as following:
1. Missing fields in Type #3 and #4
2. Type #7

Add support to dynamic length of contained object handles and
elements.

As SMBIOS is a fundamental feature which is enabled for all
boards, in order to avoid increasing rom size, all detailed SMBIOS
information is under kconfig GENERATE_SMBIOS_TABLE_VERBOSE.
Board maintainers can determine whether to select this feature.

Signed-off-by: Raymond Mao <[email protected]>

Raymond Mao <[email protected]> says:

Motivations for changes:
Current SMBIOS library and command-line tool is not fully matching with
the requirements:
1. Missing support for other mandatory types (#7, #9, #16, #17, #19).
2. Only a few platforms support SMBIOS node from the device tree.
3. Values of some fields are hardcoded in the library other than fetching
   from the device hardware.
4. Embedded data with dynamic length is not supported (E.g. Contained
   Object Handles in Type #2 and Contained Elements in Type #3)

Changes:
1. Refactor the SMBIOS library and command-line tool to better align with
   the SMBIOS spec.
2. Create an arch-specific driver for all aarch64-based platforms to fetch
   SMBIOS private data from the device hardware (processor and cache).
3. Create a sysinfo driver to poppulate platform SMBIOS private data.
4. Add generic SMBIOS DTS file for arm64 platforms for those common strings
   and values which cannot be retrieved from the system registers.
   Vendors can create their own SMBIOS node using this as an example.
   For those boards without SMBIOS nodes, this DTS file can be included to
   have a generic SMBIOS information of the system.
5. Add support for Type #7 (Cache Information) and link its handles to
   Type #4.
6. To minimize size-growth for those platforms which have not sufficient
   ROM spaces or the platforms which don't need detailed SMBIOS
   information, new added fields are only being built when kconfig
   GENERATE_SMBIOS_TABLE_VERBOSE is selected.

Once this patch is acceptted, subsequent patch sets will add other missing
types (#9, #16, #17, #19).

Tests:
To test this with QEMU arm64, please follow the guide on dt_qemu.rst to
get a merged DT to run with.
```
qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb
cat  <(dtc -I dtb qemu.dtb) <(dtc -I dtb ./dts/dt.dtb | grep -v /dts-v1/) \
  | dtc - -o merged.dtb
qemu-system-aarch64 -machine virt -nographic -bios u-boot.bin \
  -dtb merged.dtb
```

Link: https://lore.kernel.org/r/[email protected]

commit 2e2c2a5 ("arm: qemu: override flash accessors to use virtualizable instructions")
explains why we can't have instructions with multiple output registers
when running under QEMU + KVM and the instruction leads to an exception
to the hypervisor.

USB XHCI is such a case (MMIO) where a ldr w1, [x0], #4 is emitted for
xhci_start() which works fine with QEMU but crashes for QEMU + KVM.

These instructions cannot be emulated by KVM as they do not produce
syndrome information data that KVM can use to infer the destination
register, the faulting address, whether it was a load or store, or
if it's a 32 or 64 bit general-purpose register.
As a result an external abort is injected from QEMU, via ext_dabt_pending
to KVM and we end up throwing an exception that looks like

 U-Boot 2025.07-rc4 (Jun 10 2025 - 12:00:15 +0000)
 [...]
 Register 8001040 NbrPorts 8
 Starting the controller
 "Synchronous Abort" handler, esr 0x96000010, far 0x10100040
 elr: 000000000005b1c8 lr : 000000000005b1ac (reloc)
 elr: 00000000476fc1c8 lr : 00000000476fc1ac
 x0 : 0000000010100040 x1 : 0000000000000001
 x2 : 0000000000000000 x3 : 0000000000003e80
 x4 : 0000000000000000 x5 : 00000000477a5694
 x6 : 0000000000000038 x7 : 000000004666f360
 x8 : 0000000000000000 x9 : 00000000ffffffd8
 x10: 000000000000000d x11: 0000000000000006
 x12: 0000000046560a78 x13: 0000000046560dd0
 x14: 00000000ffffffff x15: 000000004666eed2
 x16: 00000000476ee2f0 x17: 0000000000000000
 x18: 0000000046660dd0 x19: 000000004666f480
 x20: 0000000000000000 x21: 0000000010100040
 x22: 0000000010100000 x23: 0000000000000000
 x24: 0000000000000000 x25: 0000000000000000
 x26: 0000000000000000 x27: 0000000000000000
 x28: 0000000000000000 x29: 000000004666f360

 Code: d5033fbf aa1503e0 5287d003 52800002 (b8004401)
 Resetting CPU ...

There are two problems making this the default.
- It will emit ldr + add or str + add instead of ldr/str(post increment)
  in somne cases
- Some platforms that depend on TPL/SPL grow in size enough so that the
  binary doesn't fit anymore.

So let's add proper I/O accessors add a Kconfig option
to turn it off by default apart from our QEMU builds.

Reported-by: Mikko Rapeli <[email protected]>
Tested-by: Mikko Rapeli <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>

commit 2e2c2a5 ("arm: qemu: override flash accessors to use virtualizable instructions")
explains why we can't have instructions with multiple output registers
when running under QEMU + KVM and the instruction leads to an exception
to the hypervisor.

USB XHCI is such a case (MMIO) where a ldr w1, [x0], u-boot#4 is emitted for
xhci_start() which works fine with QEMU but crashes for QEMU + KVM.

These instructions cannot be emulated by KVM as they do not produce
syndrome information data that KVM can use to infer the destination
register, the faulting address, whether it was a load or store, or
if it's a 32 or 64 bit general-purpose register.
As a result an external abort is injected from QEMU, via ext_dabt_pending
to KVM and we end up throwing an exception that looks like

 U-Boot 2025.07-rc4 (Jun 10 2025 - 12:00:15 +0000)
 [...]
 Register 8001040 NbrPorts 8
 Starting the controller
 "Synchronous Abort" handler, esr 0x96000010, far 0x10100040
 elr: 000000000005b1c8 lr : 000000000005b1ac (reloc)
 elr: 00000000476fc1c8 lr : 00000000476fc1ac
 x0 : 0000000010100040 x1 : 0000000000000001
 x2 : 0000000000000000 x3 : 0000000000003e80
 x4 : 0000000000000000 x5 : 00000000477a5694
 x6 : 0000000000000038 x7 : 000000004666f360
 x8 : 0000000000000000 x9 : 00000000ffffffd8
 x10: 000000000000000d x11: 0000000000000006
 x12: 0000000046560a78 x13: 0000000046560dd0
 x14: 00000000ffffffff x15: 000000004666eed2
 x16: 00000000476ee2f0 x17: 0000000000000000
 x18: 0000000046660dd0 x19: 000000004666f480
 x20: 0000000000000000 x21: 0000000010100040
 x22: 0000000010100000 x23: 0000000000000000
 x24: 0000000000000000 x25: 0000000000000000
 x26: 0000000000000000 x27: 0000000000000000
 x28: 0000000000000000 x29: 000000004666f360

 Code: d5033fbf aa1503e0 5287d003 52800002 (b8004401)
 Resetting CPU ...

There are two problems making this the default.
- It will emit ldr + add or str + add instead of ldr/str(post increment)
  in somne cases
- Some platforms that depend on TPL/SPL grow in size enough so that the
  binary doesn't fit anymore.

So let's add proper I/O accessors add a Kconfig option
to turn it off by default apart from our QEMU builds.

Reported-by: Mikko Rapeli <[email protected]>
Tested-by: Mikko Rapeli <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>

commit 2e2c2a5 ("arm: qemu: override flash accessors to use virtualizable instructions")
explains why we can't have instructions with multiple output registers
when running under QEMU + KVM and the instruction leads to an exception
to the hypervisor.

USB XHCI is such a case (MMIO) where a ldr w1, [x0], u-boot#4 is emitted for
xhci_start() which works fine with QEMU but crashes for QEMU + KVM.

These instructions cannot be emulated by KVM as they do not produce
syndrome information data that KVM can use to infer the destination
register, the faulting address, whether it was a load or store, or
if it's a 32 or 64 bit general-purpose register.
As a result an external abort is injected from QEMU, via ext_dabt_pending
to KVM and we end up throwing an exception that looks like

 U-Boot 2025.07-rc4 (Jun 10 2025 - 12:00:15 +0000)
 [...]
 Register 8001040 NbrPorts 8
 Starting the controller
 "Synchronous Abort" handler, esr 0x96000010, far 0x10100040
 elr: 000000000005b1c8 lr : 000000000005b1ac (reloc)
 elr: 00000000476fc1c8 lr : 00000000476fc1ac
 x0 : 0000000010100040 x1 : 0000000000000001
 x2 : 0000000000000000 x3 : 0000000000003e80
 x4 : 0000000000000000 x5 : 00000000477a5694
 x6 : 0000000000000038 x7 : 000000004666f360
 x8 : 0000000000000000 x9 : 00000000ffffffd8
 x10: 000000000000000d x11: 0000000000000006
 x12: 0000000046560a78 x13: 0000000046560dd0
 x14: 00000000ffffffff x15: 000000004666eed2
 x16: 00000000476ee2f0 x17: 0000000000000000
 x18: 0000000046660dd0 x19: 000000004666f480
 x20: 0000000000000000 x21: 0000000010100040
 x22: 0000000010100000 x23: 0000000000000000
 x24: 0000000000000000 x25: 0000000000000000
 x26: 0000000000000000 x27: 0000000000000000
 x28: 0000000000000000 x29: 000000004666f360

 Code: d5033fbf aa1503e0 5287d003 52800002 (b8004401)
 Resetting CPU ...

There are two problems making this the default.
- It will emit ldr + add or str + add instead of ldr/str(post increment)
  in somne cases
- Some platforms that depend on TPL/SPL grow in size enough so that the
  binary doesn't fit anymore.

So let's add proper I/O accessors add a Kconfig option
to turn it off by default apart from our QEMU builds.

Reported-by: Mikko Rapeli <[email protected]>
Tested-by: Mikko Rapeli <[email protected]>
Signed-off-by: Ilias Apalodimas <[email protected]>