fix(console): the serial line is found, not assumed -- from the devicetree on a board, COM1 by probe on a PC
Each board has one serial line that is its console, the lowest common denominator beside the screen and keyboard. Its address was QEMU's, fixed: on a Raspberry Pi 5 the aarch64 one is ordinary RAM, written to with every character printed; on a Milk-V Mars the riscv64 one is the board's UART with registers four bytes apart, and the UEFI loader would have waited for ever on its first character; on a PC with no COM1 the prompt read 0xFF for ever. console_attach_serial(), called before anything prints: COM1 if a UART answers there; elsewhere the UART that /chosen/stdout-path names (fdt_uart.c: alias, path, the address carried up through each bus's ranges, reg-shift and reg-io-width); with no devicetree, QEMU's. A devicetree that names no usable console gives no line, not a guess. A line that does not come ready is given up, not waited on. The riscv64 loader's early serial does the same. tools/fdt_uart_test.c, run by hand, 19 checks plain and under the sanitizers: devicetrees shaped like the Mars's, the Pi 5's and QEMU's, what must find nothing, and a block cut short at every length; and the Pi 5's real devicetree gives a PL011 at 0x107d001000. Acceptance, one QEMU at a time: v3 on amd64 (logs/20261013-204436), aarch64 (-204803) and riscv64 (-205001) to the zuse prompt, no unknown word, hash 0x08873e0f44b7cb2a on all three as before. -204600 is an aarch64 run during which the disk images were restored under it by a script that had been refused a second QEMU; it passed and is kept, and was run again. v4 on the three ISAs (-211149, -211444, -211857): POST 538 of 538, dict_hash 0xe5a57f3eb72ff94a, the typed session unchanged. The Mars image through OpenSBI and U-Boot in QEMU took its line and its interrupt controller from the devicetree and passed POST. Found on the way and not mended (boards/BRINGUP.md 1.6): built with EMERGENCY_CONSOLE_ENABLED=1 the prompt floods with empty lines. -210442 shows it; the commit before this does the same. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 5.5
parent
f4e359859a
commit
c95191736e
@@ -167,4 +167,37 @@ const void* fdt_next_child_node(const void* fdt, const void* parent,
|
||||
const void* fdt_find_prop_in_node(const void* fdt, const void* node,
|
||||
const char* name, uint32_t* len_out);
|
||||
|
||||
/**
|
||||
* @brief Is the structure block whole?
|
||||
* @c fdt_valid() checks the header; this checks also that the structure
|
||||
* block ends with its end token, as a blob that has not been cut short
|
||||
* does. A reader that takes a property's absence to mean its default
|
||||
* (a UART's "reg-shift") must not be handed half a tree.
|
||||
* @return 1 if @p fdt is valid and its structure block ends with FDT_END.
|
||||
*/
|
||||
int fdt_complete(const void* fdt);
|
||||
|
||||
/**
|
||||
* @brief The root node.
|
||||
* @param fdt Blob; checked with @c fdt_valid().
|
||||
* @return Handle to the root node, for @c fdt_find_child() and
|
||||
* @c fdt_find_prop_in_node(), or NULL.
|
||||
*/
|
||||
const void* fdt_root_node(const void* fdt);
|
||||
|
||||
/**
|
||||
* @brief Find a direct child of a node by its whole name.
|
||||
* The name is matched exactly, unit address included ("serial@10000000"
|
||||
* is not "serial"), and is given with its length so that one component of
|
||||
* a path can be passed without copying it. Only @p parent's own children
|
||||
* are looked at, never their descendants.
|
||||
* @param fdt Blob; checked with @c fdt_valid().
|
||||
* @param parent Node handle; NULL is safe and returns NULL.
|
||||
* @param name The child's name; need not be NUL-terminated.
|
||||
* @param name_len Its length in bytes.
|
||||
* @return Handle to the child, or NULL if @p parent has none of that name.
|
||||
*/
|
||||
const void* fdt_find_child(const void* fdt, const void* parent,
|
||||
const char* name, uint32_t name_len);
|
||||
|
||||
#endif /* STARKERNEL_FDT_H */
|
||||
|
||||
Reference in New Issue
Block a user